8.4.1 KM-Plan



		8.4.1 KM-Plan (KPl)

CM Plan

Inhalt
Einleitung
Inhalt des Dokuments
Aufbau des Dokuments
Verknüpfungen mit der V-Modell Mailingliste

Inhalt		Einleitung Inhalt des Dokuments Aufbau des Dokuments Verknüpfungen mit der V-Modell Mailingliste

Einleitung

Der Konfigurationsmanagement-Plan schreibt die abwicklungstechnischen Details bezüglich des Konfigurationsmanagements fest. Es werden Projektregeln und Konventionen bezüglich der Punkte Einführung des Konfigurationsmanagements, Änderungsmanagement (Konfigurationssteuerung) sowie Sicherung und Archivierung vereinbart, die im gesamten Projektverlauf verbindlich einzuhalten sind.

Inhalt des Dokuments

1. Allgemeines
2. Einführung des Konfigurationsmanagements
2.1. Produktbibliothek
2.2. Projektspezifische Festlegungen
2.3. Konventionen zur Identifikation
3. Änderungsmanagement
3.1. Änderungsmanagement
3.1.1. Verfahren im Änderungswesen
3.1.2. Änderungsaufträge
3.1.3. Schnittstellen zum Auftraggeber und zu anderen Stellen
3.1.4. Änderungskontrolle und Statusanzeige
3.2. Formulare des Änderungswesens und deren Handhabung
3.3. Versionskontrolle
3.4. Dokumente des Konfigurationsmanagements
4. Sicherung und Archivierung

Aufbau des Dokuments

1. Allgemeines

Siehe Gliederungspunkt 1. Allgemeines.

2. Einführung des Konfigurationsmanagements

Alle zur Einführung des KM erforderlichen Regelungen werden hier getroffen. Dies betrifft die Produktbibliothek, Identifikationsrichtlinien und weitere projektspezifische Regelungen.

2. 1. Produktbibliothek

Alle Produkte - soweit sinnvoll und möglich - werden in einer Produktbibliothek zusammengefaßt und geführt. Hier ist die Produktbibliothek mit ihrer Systematik der Produkt-, Nutzer-, Rechte- und Relationsverwaltung zu beschreiben, bzw. auf geeignete Dokumente/Handbücher zu verweisen.

2. 2. Projektspezifische Festlegungen

Dieser Gliederungspunkt legt fest,

welche Produkte unter KM-Kontrolle gestellt werden,
anhand welcher Kriterien die Konfigurationseinheiten gebildet werden,
welche Zustände die Produkte durchlaufen,
welche Produktattribute mitgeführt werden,
wie Zugriffsrechte vergeben und kontrolliert werden,
wie Produkte von Unterauftragnehmern unter KM-Kontrolle gestellt werden,
welche sonstigen Objekte (Entwicklungsrechner, Werkzeuge, Prüfumgebung, usw.) unter KM-Kontrolle gestellt werden,
wie KM-Instanzen (z. B. Change Control Board, Interface Control Working Group) eingeführt und besetzt werden,
welche Hilfsmittel (z. B. KM-Werkzeuge, Formblätter) bereitgestellt werden.

Zu Produktattribute: Es wird festgeschrieben, welche Produktattribute geführt werden, welchen Initialwert sie besitzen und wie mögliche Wertfolgen der Attribute aussehen können. Beispiele für Produktattribute sind:

Zustand
klassifiziert den Fertigstellungsgrad des Produkts (geplant, in Bearb., vorgelegt, akzeptiert).

Eigentümer
bezeichnet den Eigentümer (Projekt, usw.) des Produkts.

Bearbeiter
bezeichnet das Submodell oder den Bearbeiter, der das Produkt bearbeitet und verändert.

Entstehungsdatum

Änderungshistorie

Vorgegebene Bearbeitungsdauer
bezeichnet die vom Projektmanagement vorgegebene Bearbeitungsdauer.

Zugriffsrecht
bezeichnet Zugriffsrechte für die Projektmitglieder.

Klassifizierung
VS-Vermerke unterschiedlicher Abstufung.

Schlüsselbegriffe
bezeichnen das Produkt und dienen zum Wiederfinden. Mögliche Bezeichnungen wären: Treiber, usw.

Zugehörige andere Produkte,
hier kann eine Verkettung aller zu einem SW-Modul/SW-Komponente gehörenden Produkte erfolgen.

Versionsattribute,
ist das gegenwärtige Produkt eine Version eines Vorgängers, so werden die Versionsattribute eingetragen. Jede Änderung an dem Produkt, die mit einer Zustandsänderung verknüpft ist, bedeutet automatisch eine Änderung der Versionsbezeichnung (normalerweise Versionserhöhung).

Zu Produktzustände: Ein projektspezifischer Mechanismus, der die erlaubten Zustandsübergänge beschreibt, wird hier festgelegt. Dazu kann Abbildung 6.1: Zulässige Zustandsübergänge von Produkten aus dem V-Modell übernommen werden; bei Bedarf können diese Festlegungen weiter detailliert werden durch ein Verfeinern oder Zwischenschalten von Zuständen, wobei allerdings genau definiert werden muß, durch welche Aktivität oder welches Ereignis ein Zustandswechsel erfolgt. Denkbar wäre z. B. die Verfeinerung von "akzeptiert" in "qualitätsgesichert" (durch interne QS) und "freigegeben" (durch externe Prüfstelle) oder die Ergänzung des Zustands "abgenommen" (nach einer Abnahme durch den Auftraggeber).

Zu Zugriffsrechte: Entsprechend den Bearbeitungskompetenzen der Organisationseinheiten (vgl. Projekthandbuch.Projektorganisation) und der VS-Einstufung der Produkte werden hier Richtlinien für die Vergabe und Kontrolle von Zugriffsrechten auf Daten(basis), Programme, Prozeduren, Werkzeuge festgelegt. Ferner sind in diesem Zusammenhang auch Schutz- und Kontrollmechanismen zu beschreiben und festzulegen.

2. 3. Konventionen zur Identifikation

Alle entwickelten Produkte, Dokumente des Berichts- und Änderungswesens, beauftragte und beigestellte Produkte, referenzierte und verwendete Produkte (z. B. Schnittstellen, Prüfumgebung) und alle Komponenten der Entwicklungsumgebung (Methoden, Werkzeuge, Hilfsmittel) sind eindeutig zu bezeichnen (dazu gehört z. B. auch die eindeutige Beschriftung von Datenträgern).

Es werden den Produkten Identifikatoren zugeordnet, die diese eindeutig einschließlich ihrer Version kennzeichnen. Bei einigen Produkten bietet sich auch eine Identifikation von Produktinterna (z. B. Numerierung von Source-Code-Zeilen) an, die hier mit zu beschreiben ist.

Zu beschreiben sind:

Struktur des Identifikators,
Informationen, die der Identifikator widerspiegeln soll,
Methodik, wie der Identifikator sich bei Änderungen des "Produkts" (z. B. neue Version, neues Release) verhält,
Hilfsmittel (eventuell automatisch), die eine selbsttätige Identifikation der Produkte ermöglichen, z. B. bordautonome Analyse der PROM-Checksumme zur Identifikation der Segment-Version,
Identifikation von produktinternen Einheiten.

Die Identifikationsrichtlinien gelten jeweils für alle Architekturelemente vom System bis zum Modul, alle zugehörigen Dokumente und verwendeten Produkte. Es wird empfohlen, bei den Identifikatoren der Software die gleiche Methodik wie bei der Hardware anzuwenden (z. B. über Zeichnungsnummer).

3. Änderungsmanagement

Dieses Kapitel enthält Regelungen im Zusammenhang mit der Durchführung von Änderungen: das Verfahren vom Änderungsantrag/Problemmeldung bis zur Änderungsmitteilung, alle erforderlichen Änderungsformulare und Richtlinien der Versionsführung.

3. 1. Änderungsmanagement

In diesem Kapitel wird der Ablauf einer Änderung beginnend bei ihrem Antrag bis zur abschließenden Mitteilung beschrieben. Häufig wird bei der Änderungsprozedur unterschieden, ob Produkte bereits an den AG ausgeliefert wurden. Bei noch in der Entwicklung befindlichen Produkten wird meist eine vereinfachte Änderungsprozedur verwendet. Falls unterschiedliche Änderungsprozeduren zum Einsatz kommen, sind alle zu beschreiben.

Hier ist zu berücksichtigen, daß in der Praxis mehrere Änderungsvorgänge zusammengeführt werden können. Die Auswirkungen von Änderungen auf die Festlegung von Baselines sind zu beschreiben.

3. 1. 1. Verfahren im Änderungswesen

Folgende Situationen sind hier abzudecken:

Änderungswunsch für noch in der Entwicklung befindliche Produkte und bereits ausgelieferte Produkte,
Änderungswunsch projektexterner (Anwender, AG) und -interner Stellen,
Inhalt des Änderungswunsches: Problem, Fehler, Modifikation und Erweiterung,
Festlegung von Baselines.

Zu regeln sind in diesem Kapitel:

Erfassung und Verfolgung des Änderungswunsches,
Weg der Änderung vom Änderungsantrag/Problemmeldung über den Änderungsvorschlag und Änderungsauftrag bis zur Änderungsmitteilung,
beteiligte Instanzen mit ihren Pflichten und Entscheidungsbefugnissen.

3. 1. 2. Änderungsaufträge

Es wird festgelegt, wie mit Änderungsaufträgen weiter verfahren wird; dies umfaßt insbesondere die Regelung von Release-Ausgaben (Zusammenfassung mehrerer Änderungen) und die Vorgehensweise für das Verfolgen von Änderungen. IT-sicherheitskritische Ergänzungen bzw. Modifikationen zum Änderungsverfahren sind zu beschreiben.

welche Dokumente im Rahmen des Konfigurationsmanagements zu erstellen sind,
welche Inhalte und
welche äußere Form die Dokumente aufzuweisen haben.
Insbesondere werden Verfahren zur Cross-Referenzierung zwischen Formularen definiert, damit Änderungen im Detail verfolgt werden können.