R
wirtschaft + weiterbildung
05_2019
51
Modells. Die wesentlichen Phasen im
Wasserfall-Modell zum Beispiel bei der
Softwareentwicklung sind:
1.
Analyse
2.
Design
3.
Implementierung
4.
Test und
5.
Betrieb
In der Phase 1 „Analyse“ werden zu-
nächst die Anforderungen vollständig do-
kumentiert, um daraus ein Lasten- oder
Pflichtenheft zu entwickeln. Erst danach
wird ein Projektplan erstellt und werden
die wahrscheinlichen Aufwendungen er-
mittelt. Große Aufgaben werden im Zuge
der Projektplanung in kleine Teilaufgaben
gegliedert und alle Aufgaben bezüglich
des Zeit- und Ergebnisverlaufs miteinan-
der verbunden.
In der Design-Phase (Phase 2) wird das
Lösungskonzept erarbeitet. Bei Software
projekten sind dies die Architektur und
das Systemdesign. Die Implementierungs-
phase (Phase 3) umfasst die gesamte
Programmierung der Anforderungen auf
Basis des Lastenhefts und im Rahmen
des Projektplans. Das Ergebnis der Imple-
mentierungsphase ist ein Software-Pro-
dukt, das in der nachfolgenden Testphase
(Phase 4) zum ersten Mal als Gesamtpro-
dukt getestet wird (Alpha-Test). Dies ge-
schieht in der Regel durch die Entwickler
selbst. Als Beta-Version geht die Software
danach an ausgewählte Endnutzer, und
erst hier zeigt sich, ob das Produkt die
zuvor definierten Anforderungen und Er-
wartungen der Anwender erfüllt. Nach
dem erfolgreichen Abschluss der Test-
phase wird die Software für den Betrieb
freigegeben beziehungsweise ein Release
erstellt. Mit dem Release beginnt der
Einsatz der Software und die fünfte und
letzte Phase des Modells (Betrieb). Auf-
tretende Fehler werden behoben, Verbes-
serungen eingebaut.
Theoretisch soll das Wasserfall- bezie-
hungsweise V-Modell Projektrisiken so-
wohl kosten- als auch terminseitig ver-
meiden. Sinnvoll ist sein Einsatz daher
bei Projekten, bei denen sich auf Sicht
nichts ändert und bei denen es fast keine
Anpassungen gibt. Ideal sind Projekte,
die sich in Struktur und Aufgabenstellung
wiederholen und einen überschaubaren
Zeitraum dauern. Das sind oft regulierte
Projekte, bei denen es darauf ankommt,
Gesetze und Vorschriften einzuhalten
und bei denen eine umfassende Doku-
mentation nötig ist wie zum Beispiel in
der Pharmaindustrie oder Medizintech-
nik.
Die Erfahrung zeigt jedoch, dass zum Bei-
spiel nur wenige Softwareprojekte diesen
Parametern unterliegen. Deshalb birgt die
Wasserfall-Methode bei der Softwareent-
wicklung viele Risiken. Ähnlich verhält
es sich bei fast allen größeren Change-
und Transformationsprojekten in Unter-
nehmen – unter anderem, weil in ihnen
meist auch eine passende, unterstützende
Software-Lösung entwickelt und/oder im-
plementiert werden muss.
Agilität ist die Antwort auf die
gestiegene Komplexität
Dies ist ein Grund, warum viele Unter-
nehmen nach anderen Projektmanage-
mentansätzen suchen. Ein weiterer ist:
Die Komplexität der Anforderungen und
die bestehenden Wechselwirkungen im
System lassen es bei vielen Projekten
kaum zu, klare Projektphasen zu planen.
Hinzu kommt ein sich schnell wandeln-
des Umfeld, mit nicht planbaren neuen
Erkenntnissen und Einflüssen. Unge-
plante Verläufe, neue Informationen und
komplexe Strukturen führen beim klassi-
schen Projektmanagement oft dazu, dass
Projekte gestoppt und neu ausgerichtet
werden müssen. Drastische Termin- und
Kostenverschiebungen sind die Folge.
Das agile Projektmanagement – zum
Beispiel bei der Softwareentwicklung –
bedient sich meist des Scrum-Modells.
Dieses steht im Gegensatz zum Wasser-
fall- oder V-Modell. Der wesentliche Un-
terschied ist: Das (Entwicklungs-)Projekt
wird nicht von vorne bis hinten durchge-
plant. Vielmehr folgt das Vorgehen einer
Vision. Dadurch entfallen detaillierte Las-
ten- und Pflichtenhefte. Zudem ist das
Vorgehen inkrementell, also in kleinen,
aufeinander aufbauenden Schritten erfol-
gend, und iterativ, also sich in Reflexions-
und Wiederholungsschleifen vollziehend.
Ein Scrum-Projekt hat drei Kernelemente:
• das Product Backlog
• das Sprint Backlog
• das Produkt-Inkrement.
Im Mittelpunkt des Geschehens stehen
jedoch die Stakeholder (Kunden/Anwen-
der) und die User-Stories. Die User-Sto-
ries beschreiben die Anforderungen an
das Endprodukt oder die Problemlösung
aus der Perspektive eines Benutzers. Sie
werden meist vom Product-Owner – also
der Person, die letztlich für die Arbeit des
Entwicklungsteams und die Qualität des
Endprodukts verantwortlich ist – mit den
Stakeholdern verfasst. Die User-Stories
werden parallel zur Entwicklung in einem
fortlaufenden Prozess definiert.
Das Projekt selbst gliedert sich beim agi-
len Projektmanagement nicht in Phasen,
sondern in eine Abfolge circa drei- bis
vierwöchiger Sprints. In ihnen werden
die User-Stories den Entwicklungsteams
Klassisches Projektmanagement
Grafik 1.
Beim „Wasserfall-Modell“ wird ein Projekt in klar
abgrenzbare Phasen zerlegt. Diese Phasen werden nacheinander
abgearbeitet und ihre Erledigung wird sorgfältig dokumentiert.
Projektrisiken werden durch eine genaue Planung minimiert.
Quelle: Dr. Kraus & Partner
Analyse
Design
Entwicklung
Test
Betrieb
