Das Wasserfallmodell ist ein sequenzielles Vorgehensmodell, das ein Projekt in aufeinanderfolgende Phasen von den Anforderungen bis zum Betrieb zerlegt. Jede Phase startet erst, wenn die vorige ihr Ergebnis abgeliefert hat. Winston W. Royce beschrieb diese Abfolge 1970 auf der IEEE WESCON in sieben Schritten und nannte die reine Form selbst riskant.
Was ist das Wasserfallmodell?
Das Wasserfallmodell ist ein lineares Vorgehensmodell, in dem ein Projekt seine Phasen genau einmal und in fester Reihenfolge durchläuft. Das Ergebnis einer Phase ist die Eingabe der nächsten. Im Gantt-Diagramm entsteht so die typische Treppe, die dem Modell den Namen gibt.
Vier Bausteine machen ein Projekt zum Wasserfallmodell:
- Phasen mit klarem Anfang und Ende, zum Beispiel Entwurf oder Test.
- Phasenergebnisse, etwa Lastenheft, Pflichtenheft oder Testprotokoll.
- Meilensteine am Ende jeder Phase, an denen Auftraggeber oder Projektleitung das Ergebnis freigeben. Mehr dazu im Artikel über Meilensteine im Projektmanagement.
- Ende-Anfang-Abhängigkeiten zwischen den Phasen: Phase 2 startet am Ende von Phase 1.
Woher stammt das Wasserfallmodell?
Das Wasserfallmodell stammt aus der Softwareentwicklung. Winston W. Royce stellte es 1970 im Aufsatz Managing the Development of Large Software Systems vor (Proceedings IEEE WESCON, August 1970, S. 1 bis 9). Seine Abbildung 2 zeigt sieben Schritte: Systemanforderungen, Softwareanforderungen, Analyse, Programmentwurf, Codierung, Test und Betrieb.
Royce hielt diese reine Abfolge für gefährlich. Er schrieb direkt unter der Abbildung: „I believe in this concept, but the implementation described above is risky and invites failure.“ (Ich halte das Konzept für richtig, aber die oben beschriebene Umsetzung ist riskant und lädt zum Scheitern ein.) Sein Argument: Der Test am Ende ist der erste Moment, in dem das System sich real verhält. Fällt dort ein Entwurfsfehler auf, springt das Projekt zurück an den Anfang, und Royce rechnet dann mit bis zu 100 Prozent Überschreitung bei Zeit oder Kosten.
Als Gegenmittel empfahl er fünf Ergänzungen: Programmentwurf vor der Analyse, Entwurf ausführlich dokumentieren, das System zweimal bauen (erst als Pilot), Tests planen und überwachen, den Kunden formell einbinden. Das Wort „Wasserfall“ verwendet Royce nicht. Es taucht nach heutigem Stand zuerst 1976 bei Thomas E. Bell und T. A. Thayer auf, in einem Beitrag zur 2. International Conference on Software Engineering, der sich auf Royce beruft.
Welche Phasen hat das Wasserfallmodell?
Das Wasserfallmodell hat in der Praxis meist sechs Phasen: Anforderungen, Entwurf, Implementierung, Test, Inbetriebnahme und Wartung. Royce unterschied sieben Schritte; Lehrbücher fassen System- und Softwareanforderungen oft zusammen. Entscheidend ist das Ergebnis, das jede Phase abliefert.
| Phase | Ergebnis der Phase | Meilenstein am Phasenende |
|---|---|---|
| 1 Anforderungen | Lastenheft: Was soll das System leisten? | Lastenheft abgenommen |
| 2 Entwurf | Pflichtenheft und Architektur: Wie wird es gebaut? | Pflichtenheft freigegeben |
| 3 Implementierung | Lauffähiges, vollständiges System | Code-Freeze |
| 4 Test | Testprotokoll, behobene Fehler | Abnahme erteilt |
| 5 Inbetriebnahme | Installiertes System, geschulte Anwender | Go-live |
| 6 Wartung | Fehlerbehebung und Updates im Betrieb | Vertragsende oder Ablösung |
Wie sieht ein Wasserfallprojekt an einem Beispiel aus?
Ein Softwarehaus entwickelt für einen Bauträger ein Kundenportal, in dem Käufer Bemusterung und Bautermine einsehen. Der Bauträger zahlt einen Festpreis, das Lastenheft steht vor Vertragsschluss fest. Das Projekt läuft 18 Wochen bis zum Go-live.
Kundenportal als Wasserfallprojekt
Sechs Phasen, fünf Meilensteine, alle Phasen mit Ende-Anfang verknüpft
Drei Zahlen aus dem Beispiel zeigen, wie das Modell rechnet:
- Verschiebung: Nimmt der Bauträger das Lastenheft eine Woche später ab, wandert der Go-live von Woche 18 auf Woche 19. Jede Phase liegt auf dem kritischen Pfad, also schiebt jede Verzögerung das Ende.
- Gewicht der Phasen: Die Implementierung belegt 8 von 18 Wochen (44 Prozent), der Test nur 3 Wochen (17 Prozent).
- Rücksprung: Zeigt der Test in Woche 15 einen Fehler im Entwurf, muss das Team Entwurf (3 Wochen), Implementierung (8 Wochen) und Test (3 Wochen) wiederholen. Das sind 14 Wochen; der Go-live rückt von Woche 18 auf Woche 32, also 78 Prozent später. Genau dieses Risiko meinte Royce mit seiner Warnung.
Gibt es eine Vorlage für ein Wasserfallprojekt?
Ja. Für Merlin Project gibt es zwei fertige Vorlagen, die ein Phasenprojekt mit Meilensteinen abbilden. Die Vorlage Softwareentwicklung gliedert ein Entwicklungsprojekt in Evaluierungs-, Konzeptions-, Spezifikations- und Entwicklungsphase, Testphase und Auslieferung; Entscheidungs-Meilensteine wie „Spezifikation abgeschlossen“ trennen die Phasen. Die Vorlage Einfamilienhaus zeigt dieselbe Logik als Bauzeitenplan von der Vorplanung bis zum Rohbau.
Wasserfall-Vorlage für Merlin Project
Die Vorlage enthält die typischen Phasen eines Entwicklungsprojekts mit Meilensteinen zwischen den Phasen. Laden Sie die Datei herunter, löschen Sie Phasen, die Sie nicht brauchen, und ergänzen Sie Ihre Vorgänge. Die Vorlage gibt es auf Deutsch, Englisch, Spanisch und Französisch.
Vorlage Softwareentwicklung öffnen
Wer ohne Merlin Project startet, übernimmt die Struktur aus dem Beispiel als Tabelle. Jede Zeile wird ein Vorgang oder Meilenstein, die Spalte „Vorgänger“ ergibt die Ende-Anfang-Abhängigkeit:
| # | Vorgang | Typ | Dauer | Vorgänger |
|---|---|---|---|---|
| 1 | Anforderungen erheben | Vorgang | 3 Wochen | keiner |
| 2 | Lastenheft abgenommen | Meilenstein | 0 | 1 |
| 3 | Entwurf und Pflichtenheft | Vorgang | 3 Wochen | 2 |
| 4 | Pflichtenheft freigegeben | Meilenstein | 0 | 3 |
| 5 | Implementierung | Vorgang | 8 Wochen | 4 |
| 6 | Code-Freeze | Meilenstein | 0 | 5 |
| 7 | System- und Abnahmetest | Vorgang | 3 Wochen | 6 |
| 8 | Abnahme erteilt | Meilenstein | 0 | 7 |
| 9 | Inbetriebnahme und Schulung | Vorgang | 1 Woche | 8 |
| 10 | Go-live | Meilenstein | 0 | 9 |
| 11 | Wartung | Vorgang | laufend | 10 |
Wann passt das Wasserfallmodell und wann nicht?
Das Wasserfallmodell passt, wenn die Anforderungen vor dem Start feststehen und sich während der Umsetzung kaum ändern. Typisch sind Bauvorhaben, Projekte mit behördlicher Genehmigung und Aufträge zum Festpreis. Bei einem Haus folgt das Dach auf die Wände, weil die Statik keine andere Reihenfolge zulässt.
Das Wasserfallmodell passt, wenn
- Auftraggeber und Team die Anforderungen vor dem Start schriftlich festlegen können,
- Behörden, Prüfer oder der Vertrag Freigaben an festen Punkten verlangen,
- ein Festpreis oder ein fixer Termin vereinbart ist,
- physische Abhängigkeiten die Reihenfolge erzwingen (erst Fundament, dann Wände).
Das Wasserfallmodell passt nicht, wenn
- Anforderungen erst durch Rückmeldungen der Nutzer entstehen,
- das Team früh einen lauffähigen Zwischenstand zeigen muss,
- sich Markt oder Technik während der Laufzeit ändern,
- ein später Test zum teuren Rücksprung führt, wie im Beispiel oben.
Wasserfall, agil oder hybrid: Was ist der Unterschied?
Wasserfall plant das ganze Projekt im Voraus und liefert am Ende; agile Methoden wie Scrum planen in kurzen Zyklen und liefern nach jedem Zyklus ein nutzbares Ergebnis. Hybrides Projektmanagement verbindet beides: Phasen und Meilensteine für den Rahmen, agile Arbeit innerhalb einer Phase.
| Kriterium | Wasserfall | Agil (z. B. Scrum) | Hybrid |
|---|---|---|---|
| Planung | Gesamtes Projekt vor dem Start | Je Sprint, höchstens ein Monat | Phasen vorab, Aufgaben je Phase |
| Änderungen | Über formalen Änderungsantrag | Jederzeit im Backlog | Im Rahmen der Phase |
| Kunde beteiligt | An den Meilensteinen | In jedem Sprint-Review | An Meilensteinen und Reviews |
| Lieferung | Einmal am Ende | Nach jedem Sprint | Je Phase oder Release |
| Typische Ansicht | Gantt-Diagramm | Kanban-Board | Gantt und Kanban gekoppelt |
Wie Teams die Mischform aufbauen, beschreibt der Artikel zum hybriden Projektmanagement.
So planen Sie ein Wasserfallprojekt in Merlin Project
Merlin Project bildet die Wasserfall-Struktur im Strukturplan ab: links die Gliederung, rechts das Gantt-Diagramm. So bauen Sie das Beispiel nach:
- Öffnen Sie Darstellung > Strukturplan > Eingabe und legen Sie jede Phase als Gruppe an. Mit Ctrl+Cmd+→ rücken Sie die Vorgänge unter ihre Phase ein.
- Setzen Sie ans Ende jeder Phase einen Meilenstein mit Einfügen > Meilenstein (Cmd+Alt+M). Im Gantt-Diagramm erscheint er als Raute.
- Markieren Sie Phasen und Meilensteine in ihrer Reihenfolge und wählen Sie Struktur > Verknüpfen > Ende zu Anfang (Ctrl+Cmd+L). Merlin Project verknüpft die Auswahl der Reihe nach.
- Blenden Sie mit Darstellung > Kritischen Pfad zeigen die Kette ein, die den Go-live bestimmt.
- Tragen Sie am Tag der Freigabe das Datum ins Feld Referenzdatum der Projekteinstellungen ein. Ab dann zeigt die Ansicht Soll/Ist-Vergleich (Zeit) jede Abweichung gegen diesen Basisplan.
Phasen und Meilensteine im Strukturplan
Das Beispiel aus der Merlin-Dokumentation zeigt einen Büroumzug in drei Phasen. Nach jeder Gruppe steht ein Meilenstein, etwa „Altgebäude geräumt“, und die Pfeile im Gantt-Diagramm zeigen die Ende-Anfang-Abhängigkeiten.
Basisplan ohne Extra-Schritt
Merlin Project speichert die gesamte Projekthistorie im Dokument. Sie müssen deshalb keinen Basisplan von Hand sichern: Ein Datum im Feld Referenzdatum genügt, und graue Referenzbalken zeigen den damals geplanten Zeitraum. Details in der Lektion Soll/Ist-Vergleich.
Für die Implementierungsphase lohnt der hybride Weg. Blenden Sie mit F2 die Detailansicht ein und wählen Sie darin das Kanban-Board. Markieren Sie oben die Phase, zeigt das Board unten nur deren Vorgänge. Ziehen Sie dort eine Karte von „Aufgaben“ nach „Erledigt“, setzt Merlin Project den Fortschritt des Vorgangs auf 100 Prozent, und der Balken im Gantt-Diagramm zeigt das sofort.
Wasserfall oben, Kanban unten
Oben steht der Phasenplan mit Meilensteinen, unten das Kanban-Board für die markierte Phase. Beide Ansichten zeigen dieselben Vorgänge, eine Änderung wirkt sofort in beiden.
Haben Sie Fragen zu diesem Blogartikel oder möchten darüber diskutieren, freuen wir uns auf Ihren Beitrag bei uns im Forum.
Häufige Fragen
Was ist ein Beispiel für das Wasserfallmodell?
Ein Kundenportal mit festem Lastenheft: Anforderungen (3 Wochen), Entwurf (3 Wochen), Implementierung (8 Wochen), Test (3 Wochen) und Inbetriebnahme (1 Woche) folgen nacheinander. Jede Phase endet mit einem Meilenstein wie „Lastenheft abgenommen“. Der Go-live liegt nach 18 Wochen. Ein Bauvorhaben wie ein Einfamilienhaus folgt derselben Logik.
Welche Phasen hat das Wasserfallmodell?
In der Praxis meist sechs: Anforderungen, Entwurf, Implementierung, Test, Inbetriebnahme und Wartung. Winston W. Royce unterschied 1970 sieben Schritte, weil er System- und Softwareanforderungen getrennt aufführte. Jede Phase liefert ein prüfbares Ergebnis, etwa Lastenheft oder Testprotokoll.
Wer hat das Wasserfallmodell erfunden?
Die Abfolge geht auf Winston W. Royce zurück, der sie 1970 im Aufsatz „Managing the Development of Large Software Systems“ beschrieb. Royce selbst hielt die reine Form für riskant und empfahl Rückkopplung und einen Pilotdurchlauf. Den Namen „Wasserfall“ verwendeten zuerst Thomas E. Bell und T. A. Thayer im Jahr 1976.
Was ist das erweiterte Wasserfallmodell?
Das erweiterte Wasserfallmodell erlaubt Rücksprünge in die jeweils vorige Phase. Royce zeigte diese Rückkopplung zwischen benachbarten Phasen bereits 1970 in seiner Abbildung 3. Fehler lassen sich so früher korrigieren, ohne das ganze Projekt neu zu starten.
Gibt es eine kostenlose Vorlage für ein Wasserfallprojekt?
Ja. Die Vorlage „Softwareentwicklung“ für Merlin Project enthält Phasen mit Entscheidungs-Meilensteinen, die Vorlage „Einfamilienhaus“ einen phasenweisen Bauzeitenplan. Beide stehen im Vorlagenbereich zum Download bereit. Merlin Project testen Sie 30 Tage kostenlos.
Ist das Wasserfallmodell agil?
Nein. Das Wasserfallmodell plant das gesamte Projekt vor dem Start und liefert einmal am Ende. Agile Methoden wie Scrum planen in Sprints von höchstens einem Monat (Scrum Guide 2020) und liefern nach jedem Sprint. Hybride Ansätze nutzen Wasserfall-Phasen als Rahmen und arbeiten innerhalb einer Phase agil.
