Waterfall Model

Das Ur-Modell der Softwareentwicklung (1970). Wie beim Bau eines Hauses:

Architekt: Plan zeichnen. (Darf nicht geändert werden).
Maurer: Wände hochziehen.
Maler: Anstreichen. Du kannst nicht streichen, bevor die Wand steht. Und wenn das Dach drauf ist, kannst du den Keller nicht mehr ändern. In Software heißt das: Requirements -> Design -> Coding -> Testing -> Maintenance. Wasser fließt nur nach unten. Zurückgehen ist teuer/unmöglich.

Merksatz: Ein lineares Vorgehensmodell, bei dem Softwareentwicklung in aufeinanderfolgende Phasen unterteilt ist, wobei jede Phase abgeschlossen sein muss, bevor die nächste beginnt.

Heute gilt es als veraltet für Software (weil Kunden ihre Meinung ständig ändern). Aber für Hardware oder kritische Systeme (Raumfahrt, Medizin, Brückenbau) ist es noch Standard. Du kannst keine Firmware patchen, wenn die Rakete schon explodiert ist. Hier muss vorher alles zu 100% geplant sein.

1. Das Missverständnis

Winston Royce, der "Erfinder", beschrieb das Modell als fehlerhaft! Er zeigte es als Beispiel ("So sollte man es nicht machen") und schlug vor, Rücksprünge (Loops) einzubauen. Die Industrie hat nur das erste Bild gesehen und es zum Standard erklärt (US DoD Std 2167). Ein historischer Unfall.

2. V-Modell

Eine Weiterentwicklung des Wasserfalls (Standard in Deutschland / Behörden). Zu jeder Phase links (Planung) gibt es eine Phase rechts (Testen).

Anforderung -> Abnahmetest.
Systemdesign -> Systemtest.
Unit Design -> Unit Test. Es erzwingt, dass man schon beim Planen überlegt: "Wie teste ich das?"

3. Waterfall vs. Agile

Waterfall: Big Bang Release. Man sieht nach 2 Jahren das Ergebnis. Risiko: Kunde sagt "Das wollte ich nicht."
Agile: Iterativ. Alle 2 Wochen ein kleines Release. Kurskorrektur möglich. Waterfall hat höhere Fixkosten bei Änderungen (Cost of Change Curve steigt exponentiell).

1. Critical Path Method (CPM)

Im Wasserfall-Modell nutzt man oft die Methode des kritischen Pfades. Man zeichnet alle Aufgaben und ihre Abhängigkeiten auf. Der "kritische Pfad" ist die Kette von Aufgaben, die am längsten dauert. Wenn sich eine Aufgabe auf diesem Pfad nur um einen Tag verzögert, verschiebt sich das gesamte Projektende. In agilen Projekten ist das egal, da man eh kontinuierlich liefert. Im Wasserfall ist das Management des kritischen Pfades die Hauptaufgabe des Projektleiters, um das "Big Bang" Release-Datum zu halten.

2. Das Gatekeeper-Prinzip

Ein Kernmerkmal von professionellem Wasserfall-Management (z. B. in der Pharma-Industrie) sind Quality Gates. Ein Projekt darf die Phase "Design" erst verlassen, wenn ein Gremium (Gatekeeper) alle Dokumente geprüft und unterschrieben hat. Das verhindert zwar "Wildwuchs" und sorgt für exzellente Dokumentation, führt aber oft zur Analyse-Paralyse: Das Team verbringt Monate damit, perfekte Dokumente zu schreiben, statt Code zu produzieren, nur um das Gate zu passieren.

3. Contractual Lock-in (Das finanzielle Risiko)

Wasserfall-Projekte basieren oft auf Festpreis-Verträgen. Gefahr: Wenn nach 6 Monaten (mitten in der Entwicklung) auffällt, dass ein technisches Detail im Plan unmöglich ist, beginnt eine rechtliche Schlammschlacht. Wer trägt die Kosten für die Planänderung? Agile Modelle lösen das durch "Time & Material" (Bezahlung nach Aufwand). Wasserfall erzwingt eine Scheinsicherheit: Man glaubt, man wisse am Tag 1 genau, was es am Ende kostet. In der Realität führen unvorhergesehene Probleme bei Wasserfall-Projekten oft zu gigantischen Budgetüberschreitungen.