Das Wasserfallmodell einfach erklärt

Vom Wasserfallmodell hast du sicher schon einmal gehört – wird es doch oft als Synonym für klassisches Projektmanagement verwendet. Ein Projekt in feste Phasen unterteilen und von Anfang bis Ende anhand eines Plans umsetzen? Genau so stellen sich viele Projektmanager ihre Arbeit in einer idealen Welt vor.

In diesem Artikel erfährst du, wie das Wasserfallmodell entstanden ist, warum der „Erfinder“ es selbst kritisiert, für welche Projekte es sich eignet und welche Vor- und Nachteile es hat. Legen wir los!

Was ist das Wasserfall-Modell?

Was also hat es mit dem Wasserfallmodell auf sich? Wir schauen uns zwei Definitionen näher an und beginnen mit dem Gabler Wirtschaftslexikon. Demnach ist das Wasserfallmodell ein

„lineares Vorgehensmodell in der Softwareentwicklung, das sich in die sechs Phasen gliedert … Die einzelnen Phasen werden streng nacheinander ohne Iterationen durchlaufen.“

Gabler Wirtschaftslexikon

Zu den Phasen kommen wir später – zuerst lassen wir Wikipedia zu Wort kommen:

„Ein Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell, das insbesondere für die Softwareentwicklung verwendet wird und das in aufeinander folgenden Projektphasen organisiert ist.“

Wikipedia

Der Name ist Program: Das Projekt „fließt“ von Phase zu Phase, ohne Rücksprünge – bildlich wie ein Wasserfall dargestellt:

Ein Projekt, das nach dem Wasserfallmodell geplant und durchgeführt wird, weist üblicherweise folgende Merkmale auf:

• Es verläuft linear, also geradlinig in eine Richtung.
• Es besteht aus fest definierten Phasen.
• Jede dieser Phasen wir nur einmal durchlaufen.
• Sobald eine Phase abgeschlossen wurde, beginnt die nächste. Eine Überlappung ist in der strengen Definition nicht vorgesehen.
• Jede Phase endet mit einem vorher definierten Zwischenergebnis (Meilenstein).
• Jede Phase baut auf den Ergebnissen der vorherigen Phase auf.
• Das Projekt hat meist einen festen Start- und Endtermin.

Die praktische Verwendung des Begriffs

Obwohl das ursprüngliche Wasserfallmodell sich auf die Software-Entwicklung bezieht, wird der Begriff mittlerweile deutlich breiter verwendet. Mit dem Aufschwung von agilem Projektmanagement steht der Begriff „Wasserfall“ oft als Synonym für klassisches bzw. traditionelles Projektmanagement. Besonders im englischsprachigen Umfeld steht „Waterfall“ für alle nicht-agilen Ansätze – auch wenn eine Reihe anderer klassischer Vorgehensmodelle existieren.

Geschichte und Kritik am Begriff

Dieser Artikel wäre nicht vollständig, wenn wir nicht zumindest kurz auf die Herkunft des Modells eingehen würden. Häufig wird das Wasserfallmodell einem gewissen Dr. Winston W. Royce zugeschrieben, der 1970 den Artikel „Managing the development of large software systems“ veröffentlicht hat. Er skizziert zu Beginn des Artikels grafisch einen typischen Wasserfall, schränkt den praktische Nutzen aber sofort ein:

„I believe in this concept, but the implementation described above is risky and invites failure.“

Obwohl der Artikel als Grundlage für das Wasserfallmodell gilt, kommt darin das Wort „Waterfall“ selbst niemals vor. Stattdessen beschreibt Royce die Probleme des linearen Ansatzes und macht Vorschläge, wie ein iteratives Vorgehen die Software-Qualität erhöhen kann.

Wenn aber Royce den Begriff des Wasserfalls gar nicht geprägt und das damit verbundene Vorgehen sogar kritisiert hat – wo kommt er dann her? Ganz klar ist das nicht. Spätestens im Artikel „Software Requirements: Are they really a problem?“ wurde der Begriff 1976 erwähnt – in Anführungszeichen und mit Bezug auf Royce.

Achtung, für Spitzfindige: Heutzutage muss das Wasserfallmodell häufig als Gegenentwurf zu agilen Ansätzen herhalten. Allzugern wird in der Argumentation das streng lineare und sequenzielle Wasserfallmodell als repräsentativer Prototyp des klassischen bzw. traditionellen Projektmanagements dargestellt – und seine Nachteile pauschal auf das klassische Projektmanagement übertragen. Damit macht man es sich allerdings deutlich zu einfach. Zum einen, da selbst im Artikel von Royce (und vielen anderen traditionellen Quellen) bereits iterative Ansätze vorgeschlagen wurden. Zum anderen aber wird es deutlich, wenn man auf die Praxis des traditionellen Projektmanagements schaut: Häufiger als man denkt gibt es überlappende Phasen, oder es werden komplexe Entwicklungsprojekte unterteilt in z. B. eine „Machbarkeitsstudie“, eine „Prototypenentwicklung“ und eine „Anpassung beim Kunden“. Jeder Teil für sich ist zwar ein Wasserfall, aber in der Gesamtheit iterativ. Selbst Projekte, die von sich selbst behaupten „nach Wasserfall“ durchgeführt zu werden, erfüllen kurioserweise die strenge Definition des Wasserfalls häufig nicht.

Die Phasen des Wasserfallmodells

Wir bleiben zunächst bei der Software-Entwicklung, aus der sich die typischen Phasen des Wasserfallmodells ableiten. Je nach Komplexität der zu entwickelnden Software werden 5-7 Phasen beschrieben. Die fünf typischsten Phasen sehen so aus:

1. Anforderungsanalyse (Requirements): Je genauer die Anforderungen zu Beginn definiert werden, desto höher ist die Erfolgswahrscheinlichkeit im Projekt. Die Grundfrage: Was soll entwickelt werden?
2. Entwurf (Design): In dieser Phase werden die Anforderungen vom Projektteam in Spezifikationen umgesetzt. Anders gefragt: Wie wollen wir die Anforderungen umsetzen?
3. Implementierung (Implementation): Jetzt wird gearbeitet! Auf Basis der Spezifikation werden die Anforderungen umgesetzt – ein funktionierendes Produkt entsteht.
4. Test (Verification): Wurde alls wie geplant implementiert? Genau das wird in dieser Phase ermittelt. Jetzt finden alle Beteiligten heraus, ob das Produkt den ursprünglichen Anforderungen entspricht.
5. Inbetriebnahme und Wartung (Maintenance): Nach erfolgreichen Tests wird das Produkt in einer produktiven Umgebung eingesetzt sowie regelmäßig auftretende Fehler behoben.

Du siehst: Im Standard-Wasserfall gibt es insbesondere während der Design- und Implementierungsphase keinen kontinuierlichen Austausch zwischen den Produktentwicklern und dem Kunden.

Wie oben erwähnt, wird das Wasserfallmodell auch außerhalb der Software-Entwicklung verwendet, wenn auch nicht immer der streng sequenzielle Ansatz verfolgt wird. Typische Phasen für andere Projektarten findest du in diesem Artikel.

Für welche Projekte ist das Wasserfallmodell geeignet?

Wir gehen hier bewusst weg von der reinen Software-Entwicklung und schauen uns an, welche Eigenschaften ein Projekt haben sollte, wenn das Wasserfallmodell eingesetzt werden soll:

• Das Projekt lässt sich von Start bis Abschluss im Detail planen und linear abarbeiten.
• Die Anforderungen und Spezifikation sind von Beginn an klar und vollständig. Alle Beteiligten haben ein gemeinsames Verständnis über das Zielbild.
• Es ist ein fester Start- und Endtermin vorgesehen.
• Es werden wenige Änderungen oder unvorhergesehene Anpassungen erwartet.
• Das Projektumfeld ist hierarchisch geprägt mit langen Entscheidungswegen.
• Traditionell aufgestellte Unternehmen mit festen Strukturen tun sich mit einem solch klassischen Ansatz oft leichter als mit agilen Vorgehensmodellen.

Typische Beispiele sind die Organisation eines Messeauftritts oder der Bau eines Fertigteilhauses. In beiden Fällen sind die Anforderungen klar definiert und ein klarer Schritt-für-Schritt-Plan kann umgesetzt werden.

Zusammengefasst: Das Wasserfallmodell ist dann gut einsetzbar, wenn die Anforderungen eindeutig sind, Projektphasen im Detail geplant und bearbeitet werden können und ein fester Zeitplan verfolgt wird.

Die Vorteile des Wasserfallmodells

Auch wenn die praktische Umsetzung eines Projekts immer Hürden parat hat: So ein Wasserfall ist einfach gestrickt und hat eine Reihe von Vorteilen:

• Es ist leicht verständlich für alle Beteiligten.
• Besonders in Projekten mit geringem Änderungspotenzial gibt es eine hohe Planungssicherheit.
• Die Rahmenbedingungen wie Kosten und Termine sind klar festgezurrt.
• Der Projektfortschritt lässt sich am Erreichen von Meilensteinen ablesen.
• Der vorab definierte Plan gibt einen klaren Rahmen vor, dem alle Beteiligten folgen können.

Logisch: Auch was schön klingt, ist nicht für alle Projekte geeignet – was uns zu den Nachteilen bringt.

Die Nachteile des Wasserfallmodells

Viele der Nachteile liegen auf der Hand:

• Das Vorgehen ist starr und wenig flexibel.
• Fehler werden oft erst spät erkannt, da erst am Ende der Produktentwicklung eine Testphase stattfindet.
• Je komplexer das Projekt, desto schwieriger ist es, vorab einen detaillierten Plan aufzustellen.
• Feedback- und Korrekturschleifen sind nicht vorgesehen.
• Sind die Anforderungen nicht bis ins letzte Detail klar, können Fehldeutungen entstehen, die erst spät im Projekt ans Licht kommen.

Je komplexer das Projekt, je unklarer die Anforderungen und je größer die Anzahl der erwarteten Änderungen, desto schwieriger lässt sich ein Vorhaben in das strenge Korsett eines Wasserfalls zwängen.

Fazit

Das Wasserfallmodell stammt ursprünglich aus der Software-Entwicklung, wobei der Entwicklungsprozess in linear und sequenziell ablaufende Phasen aufgeteilt wurde. Das Vorgehensmodell ist dann besonders gut einsetzbar, wenn die Anforderungen im Detail bekannt sind und wenige Änderungen erwartet werden – was besonders im Software-Bereich eben nicht zutrifft. Auch aus diesem Grund wird der Begriff „Wasserfall“ häufig breiter auch für andere Projekttypen verwendet, in denen sich Phasen klar abgrenzen lassen.

Fragen und Antworten