Der VW-Geschäftsbereich Leasing (VWL) bietet seinen Kunden Leasingfahrzeuge und sonstige Dienstleistungen rund ums Auto an, zum Beispiel Abrechnung von Kraftstoff, Ersatzwagen, Schadenservice etc. Mit der monatlichen Abrechnung erhalten die Kunden neben der Aufstellung ihrer festen und variablen Kosten eine Vielzahl von Auswertungen, unter anderem über durchschnittliche Kilometerleistungen und den Kraftstoffverbrauch. Auch mit diesem Aufwand und des damit verbundenen erheblichen Papierverbrauchs ist es heute besonders für die Kunden, die ganze Fahrzeugflotten bei der VWL unter Vertrag haben, fast unmöglich, damit ihren Fuhrpark effektiv zu verwalten und zu analysieren.

Abhilfe soll ein neues Reporting-System schaffen. Das Anwendungssystem "Flotten-Reporter" soll als Ergebnis des Projekts "Flotten-Management Reporting System" (FMR) den Kunden Funktionen zur Organisation und Analyse ihrer Fuhrparks anbieten. Jedem Kunden werden die Informationen über die ihn betreffenden Verträge, Verbrauch und Kosten, die weiterhin zentral auf einem VWL-Host gespeichert sind, als eigene Datenbank bereitgestellt.

Mit der Entwicklung des neuen Reporting-Systems verfolgt die VWL-Mutter Financial Services (VWFS) zwei Ziele: Eine erste Version des Flotten-Reporters soll frühestmöglich an die Flottenkunden ausgeliefert werden. Und das Anwendungssystem soll mit Hilfe objektorientierter Methoden und Werkzeuge auf einer Smalltalk-Plattform realisiert werden. Durch das Pilotprojekt werden Know-how über objektorientierte Entwicklung und Grundlagen für eine strategische Entscheidung über die zukünftige Anwendungsentwicklung im Client-Server-Bereich erarbeitet.

Mit der Phase "Anforderungen" begann die Projektarbeit. Die ersten Schritte bestanden darin, mit dem Fachbereich Fuhrpark-Controlling die Projektziele zu definieren, die fachlichen und technischen Anforderungen zu sammeln sowie die Rahmenbedingungen des Projektes zu bewerten.

Die zentrale Dokumentation der fachlichen Anforderungen ist das "Use-case-Modell". Es definiert zwölf Benutzerrollen, sogenannte "Actors", die von dem Anwendungssystem Unterstützung für rund 40 Geschäftsvorfälle ("use cases") erwarten. Auf Basis dieses Modells wurde ein grober Gesamtprojektplan erstellt. Danach wird der Flotten-Reporter in drei bis vier Entwicklungszyklen zu vollständiger Funktionalität heranreifen.

In Zyklus 1 sollen die wichtigsten Standardfunktionen programmiert werden. Jeder weitere Zyklus soll diese dann erweitern und schließlich ein neues auslieferungsfähiges Produkt hervorbringen. Der erste Entwicklungszyklus, der wie alle anderen aus Analyse, Design, Realisierung sowie der Planung des nächsten Zyklus besteht, wurde detailliert geplant.

Die erste Version des Flotten-Reporters wird die Bearbeitung der vier wichtigsten Geschäftsvorfälle ermöglichen. Damit läßt sich ein Großteil der Standardfunktionen bereitstellen. Als Entwicklungszeit sind drei Monate vorgesehen. Die Phase Anforderungen wurde nach zirka vier Wochen beendet. Der erste Entwicklungszyklus konnte beginnen.

Wurden die fachlichen Anforderungen bisher eher allgemein betrachtet, so werden jetzt die für diesen Zyklus ausgewählten Use-cases einer detaillierten Analyse unterzogen. Diese beginnt mit der Detailbeschreibung der Geschäftsvorfälle, auf deren Grundlage die Suche nach den involvierten Fachklassen erfolgt.

Dazu eignen sich CRC-Karten (CRC = class, responsibility, collaborator) besonders gut: Im Brainstorming wird für jeden Klassenkandidaten eine Karteikarte mit dessen Namen (class) angelegt. Darauf werden dann all die Leistungen festgehalten, die die Objekte dieser Klasse erbringen sollen (responsibility) sowie die dabei mitwirkenden Klassen (collaborator). Das erste - aus den CRC-Karten abgeleitete - fachliche Klassenmodell enthielt über 80 Fachklassen und deren Beziehungen untereinander.

Auf Basis des Klassenmodells konnte man parallel fortschreiten: Ein GUI-Prototyp entstand, der die Dialogabläufe simuliert. Fachklassen wurden als Smalltalk-Klassen implementiert. Aus dem Klassenmodell ließ sich das Datenmodell ableiten. Der Fachbereich konstruierte Testfälle und eine Testdatenbank. Verfahren für die Datenübernahme vom Host wurden spezifiziert.

Die einzelnen Tasks weisen hohe Interdependenzen auf. Analyse, Design und Implementierung greifen stark ineinander und produzieren permanent wechselseitige Rückwirkungen. Besonders wichtig waren die Abstimmungen und Diskussionen des GUI-Prototypen mit Fachexperten und Pilotanwendern.

Die Analyse geht mit der Implementierung von Smalltalk-Klassen in die Realisierungsphase über. Modifikationen und Erweiterungen des Klassenmodells sind jederzeit möglich.

Diese Arbeitsweise ist sehr effektiv, sie stellt aber hohe Anforderungen an die Kommunikation und das Projekt-Management. Jeder Beteiligte muß die Vorgehensweise und die bisher erzielten, weitgehend voneinander abhän- gigen Ergebnisse genau kennen. Kommunikationsfördernd waren die räumliche Nähe der Projektmitarbeiter, regelmäßige Meetings und Workshops sowie ein einfacher Mechanismus für den Austausch von Mitteilungen.

Die zeitgleiche Bearbeitung verschiedener Modelle durch mehrere Projektmitarbeiter ist ohne ein CASE-Tool mit einem zentralen Repository, das für alle beteiligten Mitarbeiter verfügbar ist, fast unmöglich. Mit Hilfe des Tools lassen sich Use-case-, Klassen- und Datenmodelle aufbauen und pflegen. Das Werkzeug sollte ein Regelwerk bereitstellen, das für vollständige, widerspruchsfreie und einheitliche Modelle sorgt. Wünschenswert ist die Generierung von Smalltalk-Code und eine Unterstützung bei der Aufrechterhaltung der Konsistenz zwischen Klassenmodell und Klassenimplementierung. Im FMR-Projekt kam das CASE-Tool "Select Enterprise" für Analyse und Design zum Einsatz.

Den ersten Entwicklungszyklus zeichnen zwei Besonderheiten aus: Erstens muß dem Entwurf des Klassenmodells große Aufmerksamkeit gelten. In ihm ist die Basis für die weitere Produktentwicklung definiert.

Zweitens müssen Anwendungsarchitektur, Entwicklungsstandards und Klassenbibliotheken (Frameworks), zum Beispiel für die Unterstützung von Datenbankzugriffen, spätestens mit dem Entwurf des ersten Klassenmodells vorliegen. Ohne diese Grundlagen sind keine sinnvollen Design- oder Realisierungsaktivitäten möglich. Und ohne erfahrene Spezialisten auf dem Gebiet der Objekttechnik sind diese Ergebnisse nicht zu erreichen.

Der Flotten-Reporter ist nach einer Schichtenarchitektur aufgebaut. Die View-Schicht realisiert die Benutzeroberfläche. Die Controller-Schicht sorgt für die Bearbeitung der Benutzereingaben, die Steuerung des Dialogablaufes und die Aktualisierung der Benutzeroberfläche bei einer Änderung der Fachobjekte. Die Model-Schicht umfaßt die Fachklassen beziehungsweise -objekte. Datenbank-Server sorgen dafür, daß ein Fachobjekt aus einer Datenbank aufgebaut beziehungsweise in ihr gespeichert werden kann. Das Produkt "ODB-Talk" setzt die von den Servern gewünschten Datenbankzugriffe um und führt diese aus. Die Speicherung der Daten selbst erfolgt in einer relationalen Datenbank.

Das Standardverhalten einer Schicht ist in abstrakten Klassen implementiert, die es an die einzelnen Objekte der Unterklassen vererben. Die Mechanismen für die Darstellung der Objekte an der Benutzeroberfläche und die Dialogsteuerung stellt ein einfaches Model-View-Controller-Framework bereit.

Für die Speicherung von Objekten in der Datenbank sorgt das Persistenz-Framework. Es läßt die Fachobjekte, DB-Server, ODB-Talk und die Datenbank zusammenwirken. Diese Architektur stellt die Unabhängigkeit der einzelnen Komponenten sicher und schafft die Grundlage für eine weiterentwicklungsfähige, wiederverwendbare Software.

Nach den Erfahrungen im FMR-Projekt kann der Einstieg in die objektorientierte Anwendungsentwicklung ohne "Forschungsprojekte" und Trockenkurse erfolgen. Ein Pilotvorhaben wie dieses mit realem Fertigstellungsdruck zwingt zu pragmatischen und erprobten Lösungen. Experimentierfelder bestehen kaum.

Vorgehensmodell, Methoden, Tools und Architektur müssen zu Projektbeginn feststehen. Erprobte Lösungen sollten übernommen werden. Es ist sinnvoller, damit praktische Erfahrungen zu sammeln, als alles selbst erfinden zu wollen. Wenig erfolgversprechend wäre es hingegen, ohne die praktischen Erfahrungen aus einem echten Projekt nach den "richtigen" Entwurfsmethoden oder der "allumfassenden" Entwicklungsumgebung zu suchen.

Die Vorteile der objektorientierten Programmierung sind nur zu erreichen, wenn die Anwendungen auf einer wohlstrukturierten Architektur aufbauen. Sie muß gewährleisten, daß alle Komponenten gekapselt, austauschbar, weiterentwicklungsfähig und wiederverwendbar sind. Das Standardverhalten der Applikation läßt sich in den abstrakten Klassen von Frameworks in Folgeprojekten erweitern.

Hinsichtlich ihrer Effizienz haben sich Frameworks und Standards schon während der bisherigen Projektlaufzeit bewährt. Ihren vollen Nutzen werden sie in den weiteren Zyklen, Folgeprojekten und bei der Integration neuer Mitarbeiter entfalten.

Mit über einem Viertel des Gesamtaufwandes stellt die Ausbildung den größten Kostenfaktor in der ersten Phase des Pilotprojekts dar. Die reine Programmierung des Flotten-Reporters hat nur 18 Prozent der Ausgaben verursacht.

Auch die Aufwände für die Analyse sind gering. Klassen- und Datenmodell sind in etwa drei Wochen erstellt worden. Zusammen mit dem GUI-Prototypen waren nur 14 Prozent des Gesamtaufwands notwendig, um eine ausreichende Fachspezifikation zu erarbeiten. Die Ausbildung ist mit dem Pilotprojekt nicht beendet.

Zirka ein Fünftel der Gesamtkosten ist in die Bereitstellung der Entwicklungsumgebung geflossen. Angesichts ihres Nutzens sind die Investitionen in den Einsatz und die Anpassung der Frameworks (Architektur) und die Definition der Standards mit einem Anteil von vier respektive drei Prozent sehr gering. Der pragmatische Ansatz, auf die Lösungen eines Beratungsunternehmens zu setzen, hat sich hier am produktivsten ausgewirkt.

Die Arbeit an dem FMR-Projekt orientiert sich an zwei Maximen: Erstens lassen sich die Vorteile objektorientierter Entwicklung nur dann vermitteln und realisieren, wenn man deren Entwurfs- und Konstruktionsprinzipien konsequent anwendet. Das erfolgt zweitens mit den kostengünstigsten Lösungen.

Dadurch war es in nur etwa fünf Monaten möglich, eine Entwicklungsumgebung, Anwendungsarchitektur, Entwicklungsstandards und -konventionen bereitzustellen, die VWFS-Mitarbeiter intensiv auszubilden und den Flotten-Reporter soweit flottzumachen, daß die Version 1.0 termingerecht fertiggestellt wurde. Ohne die Effizienz der objektorientierten Vorgehensweise und der auf Smalltalk basierenden Entwicklungsumgebung wäre dies nicht möglich gewesen.

Angeklickt

Die Entscheidung über den Einstieg in die Objekttechnologie machen viele Firmen von den Erfahrungen eines Pilotprojektes abhängig. So auch die Volkswagen Financial Services (VWFS), die seit August 1996 das Projekt "Flotten-Management-Reporting System" (FMR) auf der Grundlage eines objektorientierten Vorgehensmodells durchführt. Dieser Beitrag gibt einen Überblick über die Vorgehensweise, Erfahrungen und Kosten dieses Projektes.

*Dirk Lucht ist als Projekt-Manager und Berater bei der CS Consulting Services GmbH in Hannover für den Bereich Objekttechnologien verantwortlich