Document Actions
Methodik Entwicklung
Ein kurzer Abriss, wie bei der Entwicklung des Projektes methodisch vorgegangen wird: Spiralmodell, XP, SCRUM
Entwicklungsmodell
Als Entwicklungsmodell wird eine Kombination von Spiralmodell (nach Boehm 1988, bzw. Pomberger, Pree 2004) und Extrem Programming eingesetzt. Dies sichert die entsprechende Ballance der Strukturiertheit iterativer Entwicklung und der Flexibilität agiler leichtgewichtiger Methoden. Ein solcher Vorgehen soll die Verteile beider Modelle maximieren sowie die Nachteile minimieren. Milestones beschreiben Fixpunkte in den Iterationen des Spiralmodells.
Spiralmodell
Der Entwicklungsprozess wird in vier Schritte gegliedert, die im Sinne einer evolutionären Entwicklungsstrategie mehrmals zyklisch durchlaufen werden (siehe Abbildung unten).
Die radiale Ausdehnung stellt dabei den Gesamtaufwand, der bis zu einem bestimmten Zeitpunkt geleistet wurde, dar, und die Winkeldimension bezieht sich auf den Projektfortschritt in den einzelnen Spiralenzyklen. Jeder Zyklus umfasst die gleiche Schrittfolge für jeden Teil des zu entwickelnden Produkts und für jede Ausarbeitungsstufe.
Jeder Spiralenzyklus beginnt mit der Festlegung folgender Punkte (Schritt 1):
Ziele für und Anforderungen an das (Teil-)Produkt (Einsatzbereich, Funktionalität, Modifizierbarkeit etc.)
Alternativen zur Realisierung des (Teil-)Produkts (Lösungsvariante A, Lösungsvariante B, Wiederverwendung, Zukauf etc.)
Nebenbedingungen und Einschränkungen (Kosten, Termine, Schnittstellen etc.)
Im nächsten Schritt (Schritt 2) wird eine Beurteilung der vorgeschlagenen Lösungsvarianten im Hinblick auf die Projektziele und gegebenen Nebenbedingungen vorgenommen. Dabei geht es vor allem darum, mögliche Risikoquellen und Unklarheiten aufzudecken.
Werden solche gefunden, schließt sich daran die Überlegung von Maßnahmen und Strategien zur Ausschaltung von Risikoquellen und ihrer Auswirkung an. Dabei soll vor allem Prototyping eingesetzt werden. Falls zum Beispiel Unklarheit über den Leistungsumfang, die Gestaltung der Benutzungsschnittstelle oder das Datenmodell für eine Datenbank bestehen, sollen Prototypen helfen, diese Aspekte näher abzuklären.
Im Schritt 3 wird unter Berücksichtigung der verbleibenden Risiken das Prozessmodell für diesen Schritt festgelegt (dies kann auch eine Kombination verschiedener Prozessmodelle sein) und es werden die daraus resultierenden Aktivitäten durchgeführt.
Basierend auf den Ergebnissen einer Validierung als abschließende Aktivität in Schritt 3 wird in Schritt 4 der nächste Zyklus einschließlich der dazu benötigten Ressourcen geplant, und es muss ein Einverständnis über den nächsten Zyklus herbeigeführt werden. Diese Vorgangsweise setzt sich im Uhrzeigersinn fort.
Ein wichtiger Aspekt des Spiralmodells ist, dass jeder Zyklus mit einem Validierungsschritt versehen ist, in dem alle am Projekt beteiligten Personen und davon betroffene Anwender oder Organisationseinheiten mit einbezogen werden. Die Validierung umfasst alle Produkte, die während des Zyklus entstanden sind, darunter auch die Planung für den nächsten Zyklus sowie die dafür notwendigen Ressourcen. Wichtig ist, dass sich alle Beteiligten über das bisher Geleistete und das im nächsten Zyklus Geplante einig sind. Die Zyklusplanung kann selbstverständlich zu einer Aufteilung des Projekts in Teilprojekte führen, die dann in eine Reihe von parallel durchzuführenden Spiralenzyklen münden.
Es bleibt offen, wann die Spirale endet und wie die Phase der Wartung in dieses Vorgehensmodell eingebettet ist. Es wird davon ausgegangen, dass das Spiralmodell gleich gut sowohl auf die Entwicklung als auch auf die Wartung von Software-Produkten angewandt werden kann. In beiden Fällen beginnt man mit der Annahme, dass ein bestimmtes Aufgabenfeld durch den Einsatz oder die Anpassung von Software-Produkten sinnvoll bewältigt werden kann. Der (spiralförmige) Entwicklungsprozess dient der Prüfung dieser Hypothese. Die Spirale endet, wenn die Hypothese widerlegt ist oder der inkrementelle Entwicklungsprozess ein fertiges Produkt ergibt.
Der Vorteil des Spiralmodells liegt insbesondere darin, dass es sich gut für die Einbettung von Qualitätssicherungsmaßnahmen in den Software-Entwicklungsprozess eignet und sich an dem Ziel orientiert, möglichst früh Fehler zu erkennen und verschiedene Lösungsalternativen (mit vertretbarem Aufwand) zu erwägen. Es erfordert keine verschiedenen Ansätze für die Entwicklung und Wartung von Software-Systemen. Die Software-Entwicklung wird als kontinuierlicher Wartungsprozess angesehen. Dadurch verliert die Wartung ihren „zweitklassigen“ Status.
Viele Probleme, die entstehen, wenn – wie häufig der Fall – Wartungs- und Erweiterungsaktivitäten mit wesentlich geringerer Systematik und Planung durchgeführt werden als die Neuentwicklung eines Software-Produkts, werden dadurch vermieden.
Abbildung: Spiralmodell (nach Pomberger, Pree, 2004)
Ein entscheidender Vorteil ist weiters, dass es sich beim Spiralmodell um ein Meta-Modell handelt, dass die Integration anderer Prozessmodelle als Spezialfälle erlaubt. Dies steigert die Flexibilität, die Anpassungsmöglichkeiten an spezielle Rahmenbedingungen und die Akzeptanz.
Als nachteilig hat sich in der Praxis herausgestellt, dass zu Beginn eines Projektes Zeit- und Kostenpläne nur schwer zu erstellen sind. Wie alle Metamodelle hat auch dieses Modell den Nachteil, dass das richtige „Tailoring“ in entscheidendem Ausmaß von den Fähigkeiten und Erfahrungen der Projektverantwortlichen abhängt.
Extreme Programming
Extreme Programming (XP) postuliert im Wesentlichen vier so genannte „prägende Werte“, man könnte diese auch besser die vier kritischen Erfolgsfaktoren nennen. Diese sind: Kommunikation, Einfachheit, Feedback und Courage.
Durch die Betonung des Kommunikationsaspektes soll deutlich gemacht werden, dass der Projekterfolg ganz wesentlich von einem angemessenen Ausmaß und von der richtigen Art und Weise der Kommunikation zwischen den Projektbeteiligten abhängt, und dass daher dem Schaffen von geeigneten Rahmenbedingungen zur Förderung der Kommunikation im Rahmen der Projektorganisation besondere Bedeutung zukommt.
Durch die Betonung des Einfachheitsaspektes soll der Tatsache Rechnung getragen werden, dass viele Software-Produkte und auch die bei deren Herstellung ablaufenden Entwicklungsprozesse oft eine unnötig hohe Komplexität aufweisen und dass man daher bei jedem Schritt und bei jedem Zwischenergebnis darauf achten muss, Produkte und Prozesse so einfach wie möglich zu halten.
Durch die Betonung des Feedback-Aspektes soll sichergestellt werden, dass die Entwickler laufend über den Grad der Zufriedenheit der Auftraggeber informiert werden, den Grad der Anwenderakzeptanz für jede ausgelieferte Komponente kennen, und dass der Auftraggeber bei allen anstehenden Entscheidungen abschätzen kann, welche Folgen sich daraus im Hinblick auf Kosten, Termine, Produkteigenschaften und Produktqualität ergeben.
Durch die Betonung des Courage-Aspektes sollen die Projektbeteiligten zu verantwortlicher Eigeninitiative ermutigt werden. Sie sollen ohne pompöse Planung und hundertprozentige Absicherung die ihrer Meinung nach für den Projekterfolg notwendigen Schritte in Angriff nehmen und an die anderen Projektbeteiligten offen kommunizieren, auch wenn dabei Konflikte entstehen können, zum Beispiel bei Änderungen an „fremdem“ Code.
Ausgehend von diesen vier grundlegenden Aspekten postuliert das XP-Prozessmodell folgende Strukturierung bzw. folgenden Prozessablauf:
Der Entwicklungsprozess umfasst drei Teilprozesse: (1) Release-Planung, (2) iterative Release-Erstellung, (3) Akzeptanztests und Release-Veröffentlichung. Das Prozessmodell postuliert eine release-bezogene Produktentwicklung. Man beginnt mit der Entwicklung eines ersten Release (Systemkern), wobei die Entwicklungsdauer möglichst kurz gehalten wird (maximal drei bis vier Monate) und testet die Akzeptanz. Danach versucht man, in einer kontinuierlichen Abfolge neue Releases (Systemerweiterungen) zu erstellen.
Durch kontinuierliche Akzeptanztests versucht man das für die Erstellung des jeweils folgenden Release erforderliche Feedback von den Benutzern zu bekommen. Diese Vorgehensweise entspricht exakt der Vorgehensweise bei evolutionärer, Prototyping-orientierter Software-Entwicklung.
Die Vorteile des XP-Prozessmodells liegen vor allem in der Flexibilität bei der Anpassung an sich ändernde Rahmenbedingungen, in der Beschränkung auf das Wesentliche, im iterativen Grundmodell, in der starken Einbindung des Auftraggebers (on-site customer-Prinzip), im Verzicht darauf, bereits bei der Produktentwicklung künftige Anwenderanforderungen vorauszudenken und gegebenenfalls umzusetzen, und in der Möglichkeit, Entwicklungsziele von einem Release auf das nächste verschieben zu können.
XP eignet sich deshalb besonders für Produktentwicklungen, bei denen die Anforderungen an das Produkt nur in informeller, sehr vager Form vorliegen und/oder sich die Anforderungen häufig ändern.
Die Nachteile des XP-Prozessmodells sind, dass die postulierte Prozessorganisation, die für „kleine“ Projekte recht gut geeignet ist, mit zunehmender Produkt-/Projektkomplexit immer unpassender wird und keine verteilte Produktentwicklung möglich ist, die bei großen Projekten unabdingbar sein kann. Der XP-Prozess ist darauf ausgerichtet, jeweils nur ein spezifisches Problem zu lösen. Der Verzicht auf eine Systemdokumentation kann bei langlebigen Produkten, das heißt, wenn die personalisierte Wissenssicherung nicht mehr greift, schwerwiegende Folgen haben.
Als Rahmen für die Umsetzung der agilen Methoden von XP wird das SCRUM Modell verwendet. Dieses sieht Softwareentwicklung als Teamsport, in dem jedes Teammitglied unabhängig an einem gemeinsamen Ziel arbeitet. Wesentlicher Punkt dabei sind Sprints, in denen gemeinsam in jeder Phase intensiv an der Entwicklung gearbeitet wird. Siehe auch: Srum Development [wikipedia.org]