Lesson 11 of 16 · Automation and AI · Automotive SPICE, the vital 20 %
Lifecycles, gates and approvals
ASPICE defines no phases, so no gate model can "map to the phases of the V". What a gate model can do is leave exactly the records an assessor looks for. This lesson shows which records.
A CI check that blocks duplicate record IDs is evidence at which level for SUP.8 itself?
A reviewer checks an architecture record against a checklist and closes two findings. Which GP?
ASPICE has processes, not phases
A PRM/PAM "neither predefines, nor discourages, any order in which PRM processes or Base Practices are to be performed"[PAM §3.3.4, pp. 26–27]. Order belongs to the lifecycle a project defines, which is its answer to MAN.3.BP2 "Define the project lifecycle". The V is a picture of which work products must be consistent and traceable with which. It is not a sequence of phases. So:
- A stage-gate model is a lifecycle, a HOW. It can be a strong one, and the assessor maps it onto the indicators like any other.
- Iteration is allowed. Agile methods "cannot, by definition, contradict" ASPICE[Guidelines §2.5.2, p. 76]. Going back through a gate is not a deviation.
- Plans must still meet the customer's release planning. Significant gaps there downrate MAN.3.BP4, BP9 and SPL.2.BP1 (AGE.RL.1)[p. 77].
A new process for the course: SPL.2 Product Release
It is flex, not base, but it is the process a final gate most often lands in. Purpose: "to control the release of a product to the intended customer". Its BPs define release content and criteria, define the package, identify each release uniquely, build it "from items under configuration control", ensure approval before delivery, provide a release note, state the support terms, and deliver[PAM pp. 30–32]. The information item 13-13 Product release approval identifies the release date and "name and role of approver"[Annex B, p. 138].
Seat-Heat's gates, and where each lands
| Seat-Heat gate | ASPICE home | Evidence it should leave |
|---|---|---|
| Scope agreed | MAN.3.BP1 scope, BP3 feasibility; SYS.1 elicitation | Scope of work (08-53), who confirmed it, when |
| Requirements agreed | SYS.2 / SWE.1; for a change, SUP.10.BP2–BP3 | Analysed requirements; impact analysis covering side effects |
| Plan and design agreed | SYS.3 / SWE.2; MAN.3.BP4/BP8; GP 2.1.2–2.1.4 | Approved plan, named responsibilities |
| Candidate frozen | SUP.8.BP5 baseline; SWE.3.BP4 design ↔ units | Baseline (13-08) |
| Verified | SWE.4–SWE.6 and their traceability BPs | Results traced to measures |
| Ready to release | SUP.8.BP7 complete, consistent baseline; SUP.9 open problems | Manifest and open-problem list |
| Released | SPL.2.BP4–BP8; SUP.10.BP5 confirmation | Approval (13-13), release note (11-03) |
SUP.8.BP7's note says that a baseline's completeness and consistency "can be used to support, e.g., project gate approval"[p. 82]. The mapping above is this course's; an assessor makes their own.
Two things gates are often credited with, wrongly
- System requirements are analysed in SYS.2, not SYS.1. SYS.1 is Requirements Elicitation: it gathers and analyses stakeholder needs and their changes. Software requirements are SWE.1.
- Independent verification is not an ASPICE demand. In PAM 4.1 only quality assurance must be independent, "without conflicts of interest" (SUP.1.BP1, "no self-monitoring")[p. 79], and the Guidelines spell out what that means for roles: the project manager or a developer of the same project may not take the quality-assurance role, though they may in another project[Guidelines §3.23.2.1, p. 192]. ASPICE doesn't require independent verification. Other standards your project follows, such as ISO 26262, have their own independence rules: check which apply, and credit the right standard.
Practice
The final "Released" gate approval is primarily evidence for…
A feature goes back from "Verified" to "Candidate frozen" after a failed test. Is that a deviation from ASPICE?
In the recommended VDA Scope, VAL.1 Validation is…
Besides the decision and date, what does information item 13-13 list for a release approval?
Which ASPICE process explicitly requires independence?
Someone says, "Our gates map to the ASPICE V-model phases." Correct them in two sentences.
ASPICE defines no phases or order; the V shows which work products must be consistent and traceable with which. The gates are our lifecycle (the HOW), and each should leave the records an assessor looks for: baselines, approvals with name and role, and traced verification results.
Your win: you can present any stage-gate lifecycle for what it is and point to the evidence each gate should leave behind.
To keep it: import this lesson's Anki deck (how).
Read next
SPL.2 Product Release, PAM pp. 30–32, and its rating rules in the Guidelines §3.2, pp. 112–113.
Mapping your own team's gates? Walk through them with your teacher in the chat.