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
Requirements for the work products of the process are defined.
A2
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, and 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 and 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, and 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 )
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 and requirements.), tool related requirements, etc. Note 4: Examples for work product storage are files in a file system, ticket in a tool, Wiki entry, paper documents etc. Note 5: Where 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. 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 )
Identifies a state of one or a set of work products and artifacts which are consistent and complete
Basis for next process steps and/or delivery
Is unique and may not be changed
Note: This should be established before a (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) to identify consistent and complete delivery
Used by these processes:
SUP.8 Configuration Management
Used by these process attributes:
PA2.2 Work Product Management
18-07
Quality criteria (
A1 )
Defines the expectations for work products and process performance
Including thresholds/tolerance levels, required (Measurement = “The activity to find the size, quantity or degree of something”.), required checkpoints
Defines what is an adequate work product (required elements, completeness expected, accuracy, etc.)
Defines what constitutes the completeness of the defined (Task = A definition, but not the execution, of a coherent and set of atomic actions.)
Defines what constitutes the performance of the defined (Task = A definition, but not the execution, of a coherent and set of atomic actions.)
Establishes expected performance attributes
Used by these processes:
SUP.1 Quality Assurance
Used by these process attributes:
PA2.2 Work Product Management
16-00
Repository (
A3 )
Used by these process attributes:
PA2.2 Work Product Management
17-05
Requirements for work products (
A1, A2 )
Requirements for content and structure, storage and control
Identifies documentation specific meta data, such as id, date, author information, ownership, access rights, review and (Approval = Written statement that a deliverable is fit for its intended use, and compliant with defined criteria.) status with, where applicable, status model and workflow, or others
Identifies requirements on documentation structure, e.g., table of content or figures or other formal aspects
May be provided by documentation templates
May be based on tool specific templates
Defines the storage location such as data repository, tool, versioning system
Requirements for versioning
Requirements for baselining
Distribution of the documents
Maintenance and disposal of the documents
May be specific for certain types of documents
Used by these process attributes:
PA2.2 Work Product Management
18-59
Review and approval criteria for work products (
A1 )
Specifies for each type of work products review and (Approval = Written statement that a deliverable is fit for its intended use, and compliant with defined criteria.) needs
If and when a review is required
Who shall review it
Who shall approve it
Review method(s) to be used
Criteria for (Approval = Written statement that a deliverable is fit for its intended use, and compliant with defined criteria.)
Used by these process attributes:
PA2.2 Work Product Management
13-19
Review evidence (
A4 )
Provides the context information about the review:
what was reviewed
lists reviewers who attended and their area of responsibility
status of the review
Provides information about the scope of the review:
PA2.2
Work Product Management
