Wenn von klassischem Projektmanagement die Rede ist, ist meistens das Wasserfallmodell gemeint. Die Wasserfallmethode bildet Projektphasen in Form einer Kaskade oder eines Wasserfalls ab.
Jede Phase wird sequenziell, d. h. Schritt für Schritt abgearbeitet.
Erst wenn eine Phase abgeschlossen ist, folgt die nächste.
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.
Alle Parameter einer Phase werden im Voraus definiert: Was sind die zu erfüllenden Aufgaben? Welche Dokumente müssen erstellt werden? In wechselhaften Branchen, in denen sich die Rahmenbedingungen eines Projektes leicht ändern können oder Projekte zu komplex sind, ist die Wasserfallmethode nicht zu empfehlen. Dafür punktet das Wasserfallmodell mit seiner klaren und leicht zu formalisierenden Struktur. Ein Klassiker, wenn es um Projektmanagement geht.
Jedes Softwareprojekt beginnt mit einer Analysephase, die eine Machbarkeitsstudie und eine Anforderungsdefinition umfasst. In der Machbarkeitsstudie wird das Software-Projekt bezüglich Kosten, Ertrag und Realisierbarkeit eingeschätzt. Aus der Machbarkeitsstudie gehen ein Lastenheft (eine grobe Beschreibung der Anforderungen), ein Projektplan und die Projektkalkulation hervor sowie ggf. ein Angebot für den Auftraggeber.
Anschließend folgt eine detaillierte Anforderungsdefinition, die eine Ist-Analyse und ein Soll-Konzept beinhaltet. Während Ist-Analysen den Problembereich skizzieren, wird im Soll-Konzept definiert, welche Funktionen und Eigenschaften das Software-Produkt bieten muss, um den Anforderungen gerecht zu werden. Zu den Ergebnissen der Anforderungsdefinition gehören beispielsweise ein Pflichtenheft, eine detaillierte Beschreibung, wie die Anforderungen an das Projekt zu erfüllen sind, sowie ein Plan für Akzeptanztest.
Abschließend sieht die erste Phase des Wasserfallmodells eine Analyse der Anforderungsdefinition vor, in der komplexe Probleme in kleine Teilaufgaben zerlegt und entsprechende Lösungsstrategien erarbeitet werden.
Das Lastenheft (auch Anforderungsliste, Anforderungsspezifikation, Anforderungskatalog, Produktskizze, Kundenspezifikation oder Anwenderspezifikation) beschreibt die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers.
Die Anforderungen in einem Lastenheft sollten so allgemein wie möglich und so einschränkend wie nötig formuliert werden. Hierdurch hat der Auftragnehmer die Möglichkeit, eine passende Lösung (z. B. eine Software) zu erarbeiten, ohne in seiner Lösungskompetenz durch zu konkrete Anforderungen eingeschränkt zu sein.
Projektplan (oder Projektmanagementplan) ist ein Begriff aus dem Projektmanagement und hält das Resultat sämtlicher Planungsaktivitäten in einem konsistenten Dokument oder mehreren kohärenten Dokumenten fest.
Die Design-Phase dient der Ausarbeitung eines konkreten Lösungskonzepts auf Basis der zuvor ermittelten Anforderungen, Aufgaben und Strategien. Software-Entwickler erarbeiten in dieser Phase die Software-Architektur sowie einen detaillierten Bauplan der Software und konzentrieren sich dabei auf konkrete Komponenten wie Schnittstellen, Frameworks oder Bibliotheken. Das Ergebnis der Design-Phase umfasst ein Entwurfsdokument mit Software-Bauplan sowie Testplänen für einzelne Komponenten.
Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. Der Auftraggeber beschreibt vorher im Lastenheft möglichst präzise die Gesamtheit der Forderungen – was er entwickelt oder produziert haben möchte. Erst wenn der Auftraggeber das Pflichtenheft akzeptiert, sollte die eigentliche Umsetzungsarbeit beim Auftragnehmer beginnen.
Pflichtenheft Vorlage
Pflichtenheft RoomBA
Pflichtenheft Airhockey
Pflichtenheft AlicePro
Pflichtenheft Brettspiele
Pflichtenheft Syntax Tool
Pflichtenheft Cluedo
Das Projekthandbuch beinhaltet alle einzuhaltenden Regeln und relevanten Informationen, die für die erfolgreiche Durchführung des Projekts relevant sind. Es ist somit Regelwerk und Übersicht zugleich. Aber was gehört eigentlich in so ein Projekthandbuch? Warum ist es so wichtig? Und von wem wird es überhaupt erstellt? Fragen, die wir für Sie in diesem Artikel beantworten.
Laut DIN 69901-5:2009 ist das Projekthandbuch ein projektspezifisches Informationswerk zur Durchführung des Projekts. Jedes Projekt bekommt sein eigenes.
Dann fehlen Transparenz, Kontinuität und Reporting – so können Sie kein Projekt managen.
Egal für welche Richtlinie Sie sich entscheiden, der verwendete Standard gibt Ihnen die Mindestinhalte vor, die Sie nicht in Frage stellen sollten.
Je nach Projektart und dem Umfang des Vorhabens können Sie selbst entscheiden, welche der erforderlichen Aspekte Sie wie ausführlich handhaben.
Es wird kein Roman verlangt! Das Projekthandbuch soll so knapp wie möglich und nur so ausführlich wie nötig formuliert sein.
Realisiert wird die in der Design-Phase konzipierte Software-Architektur in der Implementierungsphase, die Software-Programmierung, Fehlersuche und Modultests umfasst. In der Implementierungsphase wird der Software-Entwurf in der gewünschten Programmiersprache umgesetzt. Einzelne Komponenten werden separat entwickelt, im Rahmen von Modultest überprüft und Schritt für Schritt in das Gesamtprodukt integriert. Das Ergebnis der Implementierungsphase ist ein Software-Produkt, das in der nachfolgenden Phase zum ersten Mal als Gesamtprodukt getestet wird (Alpha-Test).
Die Testphase beinhaltet die Integration der Software in die gewünschte Zielumgebung. In der Regel werden Software-Produkte zunächst als Beta-Version an ausgewählte Endbenutzer ausgeliefert (Beta-Tests). Ob die Software die zuvor definierten Anforderungen erfüllt, lässt sich mithilfe der in der Analysephase entwickelten Akzeptanztests ermitteln. Ein Software-Produkt, das Beta-Tests erfolgreich absolviert hat, ist bereit für den Release.
Nach erfolgreichem Abschluss der Testphase wird die Software für den Betrieb im Produktiveinsatz freigegeben. Die letzte Phase des Wasserfallmodells schließt Auslieferung, Wartung und Verbesserung der Software ein.
| Vorteile | Nachteile |
|---|---|
| Einfache Struktur durch klar abgegrenzte Projektphasen | Komplexe oder mehrschichtige Projekte lassen sich nur selten in klar abgegrenzte Projektphasen unterteilen |
| Gute Dokumentation des Entwicklungsprozesses durch klar definierte Meilensteine | Geringer Spielraum für Anpassungen des Projektablaufs aufgrund veränderter Anforderungen |
| Kosten und Arbeitsaufwand lassen sich bereits bei Projektbeginn abschätzen | Der Endanwender wird erst nach der Programmierung in den Produktionsprozess eingebunden |
| Projekte die nach dem Wasserfallmodell strukturiert werden, lassen sich auf der Zeitachse gut abbilden. | Fehler werden mitunter erst am Ende des Entwicklungsprozesses erkannt. |
Wasserfallmodelle nutzt man vor allem bei Projekten, bei denen sich Anforderung und Abläufe bereits in der Planungsphase präzise beschreiben lassen und bei denen davon auszugehen ist, dass sich die Vorannahmen während des Projektablaufs höchstens geringfügig ändern. Streng lineare Vorgehensmodelle eigenen sich somit in erster Line für kleine, einfache und klar strukturierte Software-Projekte.