Classic Waterfall Model in Software Engineering

Einführung

Es gibt verschiedene Methoden, die die Vorgehensweise der Softwareentwicklung unterstützen. Nicht nur die Entwicklung sondern auch die Ergebnisse sollen mit diesen Methoden effektiver und effizienter gestaltet werden. Die Modelle können in klassische und agile Vorgehensweisen unterschieden werden. Der klassische Ansatz wird vor allem bei großen Projekten eingesetzt, bei denen während der Entwicklung wenige Veränderungen bei den Anforderungen und in der Technik auftreten. In den Mittelpunkt rückt hier vor allem die Dokumentation des Systems. Generell kann der Ansatz als eher kostspielig angesehen werden. Das Gegenstück dazu bildet die agile Vorgehensweise, die eher für kleinere Projekte bei Teamarbeit eingesetzt wird. Die Entwicklung muss flexibel auf Veränderungen eingehen können. Anstatt sich an der Dokumentationen zu orientieren, rückt die Benutzerfreundlichkeit des Systems in das Zentrum der Betrachtung. Die gewonnene Struktur des klassischen Modells geht bei der agilen Vorgehensweise verloren und die Struktur wirkt eher chaotisch. Ein Beispiel für die klassische Methode ist das Wasserfallmodell. Es nähert sich systematisch und sequentiell an den Prozess der Softwareentwicklung an, indem der Prozess in mehreren Stufen oder Phasen unterteilt wird. [Pehk06] Diese Phasen werden in ihrer richtigen Reihenfolge und in ihrer vollen Breite abgearbeitet. Das sequentielle Vorgehen bei der Abarbeitung der Phasen wird auf jeder Stufe mit einem Meilenstein abgeschlossen. Erst wenn der Meilenstein erreicht wurde, kann mit der nächste Phase begonnen werden. Wie bei dem klassischen Ansatz beschrieben, orientiert sich auch das klassische Wasserfallmodell an Dokumenten und es kann als stufenweise bezeichnet werden.Gegründet wurde das klassische Wasserfallmodell auf dem Stufenmodell von Herbert D. Benington. Dieser stellte 1970 sein Modell vor, dass den Entwicklungsprozess in die Phasen Analyse, Entwurf, Codierung und Test einteilte. Er passte den Prozess der Softwareentwicklung an den industriellen Produktionsprozess an, da sie die Vorstellung besaßen, dass Software sich wie ein physisches Produkt produzieren lässt. Mit diesem Modell wollte Benington vor allem gegen die unorganisierte Softwareentwicklung angehen und bisherige Probleme beseitigen. Zu diesen Problemen gehörte die schlechte Wartbarkeit der Quelltexte, aber auch das häufige Auftreten von Fehlern. Zudem wurden Systeme entwickelt, die nicht die Erwartungen der Benutzer erfüllten. Walker Royce erweiterte 1970 das Stagewise Model von Benington und fügte zu den bestehenden Phasen eine Rückkopplungsschleife zwischen den Stufen ein. Falls die Resultate der vorherigen Phase nicht ausreichend sind, kommt es zum Abbruch des Prozesses in der aktuellen Phase. Der Prozess wird in der vorangegangenen Phase wieder aufgenommen. Der Startpunkt für die Weiterführung des Prozess kann nicht beliebig gewählt werden, sondern kann nur in der vorangegangenen Stufe gewählt werden. Zu der Bezeichnung Wasserfallmodell kam es durch Barry W. Boehm, der 1980 in seiner Veröffentlichung auf die nicht zyklische Vorgehensweise des Modells mit dem gewählten Namen hinweist. [Heid02] Das Wasserfallmodel unterscheidet sich von dem klassischen Wasserfallmodell durch die Rückkopplungsschleifen zwischen den Stufen.

Das klassische Wasserfallmodell stellt einen formalen Prozess dar, woraus folgende Vorteile resultieren. Die Entwickler können gemeinsame Aktivitäten, Ressourcen und Bedingungen analysieren und sich gegenseitig unterstützen. Die Manager können mit Hilfe des klassischen Wasserfallmodells einen Ablaufsplan erstellen, um das Projekt zeitlich strukturieren zu können. Zusätzlich zu den Managern können auch Entwickler und Projektleiter ihr Wissen auf andere Projekte transferieren und sie müssen einen neuen Prozess nicht vollständig erlernen. [Wats99]

Erklärung der einzelnen Entwicklungsstufen

Der komplexe Entwicklungsprozess wird in einzelne Phasen unterteilt. Jede Stufe beinhaltet eigenständige Prozesse und Aufgaben, die das jeweilige Entwicklerteam erfüllen muss. Die wesentlichen Stufen sind die Anforderungsanalyse sowie die Spezifikation, das Design, die Implementierung, das Testen, die Analyse und die Wartung.

Abb: Das klassische Wasserfallmodell [img1]

Zu beachten ist, dass die Abarbeitung einer Stufe erst nach Beendigung der vorangegangenen Phase beginnen kann. [Bozz03] In die Anforderungsanalyse fließen die benötigten Funktionen des Systems, aber auch das Benutzerverhalten und die Wünsche des Anwenders ein. Die Spezifikation beschreibt dann eine detaillierte Zielsetzung der Software. Aber auch die genauen Bedingungen, die für die Erfüllung der Anforderungen nötig sind und zu diesem Zeitpunkt schon bekannt sind, werden in der Spezifikation aufgelistet. Des Weiteren werden auch die benötigten Kriterien für die Testphase definiert, um die Endsysteme evaluieren zu können. Die Testkriterien bieten auch die erste Möglichkeit, den jeweiligen Fortschritt des Softwaresystems festzustellen. In der Designphase werden die gewonnen Ergebnisse der vorherigen Phase in Form von Ablaufdiagrammen und Struktogrammen graphisch dargestellt. Auch Tabellen über Benutzerschnittstellen werden erstellt und im weiteren Verlauf werden die ersten Algorithmen und Datenstrukturen entwickelt. Bei der Implementierung werden die Resultate der Designphase in eine Programmiersprache übertragen. Dabei ist die Dokumentierung des Quelltextes genauso wichtig wie die eigentliche Programmierung. Die Überprüfung des Systems kann wiederum in zwei Phasen unterschieden werden – Integrationsphase und Testphase. Während bei der Integrationsphase das System als Ganzes getestet wird, werden in der Testphase nur einzelne Module getestet. Die Module können auch nur aus einzelnen Funktionen bestehen, die getrennt von den restlichen Modulen überprüft werden. In der letzten Phase trifft die Software zum ersten Mal auf den Kunden. Zur Wartung des Systems gehört Einbindung von typischen Aufgaben, sowie das Angebot von neuen Produktversionen. Zudem müssen in dieser Phase auftretende Fehler behoben werden und die Systemdokumentation muss aktualisiert werden. [Four03]

Kritik am klassischen Wasserfallmodell

Um ein großes Softwareprodukt zu entwickeln, ist während des Prozesses Koordination und Synchronisation gefordert. Vor allem wenn viele Entwickler an dem Prozess beteiligt sind und sie voneinander abhängige Komponenten erstellen, die sich schnell und oft ändern. Die Koordination und Synchronisation wird mit dem Wasserfallmodell erleichtert, da mit ihm die Abfolge der Aktivitäten festgelegt wird. Doch Manager sehen in dem festgelegten Ablauf auch Schwierigkeiten. Zwar wird die Koordination mit dem Wasserfallmodell gesichert, doch die Programmierer werden in ihrer Kreativität und Eigenständigkeit beim Arbeiten eingeschränkt. Angewendet werden sollte das Wasserfallmodell auf jeden Fall, wenn der Prozess wenige Veränderungen aufweist. Beispielsweise werden Funktionen schrittweise zu einem existierenden System hinzugefügt. Genauso empfehlenswert ist das Modell für Projekte, bei denen der Entwickler die Details im Design kontrollieren kann und mit dem Prozess bis zum Ende fortfahren kann. Falls er nicht zur Beedigung seiner Aufgabe kommt, sollte der Anwender die Unterbrechung aufgrund der Überarbeitung nicht bemerken. Nicht empfehlenswert ist die Vorgehensweise des Wasserfallmodells, wenn viele inhaltliche Veränderungen auftreten und beim Beseitigen der durch Änderungen hervorgerufenen Probleme Unsicherheiten auftreten. Auch Unsicherheiten bei den Systemanforderungen und ein sich schnell ändernder Markt sprechen gegen das Wasserfallmodell. So treten zum Beispiel bei der Softwareentwicklung schnell Änderungen im Bereich der Technologie auf, sowie der Benutzer entwickelt andere Anforderungen an das Softwaresystem. Eine allzu ausführliche Spezifikation des Projektzieles zu Beginn ist überflüssig, da sonst das Endprodukt nicht mehr den Anforderungen der Kunden gerecht wird. Entwickler können auch nicht in ihren Modulen eigenständig Teile ändern, indem sie auf Rückmeldung der Anwender eingehen oder weiterentwickelte Technologien in Hardware und Software verwenden. Die einzelnen Module passen nicht mehr zusammen und sowohl bei der Integration als auch beim Testen werden Probleme aufkommen. Das Programmierteam muss die einzelnen Teile überarbeiten. Bei diesen Problemen in der Softwareentwicklung ist es nicht verwunderlich, dass der Zeitplan der Projekte nicht eingehalten werden kann und Projekte das festgelegte Budget überschreiten. Zudem kommt es aufgrund der Abhängigkeit der einzelnen Module untereinander zu Fehlern, die von den einzelnen Modulen und ihren Veränderungen kommen. Alternativ zum Wasserfallmodell wurden andere Vorgehensweisen entwickelt, die die aufgeführten Probleme beseitigen sollten. Durch Iteration soll die Vorgehensweise weiter an den Entwicklungsprozess angepasst werden. Der Entwickler hat nun die Möglichkeit zu einer beliebigen vorherigen Stufe zurückzukehren und muss nicht mehr die Projektplanung bis zum Ende einhalten, sondern er kann flexibel auf Veränderungen agieren. Tatsächlich ist das Wasserfallmodell mit Iteration eine genaue Beschreibung, was viele Softwareentwickler in ihren Projekten schon erfahren haben, doch der Ablauf war unkontrolliert und ungeplant. Iteration wird auch als ein schrittweiser Aufbau eines Projektes bezeichnet, ohne Projektplanung und Meilensteine zu berücksichtigen. In einem iterativen Modell wird nicht deutlich, wann die Iteration nicht mehr fortgeführt werden soll. Viele Unternehmen verwenden das Wasserfallmodell in der Praxis nicht mehr, da viele Wiederholungen der Phasen Spezifikation, Entwicklung und Testen gefordert sind. Der wesentliche Vorteil des Wasserfallmodells ist, dass das Projekt eine Struktur erhält, die die Organisation und Kontrolle der Softwareentwicklung erleichtert. Dabei ist das wichtigste, die Anforderungen der Benutzer genau zu analysieren und in das System einzubauen. Wenn das klassische Wasserfallmodell zur Unterstützung bei der Softwareentwicklung dient, dann müssen zu Beginn der Entstehung die Anforderungen an das System spezifiziert werden. Da aber in diesem Modell weder Iteration noch Rückmeldungen der Testanwender berücksichtigt werden, gibt es keine Möglichkeit die Fehlerstelle auszubessern. Deswegen wurden alternative Modelle entwickelt, die mit Iteration und Interaktion dem Entwickler erlauben, gefundene Fehlerquellen wieder zu beheben. Im Wasserfallmodell werden die Aktivitäten linear abgearbeitet. Diese Linearität hat zur Konsequenz, dass jede Phase am Ende einen Meilenstein erhält. Dieser Meilenstein definiert das Ende der vorherigen Phase und der Beginn der nächsten Stufe. Zudem beinhaltet er eine Bestätigung und Bewertung der Zwischenergebnisse der vorangegangenen Phase, indem überprüft, wird ob das Ergebnis mit der Eingabe für die kommende Phase übereinstimmt. Aber auch der Vergleich mit den allgemeinen Anforderungen an das System mit dem gewonnenen Resultat ist eine zusätzliche Aufgabe des Meilensteins. In der Regel ist im Wasserfallmodell das Ergebnis ein Dokument oder Quelltext. Diese Ergebnisse dürfen nach der Bestätigung eigentlich nicht mehr verändert werden. Aber da die Systemanforderungen sich laufend ändern, muss es für den Entwickler eine Möglichkeit geben, auch nach der Bestätigung und Bewertung der Ergebnisse Änderungen an den validierten Zwischenergebnissen vorzunehmen. Firmen verbesserten das Wasserfallmodell, aber auch neue Progammiertechniken und Tools sollten helfen, die Softwareentwicklung zu unterstützen. Und trotzdem entstehen vor allem bei großen Projekten Fehler in der Entwicklungphase. So kommt es immer noch häufig vor, dass der Zeitplan nicht eingehalten wird, Ressourcen überschritten werden oder finanziellen Kosten unterschätzt werden. Zudem erfüllt das Projektziel nicht die Erwartungen der Benutzer. Mögliche Gründe für diese Fehlerquellen sind eine mangelnde Anforderungsanalyse, aber auch eine unvollständige Zieldefinition. Aber auch schon Fehler in der Designarchitektur können zu diesem mangelhaften Resultat führen. Weiterhin sind der mangelnde Statusberichten und Projektmaßstäben als Gründe zu nennen. Des Weiteren kann die unklare Definition der Meilensteine und die Unterschätzung der Realisierung des Projektes aufgeführt werden.[Cusu07]

Alternative Modelle für Softwarentwicklung

Dieses Modell ist eine Variation des Wasserfallmodells. Hier wird berücksichtigt, dass die einzelnen Stufen des Wasserfallmodells von einander abhängig sind und nicht ausschließlich getrennt voneinander betrachtet werden können. So entstehen verschiedene Projektversionen, die getestet und überprüft werden. Nach erfolgreicher Validierung und Hinzufügen von weiteren Funktionalitäten entsteht eine neue Version des Systems. Diese Versionen werden nicht veröffentlicht, sondern sind ein Teil der Entwicklung des Softwaresystems. Jeden Tag um dieselbe Uhrzeit stellt der Projektleiter einen neuen Ablaufplan für die neue Projektversion auf und die Entwickler müssen diesen Plan einhalten, sowie die abschließenden Tests erfolgreich abgeschlossen haben. Es soll ein funktionsfähiges und hochwertiges System in jeder Projektversion entstehen. Allerdings wird die funktionale Spezifikation nicht vollständig erfüllt. Vorteilhaft ist, dass das Modell flexibel auf Änderungen in der Spezifikation eingehen kann und dass die Komplexität des System verringert wird, da die Systementwicklung in kleineren Einheiten angegangen wird. [jaya06]

Abb: Incremental Model [jaya06]

Mit dieser Vorgehensweise wird ein Prototyp erstellt, der die wesentlichen und vielleicht auch die typischsten Funktionen des endgültigen Produktes umsetzt. Dazu werden zwei Varianten des Prototyps angefertigt, ein „operational“ - entspricht dem Incremental Model - und ein „throwaway“ Prototyp. Dieser wird verwendet, um Implementierung der Methoden und Akzeptanz des Endbenutzers zu testen. Wenn der Prototyp eine verwendbare Technologie besitzt, wird er auch als Grundlage für das Endprodukt verwendet, doch meistens kann die funktionale Spezifikation damit nicht vollständig erstellt werden. Anschließend ist der weitere Prozess dem des Wasserfallmodells sehr ähnlich. Der Unterschied ist zu der Entwicklung eines funktionsfähigen Prototyps - „operational“ prototype – vor allem die schnellere Entwicklung. [jaya06]

Abb: Rapid Prototyping Model [jaya06]

Entwickelt wurde dieses Model von Barrry Boehm und ist eine Erweiterung des Wasserfallmodells und des Rapid Prototyping. Zusätzlich wird vor jeder Stufe des Wasserfallmodells eine Risikoanalyse gemacht. Das Modell stellt das Rapid Prototyping Model spiralenförmig angeordnet dar. Es wird sehr erfolgreich eingesetzt, weil vor allem Änderungen in den Zielvorstellungen berücksichtigt und während der Entwicklung Risiken abgeschätzt werden können. Risikofaktoren können kontrolliert werden oder zumindest deren Einfluss vermindert werden. Zudem gibt es im Gegensatz zum Wasserfallmodell Vergleiche zu vorherigen Projektzuständen. [jaya06]

Abb: Spiral Model [jaya06]

Das iterative Entwicklungsmodell bildet das realistischste Modell in der Softwareentwicklung. Es entspricht dem Wasserfallmodell, aber es hat zusätzlich zwischen den einzelnen Phasen Rückkopplungsschleifen und auch nach der letzten Stufe kann wieder mit der ersten begonnen werden. [jaya06]

Abb: Iterative Model of Software Development [jaya06]

Vergleich der vorgestellten Modelle

Die Anforderungen an ein Modell werden abhängig von den nicht technischen Anforderungen an das Projekt festgelegt [Groa97]. Das Wasserfallmodell geht sehr diszipliniert vor und orientiert sich an Dokumenten in jeder Phase. Allerdings können durch den Wandel an Anforderungen die Anwender eventuell mit dem Endprodukt nicht zufrieden gestellt werden [jaya06]. Der Einsatz lohnt sich vor allem bei kleinen Projekten mit wenigen Anforderungen [Groa97]. Die Zufriedenheit des Benutzers kann mit dem Rapid Prototyping Model zwar garantiert werden, dafür kann es nicht für große Projekte eingesetzt werden. Das Spiralmodell entspricht dem endgültigen Wasserfallmodell, aber kann nur für die interne Entwicklungsphase eingesetzt werden [jaya06]. Dafür ist es gut geeignet, um Projekte mit vielen Systemanforderungen zu unterstützen, da sie in viele einzelne Komponenten unterteilt werden können [Groa97]. Im Gegensatz zum Wasserfallmodell und dem iterativen Modellansatz geht das Spiralmodell nicht davon aus, dass alle Systemanforderungen zu Beginn des Projektes definiert werden können, sondern kann auf diese Veränderung flexibel reagieren [Kenz02]. Der iterative Modellansatz ist eine gute Wahl für ungeprüfte Technologien oder wenn das Projekt viele Benutzerinteraktionen beinhaltet [Groa97]. Es besteht höchstens die Gefahr, dass zu viele Iterationen durchgeführt werden [jaya06]. Zwei oder mehrere Modelle können auch zusammen angewendet werden. Bei der Wahl eines Modells sollten die folgenden Punkte beachtet werden. Das Modell muss die Möglichkeit bieten, auch zu einer vorherigen Phase zurückzukehren, um die definierten und dokumentierten Anforderungen zu korrigieren. Des Weiteren sollte die Umsetzung der Anforderungen durch die jeweiligen Teams für z.B. Software, Hardware und Teilsysteme parallel passieren können. [Groa97]

Literatur

[Bozz03]
Marco Bozzano, Antonella Cavello, Massimo Cifaldi, Laura Valacca, Adolfo Villafiorita. Improving Safety Assessment of Complex Systems: An industrial case study. 2003. online verfügbar unter: http://www.cert.fr/isaac/doc/fme03.pdf, 14. Jan. 2007

[Cusu07]
Michael A. Cusumano, Stanley Smith. Beyond the Waterfall: Software Development at Microsoft. 1995. online verfügbar unter: https://dspace.mit.edu/bitstream/1721.1/2593/1/SWP-3844-33836288.pdf. 11. Jan. 2007

[Four03]
David Fourney. Software Process Modeling Using Petri Nets. 2003. online verfügbar unter: http://www.cs.usask.ca/grads/dwf129/coursework/856/856project.pdf, 14. Jan. 2007

[Groa97]
Brian Groarke, George Robertson. Avionics Software Engineering - Requirements Management Guidebook. .1997. online verfügbar unter: http://www.itq.ch/pdf/Req_Eng_GuideBook7_Avionics1.pdf, 14. Jan. 2007

[Heid02]
Raimund Heid. Einführung und Bewertung eines leichtgewichtigen Entwicklungsprozesses. 2002. online verfügbar unter: http://swt-www.informatik.uni-hamburg.de/publications/papers/Dipl/DA_Heid.pdf, 14. Jan. 2007

[Img1]
online verfügbar unter: http://images.google.de/imgres?imgurl=http://www.informatics.susx.ac.uk/research/nlp/carroll/se/Slides/process/waterfall.fig.gif&imgrefurl=http://www.informatics.susx.ac.uk/research/nlp/carroll/se/Slides/process/process-1.html&h=328&w=409&sz=4&hl=de&start=52&tbnid=kVZKbFVJAwqOeM:&tbnh=100&tbnw=125&prev=/images%3Fq%3D%2522waterfall%2Bmodel%2522%26start%3D40%26ndsp%3D20%26svnum%3D10%26hl%3Dde%26lr%3D%26sa%3DN, 14. Jan. 2007

[jaya06]
Bijay K. Jayaswal, Peter C. Patton. Software Development Methodology Today. 2006. online verfügbar unter: http://www.phptr.com/articles/article.asp?p=605374&seqNum=6&rl=1, 14. Jan. 2007

[Kenz02]
G. MacKenzie, G. Schulmeyer, L. Yilmaz. Verification Technology Potential with Different Modeling and Simulation Development and Implementation Paradigms. 2002. online verfügbar unter: https://www.dmso.mil/public/library/projects/vva/found_02/sess_papers/a1.pdf, 11. Jan. 2007

[Pehk06]
Marika Pehkonen, Heljä Franssila. Challenges and emerging promises of intranet portal implementation and design in use. 2006. online verfügbar unter: http://www.uta.fi/hyper/projektit/sampo2/HCT06_Challenges_and_emerging_120406_Pehkonen_Franssila.pdf, 14. Jan. 2007.

[Wats99]
Kent Watsen. Software Architectures. 1999. online verfügbar unter: http://watsen.net/Bamboo/papers/siggraph99.pdf, 14. Jan. 2004