Developmentsmethods
back to overview
Die ewige Diskussion
Die Frage "Phasenmodell oder evolutionär?" wird seit über einem Jahrzehnt in Fachkreisen leidenschaftlich diskutiert, neuerdings belebt durch die Gestaltung von Internetanwendungen und durch die Diskussion über Extreme Programming (XP). Dabei wird das Phasenvorgehen als Wasserfall- und das evolutionäre als Spiralmodell bezeichnet, abgeleitet von entsprechenden grafischen Darstellungen, die nur jeweils eine von mehreren Veranschaulichungen sind.
Betrachten wir zunächst das phasenweise Vorgehen. Die Abfolge Fachliche Spezifikation – Technisches Design – Modulimplementierung – Test ist natürlich keine strenge Sequenz, sondern wird vielfach aufgelöst durch Überlappung von Phasen, Überarbeitung von Ergebnissen früherer Phasen aufgrund von Erkenntnissen in späteren Phasen (Fehler, Verbesserungen, neue Anforderungen), Bildung von Stufen, d.h. von aufeinander aufbauenden Teilsystemen, die eigenständig betrieben werden können.
Die Verfechter des Spiralmodells behaupten gerne, das Wasserfallmodell sei altmodisch, weil Großrechner-orientiert und eine Bastion der zentralen DV-Abteilungen, die die Anwender nicht beteiligen wollen. Vor allem aber kritisieren sie, es laufe ohne Rückkopplungen von späteren in frühere Phasen ab, also ohne die Erkenntnisse zu nutzen, die man zwangsläufig im Projektverlauf gewinnt.
Unter evolutionärem Vorgehen verstehen wir die Entwicklung einer Folge von Prototypen, deren letzter im Regelfall das laufende System ist. Die Kernidee dabei ist, den Anwender früh und intensiv mit laufender Software zu konfrontieren (statt mit papierenen Spezifikationen), um damit Erfahrungen und Anforderungen für den jeweils nächsten Schritt zu gewinnen. Erfahrungen und Erkenntnisse während des Projekts fließen damit sofort in die Entwicklung ein.
Die Verfechter des Wasserfallmodells behaupten gerne, eine Entwicklung auf Basis des Spiralmodells sei unplanbar, könne daher nicht auf Festpreisbasis abgewickelt werden und hätte einen wesentlich höheren Integrationsaufwand, da sich die Software während des Projektes ständig ändert und neue Prototypen installiert werden müssen. Weiterhin würde wenig Wert gelegt auf Spezifikations- und Designdokumente, da die Programmierung ausgehend von Entwürfen der Benutzeroberfläche dominiere.
Und was lernen wir daraus?
Bei genauerem Hinsehen auf die praktische Vorgehensweise vieler Entwicklungsunternehmen stellten wir fest, dass jede der Methoden kaum so eingesetzt wird, wie sie in der Literatur beschrieben wird. Beim Wasserfallmodell werden über die Phasen einzelne Versionen von Systemen oder Teilsystemen entwickelt (eben wie Prototypen), damit Rückkopplungen möglich werden. Das Spiralmodell wird häufig von einer Dokumentation begleitet.
Wir entwickeln individuelle Software auf die Anforderungen unserer Kunden hin. Es liegt in der Natur praktisch veranlagter Menschen, lieber etwas anzufassen und damit zu arbeiten anstatt sich theoretisch alle möglichen Fälle auszudenken - das klappt auch bei hervorragend geplanten Projekten nicht, sobald etwas mehr Komplexität ins Spiel kommt.
Deshalb "mischen" auch wir die Methoden, wobei jedoch das evolutionäre Vorgehen eindeutig überwiegt.
Die wesentlichen Schritte sind:
- Erstellung einer funktionalen Spezifikation (Lastenheft oder Grobspezifikation) am Beginn eines Projektes.
- Angebot und Vereinbarung eines Festpreises (bei allen bisherigen Projekten wurde der Preis gehalten).
- Entwicklung von Prototypen entsprechend der vereinbarten Prozess-Schritte und der kritischen Systemteile.
- Erstellung der Design-Spezifikation parallel zur Entwicklung.
- Test der Komponenten parallel zur Entwicklung.
- Validierung der Systeme inkl. Gegenüberstellung Anforderung - Design - Testergebnis.
- Integration und produktiver Einsatz von Teilsystemen und -funktionen.
Wir kommen bei dieser Methode zu hervorragenden Ergebnissen, da wir auf viele "fertige" und getestete Bausteine zurückgreifen können, die sich in vielen Projekten bewährt haben. Alle kritischen Elemente werden im Regelfall an den Anfang der Entwicklung gestellt und erreichen durch die gewählte Methode zwangsläufig am Ende des Projektes eine hohe Reife.
Wir halten die vereinbarten Festpreise, da auch bei dieser Vorgehensweise Vereinbarungen über den Funktionsumfang getroffen werden und ein Projektmanagement durchgeführt wird.
Wir wickeln damit auch große Projekte ab, weil sich die einzelnen Funktionsblöcke in überschaubare Phasen aufteilen lassen, welche dann für sich gesehen als Teilprojekte realisiert werden können.
Wie erreichen damit eine sehr hohe Identifikation der Anwender, da sich diese in die Entwicklung einbringen können und falsche Annahmen sofort erkannt und korrigiert werden können.