Aufgabe: Iterationsplan entwickeln
Diese Aufgabe beschreibt, wie ein Iterationsplan zusammengestellt wird, indem Inhalt und Umfang (Scope), die Bewertungskriterien und die Aktivitäten definiert und die Zuständigkeiten für die Iteration zugeordnet werden.
Zweck

Einen Iterationsplan entwickeln, der sich wie folgt zusammensetzt:

  • Detaillierter Projektstrukturplan der Aufgabe und Zuordnung der Zuständigkeiten
  • Meilensteine und Liefergegenstände für die Iteration
  • Bewertungskriterien für die Iteration
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Die Iteration selbst ist eine in einem bestimmten Zeitrahmen auszuführende Gruppe von Aufgaben, die sich streng auf die Produktion einer ausführbaren Funktion konzentrieren. Bei allen Iterationen mit Ausnahme der letzten Übergangsiteration ist dies ein Zwischenprodukt, das erzeugt wird, um die Aufmerksamkeit des Teams darauf zu lenken, dass die Risiken minimiert und das Projekt einem erfolgreichen Abschluss entgegengesteuert wird. Der Fokus auf einen ausführbaren Liefergegenstand macht eine nahezu fortlaufende Integration zwingend erforderlich und ermöglicht dem Projekt, technische Risiken früh anzugehen und somit begleitende Risiken zu verringern.

Iterationen implizieren gewisse Nacharbeiten (an vorhandenen Arbeitsergebnissen) und eine damit einhergehende geänderte Einstellung gegenüber Nacharbeiten. Kurz gesagt, Nacharbeiten sind erforderlich, um ein qualitativ hochwertiges Produkt zu liefern: Durch die Erstellung von Zwischenprodukten und die frühe und wiederholte Beurteilung der Eignung der Produktarchitektur erhöht sich die Qualität des Endprodukts und dies zu einem Zeitpunkt, zu dem Änderungen weniger kostenintensiv sind und sich leichter implementieren lassen.

Schritte
Iterationsumfang bestimmen
Zweck Gruppe von Anwendungsfällen oder Szenarios auswählen, die während der Iteration berücksichtigt werden müssen.
Gruppe nicht funktionaler Anforderungen auswählen, die während der Iteration bearbeitet werden müssen. 
Richtlinien: Iterationsplan 

Der Umfang einer Iteration wird durch vier Faktoren gesteuert:

  • Größte Risiken für das Projekt
  • Vom System geforderte Funktionalität
  • Im Projektplan festgelegte Dauer der Iteration
  • Phase und ihre spezifische Zielsetzungen (siehe Konzept: Phase)

Bei der Anfangsplanung einer Iteration wird genügend Arbeit ausgewählt, um die für die Iteration geplante Zeit zu füllen, obwohl der Projektleiter während der Entwicklung des Iterationsplans einen gewissen Spielraum hat, um Ressourcenengpässe und andere taktische Maßnahmen einzukalkulieren. Es versteht sich von selbst, dass Arbeit, die für die vorherige Iteration geplant war, aber nicht abgeschlossen wurde (weil der Umfang der vorherigen Iteration im Hinblick auf den Zeitplan reduziert wurde), normalerweise hohe Priorität hat.

Die Bestimmung des Arbeitsumfangs für die Iteration muss einhergehen mit der sorgfältigen Überlegung, wie viele Mitarbeiter benötigt werden, um diese Arbeit effizient erledigen zu können. Beispielsweise kann die in einer Iteration zu bewältigende Arbeit gewöhnlich nicht durch Verdopplung des Personals verdoppelt werden, selbst wenn das Personal zur Verfügung stünde. Mit welcher Mitarbeiterzahl eine effiziente Iterationsdurchführung möglich ist, richtet sich nach der Gesamtsoftwaregröße und der Architektur. Schätzmodelle wie COCOMO II (siehe [BOE00]) können Anhaltspunkte liefern.

Die Durchführung einer Iteration wird dann durch Zeitrahmen verwaltet, d. h. Umfang und Qualität (ausgedrückt in gefundenen und nicht in behobenen Mängeln) werden aktiv verwaltet, um den Endtermin zu halten.

In der Ausarbeitungsphase:

Es gibt drei Hauptfaktoren für die Definition der Zielsetzungen einer Iteration in der Ausarbeitungsphase:

  • Risiko
  • Priorität
  • Abdeckung

Der Hauptfaktor für die Definition von Iterationszielsetzungen sind Risiken. Sie müssen Risiken so früh wie möglich mindern bzw. ausschalten. Dies findet zum größten Teil in der Ausarbeitungsphase statt. Dort sollten die meisten Risiken gemindert werden. Die Risikominderung kann sich aber als Schlüsselelement bis in die Konstruktionsphase fortpflanzen, wenn einige Risiken unvermindert hoch bleiben oder neue Risiken erkannt werden. Da das Ziel der Ausarbeitungsphase jedoch das Erstellen einer Referenzversion der Architektur ist, kommen einige andere Aspekte ins Spiel, z. B. sicherzustellen, dass die Architektur alle Aspekte der zu entwickelnden Software adressiert (Abdeckung). Dies ist wichtig, weil die Architektur für die weitere Planung verwendet wird: Organisation des Teams, Schätzung des zu entwickelnden Codes usw.

Obwohl es wichtig ist, den Fokus auf Risiken zu setzen, muss man unbedingt im Hinterkopf behalten, was der primäre Auftrag des Systems ist: Die Behebung aller schwerwiegenden Probleme ist sinnvoll, aber dabei darf die Kernfunktionalität nicht vernachlässigt werden. Stellen Sie sicher, dass die kritischen Funktionen und Services des System wirklich abgedeckt sind (Kritikalität), selbst wenn ihnen kein offensichtliches Risiko anhaftet.

Ermitteln Sie anhand der Liste der Risiken ein Szenario in einem Anwendungsfall, mit dem das Entwicklungsteam dazu gezwungen wird, sich mit dem Risiko auseinander zu setzen.

Beispiele

  • Wenn es ein Integrationsrisiko wie "Datenbank D arbeitet ordnungsgemäß mit Betriebssystem Y" gibt, stellen Sie sicher, ein Szenario einzufügen, dass, wenn auch nur in bescheidenem Maße, Datenbankinteraktionen beinhaltet.
  • Wenn es ein Leistungsrisiko wie "Zeit zur Berechnung der Flugbahn des Flugzeugs" gibt, stellen Sie sicher, dass Sie ein Szenario einfügen, das diese Berechnung beinhaltet, zumindest für den offensichtlichsten und häufigsten Fall.

Stellen Sie für die Kritikalität sicher, dass die grundlegenden Funktionen und Services des Systems beinhaltet sind. Wählen Sie ein Szenario aus dem Anwendungsfall aus, das die allgemeinste, die häufigste Form des vom System angebotenen Service bzw. Feature darstellt. Zur Unterstützung dieser Arbeit wird das Softwarearchitekturdokument verwendet, das eine nach Priorität sortierte Gruppen von Anwendungsfällen oder ungeordneten Abläufen von Anwendungsfällen beschreibt, die vom Softwarearchitekten ausgewählt wurden, um die architektonisch relevanten Anwendungsfälle und Szenarios zu veranschaulichen.

Beispiel

  • Bei einem Telefonsystem ist der einfache Anruf zwischen Stationen das offensichtliche Muss für eine frühe Iteration. Diese Funktion ist weitaus wichtiger als die ausgefeilten Fehlermodi in der Operatorkonfiguration des Subsystems für Fehlerbehandlung.

Fügen Sie für die Abdeckung gegen Ende der Ausarbeitungsphase Szenarios ein, die Bereiche berühren, von denen Sie wissen, dass Entwicklungsarbeiten erforderlich sind, obwohl sie weder kritisch noch risikoreich sind.

Wirtschaftlich gesehen ist es häufig besser, lange und umfassende Szenarios zu erstellen, die mehrere Probleme gleichzeitig ansprechen.

Es besteht jedoch häufig die Gefahr, dass die Szenarios zu "komplex" werden, d. h. versuchen, zu viele unterschiedliche Aspekte, Varianten und Fehlerfälle abzudecken (siehe Iterationsplan).

In der Ausarbeitungsphase müssen Sie auch daran denken, dass einige der Risiken eher auf menschlicher oder programmatischer Seite anzusiedeln sind (Teamkultur, Ausbildung, Auswahl der Tools, neue Techniken usw.) und sich mit jeder Integration verringern.

Beispiele

  1. Einen Teilnehmerdatensatz auf einer Clientworkstation anlegen, der in der Datenbank auf dem Server gespeichert wird, einschließlich Benutzerdialog, der nicht alle Felder enthalten muss, und voraussetzen, dass kein Fehler erkannt wird.
    Kombiniert einige kritische Funktionen mit einigen Integrationsrisiken (Datenbank und DFV-Software) und Integrationsrisiken (wegen der Beteiligung von 2 unterschiedlichen Plattformen). Zwingt die Designer, sich mit dem neun Designtool für grafische Benutzerschnittstellen vertraut zu machen. Erzeugt schließlich einen Prototyp, der den Benutzern vorgestellt werden kann, um Rückmeldungen zu erhalten.
  2. Sicherstellen, dass 20.000 Teilnehmer erstellt werden können und dass kein Zugriff länger dauert als 200 Millisekunden.
    Adressiert einige Hauptleistungsaspekte (Menge oder Daten und Antwortzeit), die sich erheblich auf die Architektur auswirken können, wenn sie nicht erfüllt werden.
  3. Änderung der Teilnehmeradresse rückgängig machen.
    Ein einfaches Feature, das die Designer dazu zwingt, über das Design aller Funktionen "Rückgängig machen" nachzudenken. Der Ball können dann wieder an die Benutzer zurückgespielt werden, die sich unter Berücksichtigung des Kostenfaktors darüber Gedanken machen müssen, welcher dieser Funktionen sie den Vorzug geben.
  4. Alle Anwendungsfälle in Zusammenhang mit dem Management der Lieferkette abschließen.
    In der Ausarbeitungsphase soll auch die Erfassung der Anforderungen abgeschlossen werden.

In der Konstruktionsphase:

Auch in der Konstruktionsphase bleiben die Risiken ein Hauptschwerpunkt, insbesondere, wenn neue unerwartete Risiken entdeckt werden. Aber auch die Vollständigkeit der Anwendungsfälle fängt an, eine treibende Kraft zu werden. Die Iterationen können Feature um Feature geplant werden. Es sollte versucht werden, einige der kritischsten Features früh fertig zu stellen, damit sie in mehreren Iterationen gründlich getestet werden können. Gegen Ende der Konstruktion ist die Stabilität vollständiger Anwendungsfälle das Hauptziel.

Beispiel

  1. Alle Varianten von Rufweiterleitung, einschließlich fehlerhafter implementieren.
    Dies ist eine Gruppe zusammengehöriger Features. Eine kann bereits während der Ausarbeitungsphase implementiert worden sein und als Prototyp für den Rest der Entwicklung dienen.
  2. Alle Telefonzentralen-Features mit Ausnahme des Nachtdienstes fertig stellen.
    Eine weitere Gruppe von Features.
  3. 5.000 Transaktionen pro Stunde mit einer 2-Computer-Konfiguration erreichen.
    Dies kann die erforderliche Leistung relativ zu dem, was tatsächlich in der vorherigen Iteration erreicht wurde (nur 2.357/Stunde), erhöhen.
  4. Neue Version eines Geographical Information System integrieren.
    Dies kann eine geringfügige Architekturänderung sein, die durch ein zuvor entdecktes Problem erforderlich wird.
  5. Alle Mängel der Stufe 1 und Stufe 2 beheben.
    Behebt Mängel, die während der Tests in der vorherigen Iteration festgestellt und nicht unverzüglich behoben, sondern verschoben wurden..

In der Übergangsphase:

Das Hauptziel ist die Fertigstellung dieser Produktgeneration. Die Zielsetzungen für eine Iteration werden anhand der zu behebenden Fehler und der einzuführenden Verbesserungen in Leistung oder Benutzerfreundlichkeit definiert. Wenn Features verworfen (oder inaktiviert) werden mussten, um rechtzeitig zum Ende der Konfiguration (Meilenstein 'Erste Betriebsbereitschaft' oder "Beta") zu kommen, wurden diese möglicherweise in der Zwischenzeit fertig gestellt oder aktiviert, falls sie das bisher Erreichte nicht gefährden.

Beispiele

  1. Alle Probleme der Kategorie 1 beheben, die an Kundenstandorten in der Betaversion gefunden werden.
    Ein Qualitätsziel kann mit der Glaubwürdigkeit auf dem Markt in Zusammenhang stehen.
  2. Alle Abstürze beim Starten ausmerzen, die auf abweichende Daten zurückzuführen sind.
    Ein weiteres Qualitätsziel.
  3. 2.000 Transaktionen pro Minute erreichen.
    Durchsatzverbesserung, einschließlich einiger Optimierungsarbeiten: Änderung der Datenstruktur, Caching und intelligentere Algorithmen.
  4. Anzahl unterschiedlicher Dialogfenster um 30 % reduzieren.
    Benutzerfreundlichkeit durch Steigerung der Übersichtlichkeit von Anzeigen verbessern.
  5. Deutsche und japanische Versionen produzieren.
    Die Betaversion wurde aus Zeitmangel und zur Verringerung von Nacharbeiten nur für Englisch sprechende Kunden produziert.
Bewertungskriterien für die Iteration definieren

Jede Iteration bringt ein ausführbares Release hervor. Das Release hat gewöhnlich keine Produktionsqualität (abgesehen von der letzten Übergangsiteration), kann aber trotzdem bewertet werden.

Konzeptionsiterationen bewerten

Die Konzeptionsiteration konzentriert sich im Allgemeinen auf den Nachweis des Produktkonzepts und die Bereitstellung der für die Bewilligung der Projektmittel erforderlichen Unterstützung. Das Iterations-Release ist deshalb gewöhnlich ein funktionaler Prototyp für den Konzeptnachweis, dem es unterhalb einer dünnen Benutzerschnittstellenfassade an echtem Implementierungscode fehlt. Die Bewertungskriterien sind an der Benutzerakzeptanz und qualitativen Messwerten ausgerichtet.

In bestimmten Situationen müssen in der Konzeptionsphase wichtige technische Hürden überwunden werden, bevor Projektmittel bereitgestellt werden. Die Bewertungskriterien müssen dies zum Ausdruck bringen.

Ausarbeitungsiterationen bewerten

Der Schwerpunkt in den Ausarbeitungsiterationen liegt auf der Erstellung einer stabilen Architektur. Deshalb müssen sich die Bewertungskriterien für die Ausarbeitung auf die Bewertung der Architekturstabilität konzentrieren. Die folgenden Messwerte können verwendet werden:

  • Stabilität der Schnittstelle (oder Schadhaftigkeit)
  • Die Änderungsrate für die Architektur (verglichen mit einer Referenzversion der Architektur)
  • Leistung der Schlüsselfunktionalität

Das Hauptziel ist sicherzustellen, dass sich Änderungen in der Konstruktionsphase nicht durch das System ziehen und zu übermäßigen Nacharbeiten führen.

Konstruktions- und Übergangsiterationen bewerten

Konstruktions- und Übergangsiterationen werden mit traditionellen Softwaretests und Änderungsmanagementdimensionen wie Schadhaftigkeit, Mängeldichte und Fehlererkennungsraten gemessen. Der Fokus in diesen Iterationen liegt auf der Ermittlung von Fehler, damit diese behoben werden können.

Fehler werden auf verschiedene Arten gefunden: durch Untersuchungen und Codeprüfungen, funktionale Tests, Leistungstests und Belastungstests. Jede Technik orientiert sich an einer bestimmten Gruppe von Mängeln, und jede hat ihren Platz. Einzelheiten zu diesen Techniken finden Sie in der Beschreibung der RUP-Disziplin Test.



Iterationsaktivitäten definieren

Basierend auf den Zielen der Iteration müssen die während der Iteration auszuführenden Aufgaben ausgewählt werden. Gewöhnlich durchläuft jede Iteration einen Teil aller Aufgaben im Softwarelebenszyklus:

  • Anwendungsfälle und Szenarios werden ausgewählt, die die erforderliche Funktionalität durchexerzieren.
  • Das Anwendungsfallverhalten (bzw. Szenarioverhalten) wird geprüft und dokumentiert.
  • Das Verhalten wird analysiert und auf Subsysteme und Klassen verteilt, die das erforderliche Verhalten erbringen.
  • Die Klassen und Subsysteme werden entworfen, implementiert und Einheitentests unterzogen.
  • Das System wird als Ganzes integriert und getestet.
  • Für externe Releases (Alpha, Beta und allgemeine Verfügbarkeit) wird das Produkt in einer Release-fähigen Form gepackt und in die Benutzerumgebung überführt.

Der Grad, zu dem diese Aufgaben ausgeführt werden, variiert mit den Iterationen und Phasen des Projekts. Die einzelnen Disziplinen (Anforderungen, Analyse & Design, Test usw.) definieren die generischen Aufgaben, die wiederum während der Prozesskonfiguration an die Organisation angepasst werden.

Betroffene Arbeitsergebnisse und involvierte Aufgaben identifizieren

Nachdem Sie die zu entwickelnden Szenarios oder kompletten Anwendungsfälle (einschließlich zu behebender Mängel) ausgewählt und kurz skizziert haben, müssen Sie feststellen, welche Arbeitsergebnisse betroffen sind:

  • Welche Klassen müssen nochmals bearbeitet werden?
  • Welche Subsysteme sind betroffen oder werden erstellt?
  • Welche Schnittstellen müssen wahrscheinlich geändert werden?
  • Welche Dokumente müssen aktualisiert werden?

Anschließend extrahieren Sie aus den Prozessdisziplinen die involvierten Aufgaben und übernehmen Sie sie in Ihren Plan. Einige Aufgaben werden nur einmal pro Iteration (wie in diesem Beispiel) ausgeführt, andere müssen einmal pro Klasse, pro Anwendungsfall oder pro Subsystem (Beispiel) ausgeführt werden. Verbinden Sie diese Tasks mit ihren offensichtlichen Abhängigkeiten und weisen Sie ihnen einen geschätzten Aufwand zu. Die meisten Aufgaben, die für den Prozess beschrieben werden, sind so klein, dass sie von einer einzelnen Person oder einer sehr kleinen Gruppe von Personen in wenigen Stunden bzw. wenigen Tagen bewältigt werden können.

Wahrscheinlich werden Sie feststellen, dass in der Iteration nicht genug Zeit bleibt, um alle Aufgaben zu erledigen. Anstatt die Iteration auszudehnen (und damit den Endtermin für die Lieferung verschieben oder die Anzahl der Iterationen reduzieren zu müssen), sollten Sie Ihre Ambitionen für die Iteration herabsetzen. Je nach Phase, in der Sie sich befinden, können Sie die Szenarios vereinfachen, Features verwerfen oder inaktivieren.

Zuständigkeiten zuordnen

Nachdem Sie die Aufgaben für die Iteration definiert haben, müssen Sie sie den einzelnen Projektteammitgliedern zuordnen. Je nach Verfügbarkeit von Personalressourcen und Umfang der Iteration können die Aufgaben entweder von einer Person oder von einem Team ausgeführt werden. Prüfungen und Untersuchungen sind natürlich Teamaufgaben. Andere Aufgaben wie das Authoring von Anwendungsfällen oder das Design und die Implementierung von Klassen sind von Natur aus Aufgaben für Einzelpersonen (abgesehen von solchen Fällen, in denen einem jüngeren Teammitglied ein erfahrenes Teammitglied als Mentor zur Seite gestellt wird).

Im Allgemeinen muss jedes Arbeitsergebnis in der Zuständigkeit einer Einzelperson liegen, auch wenn die Arbeit von einem Team ausgeführt wird:

  • Anwendungsfälle
  • Subsysteme
  • Klassen
  • Tests und Testpläne
  • etc.

Ohne zentrale Anlaufstelle ist die Gewährleistung der Konsistenz nahezu unmöglich.



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Wichtige Hinweise

Bei der Projektplanung instanziert der Projektleiter einen bestimmten Bereitstellungsprozess (siehe Arbeitsergebnis: Entwicklungsprozess) für das Projekt, dessen Durchführung er anschließend verwaltet. Dies wird häufig auch als Prozessumsetzung bezeichnet.

Ein "instanzierter" Prozess ist ein aktivierbarer Projekt-/Iterations-/Aktivitätsplan (der die eigentlichen Aktivitäten und Arbeitsergebnisse für ein echtes Projekt enthält). Ein Bereitstellungsprozess kann instanziert werden, indem ein Bereitstellungsprozess aus Rational Method Composer in Rational Portfolio Manager (RPM) importiert wird und die Instanzierungsarbeiten anschließend durch Duplizierung von Aktivitäten und Aufgaben mit den Attributen (isRepeatable oder hasMultipleOccurences), Erstellung echter Arbeitsergebnisse, Zuordnung echter Ressourcen zu Rollen usw. durchgeführt werden.

Weitere Informationen