Mit Google fortfahren
Wasserfallmodell: Phasen und Einsatz einfach erklärt
Das Wasserfallmodell ordnet ein Projekt in aufeinanderfolgende Phasen. Im klassischen Modell wird jede Phase abgeschlossen, bevor die nächste beginnt; reguläre Rücksprünge sind nicht vorgesehen. Das schafft Planbarkeit, erschwert aber spätere Änderungen.
Du lernst, die fünf verbreiteten Phasen zu erklären, das Modell auf ein Softwareprojekt anzuwenden und seine Eignung anhand der Anforderungen zu beurteilen.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Warum fließt ein Projekt wie ein Wasserfall?
Stell dir vor, ein Team beginnt erst mit dem Programmieren und fragt danach, was die Software eigentlich leisten soll. Viel Arbeit müsste möglicherweise wiederholt werden. Das Wasserfallmodell versucht, solche Sprünge durch eine feste Reihenfolge zu verhindern.
Wasserfallmodell
Das Wasserfallmodell ist ein lineares beziehungsweise sequenzielles Vorgehensmodell. Die Ergebnisse einer Phase bilden die Grundlage der folgenden Phase. Im klassischen Modell wird jede Phase nur einmal durchlaufen.
Der Name beschreibt das Bild eines Wasserfalls: Das Projekt bewegt sich stufenweise in eine Richtung. Eine abgeschlossene Phase wird normalerweise nicht erneut geöffnet.
Am Ende einer Phase steht ein Meilenstein. Das ist ein überprüfbares Zwischenergebnis, zum Beispiel ein freigegebener Anforderungskatalog oder ein fertiger Softwareentwurf. Meilensteine machen den Fortschritt nachvollziehbar.
Die feste Reihenfolge ist zugleich Stärke und Schwäche: Sie erleichtert die Planung, macht Änderungen nach einem Phasenabschluss aber aufwendig.
Welche fünf Phasen gehören zum Modell?
Es gibt Fassungen mit unterschiedlicher Phasenzahl. Für den grundlegenden Lernweg eignet sich die verbreitete Folge aus fünf Phasen:
- Analyse: Das Team klärt Ziele, Anforderungen, Rahmenbedingungen und erwartete Eigenschaften des Produkts.
- Design: Es entwirft eine passende Lösung, zum Beispiel die Softwarearchitektur, Komponenten und Schnittstellen.
- Implementierung: Es setzt den Entwurf um, programmiert Komponenten und fügt sie zusammen.
- Test: Es prüft das Gesamtprodukt gegen die festgelegten Anforderungen und behebt erkannte Fehler.
- Betrieb: Es führt das Produkt ein, liefert es aus und wartet oder verbessert es.
Manche Darstellungen trennen die Bereitstellung von der Wartung und zählen deshalb sechs Phasen. Andere unterscheiden Anforderungen noch feiner. Entscheidend ist nicht die Zahl, sondern das sequenzielle Grundprinzip.
Tests einzelner Komponenten können schon während der Implementierung stattfinden. Die eigene Testphase bezeichnet vor allem die Prüfung des integrierten Gesamtprodukts. Dadurch bleibt das Risiko bestehen, grundlegende Probleme erst spät zu erkennen.
Wie läuft ein Softwareprojekt vollständig ab?
Ein fiktives Schulteam entwickelt ein digitales Ausleihsystem. Die Schule verlangt drei Funktionen: Medien suchen, Ausleihen erfassen und Rückgabetermine anzeigen.
1. Analyse: Das Team hält die drei Funktionen als Anforderungen fest. Zusätzlich legt es fest, dass eine Ausleihe nur für ein vorhandenes Medium erfasst werden darf.
2. Design: Das Team plant Komponenten für Suche, Ausleihe und Datenverwaltung. Es beschreibt, welche Daten zwischen diesen Komponenten ausgetauscht werden.
3. Implementierung: Die Komponenten werden programmiert, einzeln geprüft und anschließend verbunden.
4. Test: Das Team prüft das Gesamtsystem gegen die Anforderungen. Es kontrolliert beispielsweise, ob ein nicht vorhandenes Medium tatsächlich nicht ausgeliehen werden kann.
5. Betrieb: Das geprüfte System wird bereitgestellt. Später entdeckte Fehler werden behoben und notwendige Aktualisierungen eingespielt.
Der entscheidende Denkweg lautet: Jede Prüfung bezieht sich auf Anforderungen, die bereits in der Analyse festgelegt wurden.
Fehlt eine Anforderung am Anfang, kann das Team sie beim abschließenden Test nicht einfach als vereinbart voraussetzen. Eine nachträgliche Ergänzung kann Änderungen am Design und am Programmcode erfordern.
Wann passt das Wasserfallmodell?
Das Modell passt besonders gut, wenn Anforderungen und Ziel früh klar, stabil und vollständig beschreibbar sind. Auch zwingende Abhängigkeiten sprechen für eine feste Reihenfolge: Ein späterer Arbeitsschritt kann dann sachlich erst nach dem vorherigen beginnen.
Günstige Bedingungen sind:
- ein klar definiertes Endergebnis;
- wenige erwartete Anforderungsänderungen;
- gut trennbare, aufeinander aufbauende Arbeitsschritte;
- Bedarf an ausführlicher Dokumentation und eindeutigen Abnahmen;
- ein im Voraus gut abschätzbarer Aufwand.
Weniger geeignet ist das Modell bei häufig wechselnden Anforderungen, unklarem Endziel oder vielen parallel laufenden Aufgaben. Dann können frühe Entscheidungen schnell veralten.
| Vorteil | Zugehörige Grenze |
|---|---|
| Klare Phasen und Zuständigkeiten | Rücksprünge sind schwierig |
| Meilensteine zeigen den Fortschritt | Eine Verzögerung kann Folgephasen aufhalten |
| Kosten und Aufwand sind früh abschätzbar | Die Vorausplanung ist aufwendig |
| Umfangreiche Dokumentation schafft Nachvollziehbarkeit | Dokumente schützen nicht vor falschen Annahmen |
| Anforderungen werden früh festgelegt | Spätes Feedback erschwert Änderungen |
Frage nicht nur: „Ist das Projekt groß oder klein?“ Entscheidend ist vor allem: Wie stabil sind Ziel, Anforderungen und Abhängigkeiten?
Wie unterscheiden sich Wasserfall, agile und erweiterte Ansätze?
Agile Vorgehensweisen entwickeln ein Produkt in kurzen, wiederholten Arbeitsabschnitten. Ergebnisse und Rückmeldungen fließen fortlaufend in die weitere Planung ein. Das erleichtert Anpassungen, bietet aber nicht dieselbe langfristig festgelegte Phasenfolge.
| Kriterium | Wasserfallmodell | Agile Vorgehensweise |
|---|---|---|
| Ablauf | Phasen nacheinander | Wiederholte kurze Entwicklungsabschnitte |
| Anforderungen | Möglichst vollständig zu Beginn | Können weiterentwickelt werden |
| Rückmeldung | Häufig spät am Gesamtprodukt | Regelmäßig an Zwischenergebnissen |
| Änderungen | Nach Phasenabschluss aufwendig | Als Teil des Vorgehens vorgesehen |
| Planung | Stark im Voraus | Wird schrittweise angepasst |
Ein erweitertes Wasserfallmodell erlaubt begrenzte Rücksprünge, damit ein Ergebnis anhand früherer Anforderungen überprüft und korrigiert werden kann. Ein hybrides Vorgehen kann außerdem Analyse und Planung sequenziell organisieren, die Implementierung aber in kurzen Iterationen durchführen.
Der Aufsatz von Winston W. Royce aus dem Jahr 1970 wird häufig mit dem Wasserfallmodell verbunden. Royce verwendete den Begriff „Wasserfall“ jedoch nicht. Er beschrieb ein streng lineares Vorgehen als riskant und schlug unter anderem frühe Verifizierung, einen Prototypdurchlauf und eine frühere Beteiligung der Endnutzer vor.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- Wasserfallmodell
- Grundprinzip
- Phasen laufen nacheinander
- Rücksprünge sind klassisch nicht vorgesehen
- Phasen
- Analyse und Design
- Implementierung, Test und Betrieb
- Stärken
- Planbarkeit und klare Meilensteine
- Dokumentation und Nachvollziehbarkeit
- Risiken
- Aufwendige Änderungen
- Späte Entdeckung grundlegender Fehler
- Einsatzentscheidung
- Stabilität der Anforderungen prüfen
- Abhängigkeiten und Feedbackbedarf prüfen
- Erweiterungen
- Verifizierung und Rücksprünge
- Iterative oder hybride Umsetzung
- Grundprinzip
Abschluss-Check
Prüfe deine Entscheidung künftig mit drei Fragen: Steht das Ziel fest? Bleiben die Anforderungen stabil? Müssen die Arbeitsschritte nacheinander erfolgen? Je häufiger du mit Ja antwortest, desto eher kann das Wasserfallmodell passen.