Wann Sie Ihr Konfigurationsmanagement-Tool wechseln sollten

Manchmal stößt ein Konfigurationsmanagement-Werkzeug (CM) an seine Grenzen. In diesem Fall ist es anzuraten, nicht einfach nur ein neues Tool zu wählen, sondern auch die CM-Strategie zu überdenken.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Mixed Mode GmbH

Wenn das bestehende System zum Konfigurationsmanagement (CM) ersetzt werden soll, kann es dafür verschiedene Gründe geben: Vormals überschaubare Projekte können einen Umfang angenommen haben, der nicht mehr effizient zu verwalten ist. Viele neue Entwickler sind dazugekommen, die sich gegenseitig blockieren, weil paralleles Entwickeln nicht oder nicht ausreichend unterstützt wird.

Neue Standorte sollen einbezogen werden, aber mit dem vorhandenen Tool ist ein sinnvolles verteiltes Arbeiten an mehreren Sites nicht möglich. Der Entwicklungsprozess soll verbessert oder eine neue Methodik eingeführt werden, was mit dem aktuellen System zu größeren Anpassungen oder Erweiterungen führen würde. Oder das System ist zu teuer, weil hohe Lizenzgebühren zu zahlen sind oder die Bedienung zu viel administrativen Overhead für die Entwickler bereitet.

Doch wann lohnt sich ein Umstieg wirklich? Ist die Entscheidung für einen Wechsel gefallen, ergeben sich weitere Fragen nach dem geeigneten Tool. Wie wichtig ist die Wahl des CM-Systems überhaupt? Welches ist das Best-In-Class-Tool? Schließlich: Welche Daten sollen und können mit vertretbarem Aufwand migriert werden?

Die Umstellung des CM-Tools und die damit verbundene Datenmigration ist als eigenes Projekt mit dem dazu gehörenden Projektmanagement zu sehen und zu realisieren. Dies ist gerade in größeren Organisationen unabdingbar, in denen die Umstellung viele laufende Projekte betrifft, die den Aufwand für ihre Migration (Schulung, Datenmigration, Client-Installation) in ihrer eigenen Planung rechtzeitig berücksichtigen müssen. Diese Kosten werden sonst oft auf der Ebene der Entwicklungsprojekte ignoriert.

1. Schritt: Analyse der aktuellen CM-Lösung

Eine der wichtigsten Aktivitäten für die erfolgreiche Umstellung steht gleich am Anfang und besteht in der Analyse der aktuellen Lösung. Dazu gehören neben der Verbindung des Projekts zu Change- und Test Management die Schnittstellen zu anderen Projekten. Die folgenden Fragen können zur Analyse dienen:

• Wie groß ist der Projektumfang (Codegröße, Anzahl Entwickler, verteilte Standorte)?

• Wie erfolgt die Anbindung an das Build-System?

• Wie ist aktuell die Zuordnung von Change Requests und Änderungen im Code / Dokument realisiert?

• Wie erfolgen Übergaben an die Testabteilung und an den Kunden?

• Wie sind Lieferungen aus anderen Projekten, etwa generische Libraries, geregelt?

• Wie wird verwendete Third-Party-Software verwaltet und integriert?

2. Schritt: Analyse der Ziele der CM-Umstellung

Die Festlegung der Ziele, die mit der Umstellung erreicht werden sollen, zu Beginn der Planung ist eine Selbstverständlichkeit, die aber oft vor der Wahl des Tools und seiner Features zurücksteht. In vielen Projekten und Organisationen ist zu beobachten, dass zuerst das Tool ausgewählt wird und anschließend der Workflow an die Gegebenheiten des Tools angepasst werden muss.

Wenn es möglich ist, sollte der Weg umgekehrt sein: Erst wird das Ergebnis festgelegt, dann sucht man das für dieses Ziel passende Tool. Gerade in sehr großen Organisationen gibt es aber oft oft Richtlinien, nach denen Entwicklungsumgebungen und CM-Systeme konzernweit vorgeschrieben sind. Dann ist es besonders wichtig, die erreichbaren Ziele zu identifizieren und innerhalb der eigenen Organisation darzulegen, um beim späteren Einsatz Akzeptanzprobleme zu minimieren.

Oft wird eine Verbesserung oder Anpassung des Entwicklungsprozesses angestrebt, um etwa bisher mit verschiedenen Tools verwaltete Daten aus dem Requirements Engineering, dem Change Management oder dem Test Management zusammenzuführen. Dadurch lässt sich die Nachverfolgbarkeit (Traceability) von Änderungen und des Workflows von den Requirements bis zum Test verbessern. Oft stellt dies ein angestrebtes Qualitätsziel dar, um Vorgaben eines Standards wie SPICE oder CMMI zu erfüllen.

Auch die Steigerung der Performance kann ein Ziel sein. Zu denken ist dabei nicht nur an die reine Tool-Laufzeit bei regelmäßigen Operationen wie Mergen, Labeln oder Baselining, sondern auch an effizientere Integration zwischen Standorten und höhere Interoperabilität mit anderen Tools aus dem Change Management oder dem Requirement Engineering. Schließlich kann auch die Reduzierung der Entwicklungskosten eine Rolle spielen.

Die Neuausrichtung der CM-Strategie sollte immer mit ausreichender Vorbereitung erfolgen und durch Evolution aus der bisherigen hervorgehen. Auch in großen Organisationen ist schon die radikale Tool-Umstellung an der unzureichenden Planung gescheitert und hat hohe Kosten beim erzwungenen Rückschritt auf die vorherige Lösung verursacht.

Deshalb müssen von Beginn der Planung an alle Aspekte der Projektlandschaft berücksichtigt werden: Abhängigkeiten und Lieferbeziehungen zu anderen Projekten, Integration und Test, Standorten, eventuell auch zu Lieferanten und Kunden.

3. Schritt: Entwicklung der CM-Strategie

Auch in der neuen Entwicklungsumgebung sollte die gelebte Team- bzw. Unternehmenskultur erhalten bleiben. Nicht zu unterschätzen können die Widerstände der Entwicklungsmannschaft bei der Einführung eines neuen Tools sein. Dies kann jeder erfahren, der versucht, von oben herab auch nur einen anderen Editor einzuführen.

Hinzu kommt, dass gerade Entwickler oft den Aufwand für die SW-Versionierung als Beeinträchtigung ihrer kreativen Arbeiten betrachten und deshalb frühzeitig in den Entscheidungsprozess eingebunden werden sollten. Information über die Vorteile der neuen Umgebung und Aufklärung darüber, welche Verbesserungen im Entwicklungsprozess damit verfolgt werden, erhöht die Akzeptanz bei den Anwendern, die es später in ihrer täglichen Arbeit einsetzen.

4. Schritt: Umsetzung der CM-Strategie

Nachdem die Ausgangslage und die Ziele bestimmt sind, kann die Entscheidung für das CM-Tool getroffen werden, mit dem man am besten die Ziele erreichen kann. Dabei werden auch Budgetüberlegungen eine Rolle spielen. In vielen Fällen mag eine Open Source-Lösung wie Subversion, Git oder Mercurial ausreichen. Diese Systeme haben zudem den Vorteil, dass sie oft auch Berufsanfängern vom Studium her vertraut sind. Allerdings sind diese Tools meist auf die Aufgabe der Versionierung beschränkt; eine Modellierung des eigenen Workflows erfordert zusätzlichen Aufwand.

Aktuelle kommerzielle Tools gehen in die Richtung integrierter Entwicklungsumgebungen, die Unterstützung und eine gemeinsame Datenhaltung für verwandte Disziplinen wie Change Management, Requirements Engineering und Test Management bieten – mit dem Ziel eines umfassenden Application-Lifecycle-Managements (ALM) oder Product-Lifecycle-Management (PLM).

Die Hersteller versuchen dies auch bei ihren schon länger auf dem Markt erfolgreich vertretenen Produkten durch die Entwicklung von Integrationen zwischen den Disziplinen.

Jedoch bleibt dabei meist die tatsächliche Integrationsfähigkeit der unterschiedlichen Tools beschränkt. Hier lohnt sich ein genauerer Blick in Verbindung mit einer Testinstallation, ob der Datenaustausch und der Workflow zwischen den Disziplinen reibungslos funktionieren, da selbst Produkte eines Tool-Herstellers nicht immer ursprünglich aus einer Hand kommen und durch ihre Entstehungsgeschichte nicht selten auf inkompatiblen Architekturen beruhen. Neuere, konsequent auf Integration setzende Konzepte wie das auf der Jazz-Plattform basierende Rational Team Concert von IBM gehen hier deutlich weiter.

Bei der Vielzahl der angebotenen Lösungen sollte bei der Entscheidung auch die Flexibilität gegenüber zukünftigen Strategieänderungen berücksichtigt werden, wenn später einmal weitere Disziplinen integriert werden sollen. Auf der anderen Seite stellt das Configuration Management eine so zentrale und in alle Entwicklungsbereiche hinein wirkende Funktion dar, dass auch eine längerfristige, also auf mehrere Jahre ausgerichtete, stabile Tool-Umgebung gesucht ist. Das CM-Tool wechselt man ja sicher nicht (ohne größte Not) jährlich!

Die Einführung des Tools muss nun mit den Leitern der aktuellen Projekte abgestimmt werden, um die aus dem alten Tool zu übernehmenden Daten abzustimmen und einen geeigneten Zeitpunkt für die Umstellung zu finden.

Aufgrund der unterschiedlichen Datenhaltungen gibt es nur zwischen den wenigsten CM-Systemen Transfer- oder Importverfahren, die neben dem eigentlichen Inhalt auch eine komplette Übernahme der Metadaten wie Label, Kommentare, Verknüpfungen und Ähnliches erlauben.

Deshalb sollte mit den Projekten eine möglichst geringe Zahl an wichtigen Baselines identifiziert werden, die in das neue System migriert werden. Bei länger laufenden Projekten kann dies ein günstiger Zeitpunkt sein, um alte Daten zu entrümpeln und die Projekthistorie zu entschlacken, was in vielen CM-Systemen sonst nur mit größerem Aufwand möglich ist.

Der Umstiegstermin muss klug gewählt werden

Da die mehr oder weniger umfangreiche Datenmigration zwischen mehreren Stunden und einigen Tagen in Anspruch nehmen kann, ergibt sich für die Projekte eine Zeitspanne, in der nicht eingecheckt werden kann. Der Umstiegstermin muss daher so gewählt werden, dass er nicht gerade mit einer hektischen Freigabephase kollidiert. Auch an dieser Stelle ist gelegentlich Fingerspitzengefühl gefragt, denn einen idealen, unkritischen Zeitpunkt gibt es im laufenden Projekt naturgemäß nie.

Für besonders kritische Projekte empfiehlt sich neben den nötigen internen Tests eine Testmigration auf einen Testserver, mit der bei der Migration auftretende Fragen oder Probleme in Zusammenarbeit mit einzelnen Key-Usern aus dem Projekt frühzeitig analysiert und geklärt werden können.

Zum Rollout auf dem Produktivsystem werden die neuen Tool-Clients zur Installation verteilt und Trainings für die Anwender abgehalten. Die Schulungen sollten nicht zu früh stattfinden, sondern zeitnah zum tatsächlichen Einsatz des neuen Tools und neben dem reinen Tool-Gebrauch auch den neuen Workflow darstellen und motivieren.

Wenn die genannten Punkte berücksichtigt worden sind, hat man in der Vorbereitung alles für eine erfolgreiche Tool-Einführung getan und ist auf die Unwägbarkeiten der Umstellungsphase gewappnet.

Der Schlüssel zum Erfolg liegt in der Vorbereitung und der Analyse und nicht so sehr in der Funktionalität des Werkzeugs, denn das Tool, das allen Anforderungen optimal entspricht, gibt es nicht.

* Oliver Gesing arbeitet seit 25 Jahren in der Softwareentwicklung. Bei Mixed Mode berät er Kunden zum Thema Konfigurationsmanagement.

(ID:43017085)