Ob nun CASE oder nicht - das Management von Konfigurationen und die Kontrolle von Versionen ist ein brandheißes Thema, das erhebliche Feuergefahr für die Unternehmen birgt. PC-gestützte Tools können indes für Abhilfe sorgen.
In vielen Unternehmen wird seit geraumer Zeit an internen Lösungen gebastelt, weil der Markt kein akzeptables System für den kommerziellen Mainframe-Sektor bereithält. Die Verlagerung der Anwendungsentwicklung auf Workstation-Ebene stellt jedoch Abhilfe in Aussicht. Ferner gibt es die Möglichkeiten PC-gestützter Tools, die sich in den USA bereits eines großen Markterfolges erfreuen und von denen eines kürzlich sogar in den Kreis der AD/Cycle-Tools erhoben wurde.
"Verteilt" ist eines der meistgebrauchten Schlagworte in der DV-Szene. Nach verteilter Datenhaltung, verteilten Anwendungen und gar "verteilten Repositories" steht uns als jüngster Begriff "Distributed Configuration Management (DCM)" ins Haus. Hinter diesem US-Modewort verbirgt sich aber ein durchaus ernst zu nehmendes Problem, nämlich das der mangelhaften Kontrolle und Kontrollierbarkeit von SW-Konfigurationen und -Versionen.
Air Force hat die Vorreiterrolle inne
Wer kennt es nicht - dieses schleichende Anwachsen unterschiedlicher Versionen von Anwendungen? Bewußt oder unbewußt steht man plötzlich vor einer unübersehbaren Anzahl von Varianten, die ohne Hilfsmittel nicht mehr zu identifizieren sind. Was fehlt, ist ein Tool, das Versionen kontrolliert, bei Revisionen hilft, parallele Entwicklungen unterstützt, Standards setzt, Bausteine speichert und Konfigurationen zusammenstellt, ein entsprechendes Berichtswesen liefert - einfach den gesamten Prozeß überwacht und sichert. Aber wo ein solches Hilfsmittel hernehmen? Bei den Tool-Herstellern für Mainframes gibt es bisher nur Fehlanzeige. Also behalf man sich mit unzureichenden Eigenentwicklungen oder - schloß einfach die Augen.
Ursprünglich kommt das Konzept des Konfigurationsmanagements, wie so vieles in der DV-Szene aus den USA. Die ersten Gehversuche wurden seinerzeit bei der US Air Force unternommen. Ziel war, ein effektives Änderungswesen, insbesondere in der Entwicklungsphase, zu gewährleisten. Das Konzept gliedert sich in drei wesentliche Aspekte:
Die Konfigurationsbestimmung legt die Konfigurationsbasis fest und damit den Bezugspunkt für nachfolgende Änderungen.
Die Konfigurationssteuerung regelt den Änderungsvorgang in den unterschiedlichen Entwicklungsphasen.
Die Konfigurationsverfolgung hat als Ziel, gelöste Probleme bis zu ihren Ursachen hin zurückzuverfolgen, die aktuelle Konfiguration abzufragen und Soll-Ist-Vergleiche zwischen dem aktuellen Stand der Dokumentation und der Projektdurchführung zu leisten.
Dadurch müssen Vorgänge gesteuert und koordiniert werden. Dies läßt sich nicht mehr manuell, sondern nur noch mit geeigneten Tools durchführen. Die Notwendigkeit für ein DCM hat sich inzwischen auf den gesamten SW-Lebenszyklus ausgeweitet und überspannt alle Disziplinen der Entwicklung - von technischen Anwendungen bis hin zu IS-Systemen.
Mehrere Leistungsstufen des DCM-Systems für unterschiedliche Gruppen von Anwendern müssen unterstützt werden:
- kleine Teams, die kleine bis mittlere Anwendungen mit einer begrenzten Anzahl von Versionen und Releases schreiben,
- mittlere Teams, die große Applikationen entwickeln mit diversen Versionen, mehreren Releases und auf unterschiedlichen Betriebssystemen arbeiten, große Teams, die sehr große Systeme unter formal geregelten Bedingungen erstellen und dabei eine größere Anzahl Versionen und Releases für verschiedene Operations- und Zielsysteme zu verwalten haben.
Damit zeigt sich sofort, daß ein Produkt, das erfolgreich solche Marktbedingungen erfüllen soll, flexibel modular konfigurierbar sein muß, so daß es auch gegebenenfalls sich ändernden Anforderungen eines Unternehmens folgen kann - sprich: mit dem Unternehmen wächst. Moderneren Tools gelingt es, einer solch geballten Mischung aus Bedarf und Bedürfnissen gerecht zu werden. Welche speziellen Bedürfnisse haben solche Teams nun, und welche Funktionalität eines DCM-Systems nutzen sie?
Easy to use - Bedingung für kleine Teams
Betrachtet man die Gruppe der kleinen Teams, findet sich die Notwendigkeit, Moduländerungen kontrollieren zu können, das Überschreiben von Änderungen zu vermeiden und Sackgassen-Lösungen wieder zurücknehmen zu können. Release-Stände sind zu führen. Und es besteht aus Produktivitätsgründen der Wunsch, die Herstellung von Executables zu automatisieren und zeitraubendes Rekompilieren zu vermeiden. Sie benötigen ein Konfigurationsmanagement, das sich schnell installieren läßt, leicht und ohne großen Lern- und Planungsaufwand zu nutzen ist, transparent bleibt und mit ihren anderen Tools zusammenarbeitet. Unter einem guten DCM-System werden solche Teams alle Module, die zu einem Projekt gehören, unter Log-Files zusammenschließen, die ebenso die "Deltas" führen - also die Änderungen eines Moduls und die Informationen über die Änderungen Log-Files lassen sich auch im nachhinein für bestehende Versionen aus dem Archiv konstruieren und natürlich auch in der laufenden Revision. Kleine Teams haben Bedarf an einem flexiblen, einfachen Kontrollsystem für ihre Versionen. Sie benötigen keine hochformalisierten Strategien und Regelungen. Für eine saubere und klare Versionsführung reicht in aller Regel die Führung ihrer Varianten unter einem gemeinsamen "sprechenden" Label. Durch Eingabe von "TEST 21" oder "REL 9_90" erhält man alle Module und Informationen, die mit diesem Versionsnamen verbunden sind, und kann die spezifizierte Operation darauf ausführen .
Obwohl die Teams klein sind, haben sie gelegentlich Probleme bei simultan ausgeführten Änderungen, bei denen die Arbeit einzelner Mitglieder gegenseitig überschrieben werden kann. Hier helfen einfache Features weiter, wie die Möglichkeit, Module mit "Locks" zu belegen oder ein unbeeinflußtes Arbeiten unter einer "Zweig"-Variante durchzuführen.
Mit "Make"-Files
Systeme herstellen
Mit sogenannten "Make"-Files lassen sich ganze Systeme recht effizient herstellen. Die Make-Files beinhalten alle Informationen über die Abhängigkeiten zwischen den Modulen und den Regeln für die Zusammenstellung eines Systems, einschließlich aller Compiler- und Linker-Schalter und anderer Tool-Kommandos. Zwischenzeitlich geänderte Module werden automatisch erkannt, und nur diese und davon abhängige Module werden rekompiliert.
Umfangreiche Projekte mit einer Vielzahl von Modulen und Releases zu bearbeiten ist die Aufgabe von mittelgroßen Teams. Für diese Teamgröße hat Produktivität eine viel höhere Bedeutung. Die Teamleiter und ihre Manager sehen DCM als ein Mittel, die Teamleistungen zu koordinieren, Hunderte oder gar Tausende von Modulen zu überblicken und eine große Anzahl von Versionen zu führen. Der Umfang der Projekte macht optimale Implementierungsprozesse wichtig. Die Teams müssen sich dabei gegebenenfalls in heterogenen Netzwerken und auf unterschiedlichen Plattformen bewegen.
Solche Teams arbeiten in der Regel in weitgefächerten Entwicklungs-LANs. Ihr DCM-System muß komplexe Projektarchitekturen unterstützen und eventuell sogar geographisch verteilte Projekte verwalten können. Datenzugriffe innerhalb großer LANs und WANs müssen für die Nutzer transparent gehalten werden, ohne daß sie zu wissen brauchen, wo die Daten residieren.
Spiltten in
Entwisklungszweige
Aus diesem Grunde muß das DCM deutlich anders konfiguriert sein als bei kleinen Teams. Eine größere Anzahl User benutzt die LAN/WANs, und diese benötigen eine feinmaschige File- und Funktionssicherheit. Beides dient dazu, nicht autorisierte Zugriffe zu verhindern und zufällige Fehlnutzungen zu vermeiden. Um die Entwicklungsarbeit zu sichern und zu beschleunigen, benutzen sie referenzierende Führungsfunktionen. Die Software-lngenieure greifen auf Module über ihre logischen Namen zu - die physikalische Lokation auf dem LAN/WAN managed das DCM-System auch über Betriebssystemgrenzen hinweg. Die zugehörigen Log-File-Formate werden in allen Environments, auf die das DCM-System zugreift, gleichgehalten, unabhängig davon, ob das ursprüngliche File-Format differiert.
Bei dieser Größe der Projektteams würde sich die Log-Strategie kleinerer Teams als Flaschenhals erweisen. Hier erweist sich die Möglichkeit des Splittens in Entwicklungszweige als vorteilhafter Mittels Merge-Funktionen lassen sich dann diese Verzweigungen automatisiert zusammenführen. Zusammenführungskonflikte werden angezeigt und können im Online-Verfahren behoben werden. Der daraus resultierende Produktivitätsgewinn ist verblüffend. Die System-Ingenieure können ihre Arbeit ausführen, ohne sich darum kümmern zu müssen, wer gerade an was arbeitet. Konfliktlösungsprobleme werden eher zur Ausnahme als zu einer permanenten Sorge.
Sauberes Berichtswesen in DCM lebenswichtig
Versionsverzweigung ist ein weiteres Feature, das wichtig wird, wenn Software auf unterschiedlichen Maschinen und Betriebssystemen laufen soll oder spezielle Versionen released werden sollen. Die Verzweigungsmanagement-Funktionen wandeln das Bearbeiten von getrennten Versionen von einer unzumutbaren Belastung zu einer erfüllbaren Wartungsaufgabe.
Mittels eines einzigen Make-Files können anschließend komplette Systeme für unterschiedliche Environments gebaut werden, wobei das jeweilige Betriebssystem automatisch identifiziert wird und die jeweiligen Module und Tools angesprochen werden.
Erhebliche Produktivitätsgewinne lassen sich zugleich dadurch erzeugen, daß automatisch nur noch die modifizierten und davon abhängigen Module rekompiliert werden - und das ohne Sorgen, ob dies auch wirklich konform zum Gewünschten ausgeführt wird.
Große Teams stellen größte Projekte unter sorgfältig definierten und formalen Organisationsformen her. Ein sauberes Konfigurations-Management ist absolut kritisch für den Herstellungsprozeß. Die Implementation einer DCM stellt damit eine strategische Entscheidung dar.
Solche Teams sind zu einer strengen Qualitätssicherung verpflichtet, die präzise alle Änderungen der Anwendungen verfolgt. Ein sauberes Berichtswesen innerhalb des DCM wird lebenswichtig, um die Erfüllung von Requirements der Spezifikation nachweisen zu können. Für das Tuning der Systeme kann ausreichend Zeit investiert werden, da in aller Regel von jeder noch so kleinen Performance-Verbesserung die Organisation profitiert.
Hohe Ansprüche werden auch an das User-Interface des DCM-Systems und seine Flexibilität gestellt. Auch an die Sicherheitsfunktionen sind höchste Maßstäbe anzulegen, um zufällige fatale Fehler weniger erfahrener Mitarbeiter weitgehend auszuschalten. Den implementierten Verfahren zur Zugriffsberechtigung kommt oft eine große Bedeutung zu.
Große Teams haben unterschiedliche Ausrichtungen auf Zielsysteme, arbeiten auf weitreichenden LAN/WANs und erwarten gegebenenfalls eine Synchronisation der LAN-basierten DCM-Systeme gegen ein Mainframe-Bibliothek-System.
DCM-Systeme in großen
Teams sind zeitsparend
Die Gruppierungs- und Verzweigungsfähigkeiten des DCM-Systems erweisen sich in großen Teams als ausgesprochen zeitsparend.
Gleiches gilt für die "Labeling"-Funktionen, die durch ihre besondere Strukturierung selbst in solch großen Systemen die Möglichkeit eröffnen, mit nur einem einzigen Label beispielsweise den letzten Stand aller Module zu erfassen Auch ein phasenweises Labeling der Versionen ist möglich, wobei ein automatisiertes konsistentes Renaming der nachfolgenden Phasen-Versionen eingeschaltet werden kann. Das DCM-System muß eine virtuell unbegrenzte Anzahl an Versions-Labels führen können, um die Versionsvielfalt so umfangreich wie nötig zu erlauben.
Eine automatisierte Versionsverwaltung und ein Change-Management ohne unnötiges Recompiling sind hier von noch größerer Bedeutung. Auch muß jede frühere Version jederzeit identisch wiederholbar sein und Unterschiede zu einer vorangegangenen Variante sind automatisch aufzuspüren und anzuzeigen.
Moderne DCM-Systeme sind in der Lage, alle maschinenspeicherbaren Informationen wie Requirement-Spezifikationen, Dokumentation, Änderungsanforderungen, Reports etc. zu speichern und in Synchronisation mit der SW-Version zu halten sowie Änderungen dazu in analoger Form zu führen. Wie bei den Source- und Object-Files wird permanent festgehalten, wer welche Veränderungen vorgenommen hat und wann sie warum gemacht wurden.
DCM-Versionen jetzt an Front-ends gebunden
Die bisherige DCM-Versionen waren angebunden an Backend-Tools. Erste Hersteller haben ihre Links bereits auf marktgängige Front-ends zum Beispiel aus AD/Cycle ausgedehnt. Dies erlaubt zukünftig Change- und Versionskontrolle auch in den wichtigen frühen Phasen. Da jede Art File und seine Änderungen durch ein solches DCM-System erfaßt werden können, sind label-gesteuerte Zugriffe auf alle Arten Diagramme, Data Dictionaries, Spezifikationen, Bibliotheken, Tools, Bug-Reports und Testfälle ebenso möglich wie auf Source- und Object-Files und Dokumentationen. Damit schließt sich gleichzeitig eine unübersehbare Lücke in IBMs AD/Cycle-Konzept.