Configuration Management
The purpose of configuration management (CM) is to establish and maintain the integrity of all identified outputs of a project or process and make them available to concerned parties. (ISO/IEC 2008) Since unmanaged changes to system artifacts (such as those associated with plans, requirements, design, software, hardware, testing, and documentation) can lead to problems that persist throughout the system lifecycle, a primary objective of CM is to manage and control the change to such artifacts.
Configuration management is the discipline of identifying and formalizing the functional and physical characteristics of a configuration item at discrete points in the product evolution for the purpose of maintaining the integrity of the product system and controlling changes to the baseline. The baseline for a project contains all of the technical requirements and related cost and schedule requirements that are sufficiently mature to be accepted and placed under change control by the project manager. The project baseline consists of two parts: the technical baseline and the business baseline. The system engineer is responsible for managing the technical baseline and ensuring that it is consistent with the costs and schedules in the business baseline. Typically, the project control office manages the business baseline.
The ANSI/GEIA EIA-649-A standard presents configuration management from the viewpoint that configuration management practices are employed because they make good business sense rather than because requirements are imposed by an external customer. (ANSI/GEIA October 2005) The standard discusses configuration management principles and practices from an enterprise view; it does not prescribe which CM activities individual organizations or teams within the enterprise should perform. Each enterprise assigns responsibilities in accordance with its own management policy. See also the GEIA-HB-649 Implementation Guide for Configuration Management, which supports and is related to this standard. (ANSI/GEIA October 2005)
Configuration Management Process Overview
Effective Configuration Management depends on the establishment, maintenance, and implementation of an effective CM process The CM process should include, but not be limited to, the following activities:
- Identification and involvement of relevant stakeholders
- Setting of CM goals and expected outcomes
- Identification and description of CM tasks
- Assignment of responsibility and authority for performing the CM process tasks
- Establishment of procedures for monitoring and control of the CM Process
- Measurement and assessment of the CM process effectiveness.
As a minimum the CM process should incorporate and detail the following tasks (CMMI Product Team, 2006) :
- Identifying the configuration of selected work products that compose the baselines at given points in time
- Controlling changes to configuration items
- Building or providing specifications to build work products from the configuration management system
- Maintaining the integrity of baselines
- Providing accurate status and current configuration data to developers, end users, and customers.
The figure below shows the primary functions of systems configuration management.
Configuration Management Functions
CM Planning
The CM plan must be developed in consideration of the organizational context and culture; it must adhere to or incorporate applicable policies, procedures, and standards; and it must accommodate acquisition and subcontractor situations. A CM plan details and schedules the tasks to be performed as part of the CM process: configuration identification, change control, configuration status accounting, configuration auditing, and release management and delivery.
Configuration Identification
This activity is focused on identifying those configuration items which will be managed and controlled under a CM process. The identification activity involves establishing a procedure for labeling items and their versions. The labeling provides a context for each item within the system configuration and shows the relationship between system items.
Establishing Baseline
As the confirmation items are identified they are assembled into a baseline which specifies how a system will be viewed for the purposes of management, control and evaluation. A baseline can only be changed through the formal change procedures. The baseline is fixed at specific point in time in the system life cycle and represents the current approved configuration.
Change Control
A disciplined change control process is critical for systems engineering. A generalized change control process is shown in the figure below, which is adapted from [Blanchard and Fabrycky, 1999).
Configuration Change Control Process
Configuration Auditing
Audits are independent evaluations of the current status of configuration items and to determine conformance of the configuration activities to the CM process. Adherence to applicable CM plans, regulations, and standards, will be assessed.
Constraints and Guidance
Constraints affecting, and guidance for the CM process come from a number of sources. Policies, procedures, and standards set forth at corporate or other organizational levels might influence or constrain the design and implementation of the CM process. Also, the contract with an acquirer or supplier may contain provisions affecting the CM process. Finally, the system life cycle process adopted and the tools, methods and other processes used in system development can affect the CM process. (Abran,A. 2004) There are a variety of sources for guidance on development of a CM process. These include the ISO standards on system life cycle processes (ISO/IEC 2008) and configuration management guidelines (ISO 10007, 2003); the guide to the software engineering body of knowledge (SWEBOK ) (Abran,A. 2004), and the CMMI for Development (CMMI Product Team, 2006) .
Organizational Issues
Successful CM planning, management and implementation requires an understanding of the organizational context for and the constraints placed on the design and implementation of the CM process. To plan a CM process for a project, it is necessary to understand the organizational context and the relationships among the organizational elements. CM interacts with other organizational elements, which may be structured in various ways. Although the responsibility for performing certain CM tasks might be assigned to other parts of the organization, the overall responsibility for CM often rests with a distinct organizational element or designated individual (Abran, 2004).
Measurement
In order to carry out certain CM functions, such as status accounting and auditing, and to monitor and assess the effectiveness of CM processes it is necessary to measure and collect data related to CM activities and system artifacts. CM libraries and automated report tools provide convenient access and facilitation of data collection. Examples of metrics include the size of documentation artifacts, number of change requests, mean time to change to a configuration item, and rework costs.
CM Tools
Configuration management employs a variety of tools to automate the process including:
- Library Management
- Tracking and Change Management
- Version Management
- Release Management
The INCOSE Tools Database Working Group (INCOSE TDWG, 2010) maintains an extensive list of tools including configuration management.
Linkages to Other Systems Engineering Management Topics
Configuration management is involved in the management and control of artifacts produced and modified throughout the system lifecycle in all of areas of system development, operations, and maintenance. This includes being applied to the artifacts of all the other management processes (plans, analyses, reports, statuses, etc.).
Practical Considerations
Key pitfalls and good practices related to systems engineering CM are described in the next two sections.
Pitfalls
Some of the key pitfalls encountered in planning and performing Configuration Management are in the following table.
| Name | Description |
|---|---|
| Shallow Visibility |
|
| Poor Tailoring |
|
| Limited CM Perspective |
|
Good Practices
Some good practices gathered from the references are below.
| Name | Description |
|---|---|
| Cross-functional CM |
|
| Full Lifecycle Perspective |
|
| CM Planning |
|
| Requirements Traceability |
|
| CCB Hierarchy |
|
| Consistent Identification |
|
| CM Automation |
|
Additional good practices can be found in (ISO/IEC/IEEE 2009, Clause 6.4) and (INCOSE, 2010, Section 5.4.1.5).
Additional References and Readings
Glossary
Acronyms
Acronym Definition
CM Configuration Management
References
Citations
List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Primary References
Abran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. SWEBOK: Guide to the software engineering body of knowledge: 2004 version. Los Alamitos, CA; Tokyo, Japan: IEEE Computer Society Press.
ANSI/GEIA. October 2005. GEIA-HB-649, implementation guide for configuration management. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association, GEIA-HB-649.
GEIA. 2004. GEIA consensus standard for data management. Arlington, VA, USA: Government Electronics & Information Technology Association, GEIA-859.
ISO/IEC. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).
SEI. 2010. Capability Maturity Model Integrated (CMMI) for Development, version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
Additional References
Blanchard, B. S., and W. J. Fabrycky. 2005. Systems Engineering and Analysis. Prentice-hall international series in industrial and systems engineering. 4th ed. Englewood Cliffs, NJ, USA: Prentice-Hall.
INCOSE Tools database working group (TDWG). in International Council on Systems Engineering (INCOSE) [database online]. San Diego, CA, USA, 2010 Available from http://www.incose.org/practice/techactivities/wg/tools/.
---. INCOSE measurement tools survey. in International Council on Systems Engineering (INCOSE) [database online]. San Diego, CA, USA, 2008 Available from http://www.incose.org/productspubs/products/SEtools/meassurv.html (accessed 15 August, 2010).
ISO/IEC/IEEE. 2009. Systems and software engineering - life cycle processes - project management. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).