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 Bearbeiten
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, 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 Bearbeiten
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 ist.
- 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 systematisch 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 über dasselbe terminologische Verständnis zum Sachverhalt verfügen. Bei der Produkt- und Softwareentwicklung fallen viele unterschiedliche Arbeitsergebnisse an, z. B. Programme und Komponenten, Dateien wie Lastenhefte und Architekturskizzen, Release Notes oder Changelogs, Testspezifikationen und Testdaten, Änderungsanträge oder Quellcode.
Das Konfigurationsmanagement verwaltet und labelt zusammengehörende Arbeitsergebnisse (Konfigurationseinheiten) als sogenannte Konfigurationen.
Grundlegende Objekte des Software-Konfigurationsmanagements Bearbeiten
Grundlegende Objekte, die ein SCM-Werkzeug abbilden können muss, sind Projekt, Datei, Konfigurationseinheit, Baseline und Produkt.
Projekt Bearbeiten
Ein Projekt zeichnet sich durch Anfang, Ende und Umfang aus. Weil in der Entwicklung gemeinhin damit etwas Umfangreiches gemeint ist, wird häufig zwischen Teilprojekt, Änderung, Change Order, Change Request, Task o. ä. unterschieden. Es ist zwar möglich, mit nur einer Hierarchiestufe auszukommen, doch wird die Arbeit dadurch meist unübersichtlich. Deshalb geben die Werkzeuge mehrere Stufen vor oder lassen es zu, diese frei zu definieren, um eine Delegation an andere Personen oder Teams zu ermöglichen. Typische Hierarchien sind Project-Task-Subtask.
Datei Bearbeiten
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. Wenn diese bei der Auswahl des SCM-Werkzeugs nicht beachtet werden, kann dies hinterher zu Problemen führen. Ein solches ist z. B. die thematische 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 Aspekte 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 berücksichtigt werden, entfallen jedoch bei den meisten Produkten. Auf die Änderungszeit wird jedoch häufiger geachtet, weil sie beim Aufspielen 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 ist abhängig vom Build-System ab das der Anwender benutzt.
Baseline Bearbeiten
Weil sich im Archiv zahlreiche Versionen befinden, muss es einen Mechanismus geben, der die zusammengehörigen Versionen 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 – allerdings nur selten ausreichend gut unterstützt – ist das Veränderungsmanagement mittels Projekten, in denen Änderungen von Prozessen nur durchgeführt werden dürfen, wenn die Prozesse ausgereift sind.
Produkt Bearbeiten
Ziel der Software-Entwicklung ist ein Produkt, das 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 den Zugriffsberechtigungen dient.
SW-Konfigurationseinheit Bearbeiten
SW-Konfigurationseinheit meint in diesem Zusammenhang eine geeignete, ausgewählte, zu anderen SW-Konfigurationseinheiten abgegrenzte Einheit (z. B. Betriebssystem, Treiber u. ä.). Diese Konfigurationseinheit steht in Bezug zu einer beliebigen Kombination anderer Konfigurationseinheiten aus Hardware, Software, Infoware oder Dienstleistungen. SW-Konfigurationsmanagement ist somit nicht per se an einen bestimmten Anwendungskontext und eine spezifische Systemkonfiguration gebunden.
Weitere Objekte Bearbeiten
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, sodass sowohl die Datenmodelldifferenz zum Vorgänger als auch der Neuaufbau bereitgestellt werden müssen.
Versionsverwaltungssysteme Bearbeiten
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 Bearbeiten
Datenhaltung Bearbeiten
Oben wurde aufgezeigt, dass die Strukturen in einem SCM-Werkzeug meist hierarchisch in unbestimmter Tiefe gegliedert 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 dies 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, das 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 Bearbeiten
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. Die Konsequenz ist, dass Entwicklungs- und Verwaltungswerkzeuge häufig bestimmte Versionskombinationen benötigen, um zusammen 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 ist auch nicht schwierig, ein SCM-Werkzeug für Windows und eine bekannte Unix-Variante zu erhalten (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 Bearbeiten
Die Einführung in den Betrieb ist schwierig und meist eine strategische Entscheidung. Die Kosten beschränken sich nicht Alllein 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 darstellbar und damit argumentativ nicht zu nutzen. 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 Bearbeiten
Diverse Softwareentwicklungsprodukte Bearbeiten
Es gibt viele verschiedene Systeme auf dem Markt. Eine Übersicht über bekanntere Produkte:
- AccuRev
- PREEvision
- eASEE
- BitKeeper
- ClearCase
- Azure DevOps Server (ehemals Team Foundation Server)
- Perforce
- PureCM
- Sablime
- Serena Dimensions CM
- SET-LIBER
- Smart Bear
- SpectrumSCM
- Surround SCM
- IBM Rational Synergy (ehem. Telelogic Synergy, Synergy/CM, ehem. CM/Synergy, ehem. Continuus CM)
- MKS Source
- in-STEP BLUE
Open Source:
Versionsverwaltungssysteme Bearbeiten
Folgende Produkte sind keine SCM-Systeme, sondern lediglich Versionskontrollsysteme:
Siehe auch Bearbeiten
- Versionsverwaltung beim Dokumentenmanagement
- Scrum
Literatur Bearbeiten
- 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.