Das Wasserfallmodell: Phase für Phase zum fertigen System

Das Wasserfallmodell: Phase für Phase zum fertigen System

https://bildung.social/@oerinformatik/

https://oer-informatik.de/wasserfallmodell

Wasserfallmodell, Vorgehensmodelle, Phasenmodell, Lastenheft, Pflichtenheft, Meilenstein, Abnahme, Royce, dokumentengetrieben, Projektmanagement

tl/dr; (ca. 14 min Lesezeit): Das Wasserfallmodell ist das bekannteste klassische Vorgehensmodell: Ein Projekt durchläuft Analyse, Entwurf, Implementierung, Test sowie Einsatz und Wartung nacheinander, und jede Phase endet mit einem freigegebenen Dokument. Der Artikel zeigt Herkunft, Ablauf, Rollen, Dokumente, Test- und Planungsansatz des Modells und erklärt, wann es passt und wo seine Grenzen liegen [AI-Assisted]. (Zuletzt geändert am 30.10.2026)

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 Wasserfallmodell zeichnet sich dadurch aus, dass ein Projekt in fest aufeinanderfolgende Phasen zerlegt wird, von denen jede erst vollständig abgeschlossen und durch ein freigegebenes Dokument belegt sein muss, bevor die nächste beginnt.

Das Bild dahinter ist einfach: Wie Wasser über die Stufen eines Wasserfalls fließt das Projekt von oben nach unten durch die Phasen, und jede Stufe übergibt ihr Ergebnis an die nächste.

Herkunft: vom Großprojekt der 1950er zum Standard

Die Idee, Software in festen Stufen zu entwickeln, stammt aus großen militärischen und staatlichen Projekten der 1950er und 1960er Jahre: Herbert D. Benington beschrieb 1956 für das Luftverteidigungssystem SAGE einen stufenweisen Ablauf von der Spezifikation bis zum Betrieb. Bekannt wurde das Phasenmodell durch einen Aufsatz von Winston W. Royce aus dem Jahr 1970, der den streng sequenziellen Ablauf allerdings gerade als riskant darstellte. Der Begriff „Wasserfall“ taucht erst einige Jahre später auf (u. a. bei Bell und Thayer, 1976). Durch Standards wie den US-Militärstandard DoD-STD-2167 (1985) wurde das dokumentengetriebene Vorgehen zur Vorgabe in vielen Auftragsprojekten. Ziel war, große Vorhaben mit vielen Beteiligten planbar, vertraglich abgrenzbar und nachweisbar zu machen. Typische Einsatzbereiche sind bis heute Projekte mit festen Anforderungen, festem Budget und klarer Abnahme.

Grundprinzipien: Ordnung, Vollständigkeit, Nachweis

Das Wasserfallmodell folgt wenigen, strengen Leitlinien:

• Sequenz: Die Phasen werden nacheinander durchlaufen; eine Phase beginnt erst, wenn die vorige abgeschlossen ist.

• Vollständigkeit vor Fortschritt: Jede Phase soll ihr Thema vollständig klären, bevor weitergearbeitet wird. Die Anforderungen werden also zu Beginn vollständig erhoben.

• Dokumentengetrieben: Am Ende jeder Phase steht mindestens ein Artefakt (meist ein Dokument), das den Abschluss der Phase definiert. Die Artefakte der vorgelagerten Phasen bilden die verbindliche Grundlage der folgenden.

• Meilensteine: Die Phasenübergänge sind Meilensteine mit Prüfung und Freigabe. Hier wird entschieden, ob das Projekt in die nächste Phase geht.

Das Besondere am Wasserfallmodell ist vor allem seine Einfachheit: Jede Person im Projekt weiß jederzeit, in welcher Phase es steht und welches Ergebnis als Nächstes fällig ist.

Ablauf: fünf Phasen, fünf Ergebnisse

Typische Phasen der Softwareentwicklung im Wasserfallmodell sind:

1. Analyse: Anforderungen erheben und festschreiben (Artefakte: z. B. Lastenheft, später Pflichtenheft).

2. Entwurf: Architektur, Datenmodell, Module und Schnittstellen planen (Artefakte: z. B. Entwurfsdiagramme und -dokumente).

3. Implementierung (Realisierung): programmieren (Artefakte: z. B. Programmcode).

4. Test: prüfen, ob die Software die Anforderungen erfüllt (Artefakte: z. B. Testprotokoll).

5. Einsatz und Wartung: durch die Auftraggebenden abnehmen lassen, übergeben, in Betrieb nehmen, Fehler beheben, pflegen (Artefakte: z. B. Abnahme- und Übergabeprotokoll, Benutzerhandbuch).

Manchmal werden mehr oder anders benannte Phasen verwendet (z. B. Planung vor der Analyse oder ein getrennter Abnahmetest). Entscheidend ist das Prinzip: Jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt, und ihr Ergebnis ist die verbindliche Grundlage der nächsten Phase.

Das folgende Aktivitätsdiagramm zeigt den Ablauf mit den Dokumenten, die zwischen den Phasen weitergegeben werden (Objektknoten als Rechtecke). Feste Meetings wie in agilen Modellen gibt es nicht; die typischen Termine sind das Kick-off zu Beginn, Reviews und Freigaben an jedem Phasenübergang und die Abnahme am Ende.

Werden im Wasserfallmodell Probleme oder Fehler in einer der vorgelagerten Phasen erkannt, müssen alle Artefakte der darauf folgenden Phasen neu erstellt oder angepasst werden. Im Netz ist häufig die Rede von einem strengen Wasserfallmodell, in dem Rücksprünge nicht erlaubt sind. Das ist in der Praxis Unsinn, man müsste ja wissentlich ein fehlerhaftes Produkt ausliefern. Statt von einem erweiterten Wasserfallmodell zu sprechen, ist es wichtiger hervorzuheben, dass bei Rücksprüngen alle Artefakte nachgezogen werden müssen.

Rollen: Wer übergibt was an wen?

Das Wasserfallmodell selbst schreibt keine Rollen vor; in der Praxis haben sich aber klare Zuständigkeiten etabliert, die meist entlang der Phasen und der Vertragsgrenze zwischen Auftraggebenden und Auftragnehmenden verlaufen:

Die Zusammenarbeit ist arbeitsteilig und hierarchisch: Die Projektleitung steuert, Spezialist*innen arbeiten ihre Phase ab und übergeben das Ergebnis. Das spart Abstimmung, birgt aber die Gefahr, dass Wissen bei der Übergabe verloren geht („Über-die-Mauer-werfen“).

Artefakte: Das Dokument ist der Meilenstein

Im Wasserfallmodell ist Dokumentation kein Beiwerk, sondern das Steuerungsinstrument: Ein Meilenstein gilt erst als erreicht, wenn das zugehörige Dokument geprüft und freigegeben ist.

Die Erwartung an die Dokumentation ist umfangreich und verbindlich: Die Dokumente sind zugleich Vertragsgrundlage, Arbeitsauftrag für die nächste Phase und Nachweis gegenüber den Auftraggebenden. Wie ein Lastenheft und ein Pflichtenheft konkret aussehen, zeigt die Artikelreihe Realisierung eines Microcontroller-Projekts nach dem Wasserfall-Modell mit den Teilen Lastenheft und Pflichtenheft.

Qualität und Test: geprüft wird am Ende

Getestet wird im klassischen Wasserfallmodell in einer eigenen Phase nach der Implementierung. Grundlage der Testfälle sind die Anforderungen aus Lasten- und Pflichtenheft. Qualität entsteht außerdem durch Reviews der Dokumente an jedem Phasenübergang: Bevor entworfen wird, prüfen Auftraggebende und Team das Pflichtenheft; bevor programmiert wird, den Entwurf. Die Schwäche liegt auf der Hand: Ob die Software wirklich funktioniert, zeigt sich erst spät. Das V-Modell greift genau diesen Punkt auf und ordnet jeder Entwurfsphase eine eigene Teststufe zu (siehe V-Modell).

Stakeholder: viel Kontakt am Anfang und am Ende

Die Auftraggebenden sind vor allem in der Analyse (Anforderungen formulieren, Pflichtenheft freigeben) und bei der Abnahme beteiligt. Dazwischen erhalten sie Statusberichte und nehmen an den Meilenstein-Reviews teil, sehen aber in der Regel keine lauffähige Software. Rückmeldungen zum fertigen Produkt kommen deshalb erst spät, und ein Änderungswunsch während der Entwicklung läuft als formaler Änderungsantrag (Change Request) mit Bewertung von Aufwand, Kosten und Terminen.

Planung und Kontrolle: vorab festgelegt

Der Planungsgrad ist hoch: Umfang, Termine und Kosten werden zu Beginn festgelegt, meist mit einem Projektstrukturplan, einem Gantt-Diagramm oder Netzplan. Im magischen Dreieck (siehe Projektorganisation) ist damit der Umfang fixiert, Zeit und Kosten werden daraus geschätzt. Kontrolliert wird über Meilensteine (Termin eingehalten, Dokument freigegeben?) und Kennzahlen wie Planabweichung bei Kosten und Terminen, Fertigstellungsgrad oder die Earned-Value-Analyse. Für die Transparenz sorgen Statusberichte an Lenkungsausschuss und Auftraggebende.

Skalierung und Anpassung: einfach im Kleinen, schwerfällig im Großen

Formal skaliert das Wasserfallmodell gut, weil sich große Vorhaben in Teilprojekte mit eigenen Phasen zerlegen lassen; der Abstimmungs- und Dokumentationsaufwand wächst aber stark. Typische Anpassungen sind:

• Wasserfall mit Rücksprüngen: Rückkehr in die vorige Phase, wenn dort Fehler entdeckt werden (das ist in der Praxis der Normalfall).

• Überlappende Phasen (Sashimi-Modell): Die nächste Phase beginnt schon, bevor die vorige ganz fertig ist.

• Prototyp vorab: Ein Wegwerf-Prototyp klärt Unsicherheiten, bevor die Anforderungen festgeschrieben werden – genau das hat Royce empfohlen.

• Stufenweise Auslieferung: Das System wird in mehreren nacheinander geplanten Ausbaustufen erstellt.

Häufig genutzte Techniken

Diese Techniken gehören nicht zum Kern des Modells, werden aber oft mit ihm kombiniert:

• Projektstrukturplan, Netzplan und Gantt-Diagramm für die Termin- und Ressourcenplanung,

• Lasten- und Pflichtenheft nach DIN 69901-5 bzw. VDI 2519,

• Reviews und Inspektionen von Dokumenten,

• Änderungsmanagement (Change Requests, Änderungsausschuss),

• Earned-Value-Analyse zur Fortschrittskontrolle.

Risiken, Stärken und Grenzen

Häufige Stolpersteine: Die Anforderungen sind zu Beginn doch nicht vollständig bekannt; Fehler in den Anforderungen fallen erst im Test auf, wenn ihre Behebung teuer ist; die Auftraggebenden sehen lauffähige Software erst ganz am Ende und merken dann, dass sie etwas anderes gemeint haben; späte Änderungen führen zu Verzögerungen und Mehrkosten.

Typische Gegenmaßnahmen: gründliche Anforderungsanalyse mit Reviews, Prototypen für unsichere Teile (vor allem die Oberfläche), frühzeitig geplante Testfälle, ein geregeltes Änderungsverfahren und Puffer in der Terminplanung.

Stärken: einfach zu verstehen und zu steuern, klare Meilensteine an den Phasenübergängen, Kosten und Termine früh planbar, umfangreiche Dokumentation und Nachweise, gut geeignet für Festpreisverträge und für Projekte mit stabilen, gut bekannten Anforderungen.

Grenzen: wenig flexibel bei sich ändernden Anforderungen, späte Fehlererkennung, später Nutzen, hoher Dokumentationsaufwand.

Interessant: Winston W. Royce, auf den das Wasserfallmodell oft zurückgeführt wird, hat es 1970 gerade als problematisches Vorgehen beschrieben und Verbesserungen vorgeschlagen, etwa einen Prototyp („do it twice“) und die frühe Einbindung der Kundschaft. Mehr dazu im Artikel Leitfragen zu Royce’ Kritik am „Wasserfallmodell“.

Praxisbeispiele und Anwendungsfelder

Das Wasserfallmodell passt, wenn das Ziel klar ist und sich voraussichtlich nicht ändert: etwa die Einführung einer Standardsoftware mit festem Funktionsumfang, die Migration eines Altsystems mit bekannten Funktionen, Projekte mit hohem Hardwareanteil (Beschaffung, Verkabelung, Montage) oder Behörden- und Auftragsprojekte mit Ausschreibung, Festpreis und formaler Abnahme. Das Werkstattportal der Fahrradmanufaktur CSB-Rad mit festem Termin, festem Budget und abgestimmtem Pflichtenheft ist ein typisches Beispiel. Die Teamgröße ist dabei kaum begrenzt; von kleinen Teams mit drei bis fünf Personen bis zu großen Projekten mit Teilprojektleitungen ist alles möglich.

Leitfragen

1. Welche Phasen hat das Wasserfallmodell, und welches Dokument entsteht typischerweise in welcher Phase? Antwort

Typische Phasen sind Analyse (Lastenheft, Pflichtenheft), Entwurf (Entwurfsdokumente), Implementierung (Quellcode), Test (Testprotokoll) sowie Einsatz und Wartung (Abnahme- und Übergabeprotokoll, Benutzerhandbuch); jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt, siehe Abschnitt „Ablauf“ und Abschnitt „Artefakte“.

2. Warum gilt das Wasserfallmodell als dokumentengetrieben, und was muss bei einem Rücksprung passieren? Antwort

Jede Phase endet mit einem geprüften und freigegebenen Dokument, das den Abschluss der Phase definiert und die verbindliche Grundlage der nächsten Phase bildet. Wird in einer späteren Phase ein Fehler aus einer früheren entdeckt, geht es dorthin zurück, und alle Dokumente der folgenden Phasen müssen angepasst werden, siehe Abschnitt „Grundprinzipien“ und Abschnitt „Ablauf“.

3. Welche Rollen gibt es typischerweise in einem Wasserfallprojekt, und wie arbeiten sie zusammen? Antwort

Auftraggebende formulieren die Anforderungen und nehmen ab, die Projektleitung plant und kontrolliert, Spezialist*innen für Analyse, Entwurf, Entwicklung, Test und Betrieb arbeiten ihre Phase ab. Die Zusammenarbeit ist arbeitsteilig und hierarchisch, Ergebnisse werden über Dokumente übergeben, siehe Abschnitt „Rollen“.

4. Warum werden Fehler in den Anforderungen im Wasserfallmodell besonders teuer? Antwort

Getestet wird erst nach der Implementierung, und die Auftraggebenden sehen lauffähige Software erst am Ende. Ein Fehler in den Anforderungen fällt deshalb oft erst auf, wenn schon entworfen und programmiert wurde; dann müssen alle folgenden Dokumente und der Code angepasst werden, siehe Abschnitt „Qualität und Test“ und Abschnitt „Risiken, Stärken und Grenzen“.

5. Für welche Projekte eignet sich das Wasserfallmodell, und welche Vor- und Nachteile hat es? Antwort

Es eignet sich für Projekte mit stabilen, gut bekannten Anforderungen, Festpreis und formaler Abnahme. Vorteile sind einfache Steuerung, klare Meilensteine, frühe Planbarkeit und gute Nachweise; Nachteile sind geringe Flexibilität, späte Fehlererkennung und später Nutzen, siehe Abschnitt „Risiken, Stärken und Grenzen“ und Abschnitt „Praxisbeispiele“.

6. Was kritisierte Royce 1970 am streng sequenziellen Vorgehen, und welche Gegenmaßnahmen helfen bis heute? Antwort

Royce hielt den streng sequenziellen Ablauf für riskant, weil sich Probleme erst im Test zeigen, und schlug u. a. einen vorgezogenen Prototyp („do it twice“) und die frühe Einbindung der Kundschaft vor. Heute helfen außerdem Reviews, frühzeitig geplante Testfälle und ein geregeltes Änderungsverfahren, siehe Abschnitt „Herkunft“, Abschnitt „Risiken, Stärken und Grenzen“ und den Artikel zu Royce’ Kritik.

Links und weitere Informationen

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

• Leitfragen zu Royce’ Kritik am „Wasserfallmodell“

• Realisierung eines Microcontroller-Projekts nach dem Wasserfall-Modell mit Lastenheft, Pflichtenheft und Planungsphase

• Projekte organisieren: von den Projektzielen bis zum Projektabschluss

• historisch: Winston W. Royce: Managing the development of large software systems (1970)

• historisch: Herbert D. Benington: Production of Large Computer Programs (1956, Nachdruck in IEEE Annals of the History of Computing, 1983)

• als Nachschlagewerk: DIN 69901-5 (Projektmanagement – Begriffe, u. a. Lasten- und Pflichtenheft)

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 Wasserfallmodell: Phase für Phase zum fertigen System” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/wasserfallmodell 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]