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.

19.08.1988 - 

Trotz fehlender Erfahrung und anfänglicher Kommunikationsprobleme:

ADAC landet mit Adam auf dem Punkt

MÜNCHEN - 110 Mannjahre Aufwand steckte der ADAC in den vergangenen vier Jahren in die Entwicklung des neuen Informationssystem "Adam" für die Mitgliedsbestandsführung. Es war das bisher größte Entwicklungsvorhaben. Nach der Systemeinführung zieht jetzt Norman Heydenreich* ein kritisches Resümee über ein Projekt, für das in dieser Größenordnung anfangs die Erfahrungen fehlten.

Zu Beginn des Adam-Projektes standen langfristige Zielsetzungen im Vordergrund: Die zum Teil veralteten und ohne einheitliches Konzept entwickelten Bestandsführungen sollten durch ein modernes und integriertes System abgelöst werden. Neben der notwendigen technischen Modernisierung mußten die Voraussetzungen für eine verstärkt mitgliederorientierte und rationelle Bestandsführung geschaffen werden. Dazu waren gemeinsame Verfahren, insbesondere in der Inkassobearbeitung, zu entwickeln. Das neue System sollte langfristig die Voraussetzung für neue Mitgliedschaftsmodelle sowie für die Unterstützung der ADAC-Geschäftsstellen schaffen. Erst im Verlauf der Analysephase wurde der Schwerpunkt auf den Neubau des für den ADAC zentralen Mitgliedersystems gelegt.

Adam löste ein 16 Jahre altes und fachlich wie technisch veraltetes System ab, das auf maximal 10 Millionen Mitgliedsnummern ausgelegt war. Bei dem abzusehenden Mitgliederwachstum war somit der Einführungstermin - vor Beginn der Saison 88 - fest vorgegeben. Eine Terminüberschreitung hätte hohe zusätzliche Investitionen in das alte System erforderlich gemacht.

In das abzulösende Altsystem waren über ein Jahrzehnt permanenter Weiterentwicklung eingeflossen. Seine Leistungen wurden von der Fachabteilung vorausgesetzt und waren ihr im einzelnen zum Teil nicht einmal bewußt - auch nicht mehr dokumentiert. Die Gefahr, davon etwas Wichtiges bei der Spezifikation des neuen Systems zu vergessen, war groß.

Bei der Erarbeitung des fachlichen Modells wurden im ADAC erstmalig die Methoden der Funktions- und der Informationsanalyse eingesetzt. Das Know-how kam von externen Beratern, deren praktische Erfahrungen in der Anwendung dieser Methoden allerdings nicht ausreichend waren, wie sich später herausstellte. Auch auf der Seite des ADAC-Teams fehlte die Erfahrung in der Konzeption und Planung großer Informationssysteme. Die isolierte Anwendung der neuen Methoden führte rasch zu Sprach- und in der Folge zu Akzeptanzproblemen zwischen den "Kullermännern" - so wurde das Projektteam aufgrund neuer grafischer Darstellungsmethoden genannt - und den Praktikern.

Das Wissen über die bestehenden Verfahren ging zu wenig in die Neukonzeption ein. Statt rechtzeitiger Konzentration auf die Kernfunktionen - Voraussetzung für Machbarkeit und Wirtschaftlichkeit ñ flossen alle fachlichen Wünsche in das Modell ein. Die angewandte Methode unterstützte eher die Detaillierung als die Modellierung der Zusammenhänge. Sein Unbehagen über die Entfernung des Ergebnisses dieser Phase von den realen Arbeitsabläufen drückte der Leiter der Fachabteilung so aus: "Wir haben jedes Schräubchen genau beschrieben - aber am Ende war das Auto kaum noch zu erkennen."

Ein neuer Anlauf

Die durchgängige Umsetzung der Ergebnisse der fachlichen Analyse in einen Systementwurf war nicht möglich. Das vorhandene Material mußte auf die wesentlichen Anforderungen hin neu strukturiert und verdichtet werden. Ein Wechsel in der Projektleitung unterstützte die notwendige Neuorientierung in der Vorgehensweise. Der Org./DV-Chef und die Unternehmensleitung nahmen sich des Projektes verstärkt an.

In dieser Phase wurde auf in Projekten bereits bewährte Methoden zurückgegriffen. Eine Liste der Geschäftsvorfälle aus Benutzersicht diente als roter Faden. Die aus fachlicher Sicht relevanten Daten wurden nach dem Entity-Relationsship-Modell, der Dialogablauf mit Hilfe von Interaktionsdiagrammen modelliert, die Batchorganisation mit konventionellen Darstellungstechniken (EVA, Datenflußdiagramme). Alle Funktionen und Daten wurden einer kritischen Überprüfung unterzogen. Der parallel erarbeitete technische Grobentwurf sicherte die Machbarkeit.

Die vom Fachbereich abgenommene Systemspezifikation erlaubte eine realistische Schätzung des Projektaufwandes. Im Verlauf des Projektes zeigte sich jedoch, daß gerade die fachlichen Zusammenhänge mit der größten Komplexität (zum Beispiel Inkassowirkungen von Vertragsänderungen) durch diese Spezifikation ungenügend dargestellt wurden. In Folgeprojekten wird deshalb mehr Gewicht auf die Darstellung des Ablaufs innerhalb der Anwendung gelegt. Eine stärkere Orientierung der Systemspezifikation an konstruktiven Modellen kann den Übergang zum Systementwurf erleichtern.

Die Aufwandsschätzung auf der Basis des vorliegenden Entwurfs wurde nach einem Ähnlichkeits- und Differenzen-Verfahren durchgeführt, das heißt die Aufgaben wurden soweit aufgegliedert, daß Ähnlichkeiten und Differenzen gegenüber vorangegangenen Projekten festgestellt werden konnten. Sie wurde durch das COCOMO-Verfahren überprüft. Das Ergebnis machte deutlich, daß die bisher der Planung zugrunde gelegten Werte mindestens zu verdoppeln waren. Hier stellte sich nicht nur die Frage der Kosten, sondern auch die der Machbarkeit und des Projektrisikos.

Deshalb wurden die Möglichkeiten der Bildung einer ersten Entwicklungsstufe untersucht. Nach dem Einführungszeitpunkt dieser Stufe mußte jedoch mindestens die volle Funktionalität des alten Verfahrens verfügbar sein. Das war grundsätzlich über zwei Wege möglich.

a) Nur ein Teil des neuen Systems wird in der ersten Stufe neu entwickelt und über Schnittstellen mit dem für die Weiterverwendung bestimmten Teil des Altsystems verbunden. Dieser Lösungssatz, der vom Team als "halbes Schwein" bezeichnet wurde, erwies sich vor allem wegen der zu hohen Einschränkung durch die zu beachtenden Schnittstellen als nicht realisierbar.

b) Reduktion des vom Anwender geforderten Funktionsumfanges um die in einer ersten Stufe verzichtbaren zusätzlichen Funktionen ("kleines Schwein"). Dieser Weg wurde eingeschlagen und brachte eine Reduktion des geschätzten Realisierungsaufwandes um 20 Prozent. Das Ergebnis: 40 Mannjahre Rest-Aufwand des Entwicklungsteams ohne Umstellungsprojekte und Fachbereichsaufwand. Für die Konzeption waren bereits 16 Mannjahre aufgewandt worden.

Nach Abschluß des Projektes ergab eine Nachkalkulation des Projektaufwandes folgendes: Von insgesamt 110 Mannjahren entfielen 63 Mannjahre auf das Adam-Entwicklungsteam, 38 Mannjahre auf den Fachbereich und 9 Mannjahre auf Umstellungsprojekte. Der Aufwand des Entwicklerteams für Realisierung, Test und Einführung lag um 20 Prozent über der Schätzung nach der Konzeptionsphase, der Aufwand des Fachbereichs war allerdings erheblich höher als angenommen. Seine rechtzeitige Bereitstellung bereitete erhebliche Probleme. Bei künftigen Projektansätzen wird von einer Fachbereichsmitarbeit im Umfang von mindestens einem Drittel des Gesamtaufwandes ausgegangen.

Realisierungsplanung

Die Aufwandsschätzung hatte ergeben, daß die Projektaufgabe unter dem vorgegebenen Zeitrahmen von zwei Jahren für Detailkonzeption, Realisierung, Test und Einführung nur mit einem sehr großen Team zu realisieren war. Vorgehensweise und Planung für das Projekt hatten vor allem Beherrschbarkeit sicherzustellen:

Für die Einführungsphase wurden vier Monate geplant. Die verbleibenden 20 Monate wurden in drei Entwicklungssockel unterteilt. Im ersten Sockel war die Entwicklungsumgebung bereitzustellen, die technische Basis sowie ein "Durchstichsystem"

mit beschränktem Punktionsumfang zu entwickeln. Dieses Kernsystem stellte einen fachlichen und technischen Prototypen dar: Es sollte vom Fachbereich getestet werden und den Nachweis für die Realisierbarkeit der technischen Konzepte erbringen. Die für den weiteren Projektverlauf grundlegenden Verfahrensweisen - insbesondere die Testabwicklung - konnten hier entwickelt, eingeübt und in der Praxis überprüft werden. Im zweiten Sockel wurde der vorhandene Prototyp überarbeitet, in seiner Funktionalität ausgeweitet und erneut durch den Fachbereich getestet. Mit dem dritten Sockel war die Softwareentwicklung abgeschlossen.

Motivationsschub

Diese Vorgehensweise der "inkrementalen Entwicklung" eines großen Softwaresystems hat sich im Adam-Projekt grundsätzlich bewährt. Der Motivationsschub für alle Mitarbeiter, der aus vorzeigbaren Ergebnissen kommt, war unverkennbar. Eine sehr intensive Mitarbeit des Fachbereichs im Verlaufe der gesamte Realisierungsphase wurde möglich. So war sichergestellt, daß die Entwicklung sich durchgehend an den fachlichen Anforderungen orientierte. Fachliche und technische Probleme wurden rechtzeitig deutlich und konnten in einer verbesserten Version im Rahmen der geplanten Entwicklungszeit ausgeräumt werden.

Die frühzeitig vorliegenden Testergebnisse erlaubten eine weitgehende Objektivierung des Projektfortschritts, nach Sneed eines der gravierendsten Probleme der Software-Entwicklung, wurde erreicht. Das Projektmanagement hatte Klarheit über den Projektzustand und konnte beizeiten Maßnahmen ergreifen. Dadurch konnte ein sehr ehrgeiziges Terminziel erreicht werden: Der geplante Einführungstermin wurde nur um einen Moment verfehlt ñ nach Maßstäben der Praxis von Großprojekten eine Punktlandung.

Umfeld muß stimmen

Diese Vorgehensweise hat allerdings auch ihre Nachteile: Die Konzentration bei der Detailkonzeption auf den Funktionsumfang eines Kernsystems kann dazu führen, daß konzeptionelle Schwierigkeiten erst in Folgesockeln zutage treten und dadurch ein Redesign von bereits realisierten Teilen der Anwendung notwendig wird. Die Qualität der Grobkonzeption bestimmt das Ausmaß dieser Gefahr.

Auch die beste Software ist wertlos, wenn das Umfeld nicht stimmt. Die rechtzeitige Aufstockung der Rechner- und Plattenkapazität, die notwendigen Erweiterungen der Basissoftware, die Bereitstellung der technischen Umgebung durch die Systemtechnik und umfangreicher Jobnetze und ausgeklügelter Sicherungsverfahren durch die Arbeitsvorbereitung gehörten ebenso in den Gesamtplan wie die Ausarbeitung der Ablauforganisation und die Einführungsplanung. Haben wir an alles gedacht? Diese Frage mußte immer wieder gestellt werden.

Einrichten der Baustelle

Der Projektmanager für die Entwicklung des Betriebssystems OS/360, Fredrik P. Brooks, bemerkte, daß schon der Turmbau zu Babel an dem gleichen Mangel scheiterte wie heute manches große Softwareprojekt: Kommunikation und ihre Konsequenz - Organisation. Aufgrund der notwendigen Arbeitsteiligkeit wird der Erhalt der konzeptionellen Integrität des Produktes zum kritischen Management-Problem. Diesen Aspekten wurde beim Aufbau des Adam-Projektes große Bedeutung beigemessen.

Hohe "Management-Attention" gab dem Adam-Projekt den notwendigen Rückhalt und Schwung. Im Rahmen des "Organisationsausschusses" waren die Hauptverantwortlichen aller tangierten Bereiche und die Geschäftsleitung, beim ADAC Generalsekretariat genannt, in das Projekt eingebunden. Zielkonflikte und grundlegende Fragen, wie die der Übergangs- und Rückzugsstrategie, konnten hier diskutiert und entschieden werden. Der Projektleiter wurde durch ein schlagkräftiges Projektmanagement-Team unterstützt, dem der Hauptabteilungsleiter Organisation und Datenverarbeitung und der Leiter der Mitgliederabteilung angehörten.

Dieser wöchentlich tagende Projektausschuß sah seine Aufgabe nicht nur in der Projektkontrolle. Hier wurden durch kritisches Nachfragen Probleme frühzeitig erkannt und somit Handlungsspielraum für Entscheidungen geschaffen, die das Projekt auf Kurs hielten. Für neue fachliche Anforderungen wurde ein Genehmigungsverfahren eingerichtet. Die Abteilungsleiter für Systemtechnik und Produktion berichteten regelmäßig dem Projektausschuß über den Stand ihrer Vorbereitungen.

Innerhalb kurzer Zeit wurde ein Team von 25 Entwicklern und einigen Mitarbeitern aus der Methoden- und Werkzeug-Gruppe, der Systemtechnik und der Arbeitsvorbereitung aufgebaut und - entsprechend der Aufgabenstruktur des Gesamtprojekts - in überschaubare Teilprojekt-Teams gegliedert. Die Teamleiter waren für die Erreichung der mit ihnen vereinbarten Meilensteine verantwortlich. In wöchentlichen Teamleiter-Meetings wurden alle übergreifenden Pläne abgestimmt und Lösungswege für Probleme festgelegt.

Die Behandlung fachlicher und technischer Probleme, die nicht im Rahmen einzelner Teilteams zu lösen waren, wurde an einen geeigneten Expertenkreis ("Design-Meeting") delegiert. Ein "Chef-Designer" stellte die Konsistenz des Anwendungsentwurfs über die verschiedenen Teams hinweg sicher. Alle Entwurfsdokumente wurden durch ein "Review-Team" geprüft. So gelang es trotz der Teamgröße, die Qualität des Entwurfs zu sichern und einen "Turmbau-zu-Babel-Effekt" zu verhindern.

Die bis zu 20 Mitarbeiter des Fachbereichs bildeten ein eigenes Organisationsprojekt. Sie detaillierten die fachlichen Anforderungen, arbeiteten die Ablauforganisation aus, führten den Integrationstest durch und verfaßten die Benutzerdokumentation. Diese Elemente einer Linien-Projekt-Organisation, die vor allem durch die Projekterfahrung des Fachabteilungsleiters wirksam wurden, entlasteten die Projektleitung und stärkte die Rolle des Anwenders.

Doch es galt auch zu verhindern, daß aus den Teilprojekten Lager wurden: "Nun hat der Fachbereich schon zum dritten Mal seine Anforderung geändert. Die wissen wohl nicht, was sie wollen." oder: "Auf die Entwickler kann man sich nicht verlassen, den Fehler habe ich doch schon früher gemeldet." Derartige Frontstellungen wichen im Verlauf des Projektes einem Verständnis für die Aufgaben und Schwierigkeiten der Teamkollegen aus dem anderen Bereich. Die informelle Kommunikation war dabei besonders wichtig. Eine gemeinsame Reise nach dem ersten Meilenstein und einige Feste haben zum gegenseitigen Verständnis und der hervorragenden Zusammenarbeit zwischen Entwicklung und Fach bereich beigetragen.

Schnittstellenkonferenz

Die Verantwortlichen für die umzustellenden Nachbarsysteme wurden in einer Schnittstellen-Konferenz zusammengefaßt, in der Vorgehensweisen, Schnittstellen und Planungen abgestimmt wurden.

Auch der Ausbau der Entwicklungsumgebung für das Projekt diente der Entlastung der Kommunikation innerhalb des Entwicklungsteams und der Verbesserung der Qualität. Für Spezifikation, Realisierung und Test wurden Standards festgelegt und so weit wie möglich durch Werkzeuge unterstützt. Ein auf der Basis des Code-Generators "Delta" entwickelter Programmrahmen enthielt standardisierbare Programmfunktionen wie Steuerungsfunktionen und Fehlerbehandlung. Generierung der Schnittstellen und Datensichten direkt aus dem Data-Dictionary sicherte deren Konsistenz. Mechanismen zur automatischen Dokumentation von Verwendungsnachweisen im Dictionary und ein Verfahren zur werkzeuggestützten Rechenzentrums-Übergabe und Job-Control-Generierung aus dem Dictionary wurden entwickelt.

Testumgebungen für Funktionsgruppen und Integrationstest mußten geschaffen werden: Mehrere getrennte Testdatenbanken mit rückladbaren definierten Ausgangbeständen, Utilities zur Testdatenverwaltung, komplexe Test-Jobnetze. In den Integrationstests traten erhelbliche Probleme beim Konfigurationsmanagement auf. Hier fehlten ausgearbeitete organisatorische Verfahren und eine Werkzeugunterstützung. Dafür wurde ein eigenes Projekt initiiert. Es bildet den Schwerpunkt für den weiteren Ausbau der ADAC-Entwicklungsumgebung.

Die Weiterentwicklung und der konsequente Einsatz von Methoden und Werkzeugen haben sich in diesem Projekt bezahlt gemacht: Junge Mitarbeiter konnten rasch in die Aufgabe hineinwachsen, durch Standardisierung und automatische Dokumentation wurden Qualität, durch Vermeidung von Integrationsproblemen Terminsicherheit gewonnen.

Der technische Entwurf

Bei einer Anzahl von fast 9 Millionen aktiven Mitgliedern und 6 Millionen Dialogvorgängen pro Jahr sind die Anforderungen an den Automatisierungsgrad der Anwendung sehr hoch. Die auftretenden Transaktionsraten (über 200 000 Transaktionen pro Tag in der Saison), hohe Verfügbarkeitsanforderungen an die Dialogverarbeitung (Auskunftsdialog rund um die Uhr) und die Volumina der Batchverarbeitungen (zum Beispiel Produktion von 1,4 Millionen Rechnungen in einem Lauf) stellen hohe Anforderungen an den technischen Entwurf der Datenbank und der Anwendung.

Der Modularisierung lagen ein Schichtenmodell sowie die Prinzipien der Datenabstraktion zugrunde: In Datenkapseln wird bestimmtes Anwendungs-Know-how konzentriert. Anwendungsfunktionen werden über Zugriffsoperationen realisiert, die auf ein gemeinsames internes Modulgedächtnis zugreifen. Eine Standardkomponente "Magic" stellte sicher, daß alle im Rahmen einer Transaktion aufgerufenen Datenabstraktionsmodule durch einen Datenbankzugriff versorgt werden (I/O-Optimierung) und somit die Modularisierung nicht auf Kosten des Leistungsverhaltens geht. Eine zentrale Störfallbehandlung, die Abschottung der DB/DC-Schnittstellen und die Implementierung einer Schatten-Datenbank als schnelles Back-up-Medium sicherten hohe Verfügbarkeit.

Performance-Gewinne

Die 8 Gigabyte der Adam-Datenbank benötigen 20 Platten-Laufwerke IBM 3380-D. Dazu kommen 9 Laufwerke 3380-E für die Schatten-Datenbank. Aufgrund des hohen Datenvolumens standen bereits beim ersten Datenbankentwurf Performance-Überlegungen im Vordergrund. Ausgangspunkt war das Datenmodell, doch erst genaue Aussagen über die Zugriffshäufigkeiten führten zu einem auf der Basis des eingesetzten DB-Systems Adabas tragfähigen Datenbankentwurf: Die meisten Adam-Dateien genügen nicht einmal der ersten Normalform. Erst durch Annahmen über die physische Reihenfolge der Sätze einer zentralen Datei, die großen Batchläufen als Leitdatei dient, war es möglich, durch logisch sequentielles Lesen akzeptable Laufzeiten zu erreichen.

Die physische Reihenfolge der Sätze wird gesteuert durch Laden mit User-ISN (Adabas-interne Satznummer) und einen relativ hohen Paddingfaktor, der Umlagerungen bei Updates sehr unwahrscheinlich macht. Durch Verwendung der Schatten-Datenbank für lesende Verarbeitung ist es möglich, den Batch nachts, wo nur lesender TP-Betrieb gefordert wird, gemeinsam mit der Datenbank in einem Adressraum laufen zu lassen (single-user-Betrieb). Die dadurch realisierten Performance-Gewinne sind erheblich.

Kaum Zusatzaufwand

Aufgrund der Ergebnisse zahlreicher Lastmessungen mußten die File-Aufteilung und einige Zugriffsmethoden geändert werden. Frühzeitige Messungen eines Dialog-Kernsystems waren Grundlage für die Hochrechnung der Systemlastspitzen und die Hardwareplanung. Während der Systemtests wurden aus zahlreichen Messungen Hinweise auf Tuningmaßnahmen gewonnen. Durch die konsequente Modularisierung nach Schichten war die Umsetzung der Erkenntnisse aus den Lastmessungen in wirksame Tuningmaßnahmen ohne erheblichen Zusatzaufwand möglich.

wird fortgesetzt