Iteratives Vorgehen
Wasserfallmodell versus iteratives Modell
Eines der klassischsten Vorgehensmodelle ist das sog. "Wasserfallmodell". Dabei wird ein System vorgängig 100%-ig spezifiziert. Die dann "eingefrorenen" Spezifikationen werden in der Folge entworfen, realisiert und getestet und dann eingefroren. Das Modell trägt seinen Namen darum, weil das Wasser in einem Wasserfall nur von "oben" nach "unten" fällt. Im Wasserfallmodell "nature" gibt es keine Wiederholungen oder Rücksprünge von Phasen.
Aus vielen Projekten wurde die Erfahrung gemacht, dass die sture Einhaltung dieses Modells zu schlechten Ergebnissen führen kann und zudem mit viel Risiken behaftet sind, weil man sich viel zu lange in sog. "Papierphasen" bewegt und erst spät im Projektablauf merkt, dass "etwas" nicht stimmt, nicht geht oder das ganze ev. zu teuer kommt.
In der Folge wurden vollständig konträre bzw. 100&-ig iterative "Methoden" angeboten, bei welchen sehr früh codiert und "ausprobiert" wird (Bsp: „Extreme Programming“).
Iterationen in AdeNet/VM
Das hier vorliegende Vorgehensmodell ist ein Wasserfallmodell mit iterativen Aspekten. Die Phasen werden grundsätzlich sequenziell durchlaufen, notfalls können sie wiederholt werden. Phasen sind aus einer Management- bzw. Kontroll-Perspektive unerlässlich. Kein seriöser Manager wird einfach eine Geldsumme aufwerfen und dann bis zum Projektende abwarten, bis unter Umständen ein ev. brauchbares Produkt vorliegt.
Das vorliegende Modell ist Iterativ im Sinne von RUP. Innerhalb einer Projektphase können und sollen teilweise Iterationen zwischen einzelnen zentralen Tätigkeiten (also Analyse, Design, Implementierung) stattfinden. Beispiele:
1) In der Konzeptphase sollen die Systemanforderungen mit der Systemarchitektur derart abgeglichen werden. Konkret heisst das also zum Beispiel: Man beginnt, die wichtigsten Anforderungen zu "festzuhalten" bzw. zu modellieren. Anschliessend klärt man grob ab, wie diese Anforderungen umgesetzt werden können. Dazu muss eine erste grobe Systemarchitektur entwickelt werden. Dabei wird insbesondere der Einsatz bestehender Standardkomponenten (Bsp: Personenverwaltung) überprüft. Jetzt stellt man fest, dass aufgrund der gerade existierenden Anforderungen die Personenverwaltung erweitert werden müsste, was teuer wäre. Also bespricht man das Ganze mit dem Kunden. Eventuell kommt diese zum Schluss, dass ihm die Erweiterung erstens gar nicht wichtig ist. Die Systemarchitektur kann also die Anforderungen beeinflussen[1].
2) HERMES sieht in der Konzeptphase eine Aktivität "Kritische Teilsysteme untersuchen" vor. Im Rahmen dieser Aktivität können Prototypen realisiert werden. Diese Aktivität wird dann durchgeführt, wenn man eine kleine Menge besonders wichtigen und/oder risikoreichen Anforderungen besonders "beleuchten" möchte. Faktisch bedeutet das, dass man in der Analysephase bereits einen Vorgriff auf die Realisierung macht.
3) In der Realisierungsphase wird man trotz sorgfältigem Design Situationen antreffen, bei welchem anlässlich der Programmierung das Design überarbeitet werden muss. Ebenso wird man nach dem Test in der Praxis oft das Design und ev. sogar die Anforderungen revidieren müssen.
4) Unwichtige oder triviale Funktionen (z.B. Verwaltung von Hilfsdaten wie Codes u.ä.) können in der Phase Konzept lediglich definiert aber erst in der Realisierungsphase spezifiziert und realisiert werden.
Aufteilung des Projekts in Realisierungseinheiten
HERMES basiert primär auf der Systemzerlegung bzw. auf der Grundidee „Vom Groben ins Detail“. Die RUP-Phasen sind eher Risikoorientiert und richten sich nach dem Grundsatz „das Kritische bzw. Wichtige zuerst“. Entsprechend schlägt RUP ein stark iteratives Vorgehen vor und fordert z.B., dass bereits nach der ersten Phase Inception (entspricht in etwa der Voranalyse) ein erster lauffähiger „Rohling“ vorliegt. Die Phasen haben allerdings in RUP ebenfalls eine grosse Bedeutung und die Iterationen sollen zusammen mit dem Auftraggeber geplant und in sog. Iterationsplänen festgehalten werden.
In HERMES bzw. AdeNet/VM wird die eben skizzierte „RUP-Philosophie“ wie folgt berücksichtigt:
1) Realisierung von Prototypen oder noch besser „frühen“ Versionen spätestens ab Phase Konzept. Diese Massnahme ist durch die Ergebnisse „Prototyp“ und „Detailstudie“ bereits in HERMES vorgesehen (kritische Teilsysteme; vgl. Ziele der Phase Konzept).
2) Aufteilung des Projekts in einzelne Realisierungseinheiten. Die nachfolgende Abbildung zeigt 3 mögliche Projektabläufe.
Zu beachten ist, dass bei den beiden ersten Varianten das Projekt zu jedem Zeitpunkt immer genau einer Projektphase zugeordnet werden kann, was bei Variante 3 nicht mehr der Fall ist. Ob bei einer gestaffelten Projektabwicklung einzelne Realisierungseinheiten jeweils nach deren Test eingeführt werden können, ist natürlich abhängig von der Problemstellung.
Frühe Programmversionen
Relativ früh, spätestens nach der Phase Konzept, definiert man Entwicklerversionen. Diese betreffen natürlich die kritischen Use-Cases und sie sollen primär dazu dienen, allfällige Probleme oder Missverständnisse möglichst früh zu erkennen und zu beheben.