Wasserfallmodell
Das Wasserfallmodell bezeichnet ein Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozesses in Phasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase ein.
Zuerst vorgeschlagen wurde es in einem Paper aus dem Jahr 1970 von Winston Royce mit dem Titel Managing the Development of Large Software Systems: Concepts and Techniques. Im Wasserfallmodell hat jede Phase wohldefinierte 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 verbreiteste Vorgehensmodell.
Der Name "Wasserfall" kommt von der häufig gewählten grafischen Darstellung der fünf bis sechs Punkte in einer Kaskade.
Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) erlauben ein schrittweises "Aufwärtslaufen" der Kaskade, sofern in der aktuellen Phase etwas schieflaufen sollte, um den Fehler auf der nächsthöheren Stufe ausmerzen zu können.
Das Wasserfallmodell wird allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungphase relativ präzise beschreiben lassen.
Die Phasen des Wasserfallmodells
- Anforderungsanalyse und -spezifikation (engl. Requirement analysis and specification)
- Systemdesign und -spezifikation (engl. System design and specification)
- Programmierung und Modultests (en. Coding and module testing)
- Integration und Systemtest (engl. Integration and system testing)
- Auslieferung, Einsatz und Wartung (engl. Delivery and maintenance)
Eine andere Variante macht daraus sechs Schritte:
- Planung (mit Erstellung des Lastenhefts, Projektkalkulation und Projektplan) (engl. Systems Engineering)
- Definition (mit Erstellung des Pflichtenhefts, Produktmodell, GUI-Modell und evtl. schon Benutzerhandbuch) (engl. Analysis)
- Entwurf (UML, Struktogramme) (englisch: Design)
- Implementierung (engl. Coding)
- Testen (engl. Testing)
- 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) zusammenwirft.
Nachteile des Wasserfallmodells
- Sequenz
- Phasentrennung
- späte Verfügbarkeit von Produkten
Da es schwierig ist, bereits zu Projektbeginn alles endgültig und im Detail festzulegen, besteht zudem 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 z.T. 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:
- 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 Change Management
- 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