What Is Configuration Management?
- Configuration Management Activities
- Identification
- Storage
- Change Control
- Status Reporting
- False Friends: Version Control and Baselines
This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuration, "to form from or after," derives from the Latin com-, meaning "with" or "together," and figurare, "to form." It also means "a relative arrangement of parts or elements." Configuration management therefore refers to managing a relative arrangement of parts or elements. It's as simple as that.
Configuration management, as we know it today, started in the late 1960s. In the 1970s, the American government developed a number of military standards, which included configuration management. Later, especially in the 1990s, many other standards and publications discussing configuration management have emerged.
In the last few years, the growing understanding of software development as a collection of interrelated processes has influenced work on configuration management. This means that configuration management is now also considered from a process point of view.
There are many definitions of configuration management and many opinions on what it really is. This chapter describes the definition on which this book is based. In short:
Configuration management is unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system.
Figure 1–1 shows the activity areas included in the definition of configuration management used in this book. It also shows their relations to each other, to common data, and to elements outside the configuration management process area.
)
Figure 1–1 Overview of Configuration Management Activities
When you work professionally with configuration management (as with anything else) it's important to have the fundamental concepts in place. If all else fails, you can go back and seek a solution there.
Definitions of configuration management used in various standards are covered in Chapter 3, and definitions of configuration management used in various maturity models can be found in Chapter 2. The definitions in these standards and maturity models are similar to a large extent. However, they're expressed in slightly different words and with different divisions between the detailed activities that constitute configuration management. It's perfectly okay for a company to use its own definition of configuration management, but it's a good idea to investigate how that definition maps to the definition used in this book and other relevant definitions, to make sure no activity has been left out.
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 metadata—for 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 Cyclic—or 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 items—that is, versions 1, 2, 3, and so on—may 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 product—the configuration item released for use—fulfills 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.