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

The VDA Scope: the processes that get assessed

The PRM has 32 processes. A standard assessment looks at about a dozen of them. This is the biggest 80/20 cut in the whole course: learn these well and skim the rest.

PA 1.1 is a judgement about which part of a process description?

Seat-Heat keeps change requests only as Jira tickets. Does the assessor need a separate change request document?

Base plus plug-in

The VDA Guidelines recommend a standard selection of processes, the recommended VDA Scope[Guidelines §1.3.2, Fig. 1-1, p. 29]:

Part	Processes
Base	MAN.3 Project Management · SUP.1 Quality Assurance · SUP.8 Configuration Management · SUP.9 Problem Resolution Management · SUP.10 Change Request Management
+ at least one plug-in	System SYS.2–SYS.5 · Software SWE.1–SWE.6 · Hardware HWE.1–HWE.4 · Machine learning MLE.1–MLE.4 + SUP.11
Flex / optional	ACQ.4 Supplier Monitoring · MAN.5 Risk Management · MAN.6 Measurement · SYS.1 Requirements Elicitation · VAL.1 Validation · SPL.2 Product Release · PIM.3 Process Improvement · REU.2 Management of Products for Reuse

This follows the PAM's "plug-in" concept: the system V sits at the top, domain disciplines such as software and hardware engineering plug in beneath it, and management and support processes are domain-independent, applying at every level[PAM Annex C.1, p. 153]; for choosing a scope, the Guidelines count the system processes SYS.2–SYS.5 as one plug-in among four and leave SYS.1 in the flex set[Guidelines Fig. 1-1, p. 29].

Three scoping rules worth knowing[Guidelines pp. 29–30]:

Deviating from the recommended scope needs a documented rationale tied to the assessment purpose.
A process may not be declared "not applicable" without the sponsor's approval.
"A simple non-existence of evidence shall not be a valid justification of an exclusion": if the team simply does not do it, the usual result is an N.

For Seat-Heat, a software-only supplier, the scope is the five base processes plus the software plug-in, SWE.1 to SWE.6: eleven processes. Where there is no system development, the "system requirements and architecture" the SWE processes refer to are simply the given operating environment, and stakeholder requirements can be used as their basis. Consistency and bidirectional traceability can then be ensured between stakeholder requirements and software requirements[PAM SWE.1.BP1 note 3, p. 44; SWE.1.BP5 note 12, p. 45].

The eleven, one line each

ID	In a sentence
MAN.3	Identify and control the activities and resources the project needs.
SUP.1	Independent and objective assurance that work products and processes meet the defined criteria, and that non-conformances are resolved.
SUP.8	Establish and maintain the integrity of configuration items and baselines, and make them available.
SUP.9	Problems are identified, recorded, analysed, and their resolution managed.
SUP.10	Change requests are recorded, analysed, tracked, approved and implemented.
SWE.1	Software requirements, structured and analysed, consistent with system requirements and architecture.
SWE.2	Software architecture (static and dynamic), consistent with the software requirements.
SWE.3	Detailed design consistent with the architecture, and units built consistent with the design.
SWE.4	Verify that units are consistent with the detailed design.
SWE.5	Verify components against the architecture; integrate and verify the integration.
SWE.6	Verify the integrated software against the software requirements.

Paraphrased from the purpose statements in PAM chapter 4: SWE pp. 44–57, SUP pp. 79–86, MAN.3 p. 89.

The two pairs people confuse

SUP.9 vs SUP.10. A problem is something wrong: a failed test, a field defect, a broken tool. A change request is a request to change a work product, and it may be triggered by a problem, a new customer wish, or anything else. SUP.9 analyses causes and tracks problems to closure. SUP.10 analyses impact, approves before implementation, and keeps bidirectional traceability between the request and the work products it touches[pp. 83–86]. When a problem leads to a change, the two records must trace to each other (SUP.10.BP4).

SUP.1 vs review. A peer review of a pull request is verification by a colleague. SUP.1 is quality assurance, which must be performed "without conflicts of interest", and "no self-monitoring" is the example the PAM gives[SUP.1.BP1 note 1, p. 79]. A team checking its own compliance does not satisfy SUP.1 on its own.

Practice

A. Which process?

A tester finds the seat heats past the limit when the voltage drops. It's logged with steps to reproduce.

The OEM asks for a fourth heat level in the next release.

Tagging release 2.3.0 and proving which requirement, code and test versions it contains.

A hardware-in-the-loop (HIL) test suite that checks each software requirement on the fully integrated build.

Unit tests in CI for the PWM duty-cycle software unit.

Someone from the quality department audits whether the team's PRs follow the review checklist.

B. Scoping calls

Seat-Heat has no QA function at all. The team asks to mark SUP.1 "not applicable". Without sponsor approval, what happens?

Which plug-in fits a team that develops only software, on hardware supplied to it?

C. From memory

List the five base processes of the recommended VDA Scope.

MAN.3 Project Management, SUP.1 Quality Assurance, SUP.8 Configuration Management, SUP.9 Problem Resolution Management, SUP.10 Change Request Management. Plus at least one plug-in.

In one sentence each: what does SUP.9 manage, and what does SUP.10 manage?

SUP.9 manages problems (something is wrong: find the cause, track it to closure). SUP.10 manages change requests (a change is wanted: analyse its impact, approve it before implementing, trace it both ways to the work products it touches).

Your win: you know which dozen processes decide an assessment, and you can place a piece of daily work in the right one. Next: the one idea that runs through every engineering process, consistency and traceability.

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