Wasserfallmodell der Softwareentwicklung

Das Wasserfallmodell ist ein klassischer, weitverbreiteter linearer Ansatz für den Lebenszyklus der Softwareentwicklung. Es legt eine Reihenfolge von Phasen mit jeweils klaren Zielen fest. Wie Wasser, das einen Hang hinabfließt, bewegt sich das strikte Modell nur vorwärts.

Das Wasserfallmodell ist strikt und lässt wenig Raum für Änderungen. Tests bilden eine eigene Phase, anstatt die Entwicklung laufend zu begleiten. Dadurch können Fehler in diesem Modell nicht frühzeitig während der Entwicklung erkannt werden.

Diagramm in voller Größe öffnen ↗

Wasserfallmodell der Softwareentwicklung

Die Phasen folgen in dieser Reihenfolge:

1. Anforderungen erheben. Erfassen Sie die Anforderungen des Kunden und erstellen Sie die erforderliche Dokumentation.
2. System entwerfen. Leiten Sie aus den Anforderungen die Architektur sowie den Hardwarebedarf und Softwarebedarf des Systems ab.
3. Implementieren. Beginnen Sie mit der Programmierung auf Grundlage des Entwurfs. Teilen Sie das Programm in kleine, unabhängige Einheiten auf, testen Sie jede anhand ihrer Spezifikation und integrieren Sie die Einheiten zum vollständigen System.
4. Integration testen. Fügen Sie die getesteten Einheiten zusammen und testen Sie das gesamte System auf Fehler.
5. Bereitstellen. Beheben Sie die bei den Integrationstests gefundenen Fehler und bestätigen Sie die Korrekturen durch erneute Tests. Danach ist das System für die Markteinführung und den Einsatz beim Kunden bereit.
6. Warten. Veröffentlichen Sie Patches oder neue Versionen, um Fehler und Probleme zu beheben, die nach der Auslieferung entdeckt werden.

Die Phasen bauen aufeinander auf. Eine Phase beginnt erst, wenn die vorherige erfolgreich abgeschlossen ist.

Nutzen Sie das Wasserfallmodell, wenn die Anforderungen klar sind, das Produkt stabil ist und für jede Phase genügend Ressourcen zur Verfügung stehen. In der Praxis eignet es sich nur für kleine, überschaubare Projekte. Vermeiden Sie es bei Anforderungen mit mittlerem oder hohem Risiko.

Anforderungsspezifikation und Anforderungsanalyse

Erfolgreiche Softwareentwicklung hängt davon ab, wie gut Anforderungen erfasst und dokumentiert sind. Das Ermitteln und Dokumentieren der Anforderungen heißt Anforderungsspezifikation und Anforderungsanalyse.

Der Kunde, das Managementteam und der technische Support besprechen die Anforderungen im Detail. Sie analysieren, prüfen und dokumentieren sie, bis sie klar und vollständig sind.

Diagramm in voller Größe öffnen ↗

Spezifikation der Benutzeranforderungen

Nutzen Sie das vom Unternehmen vorgeschriebene Format, etwa Word-Dokumente, Flussdiagramme oder Zeichnungen. Das Ergebnis hält die Wünsche des Kunden im Detail fest und hilft dem Team, sie richtig zu verstehen. Ein Fehler ist jede Abweichung von den Kundenanforderungen. Falsch erfasste Anforderungen bringen ein Projekt schon zu Beginn auf den falschen Kurs.

Spezifikation der Benutzeranforderungen

Dieses nichttechnische Dokument beschreibt die Erwartungen der Nutzer und die geschäftlichen Anforderungen. Die Endnutzer verfassen es. Die darin beschriebenen Anforderungen werden bei der Benutzerabnahme geprüft. Das Dokument bildet die Grundlage für die weitere Anforderungsarbeit und den Systementwurf.

Softwareanforderungsspezifikation

Die Softwareanforderungsspezifikation (SRS) legt fest, wie die Software nach den Wünschen der Nutzer funktionieren soll. Sie dient folgenden Zwecken:

• Die Vereinbarung zwischen Kunde und Anbieter über die genaue Funktionalität der Software festhalten.
• Die Grundlage für den Softwareentwurf schaffen.
• Entwicklung und Tests durch klare Anforderungen erleichtern.
• Die Ablaufplanung und Kostenschätzung unterstützen.
• Eine Grundlage für Verifikation und Validierung schaffen.

Diagramm in voller Größe öffnen ↗

Softwareanforderungsspezifikation

Softwareentwurf

Der Softwareentwurf hat zwei Ebenen:

• Grobentwurf der Software
• Detailentwurf der Software

Diagramm in voller Größe öffnen ↗

Softwareentwurf

Grobentwurf der Software

Der Grobentwurf (HLD) beschreibt den Datenbankentwurf und die funktionale Architektur. Er dient Entwicklern als Orientierung und beantwortet Fragen zum Aufbau des Entwurfs. Bevor der Grobentwurf erstellt werden kann, muss die SRS klar formuliert sein.

Detailentwurf der Software

Der Detailentwurf (LLD) zerlegt den Grobentwurf in kleinere Teile und dokumentiert die Logik, die die Programmspezifikation bildet. Er hält die Details des Systems fest und setzt einen fertigen Grobentwurf voraus.

Vorgehensweisen beim Softwareentwurf

Beim Entwerfen stehen zwei Ansätze zur Wahl:

• Top-down-Entwurf
• Bottom-up-Entwurf

Vorgehen beim Top-down-Entwurf

Der Top-down-Entwurf beginnt mit einer Übersicht über das gesamte System. Die Details der Teilsysteme folgen später. Arbeiten Sie sich durch jedes Teilsystem nach unten und definieren Sie es immer genauer, bis Sie die Grundelemente erreicht haben.

Vorgehen beim Bottom-up-Entwurf

Der Bottom-up-Entwurf beginnt mit vollständig definierten Grundelementen. Verbinden Sie sie zu Teilsystemen und setzen Sie diese zusammen, bis das ganze System entstanden ist. Stellen Sie sich vor, wie aus einem gepflanzten Samen nach und nach ein Baum wächst.