Lesson 9 of 16 · Automotive SPICE, the vital 20 %

Capstone: assess Seat-Heat's change management

A paper assessment of one process, SUP.10, with a target of level 2. Everything from lessons 1–8 turns up here, deliberately mixed. Try each question before you look anything up.

The assessment input

Purpose	OEM supplier assessment ahead of the start-of-production decision.
Org. unit	The Seat-Heat team, one site.
Process	SUP.10 Change Request Management, target capability level 2.
Context	All change requests for releases 2.0 to 2.3. Two instances: application code (Seat-Heat's own) and platform code (a shared base-software layer that Seat-Heat maintains for three projects).

SUP.10 in brief

Purpose: "to ensure that change requests are recorded, analyzed, tracked, approved, and implemented". The base practices are BP1 identify and record · BP2 analyse and assess · BP3 approve before implementation · BP4 bidirectional traceability · BP5 confirm implementation · BP6 track to closure[PAM pp. 85–86]. Rating rules you will need[Guidelines §3.26, pp. 208–211]:

SUP.10.RL.1 If the analysis omits potential side effects, BP2 shall not be rated F.
SUP.10.RL.3 If not all relevant disciplines or stakeholders are represented in the approval authority (the change control board, CCB), BP3 shall not be rated F.
SUP.10.RL.4 If approval decisions are apparently not taken, or not taken in time, without justification, BP3 shall be downrated.

The evidence: application-code instance

Jira issue type "Change Request". Mandatory fields: initiator, reason, description, affected components, effort, risk. Workflow: Open → Analysed → Approved → Implemented → Verified → Closed. Issue history intact back to release 2.0. Sample of 10 CRs, chosen by the assessor, traced from OEM request to release: · all 10 recorded with initiator and reason; · 10 of 10 list affected components; 3 of 10 say nothing about side effects on other functions; · CCB (product owner + SW lead) meets weekly; the test lead is not a member; minutes in Confluence, one page per meeting, edited the same week; · 2 of 10 went Open → Implemented, skipping Approved ("urgent customer fix"); no emergency path is defined; · every CR links to the requirement issues it changes and to its PRs; PRs cite the CR key; CRs raised from bugs link to the bug; · the test lead sets Verified only after the linked hardware-in-the-loop (HIL) tests pass; · a dashboard shows CR status; the OEM portal is synced weekly. Project handbook: "Every CR analysed within 5 working days. No unanalysed CR 4 weeks before a release." Dashboard of analysis age reviewed at stand-up. It showed the 5-day target missed in sprints 12 and 13; no action was recorded. The sprint plan reserves the CCB's two hours a week and names the product owner and SW lead for it. CCB membership and the OEM portal channel are defined in the handbook. A Confluence page lists "analysis complete" criteria; the CCB checks them before approving. A tool template enforces the fields.

Round 1: base practices and PA 1.1

BP2 analyse and assess the change requests.

BP3 approve before implementation.

BP4 establish bidirectional traceability.

PA 1.1 for the application-code instance.

Round 2: level 2 attributes

Are the handbook's two targets valid process performance objectives?

Which GP does "target missed twice, no action recorded" hit?

PA 2.1 for this instance.

The Jira template's mandatory fields and the "analysis complete" criteria page. Which GP?

PA 2.2 for this instance.

Round 3: the platform instance and the verdict

Platform code: changes arrive as Slack messages from the three projects; about half get a Jira ticket afterwards. No impact analysis recorded; no approval step; changes are merged by the platform maintainer. PRs are reviewed, and release notes list the changes. Nobody has set targets for platform changes, planned time for them, or tracks how they are handled.

PA 1.1 for the platform instance.

PA 2.1 for the platform instance.

Using your two instance ratings with equal weights, what is SUP.10's aggregated PA 1.1?

And SUP.10's aggregated PA 2.1?

SUP.10's capability level, from the aggregated ratings?

The day before the assessment, the platform maintainer creates a "Platform CR process" page. The assessor…

Which single fix does most to get SUP.10 to level 2?

Round 4: write it like an assessor

Write the weakness statement for BP3 in the application instance: what is missing, the evidence, and the risk.

"Change requests are not consistently approved before implementation: 2 of 10 sampled CRs (the two 'urgent customer fix' CRs) moved from Open to Implemented without CCB approval, and no emergency approval path is defined. The CCB does not include the test lead. Risk: changes reach the product without assessed impact on verification or agreed release scope."

In three sentences, explain to Seat-Heat's manager why SUP.10 got level 1.

Level 2 needs PA 1.1 fully achieved across both instances, and ours aggregates to largely achieved: the application code sometimes skips side-effect analysis and approval, and the platform code has almost no change process. The application team's management setup is good, but it isn't enough while the platform instance pulls every attribute down. Build a real change process for platform code, then close the approval and side-effect gaps, and level 2 is within reach.

You've finished the core course. You can now read the PAM, pick the processes that matter, trace the V, tell level 1 from level 2 from level 3 weaknesses, and reach a rating the way an assessor does. That is the vital 20 %. Lessons 10–13 apply it to automated checks, stage gates and AI-generated work. They matter most if your team builds or uses that kind of tooling. Lessons 14–16 then open each process of the V, if you skipped them after lesson 4.

To keep it: import this lesson's Anki deck (how).

Where to go from here

Deepen per process. For each process you meet in real life, read its PAM pages and then its chapter in the Guidelines (chapter 3 for level 1). The rating rules show where assessors actually look.
Test your judgement against people. An intacs Gate4SPICE event is the lowest-cost way to hear practising assessors reason about ratings.
Revisit in a week. Retake the warm-ups of lessons 2–8 without rereading the lessons. What you can't retrieve is what to review, and spacing is where long-term retention comes from.

Want a second capstone on another process (SUP.8, SWE.1, MAN.3), or to walk through your own team's evidence? Ask your teacher in the chat.