 |
| | | | | Beschreibung der Komponente | | Dieser Baustein beschreibt, wie die einzelnen Änderungsgremien (Steuerkreis und Change Control Board) organisiert sind, vgl. Einführung einer Änderungskontrolle.
Beim Bekanntwerden eines Änderungswunsches muss der Projektleiter entscheiden, welches Gremium zuständig ist. Alle Änderungen der Anforderungen oder Projektziele (vertraglich festgelegte Rahmenbedingungen) sind dem Steuerkreis unterstellt und sollten nach folgendem Muster behandelt werden:
- Änderungswünsche werden dem Projektleiter als Mitglied des Steuerkreises mit folgenden Inhalten vorgelegt: Was soll geändert werden und welche Vor- und Nachteile bringt diese Änderung aus Sicht des Vorschlagenden mit sich.
- Der Projektleiter identifiziert die betroffenen Parteien und stellt den Vorschlag für ein Review im Steuerkreis bereit.
- Jede betroffene Partei schätzt in dem Review die Vor- und Nachteile aus ihren individuellen Standpunkten (s. u.) ab.
- Danach werden die Ergebnisse zusammengefasst und es wird entschieden, ob der Vorschlag akzeptiert, abgelehnt oder auf einen späteren Zeitpunkt verschoben wird.
- Zuletzt werden alle betroffenen Parteien über den Entschluss und seine Auswirkungen informiert.
Zur Bewertung von Änderungsvorschlägen in Punkt 3 sollten sich die verschiedenen Parteien folgende Fragen stellen:
- Was ist der erwartete Vorteil der Änderung ?
- Welchen Aufwand verursacht die Durchführung der Änderung ?
- Wie wird die Zeitplanung beeinflusst ?
- Wie wird die Softwarequalität beeinflusst ?
- Wie wird die Ressourcenplanung beeinflusst ?
- Kann die Änderung auf ein späteres Datum oder eine spätere Version der Software verschoben werden ?
- Ist das Projekt an einem Punkt, an dem die Änderung den Projekterfolg gefährden könnte?
Um alle Änderungen beurteilen zu können, sollte zu Beginn des Projektes ein Zeitintervall für die Treffen des Steuerkreises festgelegt werden. Beispielsweise könnte ein Treffen alle 2 oder 4 Wochen einberaumt werden. Somit hat jede Partei die Möglichkeit, sich ausreichend auf die Termine vorzubereiten.
Alle anderen Änderungen, die keinen Einfluss auf die Anforderungen oder Projektziele haben, werden vom Change Control Board (CCB) behandelt, wobei sich folgender Ablauf etablieren sollte:
- In der Anfangsphase wird keine Änderungskontrolle vorgenommen - freie Übernahme aller Änderungen.
- Um sicherzustellen, dass die grundlegende Arbeit getan ist, wird das Artefakt (z. B. eine Systemspezifikation, oder ein Maskendesign) einem technischen Review unterzogen.
- Nun wird es der Änderungskontrolle, und somit dem Änderungsgremium, unterstellt. Wenn ein Produkt diesen Schritt getan hat, wird es als "baselined" bezeichnet. Das Change Board muss von nun an alle Blickwinkel auf die Änderungen betrachten, um sicherzustellen, dass alle Auswirkungen von Änderungen berücksichtigt werden.
- Das Artefakt wird in eine Versionskontrolle gestellt. Die Werkzeuge zur Versionskontrolle sollten somit neben der Verwaltung des Quellcodes auch die Versionierung der übrigen Dokumente wie: Tabellen, Designdiagramme, Dokumente, Testfälle usw. übernehmen.
Da die Beteiligten des CCB, im Gegensatz zum Steuerkreis, oft enger miteinander arbeiten, können sie flexibler ihre Treffen planen. Hier ist ein gesunder Mittelweg zwischen dem Beurteilen von Änderungen, sobald diese auftreten und dem Sammeln von Änderungen bis zum nächsten regulären CCB-Meeting, zu finden. Zum Beispiel kann in Projektphasen mit wenigen Änderungsanträgen jede Änderung sofort bewertet werden, während in Phasen mit vielen Anträgen jede Woche alle anstehenden Änderungen bewertet werden. | |
| | | | | | | | | | | | | Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben. |
|
| | | | | | | | Organisation der Änderungsgremien | | | | | | Ansprechpartner | | | | | | | | Literaturhinweise | | | | | | | | | | Weitere Themen | | | | | | | | Glossar | | | | | | | | | | | | | |
|
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights 
Eintrag kommentieren