Schlamperei in den Fruehphasen gefaehrdet den Projekterfolg Investitionen in Analyse und Design sind immer gut angelegt

20.01.1995

Gegner der Objektorientierung fuehren gern ins Feld, dass viele OO- Projekte unverhaeltnismaessig viel Zeit in Anspruch nehmen. Kordula Manegold und Manfred Muehlan* fuehren diesen Mehraufwand darauf zurueck, dass fuer Analyse und Design zuwenig Zeit eingeraeumt wird. Eine sinnvolle Tool-Unterstuetzung kann verhindern, dass Designmaengel zu unkontrollierbaren Implementierungsfehlern fuehren.

Gegenueber anderen Vorgehensweisen bietet der objektorientierte Ansatz eine Reihe von Vorteilen. Dazu gehoeren strukturierte, auf das Problem ausgerichtete Analyse- und Designdokumente sowie modularisierter, wart- und testbarer Code. Die in einem sorgfaeltig durchgefuehrten Software-Entwicklungsprozess identifizierten Objekte und Klassen lassen sich separat beschreiben sowie mit einem hohen Parallelisierungsgrad implementieren und testen. Zusaetzlich sind Objekte direkt oder in Verbindung mit entsprechenden Vererbungsmechanismen vielfach auch in weiteren Projekten verwendbar.

Diese Vorteile werden aber heute nicht vollstaendig genutzt, da viele Unternehmen in ihren Projekten noch den alten Verhaltensmustern folgen, die dadurch gepraegt sind, dass den Entwicklungen im wesentlichen sequentielle Vorgehensmodelle (beispielsweise das Wasserfallmodell nach Barry Boehm) zugrunde liegen.

Zwar wurden nach Einfuehrung des objektorientierten Paradigmas die einzelnen Phasen verkuerzt und die Anzahl der Entwicklungszyklen erhoeht, doch sind die Anteile, die die einzelnen Phasen am Gesamtaufwand ausmachen, nach wie vor von Erfahrungen aus Altprojekten gepraegt. In der konventionellen Software-Entwicklung findet sich meist eine nahezu gleiche Gewichtung fuer jede Phase. Der Arbeitsaufwand verteilt sich also zu je 20 Prozent auf Analyse, Design, Implementierung, Integration und Test beziehungsweise Debugging. In der objektorientierten Software- Entwicklung hingegen liegt die Betonung auf einem verbesserten Verstaendnis und einer schaerferen Abgrenzung der Problembereiche sowie auf einer praezisen, durch die reale Welt gepraegten Beschreibung des Systems.

Designergebnisse, die auf diese Weise zustande kommen, sind nicht nur besser strukturiert und genauer definiert, sondern werden oft - zumindest in Teilen - zusaetzlich durch Prototypen abgesichert. Bei einem so konstruierten System verhalten sich die fuer den jeweiligen Entwicklungszyklus investierten Aufwaende etwa im Verhaeltnis 30 (Analyse) zu 30 (Design) zu 20 (Implementierung) zu 10 (Integration) zu 10 (Test/ Debugging) (vgl. die Abbildung).

Was bedeutet die Betonung von Analyse und Design fuer die Projekte? Aus projektplanerischer Sicht waechst zunaechst einmal die fuer diese beiden Phasen benoetigte Zeit. In Verbindung mit den aus der konventionellen Entwicklung abgeleiteten Erfahrungen fuehrt diese Tatsache dazu, dass die Dauer der Analyse- und Designphase meist von vornherein unterschaetzt wird.

Folglich erklaert die Entwicklungsmannschaft die Arbeiten am Entwurf fuer beendet, obwohl das Design eigentlich noch nicht abgeschlossen ist.

Hier liegt der Grund fuer viele Probleme, die in der Implementierungsphase auftreten und dort zu unerwarteten, im Detail unvorhersehbaren Verzoegerungen fuehren. Letztlich wird dadurch die Gesamtentwicklungszeit im Vergleich zu konventionellen Methoden verlaengert.

Ein wesentlicher Grund dafuer, dass die Designphase zugunsten der Implementierung verkuerzt wird, laesst sich auf die Tatsache zurueckfuehren, dass es keine kostenguenstige Moeglichkeit gibt, den Entwurf teilweise oder auch im ganzen automatisch zum Ablauf zu bringen. Das Entwicklungsteam ist darauf angewiesen, dass die Funktionsweise in Reviews und anderen Meetings ueberprueft wird.

Getestet werden muss beispielsweise der Abgleich zwischen den Aufrufparametern und dem tatsaechlich realisierten Interface der aufzurufenden Methode. Aber eine solche Schnittstellen-Ueberpruefung stellt nur einen Teilaspekt der Gesamtaufgabe dar. Wesentlich wichtiger sind:

- Konsistenz-Checks fuer die verschiedenen Modelle einer Notation;

- die Untersuchung der verwendeten Methodik;

- das Erkennen und Vorschlagen von moeglichen beziehungsweise sinnvollen Generalisierungshierarchien;

- das Auffinden von Entwurfsmustern (Design-Patterns), die den Klassenstrukturen zugrunde liegen, sowie

- die Berechnung von Metriken zur qualitativen Einschaetzung des Entwurfs und zur Risikoabschaetzung.

Leider werden diese Aspekte in der Projektarbeit weitgehend uebersehen. Haeufig ist sich das Team nicht ganz im klaren darueber, welche Methode denn nun tatsaechlich verwendet wird. In der Praxis findet sich haeufig eine Mischform aus mehreren objektorientierten Vorgehensweisen, wodurch gerade die Ueberpruefung der Konsistenz erschwert wird, weil die dafuer benoetigten Regeln auf muendlicher Ueberlieferung beruhen.

Abhilfe schaffen hier eine gute Schulung in einer oder mehreren objektorientierten Methoden sowie eine Gegenueberstellung von unterschiedlichen Vorgehensweisen, um herauszufinden, welche sich fuer das anstehende Projekt am besten eignet. Ausserdem sollte bereits im Vorfeld geklaert werden, ob die betreffende Methode erweitert werden soll und wie sie sich am besten einfuehren laesst.

Immer mehr Unternehmen gehen dazu ueber, ihr Vorgehen bei der Software-Entwicklung zu beschreiben und zu dokumentieren - nicht zuletzt deshalb, weil eine Qualitaetssicherung nach ISO 9000 genau das fordert. Und gerade hier spielt eine automatisierbare Ueberpruefung des Designs eine wesentliche Rolle. Diese Aufgabe sollten CASE- und Qualitaetssicherungswerkzeuge uebernehmen, deren Leistungsumfang auf objektorientierte Technologien zugeschnitten ist.

Allerdings haftet diesen Werkzeugen der Ruf an, lediglich bessere Zeichen-Tools zu sein. Tatsaechlich gehoert jedoch ein Object Repository mittlerweile zum Standardumfang. Dort lassen sich die Ergebnisse aus Analyse und Design strukturiert hinterlegen. Ob dafuer eine relationale oder eine objektorientierte Datenbank genutzt wird, haengt vom Hersteller und von der Philosophie des Werkzeugs ab.

Die Struktur des Repositorys richtet sich nach der Notation beziehungsweise der Methodik, die von dem jeweiligen Werkzeug unterstuetzt wird. Die meisten Tools beherrschen derzeit nur eine Methode, und zwar zeichnet sich hier ein Trend zur Notation nach James Rumbaugh ab.

Neben dieser Moeglichkeit, Analyse- und Designergebnisse grafisch und textlich zu erfassen, unterstuetzen solche Werkzeuge in den meisten Faellen auch eine Codegenerierung. Doch nur wenige Tools bieten dem Anwender bislang die Moeglichkeit, flexibel und automatisierbar auf Daten zuzugreifen. Um die geforderten Ueberpruefungsmechnismen zu implementieren, ist diese Zugriffsmoeglichkeit aber unabdingbar. Darueber hinaus wird sie benoetigt, um den Funktionsumfang des Werkzeugs auf die jeweiligen Projektbeduerfnisse zuzuschneiden.

Realisieren laesst sich der Datenzugriff durch eine integrierte Script-Language, deren Aufgabe es ist, Abfragen an das Repository zu adressieren. Sie koennte dem Anwender zudem vielfaeltige Konfigurationsmechnismen zur Verfuegung stellen und es ihm darueber hinaus ermoeglichen, gaengige Bedienszenarien automatisch zum Ablauf zu bringen. Die Konsistenz- und Designueberpruefung ist innerhalb einer solchen Sprache implementierbar.

Durch geeignete Werkzeuge laesst sich also die Effizienz der Projektarbeit erheblich steigern. Die Arbeitsweisen der Projektmannschaft werden vereinheitlicht, zeitaufwendige Reviews lassen sich groesstenteils an das System delegieren. Dadurch steigt letztlich die Qualitaet, und der Aufwand verringert sich.

* Kordula Manegold ist Technische Produktverantwortliche fuer Meta- CASE-Tools bei der Computec Software GmbH, Karlsruhe, als deren Geschaeftsfueher Manfred Muehlan fungiert.