Richtlinie: Softwareentwicklungsplan
Diese Richtlinie unterstützt Sie beim Erstellen eines Softwareentwicklungsplans für einen iterativen Entwicklungszyklus. Sie beschreibt außerdem, inwieweit sich eine Prüfsequenz nach dem traditionellen Wasserfallmodell mit dem iterativen Ansatz deckt.
Beziehungen
Hauptbeschreibung

Dauer einer Iteration festlegen

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.

Anzahl der Iterationen bestimmen

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.

Prüfsequenz des traditionellen Wasserfallmodells mit dem iterativen Ansatz in Einklang bringen

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.

Projektorganisation

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.

Kontextabhängiges Diagramm, das zeigt, wie Zuständigkeiten auf die Teammitglieder 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.

Diagramm, dass die Entwicklung eines Teams im Verlauf des Projekts zeigt.

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.