Wenn es um sicherheitskritische Systeme geht – besonders im Bereich Automotive – dann sind die Normen und Standards der MISRA The Motor Industry Software Reliability Association maßgebend für die Systementwicklung.

1995 erschien der Report 6 Verification and Validation [MISRA R6 V&V].  Er beschreibt die Aktivitäten, die während der gesamten Softwarelebenszyklus anzuwenden sind und dies jeweils aus Sicht der Rollen

• Director (Manager)
• QA Manager (Qualitätsmanager),
• Project Manager,
• Project Engineer (Mitarbeitende des Projektes, welche nicht (vorwiegend) in der Softwareentwicklung tätig sind),
• Software Manager (Softwareentwicklungsleitung) und
• Software Engineer (Mitarbeitendes, die vorwiegend oder ausschließlich in der Softwareentwicklung tätig sind).

[MISRA R6 V&V] ist keine Norm, aber mit seinen Empfehlungen sicher ein allgemein akzeptierter Standard innerhalb von Automotive. Den darin enthaltenen Empfehlungen ist in Abhängigkeit von (Safety) Integrity Leveln Fogle zu leisten bzw. spiegeln state of the technique wieder und sind damit ein Bestandteil des Produkthaftungsgesetzes.

In nahezu allen Phasen des Software-Lebenszyklus werden Reviews gefordert, damit meint [MISRA R6 V&V] die Prüfung bereits vorhandenen Materials im Gegensatz zur Analyse, die neues Material während dieser Aktivität produziert.

Reviews müssen aktiv eingeplant werden, zum Einen in der Qualitätsplanung aber vor allem in der Planung der Verifikationsaktivitäten (Software Verification Specification), die für jede Phase des Software-Lebenszykluses erfolgen muss.

Appendix N Structured walkthroughs and code inspections

Im Anhang (Appendix N) beschreibt [MISRA R6 V&V] unter der irreführenden Überschrift Walkthroughs unterschiedliche Reviewarten.  Sie setzt dann im Unterkapitel N.1 strukturierte Walkthroughs mit Code-Inspektionenals “general purpose review” gleich. Nach [MISRA R6 V&V] werden Walkthroughs (wie auch alle anderen nachfolgenden Reviewarten) vom Software Manager und vom Software Engineer verantwortet, die optimale Anzahl an Teilnehmenden ist drei bis fünf, wobei einer der Teilnehmenden der Autor selbst sein soll. Dieser ist im Gegensatz zu Code-Reviews (Appendix O) aktiv, während die Inspektoren passiv sind.

Das Vorgehen wird nicht weiter beschrieben, wirklich hilfreich sind einige der möglichen Sichtweisen, die die Teilnehmenden einnehmen können:

• Maintenance representative – Einen Reviewer, der die Sicht eines später für die Wartung Verantwortlichen einnimmt
• Standards bearer – Jemand, der sehr genau auf die Einhaltung von Standards und Normen achtet.
• User representative – Jemand, der die Sichtweise des Endnutzers einnimmt, aber im Falle des Reviews eines Anforderungsdokumentes auch z.B. der Designer sein kann.

Der Walkthrough eines Anforderungsdokumentes ist dann eigenlich ein Widerspruch zur Definition als Synonym zu Code-Inspektion in der [MISRA R6 V&V].

Als weitere Methode werden im Unterkapitel N.2 mit der Überschrift Fagan die Fagan-Inspektion als formale Reviewmethode kurz beschrieben. Hier gibt die [MISRA R6 V&V] zu, dass der Terminus “strukturiertes Walkthrough” eine gewisse Ambiguität in der Sprache sei.

Das Unterkapitel beschreibt kurz die zentralen Eigenschaften (z.B. unabhängiger Moderator, Fehler-Checklisten) und listet die sechs Phasen auf:

• Planning – Planung
• Overview
• Preparation – individuelle Vorbereitung der einzelnen Gutachter
• Inspection – das moderierte Reviewmeeting mit dem eigentlichen Review
• Re-work – die Nacharbeit durch den Autor / Korrekturphase
• Follow up – die Kontrolle der Nacharbeit durch den Moderator und die Erstellung von Statistiken

Das Unterkapitel N.3 Peer reviews ist in der [MISRA R6 V&V] nicht – wie allgemein üblich – ein Sammelbegriff für alle Reviews bei denen Vorgesetzte ausgeschlossen werden (daher Peer), sondern beschreibt ein Form eines vollständig anonymen Reviews, in der mehrere Programmierer (10 bis 20) jeweils untereinander ihren Code austauschen und verschiedene Fragen zur Qualität des Codes mit einem Notensystem bewerten.  Die jeweiligen Autoren erhalten dann die anonymisierten Ergebnisse, um ihre Arbeit zu verbessern. Häufig – so die Ersteller der [MISRA R6 V&V] – würden die Entwickler dabei von vorneherein zwei Varianten zur Begutachtung einreichen, den “best effort” und eine weitere.

Appendix O Code reviews

Unter dem Begriff Code Review versteht der [MISRA R6 V&V] das Lesen des Codes durch einen Reviewer. Auf nahezu einer DIN A4 Seite wird dargestellt, warum die Korrektheit von Programmen hinsichtlich der Umsetzung v.a. hinsichtlich der funktionalen Anforderungen wichtig ist.

In einem Satz wird dann kurz dargestellt, dass der Programm-Reviewer oder das Reviewteam Code Walkthrough oder Fagan inspection wie in Appendix N dargestellt, empfehlen kann.

Der weitere Schwerpunkt dieses Kapitels liegt dann auf den zu prüfenden Merkmalen des Codes:

• Compliance zu den Anforderungen und zur Architektur
• Prüfbarkeit des Codes
• Einhaltung von Standards
• Traceability (Verfolgbarkeit)
• Korrektheit und Konsistenz

Als mögliche Methoden werden im Folgenden zusätzlich die Nutzung von Werkzeugen zur statischen Analyse (Codechecker) und zur formalen Beweisbarkeit genannt.

Fazit

Der [MISRA R6 V&V] beschreibt in seinem Hauptteil sehr hilfreich, wann und wie Verifikations- und Validationsaktivitäten durchgeführt werden sollten. Die Erklärungen der unterschiedlichen Reviewarten im Anhang ist jedoch wenig hilfreich für Einsteiger und in der benutzten Begrifflichkeit verwirrend für Könner. Die Konformität zur IEEE Std. 1028-2008 oder auch zu einer älteren Version sowie zu anderer gängiger Literatur zum Thema  ist nur geringfügig vorhanden.

Deswegen und wegen der zu kurzen Erklärungen im Anhang ist der [MISRA R6 V&V] nicht sehr hilfreich bzgl. der praxisnahen Nutzung von Reviews im Unternehmen.