Zum Inhalt springen

Wasserfallmodell

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 17. Februar 2017 um 13:50 Uhr durch Fabian42 (Diskussion | Beiträge) (→Geschichte). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Das Wasserfallmodell im Projektmanagement

Das Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell, insbesondere für die Softwareentwicklung, das in Phasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächsttiefere 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 ein traditionell weit verbreitetes Vorgehensmodell.

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

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.

Geschichte

Das Wasserfallmodell stammt ursprünglich aus dem Bau- und Produktionsprozess, hochstrukturierte Prozesse für Aufgaben, in denen späte Änderungen prohibitiv teuer oder sogar unmöglich sind. Nachdem damals kein formaler Softwareentwicklungsprozess existierte, wurden die dort verwendeten Prozesse einfach für Softwareentwicklung adaptiert.[1]

Die erste bekannte Beschreibung des Wasserfallmodells in der Softwareentwicklung wurde von Herbert D. Benington beim Symposium on advanced programming methods for digital computers am 29. Juni 1956 im Rahmen eines Vortrages über die Entwicklung einer Software für SAGE gegeben.[2] 1983 wurde der Vortrag neu aufgelegt, mit einem Vorwort von Benington, in dem er beschreibt, dass der Prozess nicht strikt von oben nach unten durchgespielt wurde, sondern auf einem Prototyp basierte.[3]

Die erste formale Beschreibung des Wasserfallmodells wird Winston W. Royce zugeschrieben, obwohl dieser in seinem 1970 erschienenen Artikel den Namen „Wasserfall“ nicht verwendete.[4] Er beschrieb das Modell als verbesserungswürdig und schlug folgende Änderungen vor:

  • Einfügen einer Designphase, die der Analysephase vorgelagert ist, in der eine frühe Simulation (Prototyp) des schlussendlichen Produktes ebenfalls mittels desselben Modells umgesetzt und dokumentiert wird.
  • Planung, Messung und Monitoring des Tests, um sicherzustellen, dass der Test seinen Aufgaben nachkommt.
  • Formale und laufende Einbeziehung des Kunden in Form von Reviews.

Phasen

  1. Anforderungsanalyse und -spezifikation (engl. Requirement analysis and specification) resultiert im Lastenheft
  2. Systemdesign und -spezifikation (engl. System design and specification) resultiert in der Softwarearchitektur
  3. Programmierung und Modultests (engl. Coding and module testing) resultiert in der eigentlichen Software
  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. Aktivitäten sind 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 Wasserfallmodell ist ein „dokumentgetriebenes“ 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 und verständlich.
  6. Eine Benutzerbeteiligung ist 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 effizientes Modell

Probleme und Nachteile

  • Abgrenzungsproblem: Klar voneinander abgegrenzte Phasen sind häufig unrealistisch – der Übergang zwischen ihnen ist 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.
  • Unflexibel gegenüber Änderungen und im Vorgehen (Phasen müssen sequenziell abgearbeitet werden)
  • Frühes Festschreiben der Anforderungen ist oft problematisch, da es eventuell zu teuren Änderungen führt (mehrmals wiederholtes Durchlaufen des Prozesses bei Änderungen)
  • Einführung des Systems sehr spät nach Beginn des Entwicklungszyklus, deshalb ein später Return on Investment
  • Fehler werden unter Umständen 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 das letztendlich fertiggestellte Ergebnis (z. B. 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. Das fertiggestellte Ergebnis bildet folglich nicht den aktuellen, sondern den Anforderungsstand zu Projektbeginn ab. Da größere Softwareprojekte meist auch eine sehr lange Laufzeit haben, kann es vorkommen, dass die 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:

Siehe auch

Literatur

  • Karl Pfetzing, Adolf Rohde: Ganzheitliches Projektmanagement. 5. Auflage. Gießen 2014, ISBN 978-3-921313-90-9.

Einzelnachweise

  1. ↑ Herbert D. Benington: Production of Large Computer Programs. In: IEEE Educational Activities Department (Hrsg.): IEEE Annals of the History of Computing. Band 5, Nr. 4, 1. Oktober 1983, S. 350–361, doi:10.1109/MAHC.1983.10102 (englisch, usc.edu [PDF; abgerufen am 13. Juni 2013]).
  2. ↑ United States Navy Mathematical Computing Advisory Panel (Hrsg.): Symposium on advanced programming methods for digital computers. 26. Juni 1956, OCLC 10794738 (englisch).
  3. ↑ Herbert D. Benington: Production of Large Computer Programs. In: IEEE Annals of the History of Computing. Band 5, Nr. 4. IEEE Educational Activities Department, 1. Oktober 1983, S. 350–361, doi:10.1109/MAHC.1983.10102 (englisch, usc.edu [PDF; abgerufen am 13. Juni 2013]).
  4. ↑ Winston Royce: Managing the Development of Large Software Systems. Hrsg.: Proceedings, IEEE WESCON. 26. Auflage. Institute of Electrical and Electronics Engineers, August 1970, S. 328–338 (englisch, typepad.com [PDF; abgerufen am 13. Juni 2013]).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wasserfallmodell&oldid=162731343“