Verfahren für Konfigurationsidentifikation definieren
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.
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.
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.
|
|