Course Registration System (CREG)

Softwareentwicklungsplan

 

Version 1.0

 


Revisionsprotokoll

Datum

Version

Beschreibung

Autor

15. Januar 99

1.0

Erste Version

Rick Bell

 

 

 

 

 

 

 

 

 

 

 

 

 


Inhaltsverzeichnis

1.         Einführung         

1.1     Verwendungszweck     

1.2     Inhalt und Umfang     

1.3     Definitionen, Akronyme und Abkürzungen     

1.4     Referenzen     

1.5     Übersicht     

2.          Projektübersicht      

2.1      Zweck, Inhalt und Umfang und Zielsetzung des Projekts     

2.2      Annahmen und Einschränkungen     

2.3      Arbeitsergebnisse des Projekts     

2.4      Weiterentwicklung des Softwareentwicklungsplans     

3.          Projektorganisation  

3.1      Organisationsstruktur     

3.2      Externe Schnittstellen     

3.3      Rollen und Zuständigkeiten     

4.          Managementprozess

4.1      Einschätzung der Projektkosten und des Zeitrahmens     

4.2      Projektplan     

4.2.1       Phasenplan      

4.2.2       Zielsetzung der Iterationen

4.2.3       Releases      

4.2.4       Projektzeitplan 

4.2.5       Ressourcenbeschaffung für das Projekt      

              4.2.5.1       Plan für Mitarbeiterauswahl      

              4.2.5.2       Ressourcenbeschaffungsplan      

              4.2.5.3       Schulungsplan      

4.2.6       Budget      

4.3      Iterationspläne     

4.4      Projektüberwachung und -kontrolle     

4.4.1       Plan für das Anforderungsmanagement      

4.4.2       Terminkontrollplan      

4.4.3       Budgetkontrollplan      

4.4.4       Qualitätskontrollplan      

4.4.5       Plan für Berichterstellung      

4.4.6       Messplan      

4.5      Risikomanagementplan     

4.6      Abschlussplan     

5.          Technische Prozesspläne 

5.1      Entwicklungsfall     

5.2      Methoden, Tools und Verfahren     

5.3      Infrastrukturplan     

5.4      Produktabnahmeplan     

6.          Unterstützende Prozesspläne 

7.          Weitere Pläne 

8.          Anhänge 

9.          Index     


Softwareentwicklungsplan

 

1.                   Einführung 

1.1               Verwendungszweck

Die Zielsetzung dieses Softwareentwicklungsplans ist es, die Entwicklungsaktivitäten für die Phasen und Iterationen zu definieren, die für die Implementierung eines computergestützten Kursregistrierungssystems am Wylie College erforderlich sind.

1.2               Inhalt und Umfang

Dieser Softwareentwicklungsplan ist der generelle Plan, auf den sich der Fachbereich IT am Wylie College bei der Entwicklung des CREG-Systems für das Wylie College stützt. Die Details der einzelnen Iterationen sind in den Iterationsplänen beschrieben.
Die in diesem Dokument genannten Pläne basieren auf den Produktanforderungen, die im Visionsdokument [1] definiert sind.

1.3               Definitionen, Akronyme und Abkürzungen

Siehe Glossar [4]

1.4               Referenzen

Verfügbare Referenzen:

    1. Course Registration System, Vision (WyIT387) Version 1.0, Wylie College IT
    2. Course Registration System, Kosten-Nutzen-Analyse WyIT388 (ENTWURF), 1998, Wylie College IT
    3. Course Registration System, Dokument mit Stakeholder-Anfragen (WyIT389) Version 1.0, 1998, Wylie College IT
    4. Course Registration System, Glossar (WyIT406) Version 1.0, 1998, Wylie College IT
    5. Course Registration System, grober Terminplan für das Projekt Version 1.0, 1999, Wylie College IT
    6. Rational Unified Process, 1999, Rational Software Corp.
    7. Course Registration System, Bericht zu Kostenmodell und -analyse (WylIT390) Version 1.0 Wylie College IT
    8. Course Registration System, Risikoliste (WyIT389) Version 1.0, Wylie College IT
    9. Course Registration System, Entwicklungsfall (WyIT390) Version 1.0, Wylie College IT
    10. Course Registration System, Iterationsplan, Ausarbeitungsiteration A1 (WyIT391) Version 1.0, Wylie College IT

1.5               Übersicht

Dieser Softwareentwicklungsplan enthält folgende Informationen:

Die Projektübersicht enthält eine Beschreibung des Verwendungszwecks, des Inhalts und Umfangs sowie der Zielsetzung des Projekts. Sie definiert außerdem die Arbeitsergebnisse, die das Projekt bereitstellen soll.

Im Abschnitt zur Projektorganisation ist die Organisationsstruktur des Projektteams beschrieben.

Die Beschreibung zum Managementprozess erläutert die geschätzten Kosten und den geschätzten Zeitaufwand, definiert die wichtigsten Phasen und Meilensteine für das Projekt und beschreibt die Überwachung des Projekts.

Die technischen Prozesspläne geben einen Überblick über den Softwareentwicklungsprozess und die zu anzuwendenden Methoden, Tools und Verfahren.

Zu den unterstützenden Prozessplänen gehört unter anderem der Konfigurationsmanagementplan.  

2.                  Projektübersicht

2.1               Zweck, Inhalt und Umfang und Zielsetzung des Projekts

Dieser Softwareentwicklungsplan ist der generelle Plan, auf den sich der Fachbereich IT am Wylie College bei der Entwicklung des CREG-Systems für das Wylie College stützt. Die Details der einzelnen Iterationen sind in den Iterationsplänen beschrieben.

Die in diesem Dokument genannten Pläne basieren auf den Produktanforderungen, die im Visionsdokument [1] definiert sind.

2.2               Annahmen und Einschränkungen

Das System soll die Hauptlösung für die Registrierung der Studenten des Herbstsemesters 1999 werden. Da die Registrierung für Kurse bereits am 1. August 1999 beginnt, muss das System bis dahin vollständig verfügbar sein.

2.3               Arbeitsergebnisse des Projekts

Während des Projekts werden die folgenden Arbeitsergebnisse erzeugt und an die Verwaltungsorganisation geliefert.

Darüber hinaus werden die im Entwicklungsfall des Projekts beschriebenen Arbeitsergebnisse erzeugt, die jedoch nicht an die Verwaltungsorganisation geliefert werden.

2.4               Weiterentwicklung des Softwareentwicklungsplans

Der Softwareentwicklungsplan wird vor Beginn jeder Iterationsphase überarbeitet.

3.                  Projektorganisation

3.1               Organisationsstruktur

3.2               Externe Schnittstellen

Der Projektmanager gibt dem IT-Entscheidungsträger (Stakeholder) wie in diesem Plan vorgesehen eine Statusbewertung (siehe Vision [1]).

Das Projektteam interagiert mit anderen Stakeholdern, um die Vorgaben für wichtige Arbeitsergebnisse zu erfragen und deren Überprüfung abzustimmen.

3.3               Rollen und Zuständigkeiten

Die folgende Tabelle listet die Organisationseinheiten auf, die für die einzelnen Disziplinen, Aktivitäten und Unterstützungsprozesse des Projekts verantwortlich sind.

Rolle

Zuständigkeit

Projektmanager

Siehe Beschreibung im Rational Unified Process [6. Verantwortlich für die gesamte Disziplin des Projektmanagements. Leitet das erweiterte Projektmanagementteam.

Prozessentwickler Zuständig für die Projektumgebung und die prozessbezogene Unterstützung der Projektteams, wie in der Disziplin 'Umgebung' des Rational Unified Process definiert. Gehört zum erweiterten Projektmanagementteam.
Konfigurationsmanager / Änderungsmanager Verantwortlich für die Konfigurationssteuerung des Projekts und für den Änderungsanfrageprozess am Wylie College. Gehört zum erweiterten Projektmanagementteam.

Leiter des Systementwicklerteams

Leitet das Team, das in erster Linie für das Management der Disziplinen 'Erstellung von Geschäftsmodellen' und 'Anforderungen' verantwortlich ist. Gehört zum erweiterten Projektmanagementteam. 

Leiter des Software-Engineering-Teams

Vorrangig für die Disziplinen 'Analyse und Design' und 'Implementierung' verantwortlich. Gehört zum erweiterten Projektmanagementteam.

Leiter des Testteams

Leitet das Team, das für die Disziplin 'Test' verantwortlich ist. Gehört zum erweiterten Projektmanagementteam.  

Leiter des Deployment-Teams Leitet das Team, das für die Installation und Infrastruktur in der Endbenutzerumgebung verantwortlich ist.   Gehört zum erweiterten Projektmanagementteam.  

 

4.                  Managementprozess

4.1               Einschätzung der Projektkosten und des Zeitrahmens

Die Einschätzung der Projektkosten und des Zeitrahmens basieren auf dem Kostenmodell und dem Analysebericht zum CREG-System [7].

Das Course Registration System ist in seiner Komplexität und Architektur mit dem Onlinebibliothekssystem vergleichbar, das im Jahr 1997 vom Wylie College erstellt wurde. Die Komplexität der Datenbank für das Kursregistrierungssystem liegt um ungefähr 25 % höher. Anzahl und Komplexität der Anwendungsfälle legen nahe, dass die Gesamtkomplexität des Systems um ca. 20 % erhöht sein wird. Der veranschlagte Zeitrahmen und die Aufwandsschätzungen aus diesem Bericht bilden die Basis für das Budget und den Zeitplan des Projekts.

4.2               Projektplan

4.2.1          Phasenplan

Es wird ein Projektstrukturplan erstellt und in der nächsten Version dieses Dokuments bereitgestellt.

Die Entwicklung des CREG-Systems folgt einem Stufenplan, der Phasen mit jeweils mehreren Iterationen umfasst. Die Phasen und Iterationen in diesem Plan überschneiden sich nicht. In der folgenden Tabelle ist die entsprechende Zeitplanung zusammengefasst:

Phase

Anzahl der Iterationen

Ende

Konzeptionsphase

1

KW 7

Ausarbeitungsphase

1

KW 14

Konstruktionsphase

1

KW 19

Übergangsphase

4

KW 32

Tabelle 4.2.1 Zusammenfassung der Zeitplanung

In Tabelle 4.2.2 sind die einzelnen Phasen beschrieben und die wichtigsten Meilensteine angegeben, die den Abschluss der jeweiligen Phase markieren.

 

Phase

Beschreibung

Meilenstein

Konzeptionsphase

In der Konzeptionsphase werden die Produktanforderungen entwickelt und die Kosten-Nutzen-Analyse für das CREG-System erstellt. Es werden die wichtigsten Anwendungsfälle und der grobe Umriss des Softwareentwicklungsplans entwickelt. Am Ende der Konzeptionsphase wird das Wylie College ausgehend von der Kosten-Nutzen-Analyse entscheiden, ob das Projekt finanziert und fortgesetzt werden kann.

Überprüfung der Kosten-Nutzen-Analyse am Ende der Phase ist der Meilenstein für die Entscheidung für oder gegen das Projekt.

Ausarbeitungsphase

In der Ausarbeitungsphase werden die Anforderungen analysiert und der Architekturprototyp erstellt. Am Ende der Ausarbeitungsphase werden Analyse und Design für alle Anwendungsfälle von Release 1.0 abgeschlossen sein. Zusätzlich werden die mit hohen Risiken behafteten Anwendungsfälle von Release 2.0 analysiert und entworfen sein. Mit dem Architekturprototyp wird die Realisierbarkeit und Leistung der für Release 1.0 erforderlichen Architektur getestet.

Der Architekturprototyp markiert das Ende der Ausarbeitungsphase. Anhand dieses Prototyps werden die wichtigsten Komponenten der Architektur für das Release 1.0 überprüft.

Konstruktionsphase

Während der Konstruktionsphase werden die verbleibenden Anwendungsfälle analysiert und entworfen. Die Betaversion für Release 1.0 wird entwickelt und zur Bewertung verteilt. Die Implementierungs- und Testarbeiten zur Unterstützung der Releases 1.0 und 2.0 werden abgeschlossen.

Die erste betriebsbereite Version (fertig gestellte Betaversion) markiert das Ende der Konstruktionsphase.

Übergangsphase

Die Betaversion für Release 1.0 wird verteilt und bewertet. In der Übergangsphase werden die Releases 1.0 und 2.0 zur Verteilung erstellt. Die Unterstützung in dieser Phase stellt eine reibungslose Installation und Benutzerschulung sicher.

Das Release 2.0 markiert das Ende der Übergangsphase. An diesem Punkt sind alle im Visionsdokument [1] definierten Leistungsmerkmale installiert und für die Benutzer verfügbar.

Tabelle 4.2.2 Projektphasen und wichtige Meilensteine

Jede Phase umfasst mehrere Entwicklungsiterationen, die im Abschnitt 4.3 beschrieben sind.

Abschnitt 4.2.4 enthält einen groben Projektzeitplan für die Phasen, Iterationen und wichtigsten Meilensteine.

4.2.2          Zielsetzung der Iterationen

Jede Phase besteht aus Entwicklungsiterationen, in denen jeweils ein Teil des Systems entwickelt wird. Diese Iterationen haben folgende allgemeine Zielsetzung:

In der folgenden Tabelle sind die Iterationen mit den zugehörigen Meilensteinen und anzugehenden Risiken beschrieben.

Phase

Iteration

Beschreibung

Zugeordnete Meilensteine

Anzugehende Risiken

Konzeptionsphase

Vorläufige Iteration

Geschäftsmodell, Produktanforderungen, Softwareentwicklungsplan und Kosten-Nutzen-Analyse definieren

Überprüfung der Kosten-Nutzen-Analyse

Benutzeranforderungen vorab klären

Realistische Softwareentwicklungspläne mit realistischem Inhalt und Umfang entwickeln

Durchführbarkeit des Projekts aus geschäftlicher Sicht bestimmen

Ausarbeitungsphase

Iteration A1 - Architekturprototyp entwickeln

Analyse und Design für alle mit hohem Risiko behafteten Anforderungen abschließen und Architekturprototyp entwickeln

 

Architekturprototyp

Fragen zur Architektur klären

Technische Risiken reduziert

Frühes Stadium des Prototyps zur Überprüfung durch die Benutzer

Konstruktionsphase

Iteration Kt1 - Betaversion für R1 entwickeln

Schlüsselanforderungen für Release 1 implementieren und testen, um die Betaversion für R1 bereitzustellen

 

Möglichkeit der Freigabe des Release für die Betatests beurteilen

Erste Stufe der Betriebsbereitschaft (Code für Betaversion von R1 vollständig)

Alle Schlüsselfeatures aus Sicht der Benutzer und der Architektur sind in der Betaversion implementiert.

 

 

Übergangsphase

Iteration Ü1 - Entwicklung/Deployment von Release 1.0

Deployment der Betaversion für R1

Mängel der Betaversion beseitigen und Feedback zur Betaversion einarbeiten

 

Verbleibende Anforderungen für R1 implementieren und testen

Paket für Release 1 erstellen, verteilen und installieren

Ausführliche Beschreibung der verbleibenden Anwendungsfälle mit niedrigem Risiko für R2

Betatest für R1 abgeschlossen

 

Code für R1 vollständig

 

Produktfreigabe für R1

Benutzerfeedback vor der Freigabe von R1

 

Die Produktqualität sollte hoch sein.

Mängel auf ein Minimum reduziert

Qualitätskosten reduziert

Mängel durch zweistufiges Release minimiert

Das zweistufige Release erleichtert den Übergang für die Benutzer.

R1 vollständig von der Benutzergemeinde überprüft

 

Iteration Ü2 - Entwicklung der internen Fassung von R2

Design für die interne Version 1 von R2 erstellen, implementieren und testen

Funktionale Erweiterungen integrieren und Mängel von R1 beseitigen

Deployment der internen Version 1 von R2

Test der internen Version 1 von R2 abgeschlossen

Ggf. könnte die interne Version 1 von R2 freigegeben werden, um die Mängel von R1 zu beseitigen und den Kunden zufriedenzustellen.

 

Iteration Ü3 - Entwicklung der internen Fassung 2 von R2

Design für die interne Version 2 von R2 erstellen, implementieren und testen

Funktionale Erweiterungen integrieren und Mängel der internen Version 2 von R2 beseitigen

Deployment der internen Version 2 von R2

Test der internen Version 2 von R2 abgeschlossen

Interne Version 1 von R2 inoffiziell von der Benutzergemeinde geprüft

 

Ggf. könnte die interne Version 1 von R2 freigegeben werden, um die Mängel von R1 zu beseitigen und den Kunden zufriedenzustellen.

 

Iteration Ü4 - Entwicklung/Deployment von Release 2

Paket für Release 2 erstellen, verteilen und installieren

Code für R2 vollständig

 

Produktfreigabe für R2

Interne Version 2 von R2 inoffiziell von der Benutzergemeinde geprüft

Das zweistufige Release erleichtert den Übergang für die Benutzer.

 

4.2.3          Releases

Dieser Softwareentwicklungsplan gilt für die beiden ersten Releases des CREG-Systems. Die im Visionsdokument [1] definierten Schlüsselfeatures sind für die ersten beiden Releases anvisiert. Alle für die Studentenregistrierung kritischen Features sind für das erste Release (R 1.0) geplant.

Der geplante Inhalt der Releases kann sich mit Fortschreiten des Projektprozesses aufgrund geschäftlicher und technischer Faktoren ändern. Für die Aufnahme solcher Änderungen wird Rational RequisitePro verwendet. Mit diesem Tool können die Produktanforderungen verwaltet und der Releaseinhalt verfolgt werden. Die Priorität der Produktanforderungen und somit des Zielrelease wird nach Erwägung des erzielbaren Nutzens, des Aufwands und der Risikoattribute bestimmt.

Es ist vorgesehen, das CREG-System in 2-4 Releases zur allgemeinen Verwendung am Wylie College freizugeben.

Release 1 muss mindestens die nachfolgend aufgelisteten Basisfunktionen umfassen:

Release 2 sollte folgende Funktionen umfassen:

Die Funktionalität für Release 3 wurde noch nicht festgelegt. Es ist vorgesehen, mit diesem Release Verbesserungen und Erweiterungen der vorhandenen Funktionalität bereitzustellen.

Eine Ersetzung des herkömmlichen Gebührenabrechnungssystems und Kursdatenbanksystems ist für Release 4 im Jahr 2005 anvisiert.

Vor Release 1.0 wird es eine Betaversion mit allen Schlüsselfunktionen für R 1.0 geben. Die Betaversion wird wie das reale System implementiert werden, allerdings nur mit einer isolierten Kopie der vorhandenen traditionellen Systeme interagieren, um eine Unterbrechung des Betriebs dieser Systeme zu vermeiden. Eine ausgewählte Gruppe von Studenten und Fakultätsmitarbeitern wird gebeten, die Betaversion zu beurteilen.

Darüber hinaus wird es nach dem ersten offiziellen Release interne Versionen geben, um die Kontinuität der Arbeiten am Projekt zu gewährleisten. Die internen Versionen können inoffiziell von Studenten und Fakultätsmitarbeitern geprüft werden. Nachfolgend sind die Zielsetzungen der internen Versionen kurz zusammengefasst:

Die Funktionalität für Release 3 wurde noch nicht festgelegt. Es ist vorgesehen, mit diesem Release Verbesserungen und Erweiterungen der vorhandenen Funktionalität bereitzustellen.

Eine Ersetzung des herkömmlichen Gebührenabrechnungssystems und Kursdatenbanksystems ist für Release 4 im Jahr 2005 anvisiert.

4.2.4          Projektzeitplan

Nachfolgend sehen Sie eine Übersicht über die Zeitplanung für die Projektphasen, Iterationen und Meilensteine, die im CREG-Projektzeitplan [5] enthalten ist.

Projektzeitplan

Datum

Konzeptionsphase

 

Vorläufige Iteration (Beginn)

Dienstag, 1.12.98

Meilenstein 'Überprüfung der Kosten-Nutzen-Analyse' (Ende der Konzeptionsphase)

Dienstag, 19.1.99

Ausarbeitungsphase

 

Iteration A1 - Architekturprototyp entwickeln

 

Meilenstein 'Architekturprototyp' (Ende der Ausarbeitungsphase)

Dienstag, 9.3.99

Konstruktionsphase

 

Iteration Kt1 - Betaversion für Release 1 entwickeln

 

Meilenstein 'Erste Stufe der Betriebsbereitschaft' (Code für Betaversion von R1 vollständig)

Freitag, 9.4.99

Übergangsphase

 

Iteration Ü1 - Entwicklung/Deployment von Release 1

 

Betatest für R1 abgeschlossen

Freitag, 16.4.99

Code für R1 vollständig

Freitag, 30.4.99

Produktrelease R1 (Ende von Ü1)

Freitag, 7.5.99

Iteration Ü2 - Entwicklung der Betaversion 1 von Release 2

 

Test der internen Fassung 1 von R2 abgeschlossen (Ende von Ü2)

Freitag, 28.5.99

Iteration Ü3 - Entwicklung der Betaversion 2 von Release 2

 

Test der internen Fassung 2 von R2 abgeschlossen (Ende von Ü3)

Freitag, 18.6.99

Iteration Ü4 - Entwicklung/Deployment von Release 2

 

Code für R2 vollständig

Freitag, 2.7.99

Produktfreigabe für R2 (Projektabschluss)

Freitag, 9.7.99

4.2.5          Ressourcenbeschaffung für das Projekt

4.2.5.1     Plan für Mitarbeiterauswahl

Dem Projekt werden die IT-Mitarbeiter zugeteilt, die im Organisationsdiagramm im Abschnitt 8.1 angegeben sind. Weitere Personalressourcen sind bis zur Überprüfung der Kosten-Nutzen-Analyse am Ende der Konzeptionsphase nicht erforderlich, da erst dann eine definitive Entscheidung für oder gegen das Projekt getroffen wird.

Die Testorganisation ist auf die Unterstützung durch das Software-Engineering angewiesen. Dies ist im Organisationsdiagramm als gepunktete Linie angegeben.

4.2.5.2     Ressourcenbeschaffungsplan

Der Fachbereich IT des Wylie College verfügt über genug Entwickler und Designer für das Projekt. Die Personalabteilung des Wylie College ist informiert und wird ggf. einen Entwickler mit mehrjähriger C++-Erfahrung, einen erfahrenen Systemintegrator und zwei Implementierer/Tester (Nachwuchskräfte) mit mindestens einem Jahr C++-Erfahrung einstellen.

4.2.5.3     Schulungsplan

Vor Beginn der Designaktivitäten werden für das Team Schulungen zu folgenden Wissengebieten durchgeführt:

4.2.6          Budget

 

Das Budget des Projekts auf der Basis der ersten Kosteneinschätzung

4.3               Iterationspläne

Siehe Iterationsplan für A1 [11] für das Course Registration System

4.4               Projektüberwachung und -kontrolle

4.4.1          Plan für das Anforderungsmanagement

Die Anforderungen für dieses System sind im Visionsdokument [1] und im Dokument mit den Stakeholder-Anfragen [3] erfasst.

4.4.2          Terminkontrollplan

Der Projektmanager führt einen zusammengefassten Zeitplan mit den vorgesehenen Terminen für die einzelnen Meilensteine, der - wie im Plan für Berichterstellung definiert - Teil des Statusbewertungsberichts ist. Der Statusbewertungsbericht wird dem IT-Entscheidungsträger vorgelegt, der dann ggf. neue Prioritäten setzen oder Korrekturmaßnahmen empfehlen kann.

Der zusammengefasste Zeitplan wird aus einem detaillierten Plan abgeleitet, den die Teammanager verwalten. Die Positionen in dem detaillierten Plan sind Arbeitspakete, die Personen zugeteilt sind. Jede dieser Personen meldet ihrem Teammanager wöchentlich den prozentualen Stand der Erledigung.

4.4.3          Budgetkontrollplan

Die Ausgaben werden vom Projektmanager überwacht und im Statusbewertungsbericht angegeben und beurteilt.

4.4.4          Qualitätskontrollplan

Alle Arbeitsergebnisse müssen den vorgesehenen Überprüfungsprozess durchlaufen. Die Prüfungen sollen sicherstellen, dass jedes Arbeitsergebnis eine annehmbare Qualität hat. Vorgaben für diese Prüfungen sind in den Prüfrichtlinien und Prüflisten zum Rational Unified Process [6] beschrieben.

Zusätzlich werden Mängel registriert und überwacht. Die Mängel-Metriken werden wie auf der Website des Wylie College zum Softwareprozess [10] beschrieben zusammengestellt.

4.4.5          Plan für Berichterstellung

Der Statusbewertungsbericht wird mindestens einmal monatlich vom Projektmanager erstellt und enthält Folgendes:

    - aktualisierte Einschätzung der Kosten und des Zeitrahmens

    - Zusammenfassung der Metriken

4.4.6          Messplan

Die auf der Website des Wylie College zum Softwareprozess [10] beschriebenen Standardmetriken des Projekts werden zusammengestellt und in den Statusbewertungsbericht aufgenommen.

4.5               Risikomanagementplan

Siehe CREG-Liste der Risiken [8]

4.6               Abschlussplan

Der Plan beschreibt die schrittweise Freisetzung von Mitarbeitern für andere Projekte. Nach der Auslieferung des Produkts wird das System von mindestens einem Entwickler des Fachbereichs IT in Teilzeit betreut.

Der IT-Entscheidungsträger erhält einen Abschlussbericht, der die gesammelten Projekterfahrungen zusammenfasst und den veranschlagten Kosten- und Zeitaufwand den tatsächlichen Kosten und Terminen gegenüberstellt.

5.                  Technische Prozesspläne

5.1               Entwicklungsfall

Siehe Entwicklungsfall zum CREG-System [9]

5.2               Methoden, Tools und Techniken

Siehe Website des Wylie College zum Softwareprozess [10]

5.3               Infrastrukturplan

Nicht anwendbar

5.4               Produktabnahmeplan

Nicht anwendbar

6.                  Unterstützende Prozesspläne

Siehe Website des Wylie College zum Softwareprozess [10]

7.                  Weitere Pläne

Nicht anwendbar

8.                  Anhänge

Nicht anwendbar

9.                  Index

Nicht anwendbar