Configuration Management: Difference between revisions

From SEBoK Draft
Jump to navigation Jump to search
m (Text replacement - "'''SEBoK v. 2.10, released 06 May 2024'''" to "'''SEBoK v. 2.11, released 25 November 2024'''")
m (Text replacement - "SEBoK v. 2.12, released 20 May 2025" to "SEBoK v. 2.12, released 27 May 2025")
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
----
----
'''''Lead Authors:''''' ''Ray Madachy, John Snoderly, Garry Roedler'', '''''Contributing Author:''''' ''Rick Adcock''
'''''Lead Authors:''''' ''John Metcalf, Philip Hallenbeck, Sandrine Gonthier'' '''''Contributing Author:''''' ''Garry Roedler''
----
----
The purpose of {{Term|Configuration Management (glossary)|configuration management}} (CM) is to establish and maintain the integrity of all of the identified outputs of a {{Term|Project (glossary)|project}} or {{Term|Process (glossary)|process}} and make them available to concerned parties (ISO/IEC/IEEE 2015). Unmanaged changes to system artifacts (such as those associated with {{Term|Plan (glossary)|plans}}, {{Term|Requirement (glossary)|requirements}}, {{Term|Design (glossary)|design}}, {{Term|Software (glossary)|software}}, hardware, testing, and documentation) can lead to problems that persist throughout the system {{Term|Life Cycle (glossary)|life cycle}}. Hence, one primary objective of CM is to manage and control the change to such artifacts.
{{Term|Configuration Management (glossary)|Configuration management}} (CM) helps teams keep track of changes to a system over its life cycle—ensuring that what’s built matches what was planned, and that everyone stays aligned as updates occur. Simply put, CM is about maintaining a clear, accurate picture of a system as it evolves—tracking changes, managing versions, and avoiding confusion.


==Configuration Management Process Overview==
As stated in ISO/IEC/IEEE 15288 (6.3.5.1): The purpose of the configuration management process is to manage system and system element configurations over their life cycle. The INCOSE ''SE Handbook'' describes CM as a key technical management process, supported by defined roles, resources, and controls. In this article, we may refer to a “system” or “product” depending on the application of the CM process.
CM is the discipline of identifying and formalizing the functional and physical characteristics of a {{Term|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 {{Term|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 provides further information on this standard (ANSI/GEIA October 2005).   
==Fundamental Concepts==
CM and main CM concepts are defined slightly differently according to the various standards. The objective of this article is to provide a general understanding of CM based on common and general principles, usually aligned with INCOSE ''SE Handbook'', ISO 10007, and SAE EIA-649C standards. Before entering in the description of the CM process, it is important to define a few concepts (below).   


Effective CM depends on the establishment, maintenance, and implementation of an effective process. The CM process should include, but is not limited to, the following activities:
===Applicability===
CM applies to any kind of system; any product or process can be considered a system. Therefore, CM addresses hardware, software, services, systems, and systems of systems with equal relevance, or any combination of the above. CM is applicable regardless of the complexity of the system in question.


* identification and involvement of relevant stakeholders
CM applies throughout the entire life cycle of the system. CM applies to all system life-cycle models and development approaches, with adequate tailoring.
* 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):
In addition, to master the configuration of a system of interest, the configuration of the associated enabling systems should also be taken into account.
* 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.
===Configuration, Configuration Items, and Configuration Information===
The {{Term|Configuration (glossary)|configuration}} refers to the interrelated functional and physical characteristics outlined in configuration information, as defined by ISO 10007. The system and its individual elements, which fall under Configuration Management, are known as Configuration Items. Their functional and physical characteristics constitute their configuration information.  


[[File:Cm_functions.png|thumb|700px|center|'''Figure 1. Configuration Management Functions.''' (SEBoK Original)]]
Configuration information encompasses the comprehensive data necessary to describe and document Configuration Items throughout the entire system life cycle. This includes artifacts produced during the execution of the technical processes, such as requirement specifications, architecture descriptions, design descriptions, and user documentation, as referenced in ISO/IEC/IEEE 15289.  


===Planning===
Configuration information is understood as structured and contextualized data related to the system and its artifacts. While data serves as the raw input, information represents the processed output that adds context, relevance, and purpose. The collective set of configuration information associated with a system encapsulates all pertinent elements needed to document its characteristics.
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.  
 
===CM fundamental objectives===
The objectives of Configuration Management (CM) are to provide means to guarantee consistency between the system and its configuration information, ensure the integrity and traceability of this information and its changes over time, and facilitate reproducibility. These three objectives collectively enable the capabilities to define, realize, transition, operate, maintain, and dispose of the system.
 
===How do you distinguish Configuration Management (CM) from Information Management (IM)?===
Configuration Management (CM) and Information Management (IM) processes are interconnected; however, CM focuses on the relevance of information related to the system and its evolution over time, while IM concentrates on the management of the information itself. This includes its generation, collection, validation, transformation, dissemination, and disposal, overseeing the entire life cycle of the information.
 
CM is concerned with the significance and applicability of information in relation to the specific system elements with which it is associated, referred to as configuration information. While all information can be managed, only configuration information is subject to configuration management.
 
The CM and IM processes are complementary and closely aligned with the objective of ensuring traceability. 
 
===Configuration Management System===
To ensure the CM process activities, a dedicated Configuration Management system to enable and support CM.
 
== Process Overview ==
The Configuration Management process relies on appropriate processes, resources, and controls, to establish and maintain an authoritative source of truth on system configuration.
 
The CM process consists of activities that are widely used in key standards and references, including ISO/IEC/IEEE 15288, SAE EIA 649, and ISO 10007. The names of these activities may differ through various norms and standards, and in this article, the terms used are:
 
* Configuration Management Planning and Management
* Configuration Identification
* Configuration Change Management
* Configuration Status Accounting
* Configuration Verification and Audit.
 
The benefits of using the CM process are maximized when all five activities are planned and executed. These activities are not strictly sequential; rather, they are interrelated and may be applied concurrently and iteratively as needed throughout the system life cycle.
 
[[File:CM section Figure1.jpg|alt=|center|thumb|900x900px|'''Figure 1. Configuration Management Activities''' (SEBoK Original)]]
 
===CM Planning and Management===
This first activity involves defining the scope and organization of CM tasks. It is considered good practice to formalize the results of this activity in a dedicated CM plan that guides implementation throughout the life cycle. 
 
In terms of organization, the roles in charge of leading the Configuration Management activities on the project need to be defined early in the system life cycle. These roles constitute the CM team. This team is organized according to the size and complexity of the product to be managed and to the organizational rules of the organization. It should at least have a Configuration Manager, who oversees the CM plan.
 
CM Planning and Management defines the CM scope relevant for the system and for being able to maintain the consistency between the system and its configuration information: CM activities need to be adjusted to the type of system (hardware, software, service or combination of the above), the system life cycle, and to the system complexity, as well to the type of configuration information to be managed and to their criticality.
 
The activities depend also on the stages of the life cycle that need to be addressed as defined per contract: if all the stages of the life cycle must be managed from conception until retirement, the CM plan covers all these stages.  
 
The CM plan should address the definition of the CM tasks, their organization, their schedule, the responsibilities of the various stakeholders of the system, and the tools to support the CM. CM activities involve most of the stakeholders of the system.  
 
The CM plan should also 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, subcontracting and partnership situations, as well as any specific requirements agreements.  
 
Except very specific use cases, CM planning and management should address the remaining activities as described hereafter.
 
''Additional considerations about the Planning and Management of CM activities are provided in “[[Configuration Management Implementation|CM implementation]].''


===Configuration Identification===
===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.
This activity overarches the following task:
 
* Identify which elements of the system and which information should be under configuration management
* Identify where configuration management is needed among the elements of the system: these elements are called “Configuration Items”, the information related to these elements are their configuration information
* Define the identification rules for Configuration items and configuration information to apply to ensure the unicity, the rules to make these identifiers evolve, and the associated labelling constraints
* Structure the items and their information: this structure reflects the relationships between system items
* Define the rules for validating and releasing the items and the information under configuration management
* Define the baselines to be established at dedicated milestones of the system life cycle.  
 
Note 1: a baseline specifies how a system is viewed for the purposes of management, control, and evaluation; each baseline is fixed at a specific point in time in the system life cycle and represents the current approved configuration; it serves as a basis for defining changes, and generally can only be changed through formal change procedures. See [[Configuration Baselines|CM baselines]] for more details about typical CM baselines.''
 
Note 2: depending on the practices and methods, the term “configuration item” may be used to designate anything that should be managed in the configuration management system, which leads to include the system elements and its information in the generic term “configuration items”.
 
=== Configuration Change Management ===
A disciplined Configuration Change Management process is critical for engineering systems.  
 
It encompasses the analysis, justification, evaluation, coordination and disposition of changes to the system and variances to the system (non-compliance to its requirements).
 
This activity aims to control the evolution of the system, of its elements and of its configuration information throughout the life cycle.
 
To ensure the missions of the activity, boards are defined to monitor and make key decisions regarding changes and variances process.  


===Establishing Baseline===
These boards are commonly called "Configuration Control Boards (CCBs)" but may also be referred to as "Configuration Steering Boards" or "Change Control Boards (CCBs)". They can also be split into Change Review boards and Change Implementation boards, when separately addressing the decisions about agreeing to the changes and variances and the stage where changes are implemented.
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===
[[File:CM section Figure2.jpg|alt=|center|thumb|900x900px|'''Figure 2. Example of decomposition of the CCB process''' (SEBoK Original)]]
A disciplined change control process is critical for systems engineering. A generalized change control process in response to an {{Term|Engineering Change Proposal (ECP) (glossary)|engineering change proposal}} (ECP) is shown in Figure 2 below, which is adapted from [[Systems Engineering and Analysis]] (Blanchard and Fabrycky 1999).
 
A Configuration Control Board (CCB) typically includes:
[[File:Cm_change_control_process.png|thumb|600px|center|'''Figure 2. Configuration Change Control Process.''' (SEBoK Original)]]
 
* a CCB Chair,
* a Configuration Manager,
* the product or organization systems engineer,
* domain-specific subject-matter experts (SMEs) such as for software or mechanical engineering, product support, and cyber resiliency,
* procurement and contracting specialists.


===Configuration Auditing===
The CCB dealing with the CM of a dedicated system or product (product CCB) may invite periodic participation from specialized or outside SMEs, including representation from vendors and subcontractors; this however must be carefully managed to ensure that information-access restrictions (especially for competition-sensitive information) is not compromised.  
Audits are independent evaluations of the current stat us 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===
Organizational CCBs may be organized at a wider level and address several systems, products, or product lines and they typically include information technology (IT) and cyber resiliency SMEs who may not be needed on product-focused CCBs.  
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 {{Term|Acquirer (glossary)|acquirer}} or {{Term|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 (Bourque and Fairley 2014). 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/IEEE 15288 2015) and configuration management guidelines (ISO 10007 2003), as well as the ''Guide to The Software Engineering Body of Knowledge'' (SWEBOK) (Bourque and Fairley 2014), and the CMMI for Development (SEI 2010).


===Organizational Issues===
''More advanced considerations about the change management and the related boards are provided in [[Configuration Management Implementation|CM implementation]].''
Successful CM planning, management, and implementation requires an understanding of the organizational context for 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 (Bourque and Fairley 2014).


===Measurement===
===Configuration Status Accounting===
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.
This activity covers all the reporting tasks that aim to provide dedicated reporting about the configuration information and the CM activities. The reports can address a wide range of content, for various purposes: internal reports for the organization and for the internal stakeholders, external reports as part of the deliveries planned in the contract, certificates and conformity reports, etc.


===Tools===
== Elaboration ==
CM employs a variety of tools to support the process, for example:
Configuration Management is involved in the management and control of artifacts produced and modified throughout the system [[Life Cycle Models|life cycle]]. It is therefore linked to system analysis, system detailed design definition, [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], [[System Operation|system operation]] and [[Product and Service Life Management|product and service life management]]. 
* 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.
CM must also work in conjunction with other technical management processes. These include project planning, project assessment and control, decision management, risk management, information management, and measurement.  


==Linkages to Other Systems Engineering Management Topics==
This includes CM application to the artifacts of all the other management processes (plans, analyses, reports, statuses, etc.).  
Configuration management is involved in the management and control of artifacts produced and modified throughout the system [[Life Cycle Models|life cycle]] in all areas of system definition, [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], and [[Product and Service Life Management|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==
==Practical Considerations==
Refer to [[Configuration Management Implementation|CM implementation]] for detailed considerations about the practical implementation of CM according to context. 
Key pitfalls and good practices related to systems engineering CM are described in the next two sections.  
Key pitfalls and good practices related to systems engineering CM are described in the next two sections.  


Line 90: Line 144:
|
|
* 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.  
|-
|Insufficient CM Awareness
|
* Insufficient awareness and training of all affected disciplines
|-
|Lack of CM Plan
|
* Not organizing the CM activities and provision of the adequate resources and means
|-
|Insufficient CM Checks
|
* Not verifying CM implementation regularly
|}
|}


Line 108: Line 174:
|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 occur as part of the program without explicit planning.
|-
|-
|CM Planning
|CM Planning
Line 137: Line 203:


|}
|}
Additional good practices can be found in ISO/IEC/IEEE (2009, Clause 6.4) and INCOSE (2010, sec. 5.4.1.5).


==References==  
==References==  


===Works Cited===
===Works Cited===
ANSI/GEIA. 2005. [[GEIA-HB-649|Implementation Guide for Configuration Management]]. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association, [[GEIA-HB-649]]. October 2005.
ISO/IEC/IEEE 15288:2023, Second Edition. ''[[ISO/IEC/IEEE 15288|Systems and software engineering]] — System life cycle processes'' - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. [https://www.iso.org/standard/81702.html ISO/IEC/IEEE 15288:2023] 


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. 2023. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-119-81429-0.


Bourque, P. and R.E. Fairley (eds.). 2014. ''Guide to the Software Engineering Body of Knowledge (SWEBOK)''. Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org  
ISO 10007, Third Edition. ''Quality Management Systems – Guidelines for Configuration Management''. International Organization for Standardization (ISO), [https://www.iso.org/standard/70400.html#lifecycle ISO 10007:2017]


ISO. 2003. ''[[Quality Management Systems – Guidelines for Configuration Management]]''. Geneva, Switzerland: International Organization for Standardization (ISO), ISO 10007:2003.
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/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering]]-- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. [[ISO/IEC/IEEE 15288]]:2015
IEEE SWEBOK Version 4 2024. ''Guide to the Software Engineering Body of Knowledge (SWEBOK)''. Los Alamitos, CA, USA: IEEE Computer Society. Available at: https://www.computer.org/education/bodies-of-knowledge/software-engineering


SEI. 2010. ''[[Capability Maturity Model Integrated (CMMI) for Development]],'' version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
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===
===Primary References===
ANSI/EEIA. 2016. [https://www.sae.org/standards/content/geiahb649a/ ''Configuration Management Standard Implementation Guide'']. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association,  GEIAHB649A. February 2016.
ISO/IEC/IEEE 15288:2023, Second Edition. ''[[ISO/IEC/IEEE 15288|Systems and software engineering]] — System life cycle processes'' - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. [https://www.iso.org/standard/81702.html ISO/IEC/IEEE 15288:2023] 
 
INCOSE. 2023. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-119-81429-0.
 
ISO 10007, Third Edition. ''Quality Management Systems – Guidelines for Configuration Management''. International Organization for Standardization (ISO), [https://www.iso.org/standard/70400.html#lifecycle ISO 10007:2017]


ANSI/GEIA. 2005. ''[[GEIA-HB-649|Implementation Guide for Configuration Management]]''. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association, [[GEIA-HB-649]]. October 2005.
ANSI/GEIA. 2019. ''[[GEIA-HB-649|Configuration Management Standard Implementation Guide]]''. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association, [https://www.sae.org/standards/content/eia649c/ EIA649C].


GEIA. 2004. ''[[GEIA Consensus Standard for Data Management]]''. Arlington, VA, USA: Government Electronics & Information Technology Association, GEIA-859.  
GEIA. 2022. ''[[GEIA-859|Data Management]]''. Arlington, VA, USA: Government Electronics & Information Technology Association. [https://www.sae.org/standards/content/geia859b/ GEIA-859B].


ISO. 2003. ''[[Quality Management Systems – Guidelines for Configuration Management]]''. Geneva, Switzerland: International Organization for Standardization (ISO), ISO 10007:2003.
===Additional References===
ISO/IEC/IEEE 16236:2019. ''Systems and Software Engineering - Life Cycle Processes - Project Management''. International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - [https://www.iso.org/standard/75276.html ISO/IEC/IEEE 16326:2019] (Edition 2)  


ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering]]-- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. [[ISO/IEC/IEEE 15288]]:2015
ISO/IEC/IEEE 15289:2019. ''Systems and software engineering — Content of life-cycle information items.'' International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - [https://www.iso.org/standard/74909.html ISO/IEC/IEEE 15289:2019] (Edition 4)


SEI. 2010. ''[[Capability Maturity Model Integrated (CMMI) for Development]],'' version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
ISO/IEC/IEEE 24748-1:2024. ''Systems and software engineering — Life cycle management - Part 1: Guidelines for life cycle management''. International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - [https://www.iso.org/standard/84709.html ISO/IEC/IEEE 24748-1:2024] (Edition 2)  
 
ISO/IEC/IEEE 24748-2 ''Systems and software engineering — Life Cycle Management – Part 2:'' Guidelines for the Application of ISO/IEC/IEEE 15288


===Additional References===
ISO/IEC/IEEE 24748-2:2024. ''Systems and software engineering — Life cycle management - Part 2: Guidelines for the application of ISO/IEC/IEEE 15288 (system life cycle processes'') - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - ISO/IEC/IEEE 24748-2:2024 (Edition 2)
INCOSE Tools database working group (TDWG). in International Council on Systems Engineering (INCOSE) [database online]. San Diego, CA, USA, 2010. Accessed April 13, 2015. Available at: http://www.incose.org/docs/default-source/wgcharters/tools-database.pdf. 


INCOSE. 2008. "INCOSE measurement tools survey." in International Council on Systems Engineering (INCOSE) [database online]. San Diego, CA, USA, 2008. 
ECSS-M-ST-40C Rev.1. 2009. ''Space project management - Configuration and information management''. Noordwijk, The Netherlands: European Cooperation for Space Standardization (ECSS)  


ISO/IEC/IEEE. 2009. ''Systems and Software Engineering - Life Cycle Processes - Project Management''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).
ANSI/EEIA. 2020. ''Configuration Management Requirements for Defense Contracts EIA649_1A''. Arlington, VA, USA: Government Electronics & Information Technology Association - [https://www.sae.org/standards/content/eia649_1a/ EIA649_1A]


ISO/IEC/IEEE 24748-8:2019 - Systems and software engineering — Life cycle management Part 8: Technical reviews and audits on defense programs - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - [https://www.iso.org/standard/75405.html ISO/IEC/IEEE 24748-8:2019]  (Edition 1)
----
----


<center>[[Decision Management|< Previous Article]]  |  [[Systems Engineering Management|Parent Article]]  |  [[Information Management|Next Article >]]</center>
<center>[[Decision Management|< Previous Article]]  |  [[Systems Engineering Management|Parent Article]]  |  [[Configuration Baselines|Next Article >]]</center>




Line 183: Line 254:
[[Category: Part 3]][[Category:Topic]]
[[Category: Part 3]][[Category:Topic]]
[[Category:Systems Engineering Management]]
[[Category:Systems Engineering Management]]
<center>'''SEBoK v. 2.11, released 25 November 2024'''</center>
<center>'''SEBoK v. 2.12, released 27 May 2025'''</center>

Latest revision as of 23:32, 23 May 2025

Lead Authors: John Metcalf, Philip Hallenbeck, Sandrine Gonthier Contributing Author: Garry Roedler

Configuration managementConfiguration management (CM) helps teams keep track of changes to a system over its life cycle—ensuring that what’s built matches what was planned, and that everyone stays aligned as updates occur. Simply put, CM is about maintaining a clear, accurate picture of a system as it evolves—tracking changes, managing versions, and avoiding confusion.

As stated in ISO/IEC/IEEE 15288 (6.3.5.1): The purpose of the configuration management process is to manage system and system element configurations over their life cycle. The INCOSE SE Handbook describes CM as a key technical management process, supported by defined roles, resources, and controls. In this article, we may refer to a “system” or “product” depending on the application of the CM process.

Fundamental Concepts

CM and main CM concepts are defined slightly differently according to the various standards. The objective of this article is to provide a general understanding of CM based on common and general principles, usually aligned with INCOSE SE Handbook, ISO 10007, and SAE EIA-649C standards. Before entering in the description of the CM process, it is important to define a few concepts (below).

Applicability

CM applies to any kind of system; any product or process can be considered a system. Therefore, CM addresses hardware, software, services, systems, and systems of systems with equal relevance, or any combination of the above. CM is applicable regardless of the complexity of the system in question.

CM applies throughout the entire life cycle of the system. CM applies to all system life-cycle models and development approaches, with adequate tailoring.

In addition, to master the configuration of a system of interest, the configuration of the associated enabling systems should also be taken into account.

Configuration, Configuration Items, and Configuration Information

The configurationconfiguration refers to the interrelated functional and physical characteristics outlined in configuration information, as defined by ISO 10007. The system and its individual elements, which fall under Configuration Management, are known as Configuration Items. Their functional and physical characteristics constitute their configuration information.

Configuration information encompasses the comprehensive data necessary to describe and document Configuration Items throughout the entire system life cycle. This includes artifacts produced during the execution of the technical processes, such as requirement specifications, architecture descriptions, design descriptions, and user documentation, as referenced in ISO/IEC/IEEE 15289.

Configuration information is understood as structured and contextualized data related to the system and its artifacts. While data serves as the raw input, information represents the processed output that adds context, relevance, and purpose. The collective set of configuration information associated with a system encapsulates all pertinent elements needed to document its characteristics.

CM fundamental objectives

The objectives of Configuration Management (CM) are to provide means to guarantee consistency between the system and its configuration information, ensure the integrity and traceability of this information and its changes over time, and facilitate reproducibility. These three objectives collectively enable the capabilities to define, realize, transition, operate, maintain, and dispose of the system.

How do you distinguish Configuration Management (CM) from Information Management (IM)?

Configuration Management (CM) and Information Management (IM) processes are interconnected; however, CM focuses on the relevance of information related to the system and its evolution over time, while IM concentrates on the management of the information itself. This includes its generation, collection, validation, transformation, dissemination, and disposal, overseeing the entire life cycle of the information.

CM is concerned with the significance and applicability of information in relation to the specific system elements with which it is associated, referred to as configuration information. While all information can be managed, only configuration information is subject to configuration management.

The CM and IM processes are complementary and closely aligned with the objective of ensuring traceability.

Configuration Management System

To ensure the CM process activities, a dedicated Configuration Management system to enable and support CM.

Process Overview

The Configuration Management process relies on appropriate processes, resources, and controls, to establish and maintain an authoritative source of truth on system configuration.

The CM process consists of activities that are widely used in key standards and references, including ISO/IEC/IEEE 15288, SAE EIA 649, and ISO 10007. The names of these activities may differ through various norms and standards, and in this article, the terms used are:

  • Configuration Management Planning and Management
  • Configuration Identification
  • Configuration Change Management
  • Configuration Status Accounting
  • Configuration Verification and Audit.

The benefits of using the CM process are maximized when all five activities are planned and executed. These activities are not strictly sequential; rather, they are interrelated and may be applied concurrently and iteratively as needed throughout the system life cycle.

Figure 1. Configuration Management Activities (SEBoK Original)

CM Planning and Management

This first activity involves defining the scope and organization of CM tasks. It is considered good practice to formalize the results of this activity in a dedicated CM plan that guides implementation throughout the life cycle.

In terms of organization, the roles in charge of leading the Configuration Management activities on the project need to be defined early in the system life cycle. These roles constitute the CM team. This team is organized according to the size and complexity of the product to be managed and to the organizational rules of the organization. It should at least have a Configuration Manager, who oversees the CM plan.

CM Planning and Management defines the CM scope relevant for the system and for being able to maintain the consistency between the system and its configuration information: CM activities need to be adjusted to the type of system (hardware, software, service or combination of the above), the system life cycle, and to the system complexity, as well to the type of configuration information to be managed and to their criticality.

The activities depend also on the stages of the life cycle that need to be addressed as defined per contract: if all the stages of the life cycle must be managed from conception until retirement, the CM plan covers all these stages.  

The CM plan should address the definition of the CM tasks, their organization, their schedule, the responsibilities of the various stakeholders of the system, and the tools to support the CM. CM activities involve most of the stakeholders of the system.  

The CM plan should also 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, subcontracting and partnership situations, as well as any specific requirements agreements.

Except very specific use cases, CM planning and management should address the remaining activities as described hereafter.

Additional considerations about the Planning and Management of CM activities are provided in “CM implementation.

Configuration Identification

This activity overarches the following task:

  • Identify which elements of the system and which information should be under configuration management
  • Identify where configuration management is needed among the elements of the system: these elements are called “Configuration Items”, the information related to these elements are their configuration information
  • Define the identification rules for Configuration items and configuration information to apply to ensure the unicity, the rules to make these identifiers evolve, and the associated labelling constraints
  • Structure the items and their information: this structure reflects the relationships between system items
  • Define the rules for validating and releasing the items and the information under configuration management
  • Define the baselines to be established at dedicated milestones of the system life cycle.

Note 1: a baseline specifies how a system is viewed for the purposes of management, control, and evaluation; each baseline is fixed at a specific point in time in the system life cycle and represents the current approved configuration; it serves as a basis for defining changes, and generally can only be changed through formal change procedures. See CM baselines for more details about typical CM baselines.

Note 2: depending on the practices and methods, the term “configuration item” may be used to designate anything that should be managed in the configuration management system, which leads to include the system elements and its information in the generic term “configuration items”.

Configuration Change Management

A disciplined Configuration Change Management process is critical for engineering systems.  

It encompasses the analysis, justification, evaluation, coordination and disposition of changes to the system and variances to the system (non-compliance to its requirements).

This activity aims to control the evolution of the system, of its elements and of its configuration information throughout the life cycle.

To ensure the missions of the activity, boards are defined to monitor and make key decisions regarding changes and variances process.  

These boards are commonly called "Configuration Control Boards (CCBs)" but may also be referred to as "Configuration Steering Boards" or "Change Control Boards (CCBs)". They can also be split into Change Review boards and Change Implementation boards, when separately addressing the decisions about agreeing to the changes and variances and the stage where changes are implemented.

Figure 2. Example of decomposition of the CCB process (SEBoK Original)

A Configuration Control Board (CCB) typically includes:

  • a CCB Chair,
  • a Configuration Manager,
  • the product or organization systems engineer,
  • domain-specific subject-matter experts (SMEs) such as for software or mechanical engineering, product support, and cyber resiliency,
  • procurement and contracting specialists.

The CCB dealing with the CM of a dedicated system or product (product CCB) may invite periodic participation from specialized or outside SMEs, including representation from vendors and subcontractors; this however must be carefully managed to ensure that information-access restrictions (especially for competition-sensitive information) is not compromised.

Organizational CCBs may be organized at a wider level and address several systems, products, or product lines and they typically include information technology (IT) and cyber resiliency SMEs who may not be needed on product-focused CCBs.

More advanced considerations about the change management and the related boards are provided in CM implementation.

Configuration Status Accounting

This activity covers all the reporting tasks that aim to provide dedicated reporting about the configuration information and the CM activities. The reports can address a wide range of content, for various purposes: internal reports for the organization and for the internal stakeholders, external reports as part of the deliveries planned in the contract, certificates and conformity reports, etc.

Elaboration

Configuration Management is involved in the management and control of artifacts produced and modified throughout the system life cycle. It is therefore linked to system analysis, system detailed design definition, system realization, system deployment and use, system operation and product and service life management.

CM must also work in conjunction with other technical management processes. These include project planning, project assessment and control, decision management, risk management, information management, and measurement.  

This includes CM application to the artifacts of all the other management processes (plans, analyses, reports, statuses, etc.).

Practical Considerations

Refer to CM implementation for detailed considerations about the practical implementation of CM according to context.

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.

Table 1. Configuration Management Pitfalls. (SEBoK Original)
Name Description
Shallow Visibility
  • Not involving all affected disciplines in the change control process.
Poor Tailoring
  • Inadequate CM tailoring to adapt to the project scale, number of subsystems, etc.
Limited CM Perspective
  • Not considering and integrating the CM processes of all contributing organizations including COTS vendors and subcontractors.
Insufficient CM Awareness
  • Insufficient awareness and training of all affected disciplines
Lack of CM Plan
  • Not organizing the CM activities and provision of the adequate resources and means
Insufficient CM Checks
  • Not verifying CM implementation regularly

Good Practices

Some good practices gathered from the references are provided in Table 2 below.

Table 2. Configuration Management Good Practices. (SEBoK Original)
Name Description
Cross-Functional CM
  • Implement cross-functional communication and CM processes for software, hardware, firmware, data, or other types of items as appropriate.
Full Lifecycle Perspective
  • Plan for integrated CM through the life cycle. Do not assume that it will occur as part of the program without explicit planning.
CM Planning
  • 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.
Requirements Traceability
  • Initiate requirements traceability at the start of the CM activity.
CCB Hierarchy
  • Use a hierarchy of configuration control boards commensurate with the program elements.
Consistent Identification
  • Software CI and hardware CI use consistent identification schemes.
CM Automation
  • Configuration status accounting should be as automated as possible.

References

Works Cited

ISO/IEC/IEEE 15288:2023, Second Edition. Systems and software engineering — System life cycle processes - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023 

INCOSE. 2023. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-119-81429-0.

ISO 10007, Third Edition. Quality Management Systems – Guidelines for Configuration Management. International Organization for Standardization (ISO), ISO 10007:2017

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.

IEEE SWEBOK Version 4 2024. Guide to the Software Engineering Body of Knowledge (SWEBOK). Los Alamitos, CA, USA: IEEE Computer Society. Available at: https://www.computer.org/education/bodies-of-knowledge/software-engineering

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

ISO/IEC/IEEE 15288:2023, Second Edition. Systems and software engineering — System life cycle processes - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023 

INCOSE. 2023. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-119-81429-0.

ISO 10007, Third Edition. Quality Management Systems – Guidelines for Configuration Management. International Organization for Standardization (ISO), ISO 10007:2017

ANSI/GEIA. 2019. Configuration Management Standard Implementation Guide. Arlington, VA, USA: American National Standards Institute/Government Electronics & Information Technology Association, EIA649C.

GEIA. 2022. Data Management. Arlington, VA, USA: Government Electronics & Information Technology Association. GEIA-859B.

Additional References

ISO/IEC/IEEE 16236:2019. Systems and Software Engineering - Life Cycle Processes - Project Management. International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - ISO/IEC/IEEE 16326:2019 (Edition 2)

ISO/IEC/IEEE 15289:2019. Systems and software engineering — Content of life-cycle information items. International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - ISO/IEC/IEEE 15289:2019 (Edition 4)

ISO/IEC/IEEE 24748-1:2024. Systems and software engineering — Life cycle management - Part 1: Guidelines for life cycle management. International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - ISO/IEC/IEEE 24748-1:2024 (Edition 2)

ISO/IEC/IEEE 24748-2 Systems and software engineering — Life Cycle Management – Part 2: Guidelines for the Application of ISO/IEC/IEEE 15288

ISO/IEC/IEEE 24748-2:2024. Systems and software engineering — Life cycle management - Part 2: Guidelines for the application of ISO/IEC/IEEE 15288 (system life cycle processes) - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - ISO/IEC/IEEE 24748-2:2024 (Edition 2)

ECSS-M-ST-40C Rev.1. 2009. Space project management - Configuration and information management. Noordwijk, The Netherlands: European Cooperation for Space Standardization (ECSS)

ANSI/EEIA. 2020. Configuration Management Requirements for Defense Contracts EIA649_1A. Arlington, VA, USA: Government Electronics & Information Technology Association - EIA649_1A

ISO/IEC/IEEE 24748-8:2019 - Systems and software engineering — Life cycle management Part 8: Technical reviews and audits on defense programs - International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers - ISO/IEC/IEEE 24748-8:2019  (Edition 1)

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.12, released 27 May 2025
Retrieved from "https://sebokwiki.org/draft/w/index.php?title=Configuration_Management&oldid=74795"