SUP.8 Configuration Management

Linked Knowledge Nuggets:
arrow_forward "Configuration Management"

person Author: Process Fellows
SUP.8 – Configuration Management maintains the integrity of configuration items and baselines across their lifecycle. It ensures correct versioning, storage, release handling, and traceability for all relevant work products.

• school PF_SUP.8_Configuration Management_Extract.pdf
  Short Overview of the SUP.8 Configuration Management Process covering base practices, some examples and a comparion between Automotive SPICE® version 3.1 and 4.0

arrow_forward "Levels of configuration management"

person Author: 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:

1. 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.
2. 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.
3. 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"

person Author: 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?"

person Author: 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.

• O1 Selection criteria for configuration items are defined and applied.
• O2 Configuration item properties are defined.
• O3 Configuration management is established.
• O4 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 baselines (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.

BP1 Identify configuration items. ( O1 )

Define selection criteria for identifying relevant work products to be subject to configuration management. Identify and document configuration items according to the defined selection criteria.
NOTE 1: Configuration items are representing 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 including all system, hardware (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"

person Author: 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"

person Author: 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?"

person Author: 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.

BP3 Establish configuration management. ( O3, O4 )

Establish configuration management mechanisms for 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.

Linked Knowledge Nuggets:
arrow_forward "Configuration Management system"

person Author: 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.

BP7 Ensure completeness and consistency. ( O7 )

Ensure that the information about configuration items is correct and complete including configuration item properties. Ensure the completeness and consistency of baselines (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 (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 (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) gate approval (Approval = Written statement that a deliverable is fit for its intended use, and compliant with defined criteria.).

Linked Knowledge Nuggets:
arrow_forward "How to perform configuration management audits?"

person Author: 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.)