Software-Configuration-Management

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Die fraglichen Angaben werden daher möglicherweise demnächst entfernt. Bitte hilf der Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst. Näheres ist eventuell auf der Diskussionsseite oder in der Versionsgeschichte angegeben. Bitte entferne zuletzt diese Warnmarkierung.

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

SCM wird häufig auch als Versionsverwaltung von Software verstanden.

Teilweise werden die Aufgaben eines SCM 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.

Grundlegende Betrachtungen[Bearbeiten]

Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Man spricht insgesamt von drei Generationen von Software-Versionsverwaltungssystemen. Die ersten zwei Generationen sind von zentral gehaltener Datenhaltung bestimmt. Die dritte Generation ist dezentral orientiert, siehe Git, Bazaar, Mercurial.

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[Bearbeiten]

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[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, 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[Bearbeiten]

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. 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[Bearbeiten]

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[Bearbeiten]

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[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, dass sowohl die Datenmodelldifferenz zum Vorgänger als auch der Neuaufbau bereitgestellt werden müssen.

Reale Betrachtungen[Bearbeiten]

Datenhaltung[Bearbeiten]

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[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 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[Bearbeiten]

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

Betriebseinführung[Bearbeiten]

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[Bearbeiten]

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

Open Source:

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

Siehe auch[Bearbeiten]