Von Wasserfällen und scharfer Munition
vom 8. March 2008
(Bild von @t.)
Im Laufe meines Studiums habe ich einige Vorgehensmodelle zur Softwareentwicklung kennengelernt. Besonders ausführlich wurde das Wasserfallmodell behandelt. Wer es (noch) nicht kennt: Der Softwareentwicklungsprozess ist in 5 Phasen eingeteilt, welche linear durchlaufen werden. Zuerst wird die Software geplant, sprich ein Lasten und Pflichtenheft erstellt welches beschreibt was die Software können muss. Daraus wird der Entwurf der Software (meist mit UML) erstellt. Dieser Entwurf wird in Software umgesetzt und anschließend getestet. Am Ende wird die Software ausgeliefert, Installiert und gewartet. Die einzelnen Phasen sind wie bei einem Wasserfall angeordnet und strikt getrennt. Wenn bei der Implementierung Designfehler entdeckt werden wird wieder bis zur Entwurfsphase gesprungen, der Fehler behoben und dann wieder die Kette nach unten geklettert.
Irgend wie konnte ich mich mit diesem Modell nie richtig anfreunden und habe auch nie wirklich geglaubt das ein solches Konzept erfolgreich angewandt werden kann. In dem Buch Ship it! von Richardson und Gwaltney bin ich hier auf meine lang ersehnte Bestätigung gestoßen:
Ein Vorgehensmodell, das Sie vermeiden sollten, ist das berüchtigte Wasserfallmodell. Es wurde in fortschrittlicheren Entwicklerkreisen allgemein verworfen, trotzdem ist es erstaunlich, in wie vielen Unternehmen es immer noch angewendet wird. [...] Ahnungslose Manager, die in Zeitpläne vernarrt sind, sind schon seit vielen Jahren Anhänger dieses Vorgehensmodells.
Als pragmatische Alternative zu den eingerosteten Vorgehensweisen stellt das Buch das von Thomas und Hunt entwickelte Tracer Bullet Development (TBD) vor. Ziel ist es hier, die Anwendung so schnell wie nur möglich lauffähig/ausführbar zu machen. Anfangs wird die Anwendung in Bereiche eingeteilt und Schnittstellen spezifiziert. Die einzelnen Klassen mit Methoden werden als stubs angelegt und geben bestenfalls statische dummy-Werte zurück. Wenn dieses Grundgerüst steht, werden die einzelnen Methoden ausprogrammiert und mit der Zeit verfollständigt.
Ein interessantes Konzept wird auch bei den Schnittstellen angewendet: Alle Schnittstellen kommunizieren über das Netzwerk, auch wenn beide Teile auf einem Prozessor laufen. Das hat den Vorteil, das eine Loose Kopplung erzwungen wird und die Software am Ende viel besser skaliert werden kann.
Doch eines hat dieses Konzept mit dem Wasserfallmodell gemeinsam. Es geht davon aus, das das Konzept der Software entgültig ist und das von Anfang an feststeht wie die Software am Ende auszusehen hat. Es ist zwar viel leichtgewichtiger als die "großen", aber nicht so Agil wie XP und Co. Martin Fowler unterscheidet hier zwischen geplantem und wachsendem Design.
Ich denke es kommt immer darauf an, was für Software man entwickelt. Wenn es eine Neuimplementierung einer alten Steuersoftware ist, spricht eigentlich nichts gegen TBD, doch wenn beim umzusetzenden Programm ganz neue Technologien verwendet werden, Features implementiert werden sollen die es zuvor noch nicht gegeben hat und anfangs noch garnicht klar ist, wie das Endergebnis aussehen soll (oder der Kunde nicht weiß was er will), sind agilere Vorgehensweisen angebrachter.
Kommentare
Wo ist hier bitte die scharfe Munition? Zur scharfen Munition gehört auch nen bischen was scharfen ... und vorallem etwas, das nicht allen bereits bekannt ist.
Das Waterfallmodell ist nicht genial. Niemand der sich mit der Thematik jemals beschäftigt hat, wird das bezweifeln. Warum wird es dann immernoch angewendet? Vermutlich weil es so einfach ist! Jeder versteht es - es funktioniert nicht - aber jeder versteht es. That's life ....
Und übrigens: Die Methode der Wahl hängt von deiner Aufgabe ab ... Agile Methoden ... klingt schön ... aber was ist das? Es gibt soviele Ausprägungen davon und keine, ich wiederhole, KEINE davon ist 1 zu 1 auf die Praxis zu übertragen. Jede Methode - egal ob Agil, Konservativ oder sonstwas - muss an das Team angepasst werden. Dazu braucht man einen Projektmanager, der sein Team kennt - in erster Linie. Und erst in zweiter Linie die Vorgehensmodelle. Den:
A fool with a tool is still a fool!
Tut mir leid das ich dir mit diesem Eintrag nichs neuer erzählen konnte. Die "scharfe Munition" bezog sich auf TBD.
Du wirst es vermutlich nicht glauben aber in meinem Studiengang (SE) gibt es einen Prof der total auf das Wasserfallmodell abfährt.
Das es von der Aufgabe abhängt welches Vorgehensmodell man wählen soll ist natürlich klar, das hab ich ja oben schon geschrieben. Unter einer Agilen Methode verstehe ich einen Oberbegriff für ein Vorgehen das auf Veränderungen vorbereitet ist und dies auch aktiv in den Prozess integriert. Das ist jetzt hier nicht auf XP oder einer anderen der hippen Modelle bezogen. Wenn der Kunde mit einem neuen Feature ankommt sollte man nicht sagen müssen "Sorry aber das können wir nicht umsetzen, unsere Software ist nicht dafür gebaut".
also es wundert mich nun wirklich, dass ihr euch derart intensiv im Studium mit dem Wasserfall-Modell auseinander setzt. Bei uns war dies nicht einmal 1/2 Vorlesung, dann ging es zu den weitaus besseren Alternativen über.
Als (einziges) Beispiel gab unser Prof übrigens an, dass in Regierungsprojekten oftmals auf das Wasserfallmodell gesetzt wird - sagt doch schon alles, oder?
Übrigens:
Interessante Beiträge, bist damit sofort im Reader gelandet ^^
LG aus Bremen
