Software-Configuration-Management

Das Software-Configuration-Management (SCM) oder Software-Konfigurationsmanagement ist eine Spezialisierung des Konfigurationsmanagements auf alle Aktivitäten und Ergebnisse im Bereich der Software-Entwicklung sowie deren Nutzung in Produkten. Dazu gehört unter anderem die geeignete Berücksichtigung andockender systemeigener Produktkomponenten und deren Varianten (bspw. über Kompatibilitätsmatrizen) über den gesamten Produktlebenszyklus hinweg.

Grundlegendes

SCM-Systeme sind Schwergewichte unter den Werkzeugen zur Softwareentwicklung. Neben Minimalforderungen, die sie in stark fortgeschrittener Version bereitstellen, bieten sie kleinteilige Rechteverwaltungen, Variantenmanagement und ausgereifte Lifecycle-Verwaltungen. Sie sind deutlich komplexer als die leichtgewichtigen Versionsverwaltungssysteme.

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

Eine akademische Forschung zu dem Thema findet nur in sehr bescheidenem Umfang statt, und im universitären Lehrplan der Informatiker erscheint das Thema SCM oftmals ü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 spezifische Ansichten über Umfang, Begriffe, Integrationen, Verfügbarkeit und Kompatibilität.

Konfigurationen gemäß internationalem Standard

In der 24765-2017 – ISO/IEC/IEEE, die als internationaler Standard Begriffe für System- und Software-Engineering festlegt, werden Konfigurationen wie folgt umschrieben:

  • Anordnung eines Computersystems oder einer Komponente, die sich durch die Anzahl, Art und Verbindungen seiner Bestandteile bestimmt.
  • die funktionellen und physikalischen Eigenschaften von Hardware oder Software, wie sie in der technischen Dokumentation festgehalten oder in einem Produkt verwendet werden.
  • Anordnung eines Systems oder Netzwerks, wie durch die Art, Anzahl und Hauptmerkmale seiner Funktionseinheiten definiert.
  • Anforderungen, Entwurf und Implementierung, die eine bestimmte Version eines Systems oder einer Systemkomponente definieren.
  • Art und Weise, in der die Hard- und Software einer Informationsverarbeitung System organisiert und miteinander verbunden sind.
  • Sammlung von Objekten, die an Schnittstellen interagieren können.

Wer also über Konfigurationen bzw. Konfigurationsmanagement spricht, sollte sicherstellen, dass alle Gesprächsteilnehmer dasselbe Verständnis zum Begriff besitzen und teilen. Bei der Produkt- und Softwareentwicklung fallen viele unterschiedliche Arbeitsergebnisse wie bspw. Programme und Komponenten, Dateien wie Lastenhefte und Architekturskizzen, Release Notes oder Changelogs, Testspezifikationen und Testdaten, Änderungsanträge oder Quellcode an.

Das Konfigurationsmanagement verwaltet und labelt zusammengehörende Arbeitsergebnisse (Konfigurationseinheiten) als sogenannte Konfigurationen.

Grundlegende Objekte des Software-Konfigurationsmanagements

Grundlegende Objekte, die ein SCM-Werkzeug abbilden können 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 befinden, 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. Die sinnvollste Methode, welche nur selten ausreichend gut unterstützt wird, ist das Veränderungsmanagement mittels Projekten, in denen Änderungen von Prozessen nur durchgeführt werden dürfen, wenn die Prozesse 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 vorwiegend Unterkategorien, wobei diese Hierarchie häufig als Aufhänger für Zugriffsberechtigungen dient.

SW-Konfigurationseinheit

SW-Konfigurationseinheit meint in diesem Zusammenhang eine geeignete, ausgewählte, zu anderen SW-Konfigurationseinheiten abgegrenzte Einheit (bspw. Betriebssystem, Treiber ...). Diese Konfigurationseinheit steht in Bezug zu einer „beliebigen Kombination anderer Konfigurationseinheiten aus Hardware, Software, Infoware oder Dienstleistungen“ steht. SW-Konfigurationsmanagement ist somit nicht per se an einen bestimmten Anwendungskontext und eine Systemkonfiguration gebunden.

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 Betriebssystemen 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.

Versionsverwaltungssysteme

Der Gebrauch von Versionsverwaltungssystemen ist mittlerweile in der Softwareentwicklung selbstverständlich geworden. Man spricht insgesamt von vier Generationen von Software-Versionsverwaltungssystemen. Die ersten zwei Generationen sind von zentral gehaltener Datenhaltung bestimmt. Die dritte Generation ist dezentral orientiert, siehe Git, Bazaar, Mercurial. Speziell bei Open-Source-Projekten nimmt das dezentrale Versionsverwaltungssystem "Git" eine dominante Stellung ein.

Während das Software-Konfigurationsmanagement Teil des Softwaregestaltungsprozesses ist – und damit zum Softwaredesign gehört, ist die Versionsverwaltung von Software ein davon unabhängiges Unterfangen.

Teilweise werden die Aufgaben eines SCM in der Versionsverwaltung manuell gehandhabt.

Ein typisches in Unternehmen anzutreffendes Szenario ist die Versionsverwaltung, die mit Datenbanken auf Basis von Lotus Notes oder Excel ergänzt wird. Dem stehen leistungsfähige Tools gegenüber, die ebenfalls in der Industrie eingesetzt werden.

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 auseinanderklaffen.

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, AS/400, OS/2 oder noch exotischere nur vereinzelt, häufig gar nicht unterstützt, wenn man von Open-Source-Versionsverwaltungen absieht.

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 überwiegend 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 größtenteils 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

Diverse Softwareentwicklungsprodukte

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

Open Source:

Versionsverwaltungssysteme

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

Siehe auch

Literatur

  • Gerhard Versteegen: Konfigurationsmanagement. (= Xpert.press). Springer, Berlin 2003, ISBN 978-3-540-43622-5.
  • Rainer Heinold: Rechtzeitiges Konfigurationsmanagement. In: Gerhard Versteegen (Hrsg.): Software Management: Beherrschung des Lifecycles (= Xpert.press). Springer, Berlin, Heidelberg 2002, ISBN 978-3-642-56367-6, S. 137–159.
  • Jörg Noack: Konfigurationsmanagement. In: ders. (Hrsg.): Techniken der objektorientierten Softwareentwicklung (= Xpert.press). Springer, Berlin, Heidelberg 2001, ISBN 978-3-642-63991-3, S. 340–376.