Bei den meisten Softwareherstellern und vielen großen Anwendern ist Objektorientierung (OO) mittlerweile über das Experimentierstadium hinaus für zahlreiche Einsatzbereiche wie zum Beispiel GUI (grafische Benutzeroberflächen) bietet der Markt heute vornehmlich objektorientierte Tools und Bibliotheken.
In den letzten Jahren war das Hauptaugenmerk der objektorientierten Fachwelt auf immer neue Programmiersprachen, Methoden und Tools gerichtet. Während also die Werkzeuge zur Entwicklung immer weiter perfektioniert wurden, gibt es in vielen Unternehmen heute immer noch ein Defizit an Projekt-Management- Techniken, die den speziellen Problemen objektorientierter Projekte angepaßt sind.
Um die Notwendigkeit für solche neuen Techniken zu verstehen, muß man sich die Besonderheiten von OO-Projekten klarmachen, denn der Aufwand verteilt sich anders.
Bei OO andere Zwischenergebnisse
Der konsequente Einsatz von Objektorientierung führt zu einem stärkeren Gewicht der Analyse ferner werden Design- und Realisierungsphase reduziert, vor allem durch eine gezielte Wiederverwendung.
Dem muß bei der Projektplanung und vor allem bei der Ressourcenplanung Rechnung getragen werden.
In klassisch strukturierten Projekten gibt es eine Reihe von Teilaufgaben, die als Meilensteine geplant und kontrolliert werden müssen, zum Beispiel ein abgestimmtes Klassenmodell als Basis für die gesamte weitere Entwicklung. Objektorientierte Projekte liefern Klassenspezifikationen und Klassenimplementierungen als Ergebnisse. Durch die Kapselung muß für die verschiedenen Klassen eine öffentliche Schnittstelle definiert werden, die Festlegung der internen Struktur kann dann jeweils weitgehend unabhängig vorgenommen werden (vgl. Abbildung).
Bei der Projektplanung und -abwicklung müssen daher Meilensteine hauptsächlich für die einzelnen Klassen festgelegt werden. Diese Meilensteinplanung für Klassen ist bei objektorientierten Projekten mindestens genauso wichtig wie die Planung des Projekts als Ganzes.
Eines der Hauptanliegen der Objektorientierung ist die Wiederverwendung bestehender Entwicklungen. Immer wieder wird von Unternehmen bemängelt, daß genau dieser Vorteil der Objektorientierung bisher nicht erreicht wurde.
Bei einer genaueren Prüfung ist dann oftmals festzustellen, daß die Wiederverwendung nicht ausdrücklich als Projektziel definiert wurde. Solange Projektleiter hauptsächlich daran gemessen werden, wie gut, schnell und preiswert sie ihre Projekte abwickeln, gibt es nur eine geringe Motivation, einzelne Projekte im Gesamtzusammenhang eines Unternehmens zu sehen. Wiederverwendung läßt sich nur erreichen, wenn jedes Projekt noch stärker als bisher als Teil eines gesamten IT-Konzepts betrachtet wird - vorausgesetzt natürlich, es gibt ein solches Konzept im Unternehmen.
Aufgabe der Projektleitung ist es also nicht nur, Projekte korrekt sowie termin- und budgetgerecht abzuliefern, sondern auch so, daß möglichst viele Teile davon in anderen Projekten wiederverwendet werden können. Das muß stärker als bisher ins Zentrum des Interesses gerückt werden. Solche wiederverwendbaren Ergebnisse müssen unter Umständen aufwendiger konzipiert werden als die, die in nur einem Projekt verwendet werden sollen. Daher muß bei der Betrachtung der Wirtschaftlichkeit ein Projekt immer im Gesamtzusammenhang des Unternehmens gesehen werden.
Objektorientierte Methoden gehen in aller Regel von getrennten Phasen für Analyse und Design aus, die Trennung zwischen den Projektphasen ist jedoch nicht so strikt wie bei klassischen, strukturierten Techniken. So unterscheiden sich die Phasen weniger durch die verwendeten Techniken als vielmehr durch das Maß der Detaillierung der Klassendefinition. Daher ist es in objektorientierten Projekten nötig, den Ablauf der Entwicklung in Phasen zu unterteilen, um den Gesamtablauf zu strukturieren und damit planbar zu machen. Diese Aufgabe ist beim Management klassischer Projekte nicht in diesem Ausmaß nötig, da bei strukturierten Techniken ohnehin ein systemimmanenter Methodenbruch zwischen Analyse und Design vorliegt.
Eine mögliche Strukturierung objektorientierter Projekte über den Detaillierungsgrad könnte folgendermaßen aussehen:
- Grobdefinition von Begriffen, Klassen und Beziehungen
- Festlegung der öffentlichen Schnittstelle jeder Klasse
- Entwurf der einzelnen internen Klassenstrukturen sowie
- Implementierung der einzelnen Klassen.
Die dargestellten Besonderheiten machen deutlich, daß für objektorientierte Projekte teilweise andere Regeln gelten als bei klassischer Strukturierung. Daraus resultieren spezielle Anforderungen an die Techniken und Tools zur Entwicklung. So ist es weitgehend unstrittig, daß objektorientierte Software am besten mit OO-Sprachen implementiert wird.
Im Bereich des Projekt-Managements hat sich dieses Bewußtsein jedoch noch nicht in vergleichbarem Ausmaß durchgesetzt. Es sind eine Reihe von Änderungen im Projekt-Management nötig, um nicht die potentiellen Vorteile der Objektorientierung durch eine unzureichende Projektabwicklung zunichte zu machen. Dies beginnt mit der Einordnung einzelner Projekte in das gesamte IT-Umfeld eines Unternehmens.
Bei der Planung und Durchführung eines Projekts muß bewußt gemacht werden, daß eine einzelne Aufgabenstellung meist nur ein Teil zur Erreichung des gesamten Unternehmensziels ist.
Dadurch profitiert jedes Projekt von den Ergebnissen anderer Entwicklungen, sollte aber auch verwertbare Ergebnisse für andere liefern.
Diese Veränderung der Zielsetzung sollte durch ein entsprechendes Anreizsystem unterstützt werden, in dem Wiederverwendbarkeit gemessen und belohnt wird. Auf diese Weise wird die Motivation gefördert, nicht nur den kurzfristigen Erfolg eines einzelnen Projekts anzustreben, sondern Klassen zu entwickeln, die für möglichst große Bereiche und viele Abteilungen des Unternehmens Gültigkeit haben.
OO-Entwicklung ist eine schrittweise Verfeinerung von Klassen. Dies beginnt mit der Analyse und führt über eine Entwurfsphase zur Implementierung einer Klasse. Mit zunehmender Komplexität von Systemen ist es dabei zweckmäßig, zunächst die wesentlichen Eigenschaften von Klassen zu modellieren und diese in weiteren Phasen auszubauen. Damit kann objektorientierte Entwicklung sinnvollerweise nur mit einem Vorgehen gemäß dem Spiralmodell erfolgen. Dabei werden in einem Durchlauf alle Phasen von der Analyse bis zur Nutzung durchlaufen. Auf den dabei gewonnenen Erkenntnissen läßt sich jeweils aufbauen, um im nächsten Durchlauf eine weitere Verfeinerung von Klassen oder neue Anforderungen der Anwender zu realisieren.
Die Organisationsstrukturen zur Projektabwicklung müssen ebenfalls an die speziellen Anforderungen objektorientierter Entwicklung angepaßt werden. Klassische Projekte lassen sich so gliedern, daß jede Organisationseinheit abgegrenzte Aufgaben innerhalb des Gesamtprojekts hat. Aufgabe der Projektleitung ist es, die Aufgabenerfüllung dieser Teileinheiten zu kontrollieren und das Zusammenwirken der Teilergebnisse sicherzustellen. Bei objektorientierten Projekten sind die Klassen die zentralen Teileinheiten des Gesamtsystems. Entsprechend sollten objektorientierte Projektteams in Teileinheiten zur Entwicklung jeweils zusammengehöriger Klassen gegliedert sein. Aufgabe der Projektleitung ist:
- die Planung einer organisatorischen Gliederung in Klassen
- die Planung der Schnittstellen-Definition der Klassen und
- die Überwachung der Einhaltung dieser Schnittstellen.
Damit erhalten die Teileinheiten eines Projekts mehr Freiheiten bei der Aufgabenerfüllung, und die Menge der Koordinierungsaufgaben für das Management wird geringer durch die Definition der Klassen-Schnittstellen und die Kapselung.
In klassischen Projekten werden Phasen durchlaufen, die jeweils für das Gesamtprojekt oder zumindest für wesentliche Teilprojekte vor dem Beginn der nächsten Phase abgeschlossen sein müssen. Die Kapselung ermöglicht es, diese Phasen für die einzelnen Klassen zu entkoppeln. Dadurch lassen sich einzelne Anwendungsklassen als eigene Teilprojekte ansehen, die nicht unbedingt mit allen anderen synchronisiert werden müssen. Dies ermöglicht mehr Flexibilität bei der Termin- und Ressourcenplanung.
Als Ergebnis läßt sich festhalten, daß sich OO-Projekte in einigen wesentlichen Eigenschaften von klassischen unterscheiden. Eine Konsequenz daraus ist, daß die Organisation und Abwicklung einzelner Projekte andere Techniken und Vorgehensweisen erfordert. Für den Erfolg der Objektorientierung insgesamt ist es jedoch viel wichtiger, daß es eine einheitliche IT-Strategie im Unternehmen gibt, die unternehmensweite Ziele festlegt. Nur so können Klassen definiert werden, die über ein Projekt und eine Abteilung hinaus Gültigkeit haben.
Die wirklich gravierenden und langfristig wirtschaftlichen Vorteile der Objektorientierung lassen sich erst dann erreichen, wenn es gelingt, zentrale Anwendungsbegriffe des Unternehmens nur einmal zu definieren. Damit ist eine bessere Integration verschiedener Anwendungen zu erreichen. Voraussetzung dafür sind allerdings ein unternehmensweites Klassenmodell, das für alle Projekte verbindlich ist, und Organisationseinheiten, die für die Pflege eines solchen zentralen Modells verantwortlich sind.
Erweiterte Ziele
Die Objektorientierung (OO) setzt sich in weiten Bereichen der Software-Entwicklung durch. Waren die 80er Jahre durch strukturierte Techniken gekennzeichnet, werden die 90er Jahre wohl weitgehend durch die objektorientierten Techniken geprägt sein. Objektorientierung stellt dabei eine konsequente Weiterentwicklung bestehender Prinzipien dar:
- Strukturierte Techniken stellen Regeln zur getrennten Strukturierung von Daten und Funktionen auf.
- Objektorientierte Techniken erweitern diese Ziele der Strukturierung durch ein Zusammenfassen der Daten mit den Funktionen zu ihrer Bearbeitung.
Strukturierte Techniken und Objektorientierung widersprechen sich also nicht, vielmehr ist die OO eine konsequente Weiterentwicklung der klassischen Strukturierung durch Hinzufügen einiger zentraler Techniken wie Kapselung und Vererbung.
Angeklickt
Voraussetzung für den Einsatz objektorientierter Methoden ist eine einheitliche IT-Strategie, die unternehmensweite Ziele festlegt. Nur dann können Klassen definiert werden, die über ein Projekt und eine Abteilung hinaus Gültigkeit haben.
Trifft dies zu, so sollten auch alle Vorteile des objektorientierten Projekt-Managements, wie geringerer Implementierungs- und Wartungsaufwand sowie die Wiederverwendbarkeit, ausgeschöpft werden.
*Werner Achert ist Projektleiter bei der Integrata, München. Er befaßt sich schwerpunktmäßig mit dem Thema Objektorientierung und ist Autor des Buches "Objektorientierte Software-Entwicklung" aus dem COMPUTERWOCHE-Verlag.