Linked Knowledge Nuggets: arrow_forward "Sustainable Implementation of Best Practices to achieve ASPICE Level 2"
personAuthor: Alexander Feulner
Achieving Automotive SPICE Level 2 is not an overnight task, and ensuring its sustainability presents an additional challenge. Key obstacles and best practices must be addressed to establish Level 2 in a structured and lasting manner. This includes identifying common weaknesses in Level 1 and 2 assessments, shedding light on typical pitfalls organizations encounter. Implementing best practices helps bridge these gaps by standardizing workflows and enhancing process adherence. A well-defined roadmap for the early adoption of Level 2 aspects facilitates a smoother transition and long-term stability. However, organizations often struggle with process improvements due to resistance to change and integration complexities. Successfully overcoming these challenges requires a strategic approach, continuous monitoring, and a strong commitment to process maturity.
Here you find a presentation of "strategic" level 2 wokrshops to enhances sustainable implementation.
school
Sustainable Implementation of Best Practices to achieve ASPICE Level 2.pdf
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 ATTRIBUTE SCOPE
The work product management process attribute is a (Measure = An activity to achieve a certain intent.) of the extent to which the work products produced by the process are appropriately managed.
# PROCESS ATTRIBUTE ACHIEVEMENTS
A1
The requirements for the work products of the process are defined.
A2
The requirements for storage and control of the work products are defined.
A3
The work products are appropriately identified, stored, and controlled.
A4
The work products are reviewed and adjusted as necessary to meet requirements.
# GENERIC PRACTICES
GP2.2.1
Define the requirements for the work products. (
A1 )
The requirements for the content and structure of the work products to be produced are defined. Quality criteria for the work products are identified. Appropriate review and (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) criteria for the work products are defined. Note 1: Possible sources of documentation requirements may be, e.g., best practices or lessons learned from other (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.), standards, organization requirements, customer requirements, etc. Note 2: There may be types of work products for which no review or (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) is required, thus then there would be no need to define the corresponding criteria.
Linked Knowledge Nuggets: arrow_forward "Examples of work product quality criteria and where they can be found"
personAuthor: Process Fellows
Examples of work product quality criteria:
Quality attributes like consistency to input, completeness, correctness, traceability, verifiability, etc.. These attributes are often included as part of review checklists to guide structured evaluations of work products.
The "Definition of Done" (DoD) supports as well the idea of work product quality criteria. DoD is a shared understanding within a team of what it means for a (work) product to be considered complete (remark: DoD is not only used for work products, but as well for tasks or user stories). It is a list of criteria that must be met before work can be marked as “done.”
Work product quality attributes are not limited to checklists. They can also be found within guidelines, standards, or best practices documents, providing broader context and ensuring consistent application across teams and processes.
arrow_forward "How long should a review take?"
personAuthor: Process Fellows
Keep your reviews focused. Aim for a maximum duration of 60 to 90 minutes, especially for detailed specifications. It is better to review fewer points thoroughly than to review everything superficially. In other words, a best practice is to review extensive documents iteratively in smaller steps. Track the efficiency of the reviews as a process metric.
arrow_forward "Rethinking review culture – beyond the checkbox"
personAuthor: Process Fellows
Reviews are not a formality — they’re quality gates. Encourage teams to approach them as knowledge-sharing and risk-reduction rituals. Use structured checklists, timebox the sessions, and vary the review focus (structure, content, traceability). Create value, not just evidence.
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.
GP2.2.2
Define the requirements for storage and control of the work products. (
A2 )
The requirements for the storage and control of the work products are defined, including their identification and distribution. Note 3: Possible sources for the identification of requirements for storage and control may be, e.g., legal requirements, data policies, best practices from other (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.), tool related requirements, etc. Note 4: Examples for work product storage are files in a file (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.), tickets in a tool, Wiki entries, paper documents etc. Note 5: Where the status of a work product is required in base practices, this should be managed via a defined status model.
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 "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.
GP2.2.3
Identify, store and control the work products. (
A3 )
The work products to be controlled are identified. The work products are stored and controlled in accordance with the requirements. A change control is established for work products. Versioning and baselining of the work products is performed in accordance with the requirements for storage and control of the work products. The work products including the revision status are made available through appropriate mechanisms.
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.
GP2.2.4
Review and adjust work products. (
A4 )
The work products are reviewed against the defined requirements and criteria. Resolution of issues arising from work products reviews is ensured.
Linked Knowledge Nuggets: arrow_forward "How long should a review take?"
personAuthor: Process Fellows
Keep your reviews focused. Aim for a maximum duration of 60 to 90 minutes, especially for detailed specifications. It is better to review fewer points thoroughly than to review everything superficially. In other words, a best practice is to review extensive documents iteratively in smaller steps. Track the efficiency of the reviews as a process metric.
arrow_forward "Rethinking review culture – beyond the checkbox"
personAuthor: Process Fellows
Reviews are not a formality — they’re quality gates. Encourage teams to approach them as knowledge-sharing and risk-reduction rituals. Use structured checklists, timebox the sessions, and vary the review focus (structure, content, traceability). Create value, not just evidence.
arrow_forward "Why are reviews not a waste of time?"
personAuthor: Process Fellows
Reviews prevent defects, align understanding, and improve quality. They don’t need to be long – just focused and regular. Invest the time here and save more time in testing ,managing defects, implementing bugfixes and re-testing.
# OUTPUT INFORMATION ITEMS
13-08
Baseline (
A3 )
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
16-03
Configuration management system (
A3 )
(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
18-07
Quality criteria (
A1 )
Specified requirements to determine whether a product, process, or service conforms to quality objectives.Identifies:
(Measurement = The activity to find the size, quantity or degree of something.) needs
Timings
Required elements
Needs for completeness
Accuracy
Performance needs
Includes:
Thresholds
Tolerance level
Attributes
Compliance and conformance references
Examples and References:
Conformance requirements specifying a specific set of values to be within a defined range.
Used by these processes:
SUP.1 Quality Assurance
Used by these process attributes:
PA2.2 Work product management process attribute
17-05
Requirements for work products (
A1, A2 )
Statement that identifies a textual, functional, or design characteristic, necessary for work products.Identifies:
Expectation to content and structure
Owner and origin of the requirement
Control and (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) mechanism
Identification information
Access rights
Status model references, for example as maintenance and disposal requirements
Includes:
References to documentation templates
Table of content or other overview documentation
Design constraints, for example predefined and necessary implementation details.
Tolerances
Domain specific details, for example of safety and privacy standards
Used by these process attributes:
PA2.2 Work product management process attribute
18-59
Review and approval criteria for work products (
A1 )
Specification of review and (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) criteria for work products.Identifies:
Review conditions
Timing needs, for example a specific milestone
Review methods, for example inspection or peer review
Includes:
(Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) definition
Examples and References:
Definition when and how to perform a walkthrough meeting.
Used by these process attributes:
PA2.2 Work product management process attribute
13-19
Review evidence (
A4 )
A proof to demonstrate a structured check of a work product or a process has taken place.Identifies:
Name and version of the review object
Names and roles of the people who performed the review
Date
Status
Review criteria, for example review method coverage, justification
Non-conformances found
Improvement suggestions
Includes:
Documents considered, for example checklists guidelines, work instructions
PA2.2
Work product management process attribute
