Das V-Modell: Zu jedem Entwurf gehört ein Test

Das V-Modell: Zu jedem Entwurf gehört ein Test

https://bildung.social/@oerinformatik/

https://oer-informatik.de/v-modell

V-Modell, V-Modell XT, Vorgehensmodelle, Verifikation und Validierung, Teststufen, Abnahmetest, Systemtest, Integrationstest, Komponententest, Tailoring, Qualitätssicherung

tl/dr; (ca. 13 min Lesezeit): Das V-Modell ordnet jeder Entwurfsphase eine Teststufe auf gleicher Höhe zu: Wer die Anforderungen schreibt, legt gleich fest, wie die Abnahme sie prüft. Der Artikel erklärt Aufbau und Verlaufsrichtungen des V-Modells, die Dokumente jeder Phase, Verifikation und Validierung, Rollen und Planung sowie kurz das V-Modell XT des Bundes mit Tailoring, Vorgehensbausteinen und Entscheidungspunkten [AI-Assisted]. (Zuletzt geändert am 30.10.2026)

Disclaimer: Teile des Textes stammen von einer KI. Inhalte sind nicht automatisch zuverlässig; überprüfe Fakten und zitiere vertrauenswürdige Quellen.

Dieser Artikel ist Teil einer Artikelreihe über Vorgehensmodelle: Überblick: klassisch und agil / Wasserfallmodell / V-Modell / Spiralmodell / Scrum / Extreme Programming / Kanban / SAFe / DevOps / Übungsaufgaben

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

In einem Satz: Das V-Modell zeichnet sich dadurch aus, dass jeder Spezifikations- und Entwurfsphase eine Teststufe gegenübersteht, deren Testfälle schon beim Entwurf festgelegt werden, sodass die Qualitätssicherung von Anfang an mitgeplant ist.

Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells. Die Phasen werden nicht als Treppe, sondern in Form eines „V“ angeordnet:

Herkunft: vom Verteidigungsministerium zum Bundesstandard

Die V-förmige Darstellung von Entwurf und Test findet sich schon Ende der 1970er Jahre in der US-amerikanischen Softwaretechnik (u. a. bei Barry Boehm, 1979). In Deutschland wurde das V-Modell ab 1986 im Auftrag des Bundesministeriums der Verteidigung entwickelt und 1992 für die Bundesverwaltung übernommen; das V-Modell 97 wurde zum verbindlichen Standard für IT-Projekte des Bundes. 2005 folgte das V-Modell XT (eXtreme Tailoring), das vom Bund herausgegeben und u. a. mit dem Verein WEIT e. V. weiterentwickelt wird (Version 2.3 von 2019, bereitgestellt vom ITZBund). Ziel des Modells ist, Anforderungen, Entwurf und Prüfung lückenlos miteinander zu verbinden und Projekte zwischen Auftraggebenden und Auftragnehmenden nachweisbar zu steuern. Typische Einsatzbereiche sind Projekte öffentlicher Auftraggeber sowie sicherheitskritische und hardwarenahe Systeme.

Grundprinzipien: Entwurf und Test gehören zusammen

• Symmetrie: Jeder Testphase rechts steht eine Entwurfsphase links auf gleicher Höhe gegenüber.

• Frühe Testplanung: Testfälle und Prüfkriterien werden schon beim Entwurf festgelegt: Wer die Anforderungen schreibt, legt gleich fest, wie die Abnahme sie prüft.

• Zerlegen und Zusammensetzen: Der linke Ast zerlegt das System schrittweise (top-down), der rechte setzt es wieder zusammen und prüft auf jeder Ebene (bottom-up).

• Verifikation und Validierung als getrennte Prüffragen (siehe unten).

• Dokumentengetrieben: Jede Phase endet mit einem prüfbaren Dokument.

Das Besondere am V-Modell ist also nicht die Reihenfolge – die ist wie beim Wasserfall –, sondern die feste Kopplung jeder Entwurfsebene an eine Prüfebene.

Ablauf: linker Ast, Spitze, rechter Ast

• Der linke Ast führt von oben nach unten durch Spezifikation und Entwurf. Das System wird schrittweise zerlegt und immer genauer beschrieben.

• An der Spitze unten steht die Implementierung.

• Der rechte Ast führt von unten nach oben durch Integration und Test. Die Teile werden zusammengesetzt und auf jeder Ebene geprüft.

Die Benennung der Phasen unterscheidet sich je nach Quelle (z. B. „Grobentwurf“ statt Systementwurf, „Feinentwurf“ statt Komponentenentwurf, „Modultest“ statt Komponententest). Architekturen werden häufig nur bei wirklich großen Projekten individuell entworfen – oft gibt die Wahl eines bestimmten Frameworks hier bereits sehr viel vor. Begegnen Dir Phasen unter anderen Namen, hilft beim Einordnen die Frage: Was wird hier beschrieben, und welcher Test prüft genau das?

Verlaufsrichtungen im V-Modell

• Phase erfolgreich abgeschlossen: Links geht es abwärts in die nächste Entwurfsphase, nach der Implementierung rechts aufwärts in die nächste Testphase.

• Test nicht bestanden: Es geht waagerecht zurück zur gegenüberliegenden Entwurfsphase. Fällt der Integrationstest durch, wird der Systementwurf (Schnittstellen, Architektur) überarbeitet; danach wird der Weg erneut abwärts und wieder aufwärts durchlaufen.

• Testfälle festlegen: Die gepunkteten Pfeile im Bild zeigen, dass jede Entwurfsphase die Testfälle der gegenüberliegenden Teststufe liefert.

Das folgende Aktivitätsdiagramm zeigt denselben Ablauf mit den Dokumenten, die zwischen den Phasen weitergegeben werden (Objektknoten als Rechtecke). Jede Entwurfsaktivität legt die Testfälle ihrer Teststufe fest; fällt ein Test durch, wird die zugehörige Entwurfsphase überarbeitet und der Weg ab dort erneut durchlaufen.

Wie beim Wasserfall gibt es keine fest vorgeschriebenen Meetings; typische Termine sind Reviews der Entwurfsdokumente, Testabnahmen jeder Stufe und die formale Abnahme mit den Auftraggebenden.

Rollen: Entwurf und Prüfung in verschiedenen Händen

Das einfache V-Modell nennt keine Rollen; in der Praxis entsprechen sie denen des Wasserfallmodells (Auftraggebende, Projektleitung, Analyse, Architektur, Entwicklung, Test, Betrieb). Wichtig ist eine zusätzliche Regel: Wer entwirft, sollte nicht allein prüfen. Testfälle für System- und Abnahmetest werden deshalb oft von einer unabhängigen Qualitätssicherung oder von den Auftraggebenden selbst erstellt. Das V-Modell XT definiert dagegen ausdrücklich Rollen, z. B. Projektleiter, Anforderungsanalytiker (Auftraggeber), Systemarchitekt, Prüfer, QS-Verantwortlicher und Lenkungsausschuss, und ordnet jedem Produkt eine verantwortliche Rolle zu.

Artefakte: Das V-Modell ist dokumentengetrieben

Jede Phase endet mit einem prüfbaren Dokument (Tabelle oben). Zu den Testphasen gehören Testspezifikationen (welche Testfälle, welche Eingaben, welche erwarteten Ergebnisse) und Testprotokolle bzw. Testberichte (tatsächliches Ergebnis, Datum, Prüfende), zum Abnahmetest das Abnahmeprotokoll, zur Übergabe ein Übergabeprotokoll und das Benutzerhandbuch. Diese Dokumente sind zugleich Nachweise gegenüber den Auftraggebenden, Prüfstellen oder Behörden. Die Erwartung an die Dokumentation ist umfangreich; im V-Modell XT heißen alle Ergebnisse Produkte und haben feste Gliederungsvorlagen.

Qualität und Test: Verifikation und Validierung

Der Testansatz ist das Herz des V-Modells. Es macht zwei Prüffragen sichtbar:

• Verifikation: Bauen wir das Produkt richtig? Stimmt das Ergebnis einer Phase mit seiner Vorgabe überein (z. B. Modul mit Modulbeschreibung)? Das prüfen vor allem Komponenten-, Integrations- und Systemtest.

• Validierung: Bauen wir das richtige Produkt? Erfüllt das System den tatsächlichen Zweck der Nutzenden? Das zeigt sich spätestens beim Abnahmetest.

Die vier Teststufen entsprechen den Teststufen der Softwaretechnik (vgl. ISTQB-Lehrplan und ISO/IEC/IEEE 29119). Komponententests werden heute meist automatisiert (Unit-Tests), Integrations- und Systemtests teilweise; der Abnahmetest bleibt oft manuell. Weil Testfälle früh entstehen, fallen Unklarheiten in den Anforderungen schon beim Schreiben der Testfälle auf – ein wichtiger Vorteil gegenüber dem Wasserfall.

Stakeholder: Anforderungen und Abnahme

Die Auftraggebenden formulieren die Anforderungen (Lastenheft), geben das Pflichtenheft frei, legen idealerweise die Abnahmekriterien mit fest und führen den Abnahmetest durch. Im V-Modell XT sind die Übergänge zwischen Auftraggeber und Auftragnehmer als Entscheidungspunkte festgelegt (z. B. „Angebot abgegeben“, „Projekt beauftragt“, „Lieferung durchgeführt“, „Abnahme erfolgt“). Zwischen diesen Punkten ist die Einbindung eher gering; Rückmeldungen zum laufenden System gibt es im klassischen Ablauf spät.

Planung und Kontrolle: Meilensteine mit Freigabe

Geplant wird wie beim Wasserfall vorab: Umfang, Termine, Kosten. Hinzu kommt die Testplanung je Teststufe. Kontrolliert wird über Meilensteine bzw. Entscheidungspunkte, an denen die fertigen Produkte geprüft und freigegeben werden. Typische Kennzahlen sind neben Termin- und Kostenabweichung die Anforderungsabdeckung (Anteil der Anforderungen mit mindestens einem Testfall), die Zahl offener Fehler je Teststufe und der Anteil bestandener Testfälle.

Skalierung und Anpassbarkeit: das V-Modell XT

Das einfache V-Modell lässt sich für große Systeme rekursiv anwenden: Jedes Teilsystem durchläuft ein eigenes, kleineres V. Für die IT-Projekte des Bundes gibt es mit dem V-Modell XT eine umfangreiche, anpassbare Weiterentwicklung. Es ist kein fester Ablauf, sondern ein Baukasten:

• Projekttyp: z. B. Systementwicklungsprojekt eines Auftraggebers, eines Auftragnehmers oder beider, oder Einführung eines organisationsspezifischen Vorgehensmodells.

• Tailoring (Zuschneiden): Je nach Projekttyp und Projektmerkmalen werden nur die passenden Bausteine ausgewählt – daher das „XT“.

• Vorgehensbausteine bündeln Produkte (Ergebnisse), Rollen und Aktivitäten zu einem Thema, z. B. Projektmanagement, Qualitätssicherung, Konfigurationsmanagement oder Systemerstellung.

• Projektdurchführungsstrategie: legt die Reihenfolge der Entscheidungspunkte fest, z. B. inkrementell, komponentenbasiert oder agil. Das V-Modell XT lässt sich damit ausdrücklich auch mit iterativen Abläufen kombinieren.

• Entscheidungspunkte: Meilensteine, an denen die fertigen Produkte geprüft und über den Fortgang entschieden wird.

Häufig genutzte Techniken

Oft mit dem V-Modell kombiniert werden:

• Anforderungsverfolgung (Traceability): jede Anforderung lässt sich bis zum Testfall und Testergebnis verfolgen,

• Testfallentwurfstechniken wie Äquivalenzklassen, Grenzwertanalyse oder Entscheidungstabellen,

• Reviews und Inspektionen der Entwurfsdokumente,

• Konfigurationsmanagement für Dokumente und Code,

• Testautomatisierung auf Komponenten- und Integrationsebene.

Risiken, Stärken und Grenzen

Häufige Stolpersteine: Wie beim Wasserfall sind späte Änderungen der Anforderungen teuer, der Dokumentationsaufwand ist hoch, und lauffähige Software gibt es erst spät. Beim V-Modell XT kommt hinzu, dass ungenügendes Tailoring zu unnötig vielen Produkten führt.

Typische Gegenmaßnahmen: konsequentes Tailoring, frühe Prototypen, inkrementelle Projektdurchführungsstrategie, automatisierte Tests auf den unteren Ebenen.

Stärken: Tests werden früh geplant, jedes Ergebnis wird geprüft, Fehler lassen sich einer Ebene zuordnen, die Nachweise sind lückenlos.

Grenzen: wenig flexibel bei sich ändernden Anforderungen, hoher Aufwand, für kleine Projekte überdimensioniert.

Praxisbeispiele und Anwendungsfelder

Das V-Modell passt gut zu sicherheitskritischen Systemen (Medizintechnik, Bahn, Luftfahrt, Automobil – dort angelehnt etwa an Automotive SPICE), zu hardwarenahen Projekten, zu Behördenprojekten (V-Modell XT als Vorgabe für Bundesprojekte) und allgemein zu Projekten mit vertraglich vereinbarter Abnahme. Beispiel: Eine Schule beauftragt die Installation von Info-Monitoren in den Fluren; Anforderungen, Hardware und Abnahmekriterien stehen fest, und jede Ebene (Player-Software, Netzanbindung, Gesamtsystem, Abnahme im Foyer) wird einzeln geprüft. Die Teamgröße reicht von kleinen Teams bis zu großen Vorhaben mit mehreren Auftragnehmern.

Leitfragen

1. Wie sind Entwurfs- und Testphasen im V-Modell angeordnet, und welche Phasen gehören zusammen? Antwort

Links stehen von oben nach unten Anforderungsdefinition, Systemspezifikation, Systementwurf und Komponentenentwurf, unten die Implementierung, rechts von unten nach oben Komponenten-, Integrations-, System- und Abnahmetest; zusammen gehören jeweils die Phasen auf gleicher Höhe, siehe Abschnitt „Ablauf“.

2. Welche Verlaufsrichtungen gibt es im V-Modell? Antwort

Bei Erfolg geht es links abwärts in die nächste Entwurfsphase und nach der Implementierung rechts aufwärts in die nächste Testphase; fällt ein Test durch, geht es waagerecht zurück zur gegenüberliegenden Entwurfsphase. Außerdem liefert jede Entwurfsphase die Testfälle der gegenüberliegenden Teststufe, siehe Abschnitt „Verlaufsrichtungen im V-Modell“.

3. Welches Dokument entsteht in welcher Phase, und gegen welches Dokument prüft der Systemtest? Antwort

Lastenheft, Pflichtenheft, Architekturbeschreibung und Modulbeschreibungen entstehen links, Quellcode an der Spitze, Testspezifikationen, Testprotokolle und das Abnahmeprotokoll rechts. Der Systemtest prüft das Gesamtsystem gegen das Pflichtenheft, siehe Abschnitt „Ablauf“ und Abschnitt „Artefakte“.

4. Was unterscheidet Verifikation und Validierung? Antwort

Verifikation fragt „Bauen wir das Produkt richtig?“ und prüft ein Ergebnis gegen seine Vorgabe (vor allem Komponenten-, Integrations- und Systemtest). Validierung fragt „Bauen wir das richtige Produkt?“ und prüft, ob das System den tatsächlichen Zweck erfüllt (spätestens im Abnahmetest), siehe Abschnitt „Qualität und Test“.

5. Für welche Projekte eignet sich das V-Modell, und welche Schwächen hat es? Antwort

Es eignet sich für sicherheitskritische, hardwarenahe und Behördenprojekte sowie für Projekte mit vertraglicher Abnahme, weil Tests früh geplant und alle Ergebnisse nachgewiesen werden. Schwächen sind teure späte Änderungen, hoher Dokumentationsaufwand und spät lauffähige Software, siehe Abschnitt „Risiken, Stärken und Grenzen“.

6. Was bedeutet Tailoring im V-Modell XT, und welche Bausteine gibt es? Antwort

Tailoring heißt, das Modell je nach Projekttyp und Projektmerkmalen zuzuschneiden: Ausgewählt werden Vorgehensbausteine (mit Produkten, Rollen und Aktivitäten) und eine Projektdurchführungsstrategie, die die Reihenfolge der Entscheidungspunkte festlegt – auch inkrementell oder agil, siehe Abschnitt „Skalierung und Anpassbarkeit“.

Links und weitere Informationen

• Vorgehensmodelle: klassisch und agil (Überblick und Vergleich)

• Das Wasserfallmodell

• Übungsaufgaben zu Vorgehensmodellen (u. a. ein V-Modell zum Ergänzen und zur Fehlersuche)

• als Nachschlagewerk: V-Modell XT Bund, Version 2.3 (PDF, bereitgestellt vom ITZBund)

• als Nachschlagewerk: ISTQB® Certified Tester Foundation Level, Lehrplan (Kapitel Teststufen)

• historisch: Barry W. Boehm: Guidelines for Verifying and Validating Software Requirements and Design Specifications (EURO IFIP, 1979)

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Das V-Modell: Zu jedem Entwurf gehört ein Test” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/v-modell veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 30.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]