Das mit dem V-Modell ist so eine Sache: Im Systems Engineering wird davon ausgegangen, dass jeder es kennt, und daher wird es selten erklärt. Und dadurch schleichen sich schnell Missverständnisse ein. Ziel in diesem Artikel ist es, das V-Modell nach bestem Wissen und Gewissen zu erklären.
Welches V-Modell?
Gerade in Deutschland muss man aufpassen: Denn es gibt das V-Modell 97 und V-Modell XT. Hierbei handelt es sich um Entwicklungsstandards für IT-Projekte, und wird für öffentliche Ausschreibungen eingefordert. Im Systems Engineering-Umfeld sind diese in der Regeln icht gemeint, wenn vom V-Modell die Rede ist. Zum einen geht es hier um Entwicklungsprozesse, und zum anderen im Software-, nicht Systementwicklungen. Die Einleitung des englischsprachigen Wikipedia-Artikels geht ebenfalls konkret auf die möglichen Missverständnisse ein.
Warum das V-Modell gebraucht wurde
Das heutige V-Modell wurde 1991 von Kevin Forsberg und Harold Mooz in dem Paper „The Relationship of System Engineering to the Project Cycle„vorgestellt. Das Ziel des Modells ist es, die technischen Aspekte im Projektlebenszyklus sauber darzustellen und die Verantwortlichkeit des Systems Engineers zu klären. Bis dahin gab es Modelle, wie „Wasserfall“ und „Spirale“, die jedoch oft von den Teams als praxisfremd und nicht hilfreich abgelehnt wurden. Forsberg und Mooz wollten hier eine Alternative schaffen, was ihnen auch gelungen ist.
V-Modell oder Vee-Modell? Im englischsprachigen Artikel von Forsberg und Mooz wird das Modell mit „Vee“ bezeichnet, aber in der Literatur ist oft „V“ zu finden.
Natürlich gab es Varianten des V-Modells schon vorher. Insbesondere in der Raumfahrt wurde von der NASA bereits ein ähnliches Modell entwickelt, das dann aber von Forsberg und Mooz verfeinert wurde.
Das V-Modell im Systems Engineering
Doch nun zum eigentlichen Inhalt. Im Bild oben ist das V-Modell zu sehen. Was oft vergessen wird: Das V-Modell hat drei Dimensionen: Neben den zwei Koordinaten in der Papierebene gibt es noch eine dritte. Doch dazu später mehr.
Schauen wir uns die wichtigsten Aspekte des V an. Dabei kann man sich vorstellen, dass verschiedene Artefakte der Entwicklung auf dem V positioniert werden. Je nachdem wie einfach oder komplex das zu entwickelte System ist, werden nur wenige, oder sehr viele Artefakte benötigt. Allerdings sind sechs üblich, die sich zumindest in der Form von sechs Baselines und formalen Reviews manifestieren. Recht bekannt (und gefürchtet) ist beispielsweise der Critical Design Review (CDR). Dabei haben die Teile des V grundsätzlich die folgende Bedeutung:
- Links oben beginnt die Entwicklung mit den Anforderungen des zu entwickelnden Systems
- Der linke Arm reichert die Anforderungen mit lösungsspezifischen Informationen wie Architektur und Design an. Je weiter man nach unten kommt, desto näher kommt man zur Implementierung.
- In der Mitte unten, an der Spitze des V, ist das Ergebnis zu finden, also das fertige Produkt.
- Der rechte Arm des V deckt die Ergebnisse der Verifizierung und Validierung (V&V) ab.
Bei dieser Sichtweise ergibt sich auch eine natürliche Richtung, von links oben nach unten und zurück nach rechts oben. Dabei ist wichtig nicht zu vergessen, dass dies nicht eine zeitliche Abfolge darstellt. Der linke Schenkel stellt eine Abhängigkeit der Artefakte zueinander dar: Wenn sich weit unten (Implementierungsnah) etwas ändert, so hat dies in der Regel keine Auswirkungen auf die Anforderungen. Umgekehrt kann eine Änderung der Anforderungen jedoch große Auswirkungen auf die Implementierung haben.
Die natürliche Richtung des V stellt nicht eine zeitliche Abfolge dar.
Beim rechten Schenkel geht die Abhängigkeit in die andere Richtung: Unten sind elementare Tests (wie Unit-Tests), während ganz oben Akzeptanztests sind, und dazwischen Dinge wie Integrationstests. Wenn ein Unit-Test nicht durchläuft, dann macht es bspw. wenig Sinn, Akzeptanztests durchzuführen.
Allerdings müssen wir auf der rechten Seite zwischen „Test erstellen“ und „Test durchführen“ unterscheiden. Selbstverständlich kann ein Akzeptanztest bereits erstellt werden, wenn die Anforderungen stehen. Er kann nur nicht durchgeführt werden, bevor das gesamte System entwickelt ist. Da die V&V-Aktivitäten rechts sich auf die Artefakte der selben Ebene links beziehen, wird dies oft über horizontale Pfeile visualisiert.
Die dritte Dimension
Der Artikel von Forsberg und Mooz führt eine dritte Dimension ein, die „in das Papier hinein“ geht und sich aus Configuration Items (CI) zusammensetzt. Damit soll ausgedrückt werden, dass im Rahmen der Detaillierung eines Systems dieses in weitere Untersysteme zerlegt wird. Hier findet sich ganz klar der Systems Engineering-Gedanke von Dekomposition und Schnittstellen wieder.
Kritik
Ich halte das V-Modell für ein sehr mächtiges Werkzeug, um präzise über Systems Engineering reden zu können. Natürlich gibt es auch Kritik, berechtigt oder nicht. Interessant ist der Artikel The seductive and dangerous V Model. Auch in diesem Artikel wird wieder darauf hingewiesen, dass es viele „V-Modelle“ gibt, die teilweise eine sehr unterschiedliche Bedeutung haben (auch dort wird das deutsche V-Modell XT wieder erwähnt). Aber die Hauptkritik ist letzten Endes, dass das V-Modell zu vage ist und dem Wasserfall-Modell indirekt Glaubwürdigkeit verleiht, also dem linearen Entwicklungsweg von Anforderungen zum Ergebnis (der linke Teil im V). Dem stimme ich zwar zu, aber wie bereits gesagt, dies ist im V-Modell eigentlich nicht als linearer Ablauf gedacht. Insofern sehe ich das V-Modell eher als ein Referenzmodell, das die Kommunikation erheblich erleichtert. Um es mit Leben zu füllen gibt es viele Ansätze, von denen einige auch in dem eben genannten Artikel vorgestellt werden.
Kann agil nach dem V-Modell entwickelt werden? Aber selbstverständlich!
Gerade in den letzten Jahren ist das Thema Agilität in aller Munde. Eine wichtige Frage ist daher, ob das V-Modell kompatibel mit agilen Entwicklungsansätzen ist. Dazu hatte ich mich bereits mit einem klaren „Ja“ geäußert. Dort ging es zwar um Systems Engineering (und nicht das V-Modell), doch die Folgerung ist die selbe. Das V-Modell beschreibt Artefakte und deren Relationen. Um zu diesen Artefakten zu kommen gibt es viele Wege. Das V-Modell ist eine Landkarte, die mit den verschiedensten Ansätzen helfen kann, nicht die Orientierung zu verlieren.
Bildquelle: Wikipedia
