Das V-Modell: Phasen, Stärken und wann es agil schlägt

Das V-Modell ist ein sequenzieller Entwicklungszyklus, in dem jeder Spezifikationsstufe des absteigenden Astes eine Teststufe des aufsteigenden Astes gegenübersteht. Als V gezeichnet, legt es beim Abstieg fest, was gebaut wird, und weist beim Aufstieg nach, dass es korrekt gebaut wurde. Es ist eine Verfeinerung des Wasserfallmodells, keine Alternative dazu.

Der absteigende Ast

Anforderungsanalyse, funktionale Spezifikation, Architekturentwurf, Feinentwurf: Jede Stufe präzisiert die vorherige und erzeugt ein Dokument, das einer Teststufe als Referenz dient. Genau darin liegt die Disziplin des Modells — man spezifiziert keine Stufe, ohne bereits zu wissen, wie sie geprüft wird.

Der aufsteigende Ast

Modultests bestätigen den Feinentwurf, Integrationstests die Architektur, Systemtests die funktionale Spezifikation und die Abnahme die ursprünglichen Anforderungen. Jeder Test antwortet auf ein Dokument der gegenüberliegenden Seite des V, was die Abdeckung nachvollziehbar und prüfbar macht.

Stärken und Grenzen

Das V-Modell ist stark, wo Anforderungen stabil sind und Nachweise gefordert werden: regulierte Branchen, eingebettete Systeme, kritische oder vertragliche Lieferungen. Seine Grenze ist symmetrisch — eine im aufsteigenden Ast entdeckte Änderung ist teuer, weil sie Monate zuvor erstellte Dokumente entwertet. Es setzt voraus, dass man wissen kann, was man will, bevor man es gesehen hat.

Zwischen V, Wasserfall und agil wählen

Das echte Kriterium ist nicht die Mode, sondern die Volatilität der Anforderung und der Preis einer späten Änderung. Stabile, vertragliche, zertifizierbare Anforderungen sprechen für ein V-Modell; ein exploratives Produkt, dessen Nutzer den Bedarf im Gebrauch entdeckt, spricht für iterative Lieferung. Die meisten Organisationen praktizieren am Ende beides, mitunter innerhalb eines Programms: eine Validierungsphase im V, ein Produktinkrement in Sprints.

Beides im selben Portfolio steuern

FoxPlan schreibt keine einzelne Methode vor: Ein Projekt kann als Gantt-Plan mit Phasen, Meilensteinen und Abhängigkeiten geplant oder auf einem Kanban-Board verfolgt werden — beides speist dieselbe Ressourcenauslastung, dasselbe Budget und dasselbe Portfolio-Reporting. Die Methode bleibt eine Projektentscheidung, die Konsolidierung bleibt global.