Configuration management is concerned with the management of all artifacts produced in the course of a software development project. Though configuration management also plays a role during the operational phase of a system, when different combinations of components can be assembled into one system and new releases of a system are generated, the discussion below centers around the role of configuration management during system development.

We will for the moment assume that, at any point in time, there is one official version of the complete set of documents related to the project. This is called the baseline. A baseline is 'a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures' (IEEE610, 1990). Thus, the baseline is the shared project database, containing all approved items. The baseline may or may not be stored in a real database and supported by tools to assist in retrieving and updating its elements. The items contained in the baseline are the configuration items. A configuration item is 'an aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process' (IEEE610, 1990). Possible configuration items are:

At some point in time, the baseline will contain a requirements specification. As time goes on, elements will be added: design documents, source code components, test reports, etc. A major task of configuration management is to maintain the integrity of this set of artifacts.

This is especially important if changes are to be incorporated. Suppose that, during testing, a major flaw in some component is discovered. We then have to retrace our steps and correct not only that component but also the corresponding design documents, and possibly even the requirements specification. This may affect work being done by other people still using the old version. Worse still, someone else may wish to make changes to the same component at the same time. Configuration management takes care of controlling the release and change of these items throughout the software life cycle.

The way to go about this is to have one shared library or database that contains all approved items, the 'baseline'. Adding an item to this database, or changing an item, is subject to a formal approval scheme. For larger projects, this is the responsibility of a separate body, the configuration (or change) control board (CCB). The CCB ensures that any change to the baseline is properly authorized and executed. The CCB is staffed with people from the various parties involved in the project, such as development, testing, and quality assurance.

Any proposed change to the baseline is called a change request. A change request may concern an error found in some component, a discrepancy found between a design document and its implementation, an enhancement caused by changed user requirements, etc. A change request is handled as follows (see also Figure 4.1):

Thus, configuration management is not only about keeping track of all the different versions of elements of a system; it also encompasses workflow management tasks. The process depicted in the state transition diagram in Figure 4.1, for example, describes what goes on in the life cycle of a change request. The process model thus defined exemplifies how the workflow of change requests can be managed.

In a similar vein, the state transition diagram in Figure 4.2 shows the workflow of developer tasks during the development of a system component. It shows the possible states of a system component and the transitions between them. For example, after a component has been coded, it is unit tested. If bugs are found during unit testing, further coding is necessary. Otherwise, the component enters the review stage. If the review reveals problems, the coding stage is re-entered. Otherwise, the component is submitted to the CCB for formal approval. Finally, if unit testing does not reveal any errors, the review stage is skipped.

Figure 4.2. State transition diagram of development activities

If components are kept under configuration control, configuration management can be used to manage the workflow of development tasks as well. Changes in the status of a component then trigger subsequent activities, as indicated in the development workflow model.

We have to take care that the workflow schemes do not unnecessarily curtail the day-to-day working of the people involved in the project. New items should not be added to the baseline until they have been thoroughly reviewed and tested. Items from the shared database may be used freely by the participants. If an item has to be changed, the person responsible for implementing the change gets a copy of that item and the item is temporarily locked, so that others cannot simultaneously update the item. The person implementing the change is free to tinker with the copy. After the change has been thoroughly tested, it is submitted back to the CCB. Once the CCB has approved it, the revised item is included in the database, the change itself is documented with the item, and the item is unlocked again. A sequence of documented changes thus provides a revision history of that item.

When an item is changed, the old version is kept as well. The old version still has to be used by others until they have adapted to the change. Also, we may wish to go back to the old version if another change is requested. We thus have different versions of one and the same item, and must be able to distinguish them. This can be done through some numbering scheme, where each new version is identified by the next higher number. We then get, for a component X, versions X.0, X.1, X.2, and so on.

In a more sophisticated environment, we may even create different branches of revisions. Figure 4.3 gives an example of such a forked development. In the example, component X.2.1 may be the result of fixing a bug in component X.2. Component X.3 may concern an enhancement to X.2. It should be noted that merging those parallel development paths again can be difficult. Also, the numbering schemes soon tend to become incomprehensible.

Figure 4.3. Parallel development paths

Configuration management is generally supported by powerful tools. Dart (1990) classifies the functionalities of software configuration management (SCM) tools as follows:

Many SCM tools employ the version-oriented model of configurations. A physical change in a component then results in a new version, and different versions are thus characterized by their difference. Some tools use logical changes, rather than physical ones, as a basic unit of work in configuration management. This change-oriented model gives a more intuitive way of working and may prevent a lot of user errors when configuring a system. Rather than identifying a configuration by some arcane sequence of numbers, it is now identified by some baseline plus a set of changes. The set of changes may be empty. We thus specify

baseline X plus 'fix table size problem'

rather than

{X.3.1, Y.2.7, Z.1.4, ...}.

As noted, SCM tools also offer help in constructing ('building') an executable version of the system. One writes a 'program' that identifies the various components of the required system and their mutual dependencies. The system in question is then generated by executing this 'program': the components are retrieved automatically from the database containing the source code components, and all components are translated and linked together into an executable system. If the system is smart enough, only components that have changed are translated anew.

Early SCM tools emphasized the product-oriented tasks of configuration management. They provided functionality to lock and unlock elements, to automatically number revisions, and, by default, to provide users with the latest version of an item. If an item was changed, they prompted the user to document the change. Present-day SCM tools increasingly provide the other functionalities as well, and have become a key ingredient of managing modern, distributed and global, software development. Tools for configuration and version management are discussed more extensively in Chapter 15.

On one hand, configuration management entails procedures on how to handle changes to and versions of documents. On the other hand, it consists of tool support to maintain the version history and ensure an up-to-date version of the system. In planning-driven development, both aspects are important. In agile projects, the emphasis is on tool support. Agile projects favor continuous integration, where the individual work of one developer is rapidly integrated with other parts of the system and then tests are run to make sure everything still works as expected. Such a development cycle can take a few hours or, at most, one day. At the end of the day, one again has a running system that passes all tests. This process is known as the daily build.

The procedures for configuration management are laid down in a document, the con-figuration management plan. For the contents of this plan, we follow the appropriate standard, IEEE828 (1998). This document describes methods to identify configuration items, to control change requests, and to document the implementation of those change requests. A sample table of contents for a configuration management plan is given in Table 4.1.

The SCM Management section describes how the project is being organized. Particular attention is paid to responsibilities that directly affect configuration management: how are change requests handled, how are development phases closed, how is the status of the system maintained, how are interfaces between components identified? The relationship with other functional organizations, such as software development and quality assurance, is also delineated.

The SCM Activities section describes how a configuration will be identified and controlled and how its status will be accounted and reported. A configuration is identified by a baseline: a description of the constituents of that configuration. Such a configuration must be formally approved by the parties involved.

Clear and precise procedures are needed with respect to the processing of change requests if a software development project is to be controlled. A configuration control board (CCB) usually has the responsibility for evaluating and approving or rejecting proposed changes. The authority, responsibility, and membership of the CCB have to be stated. Since software components are usually incorporated in a library, procedures for controlling this library have to be established as well.

In order to be able to control a software development project, data has to be collected and processed. Information that is normally required includes: the present status of components, versions and change requests, as well as reports of approved changes and their implementation.

Changes to configuration items may affect items outside the scope of the plan, such as hardware items. These external items have to be identified and their interfaces controlled. In a similar vein, interfaces to items developed outside the project have to be identified and controlled.

Configuration management is concerned with the management of all artifacts produced in the course of a software development project. It entails the following major activities:

For larger projects, a configuration control board (CCB) is usually established. The CCB is responsible for evaluating all change requests and maintaining the integrity of the complete set of documents that relate to a project. Its tasks and the further procedures for configuration management are laid down in a separate document, the configuration management plan.

The history and development of configuration management is closely tied to the history and development of configuration-management tools. In the early days, these tools emphasized the logging of physical file changes. There was little support for process aspects. Present-day configuration-management systems also address process aspects (workflow management) and many have adopted a change-oriented view of configurations as well as or instead of a version-oriented view. More and more, configuration-management tools function as document-management tools in that they support cooperation among a group of people, possibly distributed over multiple sites, working together on a collection of shared objects.

A readable introduction to the topic of configuration management is given in (Babich, 1986). A more recent source is (Jonassen Hass, 2002). (Estublier et al., 2005) gives an excellent overview of the major developments in the field. Weber (1996) and Wiborg-Weber (1997) describe the change-oriented configuration management technology.

Further references for technical aspects of configuration management are given in Chapter 15.