Projekte richtig organisieren

Objektorientierung braucht ein evolutionaeres Vorgehensmodell

22.03.1996

In der Regel laesst sich ein Anwendungssystem nicht in einem Schritt herstellen. Es bedarf mehrerer Zyklen. Dabei koennen sich die jeweiligen Zwischenstufen stabilisieren und bewaehren. Evolutionaer vorzugehen bedeutet auch, sich darauf einzulassen, am Anfang noch nicht zu wissen, welchen Anforderungen das System am Ende ausgesetzt sein wird.

Das Wasserfallmodell kennt jedoch keinen asynchronen Entwicklungsverlauf, sondern beruht auf der Annahme, dass die einzelnen Phasen nacheinander abgearbeitet und abgeschlossen werden koennen. Die Projektrealitaet sieht mehr oder weniger anders aus. Steigende Komplexitaet fuehrt dazu, einen Teil der Aufgaben und Probleme auszublenden und zu verschieben. Das zieht jedoch haeufig ein boeses Erwachen nach sich.

Die objektorientierte Systementwicklung ist komplexen Anforderungen besser gewachsen, wenn sie einem dynamischen und evolutionaeren Vorgehensmodell folgt. Kennzeichnend fuer dieses Vorgehensmodell ist die Gliederung der Entwicklungsaktivitaeten in deutlich kleinere Einheiten als die traditionellen Phasen sowie die koordinierte Verzahnung von Aktivitaeten unterschiedlicher Detaillierungsebenen. Die Entwicklung vom Groben zum Detail erfolgt nicht mehr synchron fuer alle Bereiche des Systems, sondern situativ je nach Prioritaet und Problemstellung.

Somit ist es kaum sinnvoll, die Verantwortlichkeiten innerhalb des Projekts phasenorientiert abzugrenzen. Statt dessen muss eine gegenstandsorientierte Arbeitsteilung und Projektkontrolle erfolgen. Neben dieser gegen- standsorientierten Arbeitsteilung stellt sich auch die Planung und Ueberpruefung der Einzelaufgaben anders dar. Der Projektfortschritt wird an feiner granulierten Ergebnissen abgelesen. Fuer das Projekt-Management bedeutet dies eine Abkehr von einer scheinbaren genauen Gesamtplanung zugunsten eines flexiblen und permanenten Planungsprozesses.

Am Anfang steht eine Untersuchung der Geschaeftsprozesse und deren Optimierung; kritische Teile der Geschaeftsprozesse lassen sich moeglicherweise durch Informationssysteme (IS) unterstuetzen oder automatisieren, andere koennen gegebenenfalls durch organisatorische Massnahmen optimiert werden. Die IS-relevanten Teile der Geschaeftsprozesse koennen den Anstoss zur Entwicklung eines Informationssystems liefern.

Bevor ein solches Projekt in der Abfolge Analyse, Design, Realisierung und operativer Einsatz in mehreren Zyklen entwickelt wird, findet zunaechst in gleicher Abfolge ein zeitlich begrenzter Schnelldurchlauf, ein Initial-Workshop, statt. Dieser sollte ungefaehr zwei bis vier Wochen dauern. Die Informatiker erschliessen fuer sich Begriffe und Kontexte der Anwendungswelt, die Anwender erhalten einen ersten Eindruck von den bevorstehenden Entwicklungen. Ausserdem werden die Kommunikationswege und - strukturen fuer die nachfolgende Projektarbeit konstituiert. Sofern sich das Projektthema ueber mehrere eigenstaendige Anwendungsgebiete, zum Beispiel ueber diverse Fachabteilungen erstreckt, sollte fuer jedes dieser Gebiete eine Schnellanalyse stattfinden.

Die Workshop-Ergebnisse und -Bewertungen bilden die Basis fuer das Projekt-Management und fuer weitere Evolutionszyklen. Sie bestehen jeweils aus der detaillierten Analyse eines Teilbereiches des Systems, der Abbildung der sich daraus ergebenden Anforderungen in das Systemdesign, der Realisierung dieses Teilsystems und seinem anschliessenden operativen Einsatz. Jeder Zyklus endet mit einer Ergebnispruefung (Review), welche die Konsolidierung und Weiterentwicklung im naechsten Zyklus anstoesst. Je Evolutionszyklus sind abhaengig von der Systemgroesse etwa zwei bis fuenf Monate zu veranschlagen. Bis zur vollstaendigen Entwicklung des Systems muessen drei Zyklen einkalkuliert werden.

Diese Zahlen geben nur eine grobe Orientierung und sind unter anderem von folgenden Parametern abhaengig: der Systemgroesse, der Entwicklungsbasis sowie der Anzahl und Produktivitaet der Entwickler.

Die IS-relevanten Arbeitsfluesse muessen nun detailliert untersucht und in typischen Anwendungsfaellen und -szenarien beschrieben werden. Dabei dienen diese Szenarien nicht allein zur Beschreibung des gegenwaertigen Zustandes, sondern vor allem auch zur Einarbeitung der Software-Entwickler in das Anwendungsfachgebiet.

Aus der Beschreibung des Ist-Zustandes lassen sich Anwendungsfaelle (Use Cases) erstellen. Diese stellen den angestrebten Zustand dar und illustrieren, wie die Arbeitsablaeufe mit dem zu entwickelnden System beschaffen sein sollen. Neben den Arbeitsablaeufen gehoeren in diese Phase auch erste einfache Bildschirmprototypen. Begriffe aus der Anwendungswelt werden in einem Glossar festgehalten. Ausserdem lassen sich CRC-Karten (CRC = Class Responsibilities Collaborators) einsetzen, um Klassen, Verantwortlichkeiten und Beteiligte aufzuspueren und zu definieren.

Beim Uebergang von der Analyse ins Design werden Begriffe und Sachverhalte in ein abstraktes Modell ueberfuehrt. Dabei besteht das Klassenmodell aus Basiskomponenten (Klassen, Objekte, Attribute, Operationen, Zusicherungen), statischen Komponenten, etwa Assoziationen, Aggregationen, Generalisierungen und Spezialisierungen, Rollen und Subsysteme sowie dynamische Modellkomponenten wie Nachrichten, Zustaende, Ereignis- und Interaktionsdiagramme oder Zeitanforderungen. Ausserdem wird gegebenenfalls auf fach- oder branchenspezifische Frameworks zurueckgegriffen.

Der Einsatz von Frameworks kann bereits viele grundsaetzliche Probleme loesen. So muessen in jedem System Dialoge zur Identifikation der Fachobjekte geschaffen werden. Die Anwendungsarchitektur gliedert sich in den meisten Faellen in Praesentations-, Datenbank- und Steuerungsschicht sowie Fachklassen. Andere Loesungsansaetze fuer typische Probleme werden dagegen als sogenannte Entwurfsmuster beschrieben und gehen kochrezeptartig in das Design ein.

Ueblicherweise entsteht das Design gleichzeitig auf mehreren Ebenen: beim Grundkonzept des Klassenmodells, bei der Entwicklung abgrenzbarer Komponenten und der einzelner Klassen. Auch die Umsetzung des erarbeiteten Designs in ein lauffaehiges System vollzieht sich auf mehreren Ebenen.

Die Klassen muessen gemaess den Ergebnissen aus der Designphase codiert und auf ihre Uebereinstimmung mit den Spezifikationen geprueft werden. Ausserdem sind sie in Teilsysteme und Komponenten einzubetten und auf ihr Zusammenspiel hin zu testen. Je nach Groesse des Systems und dem Entwicklungsstand bilden die einzelnen Komponenten oder Teilsysteme dann ein Zwischen- oder Endprodukt.

Schliesslich wird das (Zwischen-) Produkt zum operativen Einsatz freigegeben. Die Erfahrungen bei ausgewaehlten Anwendern sollten in Reviews erfasst und ausgewertet werden, damit sie in den naechsten Zyklus einfliessen koennen.