Horst Walther und Tim Braasch[1]

Situation und Zielsetzung

Berater und externe Führungskräfte werden im allgemeinen nur dann herangezogen, wenn es Probleme gibt. Genau das ist die Situation in der ein Versicherer uns die problematische Aufgabe stellt, das Management für ein objektorientiertes Softwareentwicklungsprojekt zu übernehmen.

Das Projekt hat eine ausgeprägte Vergangenheit.

Durch das Projekt zieht sich ein Methodenbruch. Die Analyse wird noch strukturiert durchgeführt. Realisiert wird jedoch objektorientiert, und ein Design hat überhaupt noch nicht stattgefunden.

Mit IAA, Workflow-Management, Objektorientierung (OO) und der angestrebten Realisierung in einem Client- / Server-Umfeld werden vier innovative Architekturprinzipien gleichzeitig in ein nur gering organisiertes Großprojekt getragen. Das damit verbundene Risiko wird dadurch noch gesteigert, dass das junge und ehrgeizige Projektteam nur über geringe Realisierungserfahrung verfügt.

Ein abgestimmtes Projektvorgehen, das den verwendeten Methoden gerecht wird und eine verlässliche Projektsteuerung erlaubt, existiert nicht. Es wird nicht einmal vermisst. Schlüsselfaktoren für den Erfolg von OO-Projekten, wie das Vorhandensein einer leistungsfähigen Metric & Prognose-Gruppe, eine wirksamen Qualitätssicherung oder eines organisierten Wiederverwendungsmanagements fehlen ebenso.

Mit einem geeigneten Projektmanagement und der Beschaffung des erforderlichen kritischen Spezial-Wissens ist dafür zu sorgen, dass das geplante Softwaresystem entwickelt und geliefert werden kann.

Größte Herausforderung dabei ist nicht das Herausarbeiten der fachlichen Anforderungen oder das Lösen einzelner kniffliger technischer Problemstellungen. Die wirkliche Aufgabe ist, einen verlässlichen, steuerbaren und der verwendeten Methodik und Technologie angemessenen Softwareentwicklungsprozess zu entwerten, einzuführen und laufend zu optimieren. Ein Prozess, der einigen Anforderungen genügen muss:

Die Risikopositionierung des Projektes

Transparenz

Der Entwicklungsprozess muss sich durch quantitative Kenngrößen beschreiben lassen. Zusätzlich muss der Entwicklungsfortschritt auf der Ebene der Einzelkomponenten der Teilprojekte und des Gesamtprojektes jederzeit und ohne Rückfragen ermittelbar sein.

Reife

Der Prozess der Softwareentwicklung muss eine hohe Reife im Sinne des CMM (Capability Maturity ModeI) des SEI (Software Engineering Institute) aufweisen.

Qualitätssicherung

Als Projektergebnis darf nur betrachtet werden, was zuvor offiziell durch ein Qualitätsmanagement freigegeben wurde. Ergebnisse sind entweder zu 0 % oder zu 100 % fertiggestellt. Ein "ich glaube, ich bin zu 90% fertig" darf es nicht geben.

Verteilbarkeit

Es muss möglich sein, durch autonome Teams an unterschiedlichen Standorten an einer gemeinsamen Aufgabe zu arbeiten. Fehl- und Doppelentwicklungen sind möglichst zu vermeiden.

Ortsunabhängigkeit

An den verschiedenen Standorten des Projekts und der beteiligten internationalen Experten müssen die erforderlichen Projektergebnisse, Teilergebnisse, Richtlinien und Standards mit vertretbarem Zeitverzug verfügbar sein. Die Kommunikation arbeitender Teams muss unterstützt werden.

Toolunterstützung

Durch Werkzeuge soll die Einhaltung der Prozesswege erleichtert werden. Changemanagement von Ergebnistypen und Qualitätssicherungsmaßnahmen sollen zwingende Bestandteile sein. Die Ergebnisse müssen unmittelbar an verschiedenen Projektstandorten zur Verfügung stehen.

Bündelung der Inkremente nach Geschäftsprozessen und 'Aktivitäten'

Strategie

Das strategische Vorgehen ist wie das Projekt selbst außerordentlich komplex:

Neuanfang

Durch Klausur-Workshops, den Austausch von Projektführungskräften, eine neue Projektaufbauorganisation, neue Projektaufträge und eine Promotionsfunktion des Vorstands wird ein Schlussstrich unter die Vergangenheit gezogen. Niemand wird für Fehl-Leistungen der Vergangenheit zur Rechenschaft gezogen. Niemand kann die Vergangenheit als Ausrede benutzen.

Einheitliche Methodik

Der Methodenbruch wird mittelfristig beseitigt. In Projekten. die dem objektorientierten Paradigma folgen, können nur objektorientierte Methoden eingesetzt werden.

Für die Analysephase wird der Use Case-Ansatz von Ivar Jacobsen ausgewählt. Im Design folgt die Orientierung dem praxiserprobten Ansatz von Grady Booch. Die vorgeschaltete Geschäftsprozessanalyse dient als Quelle für das Auffinden von Use Cases. Eine Konvergenz der beiden methodischen Ansätze zur Unified Method ist absehbar,

Zyklisches Entwickeln

Objektorientierte Software kann - wie andere Software auch - nicht in einem Schritt entwickelt werden. Beginnend mit einem ersten, evolutionären Prototyp wird des Gesamtsystem schrittweise oder besser schichtweise in Entwicklungsinkrementen aufgebaut.

Nach jedem, etwa drei Monate in Anspruch nehmenden, Entwicklungsinkrement werden die fertiggestellten Komponenten "zusammengeschraubt" und das System einem Probelauf unterzogen. Fehlende Komponenten werden durch "Brücken" und "Stutzen" ersetzt.

Mit diesen Erkenntnissen wird das Entwicklungsinkrement iterativ verfeinert, redesigned, erstellt oder sogar mit leicht geänderten funktionalen Anforderungen versehen. Dann folgt das nächste Inkrement.

Formales Vorgehen

Jedes Projekt braucht eine Struktur, Steuergrößen müssen numerisch fassbar sein. Die fünf Disziplinen der "Projekt-Mess-und-Regeltechnik" (sizing, estimating, planning, tracking and measuring) müssen quantitative Messgrößen liefern.

Qualität und Produktivität müssen messbar und transparent werden. Die produzierbaren Ergebnistypen sind vor Projektstand (der mit dem Projektauftrag beginnt) bekannt und Grundlage der Planung.

Es gilt das Prinzip der Flächendeckung: Jedes Projektergebnis wird nach einer überprüfung durch das Qualitätsmanagement formal freigegeben. Es gilt das 100 %-Prinzip.

Teammischung

Analytiker und Realisierer werden Teammitglieder. So muss zum Beispiel jeder, der noch nie selbst entwickelte Software durch die gefürchtete Qualitätssicherung des Change & Configuration Management (CCM) gebracht hat, mindestens einmal dieses Tal der Tränen durchschreiten.

Entschärfung technischer Brisanz

Immer nur eine Innovation zur Zeit - soweit ließ sich das Rad nicht mehr zurückdrehen. Der IAA wird wieder der Platz als Referenzmodell (und nicht als 1:1-Designvorgabe) zugewiesen. Das Workflow-Management wird durch einen selbstentwickelten Minimal-Kern realisiert. Zur Absicherung der technischen Risiken wird externes Know-how eingekauft.

Top-Experten von außen

Schlüssel-Know How wird eingekauft. Anerkannte Experten werden engagiert. Ein speziarisiertes Geratungsunternehmen liefert zusätzlich Versicherungsfachwissen. Es werden Berater engagiert, die über die seltene Mischung aus erfolgreicher Client/Server-Realisierung, objektorientiertem Entwicklungs-Know-how und umfassenden Systemkenntnissen verfügen.

Für die Einführung des sinn nach der Methode der "function point analysis", der Software-Metric und für den Aufbau des Qualitätsmanagements werden externe Kräfte auf Zeit herangezogen.

Starkes Projektmanagement

Nach den Erfahrungen mit dem "gespaltenen Ego" der doppelt besetzten Projektleitung in der Anfangsphase des Projekts wird besonderer Wert auf ein starkes Projektmanagement gelegt. Wichtig dabei: Enge Kontakte zum Vorstand und zu den Entwicklungspartnern. Da die persönliche Einbindung in den Konzern fehlt, kommt es hier vor allem auf die Kompetenz an. Aus der sich eine entsprechend persönliche Autorität ganz natürlich ergibt.

Ergebnis

Der Entwicklungsprozess ist nicht nur freigegeben - er wird bereits in großen Teilen gelebt. Die Tool-Unterstützung ist ein Projekt-Support-System auf Basis Lotus Notes.

Zeit und Raum werden durch die Verwendung elektronischer Projektakten überbrückt. Ein konsequenter rechnergestützter Qualitätssicherungsprozess erlaubt keine Ausnahmen und liefert die nötige Transparenz. Für sizing und estimating werden wissensbasierte Werkzeuge und entsprechende Wissensbasen für vergleichbare Projekte eingesetzt.

Alle Mitarbeiter sind de, Objektorientierung verpflichtet. Sie sind darin geschult und arbeiten in allen Phasen des Projekts danach.

Die Projektprozesse zielen auf den unmittelbaren Nutzen des Projekts: die Realisierung einer modernen Anwendungslandschaft.

Das Projekt wird realistischer gesehen.

Das Projektmanagement ist intern und extern akzeptiert und bringt das Projekt dementsprechend nach vorn.

Nutzen

Das Vertrauen in ein ehrgeiziges Projekt ist wieder weitestgehend hergestellt. Die "Fertigungsstraße" für die Softwareproduktion ist in Betrieb genommen worden. Erste Teilergebnisse sind erfolgreich zugekauft, entwickelt und installiert.

Niemand kann jetzt schon behaupten, alle Probleme des Projekts seien bereits gelöst und der Gesamterfolg sei nur eine (kleine) Frage der Zeit.

Eines allerdings steht schon heute fest: Auch Projekte, die bisher respektierte Grenzen überschreiten, sind machbar.

[1] erschienen 1997 in Jahresbericht der agens Consulting GmbH unter dem Punkt "Tat-Sachen" auf Seite 34.

Horst Walther, Hamburg