*Norman Heydenreich, Leiter des Adam-Projektes, ist Leiter der Abteilung Systementwicklung beim ADAC, München.

MÜNCHEN - 110 Mannjahre Aufwand steckte der ADAC in den vergangenen vier Jahren in die Entwicklung des neuen Informationssystems "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.

Die fachlich notwendige Neukonzeption der logischen Datenbasis machte die Transformation der alten Daten in die neue Datenbasis zu einem anspruchsvollen Teilprojekt. Hinzu kam die Komplexität des Übergangs auf funktionaler Seite: Alle neu konzipierten Fachfunktionen mußten am Tag des Überganges fachlich richtig auf dem vom alten System hinterlassenen Zustand aufsetzen.

Bereits das abzulösende System war über historisch gewachsene Schnittstellen mit zahlreichen anderen Informationssystemen verbunden. Der Austausch glich somit einer Herzoperation. Parallel zur Adam-Entwicklung waren 350 Programme von 13 Nachbarsystemen auf die neue Adam-Datenbasis umzustellen.

Die Auswirkungen von Störungen des Mitglieder-Systems sind gravierend: Allein eine nicht termingerechte Erstellung der Versandunterlagen für die "Motorwelt" würde den ADAC Millionen kosten. Ohne eine funktionsfähige Mitglieder-Datenbank sind auch andere wichtige Informationssysteme des ADAC nicht arbeitsfähig.

Ein Rückzug auf das alte Mitgliedersystem nach dem Einführungszeitpunkt war nur innerhalb von wenigen Tagen unter aufholbarem Datenverlust möglich. Deshalb war die Projektstrategie vorrangig auf die Minimierung des Übergangsrisikos ausgerichtet. Die Datenbestände (Erweiterung der Mitgliedsnummer) und alle Programme (bis auf ein Schnittstellen-Modul) der Nachbarsysteme wurden bereits Monate vor der Adam-Einführung umgestellt. Einzelne Teile des neuen Verfahrens wurden im Rahmen des alten Verfahrens vorab implementiert. Der Einsatz von Standardsoftware hatte Vorrang. Es wurde so früh wie möglich und mit hohem Aufwand getestet.

Die Machbarkeit einer "Bridge-Rückwärts", das heißt eines Verfahrens, das es ermöglicht, nach der Einführung im Notfall auf das alte System zurückzugehen, wurde geprüft. Das erarbeitete Konzept zeigte gravierende Probleme auf: Inkonsistente Daten beziehungsweise Fehlverarbeitungen im Neusystem führen mit hoher Wahrscheinlichkeit auch zur Übergabe falscher Daten an die Bridge. Deren Betrieb hätte erhebliche Restriktionen für das Neusystem notwendig gemacht und hohe zusätzliche Systemlast verursacht. Qualität und Testreife einer komplexen, am Ende des Projekts entwickelten Bridge wäre geringer als die des Neusystems - ein zusätzliches Risiko. Deshalb wurde gegen ihre Realisierung entschieden. Für die wichtigsten Verarbeitungen wurde einfache Notbetriebs-Software auf der Basis des Altsystems entwickelt. Eine umfassende Notorganisation wurde ausgearbeitet.

Dicke Drehbücher bereiten die Tests vor

Wer soll testen? Der Entwickler oder eine eigene QS-Gruppe? Nach unserer Überzeugung vor allem diejenigen, die hohes Eigeninteresse an der Qualität des Produktes haben, also vor allem Mitarbeiter des Fachbereichs.

So wurde bereits der auf den Modultest des Entwicklers folgende Funktionsgruppentest vom Fachbereich in eigener Regie durchgeführt. Entwickler leisteten hier nur technische und beratende Unterstützung. Diese Tests wurden durch umfangreiche Testdrehbücher vorbereitet (rund 200 bis 500 Testfälle je Funktionsgruppe), die parallel zur Ausarbeitung der Feinspezifikation der entsprechenden Funktionen erarbeitet wurden. Bereits bei der Erstellung der Testdrehbücher wurden Mißverständnisse und Spezifikationslücken aufgedeckt. Die Funktionsgruppentests wurden entwicklungsbegleitend über einen Zeitraum von 14 Monaten zum Teil in mehreren Iterationen durchgeführt. Bei diesen Tests gab es erhebliche Probleme mit der Versionsverwaltung. Zu diesem Zeitpunkt fehlte ein Werkzeug für das Konfigurations-Management.

Nach Abschluß der Softwareentwicklung ging ein Team aus Entwicklern und Fachbereichsmitarbeitern an den Integrationstest, wiederum unter der Hauptverantwortung des Fachbereichs. Eine Testdatenbank mit etwa 300 Mitgliedern überdeckte alle wichtigen Stammdatenkonstellationen. Der Testplan für diese "Mini-Produktion" hatte die Schwerpunkte integrative Beziehungen und produktionsnahe Abläufe: von der Datenübernahme über Dialogeingaben und Tagesbatch bis zu den periodischen und monatlichen Verarbeitungen einschließlich aller Folgeverarbeitungen in den nachgelagerten Systemen (beispielsweise Finanzbuchhaltung). Durch Manipulation des Tagesdatums konnte die Teststrecke von zwei Monaten im Zeitraffer durchlaufen werden.

Parallele Verarbeitung war zunächst nicht machbar

Eine vollständige parallele Verarbeitung des alten und des neuen Verfahrens über mehrere Tage hinweg war wegen des Umfangs der damit verbundenen Dialogeingaben, aber auch wegen der daraus resultierenden Systemlast nicht machbar. Deshalb wurden in einem 14tägigen Parallellauf nur die Dialogänderungen der Berliner Mitglieder im Adam-System zusätzlich erfaßt. Ausgangspunkt war eine Übernahme aller Mitgliederdaten. Die Jobnetze liefen zum ersten Mal unter Produktionsbedingungen. Für besonders kritische Batchverarbeitungen, wie Rechnungs- und Mahnlauf, gab es zusätzlich Sonder-Parallelverarbeitungen auf einem vergleichbaren Gesamtbestand, das heißt nach einer eigenen Datenübernahme. Die Ergebnisse aller Batchauswertungen aus beiden Systemen wurden abgeglichen. Das Parallellauf-Team kämpfte wochenlang tapfer gegen Berge von Listen, die sich in seinem "Hauptquartier" auftürmten. Das Ergebnis lohnt die Mühe: Fehlerkonstellationen traten auf, die keinem Tester eingefallen wären, vor allem jedoch wurde Sicherheit über das Systemverhalten unter Produktionsbedingungen gewonnen.

Mehrere Stunden Hochsaison simuliert

Um die Bereinigung aller Fehler aus den Integrationstests und Parallelläufen nachzuweisen, wurde die "Miniproduktion" nach dem gleichen Testplan als Abnahmetest wiederholt. In zahlreichen Übernahmetests wurde der Übergang vom alten zum neuen Verfahren einschließlich der Umstellung aller betroffenen Nachbarsysteme geprobt. In mehreren Dialog-Lasttests erzeugten alle Mitarbeiter der Mitgliederabteilung über mehrere Stunden Hochsaisonlast. Durch Restart/Recovery-Tests wurden Schnelligkeit und Korrektheit des Wiederanlaufs nach Betriebsunterbrechungen überprüft.

Der hohe Testaufwand auf Seiten des Fachbereichs war unverzichtbar, um die notwendige Sicherheit zu gewinnen. Ein weiterer positiver Effekt: Zahlreiche Fachbereichsmitarbeiter lernten das System vor der Einführungsphase gründlich kennen und standen dann als Multiplikatoren zur Verfügung.

In den abschließenden Tests, welche die Produktionsreife des Adams nachweisen sollten, wurde das konsequente Problem- und Change-Management immer wichtiger: Alle Fehler wurden in Fehlerreports dokumentiert, zentral erfaßt, vom Fachbereich mit Prioritäten versehen, ihre Behebung und der Nachtest tagesgenau geplant und durch des Projektmanagement verfolgt. Alle Änderungen der abgenommenen Software mußten durch eine Freigabe-Konferenz genehmigt werden. Die Endphase eines Projekts ist nicht die Stunde der großen Pläne und Entwürfe, sondern die der peinlich genauen Verfolgung der Details.

Stapellauf mit Hindernissen

Nach zahlreichen Test-Wochenenden war es dann soweit: Für das erste Märzwochenende war der Stapellauf angesetzt. Aus fachlichen Gründen konnte er jeweils nur am Monatsanfang stattfinden. Nur an einem Wochenende war genug Zeit für die umfangreichen Abschluß-, Übernahme- und Testläufe. Und es blieb nicht viel Zeit für Fehlversuche: Am Montagmorgen mußte alles fertig sein - andernfalls mußte die Einführung um einen Monat verschoben werden.

Die Generalprobe, die einen Monat zuvor stattgefunden hatte, war fast zu glatt gelaufen - ein schlechtes Omen für die Premiere? Freitag 20 Uhr: Der letzte Statistiklauf des Altsystems stürzte ab. Das hatte er seit zehn Jahren nicht gemacht.

Umfangreiche Tests zahlen sich aus

Die Fehlerursache war rasch geklärt: Ein Kopfsatz der Mitgliederdatei enthielt ein falsches Datum. Rasch wurde ein Korrekturprogramm geschrieben. Mit zwei Stunden Verzögerung ging es weiter. Auf zwei Rechnern liefen insgesamt 50 Jobs. Die Ergebnisse der Datenübernahme konnten bereits am Samstagmittag geprüft werden: Alle Mitglieder waren übernommen. Der Verantwortliche der Finanzabteilung strahlte: Auch das Geld stimmte auf die Mark. Und die Herren von der Revision waren ebenfalls zufrieden.

Am Samstag um 20 Uhr war die Datenbank aufgebaut. Danach lief die erste Verarbeitung im neuen System: 850 000 Rechnungen wurden mit den neuen Programmen und Daten erstellt. Die Rechnungen und Kontrollisten wurden am Sonntagmorgen geprüft. Ab 10 Uhr begannen die Tests der Dialogsysteme: Adam und die umgestellten Nachbarsysteme wurden von allen betroffenen Fachabteilungen zum letzten Mal getestet. Hier ging es vor allem um technische Probleme beim Umschalten: Waren alle Programme in die Produktion übergeben? Waren die korrekten Systemtabellen eingerichtet? Nach und nach kamen die ersten O.K.-Meldungen, um 17 Uhr die letzte von der Buchhaltung, die - wie immer - am genauesten prüfte. Dann knallten die Sektkorken. Übermüdet aber erleichtert prostete das

Team dem Adam zu. Das Adam-System hat seine Funktion ohne Anlaufschwierigkeiten aufgenommen. Hier zahlten sich die umfangreichen Tests und das konsequente Change-Management aus. Durch einen Handlingfehler gab es eine gravierende Störung, die jedoch durch das vorbereitete Notprocedure aufgefangen werden konnte. Die Antwortzeiten (92 % aller Transaktionen unter einer Sekunde) und Verfügbarkeit (98,3 %) waren bereits im ersten Monat zufriedenstellend. Der erste Monatsabschluß wurde termingerecht durchgeführt.

Was waren die entscheidenden Erfolgsfaktoren?

Die Projektstrategie - Entwicklung und Test in Sockeln - machte das große Projekt beherrschbar. Konsequenter Einsatz von Methoden und Werkzeugen - mit Augenmaß für das Machbare und Wirksame - sicherte die Qualität. Rechtzeitige Einbindung aller Mitwirkenden und Betroffenen des Umfeldes brachte diese "ins Boot". Frühzeitige Konzentration auf Projektrisiken, wie Performance und Umstellung, vermied kritische Überraschungen. Die Bereitschaft des Managements aller Ebenen, Verantwortung zu übernehmen und sich selber bei Bedarf vor den Karren des Projekts zu spannen, war eine wichtige Voraussetzung für den Projekterfolg.

Der entscheidende Faktor war jedoch das Team: Ohne das ausdauernde Engagement und viele gute Ideen der Mitarbeiter aus Fachbereich und Entwicklung, ohne die gute Zusammenarbeit und Laune auch in schwierigen Phasen hätte das Projekt nicht erfolgreich sein können.