CONCEPTS IN CONFIGURATION MANAGEMENT | Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It

9.1 CONCEPTS IN CONFIGURATION MANAGEMENT

CM is essential to satisfy one of the basic objectives of a project: delivery of a high-quality software product to the client. What is this "software" that is delivered? At the least, it contains the various source or object files that make up the source or object code, scripts to build the working system from these files, and associated documentation. During the project, the files change, leading to the creation of different versions. In this situation, how does a program manager ensure that the appropriate versions of source code files are combined without missing any source, and that the correct versions of the documents, consistent with the final source, are sent? All this is ensured through proper CM.

A primary objective of CM is to manage the evolving configuration of the software system.¹^,² In a project, a program's evolution takes it through many states. At the beginning, when a programmer develops it, the program is under development (or "private"). Once the programmer is satisfied with the program, it moves into the "ready for unit testing" state. Only when the program reaches this state can it be unit tested. After it has been unit tested, the programmer must fix any defects found. If the unit testing succeeds, however, then the program's state changes to "ready for system testing." Only when all programs reach this state can system testing commence. Again, if defects are found during system testing, the state of a program reverts to "private"; otherwise, it moves to "ready for acceptance testing." If the acceptance testing succeeds, the state of all programs changes to "ready for release," implying that they can now be released for "production use." Once a program is released and is in production use, all the programs (and associated documentation) move to the "baselined" state, which represents the state of the production system.

In addition to the changes that take place during the normal course of software development, requirement change requests may be submitted, and their implementation may alter programs. When a project has a large number of items that can be changed, developers may be called on to take many actions; these actions can be performed only if proper support is available from the CM process.

To better understand CM, let's consider the kinds of CM functionality projects require. Although these requirements can depend on the nature of the project and the exact situation, some general functions can be specified. Following is a list of some of these functions along with scenarios where they might be needed. These functions are more detailed than the CM functions defined in Humphrey.³

Give the states of the programs. You need this information to decide when to start testing or when to release the software.

Give the latest version of a program. Suppose that a program must be modified. Clearly, the modification must be carried out in the latest version; otherwise, earlier changes may be lost.

Handle concurrent update requests. Two programmers, in response to two different change requests, might change the same program concurrently. One of the changes could potentially overwrite the other change. Avoiding such a situation requires access control so that only one person can make changes to a program at a time. If multiple parallel changes are allowed, reconciliation procedures should be implemented to ensure that all changes are reflected in the final version.

Undo a program change. A change is made to a program (to implement a change request), but later a need arises to reverse this change request.

Prevent unauthorized changes or deletions. A programmer may decide to change some programs, only to discover that the change has adverse side effects. Access control mechanisms are needed to disallow unapproved changes.

Provide traceability between requirement change requests and program changes. Suppose a requirement change request dictates that three programs be modified, and these modifications have been assigned to three team members. How does a project manager ensure that this change request has been properly implemented that is, that all programs have been changed and that the changed programs have gone through their life cycle and are in a "ready for release" state? Answering this question requires a mechanism to track change requests that can specify all programs to be changed as well as the state of each program.

Undo a requirement change. A requirement change request that was implemented (by changing many programs) may later need to be undone (perhaps because the users do not like the new features).

Show associated changes. Suppose a bug is found in a program, and it is suspected that this bug came from the implementation of a change request. It is desirable to review all changes made as a result of that change request.

Gather all sources, documents, and other information for the current system. As a result of file corruption or a system crash, it might be necessary to recover all files. Similarly, a change to an existing system (one that is in operation) might be needed, making it essential to obtain all source files and documents that represent the current system.

These are some of the more frequently occurring scenarios in a project that require support from the CM process. Furthermore, if multiple versions of a single software product coexist, each using a different version of the programs, other situations related to changes might come up that require the CM to have additional functionality (for example, handling variance⁴). Still, the main purpose of CM is to provide mechanisms that handle the type of scenarios in the preceding list. These mechanisms include the following:

Conventions for naming and organization of files

Version control

Change request traceability

Access control

Reconciliation procedures

Modification login programs

Naming program files (and document files) according to a standard convention and keeping the files in specific directories help in finding a desired file quickly. Proper naming (for example, by using standard extensions) also helps developers to readily understand the nature of file contents without looking at the files. In addition, segregating programs by their states into separate directories helps developers to identify the program state easily.

Version control is a key issue for CM,¹^,²^,⁴ and many tools are available to help manage this task. Version control helps preserve older versions of the programs whenever they are changed. Without such a mechanism, the system cannot support many of the required CM functions.

A change request traceability mechanism provides mapping from a requirement change request to subsequent changes in the programs, and that helps in managing requirement changes. To trace a change back to the change request, the modification log is useful.

Access control mechanisms ensure that only authorized people can modify certain files and that only one person can modify a file at any given time. Reconciliation procedures specify how two changes made independently to a program can be merged to create a new version that reflects both.

If these mechanisms are provided, the scenarios given earlier can be handled satisfactorily. Some of these scenarios necessitate the use of more than one mechanism. For example, undoing a requirement change involves a mechanism to show the traceability of a requirement change to subsequent changes in programs, as well as a version control mechanism to actually undo the changes.

Some CM mechanisms may be supported by a tool, whereas others may require that the users perform them explicitly. For example, version control may be carried out by a tool, but capturing the state of a program may require the programmer to explicitly maintain this information. The CM process defines all steps needed to implement such mechanisms and explains how these mechanisms are to be used in a project.

The discussion so far has focused on programs. The documents that are produced in a project (such as requirements documents, design documents, and plans) also need configuration management. During the normal course of a project, a document passes through three states: "under development," "under review," and "baselined." The state transition is straightforward and similar to the one proposed in Whitgift.⁴ The CM process must also implement the state diagram for documents.