Collegiate Sports Paging System
Softwareentwicklungsplan
Version 1.0
Revisionsprotokoll
Datum |
Version |
Beschreibung |
Autor |
---|---|---|---|
5. Oktober 1999 | 1.0 | Erstes Release | Kontextintegration |
Der Zweck dieses Softwareentwicklungsplans ist, die Entwicklungstätigkeiten hinsichtlich der Phasen und Iterationen zu definieren, die erforderlich sind, um einen Collegiate Sports Paging Service für WebNewsOnLine zu implementieren.
Dieser Softwareentwicklungsplan beschreibt den Gesamtplan, der vom Team zur Entwicklung des Systems verwendet wurde. Die Details der einzelnen Iterationen werden in den Iterationsplänen beschrieben.
Keine.
Dieses Projekt wird ein für WebNewsOnLine angepasstes System implementieren. Dieser Service soll Abonnenten über Pager, Mobiltelefon oder per E-Mail über aktualisierte Inhalte benachrichtigen. Die Abonnenten werden dann in der Lage sein, ihren angepassten Inhalt über das World Wide Web anzuzeigen.
Das System muss bis zum März des Jahres 2000, d. h. bis zur NCAA-Meisterschaft, verfügbar sein.
Während des Projekts werden die folgenden Liefergegenstände erstellt:
Dieser Plan wird vor jeder nachfolgenden Phase oder Iteration aktualisiert. Die Zieltermine für das Ende der einzelnen Phasen sind unten aufgelistet.
Das Projektteam für die Konzeptions- und die Ausarbeitungsphase ist wie folgt organisiert:
Das Projektteam arbeitet mit den Teams der Bereiche Bearbeitung, Werbung und Kundendienst zusammen, um Anforderungen zu erarbeiten, Prototypen zu prüfen und verschiedene Funktionen im System zu testen. Die erste Ansprechpartnerin für WebNewsOnLine ist Donna Cram, Leiterin des operativen Geschäfts.
Die folgende Tabelle zeigt die Rollen, die im Projektdiagramm oben dargestellt sind, und deren Zuständigkeiten.
Rolle | Zuständigkeit |
---|---|
Projektleiter | Der Projektleiter ordnet Ressourcen zu, legt Prioritäten fest, koordiniert Interaktionen mit den Kunden und Benutzern und versucht im Allgemeinen, die Aktivität des Projektteams auf das richtige Ziel auszurichten. Der Projektleiter hat außerdem die Aufgabe, bestimmte Verfahren festzulegen, die die Integrität und Qualität von Projektartefakten gewährleisten. |
Architekt | Der Architekt führt und koordiniert technische Aktivitäten und Artefakte während des gesamten Projekts. Er legt die Gesamtstruktur für jede Architektursicht fest: die Aufteilung der Sicht, die Gruppierung von Elementen und die Schnittstellen zwischen diesen Hauptgruppierungen. Daher geht die Sichtweise des Architekten im Gegensatz zu den anderen Mitarbeitern in die Breite und nicht in die Tiefe. |
Geschäftsanalytiker | Der Geschäftsanalytiker führt und koordiniert den Einsatz von Geschäftsanwendungsfallmodellen, indem er die Organisation, auf die die Modelle sich beziehen, umreißt und begrenzt. Dazu legt er beispielsweise fest, welche Geschäftsakteure und Geschäftsanwendungsfälle existieren und wie sie interagieren. |
Designer | Der Designer definiert die Zuständigkeiten, Operationen, Attribute und Beziehungen einer oder mehrerer Klassen und legt fest, wie sie an die Implementierungsumgebung angepasst werden sollten. Darüber hinaus kann der Designer für ein oder mehrere Designpakete oder Designsubsysteme einschließlich aller ihnen eigenen Klassen zuständig sein. |
Kreativdesigner | Der Kreativdesigner leitet und koordiniert die Prototyperstellung und das Design der Webschnittstelle. Dies umfasst verschiedene Aktivitäten: Anforderungen der Webschnittstelle unter Berücksichtigung der Benutzerfreundlichkeit erfassen, Prototypen einzelner Webseiten erstellen, andere Stakeholder der Webschnittstelle (z. B. Endbenutzer) in Überprüfungen des Bedienkomforts einbeziehen, Testsitzungen durchführen, Feedback anderer Entwickler (z. B. Designer und Spezialisten für Implementierung) zur endgültigen Implementierung der Webschnittstelle prüfen und bereitstellen. |
Tester | Der Tester ist zuständig für die Konfiguration und die Ausführung der Tests, die Bewertung der Testdurchführung und die Fehlerbehebung sowie die Bewertung der Testergebnisse und die Protokollierung der ermittelten Mängel. |
Spezialist für Anforderungen | Der Spezialist für Anforderungen erfasst die Spezifikation eines Teils der Systemfunktionen, indem er den Anforderungsaspekt eines oder mehrerer Anwendungsfälle und andere unterstützende Softwareanforderungen erfasst. Er ist auch zuständig für ein Anwendungsfallpaket und dafür, die Integrität dieses Pakets aufrechtzuerhalten. |
Die Konzeptionsphase dieses Projekts nimmt 3 Wochen in Anspruch. Erste Schätzungen der nachfolgenden Phasen können in Abschnitt 2.4 nachgelesen werden.
Die Konzeptionsphase des Projekts kann wie folgt angezeigt werden:
Aufgabe |
Start |
Ende |
---|---|---|
KONZEPTION | Freitag, 01.10.99 | Montag, 25.10.99 |
Beginn der Konzeption | Freitag, 01.10.99 | Freitag, 01.10.99 |
Einstiegsphase der Konzeption | Montag, 04.10.99 | Mittwoch, 06.10.99 |
Aufgaben zu Projektplan für spezifische Projekttechnologie mit ContextWISE-Kassetten hinzufügen | Montag, 04.10.99 | Montag, 04.10.99 |
Change Control Board zusammenrufen | Montag, 04.10.99 | Dienstag, 05.10.99 |
Plan für das Änderungsmanagement erstellen und Referenzversion erstellen | Dienstag, 05.10.99 | Dienstag, 05.10.99 |
Freigabe erhalten | Dienstag, 05.10.99 | Dienstag, 05.10.99 |
Erste Besprechung zur Konzeption | Dienstag, 05.10.99 | Mittwoch, 06.10.99 |
Erste Besprechung zur Konzeption vorbereiten | Dienstag, 05.10.99 | Mittwoch, 06.10.99 |
Erste Besprechung zur Konzeption abhalten | Mittwoch, 06.10.99 | Mittwoch, 06.10.99 |
Einstiegsphase der Konzeption abgeschlossen | Mittwoch, 06.10.99 | Mittwoch, 06.10.99 |
Konzeptionsliefergegenstände | Mittwoch, 06.10.99 | Donnerstag, 14.10.99 |
Workshop zu Anforderungen abhalten | Mittwoch, 06.10.99 | Donnerstag, 07.10.99 |
Projektvision erstellt, überprüft und freigegeben | Mittwoch, 06.10.99 | Donnerstag, 07.10.99 |
Vorläufiges Anwendungsfallmodell (10 bis 20 % abgeschlossen) erstellt und der Überarbeitungskontrolle unterstellt | Donnerstag, 07.10.99 | Montag, 11.10.99 |
Vorläufige Übersicht über Anwendungsfälle erstellt, überprüft und freigegeben | Montag, 11.10.99 | Dienstag, 12.10.99 |
Vorläufige ergänzende Spezifikationen erstellt, überprüft und freigegeben | Dienstag, 12.10.99 | Dienstag, 12.10.99 |
Kosten-Nutzen-Analyse erstellt, überprüft und freigegeben | Dienstag, 12.10.99 | Dienstag, 12.10.99 |
Vorläufiges Projektglossar erstellt, überprüft und freigegeben | Dienstag, 12.10.99 | Dienstag, 12.10.99 |
Vorläufige Kurzinfo zum Kreativdesign erstellt, überprüft und freigegeben | Mittwoch, 06.10.99 | Donnerstag, 07.10.99 |
Vorläufige Website-Übersicht und zugehörige Navigationsübersicht erstellt, überprüft und freigegeben | Donnerstag, 07.10.99 | Freitag, 08.10.99 |
Beispiele für Kreativdesign erstellt, überprüft und freigegeben | Freitag, 08.10.99 | Montag, 11.10.99 |
Vorläufiger Inhaltsplan erstellt, überprüft und freigegeben (falls anwendbar) | Mittwoch, 06.10.99 | Mittwoch, 06.10.99 |
Prototyp der Benutzerschnittstelle (optional) erstellt, überprüft und freigegeben | Mittwoch, 06.10.99 | Mittwoch, 06.10.99 |
Prototyp des Berichts (optional) erstellt, überprüft und freigegeben | Dienstag, 12.10.99 | Donnerstag, 14.10.99 |
Vorläufige technologische Alternativen entwickeln | Mittwoch, 06.10.99 | Donnerstag, 07.10.99 |
Kontakt aufnehmen zu Ansprechpartnern für den Kontext | Dienstag, 12.10.99 | Mittwoch, 13.10.99 |
Vorläufiger Plan für den Wissenstransfer und Zeitplan erstellt, überprüft und freigegeben | Mittwoch, 13.10.99 | Mittwoch, 13.10.99 |
Annahme im Konzeptionsentwurf validieren/invalidieren | Mittwoch, 13.10.99 | Donnerstag, 14.10.99 |
Freigabe erhalten | Donnerstag, 14.10.99 | Donnerstag, 14.10.99 |
Vervollständigung der Konzeptionsliefergegenstände | Donnerstag, 14.10.99 | Donnerstag, 14.10.99 |
Nachbearbeitung der Konzeptionsphase | Donnerstag, 14.10.99 | Montag, 25.10.99 |
Besprechung zur Qualitätsprüfung mit dem Kunden durchführen | Donnerstag, 14.10.99 | Donnerstag, 14.10.99 |
Qualitätssicherung durchführen | Donnerstag, 14.10.99 | Freitag, 15.10.99 |
Besprechung zu bisherigen Erfahrungen mit Kontext abhalten | Donnerstag, 14.10.99 | Donnerstag, 14.10.99 |
Erste Schätzung der Projektkosten erstellt, überprüft und freigegeben | Donnerstag, 14.10.99 | Montag, 18.10.99 |
Vollständiger Projektplan für iterative Fertigung erstellt, überprüft und freigegeben | Montag, 18.10.99 | Dienstag, 19.10.99 |
Vorschlag für Ausarbeitungsphase erstellen | Donnerstag, 14.10.99 | Freitag, 15.10.99 |
Protokoll des Softwareprojekts erstellen | Freitag, 15.10.99 | Freitag, 15.10.99 |
Prüfpunkt für Konzeption vorbereiten | Freitag, 15.10.99 | Montag, 18.10.99 |
Team einschließlich Leiter des Clientprojekts Formular zur Projektfreigabe ausfüllen lassen | Montag, 18.10.99 | Dienstag, 19.10.99 |
Vorschlag für Ausarbeitungsphase machen | Dienstag, 19.10.99 | Donnerstag, 21.10.99 |
Überprüfung des Prüfpunkts für die Konzeption und Entscheidung über Fortsetzung des Projekts | Donnerstag, 21.10.99 | Freitag, 22.10.99 |
Passende Liefergegenstände von Projekt-Homepage in IAN-Artefakte verschieben | Freitag, 22.10.99 | Montag, 25.10.99 |
Konzeption abgeschlossen | Montag, 25.10.99 | Montag, 25.10.99 |
Die Entwicklung des Systems erfolgt in mehreren Phasen mit mehreren Iterationen pro Phase. Die Phasen und der relative Zeitplan sind in der folgenden Tabelle aufgelistet:
Phase | Anzahl der Iterationen | Start | Ende |
---|---|---|---|
Konzeptionsphase | 1 | Woche 1 | Woche 4 |
Ausarbeitungsphase | 1 | Woche 5 | Woche 11 |
Konstruktionsphase | 3 | Woche 12 | Woche 27 |
Übergangsphase | 1 | Woche 28 | Woche 31 |
Die Meilensteine, die das Ende jeder Phase markieren, können in der Tabelle unten nachgelesen werden.
Beschreibung | Meilenstein |
---|---|
Konzeptionsphase | Bei der Konzeptionsphase werden die Produktanforderungen entwickelt, und die Kosten-Nutzen-Analyse für das Collegiate Sports Paging System wird erstellt. Außerdem werden die wichtigsten Anwendungsfälle und der detaillierte Projektplan entwickelt. Am Ende dieser Konzeptionsphase wird entschieden, ob das Projekt finanziert und basierend auf der Kosten-Nutzen-Analyse fortgesetzt werden soll. Der Meilenstein, der die Prüfung der Kosten-Nutzen-Analyse am Phasenende beinhaltet, markiert die Entscheidung über die Fortführung des Projekts. |
Ausarbeitungsphase | In der Ausarbeitungsphase werden die Anforderungen analysiert und der Architekturprototyp entwickelt. Beim Abschluss der Ausarbeitungsphase sind Analyse und Design aller für Release 1.0 ausgewählten Anwendungsfälle abgeschlossen. Außerdem sind auch die Anwendungsfälle mit einem hohen Risiko, die für Release 2.0 vorgesehen sind, analysiert und entworfen. Der Architekturprototyp dient dazu, die Verwendbarkeit und Leistung der für Release 1.0 erforderlichen Architektur zu testen. Der Meilenstein "Architekturprototyp" markiert das Ende der Ausarbeitungsphase. Dieser Prototyp bezeichnet die Überprüfung der wichtigsten Komponenten der Architektur, die das Release 1.0 umfasst. |
Konstruktionsphase | Während der Konstruktionsphase werden die verbleibenden Anwendungsfälle analysiert und entworfen. Die Betaversion für Release 1.0 werden zur Bewertung entwickelt und verteilt. Die Implementierung und die Testtätigkeiten zur Unterstützung der Releases 1.0 und 2.0 werden ausgeführt. Der Meilenstein, an dem die Betriebsfähigkeit von Release 2.0 festgestellt wird, markiert das Ende der Konstruktionsphase. Die Software von Release 2.0 kann in ein Paket gestellt werden. |
Übergangsphase | In der Übergangsphase werden Release 1.0 und 2.0 für die Verteilung vorbereitet. Die Übergangsphase bietet eine einfache Installation einschließlich Benutzerschulung. Der Meilenstein "Release 2.0" markiert das Ende der Übergangsphase. An diesem Punkt werden alle Funktionen, wie im Visionsdokument definiert, installiert und den Benutzern zur Verfügung gestellt. |
Phase | Iteration | Beschreibung | Zugeordnete Meilensteine | Bearbeitete Risiken |
---|---|---|---|---|
Konzeption | Vorläufige Iteration | Definiert Geschäftsmodell, Produktanforderungen, Projektplan und Kosten-Nutzen-Analyse. | Übersicht über Kosten-Nutzen-Analysen | Klärt die Benutzeranforderungen im Voraus.
Entwickelt realistische Projektpläne mit realistischem Umfang. Bestimmt die Durchführbarkeit eines Projekts aus geschäftlicher Sicht. |
Ausarbeitungsphase | Architekturprototyp entwickeln | Führt für alle Anwendungsfälle die Analyse aus und erstellt das Design. Entwickelt den Architekturprototyp. | Architekturprototyp | Probleme hinsichtlich der Architektur geklärt.
Technische Risiken reduziert. Früher Prototyp für Benutzerprüfung. |
Konstruktionsphase | C1-Iteration - Betaversion entwickeln | Anwendungsfälle für Betaversion implementieren und testen. | Betaversion | Alle wichtigen Features aus Benutzersicht und
Architektursicht sind in der Betaversion implementiert.
Feedback der Benutzer vor Freigabe der Software. |
C2-Iteration - Erstes Release entwickeln | Restliche Anwendungsfälle implementieren und
testen, Mängel in Betaversion beheben und Feedback aus Betaversion aufnehmen. Entwickelt das erste System. |
Software | Software von Benutzergruppe vollständig überprüft.
Hohe Produktqualität angestrebt. Mängel reduziert. Qualitätskosten reduziert. |
|
C3-Iteration - Vollständiges Release entwickeln | Verbesserungen aus erstem Release einbinden und
nicht behobene Mängel dokumentieren.
Entwickelt das vollständige System. |
Software | Schnelle Freigabe zur Zufriedenheit der Kunden.
Alle Schlüsselfunktionen durch vollständiges Release im System bereitgestellt. |
|
Übergangsphase | Softwarefreigabe | Releasepaket erstellen, verteilen und installieren. | Software freigegeben |
Gegenwärtig sind zwei Releases geplant. Das erste Release muss bis zu den Meisterschaften im März (March Madness) fertig gestellt sein, und sein Umfang wird während der Ausarbeitungsphase bestimmt. Die gesamte verbleibende Funktionalität wird in ein künftiges Release aufgenommen (falls erforderlich).
Der vorläufige Projektzeitplan kann in Abschnitt 2.4 nachgelesen werden. Aktualisierte Pläne werden zu den in diesem Abschnitt angegebenen Zeitpunkten bereitgestellt.
Die Mitarbeiter dieses Projekts gehören zum Bereich Kontextintegration und sind im Abschnitt 3.1 aufgelistet.
Nicht zutreffend.
Die Mitarbeiter, die diesem Projekt zugeordnet sind, verfügen zu diesem über das entsprechende Know-how. Während der Konzeptionsphase wird ein Plan für den Wissenstransfer entwickelt, um sicherzustellen, dass die Mitarbeiter die Schulung erhalten, die sie benötigen, um das System nach der Übergangsphase zu unterstützen.
Das Budget für diese Iteration beträgt 150.000 $. Der Preis für die Ausarbeitungsphase wird während der Konzeptionshase ermittelt.
Dieses Dokument enthält den Iterationsplan für die Konzeption. Iterationspläne für nachfolgende Phasen werden am Ende der vorangegangenen Phase oder Iteration bereitgestellt.
Siehe Referenzinformationen [1].
Es werden wöchentlich Berichte zum Projektstatus erstellt, die Details zu den angestrebten Meilensteinen enthalten. So soll sichergestellt werden, dass das Projekt im geplanten Rahmen bleibt. Änderungen im Zeitplan werden den Projektträgern mitgeteilt, die dann entscheiden, ob der Projektumfang geändert werden soll, um das geplante Fertigstellungsdatum einzuhalten.
Es werden wöchentlich Berichte zum Projektstatus erstellt, die Details zu den angestrebten Meilensteinen enthalten. So soll sichergestellt werden, dass das Projekt im geplanten Rahmen bleibt. Änderungen im Zeitplan werden den Projektträgern mitgeteilt, die dann entscheiden, ob der Projektumfang geändert werden soll, um das geplante Fertigstellungsdatum einzuhalten.
Für jedes Design- und Implementierungssubsystem werden formale Überprüfungen durchgeführt. So wird sichergestellt, dass die zu prüfenden Objekte die angegebenen Anforderungen erfüllen.
Es werden Berichte zum wöchentlichen Projektstatus erstellt. Außerdem werden zu gegebener Zeit auch Ergebnisberichte zu Phasen und Iterationen erstellt.
Der Erfolg des Projekts wird anhand der Faktoren Aufwand und Zeit überwacht. Der Projektleiter vergleicht die Planung mit den aktuellen Berichten und misst so den Erfolg.
Siehe Referenzinformationen [2].
Am Ende des Projekts wird ein Treffen zu den gemachten Erfahrungen durchgeführt, um neue Techniken, Tools oder Methoden zu dokumentieren. Projektbezogene Liefergegenstände werden im Repository für das Knowledge-Management archiviert, damit sie in Zukunft verwendet werden können.
Siehe Referenzinformationen [3].
Die Standardrichtlinien in RUP werden verwendet.
Dieses Projekt wird in einem Context Solution Center entwickelt, in dem entsprechende Server und Software bereits installiert sind.
Wird noch entwickelt.
Siehe Referenzinformationen [3].
Wird noch entwickelt.
Zu entwickelnde Dokumente sind in den Referenzinformationen [3] aufgeführt.
Siehe Referenzinformationen [3].
Wird noch entwickelt.
Nicht zutreffend. Es werden keine Subunternehmer eingesetzt.
Am Ende jeder Phase wird eine Sitzung zu den gemachten Erfahrungen durchgeführt, um
Prozessverbesserungen zu dokumentieren.
Copyright 1987 - 2003 Rational Software Corporation