4 Irrtümer über das V-Modell

Im Artikel zum V-Modell wies ich bereits darauf hin, dass es viele Missverständnisse und Irrtümer dazu gibt. Doch welche sind das konkret? In diesem Artikel gehe ich auf die vier größten Missverständnisse ein. Wenn die im Team aus dem Weg geschafft sind, sind wir schon einen großen Schritt vorangekommen.

Dieser Artikel wurde übrigens von einem englischsprachigen Artikel inspiriert, den ich kürzlich für Jama Software geschrieben habe: The Myth of the V-Model

Eigentlich ist das V-Modell ja simpel: Links oben beginnt es mit den höchsten Anforderungen oder Zielen; Diese werden nach rechts unten immer weiter konkretisiert. Der rechte Arm deckt dann V&V ab, also Verifizierung und Validieren über Tests, Analyse oder Inspektion. Diese Elemente stehen in Beziehung zueinander, was mit Pfeilen symbolisiert wird.

Das V-Modell hat oft eine Zeitachse, von links nach rechts. Wenn wir dies absolut interpretieren, dann haben wir eigentlich den Wasserfall, wobei der rechte untere Teil „nach oben geklappt“ wurde um ein V zu bilden. Außerdem sind Traces hinzugekommen.

Doch die Zeitachse ist ist nicht absolut zu verstehen. Der Wasserfall ist ein linearer Prozess, aber das V-Modell wird iterrativ bis zur Reife entwickelt.

Ja, das V-Modell ist auch ein Prozess, aber nicht nur. Der Prozessanteil ist sogar standardisiert, zum Beispiel im V-Modell, welches in Deutschland eine geschützte Marke ist. Das V-Modell wird von vielen Standards referenziert, wie bspw. ISO/IEC/IEEE 15288.

Doch diese Sicht vernachlässigt, dass das Modell auch aus Elementen und Relationen besteht, also ein ER-Modell ist. Durch diese Sicht kann das Verständnis in einer Art und Weise vertieft werden, was mit der Prozesssicht allein nicht möglich ist. Weiterhin wird in der Prozesssicht oft mit einer anderen Granularität gedacht, also bspw. Anforderungs-„Dokumente“. Die Modellsicht ermöglicht eine feingranulare Sicht, die auf vielerlei Arten genutzt werden kann.

Das V-Modell ist nicht nur für agiles Arbeiten geeignet, sondern (fast) eine Voraussetzung dafür! Denn Agilität akzeptiert Wandel. Aber Wandel kann nur mit einer feingranularen Traceability vernünftig gelebt werden. Eine robuste Traceability spiegelt die dreieckigen Beziehungen zwischen  Anforderungen, Tests und Implementierung wieder.

Mehr dazu schrieb ich bereits in dem Artikel Wie Modellierung agile Systementwicklung ermöglicht.

Wie ich bereits weiter oben schrieb, müssen wir in der Entwicklung im V-Modell hin- und herspringen. Trotzdem ist oft die Annahme, dass die Anforderungen geschrieben werden müssen, bevor die Tests schreiben. Doch so muss man nicht vorgehen.

Das V-Modell ist für Behavior-Driven Development (BDD) geeignet. Bei BDD wird Verhalten in einer testbaren Form festgehalten, bevor am Design gearbeitet wird. Dieser Ansatz ist mit der in der Softwareentwicklung verbreiteten testgetriebenen Entwicklung vergleichbar. Auch hier stellt das V-Modell die Strukturen zur Verfügung, die dieses Vorgehen erst ermöglichen.

Fazit

Das V-Modell ist ein mächtiges Konzept. Allerdings ist es alt, und wurde zu einer Zeit entwickelt, als dokumentenbasiertes Arbeiten die Norm war. Doch es kann auch im moderen Kontext angewendet werden und ermöglicht, bessere Produkte schneller zu entwickeln. Doch dazu muss es verstanden werden.

Photo by Peter Secan on Unsplash
V-Modell Jama Software