Wasserfallmodell

Dieser Abschnitt stellt das Vorgehen nach dem Wasserfallmodell vor. Es beschreibt, wie dabei mit Anforderungen umgegangen wird. Das Wasserfallmodell steht im starken Kontrast zu agilen Methoden.

Wasserfallmodell: Anforderungen -> Analyse -> Design -> Codierung -> Test

Abbildung 3: Wasserfallmodell

 

Abbildung 3 zeigt das Wasserfallmodell. Es ist ein lineares Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in einzelnen, festen Phasen organisiert wird. Dabei gelten die Phasenergebnisse immer als bindende Vorgaben für die nächste Phase. Jede Phase muss komplett abgeschlossen sein, damit die nächste beginnen kann. Dazu produziert jede Phase als Ergebnis ein ausführliches Dokument oder Programm.

Erweitertes Wasserfallmodell: Systemanalyse <-> Software-Spezifikation <-> Architekturentwurf <-> Feinentwurf und Codierung <-> Integration und Test <-> Installation und Abnahme -> Betrieb und Wartung

Abbildung 4: Erweitertes Wasserfallmodell nach Royce

 

Im Grundmodell sind keine Rücksprünge in vorherige Phasen möglich. Abbildung 4 zeigt das erweiterte Wasserfallmodell nach Royce – hier sind Rücksprünge erlaubt. Allerdings müssen dabei meist alle Arbeiten der aktuell laufenden Phase verworfen werden.

Das Wasserfallmodell stellt den Ablauf zu einem realen, physischen Projekt dar, beispielsweise einem Hausbau. Zu Beginn wird das Fundament gelegt, danach die Mauern gezogen, am Ende das Dach aufgesetzt. An diesem Beispiel wird deutlich: Je später eine fehlerhafte Spezifikation erkannt wird, desto schwieriger und teurer ist die Behebung. Sollten in späten Phasen falsche Annahmen oder Mehrdeutigkeiten während der Analysephase bekannt werden, ist oft ein Projektabbruch die einzige Möglichkeit zur Schadensbegrenzung. Dies ist insbesondere bei umfangreichen Entwicklungen problematisch, da ein kompletter Durchlauf des Modells in diesen Fällen einige Jahre dauern kann. Spätestens mit Abschluss der Entwurfsphase kann kaum noch auf geänderte Anforderungen reagiert werden.

In Bezug auf Flexibilität von Anforderungen lässt sich das Wasserfallmodell wie folgt kategorisieren:

  • Die einzelnen Phasen müssen klar voneinander abzugrenzen sein und dürfen nur sequenziell nacheinander bearbeitet werden.
  • Durch die sehr eingeschränkte Möglichkeit, die Ergebnisse bereits abgeschlossener Phasen nachträglich zu ändern, ist eine geringe Flexibilität auf geänderte Anforderungen möglich. Dies ist insbesondere bei langlaufenden Projekten, bei denen sich Anforderungen und auch Rahmenbedingungen ändern, problematisch.Das Modell ist »dokumentgetrieben«, es legt großen Wert auf die
  • Dokumentation der Vorgänge und Ergebnisse. Dies kann einen großen Aufwand darstellen.

Fazit zum Einsatz des Wasserfallmodells

Das Wasserfallmodell ist allgemein in den Projekten geeignet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen und sich auch im Laufe der Entwicklung wenig ändern. Ändern sich die Anforderungen in einer der späteren Phasen, erhält man entweder ein Produkt, das diesen Anforderungen nicht genügt, oder die gesamte Entwicklung muss aufgegeben und komplett neu begonnen werden.

Dies steht im Gegensatz zu modernen Entwicklungen in der EDV sowie der Wirtschaft allgemein, in der flexible Reaktionen auf sich schnell ändernde Begebenheiten sehr oft essentiell und überlebenswichtig sind.

Schon Winston Royce beschrieb 1970 sein Wasserfallmodell ausdrücklich als nur für einfache Projekte geeignet.

Quelle: Winston Royce, Managing the development of large software systems, Proceedings of IEEE Westcon, 1970

Lade dir hier unser

Über itemis

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.