Wie kann der V-Modell-Ablauf iterationsfrei definiert werden?

1. Einleitung

Funktionale Sicherheitsnormen setzen voraus, dass die Entwicklung eines sicherheitsbezogenen oder sicherheitskritischen Produkts nach dem V-Modell erfolgt. Abb. 1 zeigt dieses V-Modell in der Form, wie es der autoConform®-Methodik und der autoConform®-Software zugrunde liegt.

Abb. 1: Systementwicklungs-V-Modell der autoConform®-Methodik und -Software

In diesem Beitrag geht es darum, wie Inhalte und Reihenfolge der Arbeitsprodukte (d.h. der Dokumente) des V-Modells so definiert werden können, dass eine iterationsfreie Erstellung aller Arbeitsprodukte möglich ist.

Ein iterationsfreier V-Modell-Ablauf hat zwei entscheidende Vorteile.

1. Die initiale Befüllung aller Arbeitsprodukte des V-Modells kann in einem iterationsfreien V-Modell deutlich schneller erfolgen als in einem V-Modell, das nicht iterationsfrei ist.
2. Eine Produktdesignänderung oder -korrektur, die in einem bestimmten Arbeitsprodukt des V-Modells vorgenommen wird, kann in einem iterationsfreien V-Modell nur Auswirkungen auf nachfolgende Arbeitsprodukte haben. Auf Basis der Verknüpfungen („Traces“) zwischen den Inhalten voneinander abhängiger Arbeitsprodukte können diese Auswirkungen sehr schnell vollumfänglich ermittelt werden.

Mit anderen Worten:

1. Eine Produktentwicklung nach einem iterationsfreien V-Modell ist deutlich schneller als eine Produktentwicklung nach einem nicht iterationsfreien V-Modell.
2. Die normativ geforderte „Impact Analysis“

• bei Modifikation eines sicherheitskritischen Produkts oder
• bei Verwendung eines sicherheitskritischen Produkts in einem anderen Kontext

ist deutlich leichter durchzuführen, wenn die produktentwicklungsbegleitenden Dokumente einem iterationsfreien V-Modell folgen.

Abschnitt 2 beschreibt den iterationsfreien V-Modell-Ablauf. Abschnitt 3 fasst die Voraussetzungen für einen iterationsfreien V-Modell-Ablauf zusammen.

2. Iterationsfreier V-Modell-Ablauf

Der iterationsfreie V-Modell-Ablauf ist in Abb. 2 dargestellt.

Abb. 2: Iterationsfreier V-Modell-Ablauf

 Abb. 2 stellt den V-Modell-Ablauf für ein Produkt dar, dessen Produktarchitektur aus

• einer Systemebene
• n Subsystemebenen (von denen die letzte die E/E-Hardwareebene ist) und
• 2 Softwareebenen

besteht. Abb. 2 zeigt damit, dass es in einer Produktarchitektur grundsätzlich beliebig viele System-, Hardware- und Softwareebenen geben kann. Im einfachsten Fall enthält die Produktarchitektur eines elektronischen Produkts mit eingebetteter Software nur eine E/E-Hardwareebene und zwei Softwareebenen (nämlich die Gesamtsoftware-Ebene und eine Softwaredetaildesign-Ebene). Alle weiteren System-, Hardware- und Softwareebenen kann es geben, muss es aber nicht geben.

In Abb. 2 ist der Arbeitsablauf mit grünen Pfeilen dargestellt. Der V-Modell-Ablauf beginnt links oben beim Arbeitsprodukt „Item Definition“ und dem Arbeitsprodukt „External System Interface Specification“. Diese beiden Arbeitsprodukte stehen in engem Zusammenhang miteinander und sollten zusammen erstellt werden.

Ähnliches gilt für die Sicherheitsanalysen „(A)SIL-Allokation“, „FTA“, „DFMEA“ und „DFA“ auf jeder Produktarchitekturebene und den aus diesen Analysen erstellen Sicherheitsanforde-rungen: auch diese Arbeitsprodukte stehen in engem Zusammenhang miteinander und sollten deshalb zusammen erstellt werden.

In Abb. 2 gibt es bidirektionale Pfeile nur zwischen

• den Design- und Interface-Spezifikationen (ganz links) und
• den Sicherheitsanalysen (in der zweiten Block-Spalte von links).

Diese Darstellung trägt der Tatsache Rechnung, dass

• die Sicherheitsanalysen (in der zweiten Block-Spalte von links) die Informationen aus den Design- und Interface-Spezifikationen (ganz links) benötigen und andererseits
• Informationen wie das „(Automotive) Safety Integrity Level“, kurz „(A)SIL“, erst mit den Analysen „Hazard Analysis and Risk Assessment“ sowie „ASIL Allocation“ ermittelt und anschließend in die Design- und Interface-Spezifikationen eingetragen werden.

Aus Abb. 2 ergibt sich kein eindeutiger iterationsfreier Ablauf. Es ist (theoretisch) möglich, zuerst die Blockspalte ganz links (Design- und Interface-Spezifikationen) in Abb. 2 von oben nach unten zu bearbeiten, anschließend die zweite Blockspalte von links (Sicherheitsanalysen) von oben nach unten, danach die dritte Blockspalte (Anforderungen) von oben nach unten und schließlich die vierte Blockspalte (Testspezifikationen).

Der übliche und präferierte Ablauf ist aber der von links nach rechts, Ebene für Ebene, beginnend bei der obersten Ebene.

3. Voraussetzungen für ein iterationsfreies V-Modell

Nach einem iterationsfreien V-Modell kann immer dann gearbeitet werden, wenn sich alle Anforderungs-, Design- und Test-Spezifikationen auf eine hierarchisch Produktarchitektur beziehen können, in der alle physischen Hardware- und Softwareelemente und ihre jeweiligen Funktionen durch Dekomposition von oben nach unten definiert wurden.

Die erwarteten Inhalte jedes Arbeitsprodukts müssen ferner so definiert sein, dass sie nur Inhalte voraussetzen, die in einem der vorgelagerten Arbeitsprodukte enthalten oder definiert sind.

Die Arbeitsprodukt-Templates der autoConform®-Methodik und -Software sind so gestaltet, dass sie diese beiden Voraussetzungen erfüllen. Der iterationsfreie V-Modell-Ablauf ist einer der wesentlichen Schlüssel, um den Produktentwicklungsprozess wesentlich zu beschleunigen.