Difference between revisions of "Configuration Management"
| Line 1: | Line 1: | ||
| − | The purpose of [[Configuration Management (glossary)|configuration management]] (CM) is to establish and maintain the integrity of all identified outputs of a [[Project (glossary)|project]] or [[Process (glossary)|process]] and make them available to concerned parties (ISO/IEC 2008). Since unmanaged changes to system artifacts (such as those associated with [[Plan (glossary)|plans]], [[Requirement (glossary)|requirements]], [[Design (glossary)|design]], [[Software (glossary)|software]], hardware, testing, and documentation) can lead to problems that persist throughout the system [[Life Cycle (glossary)| life cycle]] | + | The purpose of [[Configuration Management (glossary)|configuration management]] (CM) is to establish and maintain the integrity of all the identified outputs of a [[Project (glossary)|project]] or [[Process (glossary)|process]] and make them available to concerned parties (ISO/IEC 2008). Since unmanaged changes to system artifacts (such as those associated with [[Plan (glossary)|plans]], [[Requirement (glossary)|requirements]], [[Design (glossary)|design]], [[Software (glossary)|software]], hardware, testing, and documentation) can lead to problems that persist throughout the system [[Life Cycle (glossary)| life cycle]]. One primary objective of CM is to manage and control the change to such artifacts. |
==Configuration Management Process Overview== | ==Configuration Management Process Overview== | ||
CM is the discipline of identifying and formalizing the functional and physical characteristics of a [[Configuration (glossary)|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 (glossary)|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 systems 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. | CM is the discipline of identifying and formalizing the functional and physical characteristics of a [[Configuration (glossary)|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 (glossary)|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 systems 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 CM 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 2005). The standard discusses CM 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 | + | The ANSI/GEIA EIA-649-A standard presents CM 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 2005). The standard discusses CM 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 provides further information on this standard (ANSI/GEIA October 2005). |
| − | Effective CM depends on the establishment, maintenance, and implementation of an effective process. The CM process should include, but not | + | Effective CM depends on the establishment, maintenance, and implementation of an effective process. The CM process should include, but are not 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 (SEI 2010): | As a minimum the CM process should incorporate and detail the following tasks (SEI 2010): | ||
| − | * | + | * 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 |
Figure 1 below shows the primary functions of systems CM. | Figure 1 below shows the primary functions of systems CM. | ||
| Line 27: | Line 27: | ||
===Planning=== | ===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 | + | 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 including: configuration identification, change control, configuration status accounting, configuration auditing, and release management and delivery. |
===Configuration Identification=== | ===Configuration Identification=== | ||
| − | This activity is focused on identifying | + | This activity is focused on identifying the 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=== | ===Establishing Baseline=== | ||
| Line 44: | Line 44: | ||
===Constraints and Guidance=== | ===Constraints and Guidance=== | ||
| − | Constraints affecting and | + | Constraints affecting and guiding 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 (glossary)|acquirer]] or [[Supplier (glossary)|supplier]] may contain provisions affecting the CM process. The system life cycle process adopted and the tools, methods, and other processes used in system development can affect the CM process (Abran 2004). There are a variety of sources for guidance on the 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), as well as the ''Guide to The Software Engineering Body of Knowledge'' (SWEBOK) (Abran 2004), and the CMMI for Development (SEI 2010). |
===Organizational Issues=== | ===Organizational Issues=== | ||
| − | Successful CM planning, management, and implementation requires an understanding of the organizational context for | + | Successful CM planning, management, and implementation requires an understanding of the organizational context for on the design and implementation of the CM process and why constraints are placed upon it. 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 a number of 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=== | ===Measurement=== | ||
| − | In order to carry out certain CM functions, such as status accounting and auditing, | + | In order to carry out certain CM functions, such as status accounting and auditing, as well as 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. |
===Tools=== | ===Tools=== | ||
CM employs a variety of tools to support the process, for example: | CM employs a variety of tools to support the process, for example: | ||
| − | * | + | * 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. | The INCOSE Tools Database Working Group (INCOSE TDWG 2010) maintains an extensive list of tools including configuration management. | ||
| Line 78: | Line 78: | ||
| Shallow Visibility | | Shallow Visibility | ||
| | | | ||
| − | *Not involving all affected disciplines in the change control process. | + | * Not involving all affected disciplines in the change control process. |
|- | |- | ||
|Poor Tailoring | |Poor Tailoring | ||
| | | | ||
| − | *Inadequate CM tailoring to adapt to the project scale, number of subsystems, etc. | + | * Inadequate CM tailoring to adapt to the project scale, number of subsystems, etc. |
|- | |- | ||
|Limited CM Perspective | |Limited CM Perspective | ||
| | | | ||
| − | *Not considering and integrating the CM processes of all contributing organizations including COTS vendors and subcontractors. | + | * Not considering and integrating the CM processes of all contributing organizations including COTS vendors and subcontractors. |
|} | |} | ||
| Line 99: | Line 99: | ||
! Description | ! Description | ||
|- | |- | ||
| − | | Cross- | + | | Cross-Functional CM |
| | | | ||
| − | *Implement cross-functional communication and CM processes for software, hardware, firmware, data, or other types of items as appropriate. | + | * Implement cross-functional communication and CM processes for software, hardware, firmware, data, or other types of items as appropriate. |
|- | |- | ||
|Full Lifecycle Perspective | |Full Lifecycle Perspective | ||
| | | | ||
| − | *Plan for integrated CM through the life cycle. Do not assume that it will just happen as part of the program. | + | * Plan for integrated CM through the life cycle. Do not assume that it will just happen as part of the program. |
|- | |- | ||
|CM Planning | |CM Planning | ||
| | | | ||
| − | *Processes are documented in a single, comprehensive CM | + | * Processes are documented in a single, comprehensive CM plan early in the project. The plan should be a (systems) CM plan. |
| − | *Include tools selected and used. | + | * Include tools selected and used. |
|- | |- | ||
|Requirements Traceability | |Requirements Traceability | ||
| | | | ||
| − | *Initiate requirements traceability at the start of the CM activity. | + | * Initiate requirements traceability at the start of the CM activity. |
|- | |- | ||
|CCB Hierarchy | |CCB Hierarchy | ||
| | | | ||
| − | *Use a hierarchy of | + | *Use a hierarchy of configuration control boards commensurate with the program elements. |
|- | |- | ||
|Consistent Identification | |Consistent Identification | ||
| | | | ||
| − | *Software CI and | + | *Software CI and hardware CI use consistent identification schemes. |
|- | |- | ||
| Line 131: | Line 131: | ||
| | | | ||
| − | *Configuration status accounting should be as automated as possible. | + | * Configuration status accounting should be as automated as possible. |
|} | |} | ||
Revision as of 02:49, 9 September 2012
The purpose of configuration management (CM) is to establish and maintain the integrity of all the 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 life cycle. One primary objective of CM is to manage and control the change to such artifacts.
Configuration Management Process Overview
CM 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 systems 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 CM 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 2005). The standard discusses CM 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 Implementation Guide for Configuration Management, which supports and provides further information on this standard (ANSI/GEIA October 2005).
Effective CM depends on the establishment, maintenance, and implementation of an effective process. The CM process should include, but are not 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 (SEI 2010):
- 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
Figure 1 below shows the primary functions of systems 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 including: configuration identification, change control, configuration status accounting, configuration auditing, and release management and delivery.
Configuration Identification
This activity is focused on identifying the 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
Configuration items are typically assembled into a baseline which specifies how a system will be viewed for the purposes of management, control, and evaluation. This baseline is fixed at a specific point in time in the system life cycle and represents the current approved configuration. It generally can only be changed through formal change procedures.
Change Control
A disciplined change control process is critical for systems engineering. A generalized change control process in response to an engineering change proposal (ECP) is shown in Figure 2 below, which is adapted from Systems Engineering and Analysis (Blanchard and Fabrycky 1999).
Configuration Auditing
Audits are independent evaluations of the current status of configuration items and determine conformance of the configuration activities to the CM process. Adherence to applicable CM plans, regulations, and standards, is typically assessed during audits.
Constraints and Guidance
Constraints affecting and guiding 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. The system life cycle process adopted and the tools, methods, and other processes used in system development can affect the CM process (Abran 2004). There are a variety of sources for guidance on the 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), as well as the Guide to The Software Engineering Body of Knowledge (SWEBOK) (Abran 2004), and the CMMI for Development (SEI 2010).
Organizational Issues
Successful CM planning, management, and implementation requires an understanding of the organizational context for on the design and implementation of the CM process and why constraints are placed upon it. 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 a number of 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, as well as 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.
Tools
CM employs a variety of tools to support the process, for example:
- 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 life cycle in all areas of system definition, system realization, system deployment and use, and product and service life management. This includes CM application 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 CM are in Table 1.
| Name | Description |
|---|---|
| Shallow Visibility |
|
| Poor Tailoring |
|
| Limited CM Perspective |
|
Good Practices
Some good practices gathered from the references are provided in Table 2 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, sec. 5.4.1.5).
References
Works Cited
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. Implementation Guide for Configuration Management. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association, GEIA-HB-649.
Blanchard, B.S., and W J. Fabrycky. 2005. Systems Engineering and Analysis. 4th ed. Prentice-hall international series in industrial and systems engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
ISO. 2003. Quality Management Systems – Guidelines for Configuration Management. Geneva, Switzerland: International Organization for Standardization (ISO), ISO 10007:2003.
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).
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. 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. 2003. Quality Management Systems – Guidelines for Configuration Management. Geneva, Switzerland: International Organization for Standardization (ISO), ISO 10007:2003.
ISO/IEC. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC/IEEE 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. 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. 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 at: http://www.incose.org/practice/techactivities/wg/tools/.
INCOSE. 2008. "INCOSE measurement tools survey." in International Council on Systems Engineering (INCOSE) [database online]. San Diego, CA, USA, 2008 Available at: 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).
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus