Beschreibung des Wasserfallmodells
Das klassische Wasserfallmodell wird in Abbildungen immer Kaskadenförmig dargestellt. Dies liegt an seinen untereinander versetzen Phasen eines Projektes. Jeder Balken ist abhängig von dem jeweils Nachfolgenden. Dies bedeutet, dass erst eine Phase abgeschlossen sein muss bevor die nächste beginnen kann. Dieser Übergang von einer Phase zu der anderen wird als Meilenstein bezeichnet.
Das Modell besteht auf 5 oder auch in einigen anderen Darstellungen aus 6 Phasen. Wir konzentrieren uns hier auf das fünfstufige Modell:
1. Analyse- und Konzeptionsphase
2. Designphase (technisch und visuell)
3. Entwicklungsphase
4. Testingphase
5. Implementierungsphase
Fünfstufiges Wasserfallmodell
Die Analyse- und Konzeptionsphase
Die Analysephase ist den Erfahrungen nach einer der wichtigsten Phasen eines jeden IT-Projektes. In dieser Phase werden gemeinsam mit dem Kunden die Anforderungen definiert und es wird ein gemeinsamer Projektkonsens geschaffen. Jegliche Themen die in dieser Phase nicht beachtet und festgehalten werden, können bereits zu Beginn des Projektes erhebliche Risiken mit sich bringen, die sich insbesondere im späteren Projektverlauf widerspiegeln. Jeder Projektmanager sollte sich Zeit für diese Phase nehmen und versuchen alle Anforderungs- und Konzeptionslücken möglichst vollständig zu schließen. In dieser Phase gilt es auch grobe Rahmenparameter für die spätere technische Realisierung festzuhalten. Oftmals empfiehlt es sich, um bereits zu Beginn des Projektes einen Überlauf vorzubeugen, erst nach einem Anforderungsworkshop und der Konzeptionsphase ein finales Angebot für die Umsetzung abzugeben. Vorher ist in den meisten Fällen vielen Kunden eine Tunnelschätzung ausreichend. Zu diesem Zeitpunkt sind alle Beteiligten über den genauen Scope eines Projektes unterrichtet.
Die Designphase
Nachdem alle Anforderungen mit dem Kunden definiert sind, beidseitig nach etwaigen Lücken oder Widersprüchen die Dokumente durchforstet worden sind und vom Kunden schriftlich abgenommen wurden, kann die Designphase beginnen. Die technische Designphase ist oftmals für einen nicht technisch avisierten Projektmanager die herausforderndste Phase. Beginnend mit Server- und Datenbankspezifikationen, über Schnittstellendienste und Plattform Entscheidungen ist es dringend zu empfehlen, sich hier jederzeit an erfahrene Techniker zu wenden bzw. dieser Person federführend diese Phase übergeben. Diese sollten möglichst eine beratende Rolle auch im direkte Kundenkontakt einnehmen. Es ist zu empfehlen, dass der Projektmanager den Kommunikationsprozess eng begleitet, um somit möglichst bei allen Entscheidungen und Festlegungen beteiligt zu sein. In der gleichen Konstellation sollten auch jetzt bereits der Rollout- und ggf. Migrationsplan erarbeitet werden. Dies kann aber auch noch nachgelagert während der Entwicklungsphase erfolgen.
Die visuelle Designphase agiert mit fast allen Units. Mit den Informationsarchitekten gilt es eng abzustimmen, welche Bereiche sich wie in dem Interface wiederfinden sollen. Die Freiheiten eines Designers sind groß aber stark durch die konzeptionellen Vorgaben beschränkt. Designs bereiten oftmals aus Kundensicht auch eine herrliche Spielwiese zahlreiche Iterationen durchzuführen. Nach der 1. Iteration sollten die klare Richtlinie stehen. Jetzt gilt es mit dem Kunden zu sprechen und ihn abzuholen. Der Designer und der Projektmanager müssen nun möglichst umfassend die Änderungswünsche greifen können, um diese gezielt umzusetzen bzw. den Kunden zu beraten.
Die Entwicklungsphase
Der Projektmanager muss in dieser Phase nah an seinem Team sein und den Rücken freihalten. Dies gilt sowohl für interne als auch für externe Störfaktoren. Ein häufiger personeller Wechsel, wechselnde Projekte, „Ich hab mal ne Frage“-Störungen, „kleinere Änderungen“ führen zu einer Verlängerung des Projektes und werden oftmals unterschätzt. Das Projektteam sollte stabil gehalten werden. Jeder Projektmanager sollte für das geplante Team kämpfen. Sollte der Kunde neue Ideen haben, werden diese aufgenommen und in einer 2. Phase nach dem initialen Launch bereitgestellt. Dies ist sicherlich in den seltensten Fällen der Fall, aber jeder Projektmanager sollte dies in seinem Hinterkopf halten.
In dieser Phase findet meist auch nochmal ein reger Austausch zwischen den Informationsarchitekten und den Technikern statt. Je besser und genauer alles definiert wurde, desto geringer fällt dieser Zeitaufwand aus.
Die Testinghase
Die 80:20 (Pareto-)Regel erfreut sich in dieser Phase höchster Aufmerksamkeit. 80% der durchgeführten Arbeiten benötigen 20% Aufwand, die letzten 20% der noch offenen Arbeiten erfordern 80% an Aufwand. Und parallel steigt die Erwartungshaltung das Projekt bald finalisiert zu haben. Nur allzu oft werden unvollständig getestete Projekte live gestellt. Der frühere Livegang konnte womöglich realisiert werden aber die Unzufriedenheit wegen der fehlerhaften Anwendung überwiegt. Bereits parallel zu der Entwicklungsphase sollten Testfälle anhand der in der Analysephase definierten Anforderungen definiert werden. In der IT ist die CRUD-Methode sehr bekannt für. Die Testfälle sollten so geschrieben sein, dass ein fremder Dritter diese durchführen könnte. Schritt für Schritt sollte beschrieben sein, wie der Anwender zu einem Testfall navigiert und was das erwartete Verhalten ist. Sollte es sich um ein Webprojekt handeln, ist es elementar die Testings in den angebotenen Browsern durchzuführen. Besonderer Augenmerk sollte besondere auf geschäftskritische Prozesse der Anwendung gelegt werden. Insbesondere natürlich auch jegliche Schnittstellentests. Die Tests sollten von mehreren Personen durchgeführt werden. Besonders techniklastige Testings (Backendtests, Schnittstellentests) sollten durch einen Techniker durchgeführt werden. Generell ist das 4-Augen-Prinzip zu berücksichtigen. Ein Techniker sollte nie als einziger seinen selbst umgesetzten Bereich testen. Empfehlenswert ist darüber hinaus Tester sog. Black-Box-Tests durchführen zu lassen – einfach klicken und testen lassen. Diese Testings, wenn nicht ohnehin angedacht, können auch einen sehr guten Einblick in die Usability der Anwendung geben, da hier der Tester im Projektverlauf nicht involviert ist.
Und auch das Thema Unit-Tests ist nicht nur ein reines Theoriethema und wird leider viel zu oft aus Budget- und/ oder Zeitgründen außer Acht gelassen. Testgetriebene Entwicklung ermöglichen die Unit-Tests, die automatisiert nach den programmierten Testfällen die Anwendung/ das Portal fortwährend testen.
Die Implementierungsphase
Wenn das Projekt bis hierin mit allen Phasen sauber durchgelaufen ist, minimieren sich die ausstehenden Risiken erheblich. Die Tests waren erfolgreich, der Kunde hat das Projekt als fehlerfrei auf der Testumgebung abgenommen nun kommt der Tag des Rollouts. Den in der Designphase festgelegte Rolloutplan (und ggf. Migrationsplan) definiert alle erforderlichen Schritte für einen erfolgreichen Livegang. Es ist wichtig hier zeitlichen Puffer einzuplanen. Ein Rollout kann schnell und reibungslos verlaufen aber es ergeben sich hier doch immer wieder Überraschungen, für die die nötige Zeit eingeplant werden sollte. Wegen evtl. Downtimes sollte ein kritischer Rollout nicht zu Peakzeiten durchgeführt werden. Alle Projektbeteiligten und auch die Seite des Kunden sollte für die Zeit des Rollouts jederzeit greifbar sein.
Nach dem Livegang werden trotz intensiven Testings, trotz gehaltenem Zeitplan und Einhaltung des Projektscopes weitere Arbeiten folgen. Dem gesamten Projektteam (intern und extern) sollte an dieser Stelle klar gemacht werden, dass dieser wichtige Meilenstein geschafft wurde. Dies sollte ein Anlass für ein Glas Sekt sein.
Der hier genannte Ablauf ist nur ein sehr grober Umriss eines relativ komplexen Prozesses. Es Bedarf Zeit, zahlreichen Erfahrungen, auch den schlechten, bis Projekte reibungslos über die Bühne laufen. Und selbst dann ist niemand vor Überraschungen gefeit.