Lesson 15 of 16 · The V, process by process · Automotive SPICE, the vital 20 %

The V at software level: SWE.1 to SWE.6

This is where most of a software team's evidence lives. Whether a person or a coding agent writes the code, each of these six processes asks for something specific, and an assessor knows exactly where to look for it.

In the verification pattern, what comes right after specifying the verification measures?

Which process owns the hardware-software interface (which pins, signals and timing the software sees)?

Three words first: element, component, unit

Software component: what the software architecture decomposes the software into, "down to the lowest-level software components".
Software unit: what the detailed design decomposes a component into; a unit "is decided not to be further subdivided".
Software element: either of them, as something that is integrated.

Source: PAM terminology, p. 10. A unit is first a design idea, not a file or a function: in design, "not an implementation-level term but a logical modeling-level term"[Guidelines p. 145]. In code it may be one subroutine or several[PAM SWE.3.BP1 note 1, p. 48], and once implemented and under verification it is represented by source code files or an object file (PAM p. 10).

The left leg: requirements, architecture, design and code

Process	What it asks for
SWE.1 Software Requirements Analysis	Specify software requirements from the system requirements and architecture, with defined characteristics; structure and prioritise; analyse correctness and feasibility; analyse the impact on the operating environment; trace to the system requirements and the system architecture (one path per requirement, see below); communicate.
SWE.2 Software Architectural Design	Static aspects (components, interfaces, relationships) and dynamic aspects (behaviour, modes, concurrency such as interrupts and threads); analysis, e.g. of timing and resource consumption (RAM, ROM, CPU load), with rationales; trace to the software requirements; communicate.
SWE.3 Software Detailed Design and Unit Construction	For each component, the behaviour of its units, their structure and interfaces, including valid value ranges and physical units such as `0..3.8 [A]`; the interactions between units; units developed to the design and to coding principles; traces from design to architecture, from units to design, and from design to software requirements; communicate.

Source: PAM §4.4.1–4.4.3, pp. 44–50.

Trace one path, not two. A software requirement traces to whichever of system requirement or system architecture fits it. "Redundant traceability is not intended"[PAM SWE.1.BP5 note 9, p. 45], and tracing only one path is not downrated (SWE.1.RL.10)[Guidelines p. 137]. For a software-only supplier, lesson 3's shortcut applies: stakeholder requirements can take the place of system requirements.
Coding principles are a level 1 matter. The PAM's examples are no implicit type conversions, one entry and one exit per subroutine, and range checks[SWE.3.BP3 note 7, p. 49].

A detailed design is not a picture of the code. It says "what each software unit shall do and how it interacts with other units", and it "is not a mere graphical representation of the source code logic"[Guidelines §3.10.1, p. 144]. Who writes the code, a person or a coding agent, is a HOW (lesson 1). What SWE.3 needs is units consistent with a design that says what they should do. Diagrams generated from the code after the fact describe what the code does, so they can't show that. (That last step is this course's inference; the Guidelines have no rule about generated designs.)

The right leg: units, components, the whole software

Process	Verifies	Against
SWE.4 Software Unit Verification	Each software unit, by static analysis, code reviews and unit tests	The detailed design
SWE.5 Software Component Verification and Integration Verification	Each component's behaviour and interfaces; then the integration: data flow, timing, interface interpretation, resource consumption	The architecture (and the detailed design)
SWE.6 Software Verification	The fully integrated software	The software requirements

Source: PAM §4.4.4–4.4.6, pp. 50–57. Each follows lesson 14's five-step pattern, broadly: SWE.5 specifies and performs component and integration verification separately.

Static analysis and reviews count. The PAM's unit verification measures are static analysis, code reviews and unit tests; static analysis "can be done based on MISRA rulesets and other coding standards"[SWE.4.BP1 notes 1–2, p. 50]. Writing units to coding principles is SWE.3; checking that they were is SWE.4.
Test against the design, not the code. What a unit should do comes from the detailed design, so its tests do too. A unit "shall not be verified against the code itself": that "would just prove that the code works as programmed"[Guidelines §3.11.1, p. 154]. Unit tests generated by reading the code, by a person or an agent, fall into exactly this trap (the course's reading of this rule).
Coverage is not the goal. Code coverage is "accompanying information that helps judging completeness" of the chosen tests; "code coverage alone is not a verification objective"[p. 154].
Integrate however you like. Big-bang, continuous integration or stepwise integration are all allowed[PAM SWE.5.BP4 note 6, p. 53], and software-in-the-loop simulation can support integration verification (SWE.5.BP1 note 2).
Check the test code. As at system level, an automated measure whose definition doesn't address the correctness, completeness and consistency of its scripts means BP1 shall be downrated, or for SWE.5 BP1 or BP2 (SWE.4.RL.2, SWE.5.RL.2, SWE.6.RL.2)[Guidelines pp. 157, 159–161].

Generated code has its own rule in the Guidelines' section on model-based development: without evidence that auto-generated code complies with the detailed design, SWE.3.BP4 "shall not be rated higher than P" (MBD.RL.5)[Guidelines §2.5.1, p. 75]. It was written for code generators, not agents, but it shows what assessors expect: evidence that generated output matches the design.

Practice: Seat-Heat's software

A. Which process?

The temperature-conversion unit's interface: input 0..5 [V], output −40..125 [°C].

Static analysis with a MISRA ruleset runs on every pull request.

A software-in-the-loop test checks that the sensor component hands a new temperature to the control component within 10 ms.

Boundary-value tests of the requirement "accept heat levels 0 to 3 from LIN" on the fully integrated software.

A spreadsheet estimates each component's RAM and CPU load, with the reasons for putting the PWM control on a timer interrupt.

B. Acceptable, or a weakness?

An agent writes unit tests by reading each function's source code. All pass, with 100 % line coverage.

Software requirements trace to the system architecture, but not also to the system requirements.

At release end, an agent generates class diagrams from the code and files them as the detailed design.

There is no staged integration plan: every merge builds the whole software, and CI runs the selected integration tests on it.

Software requirements are tagged "functional" or "non-functional", and that is their only structure.

C. From memory

Why must unit verification be derived from the detailed design and not from the code?

Because verifying code against itself only proves it works as programmed. SWE.4 checks units against what the detailed design says they should do, which is the only way to catch a unit that faithfully implements the wrong thing.

What does each of SWE.4, SWE.5 and SWE.6 verify, and against what?

SWE.4: software units, against the detailed design. SWE.5: components and their integration, against the architecture (and the detailed design). SWE.6: the integrated software, against the software requirements.

Your win: you can say what each software process asks for, spot the verification that only proves the code works as programmed, and set up agent-written code and tests so the evidence holds. Next: the one process that asks whether the product is the right one.

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