Configuration Management


Definition: A technical and management process for establishing and maintaining consistency of a product’s functional and physical attributes with its requirements, design, and operational information throughout its life [1].

Keywords: acquisition development program, program control configuration management policy, program management

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) should have a sound understanding of the principles of configuration management, how the development organization initiates configuration control, how the developer implements configuration management, and how the government sponsor or sustainment organization continues the configuration management following product delivery. Because many of our programs place a significant amount of their configuration management effort on software configuration management and commercial hardware and software, that will be the focus of this discussion; however, the configuration management of developmental hardware deserves a similar discussion. Usually MITRE's role in the practice of configuration management (CM) is to ensure that good CM processes are in place, documented as part of a program Systems Engineering Plan and/or Lifecycle Management Plan, and followed by all contractors and program office personnel. The implementation of the process is not likely to be a MITRE role unless there are special circumstances (e.g., analysis of a CM breakdown). Issues such as the use of appropriate CM tools for a development environment, the application of automated system configuration monitoring, and the frequent conundrum of managing moving baselines are likely to be the focus of MITRE's expertise for CM.

Context

Why do we perform configuration management? One reason is that it is required on Department of Defense (DoD) [2], Federal Aviation Administration (FAA) [3], Internal Revenue Service (IRS) [4], and other formal organizationally run programs. Another reason is that once a program has been developed and deployed as a system, we must understand the baseline for reasons of sustainability and affordability. Obviously, it is very hard to maintain or upgrade something that is undefined and not controlled. We need to minimize unintended negative consequences and cost of changes that are not fully analyzed. We would prefer to have "interchangeable parts" as well as standards and baselines that facilitate maintenance and interoperability. Finally, repeatable performance is needed for operations, test, security, and safety. Think of how well you could react to an Information Assurance Vulnerability Assessment if you didn't know what could be affected in your system baseline or where the items are located. Think of your ability to specify a replacement system if you didn't know what constitutes your system or configuration item baselines because those changes were not tracked after the system was initially deployed.

Best Practices and Lessons Learned

Consistent with the systems engineering life cycle, configuration management exists for the life of a program and system. As part of initial program planning, MITRE is involved in establishing systems engineering processes, one of which is configuration management.

A plan is essential. A configuration management plan is necessary for sound configuration management practice. The plan should include the following elements.

  • Configuration identification. Identify the things to be managed and level of control at each level.
    • Identify all configuration items to be controlled: user requirements documents, requirements specifications and traceability, design artifacts, development documents, software version documents, interface control documents, data, drawings and parts lists, test plans and procedures, test scripts, test results, and training materials. Depending on the type of program, you may also have architecture products, data flows and network diagrams, simulation data, test harness/modeling and simulations, etc.
    • Identify the level of detail of each to be controlled: system-of-systems, system, configuration item, component, item, part number, network asset, etc.
    • Identify all baselines to be managed: user requirements, system requirements, design, development, test, sustainment, experimentation, etc.
    • Develop a schema or comply with organizational policy to provide unique identifiers for each item.
    • Determine the level of the configuration management hierarchy (stakeholders) for each identified "configuration item" to be approved (baselined).
  • Configuration control.
    • Develop a closed-loop corrective action process to track all configuration item changes to closure and inclusion in appropriate baseline documentation.
    • Build or provide specifications to build work products from the software configuration management system or physical products from the hardware configuration management system.
    • Purchase or develop tools for version control of source code. This product should provide version control tracking to the line of code level. Ensure the implementation of an engineering release system to provide hardware version control.
  • Configuration status accounting. Publish periodic reports describing the current configuration of each configuration item. There should be a configuration version description document that details each version of software undergoing integration, system, or acceptance test as well as a set of engineering drawings that detail each developmental hardware item undergoing integration and testing. Commercial hardware and software also needs to be under configuration control during integration and testing. Configuration status accounting applies to all fielded hardware, software, and other controlled assets during operations and maintenance for the life of the system.
  • Configuration audits. Perform periodic examinations of operational baselines for completeness (configuration verification audit). Prior to delivering the product to the sponsor, make sure that a functional configuration audit has been successfully completed to ensure that the product meets its specified requirements. Also, conduct a physical configuration audit to ensure that the successfully tested product matches the documentation.
  • Accounting of requirements changes per month and changes in processing time. Also, the number of defects that are open and closed are metrics that may be used for configuration management.

Automate to manage complexity. If the program is sufficiently complex, identify and install an automated tool to support the configuration management tasks. Consider the other stakeholders (engineers/programmers, users, contractors, interfacing systems, and sustainment organizations) in the selection of any automated configuration management tools.

Work your plan. Implement and conduct the configuration management activities according to the program's configuration management plan.

Use checklists. A basic checklist, such as the one in Table 1, can help capture the necessary efforts.

Checklist Item

 

Have all items subject to configuration control been identified in the program plan?

 

Has a closed-loop change management system been established and implemented?

 

Has a government configuration control board been established for both development and sustainment?

 

Are impact reviews performed to ensure that the proposed changes have not compromised the performance, reliability, safety, or security of the system?

 

Does the developer's CM create or release all baselines for internal use?

 

Does the developer's CM create or release all baselines for delivery to the customer?

 

Are records established and maintained describing configuration items?

 

Are audits of CM activities performed to confirm that baselines and documents are accurate?

 

Do sponsor, program office, primary developer team, and sustainment organizations have CM systems and expertise? Are developers and managers trained equivalently on CM?

 

Are CM resources across development teams interoperable and compatible? Note that the use of SourceSafe, CVS, CAD/CAM, Requirements Management, and Subversion may represent logistical issues if left unmanaged.

 

MITRE's experience has shown that the CM process chosen for a particular program may be a rigorous, serial process to tightly control the system baseline (i.e., for an aircraft where flight safety is paramount) or a more flexible process that allows for urgent modifications and variable levels of approval. The challenge is to determine the process that best meets stakeholder needs as well as the acquisition/procurement/maintenance needs of the system program office. Depending on the level of complexity, the number of stakeholders, and the nature of the system (e.g., system of systems), see the Engineering Information-Intensive Enterprises topic in the SEG's Enterprise Engineering section.

Articles Under This Topic

Enterprise management, evolutionary acquisition, and agile development combined with sustainment introduce some unique challenges in configuration management because of the number of concurrent development and operational baselines that must be controlled and maintained for development, test, experimentation, and operations. Understanding the complexity of the system will enable you to apply the appropriate CM process and the relationship between layers of the CM hierarchy. For more information, see this topic's How to Control a Moving Baseline article.

The number and types of tools employed to assist in configuration management have grown and changed according to technology and development techniques. After you determine the list of items to be configuration controlled, assess the variety of tools appropriate to automate the management and control process (e.g., Dynamic Object-Oriented Requirements System tool for requirements management and traceability, Deficiency Reporting Databases, Software Configuration Management tools, and Network discovery tools). For more information, see this topic's Configuration Management Tools article.

References and Resources

  1. TechAmerica/ANSI/EIA-649-B, June 17, 2011, National Consensus Standard for Configuration Management, accessed September 13, 2017.
  2. DoD, January 7, 2015, Operation of the Defense Acquisition System, USD(AT&L), DoDI 5000.02, accessed September 13, 2017.
  3. FAA, March 2, 2012, FAA Order 1800.66, Configuration Management Policy, accessed September 13, 2017.
  4. Department of Treasury (IRS), July 1, 2007, Enterprise Life Cycle Guide, Process Management and Improvement Policy, accessed September 13, 2017.

Additional References and Resources

Association for Configuration and Data Management, accessed September 13, 2017.

CM Crossroads, Configuration Management Yellow Pages, accessed September 13, 2017.

IEEE Standards Association, March 16, 2012, "IEEE Std 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering," accessed September 13, 2017.

MIL-HDBK-61A, February 2001, Configuration Management Guidance, accessed September 13, 2017.

MITRE Institute, September 2007, "Configuration Management," Systems Engineering Competency Model, The MITRE Corporation, accessed September 13, 2017.

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team