Suchen

Konfigurationsmanagement Mehr Durchblick im Projekt

| Autor / Redakteur: Rüdiger Loos* / Dipl.-Ing. (FH) Hendrik Härter

Software-Konfigurationsmanagement ist ein ungeliebter, aber wichtiger Prozess. Er bedeutet dass einzelne Schritte mit Versionen versehen und bis zum Schluss eindeutig nachvollziehbar sind. So lässt sich selbst in sehr komplexen Projekten der Überblick behalten.

Firmen zum Thema

( Archiv: Vogel Business Media )

„Wir verwenden CVS!“ Diese oder ähnliche Antworten erhält man oft von Projektbeteiligten auf die Frage „Wie sieht denn Ihr Konfigurationsmanagement im aktuellen Projekt aus?“ Viele Softwareentwickler und auch deren Projektleiter sind leider immer noch der Meinung, dass sie das Thema Konfigurationsmanagement (Configuration Management, CM) mit dem Einsatz eines Versionsverwaltungssystems bewältigen können. Doch CM ist weit mehr als Versionsverwaltung. Ein intelligenter CM-Prozess, der zudem in der definierten Art und Weise auch gelebt wird, ist unabdingbare Voraussetzung für ein erfolgreiches Projekt, unabhängig davon ob Hardware oder Software entwickelt wird. Auch wenn CM seinen Ursprung in der Entwicklung von Hardware im militärischen Bereich hat liegt der Fokus dieses Artikels klar im Bereich Software-CM (SCM). Er hat den Anspruch praktische Hinweise und Tipps zum „Wie“ und „Wozu“ zu geben. Er soll keine rein theoretische Abhandlung zu „Was ist CM“ sein.

Der Umfang und die Komplexität von Softwarelösungen im Embedded-Bereich sind in den letzten Jahren explosionsartig angestiegen. Wo noch vor einiger Zeit die neue Software für ein 16-bit System in ein 256kB Flash gepresst werden und zur Laufzeit mit maximal 128kB RAM auskommen musste, verrichtet heute eine leistungsstarke 32-bit CPU ihren Dienst. Die Flashgrößen reichen von 16MByte bis zu 256MByte CF-Cards. Der Hauptspeicher ist mit mindestens 16MByte bestückt, nach oben hin offen. In vielen Bereichen, z.B. im Automobilbereich, werden dutzende Steuergeräte dieser Größenordnung im Netzwerkverbund betrieben.

Bildergalerie

Die gestiegene Komplexität der Software spiegelt sich auch in der Größe der Entwicklerteams wider. Haben früher ein bis zwei Spezialisten die SW für ein Steuergerät entwickelt so sind heute Teamgrößen von 20 Entwicklern und mehr keine Seltenheit.

Zu der gestiegenen Komplexität kommen die Anforderungen der Auftraggeber an einen Entwicklungsprozess, der den aktuellen Stand der Technik widerspiegelt. Viele Aufträge werden nur noch an Firmen vergeben, die ISO 9001 zertifiziert sind und damit nachweisen können, dass sie ihre Projekte gemäß einem geeigneten SW-Entwicklungsprozess (Stichwort SPICE, CMMI) abarbeiten. Dieser Prozess sollte alle projektrelevanten Tätigkeiten abdecken, beginnend mit der Angebotsphase, über die Erfassung der Requirements, die Designphase, die Implementierungsphase bis hin zur Testphase, dem Deployment und der abschließenden Wartungsphase.

Reproduzierbarkeit wird unerlässlich

Doch weshalb brauchen wir nun CM? Dies wird klar wenn wir uns vor Augen führen, wie CM ursprünglich entstanden ist.

Wie bereits erwähnt hat CM seinen Ursprung im militärischen Umfeld. Anfang der 1950er Jahre wurden in den Vereinigten Staaten vermehrt kostspielige Versuche mit Flugkörpern verschiedenster Art gemacht. Unterschiedliche Systeme wurden in den verschiedensten Konfigurationen gebaut und getestet. Aus diesen sollten durch Tests die besten Systeme herausgefunden werden. Von ca. 1000 abgeschossenen Flugkörpern mit unterschiedlichen Einstellungen kamen die meisten nicht wie gewünscht ins Ziel. Viele explodierten beim Start oder in der Luft.

Ein Reverse Engineering war damit nicht mehr möglich, es konnte im Nachhinein nicht mehr festgestellt werden, wie sich die „guten“ von den „schlechten“ Testflugkörpern unterschieden. Anhand der mangelhaften Aufzeichnungen waren nicht genügend Rückschlüsse auf die Zusammensetzung der besten Flugkörper möglich. Kleine Änderungen, mit manchmal großen Auswirkungen, waren nicht dokumentiert und es gab keine Möglichkeit, die Ursachen eines erfolgreichen Tests nachzuvollziehen - die Ergebnisse waren schlicht nicht reproduzierbar.

Die Erkenntnis setzte sich durch, dass Änderungen an der Software nur noch gleichzeitig mit der Änderung der damit verbundenen Spezifikation bzw. Dokumentation gemacht werden durften. Die ersten Vorschriften, in denen dies gefordert wurde entstanden. Diese wurden später in abgeleiteter Form auch für kommerzielle Erzeugnisse übernommen. In der Zwischenzeit wurden die meisten militärischen Standards durch gleichartige kommerzielle Standards ersetzt (zum Beispiel wurde MIL-STD 973 im Jahr 1998 durch EIA/ANSI-649 ersetzt) [1].

Die o.a. Reproduzierbarkeit ist bei den heutigen komplexen Software-Projekten unerlässlich. Selbst wenn das Projekt aus nur einem einzigen Software-Entwickler besteht muss es dem Projektteam möglich sein, einen bestimmten Stand der Software, z.B. den der letzten Auslieferung an den Kunden, in kürzester Zeit verlässlich zu reproduzieren.

Configuration Identification

Der Auslieferungsstand, dazu gehören neben den Quellcode Dateien auch die entsprechenden Dokumente sowie die Release Notes, wird aus CM-Sicht Configuration genannt. Eine Configuration besteht aus mehreren Konfigurationseinheiten/Configuration Items (CI). Im einfachsten Fall ist ein CI gleichzusetzen mit einer Datei. Auf diese Art und Weise können wir zu jeder Zeit eine bestimmte Configuration reproduzieren bzw. identifizieren. Diese sogenannte Configuration Identification ist eines der vier funktionalen Elemente des SCM (Bild 1).

Die einzelnen Stände bzw. Versionen der CIs werden im Repository der Versionsverwaltung (VCS=Version Control System) gespeichert. Welche CIs nun zu einer bestimmten Configuration gehören wird im Konfigurations-Identifikationsdokument festgelegt. Im SCM ist dies entweder eine Datei, in der die entsprechenden Informationen hinterlegt sind, oder die sog. Baseline, anhand derer auch o.a. Auslieferungsstand identifiziert werden kann. Diese eindeutige Configuration Identification ist Grundvoraussetzung für alle weiteren CM Aktivitäten, denn diese setzen alle auf den Ergebnissen der Configuration Identification auf.

Zu Beginn des Projektes, während der Erstellung des SCM-Plans (SCMP), erfolgt die Festlegung, welche CIs es im Laufe des Projektes geben wird. Dieser Auswahlprozess erfordert neben großer Erfahrung in der Projektplanung und der Systemanalyse auch einen kritischen Blick auf die Kostensituation. Dies gilt umso mehr, da es weder feste, allgemeingültige Regeln dafür gibt, noch eine optimale Anzahl von CIs für ein bestimmtes System. Es gibt jedoch Leitlinien für die Auswahl der CIs, die Kriterien aufzeigen, nach denen CIs bestimmt werden können [2]. Allgemein gilt, lieber weniger CIs definieren, als zu viele. Zu viele CIs vergrößern den Entwicklungsaufwand und verursachen deutlich höhere Kosten in den Bereichen CI-Verwaltung und Review.

Neben der Definition der einzelnen CIs erfolgt während der Configuration Identification auch die Festlegung, wo diese CIs abgelegt werden und welche Baselines und Releases es geben wird. Dieses Kennzeichnen von Entwicklungsständen ist integraler Bestandteil eines jeden SCM-Plans. Damit können zur Projektlaufzeit bestimmte Zustände des Systems jederzeit konsistent reproduziert werden. Eine Baseline kennzeichnet dabei einen integren Stand der Software oder einer Konfiguration, zu der neben der Software auch die relevanten Dokumente wie Spezifikationen, Testkonzepte und Protokolle gehören.

Wichtig ist diese Kennzeichnung immer dann, wenn nebenläufige Aktivitäten stattfinden, z.B. während der Integrationstests (Bild 2). Hier wird eine bestimmte Konfiguration der Software getestet (V3.1.1 entstanden durch einen Branch der Version V3.1), während parallel dazu an der Software weiterentwickelt wird (V3.2). Werden während der Tests Fehler in der Software detektiert, werden die daraus resultierenden Änderungen an Dateien (V3.1.2) aus diesem Integrationstest-Zweig nach Beendigung der Integrationstests in die entsprechenden Dateien aus dem Hauptzweig übernommen (V3.3).

Kommt ein bestimmter Stand der Software zur Auslieferung (V3.1.2), muss dieser Stand auch als Release gekennzeichnet werden. Dazu ist es zwingend erforderlich, dass der zur Auslieferung kommende Stand durch eine Baseline gekennzeichnet wird und dass ein Konfigurationsaudit durchgeführt wird.

Der SCM-Plan ist in diesem Zusammenhang nicht nur ein wertvolles Dokument für alle am Projekt beteiligten Mitarbeiter, die in ihm genau erfahren „was“ „wie“ zu erledigen ist, sondern auch besonders für neue Mitarbeiter, die sich schnell ins Projektteam integrieren müssen. Der SCM-Plan beantwortet ihnen u.a. folgende Fragen:

  • Welche Anforderungsdokumente gibt es und wo sind diese zu finden?
  • Wie ist die Software strukturiert, welche Varianten gibt es davon und wo ist das Repository?
  • Welche Entwicklungsumgebungen kommen zum Einsatz?
  • Wie wird getestet, gibt es Modul- und Integrationstests, wo findet sich die Testspezifikation?
  • Gibt es projektspezifische Arbeitsanweisungen, Checklisten und Protokolle und wenn ja, wo?

Kurzum, der SCM-Plan ist quasi der „Rote Faden“, der sich durch das komplette Projekt zieht.

Configuration Change Control

Wenn alle CIs identifiziert und die Konfigurationsdokumente erstmalig freigegeben sind, dann sollten alle Änderungen an der Software über einen definierten Änderungsprozess erfolgen, unabhängig davon, ob es sich um neue Features, um Änderungen bereits bestehender Anforderungen, oder um Fehlerbeseitigungen handelt. Alle diese Änderungen am Sourcecode müssen reproduzierbar auch in den dazugehörigen Dokumenten, also in allen CIs, die von der Änderung betroffen sind, erfolgen. Zu diesem Zweck ist es sinnvoll, innerhalb des Software-Entwicklungsprozesses, einen entsprechenden Änderungsprozess zu definieren und zu etablieren, der das Vorgehen bei Änderungen festlegt (Bild 3).

Dabei sollte jede Änderung über eine Änderungsanforderung, einen Change Request (CR), in das Änderungs-Management-System Einzug finden. Der Status des neuen CRs ist in diesem Moment „submitted“. Eine übergeordnete Instanz, das sog. Change Control Board (CCB), entscheidet dann darüber, ob diese Änderung angenommen und sofort (Status „in progress“), oder zu einem späteren Zeitpunkt (Status „deferred“) realisiert wird, oder ob diese Änderung abgelehnt wird (Status „terminated“). Wird der CR angenommen, kann mit der Planung der Umsetzung begonnen werden. Dazu wird ermittelt, welche CIs im Rahmen der Änderung überarbeitet werden müssen. Steht dies fest, beginnt die Überarbeitung der CIs. Zuerst wird eine Strategie entwickelt, wie die Änderung getestet werden kann, dann werden die Tests spezifiziert und implementiert. Parallel dazu erfolgt die Implementierung der Änderung. Erst wenn die Software geändert (Status „resolved“), diese Änderungen integriert und getestet sind (Status „tested“), alle betroffenen Dokumente geändert und einem Review unterzogen wurden und all diese Änderungsschritte im Änderungs-Management-System dokumentiert wurden, erst dann kann die Freigabe erfolgen (Status „closed“).

Auf diese Weise sind die Vollständigkeit und damit auch die lückenlose Nachvollziehbarkeit der Änderung gewährleistet. So kann selbst in der Projekt-Retrospektive ermittelt werden, wann eine bestimmte Änderung aus welchem Grund erfolgte und welche CIs davon betroffen waren.

Um Synergieeffekte nutzen zu können ist es ratsam, einen projektübergreifenden Workflow für die CR-Behandlung zu definieren. Wenn eine firmenweite Lösung nicht möglich ist, so sollte doch versucht werden einen einheitlichen Workflow dort zu etablieren, wo sich der größte Nutzen daraus ziehen lässt. Eine weitere Verbreitung kann auch dadurch erzielt werden, dass der Workflow durch sinnvolles Tailoring in zusätzlichen Projekten zur Anwendung kommen kann.

Unabhängig von der Art des Workflows gibt die Configuration Change Control also Antwort auf folgende zentrale Fragen:

  • Wie werden die Änderungen am Produkt überwacht?
  • Was wird überwacht?
  • Wer hat wann die Änderungen getestet?

Der Prozess der Configuration Change Control kann wirkungsvoll und effektiv unterstützt werden durch den Einsatz eines entsprechenden Tools. Damit können Tätigkeiten, die in diesem Bereich anfallen zudem automatisiert werden, was nicht nur eine Zeit- und damit Kostenersparnis mit sich bringt, sondern auch eine potentielle Fehlerquelle eliminiert.

Configuration Status Accounting

Eng verbunden mit der Configuration Change Control ist die Konfigurationsbuchführung (Configuration Status Accounting). Sie ermöglicht die Rückverfolgbarkeit von Änderungen auf die letzte Bezugskonfiguration [1]. Wurden die beiden bisher beschriebenen Disziplinen prozessgerecht bewältigt, so sollten die dafür benötigten Informationen als Nebenprodukte abfallen.

Bei der Buchführung werden lückenlos der Status und die Historie aller Baselines, der davon betroffenen CIs und der damit verbundenen Änderungen aufgezeichnet. Configuration Status Accounting gibt u.a. Antwort auf folgende Fragen:

  • Welche Änderungen wurden am System vorgenommen?
  • Wann wurden Änderungen in welche Version übernommen?
  • Welche und wie viele CIs waren von den Änderungen betroffen?

Durch das Aufzeichnen der Änderungen ist die Voraussetzung geschaffen für die Traceability oder Verfolgbarkeit von Änderungen bzw. Requirements. Werden diese in das System eingebracht, müssen sie durch den kompletten Produktentstehungsprozess hindurch verfolgbar sein, damit ihre Umsetzung gewährleistet ist. Eine Anforderung oder Änderung, die in der Anforderungsspezifikation formuliert ist, muss sich im Design und im Sourcecode wieder finden. Darüber hinaus muss sichergestellt sein, dass sie zudem im Zuge der Modul- und Integrationstests getestet wird. Nur so kann sichergestellt werden, dass eine Anforderung; die an das Produkt gestellt wurde sich auch im Produkt wieder findet. Die zu erstellenden Testprotokolle bestätigen, dass die Anforderung in der gewünschten Weise umgesetzt wurde.

Die Konfigurationsbuchführung ist zudem in der Lage zu jedem Zeitpunkt den aktuellen Status, sowohl der CIs, als auch der Änderungen, die am Produkt vorgenommen wurden, zu ermitteln. Diese Statusreports sind nicht nur für das Projektteam selbst hilfreich, auch dem Management kann der Projektleiter die gewünschten Informationen liefern, sei es die Anzahl der während eines Tests entdeckten Fehler, die Anzahl der bereits umgesetzten Anforderungen, die Anzahl der Änderungswünsche, die zur Laufzeit eingegangen sind, oder auch die Zeitdauer, in der Änderungen umgesetzt wurden.

Configuration Auditing

Die Konfigurationsauditierung schließlich stellt sicher, dass das Produkt den spezifizierten Anforderungen entspricht. Sie sichert die Vollständigkeit und Integrität aller CIs und der Configurations. Vor dem Etablieren einer Baseline, besonders einer Release-Baseline sollte daher immer ein Konfigurationsaudit durchgeführt werden. Dieses Audit sollte vom Projektleiter im Projektplan als Arbeitspaket aufgeführt werden, da es signifikant Zeit in Anspruch nimmt.

Im Zuge des Audits wird geprüft, ob es noch offene, nicht behobene Fehler gibt, ob noch geplante Änderungen vorliegen, oder ob es etwaige nicht bestandene Tests gibt. Auch wird geprüft, ob alle vorgeschriebenen Reviews durchgeführt wurden. Sollte es noch offene Punkte geben, müssen diese geprüft und es muss entschieden werden, ob diese als Abweichungen in den Release-Notes dokumentiert werden, oder ob sie erst noch abgearbeitet werden.

Die Konfigurationsauditierung beantwortet daher folgende Fragen:

  • Entspricht das Produkt den Anforderungen?
  • Wurden alle Änderungen in der vorliegenden Version/Konfiguration berücksichtigt?

Fazit: Konfigurationsmanagement ist ebenso wichtig wie unbeliebt. Es ist eine Sportart vergleichbar mit dem Zehnkampf. Sie erfordert viel Erfahrung und viel Training in den unterschiedlichsten Disziplinen. Sie erfordert Fleiß und Genauigkeit und nimmt signifikant Zeit in Anspruch. Daher kostet sie auch signifikant Geld. Ein gescheitertes Projekt ist jedoch um Potenzen teuerer und kostet zudem noch Ansehen. Deshalb kann nur dazu geraten werden am Konfigurationsmanagement nicht zu sparen. Die Aufwände dafür können durch externe Beratungsleistung von Spezialisten in überschaubaren Grenzen gehalten werden. Ihr Projekt und auch Ihr Kunde wird es Ihnen danken.

Literaturhinweise:

[1] Gerhard Versteegen (Hrsg.), Guido Weischedel, Konfigurationsmanagement, ISBN 3-540-43622-7 Springer-Verlag, 2003

[2] Jessica Keyes, Software Configuration Management, ISBN 0-8493-1976-5 Auerbach

*Rüdiger Loos ist Consultant für Projekt- und Konfigurationsmanagement bei Elektrobit Automotive. Kontakt: info.automotive@elektrobit.com

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 201973)