Definition: Configuration Management (CM) is the application of sound program practices to establish and maintain consistency of a product's or system's attributes with its requirements and evolving technical baseline over its life. It involves interaction among government and contractor program functions such as systems engineering, hardware/software engineering, specialty engineering, logistics, contracting, and production in an integrated product team environment. The program manager should use configuration management to establish and mature the technical baseline throughout the acquisition life cycle. A configuration management process guides the system products, processes, and related documentation, and facilitates the development of open systems. Configuration management efforts result in a complete audit trail of plans, decisions, and design modifications .
Keywords: acquisition development program, program control configuration management policy, program management
Why do we perform configuration management? One reason is that it is required on Department of Defense (DoD) , Federal Aviation Administration (FAA) , Internal Revenue Service (IRS) , and other formal organizationally run programs; behind those requirements are the reasons and lessons learned. Once a program has been developed and deployed as a system, it is necessary to 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," and standards and baselines that allow for ease of maintenance and interoperability. Finally, there is the need for repeatable performance for operations, test, security, and safety. Think of the ability to react to an Information Assurance Vulnerability Assessment when you do not know what could be affected in your system baseline or where the items are located. Think of your ability to specify a replacement system when you do not know what constitutes your system or configuration item baselines because those changes were not tracked after the initial system deployment.
MITRE SE Roles & 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 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, 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.
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 the establishment of systems engineering processes, one of which is configuration management.
- A plan is essential: A configuration management plan is necessary for sound configuration management practice. Include the following in the plan:
- 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, drawings and parts lists, test plans and procedures, test scripts, test results, 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. Assure 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 detailing each version of software undergoing integration, system, or acceptance test. There should be a set of engineering drawings detailing 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 product delivery to the sponsor, ensure successful completion of a functional configuration audit to assure that the product meets its specified requirements. Also conduct a physical configuration audit to assure that the successfully tested product matches the documentation.
- Accounting of requirements changes per month and changes processing time; also, the number of defects that are open and closed are metrics that may be used for configuration management.
- Configuration Identification: Identify the things to be managed and level of control at each level.
- 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 below, can assist in capturing the necessary efforts.
- 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 comprised 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 team interoperable and compatible (i.e., 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), it is recommended that you refer to the topic of Engineering Information-Intensive Enterprises under the Enterprise Engineering section of this guide. Enterprise management, evolutionary acquisition, and spiral 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. Refer to the How to Control a Moving Baseline article in this topic.
The number and types of tools employed to assist in configuration management have grown and changed according to technology and development techniques. Once the list of items to be configuration controlled has been determined, assess the variety of tools appropriate to automate the management and control process (i.e., Dynamic Object-Oriented Requirements System tool for requirements management and traceability, Deficiency Reporting Databases, Software Configuration Management tools, Network discovery tools, etc.). Additional guidance is provided in the Configuration Management Tools article in this topic.
References & Resources
- Acquisition Community Connection, Defense Acquisition Guidebook, 22.214.171.124.6, accessed January 25, 2010.
- DoD, December 2008, DoDI 5000.02.
- FAA, August 7, 2008, FAA Order 1800.66, Configuration Management Policy..
- Department of Treasury (IRS), July 1, 2007, Enterprise Life Cycle Guide, Process Management and Improvement Policy.
Additional References & Resources
TechAmerica/ANSI EIA-649-B, June 17, 2011, National Consensus Standard for Configuration Management.
Association for Configuration and Data Management, accessed January 25, 2010.
CM Crossroads, "Configuration Management Yellow Pages," accessed January 25, 2010.
IEEE Standards Association, "IEEE Std 828-2005 IEEE Standard for Software Configuration Management Plans," accessed January 25, 2010.
MIL-HDBK-61A, February 2001, Configuration Management Guidance, accessed January 25, 2010.
MITRE Center for Connected Government, CM Toolbox
MITRE Institute, "Configuration Management," Systems Engineering Competency Model
MITRE Systems Engineering Practice Office, Configuration Management Toolkit
Software Technology Support Center, "Configuration Management," accessed February 2, 2010.
Ventimiglia, B., February 1998, "Effective Software Configuration Management," CrossTalk.