Aufgabe: Richtlinien für das Konfigurationsmanagement festlegen
Diese Aufgabe beschreibt, wie Richtlinien für Konfigurationsmanagement entwickelt werden, die Verfahren für Konfigurationsidentifikation, Verfahren für die Erstellung von Referenzversionen, Archivierungsverfahren sowie Anforderungen für Konfigurationsstatusberichte beinhalten.
Zweck

Der Zweck dieser Aufgabe besteht darin, Richtlinien für das Konfigurationsmanagement des Projekts zu erstellen, die zur Überwachung und Sicherung von Projekt-Assets sowie zur Umsetzung von Softwareentwicklungsverfahren verwendet werden sollen. Projektrichtlinien sollen die Kommunikation zwischen den Teammitgliedern verbessern und die Probleme im Zusammenhang mit der Integration ihrer Arbeit verringern.  

Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Schritte
Verfahren für Konfigurationsidentifikation definieren
Zweck: Arbeitsergebnisse in einem sicheren Repository identifizieren und speichern
Toolmentoren: Referenzversionen mit Rational ClearCase erstellen 

Die Konfigurationsidentifikation ist ein Kernstück des Konfigurationsmanagements und wird von der IEEE definiert als "ein Element des Konfigurationsmanagements, das die Auswahl der Konfigurationselemente für ein System und die Aufzeichnung ihrer funktionalen und physischen Merkmale in der technischen Dokumentation umfasst". Im Kontext des Softwarekonfigurationsmanagements bedeutet Konfigurationsidentifikation, die richtige Version eines Projektarbeitsergebnisses schnell und einfach finden und identifizieren zu können. Die negativen Auswirkungen eines ineffektiven Systems für Konfigurationsidentifikation wird in Form von Zeit- und Qualitätsverlust zum Ausdruck gebracht.

Kennsätze identifizieren bestimmte Versionen von Arbeitsergebnissen. Die Gruppe von Arbeitsergebnissen, die eine Version eines Subsystems ausmachen, können als Einheit und einzeln durch eine bestimmte Version und einen bestimmten Kennsatz identifiziert werden. Kennsätze sind daher nützlich bei der Wiederverwendung und Referenzierung von ursprünglichen Gruppen versionsgesteuerter Arbeitsergebnisse.

Es folgt ein Vorschlag für eine Namenskonvention für Arbeitsergebnisse auf Produktebene, die für die Kennzeichnung von Pfaden und Arbeitsergebnissen in der Produktverzeichnisstruktur verwendet werden kann.

<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SYSTEM> Identifiziert das System.

<A> Steht für ein TLA (Three Letter Acronym). Das TLA wird zur Bezeichnung verschiedener Arbeitsergebnisse bei der Erstellung des Systems verwendet. Beispiel:

PLN  Projektpläne  
REQ  Anforderungsdateien 
USC  Anwendungsfälle 
MOD  Modelldateien 
SRC  Quellcodedateien 
INT  Öffentliche Schnittstellen 
TST  Testscripts und Ergebnisse 
DOC  Dokumentation (Benutzer- und Release-Informationen) 
BIN  Ausführbare Dateien 

<SUBSYSTEM> Identifiziert jedes Subsystem.

<A>Steht für das TLA (Three Letter Acronym), das zur Bezeichnung verschiedener Arbeitsergebnisse bei der Erstellung des Subsystems verwendet wird. Stimmt mit obiger Tabelle überein.

R|A|B  Steht für Release, Alpha, Beta 
<X>  Integer, steht für ein Haupt-Release (z. B. 1) 
<Y>  Integer (optional), steht für ein untergeordnetes Release  
<Z>  Integer (optional), steht für ein alternatives Release (Programmkorrekturen, Ports etc.)  
BL  Steht für Basisversion (ein internes Release)  
Integer für interne Releases 

Beispiele:

T2K_R1.0  Release 1 des Systems Thorn 2000 
T2K_GUI_R2.0.BL5  Internes Release des GUI-Systems, das in Release 2 bereitgestellt werden soll  
T2K_B1.1  Betaversion 1.1 des Systems Thorn 2000 
T2K_R2.0.BL16  Interne Systemreferenzversion 16 von Thorn 2000 für die Erstellung von Release 2 
T2K_R1.0.5  Wartungs-Release von Thorn 2000 
Verfahren für die Erstellung von Referenzversionen definieren

Eine Referenzversion stellt einen stabilen Ausgangspunkt dar und ist eine Momentaufnahme der entwickelten Arbeitsergebnisse. Der Abschnitt Konzept: Erstellung einer Referenzversion beschreibt, wann im Projektlebenszyklus Referenzversionen erstellt werden müssen. Dieser Schritt bietet weitere Anleitungen für das Verfahren.

Referenzversionen identifizieren feste Gruppen von Datei- und Verzeichnisversionen und werden an bestimmten Projektmeilensteinen erstellt. Referenzversionen können für ein Subsystem oder für das gesamte System erstellt werden. Sie müssen in Übereinstimmung mit dem im vorherigen Prozessschritt entworfenen Schema identifiziert werden (siehe Abschnitt zur Definition der Namenskonvention für Arbeitsergebnisse).

Beim Erstellen einer Referenzversion muss zwischen den zwei folgenden Typen unterschieden werden:

  • "Referenzversion des Subsystems" mit allen Datei- und Verzeichnisversionen, die im Subsystem bzw. in den Subsystemen geändert wurden.
  • "Referenzversion des Systems" mit einer einzigen Version aller Dateien und Verzeichnisse in allen Subsystemen.

Man kann das Release-Management dadurch vereinfachen, dass man Referenzversionen des Systems an den größeren und kleineren Projektmeilensteinen und Referenzversionen des Subsystems nach Bedarf bzw. in kürzeren Intervallen erstellt. Das ist eine allgemeine Richtlinie. Als Faustregel gilt, dass man eine Referenzversion erstellen sollte, wenn bis zu 30 % der Elemente in einem Subsystem geändert wurden.

Archivierungsverfahren definieren

Der Zweck dieses Schritts besteht darin, sicherzustellen, dass die Projektsoftware und die zugehörigen Assets (Hauptdokumente) gesichert, katalogisiert und an bestimmte Speicher-Sites übertragen werden. Archive sind von großem Nutzen, wenn Daten wiederverwendet werden sollen oder wenn Notfälle eintreten. Daher müssen sie regelmäßig und an wichtigen und kleinen Meilensteinen aktualisiert werden.

Die Kennzeichnungsrichtlinien, die zuvor im Prozessschritt zur Definition der Namenskonvention für Arbeitsergebnisse beschrieben wurden, können bei der Erstellung von Archivierungskennsätzen verwendet werden. Außerdem müssen möglicherweise weitere Informationen zur Speicherposition der aktuellen Daten angegeben werden. Beispiel:

Seriennummer  123456789 
Datenträger  1 von 3 
Vault  B5 
Speicherdatum  21. Juni  

Alle produktbezogenen Daten müssen in einer Datenbank gespeichert werden, um die Freigabe und Wiederverwendung zu vereinfachen.

Anforderungen für Konfigurationsstatusberichte definieren
Zweck: Die Änderungsaktivität ist ein wichtiger Indikator für den Projektstatus und die Projekttrends. Der Zweck dieses Prozessschritts besteht darin, dass der Projektleiter festlegt, welche produktbezogenen Änderungsdaten von wem und in welchem Intervall dokumentiert werden sollen.  
Teilschritte:  
Toolmentoren:  

Im Abschnitt Konfigurationsstatusberichte werden die verschiedenen Quellen für die Erstellung von Konfigurationsstatusberichten beschrieben.

Auf Änderungsanfragen basierende Berichte auswählen Seitenanfang

Sie sollten hier Berichte auswählen, die von Änderungsanfragen an das Projekt abgeleitet werden können. Es gibt eine Reihe nützlicher Berichte, die auf Änderungsanfragen basieren.

Unter der Kategorie "Alter" können Berichte über die Anzahl der Änderungsanfragen in einem bestimmten Zeitraum, z. B. eine Woche oder einen Monat, nach folgenden Kriterien angefordert werden:

  • Übergeben
  • Zugeordnet
  • Durchgeführt
  • Priorität

Das Auflisten der Probleme nach Status kann dabei helfen, festzustellen, wie weit das Projekt vom Abschluss noch entfernt ist. Wenn beispielsweise die Probleme größtenteils behoben wurden, liegt der Abschluss näher als wenn sie sich größtenteils im Status Übergeben befinden.

Unter der Kategorie "Verteilung" können Berichte zur Beantwortung der folgenden Fragen angefordert werden:

  • Wer findet Mängel? Welcher Art sind die Mängel? Wo im Projekt treten die Mängel auf?
  • Wem werden die Probleme zugeordnet?
  • Wie viele Probleme sind im Zuständigkeitsbereich eines Entwicklers offen?
  • Welchen Schweregrad haben die ermittelten Mängel?
  • Wo im Prozess werden die Probleme verursacht (eigentliche Fehlerursache)?
  • Wann werden die Probleme behoben?
  • Wie viele Mängel bestehen?
  • Welchen Schweregrad haben diese Mängel?

Diese Metriken können bei der Auslastungsanalyse helfen, geben an, wer an den kritischsten Problemen arbeitet und wie schnelle die Probleme geschlossen werden.

Unter der Kategorie "Trend" können Berichte zur Beantwortung der folgenden Fragen angefordert werden:

  • Wie viele Mängel sind heute, in dieser Woche oder in diesem Monat offen?
  • Wie viele Mängel wurden heute, in dieser Woche oder in diesem Monat geschlossen?

Diese Daten sind nützlich, wenn es darum geht, die Häufigkeit von Reparaturen zu bewerten, und können eine Aussage über die Entwicklungseffizienz machen.

Berichtsintervall definieren Seitenanfang

Vergewissern Sie sich, dass Berichte im richtigen Intervall empfangen werden, so dass sie eine wichtige Eingabe für die Entscheidungsfindung bieten können. Berichte können wie folgt angefordert werden:

  • Täglich - Es ist unwahrscheinlich, dass Berichte so häufig angefordert werden.
  • Wöchentlich - Trend-, Verteilungs-, Zähl- und Build-Berichte.
  • Monatlich - Trend-, Verteilungs-, Zähl- und Build-Berichte.
  • Nach Iteration - Trend-, Verteilungs-, Zähl- und Build-Berichte, Versionsbeschreibungen.
  • Nach Phase - Trend-, Verteilungs-, Zähl- und Build-Berichte, Prüfungen, Versionsbeschreibungen.
  • Bei Projektende - Trend-, Verteilungs-, Zähl- und Build-Berichte, Prüfungen, Versionsbeschreibungen.


Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen