Erweitertes Wasserfallmodell

Das Wasserfallmodell ist ein lineares (nicht-iteratives) Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in Phasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase ein.

Im Wasserfallmodell hat jede Phase vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft. In der betrieblichen Praxis gibt es viele Varianten des reinen Modells. Es ist aber das traditionell am weitesten verbreitete Vorgehensmodell.

Der Name „Wasserfall“ kommt von der häufig gewählten grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen.

Ein erweitertes Wasserfallmodell mit Rücksprungmöglichkeiten (gestrichelt)

Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) führen iterative Aspekte ein und erlauben ein schrittweises „Aufwärtslaufen“ der Kaskade, sofern in der aktuellen Phase etwas schieflaufen sollte, um den Fehler auf der nächsthöheren Stufe beheben zu können.

Das Wasserfallmodell wird allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen.

Winston Royce beschreibt das Wasserfallmodell in seiner Publikation Managing the Development of Large Software Systems aus dem Jahr 1970 als fehlerträchtiges und kostenrisikobehaftetes Modell der Softwareentwicklung; dabei bezieht er sich sowohl auf die einfache Variante als auch auf die erweiterte mit schrittweise erfolgenden Rücksprungmöglichkeiten. Stattdessen schlägt Royce in dieser Publikation ein wesentlich um iterative Elemente erweitertes Modell vor.

Phasen

1. Anforderungsanalyse und -spezifikation (engl. Requirement analysis and specification)
2. Systemdesign und -spezifikation (engl. System design and specification)
3. Programmierung und Modultests (engl. Coding and module testing)
4. Integrations- und Systemtest (engl. Integration and system testing)
5. Auslieferung, Einsatz und Wartung (engl. Delivery, deployment and maintenance)

Eine andere Variante macht daraus sechs Schritte:

1. Planung (mit Erstellung des Lastenhefts, Projektkalkulation und Projektplan) (engl. Systems Engineering)
2. Definition (mit Erstellung des Pflichtenhefts, Produktmodell, GUI-Modell und evtl. schon Benutzerhandbuch) (engl. Analysis)
3. Entwurf (UML, Struktogramme) (engl. Design)
4. Implementierung (engl. Coding)
5. Testen (engl. Testing)
6. Einsatz und Wartung (engl. Maintenance)

„Definition und Entwurf“ entsprechen dabei ungefähr dem untergliederten Punkt „Systemdesign und -spezifikation“ in der ersten Variante, während die zweite Variante die zwei möglichen Ebenen des Software Testing (auf Modul- und Gesamtsystemebene) zusammenfasst.

Eigenschaften

1. Jede Aktivität ist in der vorgegebenen Reihenfolge und in der vollen Breite vollständig durchzuführen.
2. Am Ende jeder Aktivität steht ein fertiggestelltes Dokument, d.h. das Wasserfall-Modell ist ein "dokument-getriebenes" Modell.
3. Der Entwicklungsablauf ist sequenziell, d.h. jede Aktivität muss beendet sein, bevor die nächste anfängt.
4. Es orientiert sich am sogenannten top-down-Verfahren.
5. Es ist einfach, verständlich und benötigt nur wenig Managementaufwand.
6. Eine Benutzerbeteiligung ist nur in der Anfangsphase vorgesehen, anschließend erfolgen der Entwurf und die Implementierung ohne Beteiligung des Benutzers bzw. Auftraggebers. Weitere Änderungen stellen danach Neuaufträge dar.

Vorteile

• klare Abgrenzung der Phasen
• einfache Möglichkeiten der Planung und Kontrolle
• bei stabilen Anforderungen und klarer Abschätzung von Kosten und Umfang sehr effektives Modell

Nachteile und Probleme

• Abgrenzungsproblem
  Klar voneinander abgegrenzte Phasen sind unrealistisch - der Übergang zwischen ihnen ist in Wirklichkeit fließend: Teile eines Systems können sich noch in der Planung befinden, während andere schon in der Ausführung oder im Gebrauch sind.
• Abfolgeproblem
  Einzelne Phasen laufen in der Theorie nacheinander ab, in der Praxis sind jedoch Rückschritte oft unvermeidlich.
• Angemessenheitsproblem
  Je allgemeiner ein Schema ist, auf desto mehr Projekte ist es anwendbar - aber desto weniger Information ist in ihm enthalten. Je konkreter/detaillierter ein Schema ist, desto festgelegter ist es und auf desto weniger Projekte ist es anzuwenden.

• Das Modell ist nur auf einfache Projekte anwendbar
• Unflexibel gegenüber Änderungen und im Vorgehen (Phasen müssen sequenziell abgearbeitet werden)
• Frühes Festschreiben der Anforderungen ist sehr problematisch → eventuell teure Änderungen (mehrmalig wiederholtes Durchlaufen des Prozesses bei Änderungen)
• Einführung des Systems sehr spät nach Beginn des Entwicklungszyklus → später return on investment
• Fehler werden unter Umständen erst spät erkannt (Big Bang) und müssen mit erheblichem Aufwand entfernt werden

Da es schwierig ist, bereits zu Projektbeginn alles endgültig und im Detail festzulegen, besteht das Risiko, dass die letztendlich fertiggestellte Software nicht den tatsächlichen Anforderungen entspricht. Um dem zu begegnen, wird oftmals ein unverhältnismäßig hoher Aufwand in der Analyse- und Konzeptionsphase betrieben. Zudem erlaubt das Wasserfallmodell nicht bzw. nur sehr eingeschränkt, im Laufe des Projekts Änderungen aufzunehmen. Die fertiggestellte Software bildet folglich nicht den aktuellen, sondern den Anforderungsstand zu Projektbeginn wieder. Da größere Softwareprojekte meist auch eine sehr lange Laufzeit haben, kann es vorkommen, dass eine neue Software bereits zum Zeitpunkt ihrer Einführung inhaltlich veraltet ist.

Andere Vorgehensmodelle

Wegen der teilweise gravierenden Nachteile des Wasserfallmodells mit teilweise erheblichen wirtschaftlichen Konsequenzen hat die IT-Industrie eine Vielfalt alternativer oder ergänzender Vorgehensweisen, Softwaretechnologien, Vorschläge und Hilfsmittel entwickelt. Beispiele hierfür sind:

• Das Spiralmodell (Weiterentwicklung)
• Rational Unified Process
• Extreme Programming
• Agile Softwareentwicklung
• Iteratives Prototyping und Evolutionäres Prototyping
• Weitgehende Verwendung von konfigurierbarer Standardsoftware, z. B. für das Workflow-Management, die Benutzerverwaltung u.v.a.
• Universal Application
• Auf die Entwicklungsphase ausgeweitetes Veränderungsmanagement
• Auslagerung weniger priorisierter Teilaufgaben an Power User, siehe auch unter End-user Computing
• Ausgeprägte Modularisierung, bis hin zum Aufsplitten großer in kleinere, besser überschaubare Projekte mit kurzer Laufzeit
• V-Modell

Siehe auch

• Liste von Softwareentwicklungsprozessen
• Generik

Weblinks

• Institut für Gestaltungs- und Wirkungsforschung: Beschreibung Wasserfallmodell
• Dr. Winston W. Royce: Managing the developement of large Software Systems (436 KB)