Lesezeit 5 min
Das V-Modell ist wohl eines der meist missverstandenen Konzepte in der Software-Entwicklung, auch in der Entwicklung kritischer Systeme. Zusammen mit dem Wasserfall-Modell, von dem es gewissermassen abstammt, ist es auch die Bête Noire der «agilen» Community.
Ist das gerechtfertigt? Wenn man V-Modell machen «muss», kann man das Modell auch anders sehen und nutzen? Lesen Sie hier meine Meinung zu folgenden Fragen und urteilen Sie selbst:
Was ist das V-Modell?
Es gibt drei wichtige Aspekte des V-Modells:
- Grundsätzlich ist die Idee hinter dem V-Modell die von «divide and conquer», d.h. dass jedes System in kleinere Sub-Systeme aufgeteilt wird, bis dass dieses Teil eine (Anforderungs-)Komplexität hat, die es erlaubt, es zu implementieren. Das heisst auch, dass die Anforderungen auf jeder Stufe so generisch sein sollten, dass sie von einem Ingenieur noch überblickt werden können.
- Diese Aufteilung auf der linken Seite folgt dann die Integration auf der rechten Seite, wo die Teile der unteren Stufe integriert und vor allem auf dieser Stufen gegenüber den Anforderungen dieser Stufe getestet werden.
- Um sicherzustellen, dass alle Anforderungen einer Stufe auf der nächstunteren abgebildet werden, die die vertikale Traceability, jede Anforderung auf meiner Stufe muss mindestens von einer Anforderung auf der nächstunteren Stufe abgedeckt («covered») werden.
Um sicherzustellen, dass auf jeder Stufe alle Anforderungen getestet werden, dient die horizontale Traceabilty, jede Anforderung muss mindestens von einem Test abgedeckt werden.
In der Grafik unten sind es drei Stufen, diese ist die minimale Anzahl in den meisten Sicherheitsstandards. Für kompliziertere Systeme, z.B. ein ganzes Flugzeug können es auch viel mehr sein.
Generisches V-Modell (z.B. DO-178):
Woher kommt das V-Modell?
Das V-Modell hat mehrere Eltern, es wurde fast zeitgleich und unabhängig in den USA und in Deutschland in den frühewn 1980er Jahren entwickelt. Am Anfang, als man noch an fixe und unveränderliche Spezifikationen glaubte, war es als echtes Ablaufmodell gedacht. Teilweise wurde es auch mit Stage-Gate Modellen vermischt, d.h. die nächste Phase kann nur nach einer Freigabe der vorherigen Phase beginnen.
Das Problem ist hier natürlich, dass es immer Feedback Loops gibt, dass man mit Erkenntnissen einer späteren Phase oder Änderungen der übergeordneten Anforderungen die «fertiggestellten» Phasen nochmals wiedereröffnen musste. Daher macht es mehr Sinn, das V-Modell als Daten-Management-Modell anzuschauen, welches eine gewisse Sequenz sinnvoller macht, jedoch diese nicht strikt vorgibt.
Übrigens: das V-Modell gilt auch als «aufgeklappter Wasserfall». Lieder stimmt das so nicht. Das «Waterfall» Paper von Royce beinhaltet zwar auf den ersten zwei Seiten Grafiken, welche die Phasen als reine Sequenz darstellen. Auf den nächsten Seiten ist schnell Schluss damit, der Autor warnt sogar vor einem ölinearen Modell...
Wo wird das V-Modell hauptsächlich eingesetzt?
Das V-Modell wird in folgenden Bereichen genutzt:
- Luftfahrt, z.B. für generelles System Design in ARP-4754 für Sicherheit in ARP-4761 , für Software in DO-178
- Automotive, z.B. für generelle Entwicklung (hauptsächlich jedoch für Software verwendet) in aSPICE
- man beachte, dass diese Inkarnation des V-Modells auch die Architekturen auf der jeweiligen Stufe (z.B. System-Architektur) in die vertikale Traceability aufnimmt und dafür auch «Tests» definiert
- Funktionale Sicherheit, viele Standards schreiben prinzipiell das DO-178 Modell vor, teilweise gibt es auch Mischformen mit Architektur-Dokumenten im V-Modell
Was ist der Nutzen des V-Modells?
- Komplexitätsreduktion: Der Hauptnutzen des V-Modells ist «divide and conquer», d.h. dass sich komplizierte Systeme bzw. deren Anforderungen und Tests so aufteilen lassen, dass sie noch handhabbar sind.
- Dokumentenstruktur: Zusätzlich führt das V-Modell zu einer klaren Dokumentenstruktur von Anforderungen und Architektur, welche Entwicklung und vor allem Wartbarkeit vereinfachen.
- Verfolgbarkeit (Traceability): das Modell erlaubt es, während der Entwicklung und bei der Wartung zu überprüfen:
- Coverage:
- ob alle Anforderungen der höheren Ebene konsistent implementiert sind
- ob alle Anforderungen getestet wurden
- ob keine Dinge implementiert wurden, die gar nicht gefordert sind (d.h. keine falschen Annahmen getroffen wurden)
- Impact: was die Auswirkung einer Änderung an Anforderungen oder Implementation sind («Impact-Analyse»)
- Coverage:
Ohne V-Modell fehlt häufig eine Struktur, oder sie ist nur implizit vorhanden, was bei grossen Systemen zu riesigen «Haufen» von Anforderungen führen kann, welche schwer zu bewältigen sind.
Gesamthaft führt das V-Modell zu eher höheren Aufwänden vorab («Frontloading»), jedoch zu geringeren Aufwänden gegen Schluss der Entwicklung und vor allem bei der Wartung.
«Divide and Conquer» im V-Modell (kein Gantt-Chart mehr):
Wie lässt sich das V-Modell sinnvoll einsetzen?
Auch wenn in vielen Quellen (z.B. V-Modell in Wikipedia) so beschrieben, macht es wenig Sinn, das V-Modell als Gantt-Chart, als Ablaufmodell aufzufassen. Es macht sehr viel mehr Sinn, das V-Modell als Daten-Management Modell, als Dokumentenstruktur zu sehen. Die Kopplung an das Projektmanagment-Modell ist nur lose, die Reihenfolge sollte vor allem von Risikoüberlegungen getrieben sein: zuerst das tun und ausprobieren, das mit den grössten Risiken behaftet ist.
Natürlich gibt das V-Modell eine gewissen natürlich eine sinnvolle Reihenfolge vor, es macht z.B. wenig Sinn Anforderungen auf niedriger Ebene freizugeben, bevor die auf höherer Ebene auch freigegeben sind. Nur sagt niemand, dass man nicht auf einer anderen Stufe etwas anfangen kann, bevor die übergeordnete «fertig» ist.
Häufig ist das Problem nicht das Modell, sondern die Organisation. Wenn derjenige, der das sagen hat (Qualität, Management, Auditor...) das Modell als reines Ablaufmodell versteht, dann kann es schwierig sein ein flexibles Projekt ohne Leerläufe durchzuführen.
Wie sieht die Solcept Implementation des V-Modells aus?
Das V-Modell, welches wir intern benutzen lehnt sich stark an die Luftfahrt an. Wir haben die Architektur- und Designdokumente auch in die Traceability aufgenommen, wegen der Impact-Analyse, nicht der Coverage.
Schnittstellendokumente sind auf jeder Ebene separat von den Architektur bzw. Spezifikationsdokumenten ausgeführt. Damit lassen sich die Schnittstellenanforderungen einfach durch die Ebenen referenzieren (sonst muss man die obersten Schnittstellenanforderungen häufig bis in die unterste Ebene kopieren, was keinen Sinn macht). Man kann so verfahren, da reine Schnittstellenanforderungen ohne die Funktionalität so eh nicht testbar sind.
Tests sind in Testspezifiaktionen und Testinstruktionen aufgeteilt, die letzteren sind bei automatischen Tests der Testcode.
Dieses Modell lässt sich für alle Normen der funktionalen Sicherheit und Security anpassen, für nicht-kritische Systeme werden nicht benötigte Dokumente weggelassen, typischerweise tiefere Level («Tailoring»).
Solcept Dokumentationsmodell (vereinfacht, v.a. Traceability):
Andreas Stucki
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Autor
Keine Kommentare