Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.11.1996 - 

Konfigurations-Management bei FJA Feilmeier & Junker GmbH

Prozeßorientiertes Vorgehen bei der Software-Entwicklung

Neben der fachlichen Kompetenz für die Konzeption von Softwarelösungen ist die effiziente Entwicklung entscheidend, um auf dem Markt bestehen zu können. Effizienz bedeutet, höchste Qualität in immer kürzeren Zeiträumen zu erbringen. Hinzu kommt ein hohes Maß an Flexibilität, bei dem das Management der Lösungsprozesse im Mittelpunkt steht.

Um die Programmierung zu optimieren, setzt FJA Feilmeier & Junker GmbH seit Ende 1994 ein prozeßorientiertes Tool für das Konfigurations-Management ein. Darunter hat man sich eine Art Workflow-System für die Software-Entwicklung vorzustellen.

Bereits 1993 wurde durch die stark wachsende Zahl von Personen und Gruppen (Projekten), die bei FJA mit der Software-Entwicklung beschäftigt sind, erkennbar, daß das in Eigenentwicklung entstandene System zur reinen Versionsverwaltung des Quellcodes den Qualitätsanforderungen in Zukunft nicht mehr gerecht würde. Daher suchte das Unternehmen nach einem Werkzeug, das durch ein Prozeßmodell das Vorgehen in der Entwicklung aktiv unterstützt, Wiederverwendung von Bausteinen (Modulen) fördert und dabei entstehende Varianten verwaltet. Darüber hinaus sollte das System in der Lage sein, das eng mit der Entwicklung verbundene Änderungs-Management zu übernehmen und die Entwicklung über mehrere Standorte hinweg zu koordinieren.

Anfang 1994 erstellten wir einen Anforderungskatalog, zu dessen Kriterien

- die Möglichkeit des Imports bestehender Quellen,

- die Verfügbarkeit auf relevanten Betriebssystem-Plattformen,

- der allgemeine Funktionsumfang,

- die Marktposition des Anbieters,

- die Kosten zählten.

Schließlich gelangten drei Systeme in die engere Auswahl, mit denen Testinstallationen durchgeführt wurden. Eines davon scheiterte schon früh: Es konnte die bei uns vorliegenden Quellen nicht im erforderlichen Automationsgrad importieren.

Die Entscheidung fiel schließlich aufgrund der Konzeption, der Bedienbarkeit und der relativ guten Dokumentation zugunsten von "Continuus", dem Konfigurations-Management-System der gleichnamigen Software GmbH, München. Es war das einzige der favorisierten Systeme, das damals ein Änderungs-Management integriert hatte.

Allerdings mußte darauf vertraut werden, daß die geforderte, damals aber nur angekündigte Verfügbarkeit für PC-Betriebssysteme rechtzeitig umgesetzt würde.

Das Prozeßmodell wurde mit vier wesentlichen Elementen realisiert: Konfigurationen, Zustände, Rollen und einem Neukonfigurierungs-Mechanismus, der aufgrund von Regeln Projekte aktualisiert. Die zu verwaltenden Komponenten wie Quelldateien oder Verzeichnisse besitzen Attribute, die eine Unterscheidung über den Namen hinaus ermöglichen. So besitzt jede Komponente eine Versionsbezeichnung und die Angabe, um welchen Typ es sich handelt, etwa um eine C-Quelldatei oder ein Unix-Shellskript.

Für FJA mußte der Anbieter zusätzliche Attribute einführen und die möglichen Ausprägungen der Attribute festlegen. Es wurden neue Rollen geschaffen und die Regeln für die Aktualisierung von Konfigurationen angepaßt. Nach dem erfolgreichen Einsatz in einem Pilotprojekt wurde das System Ende 1994 in einem Schritt für alle Unix-Projekte von FJA verwendet.

Konfigurationen sind Aggregationen von Versionen der im Konfigurations-Management-System (KM-System) verwalteten Komponenten. Das kann ein gesamtes Softwaresystem sein oder eine einzelne Applikation. Die Zusammenstellung von Komponentenversionen bleibt so lange unverändert, bis der Anwender eine Aktualisierung vornimmt. Konfigurationen können voneinander abgeleitet werden und besitzen wie Komponenten Attribute und einen eigenen Lebenszyklus mit definierten Zuständen (states). Während der Zustand einer Komponente Aufschluß über den Qualitätsstand (welche Tests durchlaufen wurden) eines einzelnen Moduls gibt, definiert der Zustand einer Konfiguration den Qualitätsstand einer Aggregation von Komponenten. Die Abbildung zeigt, wie dieser Ansatz bei FJA umgesetzt wurde.

In Konfigurationen mit dem Zustand "working" arbeiten Entwickler in der Rolle "developer". Hier werden neue Komponenten und Versionen erzeugt und bearbeitet. Sind die Änderungen an einer neuen Komponentenversion abgeschlossen und hat sie der Entwickler in seiner Umgebung getestet, gibt er sie in den nächsten Zustand ihres Lebenszyklus - integrate - frei. In der nächsten als "inegrate" bezeichneten Konfiguration werden täglich die freigegebenen Änderungen aller Entwickler des Projektes eingesammelt und übersetzt.

Innerhalb des KM-Systems muß dazu die Rolle "build-manager" eingenommen werden, in der realen Welt entstand dadurch die Funktion des KM-Integrators. Konnte der KM-Integrator die Übersetzung erfolgreich abschließen, gibt er die neuen Komponenten in ihren nächsten Zustandstest frei. Erst dann sehen Entwickler die Arbeit ihrer Kollegen, wenn sie ihre eigene Konfiguration aktualisieren. Wird die Übersetzung nicht erfolgreich abgeschlossen, kann der KM-Integrator auf die weitere Freigabe der neuen Komponenten verzichten oder nur einzelne zurückweisen (Zustand: "rejected").

Ebenso wie der KM-Integrator gibt der Tester die Komponenten erst dann für den nächsten Zustand ("software quality assured") frei, wenn der Applikationstest erfolgreich war. Ist schließlich der Systemtest abgeschlossen, werden die Komponenten in den letzten Zustand ihres Lebenszyklus ("released") versetzt.

Nun kann die gesamte Konfiguration, etwa vor der Freigabe eines Produkt-Release oder der Anfertigung eines Auslieferungsmediums, in der Rolle "manager" eingefroren werden und ist archiviert. Bei einer Weiterentwicklung beginnt der Produkzyklus von neuem.

Damit Übersetzungsläufe überhaupt stattfinden können, werden Konfigurationen mit dem Dateisystem synchronisiert. Der Server des KM-Systems besteht aus einer Datenbank mit den Meta-Informationen über die verwalteten Komponenten und einem NFS-Dateisystem mit den Komponenten selbst.

Durch die Synchronisation von Konfigurationen werden in einem Verzeichnis des Entwicklers die Verzeichnishierarchie, wie sie die Konfiguration vorgibt, angelegt und Unix-eigene symbolische Links zu den NFS-Dateien hergestellt. Alle Daten befinden sich physikalisch auf einem zentralen Rechner und können von dort aus gesichert werden.

Um eine hohe Verfügbarkeit zu garantieren, wird ein Raid-Level-5-Plattensystem eingesetzt, das beim Ausfall einer Platte einen Tausch im laufenden Betrieb ermöglicht.

Inzwischen hat der Hersteller sein Versprechen eingelöst, sein Produkt für Windows und NT anzubieten. Unter diesen Betriebssystemen lassen sich allerdings keine symbolischen Links wie unter Unix verwenden. Daher werden Konfigurationen durch Kopien der Komponenten in das lokale Dateisystem synchronisiert. Diese Verfahrensweise ist bei FJA auch für die verteilte Entwicklung unter Unix üblich. Die Verbindung zwischen den Entwicklerstätten stellt eine ISDN-Leitung her.

Der Übergang von einer einfachen Versionsverwaltung zu einem prozeßorientierten Produkt ist nicht ohne begleitende organisatorische Maßnahmen möglich. Bereits die Anpassungen an das Prozeßmodell zu Projektbeginn wurden vom KM-Integrator mit Entwicklern aus allen Projekten abgestimmt. Seitdem werden Erfahrungen regelmäßig ausgetauscht. Dabei entstehen verbindliche Richtlinien für die Nutzung der Software.

Ein wichtiger Aspekt ist die Struktur der Quellen. Durch die Aufgliederung in eigenständige Subkonfigurationen kann die Aktualisierung auf kleinere Teilbereiche des Softwaresystems beschränkt werden, wodurch umfangreiche Entwicklungsprojekte wesentlich besser zu handhaben sind. Diese strukturellen Maßnahmen sind leichter in einem Dateisystem vorzunehmen und sollten vor dem Import von bestehenden Projekten in das KM-System getroffen werden.

FJA plant die Integration eines Veränderungs-Managements. Die nötigen Anpassungen sind bereits erfolgt und ein erstes Pilotprojekt steht kurz vor dem Einsatz. Änderungsanforderungen des Kunden können dann per E-Mail an den Server des KM-Systems gesendet werden, wobei zur Erfassung auch eine Web-Seite eingesetzt werden könnte.

In Zukunft sollen zusätzlich alle elektronischen Dokumente, die im Laufe der Lösungserstellung entstehen, durch ein KM-System verwaltet werden. An ein Dokumenten-Management-System werden jedoch weitere Anforderungen gestellt, die von einem reinen KM-System bislang nicht abgedeckt werden. Wünschenswert wäre eine Schnittstelle, um auf Konfigurationen oder Dokumentenversionen eines DM-Systems zu verweisen.

Workflow

Prozeßorientierung ist nicht nur bei kaufmännischer Software ê la R/3 in Mode. Auch die Software-Entwickler profitieren von einem derartigen Konzept den Arbeitsblauf zu organisieren. Hier versteckt sich der bekannte Terminus "Workflow" jedoch hinter der Bezeichnung "Konfigurations-Management". Wie lokal verteilte Programmierung mit einem solchen Werkzeug funktioniert, zeigt das Beispiel bei FJA.

Das Unternehmen

Beratung und Software für die Finanzdienstleistungsbranche an. Als Systemhaus für die Versicherungsbranche erstellt FJA Produkte für Mainframes, Unix und PCs. Von den rund 200 Mitarbeitern sind rund 60 Unix-Entwickler mit der Erstellung neuer und der Wartung eingeführter Systeme beschäftigt. Die Abbildung zeigt die vier Säulen des FJA-Vorgehensmodells. Dabei zieht sich das Konfigurations-Management quer durch alle Bereiche der Entwicklung.

*Martin Mechenbier ist Beauftragter für Konfigurations-Management bei der FJA Feilmemeier & Junker GmbH (FJA) in München.