Hi, herzlich willkommen in dieser Lektion, in der wir uns die Grundlagen des Wasserfalls-Modells anschauen.

Welchen Inhalt hat diese Lektion?

Wir sprechen in den nächsten Minuten über

• die Definition von Fachbegriffen, die für das Verständnis dieser Lektion wichtig sind,
• 2 verschiedene Versionen für die Standardphasen,
• Projektphasen und Aktivitäten,
• Leitlinien,
• Vor- und Nachteile,
• sowie über Anwendungsfälle und Anwendungsgebiete für diese Methode.

Vorab wieder die Begriffsdefinition für Fachbegriffe in dieser Lektion:

Was ist eine Anforderungsphase?

Die Anforderungsphase im Projektmanagement beschreibt den Zeitabschnitt der Aufnahme von Anforderungen aus den Fachbereichen und der IT, aus denen in der Folge eine Lösung entwickelt wird.

Was ist ein Lastenheft?

Das Lastenheft beschreibt, was die Anforderer haben möchten und ist damit das Ergebnis aus der Anforderungsphase.

Was ist eine Spezifikation?

Die Spezifikation leitet sich aus den Anforderungen der Fachbereiche und der IT ab und beschreibt die notwendigen darüberhinausgehenden Anforderungen, die ein Fachbereich oder die IT ohne Software-Entwicklungs-Wissen oder spezielles Expertenwissen nicht kennen können.

Was ist ein Systemdesign?

Das Systemdesign beschreibt das grobe Zusammenspiel der zu entwickelnden Lösung mit anderen Software-Systemen und beschreibt gleichzeitig auch die dazu grundsätzlich notwendige Hard- und Software-Infrastruktur.

Was ist eine Systemspezifikation?

Die Systemspezifikation leitet sich aus dem Systemdesign ab und beschreibt die Details der notwendigen Schnittstellen zu anderen Software-Systemen und die genauen Anforderungen and die Hard- und Software-Infrastruktur.

Was ist ein Produktmodell?

Die Software-Architektur beschreibt das Datenmodell (teils auch als Produktmodell bezeichnet), das Zusammenspiel aus Front-, Backend und User Interface (oft einfach als GUI bezeichnet) sowie die Struktur der Datenspeicherung und des Speichermanagements. Die Struktur der Datenspeicherung beschreibt dabei die permanente Speicherung von Daten, die Struktur des Speichermanagements das Zusammenspiel von temporärem und permanentem Speicher.

Was ist ein Pflichtenheft?

Das Pflichtenheft leitet sich aus dem Lastenheft ab und beschreibt, was alles getan werden muss, um die Anforderungen aus dem Lastenheft erfüllen zu können und ist damit das Ergebnis aus der Spezifikation, dem Systemdesign, der Systemspezifikation und der Software-Architektur.

Was ist ein Modultest?

Ein Modultest beschreibt den funktionalen Test einer aus einer Anforderung abgeleiteten neu entwickelten Funktionalität „innerhalb“ der Entwicklungs-Infrastruktur. Dafür kann entweder eine umfassende Installation auf einer Sandbox auf einem Entwicklungsrechner, eine extra eingerichtete umfassende Entwicklungs-Instanz auf einem Server oder sogar eine extra eingerichtete Test-Instanz auf einem Server genutzt werden. Für das Verständnis ist es wichtig, dass der Modultest noch nicht das Zusammenspiel mit anderen Neuentwicklungen beinhaltet.

Was ist ein Integrationstest oder Systemtest?

Integrationstests oder Systemtests finden erst im späteren Verlauf auf einer extra dafür eingerichteten Instanz statt. In dieser Phase werden Neuentwicklungen eingesammelt, die Anforderungen geprüft und bei Problemen mit Korrekturvorgaben an die Entwickler zurückverwiesen – nach erfolgter Korrektur erneut geprüft.

Was ist ein UML-Diagramm?

UML-Diagramme sind fest definierte Diagramm-Typen mit fest definierten Diagramm-Elementen und Pflichtinhalten, die in der Gesamtheit alle Merkmale einer Software beschreiben sollen. UML 2.3 kennt 7 Strukturdiagramme und 7 Verhaltensdiagramme. Weitergehende Informationen dazu findest Du bei Wikipedia unter Unified Modeling Language:  https://de.wikipedia.org/wiki/Unified_Modeling_Language

Was ist ein Struktogramm?

Ein Struktogramm ist ein Diagramm, das die Struktur und Zusammenspiel einer Software leichter verständlich graphisch veranschaulicht.

Was ist ein Top-Down-Verfahren?

Das Top-Down-Verfahren geht davon aus, dass eine Lösung mit einer groben Beschreibung beginnt und dann in mehreren Schritten immer weiter ins Feinere vertieft wird, bis die Lösung fertig entwickelt ist.

Was ist ein Return of Invest (ROI)?

Der Return of Invest (oft auch einfach ROI genannt) beschreibt den Zeitpunkt, an dem sich eine Investition unter Berücksichtigung aller positiven und negativen Effekte aus der alten und neuen Lösung rentiert, d.h. die Einsparungen die Investition überschreiten. In einer ROI-Analyse können immer nur greifbare Zahlen verarbeitet werden. Nichtgreifbare Einflüsse müssen in greifbare Zahlen überführt werden oder als Anhang zur ROI-Analyse als zusätzliche Entscheidungskriterien ausgeliefert werden.

Was ist ein Gantt-Diagramm?

Nun zum Inhalt dieser Lektion: Der Name Wasserfall leitet sich aus der grafischen Darstellung eines Projekts in Kaskaden ab, wie es dieses exemplarische Gantt-Diagramm zeigt:

Wo ist das Wasserfall-Modell entstanden?

Ursprünglich kommt dieses Modell aus der Hochbau-Branche, hat sich dann über den komplexen Anlagenbau auch in andere Branchen verbreitet, in denen spätere Änderungen sehr teuer bis praktisch unmöglich sind. Änderungen am Fundament sind nach Abschluss eines Rohbaus schlicht nicht mehr möglich – oder eben sehr teuer, weil dann alles wieder abgerissen, beseitigt und neu gebaut werden müsste.

Welche Standard-Phasen beschreibt das Wasserfall-Modell für die Softwareentwicklung?

Das Wasserfall-Modell „für die Softwareentwicklung“ beschreibt dabei folgende Standard-Phasen:

1. Die Anforderungsphase und Spezifikation, die in einem Lastenheft mündet (englisch: Requirement Analysis and Specification). Ich nenne hier auch die englischen Begrifflichkeiten, weil wir in Software-Projekten so oft die englischen Begriffe nutzen. Vielleicht fühlst Du Dich damit etwas besser mit Deinen Praxiserfahrungen verbunden.
2. Gibt es das Systemdesign und die Systemspezifikation, aus denen die Softwarearchitektur hervor geht (englisch: System Design and Specification)
3. Die Programmierung und Modultests, in denen die eigentliche Software entsteht (englisch: Coding and Module Testing)
4. Die Integrations- und System-Tests zur Sicherstellung der Funktionsfähigkeit im Gesamtsystem (englisch: Integration and System Testing)
5. Die Auslieferung, der Betrieb und die Wartung der Softwarelösung im Produktivsystem (englisch: Delivery, Deployment and Maintenance)

Eine andere häufig genutzte Alternative macht daraus 6 Phasen:

1. Die Planung mit Erstellung des Lastenhefts, der Projektkalkulation und der Projektplanung (englisch: Systems Engineering)
2. Die Definitionsphase mit Erstellung des Pflichtenhefts, dem Produktmodell, dem GUI-Modell und möglicherweise auch schon mit einem Grundmodell für das Benutzerhandbuch (englisch: Analysis)
3. Die Entwurfsphase mit UML-Diagrammen und Struktogrammen (englisch: Design)
4. Die Implementierung (englisch: Coding oder auch Implementation)
5. Das Testen (englisch: Testing)
6. Der Einsatz und die Wartung (englisch: Maintenance)

Wie werden Projektphasen im Wasserfall-Modell geplant?

Beim Wasserfall-Modell werden Projektphasen (hier im Diagramm blau dargestellt) und dazugehörige Aktivitäten linear als Abfolge geplant und umgesetzt. Projektphasen beinhalten eine oder mehrere Aktivitäten. Projektphasen und Aktivitäten können dabei sowohl aufeinander folgend als auch parallel oder überlappend organisiert werden. Bei verspäteter Fertigstellung einer Aktivität verschieben sich zum Beispiel automatisch alle davon abhängige Folge- und ggf. auch Parallelaktivitäten inklusive sich damit verändernder Personal- und Infrastrukturbedarfe.

Jede Phase und jede Aktivität im Wasserfall-Modell beinhalten einen vordefinierten Start- und Endzeitpunkt mit klar definierten Ergebniserwartungen. Zudem werden im Wasserfall-Modell Meilensteine eingeplant. Meilensteine sind festgelegte Termine, bei denen zuvor festgelegte Ergebniserwartungen überprüft und vom Projektmanagement abgenommen werden. Meilensteine werden in der Regel an jedem Phasenende, zum Ende ausgewählter Aktivitäten oder zu außerhalb des Projekts definierten Zeitpunkten z.B. durch übergeordnete Hierarchien festgelegt.

Welche Leitlinien hat das Wasserfall-Modell?

Damit das Wasserfall-Modell sauber funktioniert, gibt es folgende Leitlinien:

1. Aktivitäten sind in der „vorgegebenen“ Reihenfolge „vollständig“ durchzuführen
2. Das Wasserfall-Modell ist ein dokumentengetriebenes Modell. Das bedeutet, dass am Ende jeder Aktivität ein fertiggestelltes Dokument entsteht (typischerweise in Software-Tools wie z.B. Confluence, Sharepoint, TFS (die Kurzform für Team-Foundation-Server), Jira oder Polarion)
3. Der Entwicklungsablauf ist sequenziell: eine Aktivität kann erst dann gestartet werden, wenn alle dafür notwendigen Grundlagen „vollständig“ verfügbar sind, die zumeist in den vorherigen Aktivitäten erstellt werden
4. Wie im Top-Down-Verfahren wird vom Allgemeinen in Richtung zum Speziellen gearbeitet
5. Das Modell ist einfach und auch für Außenstehende leicht zu verstehen und leicht zu überblicken
6. In der ersten Phase des Wasserfall-Modells ist die Begleitung des Fachbereichs oder des Kunden ausdrücklich vorgesehen. Ab der zweiten Phase ist der Fachbereich oder Kunde „nicht“ mehr vorgesehen

Welche Vorteile hat das Wasserfall-Modell?

Vorteil dieses Modells ist ganz klar, dass bei konsequenter Aktualisierung der Planung eine immer aktuelle Zeit-, Personal- und Ressourcenplanung verfügbar ist. Zudem liefert uns dieses Modell die Grundlagen zur fortwährenden Neuberechnung der Budget-, Zeit- und Ressourcenplanung sowie der Aktualisierung der Soll-Ist-Planung für das Controlling bis zum Projektabschluss. Dieses Modell gibt uns auch die Flexibilität, auf ungeplante Veränderungen oder Mehr- sowie Minderaufwände durch Verschiebung reagieren zu können.

Welche Nachteile hat das Wasserfall-Modell?

Nachteile dieses Modells sind, dass es in der Softwareentwicklung selten klar abgegrenzte Phasen gibt, die Übergänge sind eher fließend. Teile des Systems können sich noch in der Planung befinden, während andere Teile bereits in der Umsetzung oder sich sogar bereits im Gebrauch befinden.

Es gibt auch ein Abfolge-Problem: Die einzelnen Aktivitäten laufen geplant fest verbunden nacheinander, parallel oder überlappend ab. Die in der Praxis auftretenden Rückschritte sind in diesem Modell nicht abbildbar.

Dazu kommt, dass das Modell gegenüber Anforderungsänderungen oder Anforderungsergänzungen sehr unflexibel ist. Jegliche auch nur sehr kleine Änderung oder Ergänzung muss im Modell den gesamten Ablauf von vorne beginnen, erzeugt dadurch überproportional hohe Aufwände und die Zeit bis zur Realisierung ist deshalb unverhältnismäßig hoch. Das frühe Festschreiben von Anforderungen ist problematisch, weil es deshalb zu unverhältnismäßig teuren Änderungen führt, die bei angepasster Anforderung auch mit wenig Aufwand zu lösen wären. Zudem sind Anforderungen im heutigen Geschäftsbetrieb sehr kurzweilig. Oft sind Anforderungen bis zur Inbetriebnahme bereits überholt, wenn die Realisierungszeiten zu hoch sind. Resultat ist dann eine Software-Lösung mit Anforderungen von gestern, die immer hinterherhinkt. Wem kommt diese Aussage unter Software-Anwendern und Fachbereichsleitern nicht bekannt vor? Das ist eben auch die Ursache dafür, dass so viele Anwender mit selbstgestrickten Excel-Lösungen anstatt mit bereitgestellter Software-Funktionalität arbeiten – mit allen dadurch ausgelösten Folgeproblemchen.

Zudem ist es so, dass eine Software mit diesem Modell extrem spät nach Beginn des Entwicklungszyklus in Betrieb geht und der damit verbundene Return of Invest so sehr verzögert ist, dass er möglicherweise sogar negativ geworden ist und sich das „Verbesserungsprojekt“ gar nicht gelohnt hat, nur Kosten verursacht hat. Das kann nicht das Ziel sein und ist ein häufiger Kritikpunkt für Softwareprojekte sowohl aus den Fachbereichen als auch der Unternehmensleitung. Von der Hand zu weisen ist diese Kritik auf jeden Fall nicht. Nur zu lösen!

Was ist ein Big Bang?

Im Wasserfall-Modell wird eine Lösung vom Anfang bis zum Ende umgesetzt und ist erst nach Abschluss aller Aufgaben einführungsbereit. Diesen Zeitpunkt bezeichnet man dann nicht umsonst als „Big Bang“, bei dem sich herausstellt, ob die Lösung funktioniert, oder sich wie bei Software üblich, erst im Realbetrieb herausstellt, dass noch eine Vielzahl von Bugs zu beheben ist. Im Gegensatz zu einer alternierenden Projektmethode überfluten die nachträglichen Bug-Meldungen dann alle auf einmal die Entwicklungsabteilung – und die Lösung lässt erwartungsgemäß auf sich warten. Das Schlimmste wäre jedoch, wenn die Lösung dann gar nicht mehr zur Anforderung passt, nie im Geschäftsbetrieb genutzt wird und damit die gesamte Investition versenkt ist. Und das kommt leider gar nicht so selten vor …

Wann ist ein Wasserfall-Modell vorteilhaft?

Wasserfall-Modelle sind vor allem dann vorteilhaft,

• wenn sich Anforderungen und Abläufe bereits in der Planungsphase präzise beschreiben und planen lassen,
• wenn die Lösung sich aus nicht allzu sehr verändernden Lösungsbausteinen zusammensetzt,
• wenn keine experimentellen Inhalte mit unsicherem Ausgang enthalten sind,
• wenn die Lösung auch nach langer Realisierungszeit vorhersehbar über eine lange Zeit eingesetzt werden soll,
• wenn sich die Anforderungen nach der Anforderungsermittlung nicht mehr verändern oder erweitern
• wenn das Projekt sich streng an übergeordnete Hierarchien, Personal- oder die Finanzabteilungen anlehnen muss, die mit festen Zeitvorgaben, Ressourcenplanungen und Budgets arbeiten – oder für die zu entwickelnde Lösung sogar publizierungspflichtig sind und demnach Anlegererwartungen erfüllen müssen, und
• wenn alternierende Organisationsmodelle eine komplette Grundlagenarbeit sowie alle darauf basierende Lösungen immer und immer wiederholen müssten.

In diesen Fällen macht es dann tatsächlich großen Sinn, sich etwas intensiver mit den Grundlagen zu befassen und diese nach wohl überlegter Festlegung auch nicht mehr bis selten anzurühren. In der Praxis ist das im Bereich der Softwareentwicklung vor allem die Entwicklung des Datenmodells und der Systemarchitektur. Denn überlege Dir, was passiert, wenn nach 2/3 der Projektzeit das Datenmodell komplett überarbeitet werden müsste und alle darauf basierenden Entwicklungen angepasst oder neu entwickelt werden müssten. Das kommt bei unsauberer Anforderungsermittlung für das Datenmodell und die Systemarchitektur tatsächlich vor – und ist nicht selten mit dem Projektabbruch aufgrund von massiver Budget- und Zeitüberschreitung gleichzusetzen. Eine schallende Ohrfeige für die Projektorganisation wegen Budget- und Ressourcenverschwendung.

Wo ist das Wasserfall-Modell verbreitet?

In der Praxis ist das Wasserfall-Modell besonders in Großunternehmen sehr verbreitet, die dafür auch für ihre Behäbigkeit bekannt sind. Auf der anderen Seite erfordert die Unternehmens-Mentalität, die Stakeholder-Befriedigung und finanzgesteuerte Entscheidungen von Großunternehmen genau diese Vorgehensweise. Auf den offensichtlichen Widerspruch dieser Mentalität und agiler Organisation gehe ich später noch genauer ein.

Und wie gesagt: ich möchte bei dieser Übersicht nur ganz grob und oberflächig auf die Projekt-Management-Methoden eingehen, mit denen wir im Alltag Berührungspunkte haben, damit wir wissen, welche Optionen uns für welche Herausforderungen zur Verfügung stehen.

Fassen wir nun zusammen, was wir in dieser Lektion behandelt haben:

• wir haben eine ganze Reihe von Fachbegriffen kennengelernt.
• Wir kennen nun 2 Versionen für die Standardphasen,
• wir kennen die Projektphasen und Aktivitäten,
• Leitlinien,
• Vor- und Nachteile dieser Methode,
• sowie geeignete Anwendungsfälle und Anwendungsgebiete für das Wasserfall-Modell.

In der übernächsten Lektion behandeln wir das Gegenstück zum Wasserfall-Modell, nämlich das Agile Projektmanagement. Doch zuvor gibt es für Dich eine kleine Überraschung: Die folgende Lektion beinhaltet ein kurzes Quiz, bei dem Du für Dich selbst prüfen kannst, welche Inhalte aus dieser Lektion bei Dir hängengeblieben sind. Ich wünsche Dir viel Spaß dabei, wir sehen uns in der übernächsten Lektion wieder!