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.
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
-
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.
-
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.
-
Ä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.
-
Alle Anwendungsfälle in Zusammenhang mit dem Management der Lieferkette abschließen.
In der Ausarbeitungsphase soll auch die Erfassung der Anforderungen abgeschlossen werden.
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
-
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.
-
Alle Telefonzentralen-Features mit Ausnahme des Nachtdienstes fertig stellen.
Eine weitere Gruppe von Features.
-
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.
-
Neue Version eines Geographical Information System integrieren.
Dies kann eine geringfügige Architekturänderung sein, die durch ein zuvor entdecktes Problem erforderlich
wird.
-
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..
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
-
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.
-
Alle Abstürze beim Starten ausmerzen, die auf abweichende Daten zurückzuführen sind.
Ein weiteres Qualitätsziel.
-
2.000 Transaktionen pro Minute erreichen.
Durchsatzverbesserung, einschließlich einiger Optimierungsarbeiten: Änderung der Datenstruktur, Caching
und intelligentere Algorithmen.
-
Anzahl unterschiedlicher Dialogfenster um 30 % reduzieren.
Benutzerfreundlichkeit durch Steigerung der Übersichtlichkeit von Anzeigen verbessern.
-
Deutsche und japanische Versionen produzieren.
Die Betaversion wurde aus Zeitmangel und zur Verringerung von Nacharbeiten nur für Englisch sprechende
Kunden produziert.
|