Each of these SWEs is broken down in the standard to a number of base practices (BPs). For example, the base practices associated with software unit verification are shown in Figure 9

Figure 9: Base practices associated with software unit verification, as represented in the LDRA tool suite

Clearly the level of thoroughness and expertise applied to each of these activities can vary enormously, and with it the level of quality assurance. Take, as a further example, the testing of software units (BP4). The standard expands that a little “Test software units using the unit test specification according to the software unit verification strategy. Record the test results and logs.”The standard provides for the assessment of capability levels associated with each of these base processes (Figure 10).

Figure 10: Capability levels in ASPICE

Any assessment of compliance will look to confirm the completeness of that test specification and the effectiveness of adherence to it in order to assess an appropriate capability level, but outside that remit there are decisions to be made relating to the rigour applied to each activity.

The thoroughness of unit test, for example, can vary considerably.

At its most rudimentary level, unit test can consist of the superficial confirmation that each software function fulfils its functional specification.
A more thorough test would include evidence of code coverage, showing that all code relates to a requirement and that all requirements are fulfilled by code.
Beyond that, the robustness of the code might be exercised to show that boundary and out of range values are handled adequately by the code.
Ultimately, object code verification might be deployed to provide evidence that the object code, like the source code, is also shown to be both pertinent and thoroughly exercised.

Figure 11: Examples of representations of function and call coverage within the LDRA tool suite

Clearly, the more demanding tests would likely apply to a braking system and only the lesser ones to in-car entertainment. Functional safety issues of this nature are outside the remit of Automotive Spice, but within the scope of the standard ISO 26262 Second Edition “Road vehicles — Functional safety” which might be considered complementary to it.

Base practices, process attributes, and functional safety