Configuration Management(CM) is the discipline that ensures that the state of the software at any given time is known and reconstructable. CM comprises three basic elements: configuration identification (CID), configuration control (CC), and configuration accounting (CA). While each element may be invoked without the others, CM is incomplete in the absence of any of them.
CID provides a method for specifically and uniquely identifying each instance (e.g., release, version) of a given software product or set of products. By using a standard naming convention that allows for the identification of every instance of the product, each new draft of a document, each new compilation of a unit, or each new build can be specifically identified.
CC is the element that ensures that each change to an instance of the product is known, authorized, and documented. CC includes the activities of the change control board (CCB), which reviews and authorizes changes to the documents and code as increasingly formal control is placed on the developing software system. The software library may also be included as a function of CC.
CA serves to keep track of the status of each instance of the product. This becomes increasingly important as units and modules are integrated into subsystems and systems. It is obvious that the specific parts of a given system must be known so the system itself can be known. CA also assigns and tracks the status of each baseline of the requirements, test, design, code, and so on, as the software effort proceeds. Another growing requirement for CA is the case of a basic product that is adapted for use in multiple installations, each with slight variations in the total requirements set.
A Configuration Item (CI ) is any product of the software development process that is to be configuration managed. Each CI must have a unique identifier to differentiate it from all other software development products and other instances of the item itself.
Ultimate access to the Software Life Cycle(SLC) products, so that changes can be made, is through the software library, which is the repository of the official, approved issues of all documents and code. Changes to the products of the software development process come from two main sources: defect correction and enhancements. Without an effective change processing mechanism, the software can easily become unidentifiable and unmanageable.
Coordination of changes and their intercomponent effects is the task of the CCB. The CCB is responsible for determining that all effects of the proposed change have been anticipated and reconciled. Especially important is the control that the CCB exercises over the creation of new instances or versions of the various software system products. Once CM has been imposed on the project, it is the CCB that has the authority to approve changes and permit the updating of the various issues of the products. It is the responsibility of the software quality practitioner to monitor the functioning of the CCBs