Das Was­ser­fall­mo­dell

Als Was­ser­fall­mo­dell be­zeich­net man ein se­quen­zi­el­les Vor­ge­hens­mo­dell, mit dem sich Ent­wick­lun­gen anhand auf­ein­an­der­fol­gen­der Phasen abbilden lassen.

Das Was­ser­fall­mo­dell (englisch: waterfall model) ist ein lineares Vor­ge­hens­mo­dell, das Ent­wick­lungs­pro­zes­se in auf­ein­an­der­fol­gen­de Pro­jekt­pha­sen un­ter­teilt. Im Gegensatz zu ite­ra­ti­ven Modellen wird jede Phase nur einmal durch­lau­fen. Die Er­geb­nis­se einer jeden Vor­gän­ger­pha­se gehen als Vor­an­nah­men in die Fol­ge­pha­se ein. Zur Anwendung kommt das Was­ser­fall­mo­dell ins­be­son­de­re in der Software-Ent­wick­lung.

Die Ent­wick­lung des klas­si­schen Was­ser­fall­mo­dells wird dem Com­pu­ter­wis­sen­schaft­ler Winston W. Royce zu­ge­schrie­ben. Royce jedoch ist nicht der Erfinder. Statt­des­sen be­inhal­tet sein 1970 ver­öf­fent­lich­ter Aufsatz „Managing the De­ve­lo­p­ment of Large Software Systems“ eine kritische Aus­ein­an­der­set­zung mit linearen Vor­ge­hens­mo­del­len. Als Al­ter­na­ti­ve stellt Royce ein iterativ-in­kre­men­tel­les Modell vor, bei dem jede Phase auf die vor­her­ge­hen­de zu­rück­greift und deren Er­geb­nis­se ve­ri­fi­ziert.

Royce schlägt ein Modell mit sieben Phasen vor, das in mehreren Durch­gän­gen (Ite­ra­tio­nen) durch­lau­fen wird:

1. Sys­tem­an­for­de­run­gen
2. Software-An­for­de­run­gen
3. Analyse
4. Design
5. Im­ple­men­tie­rung
6. Test
7. Betrieb

Das als Was­ser­fall­mo­dell bekannt gewordene Vor­ge­hens­mo­dell ori­en­tiert sich an den von Royce de­fi­nier­ten Phasen, sieht aber nur eine Iteration vor.

In dem von Royce ver­fass­ten Aufsatz kommt der Begriff Was­ser­fall nicht einmal vor.

Er­wei­te­run­gen des einfachen Was­ser­fall­mo­dells ergänzen das Grund­mo­dell um iterative Funk­tio­nen – bei­spiels­wei­se um Rück­sprün­ge, die es er­mög­li­chen, die Er­geb­nis­se einer jeden Phase mit den aus der Vor­gän­ger­pha­se ge­won­ne­nen Annahmen ab­zu­glei­chen und somit zu ve­ri­fi­zie­ren.

Im Was­ser­fall­mo­dell reihen sich die einzelnen Phasen eines Ent­wick­lungs­pro­zes­ses in einer Kaskade an­ein­an­der. Jede Phase schließt mit einem Zwi­schen­er­geb­nis (Mei­len­stein) ab – bei­spiels­wei­se mit einem An­for­de­rungs­ka­ta­log in Form eines Las­ten­hefts, mit der Spe­zi­fi­ka­ti­on einer Software-Ar­chi­tek­tur oder mit einer Anwendung im Alpha oder Beta-Stadium.

Jedes Soft­ware­pro­jekt beginnt mit einer Ana­ly­se­pha­se, die eine Mach­bar­keits­stu­die und eine An­for­de­rungs­de­fi­ni­ti­on umfasst. In der Mach­bar­keits­stu­die wird das Software-Projekt bezüglich Kosten, Ertrag und Rea­li­sier­bar­keit ein­ge­schätzt. Aus der Mach­bar­keits­stu­die gehen ein Las­ten­heft (eine grobe Be­schrei­bung der An­for­de­run­gen), ein Pro­jekt­plan und die Pro­jekt­kal­ku­la­ti­on hervor sowie ggf. ein Angebot für den Auf­trag­ge­ber.

An­schlie­ßend folgt eine de­tail­lier­te An­for­de­rungs­de­fi­ni­ti­on, die eine Ist-Analyse und ein Soll-Konzept be­inhal­tet. Während Ist-Analysen den Pro­blem­be­reich skiz­zie­ren, wird im Soll-Konzept definiert, welche Funk­tio­nen und Ei­gen­schaf­ten das Software-Produkt bieten muss, um den An­for­de­run­gen gerecht zu werden. Zu den Er­geb­nis­sen der An­for­de­rungs­de­fi­ni­ti­on gehören bei­spiels­wei­se ein Pflich­ten­heft, eine de­tail­lier­te Be­schrei­bung, wie die An­for­de­run­gen an das Projekt zu erfüllen sind, sowie ein Plan für Ak­zep­tanz­test.

Ab­schlie­ßend sieht die erste Phase des Was­ser­fall­mo­dells eine Analyse der An­for­de­rungs­de­fi­ni­ti­on vor, in der komplexe Probleme in kleine Teil­auf­ga­ben zerlegt und ent­spre­chen­de Lö­sungs­stra­te­gien er­ar­bei­tet werden.

Die Design-Phase dient der Aus­ar­bei­tung eines konkreten Lö­sungs­kon­zepts auf Basis der zuvor er­mit­tel­ten An­for­de­run­gen, Aufgaben und Stra­te­gien. Software-Ent­wick­ler er­ar­bei­ten in dieser Phase die Software-Ar­chi­tek­tur sowie einen de­tail­lier­ten Bauplan der Software und kon­zen­trie­ren sich dabei auf konkrete Kom­po­nen­ten wie Schnitt­stel­len, Frame­works oder Bi­blio­the­ken. Das Ergebnis der Design-Phase umfasst ein Ent­wurfs­do­ku­ment mit Software-Bauplan sowie Test­plä­nen für einzelne Kom­po­nen­ten.

Rea­li­siert wird die in der Design-Phase kon­zi­pier­te Software-Ar­chi­tek­tur in der Im­ple­men­tie­rungs­pha­se, die Software-Pro­gram­mie­rung, Feh­ler­su­che und Mo­dul­tests umfasst. In der Im­ple­men­tie­rungs­pha­se wird der Software-Entwurf in der ge­wünsch­ten Pro­gram­mier­spra­che umgesetzt. Einzelne Kom­po­nen­ten werden separat ent­wi­ckelt, im Rahmen von Modultest überprüft und Schritt für Schritt in das Ge­samt­pro­dukt in­te­griert. Das Ergebnis der Im­ple­men­tie­rungs­pha­se ist ein Software-Produkt, das in der nach­fol­gen­den Phase zum ersten Mal als Ge­samt­pro­dukt getestet wird (Alpha-Test).

Die Testphase be­inhal­tet die In­te­gra­ti­on der Software in die ge­wünsch­te Ziel­um­ge­bung. In der Regel werden Software-Produkte zunächst als Beta-Version an aus­ge­wähl­te End­be­nut­zer aus­ge­lie­fert (Beta-Tests). Ob die Software die zuvor de­fi­nier­ten An­for­de­run­gen erfüllt, lässt sich mithilfe der in der Ana­ly­se­pha­se ent­wi­ckel­ten Ak­zep­tanz­tests ermitteln. Ein Software-Produkt, das Beta-Tests er­folg­reich ab­sol­viert hat, ist bereit für den Release.

Nach er­folg­rei­chem Abschluss der Testphase wird die Software für den Betrieb im Pro­duk­tiv­ein­satz frei­ge­ge­ben. Die letzte Phase des Was­ser­fall­mo­dells schließt Aus­lie­fe­rung, Wartung und Ver­bes­se­rung der Software ein.

Das Was­ser­fall­mo­dell bietet eine über­sicht­li­che Or­ga­ni­sa­ti­ons­struk­tur für Ent­wick­lungs­pro­jek­te, bei der die einzelnen Pro­jekt­pha­sen klar von­ein­an­der ab­ge­grenzt sind. Da jede Phase mit einem Mei­len­stein ab­schließt, ist der Ent­wick­lungs­pro­zess leicht nach­voll­zieh­bar. Der Schwer­punkt des Modells liegt auf der Do­ku­men­ta­ti­on der Pro­zess­schrit­te. Er­ar­bei­te­tes Wissen wird in An­for­de­rungs- oder Ent­wurfs­do­ku­men­ten fest­ge­hal­ten.

In der Theorie soll das Was­ser­fall­mo­dell durch im Vorfeld erstellte sorg­fäl­ti­ge Planung die Vor­aus­set­zun­gen für eine schnelle und kos­ten­güns­ti­ge Durch­füh­rung von Projekten schaffen. Der Nutzen des Was­ser­fall­mo­dells für den Pra­xis­ein­satz ist jedoch um­strit­ten. Zum einen sind Pro­jekt­pha­sen in der Software-Ent­wick­lung nur selten klar von­ein­an­der ab­ge­grenzt. Gerade bei komplexen Software-Projekten, sind Ent­wick­ler häufig damit kon­fron­tiert, dass sich die ver­schie­de­nen Kom­po­nen­ten einer Anwendung zur selben Zeit in ver­schie­de­nen Ent­wick­lungs­pha­sen befinden. Zum anderen ent­spricht der lineare Ablauf des Was­ser­fall­mo­dells oft nicht den realen Ge­ge­ben­hei­ten.

Streng genommen sind An­pas­sun­gen im Laufe des Projekts beim Was­ser­fall­mo­dell nicht vor­ge­se­hen. Ein Software-Projekt, bei dem sämtliche Details der Ent­wick­lung bereits zu Pro­jekt­be­ginn fest­ge­legt werden, ließe sich jedoch nur dann er­folg­reich beenden, wenn schon zu Beginn viel Zeit und Kosten in Analyse und Kon­zep­ti­on in­ves­tiert werden würden. Hinzu kommt, dass sich große Software-Projekte mitunter über mehrere Jahre er­stre­cken und ohne eine re­gel­mä­ßi­ge Anpassung an aktuelle Ent­wick­lun­gen Er­geb­nis­se her­vor­brin­gen würden, die bereits bei der Ein­füh­rung veraltet wären.

Was­ser­fall­mo­del­le nutzt man vor allem bei Projekten, bei denen sich An­for­de­rung und Abläufe bereits in der Pla­nungs­pha­se präzise be­schrei­ben lassen und bei denen davon aus­zu­ge­hen ist, dass sich die Vor­an­nah­men während des Pro­jekt­ab­laufs höchstens ge­ring­fü­gig ändern. Streng lineare Vor­ge­hens­mo­del­le eigenen sich somit in erster Line für kleine, einfache und klar struk­tu­rier­te Software-Projekte. Zu diesem Ergebnis kam Royce bereits in den 1970er-Jahren. Die von ihm vor­ge­schla­ge­ne Al­ter­na­ti­ve zum linearen Vor­ge­hens­mo­dell, das später als Was­ser­fall­mo­dell bekannt werden sollte, beinhalte daher drei we­sent­li­che Er­wei­te­run­gen:

Laut Royce sollten die Er­geb­nis­se einer jeden Pro­jekt­pha­se umgehend mit den zuvor er­ar­bei­te­ten Do­ku­men­ten ab­ge­gli­chen und ve­ri­fi­ziert werden – bei­spiels­wei­se müsste bereits nach der Ent­wick­lung eines Moduls si­cher­ge­stellt werden, dass dieses den zuvor de­fi­nier­ten An­for­de­run­gen ent­spricht, und nicht erst am Ende des Ent­wick­lungs­pro­zes­ses.

Das Was­ser­fall­mo­dell sollte laut Royce min­des­tens zweimal durch­lau­fen werden: zunächst für die Ent­wick­lung eines Prototyps und an­schlie­ßend für die Ent­wick­lung des ei­gent­li­chen Software-Produkts.

Als dritte Er­wei­te­rung des Was­ser­fall­mo­dells forderte Royce in seinem Aufsatz eine Maßnahme, die heute zum Stan­dard­vor­ge­hen in der Pro­dukt­ent­wick­lung gehört: Den Einbezug des End­ab­neh­mers in den Pro­duk­ti­ons­pro­zess. Royce schlägt vor, den Benutzer an drei Stellen in den Software-Ent­wick­lungs­pro­zess mit ein­zu­be­zie­hen: Während der Planung der Software im Rahmen der Ana­ly­se­pha­se, zwischen dem Software-Design und der Im­ple­men­tie­rung und in der Testphase vor dem Release der Software.

Aufgrund des streng linearen Ablaufs der se­quen­zi­ell auf­ein­an­der­fol­gen­den Pro­jekt­pha­sen eignet sich das Was­ser­fall­mo­dell – wenn überhaupt – lediglich für kleine Software-Projekte. Komplexe, mehr­schich­ti­ge Prozesse hingegen lassen sich nicht abbilden. Im Laufe der Zeit wurden daher diverse Al­ter­na­tiv­an­sät­ze ent­wi­ckelt.

Während Modelle wie das Spi­ral­mo­dell oder das V-Modell als Wei­ter­ent­wick­lun­gen des klas­si­schen Was­ser­fall­mo­dells gelten, folgen Konzepte wie Extreme Pro­gramming, Agile Software-Ent­wick­lung oder Ite­ra­ti­ves Pro­to­ty­p­ing einem gänzlich anderen Ansatz und erlauben meist eine fle­xi­ble­re Anpassung an aktuelle Ver­än­de­run­gen und neue An­for­de­run­gen.