Fachbeiträge

Software Configuration Management bei einem führenden Finanzdienstleister

In den vergangenen Jahren entstand bei einem führenden Finanzdienstleistungsunternehmen eine Software-Entwicklungsumgebung, die auf dem Konfigurationsmanagement-Werkzeug Rational ClearCase von IBM basiert. Neben Administrationslösungen für hohe Verfügbarkeit und Ausfallsicherheit ist die Implementierung eines Prozessmodells zur Steuerung der eigentlichen Softwareentwicklung wesentlicher Bestandteil dieser Umgebung.

Problembeschreibung

In allen Bereichen der Wirtschaft, Forschung und im öffentlichen Bereich existieren sehr komplexe und vernetzte EDV-Systeme. Je nach Umfang und produktbezogener Notwendigkeit ist eine oft sehr große Zahl einzelner Programme bzw. Programmteile mit anderen Programmen verknüpft. Erst durch eine fehlerfreie Konfiguration vieler Programme entsteht als Ergebnis das entsprechende Produkt.

Alle Anwender – ganz gleich aus welcher Branche – arbeiten mit einer großen Zahl verschiedener Programme, die durch eigene Entwickler oder durch Auftragsvergabe bedarfsgerecht entwickelt wurden und werden, entweder vollständig oder in Form einer oder mehrerer angepasster Standardsoftware-Bausteine. Naturgemäß werden die einzelnen Programme nicht alle zum gleichen Zeitpunkt oder am gleichen Ort entwickelt und zur Anwendung gebracht. Programmergänzungen und Neuerungen sind bedingt durch die Marktentwicklung eines Unternehmens notwendig.

Hierdurch ergibt sich für ein Unternehmen innerhalb weniger Jahre eine nur noch schwer überschaubare Anzahl unterschiedlicher Systemanwendungen, die von verschiedenen Entwicklern zwar bedarfsgerecht entwickelt wurden, deren interne und externe Vernetzungsstrukturen und notwendigen Konfigurationen aber kaum noch nachvollziehbar und damit auch praktisch nicht wartbar sind.

Das führt zu Fehlern und auch Systemausfällen, deren Ursachen in sehr vielen Fällen nicht lokalisiert werden können. Sie können allenfalls nur unter sehr großem Zeitaufwand oder durch Installation neuer Programme behoben werden, die dann aber erneut das Risiko einer mangelhaften Qualität in sich tragen und dadurch erneut potentiell zu Systemausfällen führen.

Lösungen durch standardisierte Techniken, Regeln, Methoden

Schon seit vielen Jahren werden von verschiedensten Seiten weltweit erhebliche Anstrengungen unternommen, um das oben geschilderte Problem zu lösen. Entstanden sind eine Vielzahl von Techniken, Sprachen, Methoden und Regelungsmodellen.

Mittlerweile wurde richtig erkannt, dass die verschiedenen Tätigkeiten zur Softwareproduktion und die IT Service-Organisationen der Unternehmen selbst durch standardisierte Ablaufsteuerungen organisiert werden müssen, damit qualitativ hochwertige Softwareprodukte entstehen. Es entstanden Prozessbeschreibungen, zum Beispiel im Rahmen von ITIL (IT Infrastructure Library) oder Prince.

Von den Gesetzgebern wurden weiterhin Vorschriften und Gesetze erlassen, die u.a. auch dedizierte Anforderungen an die Qualität von IT Produkten und damit auch deren Entstehungsprozesse implizieren. Für die Finanzdienstleistungsbrache sind dies Vorschriften beispielsweise Basel II, MaH (Mindestanforderungen an Handelsgeschäfte), MaK (Mindestanforderungen an das Kreditgeschäft) oder MaRisk (Mindestanforderungen an das Risikomanagement).

Letztlich zielen alle diese Vorschriften, Gesetze, Techniken und Regelungsmodelle darauf ab, dass Softwareprodukte folgende wesentlichen Anforderungen erfüllen:

  • Abgeschlossenheit
  • Vollständigkeit
  • Nachvollziehbarkeit
  • Wartbarkeit über mehrere Jahre ( > 10)
  • hohe Verfügbarkeit (Disaster Recovery)

 IT Service-Organisationen verschiedener Unternehmen können sehr unterschiedlich ausfallen, auch wenn sie nach einheitlichen Standards wie zum Beispiel ITIL aufgebaut sind – naturgemäß bedingt durch unterschiedliche Organisationsstrukturen in den Unternehmen selbst.

Der eigentliche Software-Erstellungs- und Änderungsprozess kann jedoch soweit standardisiert gestaltet werden dass er in unterschiedlichste Organisationen eingepasst werden kann.

Das im Weiteren beschriebene Modell deckt genau diesen Prozess ab wie er innerhalb jeder IT Service-Organisation existiert. Aus den oben genannten Anforderungen, Standards und Regeln lässt sich folgende zentrale Anforderung ableiten:

Jede ausgelieferte Software-Produktversion muss eindeutig die Konfiguration der gesamten Produktionsumgebung identifizieren, welche zum Zeitpunkt der Produktentwicklung aktuell war. Jede Konfiguration definiert eindeutig die Versionen der zugehörigen Dateien, Verzeichnisstrukturen und eingesetzten Tools.

Daneben ergeben sich aus langjährigen Erfahrungen in der Praxis der Softwareerstellung aber auch andere Anforderungen wie zum Beispiel:

Die Softwareentwickler dürfen durch den Prozess nicht in ihrer Kreativität und Entfaltungsmöglichkeit eingeschränkt werden, da die Qualität eines Softwareproduktes maßgeblich von den Qualitäten der Entwickler abhängt.

Damit der Prozess immer eingehalten wird muss er leicht verständlich sein und darf durch seine Ausführung nicht zu zeitlichen Verzögerungen führen, die die Einführung von erforderlichen Produktveränderungen am Einsatzort zum richtigen Zeitpunkt verhindern würden.

Alle Änderungen der Entwickler müssen in einem zentralen Arbeitsbereich zusammengeführt werden, um dort integriert und getestet zu werden. Nur wenn die Tests erfolgreich sind werden die Änderungen in die nächste Konfiguration eines Produkts übernommen. Es muss sichergestellt werden, dass keine (noch so kleine) Änderung an diesem zentralen Integrationsbereich vorbei in eine neue Produktkonfiguration einfließt.

Der Software Änderungsprozess innerhalb der IT Service-Organisation

Alle Änderungen jeglicher Art (zum Beispiel Quelltext-Änderungen, Wechsel eingesetzter Tools, Installation neuer Software) werden in logischen Änderungseinheiten, den Change Sets, gespeichert. Eine neue Konfiguration des jeweiligen Softwareprodukts ist somit immer durch eine Menge von Change Sets und der vorher gültigen Konfiguration definiert.

Jeder Change Set hat immer einen Status, der den Zustand (zum Beispiel WORK, ..., RELEASED, ...) des Change Set festlegt. Ein Zustandsmodell definiert die möglichen Zustandsübergänge und legt fest, wann ein Zustandsübergang durchgeführt werden darf.

Jeder Projektmitarbeiter hat immer eine definierte Rolle, die festlegt, welche Zustandsübergänge von ihm ausgeführt werden dürfen. Es existiert somit ein rollenbasiertes Vorgehensmodell, in dem festgelegt ist wer, wie, wann die Change Sets zu welchem Zweck erzeugen bzw. bearbeiten darf. Es gibt 5 Rollen:

Entwickler (Developer)

Jeder Entwickler arbeitet immer in einer Arbeitsumgebung, die einer Aufgabe zugeordnet ist. Eine Aufgabe kann zum Beispiel die Implementierung einer neuen Funktionalität oder die Behebung eines gemeldeten Produktfehlers sein.

Alle Arbeitsumgebungen zu einer Aufgabe basieren immer auf einer eindeutigen Konfiguration des jeweiligen Produkts – diese Konfiguration ist die so genannte Baseline der Arbeitsumgebungen.

Nur die Entwickler führen die tatsächlichen Änderungen durch. Die einzelnen Änderungen an Dateien, Verzeichnissen, etc. werden in Change Sets gepackt. Die entsprechenden Change Sets sind im Status WORK.

Ist ein Change Set fertig, so wird er an den Integrator übergeben – der Change Set ist im Status SUBMITTED. Ein Change Set kann aber nur dann an den Integrator übergeben werden, wenn die Baseline der Arbeitsumgebung mit dem derzeit gültigen Arbeitsfortschritt im Projekt übereinstimmt. Ist dies nicht der Fall, so müssen die Entwickler ihre Arbeitsbereiche zuerst mit dem gültigen Arbeitsfortschritt synchronisieren, d.h. die Konfiguration, durch die der derzeitige Arbeitsfortschritt definiert ist, wird zur neuen Baseline der Arbeitsumgebungen der Entwickler.

Die Synchronisation der Arbeitsumgebungen ist nicht zwangsweise an die Übergabe von Change Sets gekoppelt. Entwickler können zu jeder Zeit ihre Arbeitsumgebung synchronisieren – es liegt in ihrer Entscheidung. Nur bei der Übergabe von Änderungen werden sie gezwungen, sich mit dem aktuellen Arbeitsfortschritt im Projekt zu synchronisieren.

Integrator

Jeder Integrator arbeitet immer in einer Arbeitsumgebung, die einer Hauptentwicklungslinie des jeweiligen Produkts zugeordnet ist. Eine Hauptentwicklungslinie kann zum Beispiel die Wartung eines ausgelieferten Produkts oder die Neuentwicklung eines Produkts sein. Jede Hauptentwicklungslinie basiert immer auf einer eindeutigen Konfiguration des jeweiligen Produkts. Diese Konfiguration ist die Baseline der Hauptentwicklungslinie und bleibt immer gleich.

Der Integrator übernimmt von den Entwicklern Change Sets im Zustand SUBMITTED. Die übernommenen Change Sets sind im Status IN_TEST. Die übernommenen Change Sets werden nun getestet. Die Testverfahren werden vom Prozessmodell nicht vorgeschrieben. Aufgrund der offenen Architektur von ClearCase sind alle Testverfahren möglich, die auf einer Verzeichnisstruktur mit Dateien aufbauen.

Aufgrund der Testergebnisse werden Change Sets komplett akzeptiert oder verworfen. Akzeptierte Change Sets sind im Status PUBLIC. Verworfene Change Sets sind im Status REJECTED. Alle gemeinsam zu einem Zeitpunkt akzeptierten Change Sets definieren den nächsten Arbeitsfortschritt im Projekt. Entwickler sind immer gezwungen sich mit dem jeweiligen Arbeitsfortschritt zu synchronisieren, wenn sie neue Change Sets zur Integration übergeben wollen (siehe oben).

Verworfene Change Sets (REJECTED) sind für immer verworfen. Die Inhalte dieser Change Sets werden den zuständigen Entwicklern zur erneuten Bearbeitung zurückgegeben.

Konfigurationsmanager (Release Builder)

Jeder Konfigurationsmanager arbeitet immer in einer Arbeitsumgebung, die einer Hauptentwicklungslinie zugeordnet ist (siehe oben).

Im Laufe der Zeit werden von den Integratoren mehr und mehr Change Sets in den Status PUBLIC gesetzt. Der Konfigurationsmanager hat die Aufgabe, aus dieser Menge von Änderungen geeignete Mengen zu definieren, die dann neue Produktkonfigurationen sind, auf die aufgebaut werden kann. Dies ist entweder die Auslieferung einer neuen Produktversion oder aber die Erzeugung einer neuen Hauptentwicklungslinie, welche auf dieser Produktversion aufsetzt. Change Sets, die in eine neue Produktkonfiguration einfließen, erhalten den Status RELEASED.

Die Aufgaben der Integration (Testen) und der Konfigurationsbildung sind in zwei unterschiedliche Rollen getrennt, damit die Tätigkeiten parallel, unabhängig voneinander ausgeführt werden können ohne die andere Tätigkeit zu blockieren.

Produktmanager (Package Builder)

Jeder Produktmanager arbeitet immer in einer Arbeitsumgebung, die einer Hauptentwicklungslinie zugeordnet ist (siehe oben).

Aus den vom Konfigurationsmanager definierten Produktkonfigurationen wählt der Produktmanager die Konfiguration aus, auf der basierend eine neue Produktlieferung erstellt werden soll. Jede neue Produktlieferung erhält automatisch eine Produktversionskennung, die der Produktkonfiguration eindeutig zugeordnet ist.

Die Aufgaben der Produkterstellung und der Konfigurationsbildung sind in zwei unterschiedliche Rollen getrennt, damit die Tätigkeiten parallel, unabhängig voneinander ausgeführt werden können ohne die andere Tätigkeit zu blockieren.

Projektmanager (Project Administrator)

Die Rolle des Projektmanagers entspricht der Rolle Entwickler mit zusätzlichen Rechten. Als Entwickler ist dem Projektmanager automatisch die Aufgabe „Projektmanager“ zugeordnet.

Zusätzliche Rechte des Projektmanagers umfassen zum Beispiel die Erzeugung neuer Aufgaben oder neuer Hauptentwicklungslinien.

Fazit

Das beschriebene Prozessmodell wurde zusammen mit unterstützenden Tools und der entsprechenden Konfiguration von Rational ClearCase bei dem auftraggebenden Finanzdienstleister sehr erfolgreich eingeführt. Es entstand eine allgemeine, übertragbare und anforderungskonforme Lösung, deren große Akzeptanz bei den Anwendern den eingeschlagenen Weg bestätigt.