"Configuration management (CM) and the related elements that manage and control project information tie the parts of the engineering environment together. Unless this information is controlled, the engineering environment will degenerate, finally breaking down." --Michael W. Evans
 

Practice Description

Configuration Management (CM) is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life cycle of the program for information that is shared by more than one individual. A general guideline for CM is that all products that are input to a development of maintenance task should be under configuration change and version control. This means that the breadth of the items under CM control is much broader than just source code. The discipline of CM is vital to the success of any software effort.

Practice Essentials

• There should be written CM plans for delivered-product and developmental baselines and their change-control processes.
   
• CM plans should be subject to approval by the buyer.
   
• A CM manager should be specifically assigned.
   
• The developmental baseline should control task output products from project inception.
   
• Delivered-product baselines should include all versions that are operational.
   
• Each project accessing an external interface will participate in the interface control working group (ICWG) for that interface.
   
• The CM process together with automated tools used by CM will maintain version and semantic consistency between configuration items (CIs).
   
• CM should be responsible for building code units into integrated software for integration test.
   
• CM activities should be tightly coupled with the project plan and activity network.
   
• CM should be performed with tasks that have budgets, products, and unambiguous task exit criteria.
   
• CM tasks should be integrated with quality assurance (QA) tasks that verify that products input to CM baselines have met their acceptance criteria.
   
• CM should control versions of COTS, GOTS, and other Non-Developmental Items (NDIs) integrated into the system and used in the software development environment.
   
• CM should monitor and control the delivery and release-to-operation process.
   
  • Functional configuration audit to verify the product has achieved the requirements allocated to the product 
  • Physical configuration audit to verify that the to-be-delivered documentation is consistent with the source code 
  • Version descriptions 
  • To whom 
  • How 
  • Updates
     
• CM should control the approval of changes/additions to CM baselines in accordance with a structured process.
   
• CM should monitor and periodically report status of proposed changes, deviations, and waivers relative to items in CM baselines.
   
• CM should monitor and periodically report implementation status of approved changes, including fixes to problems found by inspections and tests.
   
• The developmental baseline CM for all suppliers/developers participating in system development should be integrated by the organization responsible for system integration. 

Implementation Guidelines

• The acquirer and the supplier/developer will develop CM plans to facilitate management control of information they own. The CM requirements and procedures of the acquirer serve as the basis for the CM plan that describes and documents how the supplier/developer will implement a single CM process. This plan will control formal baselines and will include engineering information, reports, analysis information, test information, user information, and any other information approved for use or shared within the program.
   
• The CM process will include supplier/developer-controlled developed baselines as well as acquirer-controlled baselines. It will also include release procedures for all classes of products under control, means for identification, change control procedures, status of products, and reviews and audits of information under CM control. The CM plan will be consistent with other plans and procedures used by the project.
   
• The two types of baselines managed by CM are developmental and formal. Developmental baselines include all software, artifacts, documentation, tools, and other products not yet approved for delivery to the acquirer but essential for successful production. Formal baselines are information/products (software, artifacts, or documentation) delivered and accepted by the acquirer. The supplier/developer owns developmental baselines while the acquirer owns formal baselines.
   
• All information placed under CM as a result of meeting task exit criteria will be uniquely identified by CM and placed under CM control. This includes software, artifacts, documents, COTS, GOTS, operating systems, middleware, database management systems, database information, and any other information necessary to build, release, verify, and/or validate the product.
   
• The CM process will be organizationally centered in a project library. This library will be the repository (current and historical) of all controlled products. The acquirer and the supplier/developer will implement an organizationally specific library. The library(s) will be partitioned according to the level of control of the information. Maintenance of the library structure and content will be provided.
   
• All information managed by CM will be subject to change control. Change control consists of:
   
  • Identification-Products are identified for CM control following established/documented criteria.  Once identified for CM, they are assigned unique identifiers, the characteristics of each CI are specified, the baseline to which the CI belongs is specified, as well as the point when the item will come under CM control and the person responsible for the item is identified. 
     
  • Reporting-Standard reports include SCCB minutes, change request summary, trouble report summary, baseline change summary, CI revision history, baseline status, audit results.  As tools improve, much of this information becomes more readily available online.  If processes can be adapted to make this information more readily available via on-line access, this capability should be exploited.  Other reports/information releases may be needed to accomplish CM's objective of keeping all shared information consistent.
     
  • Analysis
     
  • Implementation
     
• The change control process will be implemented through an appropriate change mechanism tied to who owns the information:
   : 
  • Change control boards, which manage formal baseline products 
  • Interface boards, which manage jointly owned information 
  • Engineering review boards, which manage supplier/developer-controlled information
     
• Any information released from the CM library will be described by a Version Description Document (VDD) (Software Version Description under MIL-STD-498 and EIA/IEEE J-STD-016). The version description will consist of any inventory of all components by version identifier, an identification of open problems, closed problems, differences between versions, notes and assumptions, and build instructions. Additionally each library partition will be described by a current version description that contains the same information.
   
• The written CM plan should include:
   
  • Identification of the configuration items in delivered-product and developmental baselines 
  • Details of the change-control process for each of the delivered-product and developmental baselines 
  • Identification of external interfaces and ICWGs 
  • Details of configuration status reporting 
  • Details of version control processes 
  • Details of the configuration audit processes 
  • Details of the use of automated tools by CM
     
• The developmental baseline will include: 
   
  • All task output that is input to other tasks 
  • Output files and databases of automated tools used for analysis, design, requirements traceability, and document production 
  • Test input data, test drivers, and successful test results 
  • Deficiency (problem, trouble) reports 
  • Automated tools used for development and COTS products, such as database management systems (DBMSs), that are part of the delivered software 
  • Operating systems and middleware
     
• CM should collect and report the CM churn metric as an indicator of potentially excessive rework.
   
• Input for the approval process for a change to a CM-controlled item should include identification of all other CIs that are impacted by the requested change and the nature of the impact.
   
• Each integration build released by CM will include a VDD that includes at a minimum:
   
  • The version numbers of each individual component in the build 
  • Defects that have been fixed 
  • Defects that have not been fixed 
  • Differences 

Things to Watch Out For

• Many projects do not have a developmental baseline under rigorous CM.
   
• Many projects that do have a developmental baseline only include in the baseline a small fraction of the configuration items that they should have.
   
• Projects in which several organizations are each developing part of the system often have no organization responsible for overall CM. This is particularly true when there is an integration supplier/developer but no prime, thereby making the DoD program office the de facto prime.
   
• Change-control boards often do not adequately assess the impacts of a proposed change or the risk and cost of making the proposed change prior to authorizing that change.
   
• CM is often found not to be adequate at the crucial, high-intensity time of frequent integration build and test.
   
• Many software-intensive systems with external interfaces do not participate in ICWGs for any of these external interfaces.
   
• Few if any projects using an automated CM tool have adequately solved the problem of keeping the data controlled with this tool consistent with the corresponding data in output files of automated CASE tools used for analysis, design, and document generation.
   
• Defect tracking is usually not done by CM or in any other formal, centralized manner.
   
• When a design problem is found during coding, CM often cannot produce the output file for the automated design tool that defines the design that needs to be changed.
   
• It sometimes happens that, when there is heavy schedule pressure during integration testing, changes are made to code without going through a controlled change process managed by CM.
   
• Often there is no centralized CM of versions of software systems that are operational in the field.
   
• When a problem is found at an operational site, the development supplier/developer's CM is often not able to reproduce the field configuration that failed, with the result that the fault cannot be reproduced in the lab. 

Figuring Out Where You Are - Project QuickLook

Chapter 6 contains a series of detailed questions that can be applied to any program to determine the health of its configuration management approach. These questions should be applied on a regular basis. However, there are some quick indicators that can be used to see if the configuration management process requires more in-depth examination. Specific "quicklook" questions are:

• Describe the role of CM in the following scenario, including identification of the CM-controlled items that are involved in the scenario: During integration test, a defect is found that requires a modification to the system architecture. This modification in turn results in a ripple effect of changes to some software design, documentation, code, and test cases.
   
• Identify automated tools (by name, vendor, and version), if any, used by CM, and describe how the data managed by these CM tools is kept consistent with output files or databases from other automated tools that produce data that is put in some CM baseline. 

An inappropriate answer to any of these questions could indicate a more serious problem and merits further investigation.

Additional Considerations
 

Tools are an important component in the development and control processes of software development. Great care should be exercised in the selection, use, maintenance, and configuration control of automated tools. Automated tools have the potential to solve project problem more efficiently than manual techniques.
 

• There are three types of automated tools: 
   
  • Narrow spectrum – single task (structured design tool), 
  • Broad spectrum – across tasks (traceability tool), 
  • Integrating technology – integrates tools (information management tools).
     
• Tools support project requirements (not vice versa).
   
• Specific needs based on the project environment and the architecture of the system must be defined first. 
   
• There are three parts to management of information support between tools: 
   
  • Procedural administrative envelope; 
  • Data and file organization must be defined (smooth transition of data, hierarchical, tracking development steps, horizontal and vertical levels of control); and 
  • Develop tools to support actual project needs, not esoteric perceived requirements.
     
• Define and select automated tools in a top-down sequence:
   
  • Define problem, 
  • Describe requirements/characteristics, 
  • Describe tooling needs, 
  • Select tools. 

The CM process will include supplier/developer-controlled developed baselines as well as acquirer-controlled baselines. It will also include release procedures for all classes of products under control, means for identification, change control procedures, status of products, and reviews and audits of information under CM control. The CM plan will be consistent with other plans and procedures used by the project.

There are two different transitions that must be managed by CM: Engineering Transition — transitions or release of informal, non-base lined information between activities or organizations; and Baseline Transition — transitions of formal documentation or products characterized by a formal approval or acceptance and product transfer.
 

CM identification segregates information to ensure that the proper level of approval is applied to each piece of information (in-process information not yet shared or approved, configuration management information, controlled program information, test information, pre-released information internally approved for release, customer-approved or base lined information).
 

• CM version control of operational software and records of version installed at each operational site is key to reproducing problems found in the field. 
   
• Identify the exact content, status, and version of all information accepted by CM and when it was last accepted and updated.
   
• Identify an accessible and current record of the status of each controlled piece of information showing the content of each release made from CM, and who has checked out or is working on a piece of information that I plan on accessing through CM.
   
• Identify a means to ensure that, before a change is made to a piece of information that I own or that impacts work that I am doing, I have the option of either providing or approving the change or, at a minimum, providing input into the change approval process.
   
• Identify how the information was approved for CM control and what the latest approved release is. 
   
• Identify what information has been approved for concurrent use in the project and who owns the information: 
   
  • Owned by the customer: Customer-controlled baselines hold all customer- approved base-lined information (functional, allocated, product, records and reports, and other approved or delivered information) and cannot be updated unless the customer authorizes the change. 
     
  • Owned by release manager or individual responsible for review, release, or customer interface: Prerelease information is review or other information or configurations internally approved for release but not yet accepted by the customer (e.g., beta releases), all versions of evolving and released documentation that has not been approved by the customer (all program reports, action items, and discrepancy reports). 
     
  • Owned by test manager: Test information is all test documentation and versions of software released for test, which includes: test scenarios, data, and results, test configurations, test cases, software configurations under test and configuration documentation, patches and unqualified source modifications, special test data, records, and audit trails.
     
  • Owned by project manager: Controlled project information is all information that has been accepted for release inside the program but has not yet been accepted by the customer or owner of the information at a higher-level life cycle for inclusion in a baseline; approved for internal release by passing a quality gate; requires that the program establish a process for CM of evolving information that is shared within the project by different organizations; and cannot be updated unless the change is authorized by an established project board.
     
  • Owned by CM:
    • The working area for CM includes: workspace for staging documentation and software releases; tools and files used by the project or needed to build or control project information and/or deliverables; project plans, procedures, and reports; schedules, budgets, and CM records; and audit trails, records, and lessons-learned information essential for certification, approval, or acceptance.
    • The CM environment provides control over all data products that have been approved through a predetermined "quality gate" and are used by more than one organizational element in the project or in the production of more than one data product.
      
      
  • Owned by the engineer doing the work: In-process information is all information that is under development or being changed that has not been approved for program use or release; may be changed by the individual responsible for the product without approval; and is content-controlled by the individual responsible for the information.

top

---