Vorgehensmodelle / V-Modell

Vorgehensmodelle

V-Modell

Das V-Modell ist wie das Wasserfallmodell ein klassisches, lineares Vorgehensmodell, mit einem entscheidenden Unterschied: Es stellt jeder Entwicklungsphase von Anfang an eine passende Testphase gegenüber, statt Tests erst am Ende zu bündeln. Grafisch entsteht daraus die namensgebende V-Form. Der linke, absteigende Ast führt von groben Anforderungen zu immer feineren Entwürfen, der rechte, aufsteigende Ast prüft jede dieser Ebenen anschließend gegen die passende Testphase.

Herkunft

Das V-Modell entstand Ende der 1980er- und Anfang der 1990er-Jahre in Deutschland, ursprünglich als Vorgehensstandard für IT-Projekte der Bundeswehr (V-Modell 92). 1997 wurde es zum allgemeinen Vorgehensmodell für die öffentliche Verwaltung weiterentwickelt (V-Modell 97). Die heute gültige Fassung, das V-Modell XT (für „eXtreme Tailoring“), stammt aus dem Jahr 2004/2005 und ist bis heute der verbindliche Vorgehensstandard für IT-Projekte des deutschen Bundes. Anders als das eher generisch gehaltene Wasserfallmodell ist das V-Modell damit ein sehr konkret ausgearbeiteter Standard, mit definierten Rollen, Dokumenten und Projekttypen.

Aufbau: Entwicklung trifft Verifikation

Der linke Ast des V gliedert sich in zunehmend detailliertere Entwicklungsebenen, etwa Anforderungsanalyse, Systementwurf, Architekturentwurf und Komponentenspezifikation. Am tiefsten Punkt des V steht die eigentliche Implementierung. Von dort aus geht es den rechten Ast wieder aufwärts, mit Testebenen, die jeweils exakt zu einer Ebene auf der linken Seite passen: Komponententest zur Komponentenspezifikation, Integrationstest zum Systementwurf, Systemtest zur Anforderungsanalyse. Diese Zuordnung heißt Verifikation und Validierung (V&V) und ist der eigentliche Kerngedanke des Modells: Für jedes Spezifikationsdokument steht von Beginn an fest, wie und wogegen es später geprüft wird, statt Prüfkriterien erst im Nachhinein zu entwickeln.

V-Modell XT: mehr als nur Struktur

Das V-Modell XT geht über die reine Phasenpaarung hinaus. Es definiert feste Rollen wie Auftraggeber, Auftragnehmer, Projektleitung und Qualitätssicherung, unterschiedliche Projekttypen für verschiedene Vertragskonstellationen und ein sogenanntes Tailoring: Nicht jedes Projekt muss jedes vorgesehene Dokument oder jede Rolle tatsächlich besetzen, der Standard lässt sich je nach Projektgröße und -art skalieren. Dieses Tailoring soll dem häufigen Vorwurf begegnen, das Modell sei zu schwergewichtig für kleinere Vorhaben.

Wann das V-Modell passt

  • Öffentliche IT-Projekte in Deutschland: Für Vorhaben des Bundes ist das V-Modell XT häufig vertraglich vorgeschrieben.
  • Sicherheitskritische oder stark regulierte Systeme: Wo lückenlose Nachvollziehbarkeit zwischen Anforderung und Testfall gefordert ist.
  • Projekte mit mehreren Vertragsparteien: Wo klare Rollen, Verantwortlichkeiten und Abnahmekriterien zwischen Auftraggeber und Auftragnehmer wichtig sind.

Grenzen

Trotz des Tailorings gilt das V-Modell XT als dokumentations- und rollenintensiv, was bei kleinen oder explorativen Projekten schnell mehr Aufwand als Nutzen erzeugt. Wie beim Wasserfallmodell bleibt der grundsätzliche Ablauf zudem linear: Änderungen an einer bereits abgeschlossenen Ebene sind im Modell nicht vorgesehen, auch wenn die gepaarten Testphasen Fehler tendenziell früher aufdecken als im reinen Wasserfallmodell, weil Prüfkriterien von Anfang an feststehen statt erst am Ende formuliert zu werden.

Verwandte Modelle

Das Wasserfallmodell teilt mit dem V-Modell die lineare Grundstruktur, ohne dessen feste Zuordnung von Entwicklungs- und Testebenen. Die Idee, unterschiedliche Testebenen bewusst zu unterscheiden, findet sich in modernerer Form auch in der Testpyramide, dort allerdings bezogen auf automatisierte Tests innerhalb der Entwicklung, nicht auf ein ganzes Vorgehensmodell.