Linked Knowledge Nuggets: arrow_forward "Levels of configuration management"
personAuthor: Process Fellows
Not every file is automatically considered a Configuration Item (CI).
To determine which item should be managed as a CI, clear criteria should be defined. These criteria help identify what qualifies for configuration management. As a result, different levels or degrees of configuration management may be established, depending on the importance, complexity, or impact of the items being managed.
Examples:
Level 1: Archiving Only: No version control, no formal change process.
Purpose: The item is stored for reference or traceability.
Examples: Meeting minutes, internal memos.
Level 2: Version Control: Each change creates a new version; changes are tracked and documented.
Purpose: The item is actively maintained and updated over time.
Examples: Specifications, plans, user manuals, source code.
Level 3: Baseline Inclusion: Changes require formal approval; baselines are used for configuration audits and traceability.
Purpose: The item is part of a formally approved configuration baseline.
Examples: Requirements baselines, software releases.
arrow_forward "When and how to use supporting processes?"
personAuthor: Process Fellows
Supporting processes like SUP.9 (Problem Resolution) or SUP.10 (Change Request Management) are often misunderstood as “back-office.” But they’re vital for delivering quality. Make sure your teams know when to invoke them — and how to record their outcomes. A 2-minute log of a problem review can save hours of debugging.
arrow_forward "Why do I need Configuration Management at Capability Level 2?"
personAuthor: Process Fellows
Without proper CM, teams risk working on outdated or inconsistent data. Even simple setups (e.g. Git with branching rules) can meet ASPICE, if consistently used and documented. CM ensures reliability and trust in project data.
# PROCESS PURPOSE
The purpose is to establish and maintain the integrity of relevant configuration items and (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.), and to make them available to all affected parties.
# PROCESS OUTCOMES
O1
Selection criteria for configuration items are defined and applied.
O2
The configuration item properties are defined.
O3
Configuration management is established.
O4
The modifications are controlled.
O5
Baselining is applied.
O6
The status of the configuration items is recorded and reported.
O7
The completeness and consistency of the (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) is ensured.
O8
The availability of backup and recovery mechanisms is verified.
# BASE PRACTICES
BP1
Identify the configuration items. (
O1 )
Define selection criteria for identifying relevant work products to be subject to configuration management. Identify and document the configuration items according to the defined selection criteria. Note 1: Configuration items represent work products or group of work products which are subject to configuration management as a single entity. Note 2: Configuration items may vary in complexity, size, and type, ranging from an entire (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) including all (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.), (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.), and software documentation down to a single element or document. Note 3: The selection criteria may be applied to single work products or a group of work products.
Linked Knowledge Nuggets: arrow_forward "Examples of criteria for configuration items"
personAuthor: Process Fellows
The following criteria may serve as exemplary criteria to select relevant work products to be subject to configuration management:
Uniqueness and Identifiability:
The item must be uniquely identifiable (e.g., through a name, ID, or version number).
Change Impact:
Changes to the item can affect system properties, functionality, compliance, or other CIs.
Need for Control:
The item requires formal control to ensure consistency, traceability, and integrity.
Reusability:
The item is reused across multiple systems, projects, or releases.
Compliance or Regulatory Requirement:
The item is subject to audits, standards, or legal requirements (e.g., medical device documentation, safety-critical software).
Customer or Stakeholder Deliverable:
The item is part of what is delivered to the customer or required by stakeholders.
Baseline Inclusion:
The item is intended to be part of a configuration baseline, meaning it must be formally approved and controlled.
Versioning Requirement:
The item evolves over time and needs version tracking to manage changes.
Dependency Relationships:
The item has dependencies or is depended upon by other items, making its configuration critical.
arrow_forward "Grouping of configuration items"
personAuthor: Process Fellows
Configuration items can be composed of multiple related work products instead of just a single work product. This allows organizations to group related work products under a single CI for traceability and control, while avoiding unnecessary overhead by not treating every work product as a CI. An example of this could be a requirements specification consisting of many individual requirements.
arrow_forward "Work Product vs. Document – Why it’s not the same?"
personAuthor: Process Fellows
In ASPICE, a work product is any tangible result – not necessarily a document. A user story in Jira? A valid work product. The format is secondary – the purpose, content and traceability matter.
BP2
Define the configuration item properties. (
O2 )
Define the necessary properties needed for the modification and control of configuration items. Note 4: The configuration item properties may be defined for single configuration items or a group of items. Note 5: Configuration item properties may include a status model (e.g., Under Work, Tested, Released, etc.), storage location, access rights, etc. Note 6: The application of properties may be implemented by attributes of configuration items.
BP3
Establish the configuration management. (
O3, O4 )
Establish configuration management mechanisms for the control of identified configuration items including the configuration item properties, including mechanisms for controlling parallel modifications of configuration items. Note 7: This may include specific mechanisms for different configuration item types, such as branch and merge management, or checkout control.
personAuthor: Process Fellows
There is no universal tool for managing all Configuration Items.
Configuration Items may be stored across multiple repositories, depending on their type, lifecycle phase, or organizational structure. This should be viewed as a "repository landscape", where each repository serves a specific purpose.
To ensure clarity and traceability:
Clearly define where each Configuration Item is stored.
Document the relationships and dependencies between the tools and repositories involved.
Also define the interdependencies between Configuration Items that span across different systems or repositories.
BP4
Control the modifications. (
O4 )
Control the modifications using the configuration management mechanisms. Note 8: This may include the application of a defined status model for configuration items.
BP5
Establish baselines. (
O5 )
Define and establish (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) for internal purposes, and for external product delivery, for all relevant configuration items.
BP6
Summarize and communicate the configuration status. (
O6 )
Record, summarize, and communicate the status of the configuration items and established (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) to all affected parties in order to support the monitoring of progress and status. Note 9: Regular communication of the configuration status, e.g., based on a defined status model supports (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) management, quality activities, and dedicated (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) phases such as software integration.
BP7
Ensure completeness and consistency. (
O7 )
Ensure that the information about configuration items is correct and complete including the configuration item properties. Ensure the completeness and consistency of the (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.). Note 10: Completeness and consistency of a (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) means that all required configuration items are included and consistent, and have the required status. This can be used to support, e.g., (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) gate (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.).
Linked Knowledge Nuggets: arrow_forward "How to perform configuration management audits?"
personAuthor: Process Fellows
A Configuration Management Audit is a formal process used to verify that configuration items (CIs) and their associated documentation are complete, correct, and compliant with defined requirements and procedures. It ensures that the configuration management system is functioning properly and that the product or system is accurately represented.
Configuration management audits typically fall into two distinct categories, each addressing a specific aspect of the configuration process:
Functional Configuration Audit (FCA): Verifies that the system meets its functional requirements. Example: Use the release plan as an input to check if all required requirements are actually implemented and verified.
Physical Configuration Audit (PCA): Verifies that the physical product aligns with its design documentation.
For example, consider a software release delivered as a ZIP file. The audit should confirm that all required components are included within the archive and that the accompanying documentation accurately reflects the contents of the release — such as software version, configuration, and intended functionality.
Depending on the specific criteria addressed with such audits, they are typically performed:
per release candidate (as known as baseline audits): to check for release readiness, i.e. all required configuration items are part of the baseline, consistency within the baseline, etc.
on a regular basis, e.g. to check if configuration item list is up-to-date, configuration items are properly managed (correct storage location, adherence to naming conventions, correct usage of tools, etc.)
BP8
Verify the availability of backup and recovery mechanisms. (
O8 )
Verify the availability of appropriate backup and recovery mechanisms for the configuration management including the controlled configuration items. Initiate (Measure = An activity to achieve a certain intent.) in case of insufficient backup and recovery mechanisms. Note 11: Backup and recovery mechanisms may be defined and implemented by organizational units outside the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) team. This may include references to corresponding procedures or regulations.
# OUTPUT INFORMATION ITEMS
06-52
Backup and recovery mechanism information (
O8 )
Processes and tools used to create backups of data restore it in case of loss or corruption.Identifies:
Description and confirmation of backup and recovery mechanisms
References to corresponding procedures or regulations
Used by these processes:
SUP.8 Configuration Management
13-08
Baseline (
O5, O7 )
A coherent set of work products which are consistent complete and may serve as basis for next process steps and/or delivery. A (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) must be unique and not changed any more.Identifies:
All work products belonging to the (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.)
References using the configuration item properties
Includes:
Name
Version
State
Used by these processes:
SUP.8 Configuration Management
Used by these process attributes:
PA2.2 Work product management process attribute
14-01
Change history (
O3, O4, O6 )
Structured, chronological record of modifications made to an object (document, file, (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.), etc.) over its lifecycle.Identifies:
Version information about changed object
Date of change
Description of change
Originator
Used by these processes:
SUP.8 Configuration Management
01-52
Configuration item list (
O1, O2, O7 )
List of configurable items under configuration control.Identifies:
Rules or parameters to determine elements of a (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) to be Included under configuration control.Identifies:
Stakeholder needs
Regulatory needs
Configuration item identification requirements
Includes:
Type of work products
Classification characteristic
Examples and References:
Maintainability requirement of software evaluation work products.
Traceability requirements of supplier goods.
Used by these processes:
SUP.8 Configuration Management
16-03
Configuration management system (
O3, O4, O5 )
(System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) to manage configurations throughout a (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) or product life cycle, providing integrity, consistency and control.Identifies:
Configuration items to be controlled, for example documents, (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) or tools
Configuration information, for example to a status model
Repository
(Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.)
Changes and change status
Includes:
Reporting requirements
Workflow of recovery and other containment activities, for example security fire drills.
Examples and References:
NASA defines it as technical management discipline that provides visibility and control over performance, functional, and physical characteristics of a product, preventing incorrect or unsafe configurations from being released.
Used by these processes:
SUP.8 Configuration Management
Used by these process attributes:
PA2.2 Work product management process attribute
15-56
Configuration status (
O6 )
Summary of configuration management records and status.Identifies:
Version and change history information
(Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) identification
Status of configuration items (CI) integrity and consistency
Identified deviations, for example missing CI performance (Metric = A quantitative or qualitative measurable indicator that matches defined information needs.) deviations
Used by these processes:
SUP.8 Configuration Management
13-51
Consistency evidence (
O7 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SUP.8
Configuration Management
