Classic Waterfall Model in Software Engineering
von Doris Hausen
Einleitung
Das Wasserfallmodell geht zurück auf Winston W. Royce. Er schlug 1970, ausgehend von einem Wasserfall, ein iteratives Modell vor. Allerdings wurde nicht sein iterativer Vorschlag aufgegriffen und häufig zitiert, sondern das "einfache" Modell, das ursprünglich nur als Grundlage diente, und das darüber hinaus auch von Winston W. Royce kritisiert wurde ist heute allgemein bekannt als "Das Wasserfallmodell". Winstons Kritik wurde, zumindest zu Beginn, weitestgehend ignoriert und das Modell auch von einigen bekannten Instituten aufgegriffen, wie der NASA und das Verteidigungsministerium der Vereinigten Staaten von Amerika.
Das Wasserfallmodell
Nach Winston W. Royce besteht jedes Software Projekt aus mindestens zwei Stufen. Analyse und Coding. Allerdings ist es nicht nur nicht empfehlenswert eine Software Entwicklung nur in diese zwei Phasen zu gliedern, sondern laut Winston W. Royce scheitern große Projekte unter Garantie, wenn nicht eine feinere Unterteilung gewählt wird. In Winston W. Royces ursprünglicher Publikation wurden sieben Phasen benannt. System Requirements, Software Requirements, Analysis, Program Design, Coding, Testing and Operations.
In verschiedenen erneuten Diskussionen des Modells wurden allerdings häufig leicht veränderte Einteilungen der Phasen vorgenommen. So wird oft nur von einer Requirement Phase gesprochen und nicht von zwei getrennten Phasen für System Requirements und Software Requirements. Die Analyse Phase findet darüber hinaus in einigen Publikationen auch keine Erwähnung. Häufig werden die verschiedenen Phasen auch verschiedenen benannt. Zum Beispiel die Coding Phase wird in einigen Veröffentlichungen auch als Implementation Phase oder Construction Phase bezeichnet. Auf die Coding Phase folgt in manchen Beschreibungen die Integration Phase, die in Winston W. Royces ursprünglichem Modell nicht inbegriffen ist. In dieser Phase sollen verschiedene Programmteile, die in der Coding Phase von verschiedenen Gruppen entwickelt wurden zusammengeführt und zu einem Programm vereint werden.
Die in der Literatur am häufigsten zu findende Einteilung beinhaltet 5 Phasen. Requirements Analysis, Design, Coding, Testing und Maintenance.
- 1. Phase: Requirements Analysis
Der erste Schritt und gleichzeitig einer der wichtigsten ist die Requirements Analysis. In dieser Stufe werden Informationen über das Projekt gesammelt. Insbesondere werden die Wünsche des Kunden genau analysiert, und definiert welche Probleme das Endprodukt lösen soll. Darüber hinaus werden technische Probleme und Details möglichst genau erfasst und Schnittstellen zu anderen externen Systemen definiert. Manchmal wird diese Phase in zwei Teile unterteilt, die System Requirements und Software Requirements getrennt beleuchten und analysieren. Techniken die in dieser Stufe verwendet werden sind unter anderem Interviews mit den Kunden und Anwendungsszenarien. Das Ende dieser Phase bildet eine formale Spezifikation, die die Requirements auflistet und detailliert erläutert. - 2. Phase: Design
In der zweiten Phase wird sowohl die Hardware wie auch die Software Architektur entwickelt. Dies beinhaltet Fragen der Performance, der Sicherheit und der Datenstruktur. Auch die Wahl der Programmierumgebung und Programmiersprache wird in dieser Phase getroffen. Nebst der "Hintergrundtechnik" wird hier auch bereits ein Augenmerk auf das Userinterface, also die grafische Oberfläche, gelegt. Hierbei sollten bereits Fragen der Bedienbarkeit und Navigierbarkeit eines Projekts adressiert und gelöst werden. Auch diese Phase wird mit einer formalen und detaillierten Spezifikation des Designs abgeschlossen. - 3. Phase: Coding
In dieser, der dritten Phase ist das Ziel die tatsächliche Implementierung des Projekts. Basis dafür sind die vorangegangenen Spezifikationen, im besonderen die Spezifikation des Designs. Diese Stufe bestreitet ein Entwicklungsteam, das aus Programmierern, Interface Designern und anderen Spezialisten besteht. Diese Stufe kann, vor allem bei sehr großen Projekten, in kleine Unterabschnitte, mit Hilfe von Versionskontrolle des aktuellen Projekts, unterteilt werden. Das Endprodukt dieser Stufe sollte ein weitestgehend funktionierendes Programm sein, das die beiden vorhergegangenen Spezifikationen lückenlos erfüllt. - 4. Phase: Testing
Phase vier dient ausschließlich dem Testen und Debuggen. Das gesamte Programm so wie einzelne Komponenten sollen auf ihre Korrektheit überprüft werden. Es gibt zwei Arten von Testansätzen. Zum einen wird der Code von den Programmierenden selbst Schritt für Schritt kontrolliert und verifiziert. Zum anderen wird häufig aber auch auf ein unabhängiges Team zurückgegriffen, dass zuvor keinen Kontakt mit der Implementierung hatte, da es sich als vorteilhaft erwiesen hat und Personen die zuvor den Code nicht kannten meist Fehler leichter und schneller erkennen und erfassen. In jedem Fall wird mit so genannten "test cases" gearbeitet. Neben der reinen Funktionalität müssen noch zwei weitere Aspekte geprüft werden. Erstens muss sichergestellt werden, dass das Endprodukt die in den vorhergehenden Phasen festgelegten Requirements vollständig erfüllt, und außerdem sollte auch die Akzeptanz des Kunden und die der Anwender des Programms überprüft und gesichert werden. Darüber hinaus wird in dieser Phase auch das Benutzerhandbuch vorbereitet und am Ende veröffentlicht. Als Abschluss dieser Phase sollte ein fehlerfreies den Vorgaben und Spezifikationen entsprechendes Produkt stehen. - 5. Phase: Maintenance
In der fünften und gleichzeitig letzten Phase wird das System nun an den Kunden ausgeliefert und wenn nötig installiert. Im Idealfall wäre nun ein vollständig funktionsfähiges und absolut fehlerfreies Produkt beim Endkunden angelangt. In der Realität wird aber ein Produkt weitere Betreuung beanspruchen. Zum einen treten im tatsächlichen Einsatz meist neue Fehler auf, die beim Testen übersehen wurden und die natürlich ausgebessert werden müssen. Zum anderen ergeben sich auf Kundenseite häufige neue Wünsche und Erweiterungen, die in das Programm integriert werden sollen. Meist führen derartige Änderungen zu einem neuen Release der Software und es entstehen verschiedene Versionen des Produkts.
Das Wasserfallmodell basiert also auf einem sequenziellen Ablauf. Jede Stufe wird strikt nacheinander abgearbeitet. Parallele Entwicklung in verschiedenen Phasen gleichzeitig ist nicht vorgesehen. Das Ergebnis der vorherigen Phase dient jeweils als Ausgangs- beziehungsweise Einstiegspunkt für die nächste Phase.
Vorteile des Modells
Einer der größten Vorteile des Wasserfallmodells ist die klare Struktur. Es handelt sich bei diesem Modell um einen einfachen Ansatz der sich durch klar erkennbare "Milestones" auszeichnet. Alle Phasen sind strikt voneinander getrennt und haben einen eindeutig definierten Start- und Endpunkt. Die nächste Phase wird erst betreten wenn die vorherige Phase komplett abgeschlossen ist. Somit erfordert das Modell eine akurate Arbeitsweise und sorgt dafür, dass Fehler auf jeder Stufe nach bestem Wissen vermieden werden, da ein zurückkehren zu alten Stufen, um Fehler auszubessern, nicht vorgesehen ist. Somit wird auch vermieden, dass beispielsweise auf falschen Requirements basierend ein Design entworfen wird, das sich im späteren Verlauf natürlich als unnötige Arbeitszeit herausstellt. Im Falle eines Fehlers der tatsächlich erst im Nachhinein festgestellt wird, hat man allerdings exakte "fallback" Positionen auf deren Basis man erneut ansetzen kann und das Software Projekt weiterentwickeln kann.
Nachteile des Modells
Vielerseits wird das Wasserfallmodell allerdings auf Grund seiner starren Struktur auch vehement kritisiert. Kritiker sind der Meinung, dass Software aus mehreren Gründen flexibel und für Änderungen offen sein muss. Probleme tauchen oft erst während der Arbeit auf. Möglicherweise kann es sinnvoll sein, das vorher spezifizierte Design abzuändern, wenn bei der Implementierung des angedachten Designs Probleme auftreten. Dies würde allerdings zu einer Verschwimmung der Phasen führen, die im Wasserfallmodell strikt abgelehnt wird. Nicht nur bei der Design Phase ist das Wissen aus später folgenden Phasen hilfreich. Dies gilt im allgemeinen für alle Phasen des Modells. So dient die vierte Phase, die sich dem Testen und Debuggen widmet, dazu, dass Fehler die in den vorherigen Phasen auftraten bemerkt und ausgebessert werden, was wiederum dazu führen kann, dass ein erneutes durchlaufen der bereits erledigten Phasen nötig wird. Für erfahrene Systemdesigner stellt dies möglicherweise kein unüberwindbares Problem dar, da sie viele Probleme, auf Grund ihrer Erfahrung, im vorhinein erkennen. Allerdings kann dies nicht als Voraussetzung für alle Software Entwicklungen so festgesetzt werden. Das ursprüngliche Modell sieht darüber hinaus vor, dass jede Phase perfekt abgeschlossen wird bevor mit der nächsten Phase begonnen wird. Allerdings ist es in der Realität nahezu unmöglich eine Phase absolut perfekt abzuschließen. In einem Software Projekt, das sich strikt an die Vorgaben des Wasserfallmodells hält, wird des Weiteren die Arbeitslast bzw. Arbeitszeit sehr ungünstig auf alle beteiligten Mitarbeiter verteilt. Da die verschiedenen Phasen meist von verschiedenen Arbeitsgruppen und verschiedenen Mitarbeitern bearbeitet werden, ist immer nur eine Gruppe aktiv mit dem Projekt beschäftigt. Ein weiteres Problem bei Software Entwicklung mit Hilfe dieses Modells stellen die Kunden dar. Sie sind häufig nicht sehr vertraut mit Entwicklungsprozessen und ändern ihre das Endprodukt betreffenden Wünsche oder modifizieren ihre Anforderungen. Oft haben sie zu Beginn eines Projekts auch keine exakten Vorstellungen von ihren Erwartungen bezüglich des Produkts. Auf derlei Wünsche muss ein Team von Software Entwicklern eingehen und reagieren können.
Modifizierungen des Wasserfallmodells
Bereits Winston W. Royce modifizierte das ursprüngliche Wasserfallmodell in seiner ersten Publikation zu diesem Thema, da er das einfache Modell selbst nicht für ausreichend hielt. Eine seiner Modifizierungen war das Einfügen einer weiteren Phase. Die Preliminary Program Design Phase befindet sich zwischen der zweiten Phase Software Requirements und der ursprünglich dritten Phase Analysis. Durch die Einführung dieser Phase erwartet Winston W. Royce eine bessere Analyse und ein besseres Design bezüglich der Ausführungszeiten und Speicherressourcen. Aufgaben dieser neuen Phase sind unter anderem die Entwicklung des Designs für die Datenbestände und der Prozesse und die Bereitstellung von Speicherplatz für Unterprogramme und Bearbeitungszeit für selbige. Eine weitere sehr wichtige Ergänzung des Modells sieht Winston W. Royce in der Dokumentation. Jede Phase muss seiner Ansicht nach mit einem umfangreichen Dokument, das alle wichtigen Informationen bezüglich der Phase enthält, beendet werden. Manche Phasen können auch mehrere solcher Dokumente haben. Beispielsweise die Coding Phase könnte verschiedene eigenständige Dokumentationen über die grafische Oberfläche und das eigentliche Programm haben. Dieses Dokument dient vor allem zum Austausch mit Kollegen und Kunden und stellt vor der Implementierung das einzig greifbare des gesamten Projekts dar. Darüber hinaus sind dadurch alle wichtigen Entscheidungen schriftlich festgehalten und spätere Phasen können sich darauf berufen. Eine weitere Modifikation veröffentlicht er unter dem Schlagwort "Do it twice". Ab dem Preliminary Program Design sollen alle Schritte zweimal durchlaufen werden, wobei der erste Durchlauf in wesentlich kürzerer Zeit (ca. 1/3 -1/4 der geplanten Gesamtzeit) eine Art Prototypen als Ergebnis hervorbringen soll. Dabei sollten viele Fehler bereits auffallen und die Phasen beim zweiten Durchlauf positiv beeinflussen. Aber auch durch das doppelte Durchlaufen aller Schritte sind Fehler nicht zu hundert Prozent zu vermeiden und ein weiterer wichtiger Augenmerk liegt auf den Tests. Auf das Testen des Produkts soll laut Winston W. Royce der größte Teil der Projekt Ressourcen entfallen, sowohl in finanzieller Hinsicht wie auch vom zeitlichen Aufwand aus gesehen. Als letzten wichtigen Hinweis empfiehlt er, den Kunden von Beginn an intensiv in das Projekt mit einzubeziehen um Fehlinterpretationen und Änderungswünsche frühest möglich zu entdecken und einzubauen. Allerdings bergen diese Modifikationen auch Gefahren. Vor allem das Einführen des Prototypens. Bei der Entwicklung muss das Team darauf bedacht sein, dass das Projekt nicht in lauter kleine Wasserfälle zerfällt.
Zusammenfassung
Obwohl sich das Wasserfallmodell gegen vielseitige Kritik wehren muss, scheint es dennoch in weiteren Bereichen sehr beliebt und etabliert zu sein. So gaben in einer Umfrage im Jahre 2000 ein Drittel aller Befragten an, das Wasserfallmodell zur Software Entwicklung zu verwenden, wobei diese Zahl durchaus kritisch betrachtet werden muss. Das Wasserfallmodell stellt für viele weitere Modelle die Basis dar und wurde über die Jahre an vielen Stellen verbessert. Spricht jemand vom Wasserfallmodell ist es also nicht eindeutig klar, was genau derjenige darunter versteht. Insgesamt stellt das Wasserfallmodell die technischen Aspekte in den Vordergrund im Gegensatz zum Anwender, also dem Menschen. Die Idee ist, dass Technik beim ersten Mal richtig sein kann. In der Realität ist dies allerdings schwer umsetzbar und Modifikationen des Modells versuchen dies, wie bereits erwähnt, durch die Einbeziehung des Kunden und der Endverbraucher, aufzuweichen. Das Wasserfallmodell beschreibt also sicher nicht die komplette und einzige Wahrheit im Bereich der Software Entwicklung, allerdings enthält das Modell einige interessante Ansätze und Strukturen.
Quellen:
- W. W. Royce. Managing the development of large software systems: concepts and techniques. In: Proceedings of the 9th international conference on Software Engineering ICSE '87, March 1987, IEEE Computer Society Press
- Phillip A. Laplante, Colin J. Neill. Opinion: The Demise of the Waterfall Model Is Imminent. In: Queue, Volume 1 Issue 10, February 2004, ACM Press
- Luciano Rodrigues Guimarães, Plínio Roberto Souza Vilela. Software development and analysis: Comparing software development models using CDM. In: Proceedings of the 6th conference on Information technology education SIGITE '05, October 2005, ACM Press
- TechRepublic. Understanding the pros and cons of the Waterfall Model of software development. 18.01.2007. http://articles.techrepublic.com.com/5100-3513_11-6118423.html