Author
Die Wasserfallmodell-Softwareentwicklung galt lange Zeit als das dominante Vorgehensmodell, nach dem sich der Project Life Cycle, Prozesse und Softwareentwicklungsteams gerichtet haben. Hierbei handelt es sich um ein lineares Vorgehensmodell, das in strikter Reihenfolge ausgeführt wird: Eine Phase beginnt erst, wenn die vorherige endet.
- Analyse
- Design
- Entwicklung
- Test
- Wartung
Der Name des Vorgehensmodells macht deutlich, dass das traditionelle Wasserfallmodell es nicht erlaubt, zu früheren Phasen des Life Cycles zurückzukehren – das Projekt fließt wie ein Wasserfall nur in eine Richtung.
Bis zur Jahrhundertwende und der Veröffentlichung des Agile Manifestos im Jahr 2001, das seitdem eine Reihe von Softwareentwicklungs-Frameworks mit agiler Methodik wie Scrum oder Adaptive Software Development (ASD) hervorgebracht hat, folgten die meisten bedeutenden Softwareentwicklungsprojekte der Wasserfallmodell-Softwareentwicklung.
Beispielsweise formalisierte das United States Department of Defense im Jahre 1985 Standards, die jedes Softwareentwicklungsunternehmen oder Spezialisten erfüllen mussten, um an Definition of Done (DoD) Projekten zu arbeiten. Diese Anforderungen drehten sich um einen nicht verhandelbaren, 5-stufigen Wasserfall Life Cycle:
- Anforderungsdefinition
- Vorläufiges Design
- Detailliertes Design
- Coding- und Unit-Tests
- Integration und Test
Dürfen wir Sie bei Ihrem nächsten Softwareentwicklungsprojekt unterstützen?
Flexible Modelle nach Maß!
Die Phasen der Wasserfall Softwareentwicklung
Je nach Quelle wird der Wasserfallansatz in unterschiedliche Phasen eingeteilt. Das einfachste Wasserfallmodell besteht aus lediglich 4 Phasen:
- Anforderungsdefinition
- Design
- Implementation
- Test
Die meisten Diagramme und Beschreibungen ergänzen das Wasserfallmodell mit ein oder zwei weiteren Phasen. Das DoD Wasserfallmodell hat beispielsweise zwei Designphasen – eine vorläufige sowie eine detaillierte Designphase. Im Kontext der Softwareentwicklung werden ebenfalls oft „Bereitstellung“ und „Wartung“ als zwei weitere Phasen ergänzt.
Anforderungsdefinition
Der lineare Charakter der Wasserfall-Methodik gibt der ersten Phase eine ganze besondere Bedeutung im Life Cycle. Alle Anforderungen an das Programm und die Funktionen des endgültigen Softwareprodukts werden hier ermittelt.
Sobald die Anforderungsdefinition abgeschlossen wurde, sollte das Softwareentwicklungsteam über alle erforderlichen Informationen verfügen, um das Projekt ohne jegliche oder nur minimale Beteiligung des Auftraggebers abzuschließen.
Design
Die Designphase wird oft in zwei Phasen unterteilt – logisches (oder vorläufiges) Design und physisches (oder detailliertes) Design. In der logischen bzw. vorläufigen Designphase werden alle möglichen Lösungen und deren Stärken und Schwächen im jeweiligen Kontext analysiert.
Nachdem die theoretischen Ideen bewertet und Entscheidungen getroffen wurden, werden sie in der physischen bzw. detaillierten Entwurfsphase dokumentiert und als konkrete Spezifikationen festgehalten.
Implementation/Codierung
Der Kern eines jeden Projekts – wenn Softwareentwickler den eigentlichen Code schreiben und zusammenfügen, um aus den in der Designphase detaillierten Spezifikationen ein funktionierendes Softwaresystem zu erstellen.
Test
Nachdem die Implementationsphase vollständig abgeschlossen wurde, müssen manuelle Softwaretester (die in aktuellen Softwareentwicklungsprojekten möglicherweise durch automatisierte Testwerkzeuge unterstützt werden) sicherstellen, dass jede Komponente des Softwaresystems sowohl autonom als auch über alle Abhängigkeiten hinweg wie beabsichtigt funktioniert.
Tester verwenden die in der Designphase erstellte Dokumentation, User-Personas und User-Journey-Szenarien, um so viele Testfälle wie möglich auszuführen, damit alle Fehler aufgedeckt werden, die es vor der Bereitstellung zu beheben gilt.
Bereitstellung
Wenn das Softwaresystem getestet und freigegeben wurde, muss eine Kopie aus der Softwareentwicklungsumgebung übertragen und in der Live-Staging-Umgebung veröffentlicht werden, von der aus Benutzer hierauf zugreifen können. Diese Phase wird Bereitstellung genannt.
Die für die Bereitstellung verantwortlichen Teammitglieder sollten sich aller Unterschiede zwischen der Softwareentwicklungs- und der Live-Serverumgebung bewusst sein und alle erforderlichen Anpassungen vornehmen, damit die Software auf die gleiche Weise funktioniert.
Wartung
In der Wartungsphase ist die Software im Einsatz und die Hauptaufgabe besteht nun darin, sie verfügbar und reibungslos zu halten sowie von Benutzern gemeldete Fehler zu beheben, die während der Testphase möglicherweise übersehen wurden.
K&C – WIR KREIEREN EINZIGARTIGE TECH-LÖSUNGEN SEIT ÜBER 20 JAHREN. WIR VERSCHAFFEN IHNEN IHREN WETTBEWERBSVORTEIL!
Schreiben Sie uns eine Nachricht, um Ihre individuellen Bedürfnisse oder das nächste Projekt zu besprechen.
Die Geschichte der Wasserfallmethodik – kritisiert vom eigenen Erfinder
Gerüchten zufolge wurde der Begriff „Wasserfall“ zum ersten Mal in wissenschaftlichen Studien ab dem Jahre 1976 verwendet, um ein Vorgehensmodell für die Softwareentwicklung zu beschreiben. Diese Referenzen zum Wasserfallmodell wurden zuerst vom amerikanischen Computer-Wissenschaftler Winston Walker Royce in einem Artikel in Diagrammform festgehalten.
Royce war Leiter des Lockheed Technology Centre in Austin Texas und wird von der Mehrheit als Pionier in diesem Bereich der Softwareentwicklung angesehen. Der Artikel zeigte ein Diagramm mit fünf aufeinanderfolgenden Phasen, die später mit dem Begriff „Wasserfallmodell“ beschrieben wurden, auch wenn Royce diesen Begriff nie selbst genutzt hat.
Tatsächlich sprach sich Royce gegen die Wasserfall-Methodik aus und beschrieb sie als „risikoreich und fehleranfällig“. Der Hauptteil des Artikels skizzierte fünf zusätzliche Phasen, die seiner Meinung nach die Mängel des vereinfachten ursprünglichen Life Cycles ausgleichen würden, um „den Großteil der Entwicklungsrisiken zu eliminieren“.
Das ausgefeiltere Wasserfallmodell von Royce betonte die Notwendigkeit, den Benutzer mit einzubeziehen, den gesamten Prozess zu testen und in verschiedenen Phasen umfangreiche Dokumentationen zu erstellen. Das Modell gewann nie wirklich an Zugkraft, aber das „fehleranfällige“ Originaldiagramm wurde dagegen immer populärer.
Es wurde die Methode der Wahl für strategisch wichtige Softwareentwicklungsprojekte auf Unternehmensebene wie beispielsweise CRM- und Supply-Chain-Management-Systeme. Selbst US-Regierungsabteilungen forderten das DoD-Modell von Softwareentwicklern ein.
Der Fall eines Empires – wie die Schwächen des Wasserfallmodells durch den Fortschritt in der Softwareentwicklung aufgedeckt wurden
Als Softwaresysteme in den 1980er und 1990er Jahren größer und komplexer wurden, kamen die von Royce hervorgehobenen Schwächen des traditionellen Wasserfallmodells zum Vorschein. Große Organisationen wie Regierungsabteilungen, Banken und Blue-Chip-Unternehmen aus verschiedenen Industrien starteten inzwischen ehrgeizige Softwareentwicklungsprojekte mit neuen Technologien, um diese effizienter zu gestalten.
Es gibt unzählige Geschichten von unglaublich teuren Projekten, die sich im Endeffekt als Investitionsruine entpuppten. Die gängigsten Gründe, warum Softwareentwicklungsprojekte fehlschlagen, lassen sich wie folgt zusammenfassen:
- Die Entwicklung dauert so lange, dass das Produkt bereits bei der Veröffentlichung veraltet ist.
- Es dauert zu lange, bei der Entwicklung noch vor der Veröffentlichung auf die Marktveränderungen zu reagieren.
- Der Umfang ist zu groß, um vom Projektmanagement effektiv gehandhabt zu werden.
- Falsche Annahmen und fehlendes Verständnis der Benutzerbedürfnisse in der Anforderungsdefinition bedeuten, dass das fertige Softwareprodukt nicht für jeweiligen Zweck geeignet ist.
- Das Ausmaß an Fehlern und anderen Problemen, die in der Testphase entdeckt wurden, ist zu groß, um die Behebung wirtschaftlich zu rechtfertigen.
Das streng lineare Wasserfallmodell spielte jedem dieser Risiken direkt in die Hände. Die eingangs beschlossenen Anforderungen wurden mit Präzision geliefert. Dieser Ansatz funktioniert nur, wenn sich die zu Beginn des Projekts gestellten Anforderungen schlussendlich auch wirtschaftlich auszahlen.
Aber als Softwaresysteme größer und komplexer wurden, wurden auch mehr Variablen eingeführt. Mehr Variablen bedeuteten eine höhere Wahrscheinlichkeit falscher Annahmen und anderer Fehler während der Anforderungsdefinition.
Mit einem Wasserfallansatz werden diese falschen Annahmen und Fehler oft erst am Ende des Projekts entdeckt. Je größer und teurer das Projekt, desto höher ist die Anfälligkeit für Misserfolge.
Dies führte zu vielen spektakulären Fehlprojekten, sodass der Ruf der Wasserfallmethodik schweren Schaden nahm. Benutzerorientiertere Variationen wie das V-Modell, die Tests zu einem früheren Zeitpunkt des Life Cycles einführten, versuchten die Schwächen zu kompensieren und den Wasserfallansatz flexibler zu gestalten.
Agile übertrifft den Wasserfallansatz als dominantes Vorgehensmodell
Als Förderband kostspieliger, manchmal sogar spektakulärer Investitionsruinen, wurden ständig neue Beweise dafür geliefert, dass die Wasserfallmethodik nicht mehr in die zeitgenössische Softwareentwicklung passt. Dagegen gewann eine Alternative schnell an Bedeutung.
Die agile Methodik als Ersatz des Wasserfallmodells wurde noch vor der Zeit von sozialen Medien von einflussreichen Influencern aus der Tech-Szene Silicon Valleys unterstützt. Der kalifornische Einfluss zeigte sich insbesondere in der enthusiastischen, manchmal auch dogmatischen Einführung von agilen Frameworks wie Scrum, die strenge Rituale wie „Daily Stand-ups“ vorschrieben und Rollennamen wie „Scrum Master“ einführten.
Trotz einiger dieser „zu kalifornischen“ Rituale boten agile Vorgehensmodelle und Frameworks – von Scrum bis SAFe (Scaled Agile Framework) und SoS (Scrum of Scrums) – mehr Vorteile für ein zeitgemäßes Projektmanagement in der Softwareentwicklung.
Der Kern des agilen Ansatzes für die Softwareentwicklung besteht darin, dass er iterativ und flexibel bzgl. der sich ändernden Anforderungen ist. Die Methodik geht von der Annahme aus, dass es für viele Softwareentwicklungsprojekte schwierig und oft unrealistisch ist, zu Beginn des Projekts die vollständigen Anforderungen zu erfassen. Selbst bei bester Absicht und sorgfältiger Detailverliebtheit wird es unausweichlich zu falschen Annahmen kommen, die im schlimmsten Fall zu einer Investitionsruine führen und in weniger extremen Fällen dennoch von den Nutzern nicht angenommen werden.
Unterschiedliche agile Frameworks unterscheiden sich in ihren Life Cycle Phasen, Details und vorgegebenen Schritten. Aber sie alle priorisieren die Entwicklung und Einführung eines funktionierenden Minimum Viable Products (MVP), das die geringstmögliche Anzahl von Funktionen und gleichzeitig einen Mehrwert für die Endnutzer liefert. Das MVP wird dann basierend auf Benutzerverhalten und Feedback iteriert und nimmt im Laufe der Zeit oft erheblich an Umfang und Komplexität zu.
Dieser iterative Loop-Back-Ansatz von Agile trägt wesentlich dazu bei, das Risiko zu neutralisieren, dass viel Zeit und Geld für die Entwicklung eines Softwareprodukts aufgewendet wird, das sich aus irgendeinem Grund als nicht zweckdienlich oder konkurrenzfähig herausstellt. Jedes größere Problem sollte schnell identifiziert und korrigiert werden, ohne dass ein großes Softwareprodukt mit komplexen Abhängigkeiten auf der Grundlage falscher Annahmen auseinandergenommen werden muss.
Kann das Wassermodell jemals das beste Vorgehensmodell für die Softwareentwicklung sein?
Wie jedes Vorgehensmodell hat auch der Wasserfallansatz seine Stärken und Schwächen. Er hat sich fast zwei Jahrzehnte lang als dominantes Vorgehensmodell für die Softwareentwicklung etabliert, was nicht möglich wäre, wenn dieser Ansatz gar nichts zu bieten hätte.
Die Stärken und Schwächen vom Wasserfallmodell liegen sowohl in seiner Einfachheit als auch seiner Geradlinigkeit. Ein Wasserfallansatz kann für kleinere Projekte sinnvoll sein, bei denen die Anforderungen glasklar sind, die erforderlichen Ressourcen vollständig zur Verfügung gestellt werden können und eine knappe, unmittelbar bevorstehende Freigabefrist besteht.
Projekte mit folgenden Eigenschaften können besonders von den Stärken des Wasserfallmodells profitieren:
- Die Anforderungen sind klar, unveränderbar und eindeutig
- Die Produktdefinition ist stabil
- Der Technologie-Stack ist definiert und wird vollständig verstanden
- Finanzielle und fachliche Ressourcen werden vollständig zur Verfügung gestellt
- Der Zeitplan des Projekts ist kurz
Projekte mit folgenden Eigenschaften eignen sich nicht für ein Wasserfallmodell:
- Die Risiken fallen hoch aus und der Umfang kann sich ändern, wenn die Annahmen präziser werden
- Mittlere bis hohe Komplexität
- Mittlerer bis langer Zeitrahmen für die Implementierung
- Die Produktentwicklung ist ein fortlaufender Prozess
- Variablen können sich ändern, bevor das fertige Softwareprodukt freigegeben wird
Die Realität ist, dass es im Jahr 2021 nur sehr wenige Softwareentwicklungsprojekte gibt, die alle Kriterien erfüllen, um die Stärken des Wasserfallmodells zu nutzen und gleichzeitig die Schwächen zu vermeiden. Jedoch gibt es diese Projekte, was bedeutet, dass das Wasserfallmodell im Jahr 2021 nicht völlig ausgestorben ist. Aber die Umstände, die durch die Wasserfallmodell-Softwareentwicklung begünstigt werden, sind so selten, dass das Vorgehensmodell heute weitestgehend als Legacy-Modell aus einer früheren Ära der Softwareentwicklung betrachtet wird.
Wann gelingt IT Outsourcing?
(und wann nicht?)
