Im September 1991 endete die Pilotierungsphase des neuen ADAC-Vertriebs- und Informationssystems, kurz Adavis, die seit Dezember 1990 in fünf Geschäftsstellen durchgeführt wurde. Erstmalig ist damit im ADAC ein System mit einer Architektur verteilter Verarbeitung entwickelt worden: PC-Arbeitsplätze in den Geschäftsstellen sind in einem LAN vernetzt und über ein Gateway und das SNA-Netz an den Großrechner der ADAC-Zentrale (Host) angebunden. Arbeitsplatzübergreifende Daten und Funktionen werden durch Daten- und Funktionsserver bereitgestellt, die entweder auf dem lokalen Server der Geschäftsstelle oder auf dem Host liegen. Mit diesem auch organisatorisch komplexen Verfahren hat man technisches Neuland betreten - eine Herausforderung für das Entwicklungsteam wie für das Management.

Der ADAC betreibt 190 Geschäftsstellen. Sie sind Service-Einrichtungen für die Beratung seiner über 11 Millionen Mitglieder in allen Fragen rund ums Auto; dort werden Schutzbriefe verkauft, Benzingutscheine ausgestellt und ADAC-Reisen und -Waren angeboten. Diese Aufgaben erledigte man bis 1986 ohne DV-Unterstützung.

Ziele und Anforderungen des Projekts Adavis-I

Von 1986 an wurden die Geschäftsstellen schrittweise an die Informationssysteme der Zentrale angeschlossen und ein Kommunikationsnetz auf der Basis der SNA-Protokolle aufgebaut. In einem Pilotprojekt mit dem Namen ADAC-Vertriebs- und Informationssystem, Stufe 1 (Adavis-I) kamen verschiedene zentrale Hostanwendungen per 3270-Terminal via Datex-P oder HfD mit geringfügigen Modifikationen zum Einsatz. Diese Anwendungen (das Mitgliederverwaltungssystem Adam, die Bestandsführungssysteme der Versicherungen, Schutzbrief und Rechtsschutz sowie das Reservierungssystem der ADAC-Reise-GmbH) waren ursprünglich allein für die Fachabteilungen der Zentrale entwickelt worden.

Sie wurden in diesem ersten Schritt kaum integriert: Da die Benutzeroberflächen nicht verändert, sondern lediglich in einem Menü auf VTAM-Ebene zusammengefaßt wurden, war ein Datenaustausch zwischen den Anwendungen nicht möglich. Allein die Druckausgaben konnten durch eine gemeinsame Drucksteuerung zusammengefaßt werden.

Bereits mit dieser Lösung verbesserte sich der Service deutlich und die Arbeitsabläufe in den Geschäftsstellen vereinfachten sich ebenfalls. Deshalb wurden bis heute 135 Geschäftsstellen mit rund 800 Mitarbeitern an das Adavis-Netz angeschlossen.

Allerdings ließen sich auch früh die Schwächen dieses Verfahrens erkennen: Der Mitarbeiter muß während der Beratung eines Kunden dieselben Daten in mehrere Systeme eingeben. Werden zusätzlich zum Beispiel Waren mit personifizierter Rechnung verkauft, müssen auch noch konventionelle Geräte wie Kassen und Schreibmaschinen bedient werden. Die verschiedenen Anwendungen haben unterschiedliche Benutzeroberflächen (Maskenlayout, Funktionstasten-Belegung, Dialogführung ... ), die für ausgebildete Spartensachbearbeiter entworfen waren (Abkürzungen, wenig Hilfen). Die einzelnen Fachfunktionen sind für die Bearbeitung in der Zentrale auf den jeweils kompliziertesten denkbaren Fall ausgelegt und damit für Geschäftsstellen zu aufwendig zu bedienen.

Im Jahr 1987 begann man mit der Entwicklung eines integrierten Geschäftsstellensystems (Adavis-II), um Beratung und Vertrieb in den Geschäftsstellen noch besser zu unterstützen. Erreicht werden sollte dies vor allem durch eine einheitliche und bedienerfreundliche Benutzeroberfläche für alle integrierten Anwendungen sowie durch ein auf die Abläufe der Geschäftsstellen hin konzipiertes Systemdesign.

Durch die einheitliche Anzeige wichtiger Kundendaten in allen Masken sollte das Beratungsgespräch individualisiert werden. Ein zweites wichtiges Ziel war die Beschleunigung von Arbeitsabläufen, um in der Hochsaison Warteschlangen vor den Kassen zu vermeiden und mehr Zeit für Beratung zu gewinnen. Eine integrierte Computerkasse, die Automatisierung von Abrechnungsvorgängen und das Entfallen manueller Nebenaufzeichnungen waren hierfür die wichtigsten Lösungsansätze.

Trotz hoher Verfügbarkeit des Zentralrechners kommt es in den ADAC-Geschäftsstellen oft zu Systemausfällen aufgrund von DFÜ-Problemen. Dies ist vor allem im direkten Kundenkontakt sehr belastend. Deshalb war die Erhöhung der Systemverfügbarkeit durch ein lokales, DFÜ-unabhängiges. Notverfahren sehr wichtig.

Im Rahmen des Projekts sollte auch überprüft werden, ob der Anstieg der Rechner- und DFÜ-Kosten durch die Nutzung dezentraler Verarbeitungs- und Speicherkapazität Downsizing gebremst werden kann.

Von der DV-Lösung wurde außerdem verlangt, daß sie auf spezifische organisatorische Gegebenheiten einzelner Geschäftsstellen hin konfigurierbar ist, zum Beispiel:

- Betriebmodi (integriert/ ohne Host-Verbindung/Standalone-Kasse),

- Organisationsmodelle (Zentralkasse/Rundum-Beratung,

- Kasse und Unterlagendruck an einem Arbeitsplatz).

Adavis-II bearbeitet ebenso wie sein Vorgängersystem alle Geschäftsvorfälle, die den Vertrieb der zentralen ADAC-Produkte Mitgliedschaft, Schutzbrief und Rechtsschutz unterstützen. Neu hinzu kommen alle Produkte, für die eine zentrale Bestandsführung nicht vorgesehen ist (zum Beispiel Benzingutscheine, Auslandskrankenschutz) sowie regionale Produkte (zum Beispiel Warndreiecke, Landkarten). Adavis-II unterstützt eine vorgangsbezogene Bearbeitung, das heißt, daß alle von einem Kunden während eines Besuchs angestoßenen Geschäftsvorfälle unter einem Vorgang im System geführt werden. Alle für eine durchgängige Bearbeitung, insbesondere die für das gemeinsame Kassieren und Drucken aller Unterlagen erforderlichen Daten werden als Vorgangsdaten zusammengefaßt. Ein Vorgang wird implizit durch die Identifizierung des Mitglieds eröffnet und durch den Abschluß des Druckens und Kassierens beendet.

Vorgänge können zum Druck abgegeben werden; das heißt, im Backoffice werden bereits Unterlagen gedruckt, während das Mitglied weiter beraten oder an einen anderen Beratungsplatz weitergeleitet wird. Eine Vorgangsliste zeigt den Status aller Vorgänge, die sich noch in der Bearbeitung befinden.

Die Adavis-Kasse ist über die Vorgangsverwaltung in die Anwendung integriert: Der Vorgang wird an der Kasse aufgenommen; mit einer Funktionstaste wird kassiert. Alle Verkaufsfunktionen stehen auch an der Kasse zur Verfügung. Wird an der Kasse eine Position storniert, hinter der sich ein Bestandsführungsposten verbirgt, so wird die entsprechende Bestandsposition automatisch (auf dem Host) korrigiert. Die Integration mehrerer Kassen wird durch gemeinsame Produktdaten und einen über alle Kassen konsolidierten Tagesschluß ermöglicht.

Auch der Unterlagendruck bedient sich der Vorgangsdaten und informiert die zentralen Bestandsführungssysteme aber Druckwiederholungen bei Dokumenten, deren Verbleib überwacht werden muß (zum Beispiel Versicherungspolicen).

Die Integration vorhandener PC-Programme in die Adavis-Anwendung ist über eine Standardschnittstelle möglich.

Das Notverfahren ermöglicht bei Leitungsausfall oder bei einer Störung des zentralen Großrechners einen geordneten Übergang in einen Offline-Betrieb, in dem ein großer Teil der Funktionen weiterhin zur Verfügung steht.

Die Anwendung wird abgerundet durch administrative Funktionen wie: Pflege des Produktstamms, Benutzer-, Paßwort- und Berechtigungsverwaltung, Festlegung der Arbeitsplatztypen (Beratung/Verkauf und/oder Kasse), sowie die Betriebsfunktionen wie:

Datensicherungsverfahren, Verfahren zur Systemrekonfiguration, Bereitstellung neuer Daten- und Software-Releases.

Die Anforderungen an Avis-II legten eine Architektur verteilter Verarbeitung nahe:

- Hohe Bedienerfreundlichkeit der Benutzeroberfläche war auf dezentralen Rechnern wirtschaftlicher zu ermöglichen.

- Funktionen wie die Computerkasse konnten nur auf dezentralen Rechnern realisiert werden.

- Die Integration der Kassenfunktionen mit den Verkaufsfunktionen war nur im dezentralen Teil der Anwendung machbar.

- Für das Notverfahren waren große Teile der Anwendung dezentral zu implementieren.

- Die zentralen Stammdaten (Mitgliedschafts- und Versicherungsbestand) mußten wegen ihres Volumens und der überregionalen Verfügbarkeitsanforderung vom Host gelesen und dort fortgeschrieben werden.

- Aufgrund der hohen Übereinstimmung der Fachfunktionen mit denen, die bereits in den zentralen Anwendungen implementiert waren, galt es eine möglichst weitgehende Nutzung von funktionalen Host-Komponenten anzustreben, auch, um die komplexen fachlichen Zusammenhänge und Plausibilitäten nur einmal pflegen zu müssen.

- Die Einbindung zentraler Funktionsmodule und die Forderung nach stets aktuellen Mitgliedsdaten machte eine Programm-zu-Programm-Kommunikation dezentraler mit zentralen Anwendungsteilen notwendig.

Man dachte auch an alternative Architekturen: eine reine Host-Lösung (Integration der Benutzeroberfläche auf dem Host, Verzicht auf die Integration der Kasse und auf das Notverfahren) oder eine schwache Dezentralisierung (nur Benutzeroberfläche). Die Entscheidung fiel für eine vollständige Dezentralisierung aller Funktionen und Daten, die sachlich in die Geschäftsstellen gehören, und damit auf das ehrgeizige Konzept einer integrierten und verteilten Gesamtlösung auf der Basis einer Client-Server-Architektur.

Bei der Auswahl der dezentralen Hardware wurden Lösungen der mittleren Datentechnik (MDT) und der PCs im lokalen Netzwerk (LAN) erwogen. Aufgrund der Kriterien Flexibilität der Konfiguration, Nutzung der Hardware für andere Anwendungen, Kompatibilität zur vorhandenen Infrastruktur sowie Erfahrung mit der Lösung erhielt im Februar 1988 die PC-LAN-Lösung den Zuschlag.

Auf der ausgewählten Hardware-Plattform standen die Betriebssysteme Unix, OS/2 und DOS zur Entscheidung. Unix war damals am PC-Markt noch nicht etabliert, OS/2 nicht verfügbar. Außerdem waren sowohl bei Unix als auch bei OS/2 waren die aus dem hohen Hauptspeicherbedarf resultierenden Hardware-Kosten zu hoch. Es blieb nur DOS, sofern man die gesamte Entwicklung nicht auf einen späteren Zeitpunkt verschieben wollte. Es war verfügbar, bekannt, wirtschaftlich und bot eine große Auswahl von Software-Produkten. Bereits installierte Anwendungen konnten weiterbetrieben werden. Als Risiko wurde damals die zu geringe Leistungsfähigkeit dieses Betriebssystems und die Hauptspeicher-Restriktionen gesehen.

Token Ring mit LAN-Software

Die lokalen PCs wurden in einem LAN vernetzt, über ein Gateway und das SNA-Netz an den Großrechner angebunden. Aufgrund der vorliegenden Erfahrungen kam der Token-Ring mit der IBM LAN-Software zum Einsatz.

APPC (advanced program to program communication) war bereits als Standard für die Kommunikation zwischen verschiedenen Anwendungssystemen im Rahmen von SAA angekündigt. Die Versuche, eine lauffähige APPC-Implementierung im PC-LAN- und DOS-Umfeld zu finden, schlugen jedoch fehl. Um das Projekt nicht mit einem weiteren technischen Risiko zu belasten, konnte nur ein bewährtes Host-Kommunikations-Protokoll als Basis dienen: die 3270-Terminal-Emulation.

Über die API-Schnittstelle der 3270-Emulation wurde eine eigenentwickelte Software-Schicht (Kommunikationsmanager) gelegt, die aus Sicht des Anwendungsprogrammierers einen synchronen Remote-procedure-call realisiert. Ein späterer Übergang zu APPC wird dadurch erleichtert. Je Arbeitsplatz werden aus der Sicht des SNA-Netzes je zwei logische Terminals vorgesehen. Das erste wird von der Adavis-Software für die Programm-zu-Programm-Kommunikation integrierter Anwendungen genutzt, das zweite für die 3270-Emulation für alle noch nicht integrierten Anwendungen. Jederzeit kann man per "Hot-Key" zwischen PC- und Terminal-Anwendungen umschalten.

Ein Vorgang kann von einem Beratungsplatz zum anderen gereicht werden, bis zur Kasse. Parallel zur Beratung können für einen oder mehrere Druckarbeitsplätze Aufgaben anfallen, zum Beispiel das Drucken von Versicherungspolicen. Nach Beendigung des Vorgangs müssen Kassen- und statistische Daten für den Tagesschluß aufbewahrt werden. Einige Transaktionen schreiben die Bestandsdaten auf dem Host fort.

Der Schutz der Datenintegrität

Wurde ein Programm abgebrochen, dann müssen die Daten nach dem Wiederanlauf in einem konsistenten Zustand vorliegen. Ein über PC-LAN und die Hostanwendungen verteiltes Datenbanksystem mit den entsprechenden Transaktionsmechanismen stand nicht zur Verfügung. Daher mußte die systemübergreifende Transaktionslogik je nach Geschäftsvorfall durch selbstgeschriebene Wiederanlaufverfahren oder durch organisatorische Maßnahmen sichergestellt werden: Beim Host-Online-Update werden die Daten auch lokal weggeschrieben.

Bei einem Systemfehler in der dezentralen Anwendung wird zum Schutz der Datenintegrität - DOS hat keine Speicherschutzmechanismen - der gesamte Vorgang verworfen. Bei Fehlern in der zentralen Anwendung werden die lokalen Daten behalten und auf den Dialoganfang zurückgesetzt.

Die Prüfung der im PC-LAN unter DOS einsetzbaren Datenbanken ergab, daß diese den Performance-Anforderungen nicht genügten. Dies liegt vor allem daran, daß ein Fileserver in diesem Umfeld lediglich eine Sammlung von Remote-Dateien mit sehr groben Synchronisationsmechanismen auf Basis eines Single-Tasking-Betriebssystems ist und damit weit davon entfernt, Leistungen eines Datenbankservers zu erbringen. Deshalb wurde auf die Datenbank im Online-Geschäft ganz verzichtet. Schreibende Zugriffe finden nur auf DOS-Dateien statt.

Diese liegen bis auf wenige Ausnahmen lokal: Die Server-Daten (zum Beispiel Produktstamm) werden im Start-Verfahren nach dem Bedarf der Online-Zugriffe sortiert und in die lokale RAM-Disk der Arbeitsplätze kopiert. Schreibende Serverzugriffe sind auf markante Dialogstellen beschränkt, zum Beispiel "gib Vorgang ab".

Zweistufiges Zugangskonzept

Ziel des Datenschutzkonzepts war, die versehentliche Zerstörung von Daten zu verhindern und gezielte Manipulationen, die wirtschaftlichen Schaden verursachen können, stark zu erschweren. Die Nutzung der PCs über die Adavis-Anwendung hinaus sollte nicht beschränkt werden. Das Zugangs- und Berechtigungskonzept ist zweistufig:

- Auf der Ebene der Host-Schutzsoftware RACF werden die für jede Geschäftsstelle auf dem Host zulässigen Funktionen und Daten festgelegt. Je Geschäftsstelle wird ein täglich wechselndes, von der Software vergebenes Paßwort mit dem RACF ausgetauscht. Ein Arbeitsplatz erhält nur Zugang zum Host, wenn er das Benutzerkennwort seiner Geschäftsstelle mit dem Tagespaßwort übermittelt.

- Ein dezentral realisiertes Benutzer-, Paßwort- und Berechtigungskonzept regelt den Zugang zur gesamten Anwendung sowie benutzerspezifisch zu den einzelnen Funktionsgruppen.

Alle langfristigen Daten liegen nur auf dem Server. Erst beim Start der Anwendung wird die logische Verbindung zum Fileserver aufgebaut. Während die Anwendung arbeitet, kann der Benutzer nicht durch Abbruch oder Warmstart auf die DOS-Ebene wechseln, da die entsprechenden Tastenkombinationen abgefangen werden. Mit dem Verlassen der Anwendung wird die Serververbindung wieder abgebaut, so daß die von der Anwendung auf dem Server genutzten Dateien aus der DOS-Ebene des Arbeitsplatzes unzugänglich sind. Wichtige Informationen wurden kryptisiert.

Grundlage war eine bewährte Standard-Software-Systemarchitektur: Das Softwaresystem ist in Schichten gegliedert, die Modularisierung erfolgt nach dem Prinzip der Datenabstraktion auf der Grundlage eines Anwendungsdatenmodells. Im folgenden sind nur die Besonderheiten der verteilten Architektur dargestellt:

Eine Datenzugriffsschicht verbirgt vor der Anwendung die physische Verteilung der Daten (lokal, auf Server, auf Host). Eine Kommunikationsschicht kapselt die verwendeten Mechanismen für die Kommunikation zwischen den zentralen und dezentralen Teilen ein. In dieser Schicht erfolgt auch die Zuordnung von Geschäftsvorfällen zu zentralen Subsystemen, die Prüfung der Host-Verfügbarkeit und die Steuerung der Wiederanlaufverfahren.

Um Anzahl und Komplexität der Remote-procedure-calls zu reduzieren, müssen die aufgerufenen Host-Anwendungen so geschichtet sein, daß insbesondere zwischen dem Anwendungskern (das heißt, den die Fachfunktionen mit ihren zugehörigen Daten enthaltenden Modulen) und der Benutzeroberfläche eine klare Geschäftsvorfall-orientierte Schnittstelle vorliegt. Bei Altsystemen mußte eine solche Schicht eingezogen werden.

Die wesentliche Aufgabe der Prozeßorganisation war es, trotz der Speicherplatzrestriktionen eine leistungsstarke, Anwendung zu entwickeln. Die Schnittstellen zu den zentralen Anwendungssystemen bilden zwölf neue Host-Programme mit zirka 20 000 Lines of Code. Das dezentrale System besteht aus 850 Programm-Quellen und 90 Delta-Makros mit insgesamt ca. 100 000 Lines of Code. Daraus ergeben sich rund 85 gebundene Programme (EXE-Files).

Die durchschnittliche Exe-File-Größe liegt bei 200 KB. Nach Abzug von DOS, LAN- und Emulationssoftware verbleiben etwa 330 K für die Anwendung. 35 K werden von einem selbstentwickelten Prozeßwechselmechanismus belegt. Programme, die zu groß sind, werden Overlay-gelinkt. Die Programme liegen auf den Platten eines jeden Arbeitsplatzes, um ein Overlay-Nachladen übers Netz zu vermeiden (Performance). Da jeder Arbeitsplatz-PC fast die volle Softwareausstattung hat, kann er bei Serverausfall leicht zum neuen Server umkonfiguriert werden.

Stets die aktuelle Programmversion

Beim Start des Arbeitsplatzes wird durch einen Zeitstempelabgleich mit der auf dem Server hinterlegten Version und gegebenenfalls einem Herunterkopieren sichergestellt, daß der Arbeitsplatz die aktuellste Programmversion erhält. Eine Verteilung neuer Software-Releases beschränkt sich dadurch auf die Server.

Die Host-Komponenten des Adavis-Systems wurden mit der bewährten ADAC-Entwicklungsumgebung für Host-Software realisiert. Eine Entwicklungsumgebung für PC-Software wurde projektbegleitend aufgebaut. Anforderungen wie Portabilität, performante Realisierung, Speichereffizienz unter MS-DOS, Schnittstellen zu Standardprodukten (zum Beispiel Datenbank) ließen keine wirkliche Alternative zur Programmiersprache C. Zugleich sollte dadurch ein späterer Übergang zu Unix offengehalten werden. Ein Makrogenerator (DELTA) dient dazu, Programmrahmen zu generieren und Konstrukte einzukapseln, die in der gesamten Software-Entwicklung standardisiert werden oder deren Implementierung bei Tuning-Maßnahmen einfach änderbar sein sollen.

Window-Handling und Dialogsteuerung entwickelte man mit dem Standardprodukt Vitamin-C entwickelt. Die Verwaltung und Versionsführung der Software unterstützt das Standardprodukt PVCS. Als Werkzeuge für die automatische Codeprüfung kamen der Syntaxprüfer Lint und Boundschecker zum Einsatz, der Speicherverletzungen erkennt.

Erstmalige Nutzung der Programmiersprache C

Die Risiken des Projekts lagen vor allem in der Komplexität des organisatorischen Umfelds, einer dezentralen Anwendung mit zahlreichen Schnittstellen zur Zentrale und im breiten Einsatz noch nicht erprobter Technologien. Die Anforderungen an Adavis waren sowohl von den verschiedenen Fachabteilungen der Zentrale zu definieren als auch von den Regionalorganisationen des ADAC (Gaue) in Vertretung der Geschäftsstellen. Die fachlichen und technischen Konzepte und Schnittstellen mußten mit mehreren zentralen Informationssystemen abgestimmt werden.

Vor Adavis-II wurden komplexe Anwendungen im ADAC ausschließlich Host-gestützt entwickelt. Die Nutzung von PCs beschränkte sich auf die individuelle Datenverarbeitung. Die Realisierbarkeit des neuen Konzepts erschien deshalb in mancher Hinsicht fraglich. Neue technische Infrastrukturen und das Know-how des Projektteams über die neuen Technologien mußten zum Teil projektbegleitend aufgebaut werden. Besondere Gefahren für die Qualität wurden in der im ADAC erstmaligen Nutzung der mächtigen Programmiersprache C gesehen.

Der Projektauftrag erteilte die Geschäftsführung der ADAC-Zentrale in Abstimmung mit den Geschäftsführern der unabhängige Gaue. Hier war viel Raum für unterschiedliche fachliche Sichten und Interessenskonflikte.

Deshalb traf ein Projektausschuß, der sich aus Leitern der betroffenen zentralen Fachabteilungen und Vertretern der Regionalorganisationen zusammensetzte, die Entscheidungen über Prioritäten und Zielkonflikte. Zur Koordination der Projektaufgaben wurde ein eigener Managementkreis (IV-Koordinationsrunde) eingerichtet. Seine Aufgabe war es vor allem, den Aufbau technischer und organisatorischer Infrastrukturen mit den Anforderungen des Projekts abzustimmen.

Das Gesamtprojekt beschäftigte bis zu 30 Mitarbeiter (davon 15 Software-Entwickler) und wurde in drei Teilprojekte gegliedert: Software-Entwicklung, Technik und Organisation. Eine innerhalb der Informationsverarbeitung für die Betreuung der dezentralen Organisationen des ADAC zuständige Stelle übernahm die Koordination der fachlichen Anforderungen der Geschäftsstellen und der zentralen Fachbereiche. Die dezentralen Organisationen wurden durch Anwenderkreise eingefunden.

In einer Voruntersuchung wurde der Aufwand erstmals geschätzt und die Gesamtplanung entworfen. Dann spezifizierte man die Systemfunktionen und erarbeitete ein technisches Grobkonzept. Um die Machbarkeit der PC-Host-Kommunikation sicherzustellen, realisierte man schließlich einen technischer Prototyp.

Test der Vorabversionen

Durch Codierrichtlinien schränkte man die Nutzung de Programmiersprache C ein. Programmierstandards wurden zum Teil durch Macros unterstützt. Programminspektionen sollten sicherstellen, daß die Standards beachtet werden.

Die Realisierungsphase war in drei Entwicklungsabschnitte gegliedert; vor der eigentliche Fertigstellung des auslieferungsfähigen Softwareprodukts dienten zwei Vorabversionen für die notwendigen Lern- und Überprüfungszyklen.

Die einzelnen Versionen wurden von einem Team aus Fachbereichsmitarbeitern und Entwicklern getestet. Um die Reproduzierbarkeit der Tests sicherzustellen, verfaßte man Drehbücher entlang der Systemspezifikation, richtete dazu passende Testdatenbestände ein und setzte zum Teil Tools zur automatischen Testwiederholung ein.

Beim Test der ersten Vorabversion zeigten sich Performance-, später Stabilitätsprobleme. Die geplante Auslieferung zur Sommersaison 1990 scheiterte. Es wurde eine dreimonatige Qualitätssicherungsphase eingezogen.

Mit Reviews, Walkthroughs und Code-Reading, aber auch neuen Werkzeugen zur automatischen Codeprüfung erreichte man schließlich das angestrebte Qualitätsziel.

Durch einen umfangreichen Abnahmetest, bestehend aus: Einzelfunktions-, Integrations-, Last- und Robustheitstest, wurde die Produktionsreife des Adavis-Systems schließlich unter Beweis gestellt.

Das Entwicklungspaket war zu dick geschnürt

Die evolutionäre Vorgehensweise hat in diesem Projekt Probleme frühzeitig sichtbar werden lassen, so daß entsprechende Maßnahmen ergriffen werden konnten.

Allerdings war aus heutiger Sicht (unter Berücksichtigung der technischen Risiken) das Entwicklungspaket für die erste Auslieferung zu dick geschnürt. Eine stufenweise Einführung hätte dem Anwender früher Nutzen gebracht und den Verantwortlichen einigen Kummer erspart.

Im November 1990 ging das neue Adavis in einer ersten Pilotgeschäftsstelle in Produktion. Bis zum April 1991 nahmen weitere vier Geschäftsstellen den Pilotbetrieb auf. Er wurde im Herbst letzten Jahres erfolgreich abgeschlossen.

In einem neuen Release konnten Erkenntnisse aus der Pilotphase bezüglich Handhabbarkeit, Robustheit und Betriebssicherheit berücksichtigt werden.

Das System wird von den Anwendern akzeptiert

Das System wird von den Anwendern akzeptiert, seine Performance und Stabilität sind gut. Die Antwortzeiten der Transaktionen, die an den Host durchgereicht werden, sind im Mittel um eine halbe Sekunde schneller als die entsprechenden Transaktionen des abgelösten Verfahrens, da das zu übertragende Datenvolumen um mehr als die Hälfte reduziert worden ist.

Lokale Prüfungen liegen im Millisekundenbereich, Dialogwechsel, die einen Overlay-Wechsel erfordern, unter einer Sekunde. Seltenere Transaktionen, wie Vorgang zum Kassieren abgeben, die Serverzugriffe erfordern, sind lastabhängig und können bis zu drei Sekunden dauern.

Die realisierten Mechanismen zur Erkennung und Protokollierung von Systemfehlern durch die Software haben dazu beigetragen, daß die Anwendung rasch robust wurde: Ein Systemfehler tritt heute im Mittel an einem Arbeitsplatz einmal in zehn Wochen auf.

Bis zum Mai 1992 ist die Installation in weiteren 40 Geschäftsstellen vorgesehen. Dies wird durch die organisatorische Umsetzung des Einführungs- und Betriebskonzepts und die weitere Automatisierung der Installations- und Verteilungsverfahren vorbereitet.

*Norman Heydenreich ist Leiter der Systementwicklung des ADAC

**Karlheinz Schneider ist Chefberater bei sd&m, München