Qualitätssicherung für die Software im Auto mit Automotive SPICE 3.0

Seite 3: Konsistenz

Inhaltsverzeichnis

In Automotive SPICE® 3.0 werden Traceability, also Verfolgbarkeit, und Konsistenz wie folgt unterschieden: Während Erstere die formale Verknüpfung von Bestandteilen von Arbeitsergebnissen darstellt und immer bidirektional vorhanden sein muss, handelt es sich bei Letzterer um inhaltliche und semantische Zusammenhänge. In allen System- und Software-Engineering-Prozessen werden Verfolgbarkeit und Konsistenz jeweils durch zwei unterschiedliche Base Practices (BP) verlangt. Die Prozesse auf der rechten Seite des V-Modells fordern zusätzlich die bidirektionale Verknüpfung zwischen Testfällen und Testergebnissen. Ein Change Request muss im neuen Automotive SPICE® ebenfalls die bidirektionale Traceability zu all den Dokumentstellen aufweisen, die er beeinflusst (Abb. 7). Damit wird der weitaus wichtigeren Bedeutung der Konsistenz mehr Rechnung getragen als im alten Modell, das eher dazu verleitet hat, eine gute Bewertung schon aufgrund der formal vollständigen Traceability zu vergeben.

Bidirektionale Traceability und Konsistenz (Abb. 7)

(Bild: Automotive SPICE® PAM v3.0, © VDA QMC)

Automotive SPICE® 3.0 verlangt bei System- und Softwarearchitekturen eine Evaluierung alternativer Lösungen (Abb. 8), für die definierte Kriterien vorliegen müssen. Beispiele für solche Merkmale sind Qualitätseigenschaften wie Modularität, Zuverlässigkeit, Sicherheit, Benutzbarkeit oder Ergebnisse von Make-or-Buy-Analysen. Die Evaluierung und die Begründung für eine Architekturentscheidung müssen dokumentiert sein.

Evaluierung, Verifikationskriterien, Compliance und Test (Abb.8)

(Bild: Automotive SPICE® PAM v3.0, © VDA QMC)

Verifikationskriterien werden als Eingabe für das Erstellen von Testfällen oder anderen Verifikationsschritten genutzt, die die Erfüllung der Anforderungen nachweisen. Sie werden nur im Zusammenhang mit SYS.2 und SWE.1 genutzt. Verifikationsaspekte, die kein Test abdecken kann, werden in SUP.2 behandelt. So zeigen zum Beispiel Kriterien zur Unit-Verifikation die Compliance von Source-Code zum detaillierten Softwaredesign beziehungsweise zu nichtfunktionalen Anforderungen. Mögliche Kriterien für die Unit-Verifikation umfassen Testfälle, Testdaten, Überdeckungsmaße, Kodierstandards und -richtlinien, wie beispielsweise MISRA-C (Motor Industry Software Reliability Association).

Für Unit-Tests sollten diese Kriterien in einer Unit-Testspezifikation definiert werden, die in Form eines (automatisierbaren) Skripts für eine definierte Testumgebung vorliegen kann. Integrationstests zeigen die Konformität einer Architektur. Sie untersuchen vor allem die Schnittstellen von Units, Software- und System-Items auf das Erfüllen des Architekturdesigns.