8.5 Software Configuration Management Plan (SCMP)

---

Once an official baseline release of the product has been made, configuration management should be implemented in all circumstances. Ideally, configuration management will have been started early on in the code development process by the developers, and transfer of the configuration management responsibility can be made from the development teams to a configuration management group. In planning for software configuration management, well-respected software engineering expert Watts Humphrey[10] recommends that your plan include several key tasks:

• Configuration control

• Change management

• Revisions

• Versions

• Deltas

• Conditional code

Configuration control begins with the establishment of a single baseline copy of the product source code. A library for the master copy of the source code should be established, and managed check-in and check-out procedures should be instituted. This single copy should be used for all subsequent builds. All changes and updates are reflected in the build. Interim checks are often established to prevent corruption of the master by requiring strict quality assurance and enforcing audit control procedures. The use of a single master for builds ensures that all changes are reflected in the latest version, and testing will account for such changes.

Change management and revision control refers in part to how modules that are checked in and out of the master source library are tracked.

Generally, a release has a major version ID, a minor version ID, and a build number associated with it. It would be unwise to mix release 2.2 build 1104 with release 3.1 build 100. Although it may have no bad side effects, you cannot be sure. It is better to regenerate all modules used in major release 3 as version 3.0 baseline code and have all builds, starting with the first one, increment from that. Mixing and matching among revisions is a sure way to court disaster.

Revisions of the current working release of code will generally increment the build number. In some places, a daily build-and-test (smoke test) process is done to ensure that all code worked on to that point will still compile and execute. While these daily revisions generally increment the build number, cutovers to periodic code fixes or updates, such as quarterly maintenance releases, will usually increment the minor version ID. Changes that add significant functionality or upgrade the performance of an application will usually be done through a new release, complete with marketing collateral, advertising, and so on. These changes generally increment the major version ID.

Deltas can best be described as changed copies of the same code. The differences that exist in one of the identical code modules when compared with the original are referred to as deltas. The deltas between current and original are tracked for various reasons. Applications often need to be generated for different platforms, and one platform may require something to be done slightly differently from the other platform. Rather than creating completely different modules, sometimes it is more efficient to manage the deltas and incorporate the changes separately into the master build. Another means of solving this problem is using conditional code.

Conditional code may make logic distinctions, such as comparing which version of software is running and performing one task if the version number is equal to or above a version number and another if it is below the version number.

---