1.1 Configuration Management Activities

The view on configuration management in this book is process oriented. Therefore, the definition includes activity areas, which can be described in terms of process descriptions. The activity areas described in detail in the following paragraphs are identification, storage, change control, and status reporting.

Configuration management has many interactions with other development and support processes. Figure 1-1 illustrates the production and usage activity areas via their respective libraries.

Metadata

All the activity areas in configuration management share metadata for items placed under configuration management. Metadata is a database concept that means data about the data stored in the database. So metadata in this context describes the configuration items. Metadata for a configuration item may include its name, the name of the person who produced the item, the production date, and references to other related configuration items. Figure 1-1 shows a logical separation of metadata, even though this data is often stored physically at the same location (in the same database) as the items in controlled storage.

Change control uses metadatafor example, the trace information for a configuration item for which a change is suggested. Change control does not in itself contribute to metadata, because information produced during change control will be present only if a configuration item is affected by a suggested change. A configuration item can exist without change control information, but it can't exist without metadata.

Configuration Management Is Cyclicor Is It?

In everyday language, "configuration item" is often used to refer to an item, which is then said to be produced in several versions. This is not strictly correct, but it's acceptable as long as the reference is clearly understood by all involved. In fact, each new version of a configuration item is a new configuration item in its own right.

This can be illustrated by an analogy to an object-oriented approach. The "configuration item" may be seen as a class and the versions as instantiations of the class, as shown in Figure 1-2. Version chains of configuration itemsthat is, versions 1, 2, 3, and so onmay be formed by indicating which configuration item a given configuration item is derived from or based on.

Figure 1-2. Configuration Item Class and Instantiations

Configuration management activities may be viewed as cyclic for each item class placed under configuration management. This means that a configuration item class continuously goes "through the mill." The first cycle is initiated by a (planned) need for a configuration item, and later the driving force is a change request (and only this!). This is illustrated in Figure 1-3.

Figure 1-3. The Life of a Configuration Item Class

In each cycle, a configuration item will be identified, produced, stored, and released for usage. Event registrations will occur as a consequence of experience gained during usage. These will lead to change control and the creation of change requests , which will lead to identification, and so on, of a new version of the original configuration item. Items placed under configuration management must never be changed, but new versions may be created.

Configuration items that are different versions of the same original item are obviously strongly related, but each one is an individual item, which will be identified and may be extracted and used independently. This is one of the main points of configuration management: to be able to revert to an earlier version of an item class.

Quality Assurance Process

Configuration management interacts with quality assurance, as illustrated by the item approval process that accompanies a configuration item from production to storage. The item approval, which may be a written quality record or verbal, is a product of quality assurance. Some see it as a product of configuration management, but it's actually the gateway from production to configuration management, provided by quality assurance.

Auditing

Auditing is included in some definitions of configuration management. An audit ensures that the productthe configuration item released for usefulfills the requirements and is complete as delivered. This includes configuration management information, so that everything required is delivered in the expected versions and that the history of each item can be thoroughly accounted for. This activity area is not considered part of configuration management in this book. It's viewed as an activity area under general quality assurance, which partly concerns the products and partly the processes, rather than a configuration management activity area.

This may be a controversial point of view, but the idea of audits is a legacy from the Department of Defense origin of configuration management. Today there is a much broader understanding in the software industry of the importance of quality assurance and, therefore, also of configuration management.

Auditing uses configuration information extensively in the form of status reports , but it also uses quality assurance techniques and methods , such as reviewing and test. In practice, people involved in configuration management also carry out the audit. Consequently, the audit will be referred to elsewhere in this book.