Änderungsanfrage (CR) - Ein formal
eingereichtes Arbeitsergebnis, mit dem alle Stakeholder-Anfragen einschließlich neuer Features,
Verbesserungsvorschläge, Mängel, geänderten Anforderungen und zugehörigen Statusinformationen im Lebenszyklus des
Projekts verfolgt werden. Die gesamte Änderungshistorie wird zusammen mit der Änderungsanfrage einschließlich aller
Statusänderungen sowie Zeitangaben und Gründen für die Änderung verwaltet. Diese Informationen sind für alle
nachfolgenden Prüfungen und für das endgültige Schließen einer Änderungsanfrage verfügbar.
Change (oder Configuration) Control Board (CCB) - Der Ausschuss, der den
Änderungsprozess überwacht und sich aus Stellvertretern aller Interessengruppen einschließlich Kunden, Entwicklern und
Benutzern zusammensetzt. In einem kleinen Projekt kann ein Teammitglied wie der Projektleiter oder der
Softwarearchitekt diese Rolle übernehmen. In Rational Unified Process wird dies durch die Rolle des Änderungsmanagementleiters dargestellt.
CCB-Prüfbesprechung - Diese Besprechung hat die
Funktion, eingereichte Änderungsanfragen zu prüfen. In dieser Besprechung wird der Inhalt der Änderungsanfrage
erstmalig geprüft, um festzustellen, ob es sich um eine gültige Anfrage handelt. Falls die Anfrage gültig ist, wird
basierend auf der Priorität, des Zeitplans, der Ressourcen, des Aufwands, des Risikos, der Wertigkeit und anderer
wichtiger Kriterien, die von der Gruppe definiert werden, bestimmt, ob die Änderung in den Rahmen des aktuellen Release
fällt oder nicht. Diese Besprechung findet in der Regel einmal pro Woche statt. Wenn die Menge der Änderungsanfragen
erheblich zunimmt, sollte die Besprechung wie auch am Ende eines Release-Zyklus täglich stattfinden. Normalerweise
nehmen an der CCB-Prüfbesprechung der Testleiter, Entwicklungsleiter und ein Mitglied der Marketing-Abteilung teil. Bei
Bedarf können auf Anforderung der Ausschussmitglieder zusätzliche Personen an der Besprechung teilnehmen.
Formular für Einreichen einer Änderungsanfrage - Dieses Formular wird angezeigt, wenn eine Änderungsanfrage zum
ersten Mal eingereicht wird. In dem Formular werden nur die Felder angezeigt, die der einreichende Benutzer
ausfüllen muss.
Kombiniertes Formular für Änderungsanfrage - Dieses Formular wird angezeigt, wenn Sie eine Änderungsanfrage
prüfen, die bereits eingereicht wurde. Das Formular enthält alle für die Beschreibung der Änderungsanfrage
erforderlichen Felder.
Die folgende Übersicht über den Änderungsanfrageprozess beschreibt die Stadien und Status, die Änderungsanfragen
durchlaufen, und gibt Aufschluss darüber, wer während des Lebenszyklus der Änderungsanfrage benachrichtigt werden muss.
Der allgemeine Prozess für Änderungsanfragen wird in der Aufgabe: Änderungsmanagementprozess einrichten beschrieben.
Das folgende Beispiel zeigt Aufgaben, die für die Verwaltung einer Änderungsanfrage in ihrem Lebenszyklus in ein
Projekt übernommen werden können. (Klicken Sie auf die Einträge in der Abbildung, um Beschreibungen anzuzeigen):
Beschreibungen der Beispielaufgaben für das Änderungsanfragemanagement:
Aufgabe
|
Beschreibung
|
Zuständigkeit
|
Änderungsanfrage einreichen
|
Jeder Stakeholder (Interessenvertreter) im Projekt kann eine Änderungsanfrage (CR, Change Request)
einreichen. Die Änderungsanfrage wird im Überwachungssystem für Änderungsanfragen (z. B. Rational
ClearQuest) protokolliert und in die CCB-Prüfwarteschlange gestellt, indem der Status der
Änderungsanfrage auf Einreichen gesetzt wird.
|
Einreichender Benutzer
|
Änderungsanfrage prüfen
|
Die Funktion dieser Aufgabe ist die Prüfung eingereichter Änderungsanfragen. In der
CCB-Besprechung wird der Inhalt der Änderungsanfrage erstmalig geprüft, um festzustellen, ob es sich um
eine gültige Anfrage handelt. Falls die Anfrage gültig ist, wird basierend auf der Priorität, des
Zeitplans, der Ressourcen, des Aufwands, des Risikos, der Wertigkeit und anderer wichtiger Kriterien,
die von der Gruppe definiert werden, bestimmt, ob die Änderung in den Rahmen des aktuellen Release
fällt oder nicht.
|
CCB
|
Duplikat bestätigen oder
zurückweisen
|
Wenn eine Änderungsanfrage ein Duplikat ist oder als ungültige Anfrage
zurückgewiesen wird (z. B. Bedienerfehler, nicht reproduzierbar, Funktionsweise usw.),
wird ein Teilnehmer des CCB damit beauftragt, das Duplikat zu bestätigen oder die Änderungsanfrage
zurückzuweisen und gegebenenfalls weitere Informationen vom einreichenden Benutzer anzufordern.
|
CCB-Beauftragter
|
Änderungsanfrage aktualisieren
|
Sollten weitere Informationen benötigt werden (Weitere Informationen), um eine
Änderungsanfrage auszuwerten, oder falls eine Änderungsanfrage zu einem beliebigen Zeitpunkt im Prozess
zurückgewiesen wird (z. B. als Duplikat bestätigt oder Zurückgewiesen wird
usw.), wird der einreichende Benutzer benachrichtigt, der daraufhin die Änderungsanfrage mit neuen
Informationen aktualisieren kann. Anschließend wird die aktualisierte Änderungsanfrage erneut zur
Prüfung der neuen Daten an die CCB-Prüfwarteschlange übergeben.
|
Einreichender Benutzer
|
Arbeit zuordnen &
planen
|
Sobald eine Änderungsanfrage geöffnet wird, weist der Projektleiter die Arbeit basierend
auf dem Typ der Anfrage (z. B. Verbesserungsvorschlag, Mangel, Dokumentationsänderung, Testmangel usw.)
dem entsprechenden Teammitglied zu und nimmt die erforderlichen Aktualisierungen am Projektplan vor.
|
Projektleiter
|
Änderungen vornehmen
|
Das zugeordnete Teammitglied führt die im entsprechenden Abschnitt des Prozesses, wie z. B.
Anforderungen, Analyse & Design, Implementierung, Erstellung von Unterstützungsmaterial für den
Benutzer oder Designtests, definierten Aufgaben aus, um die angeforderten Änderungen vorzunehmen. Zu
diesen Aufgaben gehören alle normalen Prüf- und Komponententestaufgaben, die im normalen
Entwicklungsprozess beschrieben sind. Die Änderungsanfrage wird anschließend als
Durchgeführt gekennzeichnet.
|
Zugeordnetes Teammitglied
|
Änderungen im Test-Build
prüfen
|
Nachdem die Änderungen vom zugeordneten Teammitglied (Analytiker, Entwickler, Tester, technischer Autor
usw.) durchgeführt wurden, werden die Änderungen in eine Testwarteschlange gestellt. Von
dort aus werden sie einem Tester zugeordnet und in einem Test-Build des Produkts geprüft.
|
Tester
|
Änderungen im
Release-Build prüfen
|
Sobald die durchgeführten Änderungen in einem Test-Build des Produkts geprüft wurden,
wird die Änderungsanfrage in eine Freigabewarteschlange gestellt. Von dort aus werden sie anhand eines
Release-Build des Produkts, der Produkt-Release-Informationen usw. geprüft. Danach wird die
Änderungsanfrage geschlossen.
|
CCB-Beauftragter (Systemintegrator)
|
Die folgende Beispielabbildung zeigt verschiedene Beispielstatus und die Personen, die im Lebenszyklus einer
Änderungsanfrage informiert werden müssen. [Klicken Sie auf die Einträge in der Abbildung, um Beschreibungen
anzuzeigen.]:
Beschreibungen der Beispielstatus für das Änderungsanfragemanagement:
Status
|
Definition
|
Zugriffssteuerung
|
Einreichen
|
Dieser Status wird gesetzt, wenn 1) eine neue Änderungsanfrage eingereicht wird, 2) eine vorhandene
Änderungsanfrage aktualisiert wird oder 3) eine Änderungsanfrage für einen neuen Release-Zyklus
zurückgestellt wird. Die Änderungsanfrage wird in die CCB-Prüfwarteschlange gestellt.
Diese Aktion hat keine Eignerzuordnung zur Folge.
|
Alle Benutzer
|
Zurückgestellt
|
Die Änderungsanfrage wird zwar als gültig, aber für das aktuelle Release als nicht relevant befunden.
Änderungsanfragen im Status Zurückgestellt werden aufbewahrt und für künftige Releases
erneut in Erwägung gezogen. Sie können ein Ziel-Release zuordnen, um den Zeitrahmen vorzugeben, in dem
die Änderungsanfrage eingereicht werden kann, damit sie erneut in die
CCB-Prüfwarteschlange gestellt wird.
|
Administrator
Projektleiter
|
Duplikat
|
Eine Änderungsanfrage in diesem Status wird als Duplikat einer anderen Änderungsanfrage eingestuft, die
bereits eingereicht wurde. Änderungsanfragen können vom CCB-Prüfadministrator oder von dem
Teammitglied, das für die Problemlösung zugeordnet wurde, in diesen Status versetzt werden. Wenn die
Änderungsanfrage in den Status Duplikat versetzt wird, wird die Nummer der duplizierten
Änderungsanfrage vermerkt (auf der Registerkarte "Anhänge" in ClearQuest). Ein einreichender Benutzer
muss die Datenbank für Änderungsanfragen zunächst auf Duplikate abfragen, bevor er die Anfrage
einreicht. Diese Vorgehensweise verhindert mehrere Schritte des Prüfprozesses und kann deshalb sehr
viel Zeit einsparen. Wenn Benutzer eine Änderungsanfrage einreichen, die bereits vorhanden ist, müssen
sie der Benachrichtigungsliste der ursprünglichen Änderungsanfrage hinzugefügt werden, damit sie
benachrichtigt werden, wenn eine Problemlösung gefunden wurde.
|
Administrator
Projektleiter
QE-Leiter
Entwicklung
|
Zurückgewiesen
|
Eine Änderungsanfrage in diesem Status wird in der CCB-Prüfbesprechung vom zugeordneten Teammitglied
als ungültige Anfrage eingestuft, oder es werden weitere Informationen vom einreichenden Benutzer
angefordert. Falls die Änderungsanfrage bereits zugeordnet (Geöffnet) ist, wird die
Änderungsanfrage aus der Warteschlange für Problemlösung entfernt und erneut geprüft. Für die
Bestätigung wird ein Beauftragter des CCB bestimmt. Vom einreichenden Benutzer wird nur bei Bedarf eine
Aktion erwartet. In diesem Fall wird der Status der Änderungsanfrage in Weitere
Informationen geändert. Die Änderungsanfrage wird unter Berücksichtigung der neuen
Informationen in CCB-Prüfbesprechung erneut geprüft. Wird die Änderungsanfrage als ungültig bestätigt,
wird sie vom CCB geschlossen. Der einreichende Benutzer wird benachrichtigt.
|
Administrator
Projektleiter
Entwicklungsleiter
Testleiter
|
Weitere Informationen
|
Es sind nicht genügend Daten vorhanden, um die Gültigkeit einer Änderungsanfrage im Status
Zurückweisen oder Duplikat zu bestätigen. Der Eigner wird automatisch in
den einreichenden Benutzer geändert, der aufgefordert wird, weitere Daten bereitzustellen.
|
Administrator
|
Geöffnet
|
Eine Änderungsanfrage in diesem Status wurde als relevant für das aktuelle Release eingestuft, und es
wird eine Problemlösung vor einem bevorstehenden Zielmeilenstein erwartet. Die Änderungsanfrage
befindet sich somit in der "Zuordnungswarteschlange". Nur die Besprechungsmitglieder sind berechtigt,
eine Änderungsanfrage in der Warteschlange für Problemlösung zu öffnen. Wenn eine Änderungsanfrage mit
Priorität zwei oder höher gefunden wird, muss der QE- oder Entwicklungsleiter sofort davon in Kenntnis
gesetzt werden. Diese können dann entscheiden, ob eine CCB-Notbesprechung einberufen oder die
Änderungsanfrage sofort in der Warteschlange für Problemlösung geöffnet wird.
|
Administrator
Projektleiter
Entwicklungsleiter
QE-Abteilung
|
Zugeordnet
|
Eine geöffnete Änderungsanfrage liegt dann in der Zuständigkeit des Projektleiters, der
die Arbeit basierend auf dem Typ der Änderungsanfrage zuweist und den Plan aktualisiert.
|
Projektleiter
|
Durchgeführt
|
Gibt an, dass die Problemlösung für die Änderungsanfrage abgeschlossen ist und die Änderungsanfrage
geprüft werden kann. Falls der einreichende Benutzer Mitglied der QE-Abteilung ist, wird der Eigner
automatisch in das einreichende QE-Mitglied geändert. Andernfalls wird er für eine erneute manuelle
Zuordnung in den QE-Leiter geändert.
|
Administrator
Projektleiter
Entwicklungsleiter
QE-Leiter
Entwicklungsabteilung
|
Test fehlgeschlagen
|
Eine Änderungsanfrage, die die Tests in einem Test-Build oder Release-Build nicht besteht, wird in
diesen Status versetzt. Der Eigner wird automatisch in das Teammitglied geändert, das die
Änderungsanfrage durchgeführt hat.
|
Administrator
QE-Abteilung
|
Geprüft
|
Eine Änderungsanfrage in diesem Status wurde in einem Test-Build geprüft und kann in ein
Release eingebunden werden.
|
Administrator
QE-Abteilung
|
Geschlossen
|
Die Änderungsanfrage muss nicht weiter bearbeitet werden. Dies ist der endgültige Status, der einer
Änderungsanfrage zugeordnet werden kann. Nur der CCB-Prüfadministrator ist berechtigt, eine
Änderungsanfrage zu schließen. Wenn eine Änderungsanfrage geschlossen wird, erhält der
Benutzer, der die Anfrage eingereicht hat, eine E-Mail-Benachrichtigung, in der beschrieben wird, wie
mit der Anfrage weiter zu verfahren ist. Eine Änderungsanfrage kann geschlossen werden,
1) nachdem die geprüfte Problemlösung in einem Release-Build validiert wurde, 2) wenn ihr
Zurückweisungsstatus bestätigt wurde oder 3) wenn sie als Duplikat einer vorhandenen
Änderungsanfrage bestätigt wurde. Im letzten Fall wird der einreichende Benutzer über die duplizierte
Änderungsanfrage informiert und dieser Änderungsanfrage für künftige Benachrichtigungen hinzugefügt.
(Sehen Sie sich die Definitionen der Status "Zurückweisen" und "Duplikat"
an, um nähere Einzelheiten zu erhalten.) Wenn der einreichende Benutzer das Schließen seiner Anfrage
abwehren möchte, muss die Änderungsanfrage aktualisiert und zur Prüfung durch das CCB erneut
eingereicht werden.
|
Administrator
|
Die Statuskennungen sind die Basis für die Erstellung von Statistiken über Änderungsanfragen (Prioritätssteuerung nach
Verweildauer, Verteilung oder Trend).
Zuständer der Änderungsanfragen im Kontext des CM-Kubus.
|