Was ist Waterfall in einfachen Worten?
Waterfall ist ein linearer, sequenzieller Ansatz im Projektmanagement, bei dem Sie eine Phase vollständig abschließen, bevor Sie zur nächsten übergehen – wie Wasser, das eine Reihe von Stufen hinunterfließt. Sie sammeln zuerst alle Anforderungen, dann entwerfen Sie, dann bauen Sie, dann testen Sie, dann stellen Sie bereit. Es gibt kein Zurück. Es ist der Ansatz 'zweimal messen, einmal schneiden': umfangreiche Planung im Voraus, um spätere Änderungen zu vermeiden.
Waterfall beantwortet die Frage: 'Wie liefern wir ein vorhersehbares Ergebnis, wenn die Anforderungen klar und stabil sind?'
Der lineare Fluss: Warum es Waterfall genannt wird
Waterfall erhält seinen Namen von der visuellen Darstellung seines Prozesses – wie Wasser, das einen Felsen hinunterstürzt, kann man nicht gegen den Strom schwimmen. Sobald eine Phase mit Zustimmung der Stakeholder abgeschlossen ist, geht man unwiderruflich zur nächsten über. Ein Zurückgehen ist teuer und erfordert oft formale Änderungskontrollprozesse und Nacharbeit.
Das Wasserfall-Modell wurde erstmals 1970 von Winston W. Royce in einem Papier über Softwareentwicklung (obwohl er es ironischerweise eher kritisierte als befürwortete). Es wurde zur dominierenden Methodologie, weil es widerspiegelte, wie physische Produkte seit Jahrhunderten gebaut wurden – von der Architektur bis zur Fertigung.
Dieses Modell entstand aus der Fertigung und dem Bauwesen, wo physische Lieferobjekte die Iteration kostspielig machen. Man kann Beton nicht 'entgießen', eine Brücke nicht zurückbauen oder eine Million produzierte Einheiten billig zurückrufen. Die Annahme ist, dass Anforderungen im Voraus vollständig definiert werden können und stabil bleiben.
Die 5 Phasen von Waterfall (im Detail)
Jede Phase hat spezifische Lieferobjekte, die abgeschlossen und genehmigt werden müssen, bevor die nächste Phase beginnt. Dies schafft klare Meilensteine und Dokumentation bei jedem Schritt.
Anforderungserfassung & Analyse
Alle Anforderungen werden im Voraus detailliert erfasst, analysiert und dokumentiert. Dies führt typischerweise zu einem umfassenden Business Requirements Document (BRD) oder Software Requirements Specification (SRS), das von den Stakeholdern genehmigt wird. Ziel ist es, jede Funktion, Einschränkung und Akzeptanzkriterium zu erfassen, bevor das Design beginnt. Änderungen nach dieser Phase lösen formale Änderungskontrollprozesse aus.
Systemdesign
Basierend auf den Anforderungen erstellen Architekten und Designer detaillierte technische Spezifikationen. Für Software umfasst dies Systemarchitektur, Datenbankschemata, Schnittstellendesigns und technische Dokumentation. Für den Bau umfasst es Baupläne, technische Berechnungen und Materialspezifikationen. Diese Phase erstellt den 'Bauplan', der die Implementierung leitet.
Implementierung (Bau)
Die eigentliche Bau- oder Codierungsphase. Entwickler, Ingenieure oder Bauarbeiter erstellen das Produkt gemäß den Designspezifikationen. In der Software wird Code Modul für Modul geschrieben. Im Bauwesen beginnt die physische Arbeit. Der Schlüssel: Bauherren folgen dem Plan genau wie spezifiziert, mit minimalen Abweichungen.
Verifizierung (Testen)
Testen und Qualitätssicherung validieren, dass das Produkt die ursprünglichen Anforderungen erfüllt. Tester vergleichen die tatsächliche Funktionalität mit dem Anforderungsdokument. Fehler werden protokolliert, behoben und erneut getestet. Diese Phase dauert an, bis das Produkt vordefinierte Akzeptanzkriterien erfüllt. Das Testen erfolgt nach Abschluss des Baus – nicht währenddessen.
Bereitstellung & Wartung
Das fertige Produkt wird bereitgestellt oder an den Kunden geliefert. Das Projekt wird formell mit Dokumentation und Übergabe abgeschlossen. Die Wartung beginnt – Behebung von Fehlern, Updates und operativer Support. Das Produkt tritt in seinen Betriebslebenszyklus ein, der oft von einem anderen Team verwaltet wird.
Das „Eiserne“ Versprechen: Vorhersehbarkeit
Waterfalls größte Stärke ist die Vorhersehbarkeit. Da alles im Voraus geplant wird, können Sie drei kritische Fragen beantworten, bevor die Arbeit beginnt: 'Wie viel wird das kosten?' 'Wann wird es fertig sein?' und 'Was genau wird geliefert?' Deshalb bevorzugen CFOs, Beschaffungsabteilungen und Regierungsbehörden oft Waterfall – es ermöglicht Festpreisverträge, Budgetprognosen und klare Verantwortlichkeiten.
⚠️ Der Haken: Dieses Versprechen gilt nur, wenn sich der Umfang nicht ändert. Sobald sich die Anforderungen mitten im Projekt verschieben, verflüchtigt sich die Kosten- und Zeitplansicherheit – oft dramatisch.
Die Kostenkurve für Änderungen
Eines der wichtigsten Konzepte im Wasserfallmodell ist das Verständnis, wie die Kosten für Änderungen im Laufe des Projekts eskalieren. Das Beheben eines Fehlers oder das Ändern einer Anforderung kostet in späteren Phasen exponentiell mehr:
| Phase | Relative Cost | Why |
|---|---|---|
| Anforderungen | 1x | Ein Dokument zu ändern ist günstig |
| Design | 5x | Neugestaltung wirkt sich auf mehrere Systeme aus |
| Implementierung | 10x | Code neu zu schreiben oder neu zu bauen ist teuer |
| Verifizierung | 20x | Gefundene Fehler erfordern Regressionstests |
| Wartung | 100x | Änderungen in der Produktion wirken sich auf Benutzer aus |
Im Gegensatz dazu hält Agile diese Kosten relativ konstant, da Änderungen erwartet und kontinuierlich durch kurze Iterationen eingearbeitet werden.
Vor- und Nachteile von Waterfall
Vorteile
- Klare, vorhersehbare Meilensteine und Lieferobjekte
- Leicht verständlich und handhabbar für traditionelle Organisationen
- Gut dokumentierte Anforderungen unterstützen Compliance und Audits
- Ermöglicht Festpreisverträge und genaue Budgetierung
- Funktioniert gut, wenn Anforderungen wirklich stabil und gut verstanden sind
- Klare Übergaben zwischen spezialisierten Teams (Designer, Entwickler, Tester)
Herausforderungen
- •Späte Entdeckung von Problemen – Tests finden am Ende statt
- •Schwierig und teuer, Anforderungsänderungen zu berücksichtigen
- •Benutzer sehen das funktionierende Produkt erst sehr spät
- •Risiko, etwas zu liefern, das Benutzer eigentlich nicht wollen
- •Dokumentationslastiger Prozess kann den Fortschritt verlangsamen
- •Lange Time-to-Market, da nichts ausgeliefert wird, bis alles fertig ist
Wann Waterfall eingesetzt werden sollte
Waterfall ist die richtige Wahl, wenn bestimmte Bedingungen erfüllt sind:
Use Waterfall When:
- •Anforderungen sind kristallklar und werden sich voraussichtlich nicht ändern
- •Die Technologie ist ausgereift und gut verstanden
- •Die Einhaltung gesetzlicher Vorschriften erfordert eine umfangreiche Vorab-Dokumentation
- •Sie arbeiten mit Festpreisverträgen, die detaillierte Spezifikationen erfordern
- •Physische Lieferobjekte machen die Iteration kostspielig (Bau, Fertigung)
- •Stakeholder benötigen feste Budget- und Zeitplanzusagen im Voraus
Wann Waterfall möglicherweise nicht ideal ist
- •Anforderungen sind unklar oder werden sich voraussichtlich entwickeln
- •Sie entwickeln innovative Produkte, bei denen Lernen unerlässlich ist
- •Time-to-Market-Druck erfordert eine frühe Lieferung
- •Benutzer müssen während der Entwicklung Feedback geben
- •Die Projektumgebung ist dynamisch und unvorhersehbar
Praxisbeispiel: Bauprojekte
Der Bau einer Brücke ist das Paradebeispiel für ein Wasserfallprojekt. Bevor der Bau beginnt, verbringen Ingenieure Monate (manchmal Jahre) mit den Anforderungen: Verkehrsanalyse, Lastberechnungen, Umweltverträglichkeitsprüfungen und Genehmigungen der Stakeholder. Dann werden detaillierte Entwürfe erstellt – jede Schraube, jeder Träger und jedes Kabel wird spezifiziert. Erst nachdem die Baupläne genehmigt wurden, beginnt der physische Bau. Man kann das Fundament nicht gießen, mitten im Bau entscheiden, dass die Brücke 20 % länger sein soll, und von dort aus iterieren. Die Kosten für Änderungen im physischen Bau machen Waterfall nicht nur angemessen, sondern notwendig.
Wichtige Erkenntnisse
- 1Waterfall ist sequenziell und linear – jede Phase wird abgeschlossen, bevor die nächste beginnt
- 2Es glänzt, wenn Anforderungen stabil, gut definiert und unwahrscheinlich zu ändern sind
- 3Die Kosten für Änderungen steigen exponentiell im Laufe des Projekts
- 4Es bietet Vorhersehbarkeit für Budgetierung, Zeitplanung und Compliance
- 5Kein Misserfolg – nur für andere Umstände als Agile konzipiert
- 6Oft mit Agile in hybriden Ansätzen für komplexe Projekte kombiniert
