In den letzten Jahren hat die Methodik der Software-Entwicklung einen immensen Aufschwung erfahren, vom "tricky programming" freischaffender Programmierkünstler über Phasenkonzepte, data-dictionary-gestütztes Prototyping bis hin zu den derzeit gerade Furore machenden CASE-Umgebungen auf PCs.
Während so die Erstellung von Software fortschreitend professioneller wurde, ist der Bereich der Software-Verwaltung, also das, was meist als Configuration Management (CIM) bezeichnet wird, immer noch weitgehend ein Entwicklungsgebiet geblieben.
Immer noch strickt sich jedes Rechenzentrum seine eigenen Werkzeuge für die Produktionsfreigabe von Programmen, weil es unter anderem auch auf diesem Sektor noch keine befriedigenden Standard-Verfahren gibt.
Andere DV-Abteilungen etablieren in solchen Fällen ein manuelles Verfahren mit allen damit verbundenen Risiken.
CIM heißt Sourcen-Verwaltung
Was sind üun die Anforderungen an ein CM-Verfahren, das wirklich "in the state of the art" ist?
Ein solches System muß in erster Linie ein System zur Verwaltung von Sourcen sein. Der herkömmliche Standpunkt, nur Programm-Source müsse beobachtet und verwaltet werden, ist kurzsichtig.
So kann eine mißglückte, aber nicht rechtzeitig als solche erkannte Änderung eines zentralen Macros oft weitreichendere Folgen für die Produktion nach sich ziehen als die mißglückte Änderung eines Programm-Moduls. Ebenso sind natürlich Jobcontrol, Spezifikationen oder Dokumentation wichtige und daher zu kontrollierende Sourcen.
Produktion und Entwicklung getrennt
Ein funktionierendes Konfigurations-Management muß eine klare Trennung zwischen der Produktions- und der Entwicklungsebene vornehmen. Der Übergang von einer Ebene zur anderen darf nur unter genau kontrollierten und protokollierten Bedingungen möglich sein - gegebenenfalls müssen Zwischenstufen zur Qualitätssicherung eingeschaltet werden.
Auch die Testebene ist in Umgebungen für Modulentwicklung und Einzeltest, für Integrationstest und Fachbereichsschulung zu gliedern.
Da im Laufe der Verwaltung vom System auf die Source-"Module" Transportfunktionen angewendet werden müssen, die unter Umständen vom Typ der Source (Programm, Macro, JCL) abhängen, muß das System zu jeder davon einen Typ verwalten.
Ein solches Paar "Source-Name/zugehöriger Typ" muß im System eindeutig sein, sprich, es darf wohl ein Programm "XYZ" und ein Macro "XYZ" geben, niemals aber zwei verschiedene Programme mit dem gleichen Namen "XYZ".
Besitzt ein Source-Typ abhängige Objekte (ein Quellprogramm beispielsweise "besitzt" die aus ihm erzeugten Loadmodule), so muß der Zusammenhang Source/Objekte außerhalb des Systems in einem Data-Dictionary-System festgelegt sein und dort über Schnittstellen vom System hinterfragt werden können.
Eine fest eingebaute Abhängigkeit wie die bisher oft gebrauchte "Name der Source = Name des Loads" ist schon deswegen nicht mehr sinnvoll, weil moderne Metasprachen es ermöglichen, die Anwendungslogik nur einmal zu codieren und daraus verschiedene Loadmodule wie für Batch- und Dialogverarbeitung zu generieren.
Sourcen kommen aus der Produktion zum Testen
Auf der Grundlage dieser Prämissen muß ein System des Konfigurations-Managements in der Lage sein, die im folgenden näher erläuterten Funktionen auszuführen. 1. Holen einer Source aus der Produktion in den Test (Logout): Das durch Name und Typ definierte Source-Modul wird im Test-Bereich für die Änderung zur Verfügung gestellt. Diese Funktion kopiert nicht nur die Source aus dem Produktions-Archiv, sie
- stellt auch alle abhängigen Objekte zur Source im Testbereich zur Verfügung. Das geschieht indem sie zum Beispiel Data-Dictionary-Einträge vom Produktions- in den Test-Status kopiert.
- führt das sogenannte "book-keeping" durch. Das bedeutet, daß Angaben wie Datum, Zeit und User-ld des Logout in einem Log-File festgehalten werden.
- sperrt die produktive Source zum Schutz gegen Parallel-Updates.
- verknüpft mit dem Logout eventuelle Zusatzinformationen wie "Nummer des Programmierauftrages", "Zugehörigkeit zu einer Verarbeitungseinheit". Dabei ist eventuell eine Schnittstelle zu einem benutzereigenen Auftragsverwaltungssystem erforderlich.
Ein nur bei Programmsource vorkommender Sonderfall ist das Notfall-Logout. Dieses wird nötig, wenn die Produktionsversion eines gerade in Änderung befindlichen Programmes abstürzt und deshalb parallel zur "regulären" Änderungsversion schnell eine Notkorrektur an der Produktionsversion vorgenommen werden muß.
Dieses Notfall-Logout ist vom System natürlich ebenfalls zu unterstützen, allerdings mit Einschränkungen:
- nur autorisierte Benutzer sind berechtigt, ein solches Verfahren durchzuführen,
- es darf neben der regulären Änderungsversion nur maximal eine Notversion geben,
- der Entwickler, der die reguläre Version bearbeitet, erhält automatisch einen Hinweis auf die in der Notversion vorgenommenen Änderungen.
Namensreservierung schließt Dubletten aus
2. Reservieren eines Namens für ein neues Sourcemodul: Diese Funktion bekommt als Input mindestens den Namen und den Typ des neu zu entwickelnden Sourcemoduls. Sie prüft, ob bereits ein Modul mit der angegebenen "Name/Typ"-Kombination in der gesamten Umwelt existiert; wenn nicht, wird für die gewünschte Kombination ein Eintrag in der Test- und Entwicklungsumgebung erzeugt.
Darüber hinaus verlangt die Namensreservierung, daß die Buchführung des Systems für das Konfigurations-Management (CM) über die vorhandenen Sourcemodule vonständig ist. Das beinhaltet auch alle vor der Einführung des Systems jemals in Produktion gegangenen Sourcen.
Da im Sinne eines CM ein Sourcemodul immer im Zusammenhang mit dem Anwendungssystem zu sehen ist, dem es angehört, sollte sinnvollerweise bei der Reservierung des Namens auch bereits das Anwendungssystem mit abgefragt und abgespeichert werden.
Das erwähnte Verzeichnis der Sourcen kann und sollte beim Vorhandensein eines zentralen Data-Dictionary-Systems natürlich eng an dieses gekoppelt werden.
Die Module werden bis zur Produktionsreife gesammelt
3. Bereitstellen einer Konfiguration für die Übergabe: Um insbesondere bei umfangreicheren Anwendungssystemen mit insgesamt mehreren hundert Modulen eine geordnete Releaseführung und korrekte Überstellung in die Produktion zu erreichen, übergibt nicht jeder einzelne Entwickler seine gerade fertigen Module gesondert und direkt. Vielmehr stellt der einzelne Entwickler seine Arbeiten in einen "Produktions-Bereitstellungsraum". Dieser gehört zwar noch zur Testumgebung, enthält aber nur bereits produktionsreife Elaborate.
Dort kann dann der Projektverantwortliche oder ein von ihm beauftragter Mitarbeiter
Versionen für die Produktionsübergabe zusammenstellen. Aus diesem Raum können aber auch letzte Paralleltests für die Produktion gefahren werden.
Um dieses Verfahren abzusichern, sollten bei der Realisierung zwei Gesichtspunkte beachtet werden:
- Das Klingelknopf-Prinzip: Der Übergebende meldet nur an, was zur Übernahme ansteht, er drückt nichts in den Bereitstellungsraum. Der für die Produktionsüberstellung verantwortliche Mitarbeiter kontrolliert die angemeldeten Sourcen, übernimmt sie durch Ankreuzen oder weist sie zurück.
- Automatisches Kompilieren:
Bei der Übernahme von Programm-Modulen sollten die abhängigen Loads nicht einfach kopiert werden. Um eine Übereinstimmung von Source und Load zu sichern, sollten die Loads bei der Übernahme automatisch durch Compile/Link neu erstellt werden. Dies bedingt, daß die Compile- und Link-Anweisungen zu einem Load mit diesem in irgendeiner Form mit abgespeichert werden.
4.Übergeben einer Konfiguration an die Qualitätssicherung (Log-in): Diese Funktion ist die letzte in einem Änderungszyklus, die noch im Test-Bereich angestoßen wird. Mit ihr übergibt der Softwareentwickler beziehungsweise der für die Produktionsübergabe Verantwortliche Sourcen (ein einzelnes Modul, eine Gruppe von Sourcen oder ein gesamtes neues Release) an die letzte Instanz vor der eigentlichen Produktion. Dabei hat folgendes zu geschehen:
- die zu übergebenden Sourcen werden aus der Testumgebung in eine eigene, vom Test abgeschottete Ebene für die Qualitätssicherung geholt. Abhängige Objekte, wie Data-Dictionary-Einträge, werden dabei mitgenommen;
- zugehörige Loadmodule werden durch automatischen Compile und Link in dieser Ebene neu erzeugt, um die Übereinstimmung von Source und Load in jedem Falle zu erzwingen. Die dabei erzeugten Listings können auch als Unterlagen für die EDV-Revision oder für die Fehlersuche bei Störungen in der Produktion in einem dafür geeigneten Medium abgelegt werden.
- Als letzter Schritt einer erfolgreichen Übergabe hat ein Clean-Up in der Testumgebung zu erfolgen.
Vor dem Einsatz steht die Qualitätsprüfung
Damit ist dem Entwickler die Verfügungsgewalt über die geänderte Source entzogen. Die Abteilung für Qualitätssicherung kann nun, falls gewünscht, Code-Inspektionen vornehmen, die Einhaltung hausinterner Richtlinien prüfen und beanstandete Source-Module an den Entwickler zurückverweisen (Login-Reject), was die logische Umkehrung des oben beschriebenen Prozesses zur Folge hätte. Die Hauptfunktion dieser Ebene (und der Grund, warum sie in jedem Fall in einem CM-Verfahren realisiert sein sollte) ist aber die Abstimmung der Übergaben mit der laufenden Produktion.
Nur damit kann gesichert werden, daß nicht etwa während eines Produktionslaufes eines komplexeren Verfahrens beteiligte Module ausgewechselt werden. Außerdem findet hier auch die Koordination der Übergaben bei Änderungen statt, die mehr als ein Anwendungssystem betreffen.
Schließlich erfolgt die Produktions-Freigabe
5. Überspielen der Konfiguration aus der Qualitätssicherung in die Produktion: Die Qualitätssicherung selektiert Einzelmodule oder Modulgruppen und gibt diese in die Produktion frei. Dabei werden die Source und alle ihre abhängigen Objekte aus der Umgebung der Qualitätssicherung in die Produktion kopiert die für Arbeitsvorbereitung oder Produktionskontrolle zuständigen Mitarbeiter erhalten ein Übergabeprotokoll und die Anderungsperre, die zum Schutz gegen Doppel-Update über der Source liegt, wird nun aufgehoben. Damit schließt sich der Zyklus einer Software-Änderung oder Neuentwicklung.
Neben den angeführten Aspekten zur Logik eines modernen CM-systems gäbe es natürlich auch noch eine ganze Reihe von Punkten bezüglich der technischen Realisierung zu sagen. Dies würde jedoch den Rahinen dieser Ausarbeitung weit überschreiten.