Course Registration System (CREG)
Softwareentwicklungsplan
Version 1.0
Revisionsprotokoll
Datum |
Version |
Beschreibung |
Autor |
---|---|---|---|
15. Januar 99 |
1.0 |
Erste Version |
Rick Bell |
|
|
|
|
|
|
|
|
|
|
|
|
1.3 Definitionen, Akronyme und Abkürzungen
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.3 Rollen und Zuständigkeiten
4.1 Einschätzung der Projektkosten und des Zeitrahmens
4.2.2 Zielsetzung der Iterationen
4.2.5 Ressourcenbeschaffung für das Projekt
4.2.5.1 Plan für Mitarbeiterauswahl
4.2.5.2 Ressourcenbeschaffungsplan
4.4 Projektüberwachung und -kontrolle
4.4.1 Plan für das Anforderungsmanagement
4.4.5 Plan für Berichterstellung
5.2 Methoden, Tools und Verfahren
6. Unterstützende Prozesspläne
Softwareentwicklungsplan
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.
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.
Siehe Glossar [4]
Verfügbare Referenzen:
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.
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.
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.
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.
Der Softwareentwicklungsplan wird vor Beginn jeder Iterationsphase überarbeitet.
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.
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. |
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.
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.
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. |
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.
Nachfolgend sehen Sie eine Übersicht über die Zeitplanung für die Projektphasen, Iterationen und Meilensteine, die im CREG-Projektzeitplan [5] enthalten ist.
|
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.
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.
Vor Beginn der Designaktivitäten werden für das Team Schulungen zu folgenden Wissengebieten durchgeführt:
Das Budget des Projekts auf der Basis der ersten Kosteneinschätzung
Siehe Iterationsplan für A1 [11] für das Course Registration System
Die Anforderungen für dieses System sind im Visionsdokument [1] und im Dokument mit den Stakeholder-Anfragen [3] erfasst.
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.
Die Ausgaben werden vom Projektmanager überwacht und im Statusbewertungsbericht angegeben und beurteilt.
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.
Der Statusbewertungsbericht wird mindestens einmal monatlich vom Projektmanager erstellt und enthält Folgendes:
- aktualisierte Einschätzung der Kosten und des Zeitrahmens
- Zusammenfassung der Metriken
Die auf der Website des Wylie College zum Softwareprozess [10] beschriebenen Standardmetriken des Projekts werden zusammengestellt und in den Statusbewertungsbericht aufgenommen.
Siehe CREG-Liste der Risiken [8]
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.
Siehe Entwicklungsfall zum CREG-System [9]
Siehe Website des Wylie College zum Softwareprozess [10]
Nicht anwendbar
Nicht anwendbar
Siehe Website des Wylie College zum Softwareprozess [10]
Nicht anwendbar
Nicht anwendbar
Nicht anwendbar