Software-Configuration-Management

Das Software-Configuration-Management (SCM) oder Softwarekonfigurationsmanagement ist eine Spezialisierung des Konfigurationsmanagements auf alle Aktivitäten im Bereich der Software-Entwicklung.

SCM hat mehrere Ziele:

• Definition und Verfolgung von Prozessen
• Dokumentation aller Vorgänge
• Versionierung und Konfliktbehandlung
• Verwaltung von Voraussetzungen
• Effizienzsteigerungen bei der automatisierten Applikationserstellung
• Integration aller vorhandenen Werkzeuge
• Zugriffskontrolle

Das SCM wird in weiten Teilen manuell gehandhabt. Das typische, in einem Unternehmen anzutreffende Szenario ist die Versionsverwaltung, die mit Datenbanken auf Basis von Lotus Notes oder Excel ergänzt wird. Der Umgang wird mit einem Regelwerk beschrieben, das mehr oder weniger, in keinem Fall jedoch zu 100%, eingehalten wird. Eine durchgängige Software-Lösung, die etliche anfallende Probleme beseitigt, wird kaum eingesetzt. Versuche in dieser Richtung scheitern gemeinhin am zeitlichen und finanziellen Aufwand.

Grundlegende Betrachtungen

Eine akademische Forschung zu dem Thema findet nur in sehr bescheidenem Umfang statt, und im universitären Lehrplan der Informatiker erscheint das Thema SCM überhaupt nicht. Infolgedessen sind viele der auftretenden und grundsätzlich zu lösenden Problematiken den Jungakademikern nicht präsent, was wiederum zu keiner Nachfrage am Markt führt. Dadurch sieht keine der großen Firmen den Bedarf, den Markt für sich zu besetzen und damit abseits der akademischen Pfade Standards zu schaffen. Die Folge ist somit eine starke Zersplitterung des Marktes und jeweils eigenwillige Ansichten über Umfang, Begriffe, Integrationen, Verfügbarkeit und Kompatibilität.

Grundlegende Objekte, die ein SCM-Werkzeug haben muss, sind Projekt, Datei, Konfigurationseinheit, Baseline und Produkt.

Projekt

Ein Projekt zeichnet sich durch Anfang, Ende und Umfang aus. Weil in der Entwicklung gemeinhin damit etwas Größeres gemeint ist, wird dieser Teil häufig Teilprojekt, Änderung, Change Order, Change Request, Task o.ä. genannt. Es ist zwar möglich, mit nur einer Hierarchiestufe auszukommen, doch wird die Arbeit damit meist umständlich. Deshalb geben die Werkzeuge mehrere Stufen vor oder lassen es zu, diese frei zu definieren, um eine Delegation an andere Personen oder Teams zu gewährleisten. Typische Hierarchien sind Project-Task-Subtask.

Datei

Beim SCM wird meist die Datei als Basisobjekt angesehen, das verwaltet werden muss. Neben der einfachen Versionierung ist es häufig für einen beschleunigten Produktionsablauf nötig, die Entwicklung zu verzweigen und wieder zusammenzuführen. Im Detail treten jedoch weitere Probleme auf, die bei der Auswahl des SCM-Werkzeugs nicht beachtet werden, hinterher jedoch zu Problemen führen können. Es beginnt mit dem Thema Umbenennung der Datei, die bei einfachen Versionsverwaltungen häufig nicht möglich ist. Weiter gehören zu dem Problemkreis das Verschieben in ein anderes Verzeichnis oder das Löschen. Unterschiedlich gelöst, mitunter auch ignoriert, sind Verzeichnisse. Letztere können entweder lediglich in der Abbildung auf das Dateisystem erscheinen oder tatsächlich ebenfalls als Objekte versioniert werden.

Der Transfer zwischen der Versionsverwaltung und dem Dateisystem sorgt für weitere Komplikationen, wenn mehr als ein Betriebssystemtyp versorgt werden muss. Problempunkte sind Groß- und Kleinschreibung bzw. deren Konflikte sowie Sondertypen wie symbolische und harte Links, Devices, Pipes etc. Weitere Stellen, die beachtet werden müssen, sind Zeichensätze für Dateinamen und Inhalte, die separat behandelt werden müssen, oder Zeitstempel. Weil die Betriebssysteme unterschiedliche Zeiten unterstützen, Windows z. B. die Creation-Time, Unix dagegen nicht, müssten solche Dinge behandelt werden, entfallen jedoch bei den meisten Produkten. Die Änderungszeit wird jedoch häufiger beachtet, weil sie beim Ausspielen in das Dateisystem zwei mögliche Werte annehmen kann: die tatsächliche Zeit oder die Änderungszeit vor dem Archivieren. Welche Zeit gewählt werden muss, hängt vom Build-System ab, das der Anwender benutzt.

Baseline

Weil sich im Archiv zahlreiche Versionen tummeln, muss es einen Mechanismus geben, der die zusammengehörigen Versionen auch kennzeichnet. Dies wird als „Tagging“ oder „Baselining“ bezeichnet. Die möglichen Varianten, die zur Erstellung führen, sind zahlreich. Mitunter wird eine Ansicht auf die Versionen mit Regeln erstellt und diese dann markiert. Alternativ können auch Regeln dazu führen. Meist sinnvollste Methode, dafür am seltensten gut unterstützt, ist das Veränderungsmanagement mittels Projekten, weil Änderungen nur so durchgeführt werden dürfen, wenn die Prozesse und deren Kontrolle ausgereift sind.

Produkt

Ziel der Software-Entwicklung ist ein Produkt, welches meist aus einem oder mehreren Programmen besteht. Die Unterteilung nach Produkten ist notwendig, damit das SCM-Werkzeug für mehrere Anwendungen genutzt werden kann, ohne mehrfach installiert zu werden. Für die meisten realen Entwicklungen ist die Einteilung nach Produkten zu grob. Deshalb existieren meist Unterkategorien, wobei diese Hierarchie häufig als Aufhänger für Zugriffsberechtigungen dient.

Konfigurationseinheit

Konfigurationseinheit meint in diesem Zusammenhang eine „beliebige Kombination aus Hardware, Software oder Dienstleistung“. Konfigurationsmanagement ist somit nicht per se an einen bestimmten Anwendungskontext und eine Systemkonfiguration gebunden.

siehe Konfigurationsmanagement (KM)

Weitere Objekte

Praktisch immer existieren, abhängig von der Philosophie des Werkzeugs, weitere Objekte. Diese betreffen häufig die Beziehungen der Objekte untereinander oder die Sicht auf diese, insbesondere auf die Dateien (Views, Worksets). Es kann sich um Hilfestellungen für den Umgang mit bestimmten Bestriebssystemen handeln, Gruppenberechtigungen, Delegationen, externe Prozesse etc. Ungelöst ist das Problem, wie Versionsänderungen an Datenbanken durchgeführt werden. Pragmatischer Ansatz ist die Verwaltung der SQL-Skripte, doch löst es nicht das Problem, dass sowohl die Datenmodelldifferenz zum Vorgänger als auch der Neuaufbau bereitgestellt werden müssen.

Reale Betrachtungen

Datenhaltung

Oben wurde aufgezeigt, dass die Strukturen in einem SCM-Werkzeug meist hierarchisch in unbestimmter Tiefe sind, während die einzelnen Teile meist die Eigenschaften von Objekten haben. Das macht die Speicherung in den weit verbreiteten relationalen Datenbanken schwierig, weil die Strukturen und Flexibilität nur schwer performant und wartbar abzubilden sind. Die Geschichte von IBM mit seinen SCM-Werkzeugen macht es deutlich.

IBM benutzte ursprünglich für Windows und Unix CMVC mit einer relationalen Datenbank. Sein Nachfolger war TeamConnect, das auf Objectstore, einer objektorientierten Datenbank, basierte. Die nächste Version wechselte zu DB2. IBM beendete die Linie und kaufte das Unternehmen Rational ein, welches Clearcase im Portfolio hatte. Die Anwendung basiert auf einer selbstentwickelten, objektorientierten Datenbank, während die Ergänzung Rational ClearQuest für die Prozessverfolgung verschiedene relationale Datenbanken benutzt.

Das Produkt Dimensions benutzt dagegen Oracle als relationale Datenbank, ergänzt um das Dateisystem des Servers als Versionsarchiv. Das Datenmodell ist nur teilweise normalisiert.

Kompatibilität

Der Mangel an akademischer Forschung und die fehlende Marktmacht eines einzelnen Herstellers sowie die oben nur angedeutete Komplexität, die sich auf der Zeitachse noch deutlich erhöht, sorgen für geringe Kompatibilität zwischen den einzelnen Produkten. Die Hersteller stellen zwar Werkzeuge bereit, welche die Daten bei einem Wechsel in ihr Produkt bringen, doch geschieht dies auf sehr niedrigem Niveau. Eine Migration ist daher genau zu planen, sehr aufwändig und in der Konsequenz meist unvollständig, weil die Kosten den Nutzen der Altdaten bei weitem übersteigen. Nach der Einführung sind weitere, erhebliche Investitionen zu tätigen, damit die SCM-Umgebung nutz- und wartbar ist. Die Situation ist den Herstellern bekannt und wird genutzt, um den Wettbewerb auf den Verkauf zu beschränken. Ein betriebenes System wird nur abgelöst, wenn Anforderungen und Lösungserbringung weit auseinander klaffen.

Ebenso ist die Integration in die Entwicklungsumgebung immer schlecht. Der einzig verbreitete Standard SCC von Microsoft ist auf reine Versionsverwaltung ausgelegt, wird aber von Herstellern für deutlich komplexere Dinge benutzt. In Konsequenz bedeutet dies, dass Entwicklungs- und Verwaltungswerkzeuge häufig bestimmte Versionskombinationen benötigen, um miteinander zu funktionieren. Sind diese Versionen jedoch noch von anderen Faktoren abhängig, kann als Schnittmenge schnell die leere Menge herauskommen. Nicht selten unterbleibt deshalb eine tiefere Integration oder die Übergänge weisen Brüche auf, die meist auch Sicherheitslücken öffnen (inoffizielle Versionen). Dabei sollten Projektverwaltung, SCM, Entwicklungsumgebungen sowie Testwerkzeuge integriert sein, um den Arbeitsprozess weitgehend zu automatisieren.

Es bedeutet auch keine Schwierigkeit, ein SCM-Werkzeug für Windows und eine bekannte Unix-Variante zu bekommen (Linux, Solaris, AIX, HP-UX). Doch darüber hinausgehend sind Plattformen wie MVS, AS400, OS/2 oder noch exotischere nur vereinzelt, häufig gar nicht unterstützt, wenn man von Open-Source-Versionsverwaltungen absieht.

Abgrenzung

SCM-Systeme sind Schwergewichte der Software-Entwicklung. Neben den oben dargestellten Minimalforderungen, die sie in stark fortgeschrittener Version bereitstellen, bieten sie kleinteilige Rechteverwaltungen, Variantenmanagement und ausgereifte Lifecycle-Verwaltungen. Sie sind deutlich komplexer als die leichtgewichtigen Verwandten „Versionskontrollsysteme“. SCM-Systeme sind als Open Software nicht bekannt.

Betriebseinführung

Die Einführung in den Betrieb ist schwierig und meist eine strategische Entscheidung. Die Kosten beschränken sich nicht auf den Kauf und die Wartung für das erste Jahr, sondern beinhalten zahlreiche Beratungen, die zu hohen Stundensätzen vom Hersteller erbracht werden. Dieses Geschäftsmodell ist von den Herstellern geduldet oder gar gewollt, weil Sekundärliteratur zu den Produkten nicht existiert. Die Produktdokumentation beschränkt sich meist auf Erklärung der Einzelheiten, lässt jedoch das Zusammenspiel der Komponenten zu einem gewünschten Ziel außen vor. Weiterhin sind Kosten für die Schulungen der Anwender zu erwarten, weil die meisten Produkte in der Benutzung nicht selbsterklärend sind, oder, soweit die Benutzerfreundlichkeit beim Basisprodukt gegeben ist, die Unternehmensprozesse in ihrer Komplexität nicht hinreichend einfach dargestellt werden können.

Darüber hinaus behindern meist die Entwicklungsteams die Einführung, weil häufig Prozesse und Arbeitsweisen geändert werden müssen, das laufende Geschäft gestört wird und „es nicht notwendig ist“. Die Benutzung des SCM-Werkzeugs beschleunigt typischerweise die Arbeit, doch der Mehrwert ist, weil er meist auf Kleinigkeiten basiert, kostenrechnerisch nicht erfassbar und damit argumentativ nicht verwendbar. Selten wird auch gesehen, dass vorgeschriebene oder gewünschte Berichte automatisiert erstellt werden können.

In Deutschland ist zudem die Zustimmung des Betriebsrats zwingend notwendig, weil alle Änderungen mitarbeiterbezogen protokolliert werden. Dadurch kann das SCM-Werkzeug zur Leistungskontrolle herangezogen werden.

Produktübersicht

Es gibt viele verschiedene Systeme auf dem Markt. Eine Übersicht über bekanntere Produkte:

• AccuRev
• eASEE
• BitKeeper
• ClearCase
• Team Foundation Server
• Perforce
• PureCM
• Sablime
• Serena Dimensions
• Serena PVCS
• SET-LIBER
• Smart Bear
• SpectrumSCM
• Surround SCM
• IBM Rational Synergy (ehem. Telelogic Synergy, Synergy/CM, ehem. CM/Synergy, ehem. Continuus CM)
• MKS Source

Folgende Produkte sind keine SCM-Systeme, sondern lediglich Versionskontrollsysteme:

• CVS
• Git
• Mercurial
• Microsoft Visual SourceSafe
• RCS
• Serena PVCS Version Manager
• SCCS
• Subversion (CVS-„Nachfolger“)

Siehe auch

• Versionsverwaltung
• Versionsverwaltung beim Dokumentenmanagement