RUP definiert eine Iteration als ein relativ abgeschlossenes Miniprojekt, das alle wichtigen Disziplinen durchläuft und
in den meisten Fällen ein ausführbares, wenn auch unvollständiges System - ein Release - hervorbringt. Obwohl sich der
Zyklus [Editieren, Kompilieren, Testen, Debugging] wie eine Iteration anhört, ist dies hier nicht gemeint. Das tägliche
oder wöchentliche inkrementelle Integrieren und Testen von immer mehr Elementen des Systems scheint eine eigene
Iteration zu sein, ist aber laut unserer Verwendung des Begriffs Iteration hier nur ein Teil einer Iteration.
Eine Iteration beginnt mit Planung und Anforderungen und endet mit einem Release (intern oder extern).
Die Dauer einer Iteration richtet sich primär nach der Größe der Entwicklungsorganisation.
Beispiel:
-
Fünf Personen haben Montag morgen Zeit für Planungsaktivitäten, gehen jeden Tag gemeinsam Mittagessen, um den
Fortschritt zu besprechen, weisen Aufgaben erneut zu, beginnen Donnerstag mit einem Build und schließen die
Iteration Freitag abends ab.
-
Eine solche Iteration ist mit 20 Personen nur schwer zu realisieren. Es dauert länger, die Arbeit zu verteilen,
zwischen Untergruppen zu synchronisieren, zu integrieren usw. Die Iteration kann hier bis zu drei oder vier Wochen
dauern.
-
Mit 40 Personen braucht es allein eine Woche, um "die Idee in die Tat umzusetzen". Sie haben zwischengeschaltete
Managementstufen, und somit erfordert eine gemeinsame Verständigung auf die Zielsetzung eine formalere
Dokumentation und mehr "Zeremonie". Drei Monate als Iterationsdauer anzusetzen, ist hier mehr als angemessen.
Es kommen andere Faktoren ins Spiel: der Vertrautheitsgrad der Organisation mit dem iterativen Ansatz (einschließlich
einer stabilen und reifen Organisation), der Automatisierungsgrad, den das Team verwendet, um Code zu verwalten (z. B.
verteiltes Konfigurationsmanagement), Informationen zu verteilen (z. B. internes Web), Tests durchzuführen usw.
Beachten Sie auch, dass jede Iteration einen gewissen festen Zusatzaufwand für Planung, Synchronisation, Analyse der
Ergebnisse usw. mitbringt.
Auch wenn Sie von den überragenden Vorteilen des iterativen Ansatzes überzeugt sind und diesen Ansatz verfolgen
möchten, könnte Ihr Eifer durch Personalfaktoren innerhalb Ihrer Organisation gebremst werden.
Es folgen einige empirische Daten:
SLOCs
|
Anzahl der Entwickler
|
Dauer einer Iteration
|
10.000
|
5
|
1 Woche
|
50.000
|
15
|
1 Monat
|
500.000
|
45
|
6 Monate
|
1.000.000
|
100
|
1 Jahr
|
-
Iterationen mit einer Dauer von mehr als 6 Monaten müssen wahrscheinlich integrierte Zwischenmeilensteine
haben, um das Projekt in der Spur zu halten. Sie können Inhalt und Umfang (Scope) der Iteration reduzieren, um die
Iterationsdauer zu verkürzen und einen klaren Fokus zu setzen.
-
Iterationen mit einer Dauer von mehr als 12 Monaten sind ein Risiko an sich, da sie sich über den
Jahresfinanzierungsplan hinaus erstrecken. Ein Projekt, dass innerhalb von 12 Monaten nicht Sichtbares produziert,
hat das Risiko, dass ihm möglicherweise die Mittel gestrichen werden.
-
Der Umfang von Iterationen mit einer Dauer von weniger als 1 Monat muss sorgfältig geplant werden.
Gewöhnlich eignen sich kurze Iterationen besser für die Konstruktionsphase, in der wenig neue Funktionalität und
Neuerungen eingeführt werden. In kurzen Iterationen werden wenig oder gar keine formalen Analyse- oder
Designaktivitäten durchgeführt. Solche Iterationen können einfach der inkrementellen Verbesserung bereits
verstandener Funktionalität dienen.
-
Iterationen müssen nicht alle dieselbe Dauer haben: Die Dauer von Iterationen richtet sich nach den
Zielsetzungen. Normalerweise dauern Ausarbeitungsiterationen länger als Konstruktionsiterationen. Innerhalb einer
Phase haben Iterationen in der Regel dieselbe Dauer (was die Planung einfacher macht).
Sobald Sie eine Vorstellung von der Anzahl der Iterationen in Ihrem allgemein definierten Plan haben, müssen Sie den
Inhalt jeder Iteration definieren. Es ist sogar sinnvoll, einen Namen oder Titel zu finden, um das Produkt, das jede
Iteration hervorbringt, zu qualifizieren, damit die Mitarbeiter genau wissen, auf was sie sich konzentrieren müssen.
Beispieliterationen für ein privates Telefonsystem
-
Iteration 1: Ortsgespräch
-
Iteration 2: Amtsgespräche und Teilnehmermanagement hinzufügen.
-
Iteration 3: Voicemail und Telefonkonferenzen hinzufügen.
Ein sehr einfaches Projekt kann pro Phase nur eine Iteration haben:
-
Eine Iteration in der Konzeptionsphase, in der möglicherweise ein Prototyp für die Machbarkeitsstudie oder ein
Benutzerschnittstellenmodell eingeführt wird, oder gar keine Iteration in der Konzeptionsphase, wie es
beispielsweise in einem Weiterentwicklungszyklus der Fall ist.
-
Eine Iteration in der Ausarbeitungsphase, in der ein Architekturprototyp erstellt wird.
-
Eine Iteration in der Konstruktionsphase, in der das Produkt erstellt wird (bis hin zu einem Beta-Release).
-
Eine Iteration in der Übergangsphase, in der das Produkt fertig gestellt wird (vollständiges Produkt-Release).
Für ein umfangreicheres Projekt in seinem ersten Entwicklungszyklus gilt als Norm:
-
Eine Iteration in der Konzeptionsphase (in der möglicherweise ein Prototyp erstellt wird).
-
Zwei Iterationen in der Ausarbeitungsphase, eine für einen Architekturprototyp und eine für die Referenzversion der
Architektur.
-
Zwei Iterationen in der Konstruktionsphase, in denen das System teilweise offen gelegt wird und in denen es reift.
-
Eine Iteration in der Übergangsphase, in der der Übergang von der ersten Betriebsbereitschaft zu einem
vollständigen Produkt-Release erfolgt.
Für große Projekte mit vielen Unbekannten, neuen Technologien usw. kann Folgendes vorgesehen werden:
-
eine zusätzliche Iteration in der Konzeptionsphase für weitere Prototyperstellungen
-
eine zusätzliche Iteration in der Ausarbeitungsphase für die Untersuchung unterschiedlicher Technologien
-
eine zusätzliche Iteration in der Konstruktionsphase allein aus dem Grund, weil das Produkt so große ist
-
eine zusätzliche Iteration in der Übergangsphase für Rückmeldungen zum Betrieb
In einem Entwicklungszyklus haben wir also folgende Möglichkeiten:
-
mindestens 3 Iterationen [0,1,1,1]
-
gewöhnlich 6 Iterationen [1, 2, 2, 1]
-
für große Projekte 9 Iterationen [1, 3, 3, 2]
-
für sehr große Projekte 10 Iterationen [2, 3, 3, 2]
Im Allgemeinen sollten Sie zwischen drei und zehn Iterationen einplanen. Die genannten Mindest- und Maximalwerte
beziehen sich jedoch auf ungewöhnliche Umstände. Die meisten Entwicklungen benötigen sechs bis acht Iterationen.
Je nach Risiken, Größe und Komplexität sind viele Variationen möglich:
-
Wenn das Produkt für eine vollständig neue Domäne bestimmt ist, müssen Sie möglicherweise Iterationen in der
Konzeptionsphase hinzufügen, um die Konzepte zu konsolidieren, einem ausgewählten Kreis von Kunden und Benutzern
verschiedene Modelle vorzustellen oder ein fundiertes Angebot auf eine Ausschreibung hin zu formulieren.
-
Wenn eine neue Architektur entwickelt werden muss, ziemlich viel Aufwand für die Anwendungsfallmodellierung
betrieben werden muss oder viele Risiken zu bewältigen sind, sollten Sie drei oder Iterationen in der
Ausarbeitungsphase planen.
-
Wenn das Produkt groß und komplex ist und über einen langen Zeitraum hinweg entwickelt wird, sollten
mindestens drei Iterationen in der Konstruktionsphase planen.
-
Sie sollten mehrere Iterationen in der Übergangsphase planen, wenn Sie die Markteinführungszeit für das Produkt
verkürzen und das Produkt deshalb mit einer eingeschränkten Funktionalität liefern müssen oder wenn Sie das Gefühl
haben, dass Sie nach einer gewissen Verwendungszeit viele kleine Anpassungen an der Endbenutzerbasis vornehmen
müssen.
Die Standardprüfsequenz für ein Projekt mit Wasserfalllebenszyklus sieht eine einzige größere Prüfung bei
Fertigstellung der wichtigen Arbeitsergebnisse vor, z. B.:
-
Systemanforderungsprüfung (SSR, System Requirements Review) bei Fertigstellung der Systemspezifikation
-
Softwarespezifikationsprüfung (SSR, Software Specification Review) bei Fertigstellung der
Softwareanforderungsspezifikation
-
Prüfung des vorläufigen Designs (PDR, Preliminary Design Review) bei Fertigstellung der
Architekturdesignabschnitte der Softwaredesignbeschreibung
-
Kritische Designprüfung (CDR, Critical Design Review) bei Fertigstellung der detaillierten Designabschnitte
der Softwaredesignbeschreibung
In Rational Unified Process (RUP) werden Teile der äquivalenten Arbeitsergebnisse geprüft, sobald sie in einer
Iteration fertig gestellt wurden. Die Hauptmeilensteine (und damit die Prüfungen selbst) sind jedoch am Abschluss der
einzelnen Phasen ( Konzeption, Ausarbeitung, Konstruktion und Übergang) ausgerichtet. Ein Projektleiter, der RUP
anwenden möchte, muss möglicherweise aufgrund von vertraglichen Verpflichtungen eine Möglichkeit finden, um diesen
offensichtlichen Konflikt zu lösen. Idealerweise sollte der Projektleiter den Kunden davon überzeugen, dass der phasen-
und iterationsbasierte Ansatz mehr Transparenz in den Projektfortschritt bringt und die Risiken vermindert, so dass
keine Notwendigkeit für eine Softwareanforderungsprüfung, eine Softwarespezifikationsprüfung usw. besteht. Dies ist
jedoch nicht immer möglich, und der Projektleiter muss diese Prüfungen zu entsprechenden Zeitpunkten planen. In RUP
können die Punkte, an denen diese wichtigen Arbeitsergebnisse (d. h. ihre Entsprechungen in RUP) im Wesentlichen fertig
gestellt sind, untergebracht werden, obwohl dies nicht immer ganz exakt mit Phasen oder Iterationen übereinstimmt.
Hierfür wird angenommen, dass der relative Aufwand für Anforderungen, Design usw. in RUP und im (idealen)
Wasserfalllebenszyklus nahezu derselbe ist, aber dass der Aufwand anders verteilt wird. Das Ergebnis ist Folgendes:
-
Die Softwareanforderungsprüfung (die sich hauptsächlich mit der Vision
beschäftigt) kann am Ende der Konzeptionsphase geplant werden.
-
Die Softwarespezifikationsprüfung (die sich hauptsächlich mit der Softwareanforderungsspezifikation beschäftigt) findet ungefähr
nach dem ersten Drittel der Ausarbeitungsphase statt.
-
Die Prüfung des vorläufigen Designs (die sich hauptsächlich mit dem Softwarearchitekturdokument beschäftigt) findet am Ende der
Ausarbeitungsphase statt.
-
Die kritische Designprüfung (die sich hauptsächlich mit dem Designmodell beschäftigt) findet ungefähr nach dem ersten Drittel
der Konstruktionsphase statt.
Aus Effizienzgründen sollte der Projektleiter nach Rücksprache mit dem Kunden versuchen, diese Prüfungen mit den
vorgeschriebenen RUP-Prüfungen zusammenzulegen. Dies ist eindeutig möglich für die Softwareanforderungsprüfung und die
vorläufige Designprüfung. Diese können mit der Prüfung Meilenstein
'Zielsetzungen des Lebenszyklus' bzw. der Prüfung am Meilenstein 'Architektur des Lebenszyklus' kombiniert werden.
Die Projektorganisation wird ebenso wie der Softwareprozess von den Merkmalen des Projekts beeinflusst. Die hier
dargestellte Standardstruktur (siehe folgende Abbildung) muss angepasst werden, um die Auswirkungen der Faktoren
widerzuspiegeln, von denen einige im Folgenden aufgelistet sind:
-
Geschäftskontext
-
Größe des Softwareentwicklungsaufwands
-
Neuheitsgrad
-
Typ der Anwendung
-
Aktueller Entwicklungsprozess
-
Organisatorische Faktoren
-
Technische und verwaltungsbezogene Komplexität
Dies sind Hauptunterscheidungsfaktoren, die zu berücksichtigen sind, wenn analysiert wird, wie die Organisation als
Ganzes einen neuen Entwicklungsprozess einsetzen sollte. Hier werden die Auswirkungen dieser Faktoren auf die Wahl der
Projektstruktur untersucht. Die folgende Abbildung zeigt eine Standardprojektorganisation und veranschaulicht, wie
Zuständigkeiten auf die Teamstruktur verteilt werden.
Abbildung, die eine Standardprojektorganisation zeigt. Dauer der Betriebszugehörigkeit und Autorität haben bei der
Reihenfolge der Rollen keine Bedeutung.
Sie können diese Abbildung als Ausgangspunkt verwenden, wenn Sie überlegen, wie Rollen und Zuständigkeiten auf
Projektebene auf eine Struktur von Teams verteilt werden sollen. Die Abbildung veranschaulicht auch, dass Rollen (in
den gelben Kästchen gezeigt) keine Personen, sondern "Schuhe" sind, die sich eine Person (oder ein Team) in dem Projekt
anziehen kann. Aus diesem Grund kommen einige Rollen (der Projektleiter z. B. ) auch mehrfach vor. Dies zeigt auf, dass
das Verhalten des Projektleiters (laut Definition in RUP) gelegentlich in mehreren Teams vorkommen kann. In einem
großen Projekt kann beispielsweise das Vorbereiten eines Statusberichts basierend auf dem Projektstrukturplan an eine
Person im Verwaltungsteam delegiert werden. Dies ist jedoch eine Zuständigkeit, die RUP der Rolle
Projektleiter zuweist.
In einem kleinen Projekt ist es wahrscheinlich, dass eine zum Projektleiter ernannte Person alle Aufgaben der
Rolle Projektleiter ausführt. In diesem Fall sind Verwaltungsteam und Softwaremanagementteam eins. Die Auswahl
der Teamstruktur wird durch den Charakter und die Größe des Projekts beeinflusst, sollte jedoch von einigen, dem
gesunden Menschenverstand entspringenden Regeln gelenkt werden:
-
Kleine Teams sind gewöhnlich produktiver. In größeren Projekten muss dies jedoch gegen die Menge teamübergreifender
Interaktionen abgewägt werden.
-
Zu tief verschachtelte Hierarchien sollten vermieden werden.
-
Die Anzahl der Mitarbeiter jedes Managers oder Teamleiters sollte auf sieben plus/minus zwei begrenzt werden.
-
Die Teamstruktur für die Softwareentwicklung sollte auf der
Basis der Softwarearchitektur entschieden werden. Eine gute Architektur mit hoher Kohäsion und geringer Kopplung
zwischen Subsystemen ermöglicht eine effektivere parallele Arbeit von Teams.
-
Tests (keine Einheitentests) sollten im Idealfall von einem anderen Team als dem Entwicklerteam durchgeführt
werden. Dies kann jedoch in einem sehr kleinen Projekt in wirtschaftlicher Hinsicht nicht praktikabel sein.
-
Die Struktur muss zulassen, dass allen Teams und Personen klar definierte Berechtigungen und Zuständigkeiten
zugeteilt werden können. Dies ist besonders wichtig, wenn die Hierarchie mehr als drei Ebenen aufweist. Die Manager
und Teamleiter in der Mitte solcher Strukturen müssen verstehen, was von ihnen erwartet wird, indem die technischen
und verwaltungsorientierten Aufgaben gleichmäßig verteilt werden.
-
Die Struktur muss die Fähigkeiten, Erfahrungen und Motivationen der Mitarbeiter unterstützen. Wenn ein Team
beispielsweise ohne Zwischenübergaben für Analyse, Design und Implementierung zuständig sein soll, muss es alle
erforderlichen Kompetenzen aufweisen. Erfahrene Analytiker sind nicht zwingenderweise auch gute Implementierer.
-
Teamstrukturen sollten nicht starr sein. Personen können im Leben eines Projekts das Team wechseln, und die
Zuständigkeiten des Teams können sich ändern, wenn sich der Schwerpunkt des Projekts von Phase zu Phase verlagert.
Das Grundprinzip für die Standardorganisation wird ausführlich in [ROY98] beschrieben.
Bei der Zuordnung von Deployment-Zuständigkeiten zum Softwarebewertungsteam wird insbesondere berücksichtigt, dass das
Softwarebewertungsteam von allen Teams in einem Entwicklungsprozess sich am meisten mit der Software beschäftigt, die
letztendlich dem Benutzer präsentiert wird.
Im Verlauf eines Projekts entwickelt sich die Organisation und unterstützt schließlich den Projektstrukturplan, der im
Projektplan erfasst wird. Dies wird in der folgenden Abbildung gezeigt, die [ROY98] entnommen
wurde.
Diese Weiterentwicklung veranschaulicht die unterschiedlichen Aufgaben in den einzelnen Phasen:
-
Konzeptionsteam: Eine Organisation, die sich auf die Planung konzentriert und dabei genügend Unterstützung von den
anderen Teams erhält, um sicherzustellen, dass die Pläne einen Konsens aller Perspektiven darstellt.
-
Ausarbeitungsteam: Eine Organisation, die sich auf die Architektur konzentriert und in der sich die treibenden
Kräfte im Softwarearchitekturteam befinden, das bei Bedarf durch die Softwareentwicklungs- und
Softwarebewertungsteams unterstützt wird, um eine stabile Referenzversion der Architektur zu erhalten.
-
Konstruktionsteam: Eine ausgewogene Organisation, in der die meisten Aufgaben beim Softwareentwicklungs- und
Softwarebewertungsteam liegen.
-
Übergangsteam: Eine kundenorientierte Organisation, in der die Deployment-Aufgaben durch Rückmeldungen zur
Bedienung gesteuert werden.
Durch die Wanderung zwischen Teams während der Weiterentwicklung wird sichergestellt, dass Wissen und Fähigkeiten im
Projekt verbleiben. Nach Abschluss der Ausarbeitungsphase könnten beispielsweise einige Mitglieder des Architekturteams
auf die Entwicklungsteams verteilt werden, z. B. als Teamleiter, oder die Architekturvision an die Entwicklung
weitertragen. Noch später, gegen Ende der Konstruktionsphase, verlagert sich der Schwerpunkt auf das Bewertungsteam,
und Mitarbeiter des Entwicklungsteams wandern in das Bewertungsteam ab. Um im Eifer des Konstruktionsaufwands den
Verlust der Architekturintegrität zu vermeiden, ist es wichtig, dass nicht zugelassen wird, dass der Einfluss des
Architekturteams als 'Schwerpunktzentrum' im Verlauf des Projekts schwindet. Die Verlagerung einiger Mitarbeiter des
Architekturteams in das Bewertungsteam ist beispielsweise eine Möglichkeit.
|