SG 1 Establish Baselines Baselines of identified work products are established. Specific practices to establish baselines are covered by this specific goal. The specific practices under the Track and Control Changes specific goal serve to maintain the baselines. The specific practices of the Establish Integrity specific goal document and audit the integrity of the baselines. SP 1.1-1 Identify Configuration Items Identify the configuration items, components, and related work products that will be placed under configuration management. Configuration identification is the selection, creation, and specification of the following: Products that are delivered to the customer Designated internal work products Acquired products Tools Other items that are used in creating and describing these work products Items under configuration management will include specifications and interface documents that define the requirements for the product. Other documents, such as test results, may also be included, depending on their criticality to defining the product. A "configuration item" is an entity designated for configuration management, which may consist of multiple related work products that form a baseline. This logical grouping provides ease of identification and controlled access. The selection of work products for configuration management should be based on criteria established during planning. For Systems Engineering In a system that includes both hardware and software, where software represents a small part of the system, all of the software may be designated as a single configuration item. In other cases, the software may be decomposed into multiple configuration items. |
Configuration items can be decomposed into configuration components and configuration units. Only the term "configuration item" is used in this process area. In these practices, "configuration item" may be interpreted as "configuration component" or "configuration unit" as appropriate. For example, configuration items in the area of requirements management could vary from each individual requirement to a set of requirements. Typical Work Products Identified configuration items Subpractices Select the configuration items and the work products that compose them based on documented criteria. Example criteria for selecting configuration items at the appropriate work product level include the following: Work products that may be used by two or more groups Work products that are expected to change over time either because of errors or change of requirements Work products that are dependent on each other in that a change in one mandates a change in the others Work products that are critical for the project |
Examples of work products that may be part of a configuration item include the following: |
For Software Engineering Examples of software work products that may be part of a configuration item include the following: Code/module Tools (e.g., compilers) |
Assign unique identifiers to configuration items. Specify the important characteristics of each configuration item. Example characteristics of configuration items include author, document or file type, and programming language for software code files. |
Specify when each configuration item is placed under configuration management. Example criteria for determining when to place work products under configuration management include the following: Stage of the project life cycle When the work product is ready for test Degree of control desired on the work product Cost and schedule limitations Customer requirements |
Identify the owner responsible for each configuration item. SP 1.2-1 Establish a Configuration Management System Establish and maintain a configuration management and change management system for controlling work products. A configuration management system includes the storage media, the procedures, and the tools for accessing the configuration system. A change management system includes the storage media, the procedures, and tools for recording and accessing change requests. Typical Work Products Configuration management system with controlled work products Configuration management system access control procedures Change request database Subpractices Establish a mechanism to manage multiple control levels of configuration management. Examples of situations leading to multiple levels of control include the following: Differences in the levels of control needed at different times in the project life cycle (e.g., tighter control as product matures) Differences in the levels of control needed for different types of systems (e.g., software-only systems versus systems that include hardware and software) Differences in the levels of control needed to satisfy privacy and security requirements for the configuration items |
Store and retrieve configuration items in configuration management system. Examples of configuration management systems include the following: Dynamic (or developer's) systems contain components currently being created or revised. They are in the developer's workspace and are controlled by the developer. Configuration items in a dynamic system are under version control. Master (or controlled) systems contain current baselines and changes to them. Configuration items in a master system are under full configuration management as described in this process area. Static systems contain archives of various baselines released for use. Static systems are under full configuration management as described in this process area. |
Share and transfer configuration items between control levels within the configuration management system. Store and recover archived versions of configuration items. Store, update, and retrieve configuration management records. Create configuration management reports from the configuration management system. Preserve the contents of the configuration management system. Examples of preservation functions of the configuration management system include the following: Backups and restoration of configuration management files Archiving of configuration management files Recovery from configuration management errors |
Revise the configuration management structure as necessary. SP 1.3-1 Create or Release Baselines Create or release baselines for internal use and for delivery to the customer. A baseline is a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development, and that can be changed only through change control procedures. A baseline represents the assignment of an identifier to a configuration item and its associated entities. For Systems Engineering Release of a baseline involves approving a set of configuration data for the agreed-on set of configuration items from the configuration management system and releasing the baseline for further development. Multiple baselines may be used to define an evolving product during its development cycle. One common set includes the system-level requirements, system-element-level design requirements, and the product definition at the end of development/beginning of production. These are referred to as the "functional baseline," "allocated baseline," and "product baseline." |
For Software Engineering A set of requirements, design, source code files and the associated executable code, build files, and user documentation (associated entities) that have been assigned a unique identifier can be considered to be a baseline. Release of a baseline constitutes retrieval of source code files (configuration items) from the configuration management system and generating the executable files. A baseline that is delivered to a customer is typically called a "release" whereas a baseline for an internal use is typically called a "build." |
Typical Work Products Baselines Description of baselines Subpractices Obtain authorization from the configuration control board (CCB) before creating or releasing baselines of configuration items. Create or release baselines only from configuration items in the configuration management system. For Systems Engineering Ensure that the configuration items are built to the correct drawing. |
Document the set of configuration items that are contained in a baseline. Make the current set of baselines readily available. SG 2 Track and Control Changes Changes to the work products under configuration management are tracked and controlled. The specific practices under this specific goal serve to maintain the baselines after they are established by the specific practices under the Establish Baselines specific goal. SP 2.1-1 Track Change Requests Track change requests for the configuration items. Change requests address not only new or changed requirements, but also failures and defects in the work products. Change requests are analyzed to determine the impact that the change will have on the work product, related work products, and schedule and cost. Typical Work Products Change requests Subpractices Initiate and record change requests in the change request database. Analyze the impact of changes and fixes proposed in the change requests. Changes are evaluated through activities that ensure that they are consistent with all technical and project requirements. Changes are evaluated for their impact beyond immediate project or contract requirements. Changes to an item used in multiple products can resolve an immediate issue while causing a problem in other applications. Review change requests that will be addressed in the next baseline with those who will be affected by the changes and get their agreement. Conduct the change request review with appropriate participants. Record the disposition of each change request and the rationale for the decision, including success criteria, a brief action plan if appropriate, and needs met or unmet by the change. Perform the actions required in the disposition, and report the results to relevant stakeholders. Track the status of change requests to closure. Change requests brought into the system need to be handled in an efficient and timely manner. Once a change request has been processed, it is critical to close the request with the appropriate approved action as soon as it is practical. Actions left open result in larger than necessary status lists, which in turn result in added costs and confusion. SP 2.2-1 Control Configuration Items Control changes to the configuration items. Control is maintained over the configuration of the work product baseline. This control includes tracking the configuration of each of the configuration items, approving a new configuration if necessary, and updating the baseline. Typical Work Products Revision history of configuration items Archives of the baselines Subpractices Control changes to configuration items throughout the life of the product. Obtain appropriate authorization before changed configuration items are entered into the configuration management system. For example, authorization may come from the CCB, the project manager, or the customer. |
Check in and check out configuration items from the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of the configuration items. Examples of check-in and check-out steps include the following: Confirming that the revisions are authorized Updating the configuration items Archiving the replaced baseline and retrieving the new baseline |
Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that the changes have not compromised the safety and/or security of the system). Record changes to configuration items and the reasons for the changes as appropriate. If a proposed change to the work product is accepted, a schedule is identi-fied for incorporating the change into the work product and other affected areas. Configuration control mechanisms can be tailored to categories of changes. For example, the approval considerations could be less stringent for component changes that do not affect other components. Changed configuration items are released after review and approval of configuration changes. Changes are not official until they are released. SG 3 Establish Integrity Integrity of baselines is established and maintained. The integrity of the baselines, established by processes associated with the Establish Baselines specific goal, and maintained by processes associated with the Track and Control Changes specific goal, is provided by the specific practices under this specific goal. SP 3.1-1 Establish Configuration Management Records Establish and maintain records describing configuration items. Typical Work Products Revision history of configuration items Change log Copy of the change requests Status of configuration items Differences between baselines Subpractices Record configuration management actions in sufficient detail so the content and status of each configuration item is known and previous versions can be recovered. Ensure that relevant stakeholders have access to and knowledge of the configuration status of the configuration items. Examples of activities for communicating configuration status include the following: |
Specify the latest version of the baselines. Identify the version of configuration items that constitute a particular baseline. Describe the differences between successive baselines. Revise the status and history (i.e., changes and other actions) of each configuration item as necessary. SP 3.2-1 Perform Configuration Audits Perform configuration audits to maintain integrity of the configuration baselines. Audit configuration management activities and processes to confirm that the resulting baselines and documentation are accurate, and record the audit results as appropriate. Typical Work Products Configuration audit results Action items Subpractices Assess the integrity of the baselines. Confirm that the configuration records correctly identify the configuration of the configuration items. Review the structure and integrity of the items in the configuration management system. Confirm the completeness and correctness of the items in the configuration management system. Completeness and correctness of the content is based on the requirements as stated in the plan and the disposition of approved change requests. Confirm compliance with applicable configuration management standards and procedures. Track action items from the audit to closure. |
