Wasserfallmodell

Aus besserwiki.de
Stufen des Wasserfallmodells (Beispiel) ⓘ

Ein Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell, das insbesondere für die Softwareentwicklung verwendet wird und das in aufeinander folgenden Projektphasen organisiert ist. Wie bei einem Wasserfall mit mehreren Kaskaden „fallen“ die Ergebnisse einer Stufe nach unten in die nächste und sind dort verbindliche Vorgaben. ⓘ

In einem Wasserfallmodell hat jede Phase vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. Meist beschreibt das Modell auch einzelne Aktivitäten, die zur Herstellung der Ergebnisse durchzuführen sind. Zu bestimmten Meilensteinen und am jeweiligen Phasenende werden die vorgesehenen Entwicklungsdokumente im Rahmen des Projektmanagements verabschiedet. ⓘ

Der Name Wasserfall kommt von der häufig gewählten grafischen Darstellung der als Kaskade angeordneten Projektphasen. In der betrieblichen Praxis ist es traditionell ein weit verbreitetes Vorgehensmodell, von dem es viele Varianten gibt. ⓘ

Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) führen iterative Aspekte ein und erlauben ein schrittweises Aufwärtslaufen der Kaskade. Ein Abweichen vom strengen Vorgänger-Nachfolger-Prinzip wird auch dann erforderlich, wenn in der aktuellen Phase Handlungsbedarf erkennbar wird, der grundsätzlich einer früheren Phase zugeordnet ist, z. B. Anpassungen im Systementwurf oder im Benutzerhandbuch aufgrund von Erkenntnissen beim Testen. ⓘ

Wasserfallmodelle werden allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen. ⓘ

Das Wasserfallmodell ist eine Unterteilung der Projektaktivitäten in lineare, aufeinander folgende Phasen, wobei jede Phase von den Ergebnissen der vorangegangenen Phase abhängt und einer Spezialisierung der Aufgaben entspricht. Dieser Ansatz ist typisch für bestimmte Bereiche der technischen Planung. In der Softwareentwicklung gehört er zu den weniger iterativen und flexiblen Ansätzen, da der Fortschritt in einer Richtung ("abwärts" wie ein Wasserfall) durch die Phasen Konzeption, Initiierung, Analyse, Design, Konstruktion, Test, Bereitstellung und Wartung fließt. ⓘ

Das Wasserfallmodell hat seinen Ursprung in der Fertigungs- und Bauindustrie, wo die stark strukturierten physischen Umgebungen dazu führten, dass Designänderungen schon viel früher im Entwicklungsprozess unerschwinglich wurden. Als es erstmals für die Softwareentwicklung übernommen wurde, gab es keine anerkannten Alternativen für wissensbasierte kreative Arbeit. ⓘ

Geschichte

Der erste bekannte Vortrag, der den Einsatz solcher Phasen in der Softwareentwicklung beschrieb, wurde von Felix Torres und Herbert D. Benington auf dem Symposium on Advanced Programming Methods for Digital Computers am 29. Juni 1956 gehalten. Dieser Vortrag handelte von der Entwicklung von Software für SAGE. Im Jahr 1983 wurde der Vortrag mit einem Vorwort von Benington neu veröffentlicht, in dem er erklärte, dass die Phasen absichtlich nach der Spezialisierung der Aufgaben organisiert wurden, und darauf hinwies, dass der Prozess nicht streng von oben nach unten durchgeführt wurde, sondern von einem Prototyp abhing. ⓘ

Obwohl der Begriff "Wasserfall" in dem Papier nicht verwendet wird, wird das erste formale detaillierte Diagramm des Prozesses, das später als "Wasserfallmodell" bekannt wurde, häufig als Artikel von Winston W. Royce aus dem Jahr 1970 zitiert. Er war jedoch auch der Meinung, dass dieses Modell erhebliche Mängel aufwies, da die Tests erst am Ende des Prozesses stattfanden, was er als "riskant und zum Scheitern einladend" bezeichnete. Im weiteren Verlauf seines Papiers führte er fünf Schritte ein, die seiner Meinung nach notwendig waren, um "die meisten der mit dem unveränderten Wasserfallkonzept verbundenen Entwicklungsrisiken zu beseitigen". ⓘ

Royces fünf zusätzliche Schritte (zu denen auch die Erstellung einer vollständigen Dokumentation in verschiedenen Entwicklungsstadien gehörte) haben sich nie durchgesetzt, aber sein Diagramm dessen, was er für einen fehlerhaften Prozess hielt, wurde zum Ausgangspunkt für die Beschreibung eines "Wasserfall"-Ansatzes. ⓘ

Die früheste Verwendung des Begriffs "Wasserfall" findet sich möglicherweise in einem Papier von Bell und Thayer aus dem Jahr 1976. ⓘ

Im Jahr 1985 fasste das US-Verteidigungsministerium diesen Ansatz in DOD-STD-2167A, den Standards für die Zusammenarbeit mit Softwareentwicklungsunternehmen, zusammen, in dem es heißt, dass "der Auftragnehmer einen Softwareentwicklungszyklus einführt, der die folgenden sechs Phasen umfasst: Software-Anforderungsanalyse, vorläufiger Entwurf, detaillierter Entwurf, Kodierung und Einheitstests, Integration und Tests". ⓘ

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 zum Zeitpunkt der ersten Beschreibung des Wasserfallmodells kein formaler Softwareentwicklungsprozess existierte, wurden die bei Bau- und Produktion verwendeten Prozesse einfach für Softwareentwicklung adaptiert. ⓘ

Modell

Im ursprünglichen Wasserfallmodell von Royce werden die folgenden Phasen der Reihe nach durchlaufen:

  1. System- und Softwareanforderungen: werden in einem Produktanforderungsdokument festgehalten
  2. Analyse: Erarbeitung von Modellen, Schemata und Geschäftsregeln
  3. Entwurf: Ergebnis ist die Software-Architektur
  4. Kodierung: Entwicklung, Erprobung und Integration der Software
  5. Testen: die systematische Entdeckung und Behebung von Fehlern
  6. Betrieb: die Installation, Migration, Unterstützung und Wartung kompletter Systeme ⓘ

Das Wasserfallmodell besagt also, dass man erst dann zu einer Phase übergehen sollte, wenn die vorangegangene Phase überprüft und verifiziert wurde. ⓘ

Verschiedene modifizierte Wasserfallmodelle (einschließlich des endgültigen Modells von Royce) können jedoch leichte oder größere Abweichungen von diesem Prozess enthalten. Zu diesen Variationen gehört die Rückkehr zum vorherigen Zyklus, wenn in den nachgelagerten Phasen Fehler gefunden wurden, oder die Rückkehr bis zur Entwurfsphase, wenn die nachgelagerten Phasen als unzureichend erachtet wurden. ⓘ

Unterstützende Argumente

Die zu Beginn des Software-Produktionszyklus aufgewendete Zeit kann die Kosten in späteren Phasen senken. So ist beispielsweise ein Problem, das in den frühen Phasen (z. B. bei der Anforderungsspezifikation) gefunden wird, billiger zu beheben als derselbe Fehler, der später im Prozess gefunden wird (um den Faktor 50 bis 200). ⓘ

In der gängigen Praxis führen Wasserfallmethoden zu einem Projektplan, bei dem 20-40 % der Zeit für die ersten beiden Phasen, 30-40 % der Zeit für die Codierung und der Rest für Tests und Implementierung verwendet werden. Die eigentliche Projektorganisation muss sehr strukturiert sein. Die meisten mittleren und großen Projekte umfassen eine Reihe detaillierter Verfahren und Kontrollen, die jeden Prozess im Projekt regeln. ⓘ

Ein weiteres Argument für das Wasserfallmodell ist, dass es den Schwerpunkt auf die Dokumentation (z. B. Anforderungsdokumente und Entwurfsdokumente) sowie auf den Quellcode legt. Bei weniger gründlich konzipierten und dokumentierten Methoden geht Wissen verloren, wenn Teammitglieder vor Abschluss des Projekts ausscheiden, und es kann für ein Projekt schwierig sein, sich von diesem Verlust zu erholen. Wenn ein voll funktionsfähiges Entwurfsdokument vorhanden ist (wie es die Absicht von Big Design Up Front und des Wasserfallmodells ist), sollten neue Teammitglieder oder sogar ganz neue Teams in der Lage sein, sich durch Lesen der Dokumente einzuarbeiten. ⓘ

Das Wasserfallmodell bietet eine strukturierte Herangehensweise; das Modell selbst schreitet linear durch diskrete, leicht verständliche und erklärbare Phasen voran und ist daher einfach zu verstehen; es bietet auch leicht identifizierbare Meilensteine im Entwicklungsprozess. Vielleicht ist dies der Grund, warum das Wasserfallmodell in vielen Software-Engineering-Texten und -Kursen als Anfangsbeispiel für ein Entwicklungsmodell verwendet wird. ⓘ

Kritik

Die Kunden wissen möglicherweise nicht genau, welche Anforderungen sie haben, bevor sie eine funktionierende Software sehen, und ändern daher ihre Anforderungen, was zu einem neuen Design, einer Neuentwicklung und einem erneuten Testen sowie zu höheren Kosten führt. ⓘ

In diesem Fall ist es besser, den Entwurf zu überarbeiten, als auf einem Entwurf zu beharren, der keine neu entdeckten Einschränkungen, Anforderungen oder Probleme berücksichtigt. ⓘ

Unternehmen können versuchen, das Fehlen konkreter Kundenanforderungen dadurch zu beheben, dass sie Systemanalytiker damit beauftragen, bestehende manuelle Systeme zu untersuchen und zu analysieren, was sie leisten und wie sie ersetzt werden könnten. In der Praxis ist es jedoch schwierig, eine strikte Trennung zwischen Systemanalyse und Programmierung aufrechtzuerhalten. Das liegt daran, dass die Implementierung eines nicht-trivialen Systems fast zwangsläufig Probleme und Sonderfälle zutage fördert, die der Systemanalytiker nicht berücksichtigt hat. ⓘ

Als Reaktion auf die wahrgenommenen Probleme mit dem reinen Wasserfallmodell wurden modifizierte Wasserfallmodelle eingeführt, wie z. B. "Sashimi (Wasserfall mit überlappenden Phasen), Wasserfall mit Teilprojekten und Wasserfall mit Risikoreduzierung". ⓘ

Einige Organisationen, wie z. B. das US-Verteidigungsministerium, sprechen sich inzwischen ausdrücklich gegen Wasserfall-Methoden aus, beginnend mit dem 1994 veröffentlichten MIL-STD-498, der die evolutionäre Beschaffung sowie die iterative und inkrementelle Entwicklung fördert. ⓘ

Während die Befürworter der agilen Softwareentwicklung argumentieren, dass das Wasserfallmodell ein ineffektiver Prozess für die Softwareentwicklung ist, behaupten einige Skeptiker, dass das Wasserfallmodell ein falsches Argument ist, das nur dazu dient, alternative Entwicklungsmethoden zu vermarkten. ⓘ

Die Phasen des Rational Unified Process (RUP) erkennen die programmatische Notwendigkeit von Meilensteinen an, um ein Projekt auf Kurs zu halten, fördern aber Iterationen (insbesondere innerhalb von Disziplinen) innerhalb der Phasen. RNP-Phasen werden oft als "wasserfallartig" bezeichnet. ⓘ

Modifizierte Wasserfallmodelle

Als Reaktion auf die wahrgenommenen Probleme mit dem "reinen" Wasserfallmodell wurden viele modifizierte Wasserfallmodelle eingeführt. Diese Modelle können einige oder alle Kritikpunkte des "reinen" Wasserfallmodells aufgreifen. ⓘ

Dazu gehören die Rapid Development-Modelle, die Steve McConnell als "modifizierte Wasserfälle" bezeichnet: Peter DeGraces "Sashimi-Modell" (Wasserfall mit überlappenden Phasen), Wasserfall mit Teilprojekten und Wasserfall mit Risikominderung. Es gibt auch andere Kombinationen von Softwareentwicklungsmodellen wie das "inkrementelle Wasserfallmodell". ⓘ

Das endgültige Modell von Royce

Royce endgültiges Modell ⓘ

Das endgültige Modell von Winston W. Royce, seine beabsichtigte Verbesserung seines ursprünglichen "Wasserfallmodells", veranschaulichte, dass Rückkopplungen vom Testen des Codes zum Entwurf (wenn das Testen des Codes Fehler im Entwurf aufdeckt) und vom Entwurf zurück zur Anforderungsspezifikation (da Entwurfsprobleme die Beseitigung widersprüchlicher oder anderweitig unbefriedigender / nicht gestaltbarer Anforderungen erforderlich machen können) führen können (sollten und oft auch würden). In demselben Papier plädierte Royce auch für große Mengen an Dokumentation, dafür, die Arbeit "wenn möglich zweimal zu machen" (eine ähnliche Meinung wie Fred Brooks, der für das Schreiben des Mythical Man Month, eines einflussreichen Buches im Software-Projektmanagement, berühmt ist und der dafür plädierte, zu planen, "einen wegzuwerfen") und dafür, den Kunden so viel wie möglich einzubeziehen (eine ähnliche Meinung wie die des Extreme Programming). ⓘ

Royce Anmerkungen zum endgültigen Modell sind:

  1. Vollständiger Programmentwurf vor Beginn der Analyse und Codierung
  2. Die Dokumentation muss aktuell und vollständig sein
  3. Führen Sie die Arbeit nach Möglichkeit zweimal aus
  4. Testen muss geplant, gesteuert und überwacht werden
  5. Den Kunden einbeziehen ⓘ

Phasen

  1. Anforderungsanalyse und -spezifikation resultiert im Lastenheft
  2. Systemdesign und -spezifikation resultiert in der Softwarearchitektur
  3. Programmierung und Modultests resultiert in der eigentlichen Software
  4. Integrations- und Systemtest
  5. Auslieferung, Einsatz und Softwarewartung ⓘ

Eine andere Variante macht daraus sechs Schritte:

  1. Planung (mit Erstellung des Lastenhefts, Projektkalkulation und Projektplan) (Systems Engineering)
  2. Definition (mit Erstellung des Pflichtenhefts, Produktmodell, GUI-Modell und evtl. schon Benutzerhandbuch)
  3. Entwurf (UML, Struktogramme) (Design)
  4. Implementierung (Programmierung)
  5. Testen (Testprotokoll)
  6. Einsatz und Wartung (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 Softwaretestens (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
  • Klare Abschätzung von Kosten und Umfang bei stabilen Anforderungen ⓘ

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: Die einzelnen 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
  • Durch die Einführung des vollständigen Systems zu einem bestimmten Zeitpunkt (Big Bang) werden Fehler unter Umständen erst spät erkannt 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:

  • Spiralmodell (Weiterentwicklung)
  • Rational Unified Process
  • Extreme Programming
  • Agile Softwareentwicklung
  • Iteratives Prototyping und Evolutionäres Prototyping
  • Weitgehende Verwendung von konfigurierbarer Standardsoftware, z. B. für das Workflow-Management oder die Benutzerverwaltung
  • Auf die Entwicklungsphase ausgeweitetes Veränderungsmanagement
  • Auslagerung weniger priorisierter Teilaufgaben an Power-User, siehe auch unter End-user Computing
  • Ausgeprägte Modularisierung, bis hin zum Aufsplitten großer in kleinere, besser überschaubare Projekte mit kurzer Laufzeit
  • V-Modell ⓘ
Abgerufen von „http://besserwiki.de/index.php?title=Wasserfallmodell&oldid=42390“