Wasserfallmodell: Phasen, Vorteile und wann es trägt

Der Mann, dem die Fachwelt das Wasserfallmodell zuschreibt, hat es 1970 aufgeschrieben, um zu zeigen, dass es so nicht funktioniert.

Winston W. Royce, Softwareingenieur bei Lockheed, veröffentlichte damals einen Aufsatz über die Entwicklung großer Softwaresysteme. Darin zeichnete er den streng sequenziellen Ablauf — Anforderungen, Entwurf, Umsetzung, Test, Auslieferung — und schrieb dazu, dass genau diese Umsetzung riskant sei und Misserfolg einlade. Der Rest des Aufsatzes bestand aus seinen Vorschlägen, wie man den Ablauf reparieren müsse: Prototyp vorschalten, Tests planen und überwachen, den Auftraggeber laufend über Reviews einbinden. Das Wort „Wasserfall" benutzte er kein einziges Mal.

Was die Industrie daraus machte: das erste Bild ohne die Korrekturen. Jahrzehntelang wurde das Modell nach genau der Fassung gebaut, die ihr Urheber als Warnung gemeint hatte.

Deshalb ist dieser Artikel kein Nachruf. Das Wasserfallmodell trägt in bestimmten Projekten besser als alles andere — und es fällt in anderen zuverlässig auf die Nase. Du bekommst hier: was das Modell ist, welche Phasen es hat, was es kann, wo es scheitert, und woran du in 20 Minuten erkennst, ob dein nächstes Projekt dazu passt.

Was ist das Wasserfallmodell?

Das Wasserfallmodell ist ein lineares, nicht iteratives Vorgehensmodell, das ein Projekt in klar abgegrenzte, aufeinanderfolgende Phasen zerlegt. Jede Phase hat einen definierten Start, ein definiertes Ende und ein verbindliches Ergebnis — meistens ein Dokument. Erst wenn dieses Ergebnis abgenommen ist, beginnt die nächste Phase. Zurück geht es im strengen Modell nicht.

Der Name kommt vom Bild. Zeichnest du die Phasen als versetzte Kaskade untereinander, sieht das aus wie ein Wasserfall: Die Ergebnisse einer Stufe fallen nach unten in die nächste und sind dort verbindliche Vorgabe. Was oben beschlossen wurde, ist unten Gesetz. Die deutschsprachige Darstellung des Wasserfallmodells beschreibt genau das: vordefinierte Start- und Endpunkte, eindeutige Ergebnisse, Verabschiedung der Dokumente an Meilensteinen.

Drei Eigenschaften machen den Kern aus:

• Sequenziell. Jede Aktivität muss beendet sein, bevor die nächste anfängt. Keine Parallelität, kein Vorgriff.
• Dokumentgetrieben. Am Ende jeder Phase steht ein fertiges Dokument. Das Dokument ist der Übergabepunkt, nicht das Gespräch.
• Top-down. Erst das Ganze denken, dann die Teile bauen. Nicht umgekehrt.

Der vierte Punkt ist der unbequeme: Der Auftraggeber wird am Anfang beteiligt und danach lange nicht mehr. Entwurf und Umsetzung laufen ohne ihn. Alles, was er später ändern will, ist im strengen Wasserfallmodell ein Neuauftrag.

Wasserfallmodell mit Rücksprung

In der Praxis arbeitet fast niemand mit der strengen Fassung. Die verbreitete Variante heißt Wasserfallmodell mit Rücksprung und erlaubt, jeweils eine Stufe zurückzugehen, wenn sich in der laufenden Phase herausstellt, dass eine frühere Entscheidung falsch war. Im Test fällt auf, dass der Entwurf einen Fall nicht abdeckt — also zurück in den Entwurf, korrigieren, wieder vor.

Das ist kein Schönheitsfehler, sondern der eigentliche Betriebszustand. Genau diese Rücksprünge hatte Royce gemeint. Wer das Wasserfallmodell ohne Rücksprung fährt, fährt die Fassung, vor der der Urheber gewarnt hat.

Woher das Modell wirklich stammt

Nicht aus der Softwareentwicklung. Das Wasserfallmodell ist aus dem Bau- und Produktionsprozess übernommen — aus Bereichen, in denen späte Änderungen prohibitiv teuer oder schlicht unmöglich sind. Wenn das Fundament steht, verschiebst du den Keller nicht mehr. Als in den 50ern die ersten großen Softwareprojekte anfielen, gab es keinen eigenen Prozess dafür. Also nahm man den, der im Bau funktionierte.

Die erste bekannte Beschreibung eines solchen Ablaufs für Software stammt von Herbert D. Benington, vorgetragen am 29. Juni 1956 auf einem Symposium über Programmiermethoden — es ging um die Software für das Luftverteidigungssystem SAGE. Als Benington seinen Vortrag 1983 neu auflegte, schrieb er im Vorwort selbst, dass der Prozess damals gar nicht strikt von oben nach unten durchlief, sondern auf einem Prototyp aufbaute.

Zweimal dieselbe Geschichte: Die Leute, die das Modell beschrieben haben, haben es nie so streng gemeint, wie es später gelehrt wurde.

Winston Royce 1970: der meistzitierte Aufsatz, den kaum jemand gelesen hat

Die kurze Antwort: Royce hat das Wasserfallmodell nicht erfunden, nicht so benannt und nicht empfohlen. Er hat es gezeichnet, um daran zu erklären, was schiefgeht.

Winston W. Royce leitete Softwareprojekte für Raumfahrtprogramme. Sein Aufsatz „Managing the Development of Large Software Systems" beschreibt zunächst den einfachen sequenziellen Ablauf und stellt dann fest, dass er in dieser Form riskant ist. Der Grund, den er nennt, ist bis heute der wunde Punkt jedes Wasserfallmodells: Die Phase, die Probleme aufdeckt — der Test — kommt ganz am Schluss. Zu einem Zeitpunkt, an dem eine Korrektur entweder das Budget sprengt oder den Termin.

Seine drei Vorschläge waren:

1. Eine Entwurfsphase vor die Analyse ziehen und dort früh eine Simulation, also einen Prototyp, des Endprodukts bauen und dokumentieren.
2. Den Test planen, messen und überwachen — statt ihn als Restarbeit am Ende zu behandeln.
3. Den Kunden formal und laufend einbeziehen, über Reviews, nicht nur beim Kick-off und bei der Abnahme.

Lies das noch einmal. Prototyp, geplanter Test, laufende Kundenreviews. Das sind 1970 formulierte Vorschläge, die heute in jedem agilen Verfahren stehen. Der Bruch zwischen klassisch und agil ist historisch viel weniger scharf, als die Lagerbildung glauben macht.

Für dich als Unternehmer heißt das etwas sehr Praktisches: Wenn dir jemand das Wasserfallmodell als „veraltet" verkauft oder als „bewährt" — beides ist zu billig. Das Modell ist ein Werkzeug mit Einsatzbereich. Wie jedes andere im Projektmanagement auch.

Die Phasen im Wasserfallmodell

Die klassische Fassung des Wasserfallmodells hat fünf Phasen: Anforderungsanalyse, Systementwurf, Umsetzung, Test und Auslieferung mit Wartung. Jede Phase liefert ein Dokument, das die nächste Phase verbindlich steuert. Das ist die Antwort — hier ist die Ausführung.

Phase 1: Anforderungsanalyse und Spezifikation

Hier wird festgelegt, was entstehen soll. Nicht wie. Der Auftraggeber beschreibt seinen Bedarf, das Projektteam übersetzt ihn in prüfbare Anforderungen. Ergebnis ist das Lastenheft — die Sammlung aller Forderungen des Auftraggebers. Wie du Lastenheft und Pflichtenheft sauber trennst und wer welches schreibt, steht im Artikel zu Lastenheft und Pflichtenheft.

Diese Phase entscheidet über das gesamte Projekt. Im Wasserfallmodell wird alles, was hier nicht steht, später teuer. Deshalb steckt hier auch der größte Aufwand: Wer weiß, dass er nicht mehr zurückkann, denkt zwangsläufig länger nach.

Phase 2: Systementwurf und Spezifikation

Jetzt wird festgelegt, wie es gebaut wird. Aus den Anforderungen entsteht die Architektur: Bausteine, Schnittstellen, Datenflüsse, Verantwortlichkeiten. In Softwareprojekten ist das die Softwarearchitektur, im Anlagenbau die Konstruktion, im Bau die Ausführungsplanung.

Ergebnis ist ein Entwurfsdokument, das so präzise sein muss, dass jemand danach bauen kann, ohne nachzufragen. Genau daran misst sich, ob dein Wasserfallmodell trägt: Kannst du in Phase 2 alles entscheiden, was Phase 3 braucht?

Phase 3: Umsetzung und Modultests

Gebaut wird. In der Softwareentwicklung: programmieren und jedes Modul einzeln testen. Im Maschinenbau: fertigen und einzeln prüfen. Im Bau: errichten und Gewerk für Gewerk abnehmen.

Diese Phase ist im Wasserfallmodell die ruhigste — vorausgesetzt, die ersten beiden Phasen waren sauber. Wenn das Team hier ständig Rückfragen stellt, hast du kein Umsetzungsproblem. Du hast ein Spezifikationsproblem aus Phase 1.

Phase 4: Integrations- und Systemtest

Die Einzelteile werden zusammengeführt und als Ganzes geprüft — gegen die Anforderungen aus Phase 1, nicht gegen das Gefühl der Beteiligten. Fehler, die hier auffallen, sind die teuersten des ganzen Projekts, weil sie in der Regel auf Entscheidungen aus Phase 1 oder 2 zurückgehen.

Das ist die Stelle, die Royce reparieren wollte. Und die Stelle, an der du im echten Projekt entscheidest, ob du zurückspringst oder mit einem bekannten Mangel auslieferst. Wer diese Entscheidung nicht vorher geregelt hat, trifft sie unter Termindruck. Schlechte Bedingung.

Phase 5: Auslieferung, Einsatz und Wartung

Das Ergebnis geht in Betrieb. Danach beginnt die Phase, die im Projektbudget fast immer unterschätzt wird: Wartung, Fehlerbehebung, Anpassung an neue Rahmenbedingungen. In langlebigen Systemen kostet diese Phase über die Jahre mehr als die vier davor zusammen.

Die Sechs-Phasen-Variante

Eine verbreitete Variante gliedert dasselbe feiner und kommt auf sechs Schritte: Planung, Definition, Entwurf, Implementierung, Test, Einsatz und Wartung. Der Unterschied ist keine andere Logik, sondern eine andere Schnittführung: „Definition" und „Entwurf" teilen auf, was die Fünf-Phasen-Fassung als „Systemdesign und Spezifikation" zusammenfasst, während die beiden Testebenen — Modul und Gesamtsystem — zusammengezogen werden.

Für dich ist das keine Glaubensfrage. Nimm die Schnittführung, bei der jede Phase mit einem Ergebnis endet, das jemand abnehmen kann. Wenn du eine Phase nicht abnehmen kannst, ist sie keine Phase, sondern ein Zeitraum.

Meilensteine sind keine Phasen

Ein Punkt, an dem sich Projekte in der Praxis zerlegen: Meilenstein und Phase werden verwechselt. Eine Phase ist ein Zeitraum mit Arbeit darin. Ein Meilenstein ist ein Zeitpunkt mit einer Entscheidung darin — Ergebnis abgenommen, ja oder nein, weiter oder zurück. Im Wasserfallmodell liegt am Ende jeder Phase genau ein solcher Meilenstein. Wer ihn nicht besetzt und nicht dokumentiert, hat kein Wasserfallmodell. Er hat eine To-do-Liste in Wasserfall-Optik.

Die Vorteile des Wasserfallmodells

Der Hauptvorteil: Planbarkeit. Wenn die Anforderungen früh feststehen, liefert dir das Wasserfallmodell eine Kosten-, Termin- und Ressourcenaussage, die kein iteratives Verfahren in dieser Schärfe hinbekommt. Im Detail:

• Klare Abgrenzung der Phasen. Jeder weiß, in welchem Abschnitt das Projekt steckt und was als Nächstes kommt. Das reduziert Abstimmungsaufwand massiv.
• Einfache Planung und Kontrolle. Phasen mit Anfang, Ende und Abnahmedokument lassen sich in einem Gantt-Diagramm direkt abbilden — das Wasserfallmodell ist praktisch die Vorlage dafür.
• Belastbare Kosten- und Umfangsschätzung bei stabilen Anforderungen. Für Angebote mit Festpreis ist das nicht ein Vorteil, sondern die Voraussetzung.
• Verständlich ohne Schulung. Du kannst das Modell einem neuen Mitarbeiter in fünf Minuten erklären. Bei agilen Verfahren dauert das länger.
• Nachweisbar dokumentiert. In regulierten Bereichen — Medizintechnik, Luftfahrt, öffentliche Auftraggeber — musst du belegen, wer was wann entschieden hat. Ein dokumentgetriebenes Modell liefert das nebenbei.
• Unabhängig von Personen. Weil das Wissen in Dokumenten steht und nicht in Köpfen, überlebt das Projekt einen Personalwechsel. Denselben Gedanken kennst du aus dem Prozessmanagement: Was nicht aufgeschrieben ist, kannst du nicht übergeben.
• Klare Verantwortung an den Übergaben. Jede Phase hat einen Abnehmer. Das erzwingt Entscheidungen zu einem Zeitpunkt, statt sie im Projekt treiben zu lassen.

Die Nachteile des Wasserfallmodells

Der Hauptnachteil: Das Modell setzt voraus, dass du am Anfang weißt, was am Ende herauskommen soll. In den meisten Projekten weißt du das nicht. Die Folgen:

• Abgrenzungsproblem. Sauber getrennte Phasen sind oft unrealistisch. In der Praxis ist ein Teil des Systems noch in der Planung, während ein anderer schon läuft.
• Abfolgeproblem. In der Theorie läuft es nacheinander, in der Praxis sind Rücksprünge unvermeidbar. Das strenge Modell hat dafür keinen vorgesehenen Weg.
• Unflexibel gegenüber Änderungen. Jede Änderung nach der Freigabe ist ein Eingriff, der den ganzen Zug bremst — und im Vertragsverhältnis ein Nachtrag.
• Frühes Festschreiben der Anforderungen. Was in Phase 1 vergessen wurde, kostet in Phase 4 ein Vielfaches. Deshalb wird oft unverhältnismäßig viel Aufwand in Analyse und Konzeption gesteckt — Zeit, in der noch nichts Nutzbares existiert.
• Später Return on Investment. Nutzen entsteht erst mit der Auslieferung. Bei einem Projekt über 18 Monate zahlst du 18 Monate lang, bevor irgendetwas zurückkommt.
• Big-Bang-Einführung. Alles geht auf einmal live. Fehler zeigen sich spät und gleichzeitig — mit entsprechendem Aufwand.
• Ergebnis passt zum Anforderungsstand von gestern. Bei langen Laufzeiten bildet das fertige Ergebnis nicht den aktuellen Bedarf ab, sondern den vom Projektstart. Im Extremfall ist das System am Einführungstag inhaltlich veraltet.
• Der Auftraggeber ist lange außen vor. Zwischen Freigabe und Abnahme sieht er nichts. Das ist der häufigste Grund für böse Überraschungen bei der Übergabe.

Fällt dir etwas auf? Fast jeder dieser Nachteile hängt an einer einzigen Annahme: Anforderungen sind früh bekannt und bleiben stabil. Ist die Annahme richtig, verschwinden die meisten Nachteile. Ist sie falsch, hilft dir kein Werkzeug der Welt, das Modell zu retten.

Wann das Wasserfallmodell trägt — und wann es dich kostet

Prüf drei Bedingungen. Sind alle drei erfüllt, ist das Wasserfallmodell nicht nur zulässig, sondern die bessere Wahl. Fällt eine weg, wird es riskant.

Erstens: Sind die Anforderungen präzise beschreibbar — heute? Nicht ungefähr. Präzise genug, dass ein Dritter danach bauen könnte. Bei einer Halle, einer Maschine, einer gesetzlich vorgegebenen Schnittstelle: ja. Bei einem Produkt, dessen Nutzer du noch nicht kennst: nein.

Zweitens: Sind späte Änderungen teuer oder unmöglich? Genau dafür ist das Modell aus dem Bauwesen gekommen. Wenn eine Änderung im letzten Drittel Beton aufstemmen bedeutet, ist Vorausdenken kein Bürokratismus, sondern Wirtschaftlichkeit.

Drittens: Ist die Laufzeit überschaubar? Je länger ein Wasserfallprojekt läuft, desto größer die Lücke zwischen dem, was am Anfang gefordert wurde, und dem, was am Ende gebraucht wird. Unter sechs Monaten ist die Lücke meist verkraftbar. Über zwei Jahre wird sie zum eigentlichen Projektrisiko.

Typische Projekte, in denen das Wasserfallmodell trägt: Bauvorhaben, Anlagen- und Maschinenbau, Zertifizierungen, Betriebsprüfungen, ERP-Migrationen mit fixem Stichtag, alles mit gesetzlicher Frist. Typische Projekte, in denen es kostet: neue Produkte, neue Märkte, alles mit unklarer Nutzerreaktion, alles, wo die erste Version absehbar nicht die letzte ist.

Der Mittelstands-Fall, den du wahrscheinlich kennst

Ein Betrieb mit 40 Mitarbeitern stellt sein Warenwirtschaftssystem um. Der Anbieter schickt ein 60-seitiges Pflichtenheft, der Geschäftsführer unterschreibt, weil er es nicht Zeile für Zeile prüfen kann. Neun Monate später geht das System live, und die Buchhaltung stellt fest, dass die Nachlassstaffel für Stammkunden nicht abgebildet ist — sie stand nirgends, weil sie „schon immer so gemacht" wurde.

Das ist kein Softwarefehler. Das ist Phase 1. Und es ist der Grund, warum ein Wasserfallprojekt so gut wird wie die Abläufe, die du vorher beschrieben hast. Wer seine eigenen Prozesse nicht kennt, kann sie auch nicht spezifizieren.

Wasserfallmodell und Risiko: wo das Modell blind macht

Das Wasserfallmodell verschiebt Risiko nach hinten. Das ist seine gefährlichste Eigenschaft, und sie ist strukturell, nicht behebbar durch mehr Disziplin.

In einem iterativen Verfahren zeigt sich nach vier Wochen, ob die Idee trägt. Im Wasserfallmodell zeigt es sich im Systemtest — nach acht Monaten, mit acht Monaten investiertem Geld. Bis dahin liefert das Projekt grüne Statusberichte, weil alle Phasen termingerecht abgeschlossen wurden. Abgeschlossen heißt aber nur: Dokument abgenommen. Nicht: funktioniert.

Drei Gegenmaßnahmen, die du in jedem Wasserfallprojekt einziehen kannst:

• Prototyp vor der Freigabe. Royces erster Vorschlag von 1970. Ein Muster, ein Klickdummy, ein Musterbauteil — irgendetwas Anfassbares, bevor das Lastenheft unterschrieben wird.
• Testplanung parallel zur Anforderungsphase. Wer die Abnahmekriterien schreibt, während er die Anforderungen schreibt, merkt sofort, welche Anforderung nicht prüfbar formuliert ist.
• Reviews mit dem Auftraggeber an jedem Meilenstein. Nicht Statusbericht, sondern Ansicht des Zwischenstands. Fünfzehn Minuten Ansehen ersparen dir drei Wochen Nacharbeit.

Und darüber hinaus gehört jedes Projekt mit langer Vorlaufzeit in dein Risikomanagement: Welches Risiko trägt das Projekt, wer merkt es zuerst, und ab welcher Schwelle wird abgebrochen? Der teuerste Fehler im Wasserfallmodell ist nicht das falsche Projekt. Es ist das falsche Projekt, das niemand abbrechen darf, weil schon so viel investiert wurde.

Wie sich das Wasserfallmodell zu agilen Verfahren verhält

Kurz: Das Wasserfallmodell plant vorne, agile Verfahren lernen unterwegs. Beides sind Antworten auf dieselbe Frage — wie gehe ich mit Unsicherheit um — nur mit umgekehrtem Vorzeichen.

Das Wasserfallmodell reduziert Unsicherheit, indem es sie vorne wegarbeitet: analysieren, spezifizieren, freigeben. Danach ist der Weg fest. Agile Verfahren akzeptieren Unsicherheit und bauen kurze Rückkopplungsschleifen ein: liefern, zeigen, anpassen, wieder liefern. Das Agile Manifest formuliert das seit 2001 in vier Werten — unter anderem funktionierende Software über umfassende Dokumentation und Reagieren auf Veränderung über das Befolgen eines Plans. Das ist ausdrücklich keine Absage an Dokumentation und Plan, sondern eine Gewichtung.

Praktisch heißt das: Ein agiles Vorgehen liefert nach jedem Sprint etwas Nutzbares und passt den Rest an. Das Wasserfallmodell liefert einmal — dafür genau das, was bestellt war. Welche Methodenfamilie hinter „agil" steckt und wie sie im Mittelstand aussieht, steht im Überblick zum agilen Projektmanagement. Wie das konkret in einem Rahmenwerk mit Rollen, Ereignissen und Artefakten funktioniert, steht bei Scrum. Und die Frage, welches Vorgehen für welches Vorhaben in deinem Unternehmen das richtige ist, führt der Leitfaden zum Projektmanagement aus — sie gehört nicht in einen Artikel über ein einzelnes Modell.

Das V-Modell: der Wasserfall mit eingebauter Prüfung

Eine Weiterentwicklung, die du kennen solltest, weil sie im öffentlichen Sektor und in der Industrie Standard ist: das V-Modell. Es nimmt dieselbe Phasenfolge, klappt sie zur Mitte hin und stellt jeder Spezifikationsphase auf der linken Seite eine Teststufe auf der rechten Seite gegenüber. Anforderungsanalyse gegen Abnahmetest, Grobentwurf gegen Systemtest, Feinentwurf gegen Integrationstest.

Der Effekt: Beim Schreiben jeder Spezifikation muss festgelegt werden, wie sie später geprüft wird. Damit ist Royces zweiter Vorschlag — Test planen statt Test hinten anhängen — im Modell verankert statt der Disziplin überlassen.

Das Wasserfallmodell im Werkzeugkasten

Das Wasserfallmodell ist ein Ablaufmodell. Es sagt dir, in welcher Reihenfolge gearbeitet wird — nicht, was zu tun ist und wann genau. Dafür brauchst du zwei weitere Werkzeuge, und die Aufteilung ist sauber:

• Der Projektstrukturplan beantwortet das Was. Er zerlegt das Projekt in Teilaufgaben und Arbeitspakete, ohne Termine.
• Das Gantt-Diagramm beantwortet das Wann. Es legt die Arbeitspakete auf eine Zeitachse, mit Abhängigkeiten und Meilensteinen.

Das Wasserfallmodell und das Gantt-Diagramm sind dabei ein natürliches Paar: Weil die Phasen nacheinander laufen und jede mit einem Meilenstein endet, lässt sich ein Wasserfallprojekt fast eins zu eins als Balkenplan zeichnen. Bei iterativen Verfahren ist das deutlich unhandlicher — dort verschiebt sich der Inhalt der Balken laufend.

Was das Wasserfallmodell dagegen nicht ersetzt: die Klärung, wer entscheidet. Phasenübergänge brauchen einen Abnehmer mit Namen, nicht ein Gremium mit Kalenderkonflikten. Wer diese Namen einmal sauber verteilen will, macht das mit der RACI-Matrix — eine halbe Stunde Arbeit, und jede Phasenabnahme hat danach genau einen Verantwortlichen. Und was in deinem Unternehmen wiederkehrend abläuft, gehört gar nicht in ein Projekt, sondern ins Prozessmanagement — Projekte sind einmalig, Prozesse wiederholen sich. Wer diesen Unterschied nicht macht, startet jedes Jahr dasselbe Projekt neu.

Die fünf häufigsten Fehler mit dem Wasserfallmodell

Aus der Praxis, nicht aus dem Lehrbuch. Diese fünf sehe ich am häufigsten, wenn ein Wasserfallprojekt aus dem Ruder läuft:

1. Die Anforderungsphase wird abgekürzt. Weil sie sich anfühlt, als würde nichts passieren. Genau hier entscheidet sich das Projekt. Wer Phase 1 halbiert, verdreifacht Phase 4.

2. Der Meilenstein wird abgenickt statt abgenommen. „Passt schon, wir sind im Verzug" — und drei Phasen später fällt auf, dass es nicht passte. Ein Meilenstein ohne echte Prüfung ist ein Termin, kein Steuerungspunkt. Wie du Steuerungspunkte überhaupt mit Zahlen hinterlegst, statt sie abzunicken, steht im Controlling.

3. Niemand ist zuständig für den Rücksprung. Es ist im Vorfeld nicht geregelt, wer entscheidet, ob bei einem Fund im Test zurückgesprungen wird. Also entscheidet der Termindruck. Immer.

4. Der Auftraggeber wird zwischen Freigabe und Abnahme nicht mehr gesehen. Das strenge Modell sieht das so vor. Royce hielt genau das für den Kernfehler. Bau Reviews ein, auch wenn das Modell sie nicht verlangt.

5. Das Modell wird gewählt, weil es bequem ist. Wasserfall wirkt ordentlich. Ordentlich ist nicht dasselbe wie richtig. Wenn deine Anforderungen unklar sind, macht ein Phasenplan sie nicht klarer — er versteckt nur, dass sie unklar sind.

Der gemeinsame Nenner aller fünf: Das sind Führungsfehler, keine Methodenfehler. Das Wasserfallmodell steuert Arbeit — es steuert keine Menschen. Das bleibt deine Aufgabe.

Wenn du Projekte neben dem Tagesgeschäft sauber durchziehen willst, brauchst du keine Methodendebatte, sondern Werkzeuge, die am Montag funktionieren. Genau dafür haben wir das Unternehmer-Paket gepackt: sieben Anleitungen für mehr Umsatz und klarere Steuerung im eigenen Betrieb — aus 35 Jahren Vertrieb und dem, was in Bochum mit über 70 Mitarbeitern täglich läuft. Kostenlos, direkt zum Download. Hol es dir und arbeite die Punkte durch, die bei dir gerade klemmen.

Häufige Fragen zum Wasserfallmodell

Was ist das Wasserfallmodell einfach erklärt?

Ein Projektablauf in festen Phasen, die nacheinander abgearbeitet werden. Jede Phase endet mit einem Dokument, das abgenommen wird und für die nächste Phase verbindlich ist. Zurück geht es im strengen Modell nicht — deshalb das Bild vom Wasserfall, dessen Wasser nur nach unten fällt. Verbreitet ist heute die Variante mit Rücksprung, die einen Schritt zurück erlaubt, wenn eine frühere Entscheidung sich als falsch erweist.

Welche Phasen hat das Wasserfallmodell?

Die klassische Fassung hat fünf: Anforderungsanalyse, Systementwurf, Umsetzung mit Modultests, Integrations- und Systemtest, Auslieferung mit Wartung. Eine verbreitete Variante teilt feiner in sechs Phasen — Planung, Definition, Entwurf, Implementierung, Test, Einsatz und Wartung. Die Logik ist dieselbe, nur die Schnittführung unterscheidet sich. Entscheidend ist nicht die Anzahl, sondern dass jede Phase mit einem abnehmbaren Ergebnis endet.

Was sind die Vorteile und Nachteile des Wasserfallmodells?

Vorteile: klare Phasen, einfache Planung und Kontrolle, belastbare Kosten- und Terminaussage bei stabilen Anforderungen, lückenlose Dokumentation und damit Nachweisbarkeit. Nachteile: unflexibel gegenüber Änderungen, Anforderungen müssen früh feststehen, später Nutzen und später Return on Investment, Fehler zeigen sich erst im Test am Ende, und der Auftraggeber ist zwischen Freigabe und Abnahme lange außen vor.

Ist das Wasserfallmodell veraltet?

Nein — es ist begrenzt. In Bauvorhaben, im Anlagenbau, bei Zertifizierungen und überall dort, wo Anforderungen präzise feststehen und späte Änderungen teuer sind, ist es weiterhin die wirtschaftlichere Wahl. Veraltet ist nur die strenge Fassung ohne Rücksprünge, ohne Prototyp und ohne Kundenreviews — also genau die Fassung, vor der Winston Royce schon 1970 gewarnt hat.

Wer hat das Wasserfallmodell erfunden?

Die erste formale Beschreibung wird Winston W. Royce zugeschrieben, der sie 1970 veröffentlichte — allerdings ohne den Begriff „Wasserfall" zu verwenden und ausdrücklich mit dem Hinweis, dass der streng sequenzielle Ablauf riskant sei. Eine frühere Beschreibung eines solchen Ablaufs für Software stammt von Herbert D. Benington aus dem Jahr 1956. Das Grundprinzip selbst ist älter und stammt aus Bau- und Produktionsprozessen.