Das Wasserfallmodell ist ein sequenzielles Vorgehensmodell, das die Entwicklung anhand aufeinanderfolgender Phasen organisiert. Es wurde 1970 von Royce vorgeschlagen und wurde von Boehm als „Wasserfallmodell“ bezeichnet, da Ergebnisse einer Phase immer in die folgende fließen. Entgegen der landläufigen Meinung, das Wasserfallmodell sei ein rein sequenzielles Vorgehen, gibt es zwischen den einzelnen Phasen Rückkopplungen, jedoch nur zur jeweils benachbarten, vorausgehenden Phase.
Grundkonzepte und Phasen
Die grundlegende Idee des Wasserfallmodells ist die Aufteilung des Projekts anhand der Entwicklungstätigkeiten in Phasen. Folgende Phasen werden im Wasserfallmodell verwendet:
- Analyse
- Architekturentwurf
- Implementierung
- Test
- Betrieb und Wartung
Das Wasserfallmodell gibt es in verschiedenen Ausprägungen (vgl. Chroust [Chroust 1992]). Die beiden bekanntesten sind das Phasenmodell nach Royce [Royce 1970] (einfache, ursprüngliche Version) und das Phasenmodell nach Boehm [Boehm 1981] (explizite Positionierung von Qualitätssicherung, feinere Gliederung der Anforderungserhebung und der Übergabe in den Betrieb). Die beiden Ausprägungen zeigen die gemeinsame Grundstruktur, aber auch die Abweichungen im Detail. Die Einordnung in die verschiedenen Phasen kann trotzdem problemlos erfolgen, obwohl die Ausgestaltungstiefe variiert.
Abb. 1: Wasserfallmodell nach Boehm
Abb. 2: Wasserfallmodell nach Royce
Jede dieser Phasen schließt mit einem
Meilenstein, zu dem eine definierte Ergebnismenge vorliegen muss. Jede Phase bündelt verschiedene Aktivitäten, die vollständig und in der richtigen Reihenfolge ausgeführt worden sein müssen. Am Ende jeder Aktivität liegt ein fertig gestelltes Ergebnis vor – in der Regel sind dies Dokumente, z.B. eine Architekturspezifikation. Da die Ergebnisse jeweils Eingaben für die folgenden Aktivitäten sind, müssen Aktivitäten auch vollständig abgeschlossen werden, bevor eine Folgeaktivität beginnt (eine zeitlich parallele Ausführung von Aktivitäten ist somit nur bedingt möglich).
Bewertung
Durch die streng sequenzielle Anordnung und die einfache Phasenstruktur haben Projekte, die dem Wasserfallmodell folgen, eine einfache Organisationsstruktur. Dem steht jedoch gegenüber, dass die Anwender des zu entwickelnden Systems nur zu Beginn im Rahmen der Analysephasen in das Projekt mit einbezogen sind. Damit lassen sich Anforderungen während der Entwicklung nur schwer ändern. Auch Analyse-, Planungs- und Entwicklungsfehler werden erst spät bemerkt. Insbesondere wenn Fehler Änderungen an Ergebnissen der frühen Phasen erfordern, ist das mit diesem Vorgehen nur schwer umzusetzen, da eine weit reichende Rückkopplung über mehrere Phasen hinweg nicht vorgesehen ist, Phasen aber auch nicht einfach abgebrochen werden und das Projekt an einer früheren Stelle wieder aufgesetzt werden kann. Hinzu kommt, dass in den seltensten Fällen alle Anforderungen von Anfang an präzise bekannt sind. Es ist somit nicht zielführend, alle Aktivitäten immer und in der vollen Breite auszuführen, was auch die eigentliche Aussage von Royce war. Da beim Wasserfallmodell der Projektablauf stark geregelt und auf die Erstellung von Dokumentation ausgerichtet ist, werden Projektrisiken erst spät oder gar nicht erkannt. Risiken sind aber gerade im Wasserfallmodell eine kritische Größe, da bei Eintreten eines Risikos in einer Phase alle folgenden und somit das gesamte Projekt verzögert werden. Darauf weist Royce bereits hin: “In my experience, however, the simpler method has never worked on large software development […].” [Royce 1970].
Nichtsdestoweniger ist das Wasserfallmodell die Grundlage für viele weitere strukturierte Vorgehensweisen. Durch seine Organisation in Phasen eignet es sich sehr gut für die Umsetzung bekannter, risikoarmer Verfahren, z.B. Ausschreibungs- und Auftragsverfahren der öffentlichen Hand (z.B. das V-Modell XT).
Literatur
Chroust, Gerhard: Modelle der Softwareentwicklung. Wien: Oldenbourg, 1992.
Boehm, Barry: Software Engineering Economics. Englewood Cliffs: Prentice Hall, 1981.
Royce, Winston: Managing the development of large Systems. IEEE Wescon, S. 1-9, 1970.
