Wylie College
Plan für das Anforderungsmanagement
Version 2.0
Revisionsprotokoll
Datum |
Version |
Beschreibung |
Autor |
---|---|---|---|
08. Januar 1999 |
1.0 |
Erstes Release |
Simon Jones |
10. Februar 1999 |
2.0 |
Planerweiterung |
Simon Jones |
|
|
|
|
|
|
|
|
Inhaltsverzeichnis
1.3 Definitionen, Akronyme und Abkürzungen
2.1 Organisation, Zuständigkeiten und Schnittstellen
2.2 Tools, Umgebung und Infrastruktur
3. Programm für Anforderungsmanagement
3.1 Anforderungen identifizieren
3.2.1 Kriterien für Produktanforderungen
3.2.2 Kriterien für die Anforderungen an Anwendungsfälle
3.3.1 Attribute für die Anforderungen an Anwendungsfälle
3.5 Änderungsmanagement für Anforderungen
Plan für das Anforderungsmanagement
Die Richtlinien für Anforderungsattribute benennen und beschreiben die Attribute, die für die Verwaltung der Anforderungen an alle Softwareprojekte des Wylie College verwendet werden. Dieses Dokument umreißt darüber hinaus die Rückverfolgbarkeit der Projektanforderungen während der Entwicklung.
Anhand der Attributen, die den einzelnen Anforderungen zugeordnet werden, wird die Softwareentwicklung verwaltet und werden den Features der einzelnen Releases Prioritäten zugeordnet.
Ziel der Rückverfolgbarkeit der Anforderungen ist es, die Anzahl der gegen Ende des Entwicklungszyklus festgestellten Mängel zu reduzieren. Wenn sichergestellt ist, dass die Softwarevoraussetzungen, das Design und die Testfälle vollständig sind, kann eine bessere Produktqualität erreicht werden.
Die Richtlinien für Attribute und Rückverfolgbarkeit in diesem Dokument gelten für die Produkt-, Software- und Testanforderungen aller Softwareprojekte des Wylie College.
Die hier verwendeten Begriffe sind im Rational Unified Process und in der Dokumentation zu Rational RequisitePro definiert.
Die folgenden Referenzen sind auf der Website des Wylie College zum Softwareprozess verfügbar.
1. Konfigurationsmanagementplan des Wylie College
2. Rational Unified Process
3. Entwicklungsfall des Wylie College
Im Softwareentwicklungsplan des jeweiligen Projekts beschrieben
Anforderungsattribute und Rückverfolgbarkeit werden mit Rational RequisitePro verwaltet. Die übrigen Infrastrukturdetails finden Sie auf der Website des Wylie College zum Softwareprozess.
Für jedes Projekt werden folgende Anforderungstypen identifiziert und verwaltet:
Arbeitsergebnisse
|
Anforderungstyp |
Beschreibung |
---|---|---|
Vision |
Produktanforderungen |
Produktfeatures, Einschränkungen, Qualitätsstufen und weitere Produktanforderungen |
Anwendungsfallmodell |
Anwendungsfall |
In Rational Rose dokumentierte Anwendungsfälle |
Testplan |
Testfälle |
Fälle, die beschreiben, wie geprüft werden kann, ob sich das System wie erwartet verhält |
Die im Visionsdokument definierten Produktanforderungen werden aus den entsprechenden Anwendungsfällen oder aus ergänzenden Anforderungen in den Spezifikationen der Anwendungsfälle und in der ergänzenden Spezifikation hergeleitet.
Jede Produktanforderung wird aus den Anforderungen für mindestens einen Anwendungsfall und den ergänzenden Anforderungen abgeleitet.
Jede Produktanforderung wird aus den Anforderungen für mindestens einen Anwendungsfall und den ergänzenden Anforderungen abgeleitet.
Die in den Spezifikationen der Anwendungsfälle und der ergänzenden Spezifikation definierten Anforderungen an Anwendungsfälle werden aus den entsprechenden, im Testplan angegebenen Testfällen abgeleitet.
Jede Anforderung an einen Testfall wird aus mindestens einem Systemtestfall abgeleitet.
Die im Testplan angegebenen Testfälle werden von den Produktanforderungen (aus dem Visionsdokument) und den Anforderungen an Anwendungsfälle, die mit dem jeweiligen Testfall überprüft werden, hergeleitet.
Ein Testfall kann aus mindestens einer Produktanforderung und den Anforderungen für mindestens einen Anwendungsfall abgeleitet werden. Wenn mit dem Testfall eine abgeleitete Anforderung oder das Design überprüft wird, lässt sich der Testfall möglicherweise nicht auf die ursprünglichen Produktanforderungen oder die ursprünglichen Anforderungen an Anwendungsfälle zurückführen.
Die Anforderungen an Anwendungsfälle und die ergänzende Spezifikation werden mit Hilfe der in diesem Abschnitt definierten Attribute verwaltet. Diese Attribute sind für die Verwaltung der Entwicklungsschritte, die Bestimmung des Iterationsinhalts und die Zuordnung von Anwendungsfällen zu einem bestimmten Rose-Modell geeignet.
Wird gesetzt, nachdem die Anwendungsfälle per Analyse entworfen wurden. Protokolliert den Fortschritt der Entwicklung des Anwendungsfalls vom ersten Entwurf bis hin zur abschließenden Validierung.
Vorgeschlagen |
Anwendungsfälle, die festgelegt, jedoch noch nicht überprüft oder genehmigt wurden |
---|---|
Genehmigt |
Für die weitere Gestaltung und Implementierung freigegebene Anwendungsfälle |
Validiert |
In einem Systemtest validierte Anwendungsfälle |
Die Priorität wird vom Projektmanager festgelegt. Die Wichtigkeit der Zuordnung von Entwicklungsressourcen zu einem Anwendungsfall und der Überwachung des Fortschritts bei der Anwendungsfallentwicklung bestimmt die Priorität eines Anwendungsfalls. Der erkennbare Vorteil für den Benutzer, die geplante Freigabe, die geplante Iteration, die Komplexität des Anwendungsfalls (Risiko) und der Aufwand für die Implementierung eines Anwendungsfalls bilden in der Regel die Basis für die Priorität.
Hoch |
Die Priorität des Anwendungsfalls bezüglich der strikten Überwachung seiner Implementierung und der Zuordnung von geeigneten Ressourcen für die jeweiligen Aufgaben ist hoch. |
---|---|
Mittel |
Verglichen mit anderen Anwendungsfällen hat dieser Anwendungsfall eine mittlere Priorität. |
Niedrig |
Der Anwendungsfall hat eine niedrige Priorität. Die Implementierung dieses Anwendungsfalls ist weniger kritisch und kann auch auf spätere Iterationen oder Releases verschoben werden. |
Diese Schätzung wird vom Entwicklerteam abgegeben. Da einige Anwendungsfälle mehr Zeit und Ressourcen als andere erfordern, kann beispielsweise anhand einer Einschätzung der Team- oder Mannwochen und der erforderlichen Anzahl von Codezeilen oder Funktionspunkten am besten bewertet werden, was in einem bestimmten Zeitrahmen erreichbar ist und was nicht und wie komplex die Aufgaben innerhalb des gesteckten Zeitrahmens sein werden. Auf dieser Einschätzung basiert das Scope-Management. Außerdem werden ausgehend von dieser Einschätzung die Prioritäten bei der Entwicklung gesetzt. Der Projektmanager kann auf der Basis dieser Aufwandsschätzung den Projektzeitplan festlegen und effizient die Ressourcen für die einzelnen Aufgaben planen.
Die Aufwandsschätzung wird in Manntagen (bei 7,5 Arbeitsstunden pro Werktag) angegeben.
Diese Risiken definiert das Entwicklerteam ausgehend von der Wahrscheinlichkeit, mit der unerwünschte Ereignisse in Anwendungsfällen zu erwarten sind. Hierzu gehören Designfehler, eine hohe Anzahl von Mängeln, geringe Qualität, geringer Durchsatz, ein übermäßiger Aufwand usw. Solche unerwünschten Ereignisse sind oft auf unzureichend verstandene oder definierte Anforderungen, fehlende Kenntnisse, mangelnde Ressourcen, technische Komplexität, neue Technologien, neue Tools oder neue Ausrüstung zurückzuführen.
Für Projekte des Wylie College werden die technischen Risiken jedes einzelnen Anwendungsfalls als hoch, mittel oder niedrig eingestuft.
Hoch |
Die Auswirkungen des Risikos sind schwerwiegend und die Risikowahrscheinlichkeit ist hoch. |
---|---|
Mittel |
Die Auswirkungen des Risikos sind weniger schwerwiegend und die Risikowahrscheinlichkeit ist weniger hoch. |
Niedrig |
Die Auswirkungen des Risikos sind minimal und die Risikowahrscheinlichkeit ist niedrig. |
Zieliteration für die Entwicklung
Protokolliert die Entwicklungsiteration, in der der Anwendungsfall implementiert wird. Es ist davon auszugehen, dass sich die Entwicklung der einzelnen Releases über mehrere Entwicklungsiterationen in der Konstruktionsphase des Projekts erstrecken wird.
Anhand der Iterationsnummer jedes Anwendungsfalls plant der Projektmanager die Aktivitäten des Projektteams.
Die Werte setzen sich aus Buchstaben für die Iteration (Kp, A, Kt, Ü für Konzeption, Ausarbeitung, Konstruktion und Übergang) und der Iterationsnummer zusammen. Beispiele:
A1 |
Geplant für Iteration 1 der Ausarbeitungsphase |
Kt1 |
Geplant für Iteration 1 der Konstruktionsphase |
Kt2 |
Geplant für Iteration 2 der Konstruktionsphase |
Kt3 |
Geplant für Iteration 3 der Konstruktionsphase |
Analyse, Design und Implementierung der Anwendungsfälle werden einzelnen Personen oder Entwicklerteams zugewiesen. Eine einfache Pulldown-Liste gibt einen guten Überblick über die Zuständigkeiten im Projektteam.
Bezeichnet das der Anwendungsfallanforderung zugeordnete Rose-Anwendungsfallmodell.
Der Status wird von der Testleitung angegeben, die den Status jedes Testfalls verfolgt.
Nicht getestet |
Der Testfall wurde nicht ausgeführt. |
---|---|
Gescheitert |
Der Test wurde durchgeführt und ist gescheitert. |
Bedingt bestanden |
Der Test wurde mit Problemen beendet. Dem Test wird der Status 'Bestanden' zugeordnet, jedoch unter der Bedingung, dass bestimmte Maßnahmen ergriffen werden. |
Bestanden |
Der Test wurde erfolgreich abgeschlossen. |
Gibt den System-Build an, bei dem der spezielle Testfall überprüft wird.
Die Person, die mit der Durchführung und Prüfung des Testfalls betraut wurde. Diese einfache Pulldown-Liste gibt einen guten Überblick über die Zuständigkeiten im Projektteam.
Das geplante oder tatsächliche Testdatum
Anmerkungen zur Planung oder Ausführung des Tests
NZE
Siehe Konfigurationsmanagementplan des Wylie College
Siehe Entwicklungsfall des Wylie College
Die Meilensteine werden im Softwareentwicklungsplan des jeweiligen Projekts beschrieben.
Diese Informationen enthält der Softwareentwicklungsplan zum jeweiligen Projekt.