Aufgabe: Phasen und Iterationen planen
Diese Aufgabe beschreibt, wie die Projektphasen und Iterationen geplant werden, was die Zielsetzungen sind, wie die Dauer ist, wie viele Iterationen angesetzt werden usw.
Zweck

Diese Aufgabe hat folgenden Zweck:

  • Gesamtumfang, Aufwand und Kosten für das Projekt schätzen.
  • Groben Plan für das Projekt mit Fokus auf die Hauptmeilensteine und Schlüsselliefergegenstände im Produktlebenszyklus entwickeln.
  • Iterationen für die Projektphasen definieren und Zielsetzungen für jede dieser Iterationen identifizieren.
  • Zeitplan und Budget für das Projekt entwickeln.
  • Ressourcenplan für das Projekt entwickeln.
  • Aufgaben für eine systematische Durchführung des Projekts definieren.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional:
  • Ohne
Extern:
  • Ohne
Ausgaben
Schritte
Projekt schätzen
Zweck Größenordnung für die Arbeiten schätzen, die für die Durchführung des Projekts erforderlich sind.
Optimalen Zeitplan im Rahmen der Projektvorgaben auswählen.  

In der Konzeptionsphase müssen Sie Schätzungen für die Arbeiten vorbereiten, die im Projekt vorgeschlagen werden. Eine allgemeine Diskussion über die Schätzung von Softwareprojekten finden Sie in [BOE81], [PUT92] und [MCO96]). Die Schätzung von Softwareprojekten basiert auf einer komplexen Mathematik. Deshalb werden hier keine detaillierten technischen Hintergründe beschrieben. Die Schätzung ist ein Prozess, der aus vier Schritten besteht:

  1. Produktgröße schätzen.
  2. Gesamtaufwand und -kosten für das Projekt schätzen.
  3. Vorgaben und Prioritäten festlegen (z. B. Anzahl der Mitarbeiter, Lieferdatum, Budget).
  4. Optimale Schätzung für Zeitplan, Aufwand und Kosten auswählen.

Produktgröße schätzen

Dies ist die Schlüsselinformation für den Schätzungsprozess. Wenn die Größenordnung der zu erledigenden Arbeit nicht eingeschätzt werden kann, wird zwischen erstelltem Projektplan und Realität eine große Lücke klaffen. Es gibt zwei Ansätze, um die Größe des Softwareprodukt zu schätzen, die in einem frühen Stadium des Projekts verwendet werden können: Dimensionierung durch Analogie und Dimensionierung durch Analyse. Natürlich können Sie später im Projekt (während der Ausarbeitungsphase) basierend auf einem detaillierten Projektstrukturplan rigorosere Schätzungen vorbereiten.

Dimensionierung durch Analogie

Wenn Sie den Projektumfang mit dem Ansatz "Dimensionierung durch Analogie" schätzen, vergleichen Sie das neu zu entwickelnde Produkt mit Produkten (bekannter Größe), die in früheren Projekten entwickelt wurden. Sie müssen verschiedene Merkmale der Produkte vergleichen, z. B. Anzahl der Geschäftsanwendungsfälle, Datenbankgröße/-komplexität und voraussichtliche Anzahl der Online- und Stapelverarbeitungsprogramme.

Durch den Vergleich dieser Merkmale können Sie die relative Größe des neuen Produkts im Vergleich mit den alten Projekten schätzen. Anschließend können Sie anhand der bekannten Größe des alten Produkts die geschätzte Größe für das neue Produkt berechnen. Beachten Sie bitte, dass es von äußerster Wichtigkeit ist, Produkte ähnlicher Komplexität zu vergleichen, die mit ähnlichen Ansätzen entwickelt wurden. Abweichungen in solchen Dingen wie Detaillierungsgrad von Anwendungsfallbeschreibungen kann Ihren Vergleich wertlos machen.

Dimensionierung durch Analyse

Später in der Konzeptionsphase haben Sie wahrscheinlich genügend Informationen über das neue Produkt zusammengetragen, um Analysetechniken für die Schätzung der Produktgröße zu verwenden. Diese Techniken stützen sich auf eine funktionale Beschreibung des Softwareprodukts (z. B. Spezifikation der Softwareanforderungen, Softwarearchitekturdokument) und wenden Standardregeln für quantitative Erfassung an, um aus diesen Beschreibungen eine Maßzahl für die Größe zu bestimmen. Die wohl bekannteste dieser Techniken ist die quantitative Erfassung von Funktionspunkten (FPC, Function Point Counting), aber es wurden zahlreiche andere Messwerte entwickelt wie Feature-Punkte (Modifikation von Funktionspunkten für die Anwendung in Echtzeitsystemen) und vorhersehbare Objektpunkte (ein Messwert für objektorientierte Systeme, der auf einer Analyse von Klassenkomplexitäten und -hierarchien basiert).  

Auf der IBM Website finden Sie White Paper, die Methoden für die Größenschätzung basierend auf Anwendungsfällen beschreiben. Wenn Sie auf Grundlage dieser White Paper erste Größenschätzungen basierend auf Anwendungsfällen durchführen möchten, müssen Sie Anpassungen an den Stil der Anwendungsfälle Ihrer Organisation vornehmen. Anwendungsfälle können bezüglich Abstraktionsgrad und Beschreibungsstil nicht nur von Organisation zu Organisation, sondern auch innerhalb einer Organisation stark variieren. Nach den Anpassungen ist es wichtig, den ausgewählten Standardstil für das Schreiben von Anwendungsfällen beizubehalten, da die Größenschätzungen andernfalls weit daneben liegen können.

Gesamtprojektaufwand und -kosten schätzen

Der Gesamtpersonalaufwand und der Zeitplan für ein Projekt können unter Verwendung etablierter wissenschaftlicher Modelle aus der geschätzten Produktgröße berechnet werden. Die beiden herausragenden Modelle, die heute eingesetzt werden, sind das Constructive Cost Model (COCOMO) von Barry Boehm und die Putnam Methodology von Larry Putnam. Beide Modelle haben sich bei branchenspezifischen Daten bewährt. Weitere Informationen zur neuesten Version von COCOMO finden Sie auf der COCOMOII-Website.

Die andere Schlüsseleingabe neben der Größe ist ein Messwert für die Teamproduktivität. Dieser Wert bestimmt den Gesamtprojektaufwand. Der Gesamtprojektplan steht in einer nicht linearen Beziehung mit dem Gesamtaufwand. Leider sind die Modelle mathematisch so komplex, dass es sich empfiehlt, Softwaretools als Unterstützung bei den Berechnungen zu verwenden.

Vorgaben und Prioritäten anwenden

Nahezu jedes Projekt unterliegt bestimmten Vorgaben (z. B. Lieferung zu einem bestimmten Termin, oder Kosten dürfen 850.000 Euro nicht überschreiten) oder Prioritäten (z. B. Produkt muss so schnell wie möglich geliefert werden). Diese Vorgaben und Einschränkungen sind bei einer festen Produktgröße von der Teamgröße abhängig. Daraus ergibt sich, dass die Beziehung zwischen Teamgröße und Zeitplan nicht linear ist, also müssen Sie die wissenschaftlichen Modelle verwenden, um eine gewisse Anzahl von Szenarios mit unterschiedlichen Teamgrößen zu generieren. Automatisierte Schätzsoftware ist für diese Übung sehr hilfreich.

Optimalen Zeitplan, Aufwand und Kostenschätzung auswählen

Jetzt, da Sie mehrere Szenarios für das Projekt haben, prüfen und wählen Sie das Szenario aus, das den Anforderungen Ihres Projekts am besten entspricht. Damit erhalten Sie ein erstes Bild der Gesamtdauer des Projekts und der erforderlichen Teamgröße und des erforderlichen Budgets.

Meilensteine für die Projektphasen definieren
Zweck Die Punkte definieren, an denen der Projektfortschritt formal bewertet wird.
Geschätzten Aufwand und geschätzte Kosten auf die einzelnen Phasen verteilen. 

Der Softwareentwicklungsplan definiert zuerst die Termine und die Art der wichtigsten Meilensteine (siehe Phasen). Dieser Teil des Softwareentwicklungsplans dient als "Roadmap" für das Projekt insgesamt und wird zu Beginn des Projekts (Konzeptionsphase) erstellt.

Für die Planung der Phasen für ein Projekt im ersten Entwicklungszyklus müssen Sie möglicherweise einige fundierte Vermutungen über die Meilensteine anstellen, die auf Folgendem basieren:

  • Erfahrung mit ähnlichen Projekten (Art und Domäne),
  • Neuheitsgrad,
  • spezielle Umgebungsvorgaben, z. B. Antwortzeit, Verteilung und Sicherheit,
  • Reife der Organisation.

Anhand von Schätzungen, die auf Ihren eigenen Erfahrungen in anderen ähnlichen Projekten basieren, erstellen Sie das erste Projektbudget, indem Sie die entsprechenden Teile des geschätzten Gesamtaufwands und der geschätzten Gesamtkosten auf die einzelnen Phasen des Projekts verteilen.

Weitere Informationen zum Definieren der Dauer von Iterationen und der Anzahl von Iterationen finden Sie in  Richtlinie: Softwareentwicklungsplan.

Ziele für Meilensteine definieren
Zweck Die Kriterien definieren, nach denen Phasen bewertet werden. 

Jeder Meilenstein konzentriert sich auf einen bestimmten Liefergegenstand und ist ein klar definierter Übergangspunkt zur nächsten Phase.

Phase 
Meilenstein 
Zweck 
Konzeption  Meilenstein 'Zielsetzungen des Lebenszyklus' Ressourcen für das Projekt bereitstellen 
Ausarbeitung  Meilenstein 'Architektur des Lebenszyklus' Produktarchitektur stabilisieren 
Konstruktion  Meilenstein 'Erste Betriebsbereitschaft' Produktentwicklung abschließen 
Meilenstein 'Produkt-Release' Erfolgreiches Deployment des Produkts 

Jeder Meilenstein stellt eine kritische Hürde dar, die das Projekt überwinden muss. An jedem Meilenstein wird darüber entschieden, ob das Projekt fortgesetzt wird oder nicht.

Anzahl, Dauer und Zielsetzungen von Iterationen in Phasen definieren
Zweck Festlegen, wie viele Iterationen für jede Projektphase geplant werden.
Relative Arbeitsverteilung auf die Iterationen festlegen.
Zielsetzungen für die einzelnen Iterationen festlegen. 

Nachdem Sie die Dauer der Projektphasen bestimmt haben, müssen Sie die Anzahl der Iterationen und ihre Dauer bestimmen. Weitere Informationen zum Definieren der Dauer von Iterationen und der Anzahl von Iterationen finden Sie in   Richtlinie: Softwareentwicklungsplan. Es gibt verschiedene Iterationsmuster, die Sie anwenden können und die sich nach dem Typ des Projekts, der Problemdomäne und der Neuheit der Problemdomäne richten (siehe auch Konzept: Iteration).

Jede Iteration produziert einen Liefergegenstand (ein Release), das ein ausführbares Produkt ist, auf dessen Basis Fortschritt und Qualität bewertet werden können. Da jede Iteration einen anderen Fokus hat, variieren Funktionalität und Vollständigkeit der Iterationsliefergegenstände. Iterationsziele müssen so spezifisch sein, dass am Ende der Iteration bewertet werden kann, ob die Iterationsziele erfüllt wurden. In frühen Iterationen werden Ziele gewöhnlich anhand von geminderten Risiken formuliert. In späteren Iterationen werden Ziele mit Messwerten für funktionale Fertigstellung und Qualität beschrieben.

Termine und Umfang für Meilensteine präzisieren
Zweck Die Schätzungen auf der Basis der am Ende der Konzeptionsphase verfügbaren Informationen präzisieren. 

Gegen Ende der Konzeptionsphase können Phasen unter Berücksichtigung folgender Punkte genauer geplant werden:

  • Anzahl der identifizierten Anwendungsfälle
  • Komplexität der bereits untersuchten Anwendungsfälle
  • Identifizierte Risiken (Technik und Geschäft)
  • Funktionspunkt- oder Anwendungsfallmetriken
  • Ergebnis aller Prototyperstellungen.

Dieser sehr grobe Plan wird während der Ausarbeitungsphase aktualisiert. Er dient als Basis für die Erstellung des restlichen Projektplans.

Anforderungen für die Ressourcenbeschaffung für das Projekt bestimmen
Zweck Anzahl und Typen der für das Projekt benötigten Ressourcen nach Phase/Iteration definieren. 

Basierend auf Ihren Aufwandsschätzungen und dem daraus abgeleiteten Projektzeitplan können Sie jetzt die Ressourcen definieren, die für die Durchführung des Projekts erforderlich sind. Geben Sie für jede Phase/Iteration an, welche und wie viele Rollen jeweils einbezogen werden müssen.

Projektabschlussplan entwickeln
Zweck Plan für einen ordnungsgemäßen Abschluss des Projekts entwickeln. 

Der Projektabschlussplan ist in Abschnitt 5.6 Abschlussplan des Softwareentwicklungsplans dokumentiert. Der Projektabschluss setzt sich aus einer Reihe von Aufgaben zusammen, die das Projekt zu einem ordnungsgemäßen Abschluss bringen und sicherstellen, dass alle Metriken und Erkenntnisse für spätere Referenz dokumentiert sind.

Der Abschlussprojekt beginnt, wenn die folgenden Bedingungen erfüllt sind:

  • Alle Projektliefergegenstände sind fertig gestellt und unter Konfigurationssteuerung gespeichert.
  • Der Abnahmetest ist abgeschlossen, und das Produkt wurde formal vom Benutzer abgenommen.
  • Das Produkt wurde formal an den Kunden ausgeliefert.

Abschlussaufgaben definieren

Listen Sie in Ihrem Plan zuerst die Aufgaben auf, die Sie während des Projektabschlusses ausführen. Dazu gehören normalerweise die folgenden:

  • Postmortem-Besprechung zum Projekt abhalten
  • Postmortem-Bericht zum Projekt entwickeln
  • Personalbeurteilungen zum Projektende
  • Archivierung der Projektarbeitsergebnisse
  • Neuzuordnung von Projektmitarbeitern
  • Speicherung der Projektmetriken in der Metrikdatenbank Ihrer Organisationen für künftige Projektschätzungen

Teilnehmer für Abschlussaufgaben identifizieren

Anschließend geben Sie in Ihrem Plan die Personen an, die in die einzelnen Abschlussaufgaben einbezogen werden sollen.

Zeitplan für Abschlussaufgaben definieren

Definieren Sie den Zeitplan für die Abschlussaufgaben. Gewöhnlich wird dieses Detail dem Softwareentwicklungsplan gegen Ende des Projekts hinzugefügt.



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