1. Einführung in das Konfigurationsmanagement
Damit bei der Erprobung und Entwicklung von technischen Konstruktionen
(Software, Hardware) kein Durcheinander auftritt, braucht man einen
einheitlichen Management Prozess, der grundlegende Aktivitäten reguliert und
dokumentiert. Die hier vorliegende Arbeit befasst sich daher mit dem allgemeinen
Konfigurationsmanagement (KM) und dem bei der Firma Airbus modifizierten
Configuration Management (CM) Prozess. Das Ziel dieser Arbeit ist es, die
Geschichte, Funktion und Anwendung dieser Disziplin anhand eines Vergleichs
zwischen Theorie und Praxis näher zu beleuchten. Sie soll außerdem aufzeigen,
wie adaptionsfähig dieser Prozess ist und wie weit interpretierbar die Vorgaben
eines solchen Prozesses sein können.
1.1. Geschichte und Allgemeines
Anfang der 1950er Jahre wurden in den Vereinigten Staaten von Amerika
kostspielige Versuche mit Flugkörpern verschiedenster Art gemacht. Dabei
wurden unterschiedliche Systeme in verschiedenen Konfigurationen hergestellt
und getestet. Durch diese Untersuchungen sollten die besten Konfigurationen
herausgefunden werden. ,,Von ca. 1000 abgeschossenen Flugkörpern mit
unterschiedlichen Einstellungen explodierten nur wenige im Ziel viele
explodierten beim Start oder in der Luft."
1
Ein Reverse Engineering war aufgrund
der mangelhaften Aufzeichnungen damit nicht mehr möglich , denn es konnte
nicht mehr festgestellt werden, wo der Unterschied zwischen den Flugkörpern ,
die das Ziel erreichten und denen, die vorher explodierten, war. Kleinste
Änderungen mit oft großen Auswirkungen wurden nicht dokumentiert daher war
es unmöglich, die Ursachen für einen erfolgreichen Test nachzuvollziehen.
,,Künftig durften Änderungen an militärischen Erzeugnissen nur noch gemacht
werden, wenn auch die Dokumentation entsprechend geändert wurde. Die ersten
Vorschriften, in denen dies gefordert wurde, entstanden."
2
Diese Vorschriften zur
Verwaltung und Änderungen von Konfigurationen sind bereits Anfang de r 1960er
Jahre erlassen worden: der MIL-STD-480, die AFSCM 375 Systems
Management Serie der amerikanischen Luftwaffe oder das Apollo Configuration
Management Manual NPC 500-1 der NASA. Diese Standards wurden
ursprünglich für elektrische und mechanische Konstruktionen im militärischen
Bereich entwickelt. ,,Doch KM ist im Wesentlichen unabhängig davon, was
1
Vgl. Verstegen, G. (2003). S. 1.
2
Vgl. ebda. S. 2.
1
entwickelt und hergestellt wird und ob dies für militärische oder kommerzielle
Zwecke geschieht."
3
Das Vorgehen bei der Entwicklung von Software
unterscheidet sich von dem der Hardwareentwicklung. Da Software flexibler ist
als Hardware und während der verschiedenen Lebenszyklen eines Produkts eine
Vielzahl von Problemen auftreten können, ist bei einem Erzeugnis mit
Softwareanteilen oder reinen Softwareerzeugnissen ein funktionierendes und gut
angepasstes KM unabdingbar. Deshalb nutzen heute eine Vielzahl
verschiedenster Unternehmen das KM. Einige bekannte Vertreter sind Airbus,
Audi, Bank of America, BMW, Boeing, Daimler Chrysler, Deutsche Bank,
Deutsche Telekom, Eurocopter, Ford, IBM, Infinion, Nokia, Opel, Philips, Rolls-
Royce und Siemens.
4
Anforderungen an das KM sind heute in den üblichen
Qualitätsstandards und Reifegradmodellen enthalten. Ob ein Unternehmen diese
Anforderungen erfüllt und wie genau dies erfolgt, hängt von unterschiedlichen
Faktoren ab. ,,Zur Bewertung werden Assessments in Bezug zu
Reifegradmodellen, wie zum Beispiel CMM(I), SPICE (ISO/IEC TR 15504),
durchgeführt."
5
Wie diese Anforderungen erfüllt werden, ist jedem Unternehmen
selbst überlassen, die meisten jedoch greifen auf Standard-Prozessmodelle
zurück. Organisatorisch wird das KM meist auf Projektebenen angesiedelt , um
die Ergebnisse zu sichern (Configuration Control) und um Vorgaben für jede an
der Entwicklung beteiligten Person in einem KM-Plan zu dokumentieren. Da sich
Projekte oft ähneln, ist es sinnvoll, einen generischen KM-Plan zu entwickeln,
von dem projektspezifische Pläne abgeleitet werden. Produktentwicklungen aus
Elektronik, Mechanik und Software wie Flugzeuge, Kraftfahrzeuge oder
Steuergeräte sind gängige Vertreter dieses Vorgehens. Ein optimaler KM
Prozess sollte projektübergreifend funktionieren und wird deshalb innerhalb eines
Unternehmens oft als Kernprozess, ähnlich wie das Qualitätsmanagement oder
die IT, angesiedelt. ,,Ein solches zentrales Konfigurationsmanagement wird
immer mehr zu einem Informationspool werden, in dem alle freigegebenen
Informationen eines Unternehmens strukturiert abgelegt und veröffentlicht
werden."
6
Die folgende Abbildung soll das Konfigurationsmanagement als
Informationspool veranschaulichen.
3
Vgl. Verstegen, G. (2003).S.2.
4
Vgl. ebda. S.142.
5
Vgl. ebda. S. 3.
6
Vgl. ebda. S. 4.
2
Abbildung 1: KM als Informationspool
Vgl. Verstegen, G.(2003). S. 4.
1.2. Grundlagen des Konfigurationsmanagements
Im CMMI des Instituts der Carnegie Mellon University, Pittsburgh USA heißt es:
,,Konfigurationsmanagement ist eine Disziplin, welche technische und
administrative Vorschriften enthält die nötig sind, um Konfigurationseinheiten
(Configuration Items) zu identifizieren und deren funktionale und physische
Eigenschaften zu dokumentieren, Änderungen an diesen Eigenschaften zu
steuern, Änderungs- und Implementierungsstati aufzuzeichnen und zu
veröffentlichen und die Erfüllung der spezifizierten Anforderungen zu
verifizieren."
7
CMMI ist ein Reifegradmodell und vereint die Modelle für Software,
System Engineering und Integrated Product Development zu einer Einheit. Mit
Hilfe von CMMI sollen Unternehmen ihre Prozesse bewerten und verbessern
können. Eine Konfigurationseinheit ist hierbei eine Kombination aus Hardware,
Software und Dienstleistungen oder eine mögliche Unterteilung davon. ,,Die ISO
9000 hat keine Definition bezüglich Konfigurationsmanagement, enthält jedoch
Anforderungen, die denen des Konfigurationsmanagements entsprechen:
x ,,...der Lieferant muss alle Verfahren dokumentieren und dafür sorgen,
dass das Design des Erzeugnisses den Anforderungen entspricht.
7
Vgl. Verstegen, G. (2003).S. 5.
3
x ...sämtliche Dokumente müssen vor ihrer Verwendung geprüft werden.
Die aktuell gültigen Versionsstände der Dokumente sind in einer
Stammliste einzutragen.
x ...Änderungen an Dokumenten müssen geprüft und freigegeben
werden."
8
1.2.1. Die KM Definition nach EN ISO 10007
Die EN ISO 10007:1996 als Leitfaden für KM enthält folgende Definition:
,,KM ist eine Managementdisziplin, die über die gesamte Lebensdauer eines
Erzeugnisses angewandt wird, um Transparenz und Überwachung seiner
funktionellen und physischen Merkmale sicherzustellen. Hauptziel von KM ist, die
gegenwärtige Konfiguration eines Erzeugnisses sowie den Stand der Erfüllung
seiner physischen und funktionellen Forderungen zu doku mentieren und volle
Transparenz herzustellen. Ein weiteres Ziel ist, dass jeder am Projekt
Mitwirkende zu jeder Zeit des Erzeugnislebenslaufs die richtige und zutreffende
Dokumentation verwendet. Der KM Prozess umfasst die folgenden integrierten
Tätigkeiten: Identifizierung, Überwachung, Buchführung und Auditierung."
9
An diesem Punkt beginnt die Modifizierbarkeit des gesamten KM, denn es gibt für
diese vier Punkte keine einheitlichen Definitionen. ,,Die meisten Definitionen sind
sehr ähnlich wie diese und beinhalten die folgenden Tätigkeiten:
x Die Identifizierung soll die Erzeugnisstruktur definieren und die
Konfigurationseinheiten auswählen.
x Dokumentation der physischen und funktionellen Merkmale von
Konfigurationseinheiten in eindeutig gekennzeichneten, sogenannten
Konfigurationsdokumenten.
x Aufstellen und Verwenden von Regeln zur Numminierung von
Konfigurationseinheiten, ihren Teilen und Zusammenstellungen von
Dokumenten, Schnittstellen, Änderungen und Sonderfreigaben vor und
nach der Realisierung.
x Einrichten von Bezugskonfigurationen durch formalisierte
Vereinbarungen. Diese bilden zusammen mit ihren genehmigten
Änderungen die aktuell vereinbarte und somit gültige Konfiguration."
10
Nachdem ein Dokument das erste Mal freigegeben wurde, sollten alle
Änderungen überwacht werden. ,,Die Konfigurationsüberwachung schließt die
8
Vgl. Verstegen, G. (2003) S. 6.
9
Vgl. ebda.
10
Vgl. ebda. S. 7.
4
folgenden Tätigkeiten ein, die im Einzelnen in einem Änderungsverfahren
dokumentiert sein sollten:
x Dokumentation und Begründung der Änderungen
x Beurteilung der Änderungsauswirkungen
x Genehmigung oder Ablehnung der Änderung
x Bearbeitung von Sonderfreigaben (so genannte Deviations und Waivers)
vor oder nach der Realisierung"
11
Um die Rückverfolgbarkeit von Modifikationen auf die letzte Bezugskonstruktion
ermöglichen zu können, gibt es die Konfigurationsbuchführung. Die hierfür
benötigten Aufzeichnungen und Berichte sollten als Nebenprodukte aus den
Identifizierungs- und Überwachungstätigkeiten hervorgehen. Um sicher sein zu
können, dass ein Produkt den vertraglich spezifizierten Anforderungen entsp richt
und dass das Erzeugnis in seinen Dokumenten richtig dargestellt ist, sollte vor
der Abnahme einer Bezugskonfiguration ein Konfigurationsaudit durchgeführt
werden. ,,In der Regel gibt es zwei Arten von Konfigurationsaudits:
x Funktionsbezogenes Konfigurationsaudit: Formale Prüfung einer
Konfigurationseinheit, ob sie die in ihren Konfigurationsdokumenten
festgelegten Leistungen und funktionellen Merkmale erreicht hat.
x Physisches Konfigurationsaudit: Formale Prüfung der ,,Ist"-Konfiguration
einer Konfigurationseinheit, ob diese ihren Konfigurationsdokumenten
entspricht."
12
1.2.2. Der KM-Plan
Der KM-Prozess und alle notwendigen Verfahren sollten in einem so genannten
Konfigurationsmanagement-Plan (KMP) niedergeschrieben werden. ,,Ein KMP
gibt es für die organisationsinterne Anwendung, für Projekte oder aus
Vertragsgründen."
13
Ein KMP definiert für jedes Projekt welches Verfahren von
welcher Instanz in welchem zeitlichen Rahmen durchführt. Bei einer mehrstufigen
Vertragsstruktur innerhalb eines Projekts wird in der Regel der KMP des
Hauptauftragnehmers auch als Hauptplan angewandt. Jeder Unterauftragnehmer
sollte einen Plan in den des Hauptauftraggebers einschließen oder seinen
eigenen Plan erstellen und als eigenständiges Dokument veröffentlichen.
11
Vgl. Verstegen, G. (2003) S. 7.
12
Vgl. ebda.
13
Vgl. ebda.
5
1.2.2. Das projektübergreifende CM II
,,Das Institute of Configuration Management (ICM) verfolgt mit dem
Konfigurationmanagementprozess CMII den Ansatz eines einheitlichen,
projektübergreifenden Konfigurationsmanagements."
14
Und definiert das CMII wie
folgt: ,,KM ist der Prozess, der Erzeugnisse, Einrichtungen und Prozesse einer
Organisation in Form von Anforderungen (an die Erzeugnisse, Einrichtungen und
Prozesse) einschließlich deren Änderungen verwaltet und gewährleistet, sodass
die Ergebnisse immer konform mit den verwalteten Anforderungen sind. In dem
Prozess werden alle Informationen, (d.h. nicht nur erzeugnisspezifische), die
einen Einfluss auf die Sicherheit, Qualität, Planung, Kosten, das
Betriebsergebnis oder die Umwelt haben können, verwaltet."
15
Er soll dafür
sorgen, dass Korrekturmaßnahmen minimiert bzw. im Idealfall eliminiert werden.
Diese durchgängige Konformität stammt aus den Reifegradmodellen und
Qualitätsstandards und kann erreicht werden indem,
x nur auf Basis von dokumentierten Anforderungen gearbeitet wird
x diese Anforderungen in zentralen Verwaltungsorten abgelegt werden
x die Anforderungen stets klar, knapp und gültig sind
x mit Hilfe von Dokumenten, Formularen und Aufzeichnungen (Records)
nachvollziehbar und interpretationsfrei kommuniziert wird,
x die Anforderungserfüllung von klaren und schnell umsetzbaren
Akzeptanzkriterien nachgewiesen wird und
x die gesamte Integrität bei Änderungseinarbeitung gewährleistet ist und
alle Anforderungen klar und gültig bleiben
,,Der CM II Gesamtprozess besteht aus folgenden vier Teilprozessen:
x Definitions-
und
Strukturierungsprozess
x Anforderungs-Freigabeprozess
x Anforderungs-Änderungsprozess
x Erzeugnis-Änderungs-
und
Freigabeprozess"
16
Weitere Informationen wie aktuell gängige CM-Software, Trainingsanbieter und
Trainingsabstufungen mit den entsprechenden Preisen findet man auf der
Homepage des Institute of Configuration Management:
http://www.icmhq.com
.
Hier gibt es auch Erfolgsgeschichten und eine kurze chronologische Auflistung
der Geschichte des CM und CM II sowie eine Liste der nach CM II zertifizierten
Unternehmen in deren Zertifizierungsabstufungen.
14
Vgl. Verstegen, G. (2003) S. 57f.
15
Vgl. ebda. S. 58.
16
Vgl. ebda. Auf diese vier Subprozesse soll in dieser Abhandlung nicht eingegangen w erden.
6
1.2.3. Adaptierung und Änderung des KM-Prozesses
Da heute die Arbeiten oft auf verschiedene Entwicklerteams verteilt werden ,
ergeben sich für das KM zusätzliche Probleme, wie z.B. die erschwerte
Kommunikation wenn Teams über mehrere Zeitzonen hinweg verteilt sind. Dabei
müssen technische Hürden (Infrastruktur), psychologische Hürden (einzelne
Anwender), kulturelle Hürden (Mentalitätsunterschiede) und politische Hürden
(Einfluss innerhalb des Projektes) überwunden werden. Die Anzahl der
Mitarbeiter, Standorte und Nationen im Unternehmen sind bei der KM Adaption
zu berücksichtigen. Gerade dabei ist ein geschickt modellierter und
produktspezifisch abgestimmter KM-Plan, wonach alle an einem Strang ziehen,
unerlässlich. Auch die Geschichte und Geschäftsstrategie eines Unternehmens
ist von Bedeutung. Die Eigenschaften der IT-Struktur sind ebenfalls wichtige
Modellierungskriterien. So sind Datenablage (zentral oder dezentral), Umfang
des Zugriffes auf Daten und die Art und Häufigkeit der Synchronisierung
entscheidende Faktoren und müssen mit dem KM in Einklang stehen. Auch die
Aktionen im Fehlerfall (wer muss welche Eskalationsmaßnahmen an welche
Ansprechpartner kommunizieren) dürfen dabei nicht außer Acht gelassen
werden. Eine der schwierigsten Herausforderungen bei der Anpassung ist die
Frage der Verantwortlichkeiten. ,,Gleichzeitig ist es auch derjenige Aspekt, der für
den weiteren Verlauf des Projektes die größten Risiken aus KM Sicht in sich
birgt. Entscheidungen werden häufig nicht auf Grund harter Fakten getroffen; das
politische und psychologische Element spielt hier auf allen Ebenen der Projekt -
und Unternehmenshierarchie eine gewichtige Rolle."
17
Deshalb stößt man meist
auf Widerstände, wenn Mitarbeiter entgegen ihrer Gewohnheit an Artefakten
keine Änderungen mehr vornehmen sollen. Solche Widerstände sind häufig der
Grund für Kompromisse. Das KM-System hat die Aufgabe, einen bestimmten
Zustand eines Projektes jederzeit wieder reproduzieren zu können. Daher sollte
man Updates (seien es technologische, projektspezifische oder
unternehmensweite) von KM-Tools im laufenden Projekt unter allen Umständen
vermeiden. ,,Vergleicht man ein Projekt mit dem menschlichen Organismus, so
fällt dem KM-Werkzeug am ehesten die Rolle des Herz-Kreislauf-Systems zu. Es
ist für alle Bereiche des Projektes von lebenswichtiger Bedeutu ng und stellt die
Informationen bereit."
18
Ein Update ist daher gleichzusetzen mit einer
Herzoperation geht diese daneben, kann das Projekt sterben. Genauso ist eine
optimale Vorbereitung der Schlüssel zum Erfolg.
17
Vgl. Verstegen, G. (2003) S.24.
18
Vgl. ebda. S. 25.
7