RTCM Release Technical Configuration Management

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.

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 "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 "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.

• O1 Engineering-related configuration items are identified
• O2 The content for the release (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) is defined
• O3 The release (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) is assembled from configured items
• O4 Modifications and releases (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) are made available to affected parties
• O5 Baselines (Baseline = A defined and coherent set of read-only information, serving as an input information for the affected parties.) are regularly recorded and controlled for engineering-related configuration items
• O6 The release (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) documentation is defined and produced
• O7 The product release (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) is made available to the intended customer