OSZ Handel I
Informatik

Software Engineering
Projektmanagement

S. Spolwig

[Home | Gymn. Oberstufe | Informatik | Unterrichtsmaterialien]

Was Profis darüber denken - Vortrag zur europäischen Visual FoxPro Entwicklerkonferenz 1997 - gefunden im Internet.
Mit freundlicher Genehmigung von A. Borrmann und wizards-builders.com

 

"Warum Objektorientierung sowieso nicht funktioniert"

von Alf Borrmann

 

Einführung

Besonderheiten von OO-Projekten

Grundlagen des Projektmanagemants

Risikogruppen

Konzeptionelle Risiken

Politische Risiken

Managementfehler

Analyse- & Designfallen

Risiken der Entwicklungsumgebung

QS-Fallen

Pobleme bei der Wiederverwendung

Wie man es trotzdem schafft

Bibliographie

 

Einführung

Objektorientierung (OO) ist eine wundervolle, elegante Technologie, sie funktioniert und sie bietet hervorragende Möglichkeiten, Applikationen zu bauen und Aufgabenstellungen vielerlei Art zu lösen.

Warum also dann der Titel "Warum OO sowieso nicht funktioniert"?

Der Einstieg in die Objektorientierung ist eine große Umstellung in allen Belangen eines Projektes. Dementsprechend groß sind die Risiken, die damit verbunden sind. Und innerhalb einer Firma oder in der Zusammenarbeit mit Kunden gibt es immer Leute, die, falls ein Projekt schief läuft, es (natürlich immer nachher) besser wissen und dem Promoter dann sagen: "das waren Sie mit Ihrer Objekt-Manie".

Denn natürlich können OO-Projekte schief gehen. Der Einsatz von objektorientierter Technologie ist keine Gewähr dafür, daß eine Software den Ansprüchen genügt. Ganz im Gegenteil: dadurch, daß es eine Menge neue Verfahren, Regeln, Notwendigkeiten und Begriffe gibt, gibt es natürlich auch neue Risiken. Und wenn Sie viel Arbeit darein gesteckt haben, ihr Projekt OO-gerecht zu organisieren, in bessere Ausbildung investiert, neue Tools gekauft haben etc., ist damit schon eine Menge Geld ausgegeben worden. Das Scheitern eines OO-Projektes wird damit erheblich teurer und schmerzhafter, als das Scheitern eines konventionellen Projektes.

In diesem Beitrag soll nun aufgelistet werden, welche Dinge es in einem Softwareprojekt - und speziell in einem OO-Projekt - zu beachten gibt.

Es geht dabei nicht um die Vermittlung endgültiger Wahrheiten, ja es werden nicht mal allzuviele Antworten gegeben. Denn viele Entscheidungen in einem Projekt können so oder so ausfallen. Es gibt zwar in der Literatur eine (bzw. mehrere) Idealvorstellung davon, wie ein OO-Projekt optimal läuft. In der Praxis lassen sich diese idealen Modelle aber an vielen Stellen nicht durchhalten.

Als Beispiel sei hier ein relationales Datenmodell genannt:

·         vollständig normalisiert muß es sein, sagt die Theorie, also mindestens 3. Normalform

·         es darf keine Redundanzen geben

·         jede Entität muß über einen eindeutigen Schlüssel verfügen.

Trotzdem gib es in den meisten Entity-Relationship-Modellen Abweichungen davon, nämlich Daten, die mehrfach gespeichert werden. Wozu dies? Weil es Performance bringt! Damit wird zwar gegen die Theorie verstoßen, aber dies ist eine aktive Entscheidung:

·         es ist bekannt, daß es mehrere Alternativen gibt
statt der mehrfachen Speicherung eines Wertes kommt auch eine Entity-Relationship-Modell-konforme Speicherung in Frage

·         es ist bekannt, daß eine Entscheidung gefällt werden muß
die beiden genannten Möglichkeiten schließen sich aus

·         es ist bekannt, daß normalerweise keine Feldredundanzen erlaubt sind
die Regeln der ERM verbieten Redundanzen

·         die Risiken dieser Entscheidung sind bekannt
für die Synchronisation der Speicherplätze wird Code notwendig

·         die Redundanz wird trotzdem eingebaut, um die Abfragegeschwindigkeit zu erhöhen
die Priorität wird damit klar gesetzt

·         die Entscheidung geht in die Dokumentation, z.B. dem xCase-Modell ein:
"das Feld Summe in der Rechnungstabelle errechnet sich aus den Positionen der Rechnung, ist also redundant; wird zur ständig schnell abrufbaren Umsatzstatistik dort benötigt".

Das Feld ist also nicht zufällig in dem Datenmodell, sondern hat einen klaren Zweck. Und wenn später der Einwand auftaucht: "da ist etwas redundant, eigentlich geht die Rechnungssumme doch aus den Einzelpositionen hervor", ist der Zweck dieser Redundanz und der Grund, gegen diese Regel verstoßen zu haben, aus der Dokumentation klar ersichtlich.

Hier sind die wichtigsten Kriterien, die beim Handhaben von solchen Entscheidungen beachtet werden müssen:

·         es gibt mehrere Alternativen, also wird eine Entscheidung benötigt

·         es gibt Gründe, die zu der Entscheidung geführt haben

·         die Entscheidung (und insbesondere begangene Regelverletzungen) wird dokumentiert

Analog zu diesem Beispiel gibt es Notwendigkeiten zu Entscheidungen bei der Abwicklung von OO-Projekten. In diesem Beitrag werden einige der zusätzlichen Risiken aufgelistet, die in OO-Projekten vorhanden sind. Es werden Hinweise gegeben, wie man solche Risiken erkennt und nach Möglichkeit Hinweise gegeben, wie Fehler bei Entscheidungen vermieden werden können bzw. wie man die Folgen einer Entscheidung zwischen zwei gleich großen Übeln verringert.

Was in diesem Beitrag genannt wird, basiert auf Einsichten, die Softwareentwickler durch schmerzhafte Erfahrungen in der Praxis erworben haben.

Das, was in einem Fall ein Fehler ist, kann sich in einem anderen Fall als goldrichtig herausstellen. Nutzen sie die Hinweise dazu, regelmäßige Projekt-"walk-througs" zu machen. Wenn Ihnen etwas verdächtig erscheint, stellen Sie es auf den Prüfstand. Wenn es sich als notwendig und sachdienlich erweist, gegen eine Regel zu verstoßen, ist das OK. Aber: dokumentieren Sie Ihre Entscheidungen.

Besonderheiten von OO-Projekten

"Ein Projekt ist die Kollision zwischen Wünschen, festgelegtem Termin und vorhandenem Geld."

Notwendigkeit zur Planung

In OO-Projekten muß ein besonderes Augenmerk auf Planung und Dokumentation gelegt werden. Zusätzlich zu konventionellen Projekten sind in OO-Projekten Planungen für die Analyse und Designphase (A&D), den Aufbau eines Klassenmodells und die Wiederverwendung notwendig. Daraus ergeben sich natürlich auch eine Menge Risiken, denn man muß ja in die Zukunft schauen, um ein Projekt planen zu können.

Vorschußlorbeeren

Von der objektorientierten Technologie (OOT) verspricht man sich oft, daß alles viel einfacher wird, die Komplexität wird beherrschbar, durch Wiederverwendung wird die Softwareerstellung billiger und schneller, man muß nicht mehr soviel testen …

Aber auch mit OOT kann man Projekte ganz toll versenken. In der Tat sind OO-Projekte, die versenkt werden, sogar viel teurer versenkt, als wenn man es 'normal' gemacht hätte, jedenfalls in der Anfangsphase, in der hohe Investitionen in Know-how und Training und in das Sammeln von Erfahrung nötig sind.
Besonders gefährlich ist es, einen als OO 'getarnten' prozeduralen Ansatzes zu implementieren. Dies passiert gerade bei VFP, wie bei jeder anderen hybriden Sprache sehr schnell.

Paradigmawechsel

Verbunden mit dem Wechsel von der prozeduralen zur objektorientierten Programmierung ist die Einführung eines komplett neuen Modells für die Programmierung. Dieses Modell und das alte, prozedurale schließen sich gegenseitig aus. Ein solcher Übergang von einem alten zu einem neuen Modell wird Paradigmawechsel genannt. Paradigmawechsel rufen bei den betroffenen Personen typische Reaktionen hervor. Diese Reaktionsmuster sind in der Psychologie erforscht worden und lassen sich einteilen in:

·         Emotionale Ablehnung: trotz Widersprüchen wird an den alten Überzeugungen noch festgehalten.

·         Unreflektierte Euphorie: die Defizite des alten Modells wurden erkannt, das neue aber noch nicht kritisch hinterfragt und damit letztlich nicht verstanden

·         Déjà-vu-Erlebnis: das neue Paradigma erscheint so selbstverständlich, daß man sich wundert, warum es erst jetzt da ist, oder es wird sogar der Neuigkeitswert bezweifelt.

Alle diese Reaktionen bergen die Möglichkeit für neue Risiken. Sie können durch Fehleinschätzungen ein Projekt behindern oder gar scheitern lassen.

Grundlagen des Projektmanagements

Alle Möglichkeiten, die Sie in normalen Projekten einsetzen, sind natürlich in OO-Projekten weiterhin angebracht und sinnvoll.

Planung

Planung heißt zu allererst, daß man einen Plan erstellt, daß man sich im Vorhinein Gedanken macht, wie man ein entsprechendes Ziel erreichen will. Daß man überlegt, welche Ressourcen man benötigt und wann sie benötigt werden.

Planung heißt, die Ziele, die man erreichen will, festzuschreiben.

Planung ist keine Tätigkeit, die einmal getan wird und die damit erledigt ist. Planung ist ein ständig laufender Prozeß. Planung bedeutet auch, sich abzeichnende Entwicklungen an dem zu messen, was vorgesehen war und den Vergleich dazu zu nutzen, die weitere Planung zu verbessern bzw. zu adjustieren.

Trotz guter Planung kommt es aber in Softwareprojekten oft zu Problemen. Wie diese Probleme entstehen, wie man sie erkennt und wie man gegensteuert, wird weiter unten an verschiedenen Beispielen erläutert.

Feststellen von Abweichungen

Bei der Erreichung eines Teilziels oder bei der Fertigstellung eines Teilprojektes wird der Plan meist nicht eingehalten. Nach (oder während) der Erreichung von geplanten Teilzielen gilt es, Abweichungen festzustellen. Dies kann z.B. durch regelmäßige Projektbesprechungen oder Reviews geschehen.

Prüfung der Kollisionsmöglichkeiten

Das Prüfen auf mögliche Kollisionen heißt insbesondere, eine Betrachtung der geplanten und der erreichten Ziele und der bei der Erreichung aufgetretenen Schwierigkeiten. Jedes der Zwischenziele hatte ja wiederum ein Zeitziel, ein Kostenziel und eine Featureliste, die es gilt, miteinander in Einklang zu bringen. Die Kollisionen, die bei der Erreichung von Teilzielen aufgetreten sind, lassen Rückschlüsse zu auf die möglichen Kollisionen bei den Zielen, die man noch vor sich hat.

Erarbeiten von Gegenmaßnahmen

Die Ergreifung von Gegenmaßnahmen beinhaltet natürlich auch, daß man die Möglichkeit zu deren Umsetzung bzw. Durchsetzung hat und den richtigen Zeitpunkt findet, sie anzusprechen.

Stellen Sie sich die Situation vor: Sie sind Programmierer in einem Projekt, das völlig aus dem Zeitplan geraten ist. Der Projektleiter hat das gemerkt, hat einen Rundgang gemacht, um mit den Programmierern das weitere Vorgehen zu besprechen. Sie sind dabei besonders unangenehm aufgefallen, weil Sie immer als letzter an Ihrem Arbeitsplatz sind und Ihr Schreibtisch ein Chaos aus leeren Pizzaschachteln ist. Daß Sie der produktivste Programmierer im Team sind und immer als letzter aus dem Büro gehen, wird in dem Zusammenhang natürlich gerne übersehen. Sie haben sich sogar noch Gedanken zu dem Projekt gemacht und ein paar Ideen, die das Management wieder auf Kurs bringen könnten. Trotzdem: dies ist keine Situation, in der Ihre Gedanken auf verstärkte Gegenliebe stoßen. Im Gegenteil: der Projektleiter wird möglicherweise den Verdacht haben, Daß Sie seine Kritik nur kontern zu wollen.

Anders herum: Sie sind Projektleiter. Einer Ihrer Chefprogrammierer kommt in Ihr Büro und meldet freudestrahlend, daß er eine wichtige Komponente sehr elegant und sauber fertiggestellt hat. Sie sollten das nicht als Selbstverständlichkeit nehmen und dann sofort darauf zu sprechen kommen, daß er den chaotischsten Arbeitsplatz in der ganzen Firma hat. Das demotiviert und macht Ihr Gegenüber nicht empfänglich für das, was Sie sagen wollen.

Vorbereitung und Dokumentation von Entscheidungen

Bei der Vorbereitung von Entscheidungen kommt es darauf an, die Gründe, die für jede Alternative sprechen, aufzulisten und als Dokumentation später zur Verfügung zu haben. Vielleicht muß die Entscheidung später noch einmal überdacht werden und vielleicht sind dann verschiedene Gründe weggefallen. In dieser Situation verkürzt eine Liste der Gründe die Zeit, die notwendig ist und verbessert die Entscheidung, weil einmal gefundene Kriterien nicht vergessen werden.

Risikogruppen

Die Bereiche, die in OO-Projekte spezifische Risiken bergen, lassen sich in mehrere Gruppen einteilen. Im großen und ganzen kann man die spezifischen Risiken der OO auf 9 Bereiche verteilen, die sich allerdings teilweise überschneiden. Einige dieser Risikobereiche sind nicht exklusiv auf OO-Projekte beschränkt, sondern auch konventionelle Projekte sind in der einen oder anderen Form damit behaftet.

Man kann bewußt das eine oder andere Risiko eingehen, weil man ein spezielles Ziel damit erreichen will. Wenn man jedoch aus Unwissenheit oder Unachtsamkeit gegen eine Regel verstößt oder ein Risiko eingeht oder sich keine Gedanken über die Folgen macht, kann man damit den Projekterfolg gefährden.

In einem OO-Projekt gibt es eine Menge Möglichkeiten, in Fallen zu tappen. Diese im Detail zu besprechen, würde den Rahmen diese Beitrags sprengen. Es geht hier nur darum, die verschiedenen Kategorien von Gefahren vorzustellen und andere Beispiele zu zeigen. Hinweise zu weiterführender Literatur findet sich in der Bibliographie.

Zu den Beispielen wird nach Möglichkeit aufgezeigt, woran Sie sie erkennen, was die Auswirkungen sein können, wenn eine Entscheidung nicht richtig getroffen wurde, wie Sie eine solche Klippe umschiffen können und was Sie zur Prävention tun können.

Die 9 Kategorien von Risiken sind:

·         Konzeptionelle Risiken

·         Politische Risiken

·         Managementfehler

·         Analyse- & Designfallen

·         Risiken der Entwicklungsumgebung

·         Implementationsfehler

·         Risiken in Klassen und Objekten

·         QS-Fallen

·         Probleme bei der Wiederverwendung

Konzeptionelle Risiken

Konzeptionelle Entscheidungen sind in einem Projekt die mit den am weitesten reichenden Folgen, da sie die Grundlage aller weiteren Entscheidungen stellen. Fehlgriffe bei konzeptionellen Entscheidungen sind obendrein am schwierigsten zu entdecken, da sie normalerweise vor Beginn eines Projektes gefällt werden im Projektverlauf oft nicht weiter diskutiert werden.

Konzeptionelle Gefahren lassen sich auf eine oder mehrere von drei prinzipiellen Fehleinschätzungen zurückführen:

·         das Management und/oder die Anwender haben unrealistisch hohe Erwartungen und glauben den Entwicklern nicht, wenn diese erklären, wie lange es dauert, eine Funktion wirklich komplett zu entwickeln

·         der Projektleiter, der schon genug damit zu tun hat, einen realistischen Zeitplan durchzusetzen, schafft es nicht, die spezifischen Anforderungen der Objektorientierung einzuplanen

·         durch schnelle Fortschritte in der OO enthusiasmierte Entwickler unterschätzen oder negieren die Notwendigkeit, sich in OOT weiterzubilden und reklamieren, daß sie bereits "alles wissen", später im Projekt aber feststellen, daß sie keine Zeit für genaues Design und sorgfältige Implementation haben.

Diese Probleme sind nicht OO-spezifisch, wirken sich in einem OO-Projekt aber verstärkt aus.

Die Annahme, daß OO umsonst zu haben ist

Stellen Sie sich vor, Sie sind Manager eines Boxers. Sie wollen, daß er an einer Kickbox-Europameisterschaft teilnimmt. Sie geben Ihm ein paar Bücher über Kickboxen, zeigen ihm einen Film und schicken Ihn ein paar Tage in ein Trainingscamp. Wie schätzen Sie seine Chancen, bei der Meisterschaft ein?

Klingt ziemlich dumm, nicht wahr? Aber Tatsache ist, daß genau das sehr häufig mit Software-Entwicklern gemacht wird. Sie erhalten Bücher über OO, Beispielprogramme und eine Schulung. Dann wird von Ihnen erwartet, daß sie - ohne echte OO-Erfahrung - ein kritisches Projekt in Rekordzeit erledigen. Am Ende sehen die Entwickler so aus, wie der Boxer in dem Beispiel, wenn nicht schlimmer.

Anzeichen: Widerstand bei Ihren Chefs, wenn zusätzliche Mittel bereitgestellt werden sollen. Schlüsselfrage: "Ich dachte, daß wir mit OO Zeit und Geld sparen sollten, statt mehr auszugeben." Noch gefährlicher: Entwickler, die glauben, daß sie keine zusätzlichen Schulungen für den ganzen 'OO-Krempel' brauchen.

Auswirkungen: das Projekt profitiert nicht von den spezifischen OO-Vorteilen wie Wiederverwendung, bessere Abbildung der Anforderungen etc.

Erkennung: Fragen Sie sich: "Wenn ich unsere Entwickler in einen Programmier-Wettkampf mit den besten OO-Entwicklern schicken müßte, was würde ich tun, damit sie vorzubereiten?"

Beseitigung: Wirken Sie daraufhin, daß alle Beteiligten einsehen, daß bessere Vorbereitung auch bessere Ergebnisse bringt. Wenn Sie in einem Projekt stecken und bereits Zeitdruck haben, sind Ihre Möglichkeiten begrenzt. Machen Sie eine Liste der Ausbildungsmaßnahmen, die am wichtigsten sind. Wenn Sie dieses Risiko erkennen, machen Sie den Beteiligten klar, daß das Projekt möglicherweise länger dauert, als angepeilt.

Prävention: Tun Sie das, was Sie als Antwort auf den Punkt Erkennung erhalten haben. In der Regel sind Investitionen in den Bereichen

·         Mitarbeiter

·         Zeit

·         Ausbildung

·         Tools

·         Erfahrung

nötig. Der Aufwand für solche Investitionen mag schwer zu verkaufen sein, aber er bietet zweierlei Vorteile: Sie haben eine besser ausgebildete und professionellere Gruppe von Entwicklern und dieses Klima trägt dazu bei, wirklich gute Entwickler bei der Stange zu halten.

Der Einsatz von OO-Techniken aus den falschen Gründen

Es gibt eine Menge gute Gründe, Objektorientierung einzusetzen: Handhabung von Komplexität, Abstraktion, Wiederverwendbarkeit, Kapselung, Vererbung …

Leider gibt es auch eine Anzahl ziemlich schlechter Gründe, auf OOT umzusteigen. Dazu gehören z.B.:

·         Jemand (Ihre Mitarbeiter oder Ihr Chef) hat einen Artikel darüber gelesen

·         Sie sollen Ihr Entwicklerteam verkleinern

·         Ihre Software soll weniger intensiv getestet werden

·         Sie sollen dieses verdammte Projekt nun endlich zu Ende bringen

·         Ihr Chef denkt, Sie können Software damit 5 bis 10 mal schneller entwickeln

·         Sie hoffen, OO reduziert das Projektrisiko

·         Ihre bisherige Software ist zu komplex und Sie wollen das durch Einsatz von VFP beseitigen

·         Jemand hat Ihnen VFP verkauft

·         Sie wollen in Zukunft Programme entwickeln, indem Sie nur noch Komponenten zusammenstecken

Anzeichen: Sie glauben, daß Sie mit OO alle Ihre Probleme Ihres Entwicklungsprozesses lösen; Sie sind der Ansicht, daß OOT eine ausgereifte Technik ist;

Auswirkungen: Zeitverzögerungen; Vorteile werden nicht erreicht, was zu Enttäuschungen bei Ihnen und (schlimmer) bei Ihren Chefs oder Auftraggebern führt; Köpfe rollen, ggf. Ihr eigener

Erkennung: Bitten Sie die Leute, die mit Ihnen an dem Projekt arbeiten, die Gründe, die sie haben, um OOT einzusetzen, aufzuschreiben. Bitten Sie sie, die Risiken, die sie sehen, aufzulisten. Wenn einer der genannten Gründe auftaucht, haben Sie ein Problem. Wenn auf diesen Listen keine Risiken genannt werden, haben Sie noch mehr Probleme.

Beseitigung: Besprechen Sie sich mit den Entscheidungsträgern und diskutieren Sie die Listen, die Sie erhalten haben. Erklären sie (vorsichtig) die Probleme, die damit verbunden sind. Drehen Sie die Erwartungen, die an den Einsatz von OOT geknüpft werden, auf ein erfüllbares Maß zurück.

Prävention: Im großen und ganzen das gleiche, was unter Erkennung und Beseitigung steht, außer, daß man es tut, bevor ein Projekt gestartet wird.

Weitere konzeptionelle Risiken

·         Die Annahme, daß Objekttechnologie alle Probleme löst
Wenn Sie bereits in Ihren konventionellen Projekten den Überblick verloren haben, werden Sie den nicht dadurch wiedererlangen, daß Sie sich Hals über Kopf in OO stürzen.

·         Die Annahme, daß OO ausgereift ist
In der Objektorientierung gibt es viele Ansätze ein Problem zu lösen, ja sogar viele Ansätze eine Problemlösung zu formulieren. Dagegen gibt es noch nicht genügend publizierte Standardlösungen für Problemstellungen. Hieraus resultiert, daß man oft noch zusätzliche Zeit aufwenden muß, um Forschung und Entwicklung zu betreiben.

·         Schlagworte und Konzepte verwechseln
In vielen Fällen werden Diskussionen in Projekten mit einem gepflegten Halbwissen bestritten. Dies führt oft zu unbefriedigenden und nicht problemgerechten Ansätzen. Etwas, das irgend etwas mit "Objekten" zu tun hat, ist nicht a priori objektorientiert. Denken Sie nur an OLE, das z.B. keine Vererbung kennt.

·         Tools und Prinzipien verwechseln
Ein Programm, das mit VFP entwickelt wurde, ist nicht automatisch objektorientiert. Dies ist eine besondere Gefahr von hybriden Entwicklungsumgebungen wie C++, Delphi und eben auch VFP. Man kann in der Tat VFP-Programme entwickeln, ohne gut strukturierte Klassenbibliotheken entwickelt zu haben oder eine möglichst schmale Schnittstelle für die Objektkommunikation geschaffen zu haben.

·         Präsentation und Methodik verwechseln
Programme werden oft als objektorientiert bezeichnet, weil sie eine der folgenden Eigenschaften haben:

·        eine graphische Benutzeroberfläche

·        sie ermöglichen eine ereignisgesteuerte Arbeitsweise

·        sie sind in Module unterteilt

·        es gibt mehrfach verwendbare Bibliotheken

·        sie erlauben die Datenübernahme aus anderen Applikationen per OLE.

Keines dieser Attribute ist spezifisch objektorientiert.

·         Prototypen mit fertigen Applikationen verwechseln
In OO-Projekten ist es sehr schnell möglich, Prototypen zusammenzubauen, die die Basisfunktionalitäten bereitstellen. Diese werden dann richtigerweise oft benutzt, um Anwendermeinungen einzuholen. Leider verleitet dies Kunden oder Produktverkäufer dazu, die Software als zu großen Teilen fertig zu betrachten (und dann den beteiligten Projektmitarbeitern nicht zu glauben, daß noch 80% der Arbeit zu leisten sind).

Politische Risiken

Der Begriff Politik ist durch den normalen Sprachgebrauch etwas in die Nähe von Schmutz und Schmier geraten. Manchmal wird ja auch von "Politik als schmutzigem Geschäft" gesprochen. Aber wenn man den Politikbegriff auf seine Ursprünge bezieht, wird klar, daß es hier immer um die Beziehungen zwischen Personen geht. Und in modernen Softwareprojekten sind immer mehrere Personen beteiligt. Leider ist es so, daß politische Fehler zu den häufigsten Gründen gehören, die ein Projekt als gescheitert erscheinen lassen. Oft sind Projekte technisch ein Erfolg. Nur weil irgend jemand unbedingt ein Feature haben wollte, das Sie nicht bringen konnten, wird dieses Projekt von dieser Person möglicherweise sehr wirksam schlecht gemacht. Wenn Ihnen klar ist, daß Leute, die nach einem Feature fragen, dafür vielleicht politische Gründe haben, werden Sie vielleicht leichter damit umgehen können.

Viele der politischen Risiken sind in dem Buch 'Death March' von Edward Yourdon (im Anhang genannt) sehr gut beschrieben.

Den Widerstand unterschätzen

Objekte sind wundervoll. Wenigstens Denken Sie das, basierend auf der Lektüre eines Fachartikels oder auch auf Basis langjähriger Erfahrung. Für Sie ist das Hantieren mit Klassen und Objekten ganz offensichtlich und einfach zu begreifen und Sie meinen daher daß es auch für andere ganz einfach und offensichtlich ist. Wenn Sie nun anfangen, mit Elan OOT einzuführen, wundern Sie sich nicht, wenn Sie auf Widerstände stoßen.

Der Satz "Ich habe da eine wundervolle neue Technologie entdeckt" ist ein absolutes Alarmzeichen für Ihre Umgebung. Stellen Sie sich folgende Situation vor: Sie nehmen an einer Arbeitssitzung teil, um eine anstehende Aufgabe zu beraten. Die Runde ist mit vollem Ernst bei der Sache, es wird engagiert diskutiert. Die Fetzen fliegen. Plötzlich geht die Tür auf und ein verspäteter Teilnehmer kommt aufgeregt herein und ruft: "Ich habe da eine wundervolle neue Technologie entdeckt!". Die Runde fühlt sich möglicherweise veralbert, nicht ernst genommen. Warum sollte gerade dieser Typ, der nicht mal die Diskussionslage kennt, die Lösung aller Fragen wissen. Der Nachzügler nimmt die geleistete Arbeit nicht wahr oder nicht ernst …

Das gleiche gilt natürlich, wenn Sie Leiter oder Mitglied eines Entwicklerteams sind und anfangen, mit Ihre Kollegen ganz schnell davon überzeugen zu wollen, daß OOT das einzige Mittel ist, die Aufgabe zu lösen. Wenn es Widerstand gibt, OOT einzusetzen und Sie nicht darauf eingehen, sind Sie sehr schnell in einer politischen Debatte. Ihre Kollegen haben vielfältige Gründe, OO abzulehnen, sie reichen von klaren sachlichen Argumenten bis zu irrationalen Ängsten:

·         sie verstehen OOT nicht

·         sie wollen OOT nicht verstehen

·         sie haben Angst, daß sie OOT nicht verstehen werden

·         sie wissen, daß sie OOT nicht verstehen werden, denn sie lavieren sich schon seit 10 Jahren so durch, ohne überhaupt jemals etwas verstanden zu haben

·         sie glauben nicht, daß Ihre Gründe, OOT einzusetzen, gut durchdacht sind

·         sie hängen an FPW2.6 und den Techniken, die sie zur Zeit einsetzen und glauben, damit produktiver zu sein

·         sie wollen OOT einsetzen, aber sie wollen es auf ihre eigene Weise tun

·         sie wollen, daß Sie scheitern, um Ihren Job zu bekommen.

Anzeichen: Sie erhalten nur sehr zögerlich Unterstützung. Es kursieren Gerüchte, daß Sie die Firma oder die Abteilung völlig umkrempeln wollen. In Meetings werden immer wieder Ziele in Frage gestellt. Ihr Projekt wird geringer priorisiert oder mit weniger Ressourcen bedacht.

Auswirkungen: Bedeutende Verschiebungen des Projektes, Verlust von Einfluß

Erkennung: Wenn Sie die Hartnäckigkeit des Widerstandes gegen OOT überrascht, sollten Sie die Gründe dafür herausfinden. Das kann allerdings recht schwierig sein, denn je nach dem werden Ihre Kollegen Ihnen nicht ihre wahren Gründe nennen.

Beseitigung: Je nach Schwere des Widerstandes und Ihrem eigenen Status ergeben sich folgen Möglichkeiten, damit umzugehen:

·         einfach weitermachen

·         Einbeziehung derjenigen, die den Widerstand leisten, in die Überlegungen

·         Umgehen oder Entkräften der Einwände

·         das Projekt sanft stoppen und es ggf. später noch einmal versuchen.

Prävention: Erstellen Sie eine Liste aller Leute, die Einfluß auf Ihre Bemühungen nehmen können und versuchen Sie, deren Standpunkt zu erfahren. Versuchen Sie, Anreize zu schaffen. Versuchen Sie, den Aufwand dafür in Relation zu setzen zu dem Ergebnis, das Sie von der Einführung von OOT erwarten.

In die "das Feature muß hinein"-Mühle geraten

Sie kennen das: nach endlosen Diskussionen, ständigen Kompromissen, hunderten von Überstunden ist die Version 1.0 fertig. Nun wollen Sie all die Stellen, an denen der Code ziemlich schlecht zusammengezimmert wurde, erstmal aufräumen. Sie wissen, nachdem sie das Produkt nun das erste Mal komplett haben, an welchen Stellen Sie was besser machen können. Sie wollen gerade anfangen, als Ihnen den Vertrieb eine Liste hereinreicht, auf der die Features aufgelistet sind, die nun auf jeden Fall in die Version 2.0 müssen. Die Pläne für Ihre Architekturverbesserung verschieben Sie also auf Version 3.0 … oder für immer.

Möglicherweise ist das Management der Meinung, daß es unnötig ist, daß Sie eine "elegante" Architektur in Ihrem Programm haben oder daß die Programmierer nur ihr Hobby pflegen, wenn sie ihren Code dahin entwickeln wollen, daß er knapper, klarer und verständlicher wird. Aber solche Pflegemaßnahmen zahlen sich immer aus. Immer. Die einzige Frage ist, wann sie sich auszahlen und wieviele Vorteile man erhält. Leider läßt sich das meist nicht eindeutig berechnen, und das Fehlen einer klaren Antwort kann dazu führen, daß Ihnen nicht die Zeit gegeben wird, Codepflege zu betreiben.

Anzeichen: Sie werden ständig dazu angehalten, Arbeit in die nächste Version und nicht in die aktuelle zu stecken.

Auswirkungen: Die Kosten für neue oder erweiterte Funktionen steigen und fallen nicht, wie sie es eigentlich beim Einsatz von OOT tun müßten.

Erkennung: Setzen Sie sich mit dem Management zusammen, um im Detail zu erklären, welche Arbeiten "unter der Haube" zu tun sind. Erklären Sie, welche Auswirkungen das auf die Liste der neuen Features hat. Schauen Sie, welche Reaktion Sie erhalten.

Beseitigung: Die schwerere Möglichkeit ist, das Thema mit dem Management und den Anwendern zu diskutieren, um eine Priorisierung der gewünschten Features zu erhalten. Die Wahl dieser Möglichkeit hängt von der Reaktion auf den Erkennungsversuch ab. Die zweite Möglichkeit ist, die benötigten Zeiten für neue Funktionen höher anzusetzen und die Reserven zu nutzen, um den Code zu überarbeiten.

Prävention: Fördern der Erkenntnisse, daß sich eine saubere Architektur lohnt, daß sie aber im ersten Anlauf mehr Zeit kostet. Auswirkungen von OOT auf Zeitpläne werden im Kapitel Managementfehler weiter beleuchtet.

Weitere politische Risiken

·         Die Vorteile von OOT aufbauschen
Es ist leicht, über OO begeistert zu sein. Es ist eine wichtige Technologie, die hilft, die heutzutage immer komplexer werdenden Anforderungen zu beherrschen. Jemand, der sich frisch damit beschäftigt, wird sehen, wie elegant sich viele Probleme lösen lassen. Allerdings führt das insbesondere beim Verkauf von Projekten oder Produkten dazu, daß dem Kunden zuviel versprochen wird, was zu früh in Aussicht gestellt wird und zu unrealistisch geringen Preisen angeboten wird.

·         Die Unterrichtung des Managements unterlassen
Oft wird es in Projektteams als leichter angesehen, um Entschuldigung als um Erlaubnis zu bitten. Die kann dazu führen, daß Features implementiert werden (und damit Zeit vertan wird) die in der Planung nicht vorgesehen waren. das kann dazu führen, daß im Falle eines Projektverzugs sehr unangenehme Fragen gestellt werden.

·         OO als Religion ansehen
OOT macht das Erstellen von Software einfacher. Die Annahme, daß sich mit ihr alle Probleme lösen lassen, daß alles besser werden wird, ist jedoch insofern gefährlich, als diese Annahme dazu führen kann, daß kritische Fragen nicht gestellt oder nicht ernst genommen werden.

Managementfehler

Die Notwendigkeit für Training und Schulung von Entwicklern ist inzwischen bekannt. Hinzu kommt aber die - möglicherweise noch dringendere - Notwendigkeit, auch die Projektleiter zu schulen. Ein Projektleiter als technischer Manager sollte fähig und willens sein, folgende Punkte zu regeln:

·         die richtigen Grundlagen für die Erwartungen des Managements zu liefern

·         die Fähigkeiten der Entwickler richtig einzuschätzen und diese richtig einsetzen

·         den Status des Projektes und den benötigten Ressourcenaufwand richtig einzuschätzen.

Dazu braucht man vor allem Erfahrung, aber auch das Studium von Fachliteratur hilft und gibt Ideen, worauf man beim Management eines Projektes achten sollte.

Eine lineare Entwicklungskurve erwarten

Projektverlauf

Unter einer linearen Entwicklungskurve wird hier verstanden, daß der Output an Features oder ganz allgemein "technischem Material" wie Dokumentation, Klassenentwürfen, Klassenbibliotheken etc. über die Zeit konstant bleibt und sich das Projekt stetig seiner Fertigstellung nähert. In OO-Projekten ist der Verlauf aber nicht so. Im Verlauf von OO-Projekten werden die Entwürfe automatisch immer weiter verfeinert. Dadurch entstehen ständig neue Wege, Klassen und Objekte zusammenzufassen. Die Folge ist normalerweise eine Reduzierung der Komplexität des Designs und der Implementation. In solchen Phasen des Reduzierens von Komplexität wird Zeit für das Überdenken und das Redesign der Lösung aufgewendet. Das erscheint nach außen als Phase, in der nicht produziert, in der kein Fortschritt erzielt wird. Oft ist es in solchen Phasen schwierig, zu erklären, daß tatsächlich wichtige Arbeiten stattfinden und daß diese Arbeiten nötig sind, um das Projekt überhaupt am Laufen zu halten.

Anzeichen: Diagramme des Managements, die einen linearen Projektverlauf zeigen; Meilensteine, die nicht erreicht werden; Köpfe rollen.

Auswirkungen: Projekte sind zu spät und ständig werden Schlußtermine verschoben. Bei der Verschiebung von Terminen kann Panik auftreten.

Erkennung: Achten Sie auf Terminpläne oder Projektdiagramme, die einen linearen Verlauf des Projektes implizieren. Achten Sie auf die Erwartungen, die das Management sehen will und wann welche Resultate gewünscht werden.

Beseitigung: Sollte das Projekt schon laufen, machen Sie gnadenlos einen neuen, realistischen Zeitplan. Fordern Sie die Entwickler auf, über den Stand der Subsysteme einen brutal ehrlichen Bericht zu geben. Planen Sie vom gegebenen Punkt des Projektes neu und berücksichtigen Sie die Phasen der Verringerung von Komplexität.

Prävention: Planen Sie, das Projekt mit dem Spiralmodell zu entwickeln und planen Sie dort genügend Phasen für Projektreviews ein.

Weitere Managementrisiken

·         Eingeübte Verfahren fallenlassen
Die Einführung von OOT zur Softwareentwicklung bedeutet nicht, daß eingeübte Verfahren z.B. zum Testen von Programmen entfallen können.

·         Es unterlassen, ein Vorgehensmodell zu entwickeln und zu benutzen
Ein Vorgehensmodell für ein Projekt sollte mit Bedacht gewählt werden. Je nach Projekt kann man in kleinen Schritten Features hinzufügen oder kann über Prototypenentwicklung zum Produkt kommen oder man macht zuerst ein umfassendes Pflichtenheft. Das Vorgehensmodell sollte aber mit allen Beteiligten abgesprochen und dann auch befolgt werden, um nicht unnötige Verwirrung in einem Projekt zu stiften. Dieser Punkt birgt in objektorientierten Projekten erhöhten Entscheidungsbedarf, da sich durch die Möglichkeiten, die die OOT bietet, die Anzahl der in Frage kommenden Vorgehensmodelle stark erhöht hat.

·         nicht abgesprochene Änderungen oder Verschiebungen der Spezifikationen erlauben
die Spezifikation ist die Grundlage der gesamten Softwareerstellung: sie ist die Richtschnur für das Design, die Implementation, die Tests. Nicht abgesprochene Änderungen hier können zu erheblichem Mehraufwand führen, ja sie können das Projekt zum Scheitern bringen, denn 'es wurde ja nicht geliefert, was in den Spezifikationen steht'.

·         neue Features erlauben
bei der Programmierung von OO-Software passiert es leicht, daß durch 'ganz kleine und einfache' Ergänzungen neue Features während der Implementationsphase eingebaut werden. der Aufwand für die Implementation solcher Features ist praktisch nicht meßbar. Allerdings muß dafür eine Dokumentation erstellt werden, das Feature muß getestet werden und möglicherweise gefällt das den Anwender nicht, so daß es später wieder mit Zusatzaufwand umgebaut werden muß.

·         Prototypen mit fertigen Features verwechseln
Prototypen beinhalten nur die Basisfunktionalität, um ein Feature zur Verfügung zu stellen, oder ein Feature zu simulieren. Ein Prototyp ist mitnichten ein fertiger Programmteil: es fehlen so grundlegende Teile wie Prüfung auf Ausnahmen und Code für Fehlerbehandlung, der Code ist nicht getestet, es gibt keine ordentliche Dokumentation, das Feature setzt nicht auf eine solide Klassenstruktur auf etc. Wenn man einen Prototypen mit einem fertigen Feature verwechselt, besteht natürlich auch die Gefahr, daß die restlichen Arbeiten, um dieses Feature zu implementieren, übersehen werden.

·         Fragen zu Tode diskutieren
Speziell in Projekten, in denen die Beteiligten noch nicht sehr große Erfahrung in OO haben, werden viele Fragen oft durch spekulative Annahmen zu lange diskutiert. Damit wird meist zu viel Zeit verbracht und die Aspekte, die diskutiert werden, werden oft nicht dokumentiert. Meist ist es in solchen Situationen produktiver, eine Entscheidung für eine Vorgehensweise zu treffen, die offenen Fragen zu notieren und die Diskussion noch einmal aufzunehmen, nachdem ein Weg testweise beschritten wurde. Das Risiko, Fragen zu lang zu diskutieren, ist leicht an Diskussionsbeiträgen zu erkennen, die mit "Es könnte aber auch sein, daß…" anfangen.

·         Die falschen Maßstäbe verwenden

Analyse- & Designfallen

Die Fertigkeiten, die für objektorientierte Programmierung benötigt werden, erhält man nicht über Nacht. Die für OOA/D noch viel weniger. Sie können eine Menge aus den vielen Büchern lernen, die über das Thema geschrieben wurden, aber Sie müssen auch Erfahrungen sammeln. Je früher Sie damit anfangen, desto besser. Fangen Sie mit einem weniger riskanten, kleinen Projekt an und planen Sie reichlich Zeit für Redesign und Diskussionen ein.

Unterschätzung der Schwierigkeit von Analyse und Design

Analyse und Design für Software zu machen ist schwierig, besonders, wenn man sie gut und sorgfältig machen will. Je nach eingesetzter Methode wird es notwendig, folgende Punkte für die Analyse zu definieren:

·         das Anwendungsgebiet

·         Anforderungen der Benutzer

·         zu verwendendes Objektmodell und Notation

·         Klassen des Anwendungsgebiets

·         Subjekte des Anwendungsgebiets

·         Objektverantwortlichkeiten

·         Klassenhierarchien

·         Aggregationen

·         Attribute

·         Methoden

·         Objektbeziehungen und -interaktionen

·         Statusänderungen

·         Data Dictionaries

·         Ereignisabfolgen und Nachrichtenfluß

·         dynamische Modelle inklusive use-cases und Szenarios.

 

Das Design erfordert dann noch folgende Spezifikationen:

·         Interna von Klassen und Objekten

·         Unterscheidung von abstrakten und konkreten Klassen

·         Datenmanagement

·         Benutzeroberfläche und Interaktionen mit dem System

·         Einteilung in Subsysteme, Module und deren Abgrenzung.

 

Man kann nun diskutieren, wo Analyse aufhört und Design anfängt, aber die Notwendigkeit, die genannten Punkte abzuhaken, ist unstreitig. Und es ist nicht einfach, jeden Punkt ordentlich zu erledigen.

Anzeichen: Unsicherheit über die bereitzustellenden Ressourcen und den Aufwand, den man für A&D treiben muß. Fehlende Unterstützung bei der Erarbeitung von Plänen für A&D. Ständige ad-hoc-Entscheidungen in der Analyse- und Designphase.

Auswirkungen: Terminverschiebungen, schlecht designte Anwendungen, Anwendungen die den Anforderungen der Benutzer nicht gerecht werden.

Erkennung: Vergleichen Sie die o.g. Liste der Spezifikationen mit denen, die Sie in Ihrem Konzept haben. Vergleichen Sie Ihr Konzept mit anderen in der Literatur genannten oder dem erfahrener Projektleiter. Gehen Sie die Punkte durch und schätzen Sie den Aufwand, den Sie jeweils zur Erledigung treiben müssen.

Beseitigung: Benutzen Sie die Checkliste, um herauszufinden, was in Ihrem Projekt schon geleistet wurde und was noch erledigt werden muß. Besprechen Sie die Liste mit allen Projektbeteiligten und planen Sie die

Prävention: Tun Sie das, was unter Erkennung und Beseitigung steht, bevor Sie ein Projekt angehen.

Weitere Analyse- & Designfallen

·         Eine zu globale Lösung entwickeln
Normalerweise ist eine generelle oder komplette Lösung für eine Aufgabenstellung keine schlechte Sache, im Gegenteil. Da OO es erleichtert, die Abstraktion von Problemstellungen zu verbessern, führt dies meist automatisch zu globaleren Ergebnissen. Wieso aber ist das eine Falle? Wenn man sich hineinsteigert, eine globale Lösung für ein Problem zu finden, führt das automatisch zu höherem Entwicklungsaufwand. Wenn man aber in seiner Zeit und im Termin beschränkt ist, kann das zu einem Problem führen.

·         OOA/D und konventionelle Methoden mischen
Es ist eigentlich offensichtlich, daß mit Hilfe von funktionaler Dekomposition zur Definition von Funktionen innerhalb einer Software kein solides OO-Modell entstehen kann, denn die funktionale Dekomposition hat genau das Gegenteil von OOT zum Ziel: nämlich die einzelnen Funktionalitäten ohne ihren Kontext zu beschreiben. Die OOT versucht dagegen, Funktionen so zu gruppieren, daß sie sich als Methoden den richtigen Objekten zuordnen lassen. Erkennen läßt sich dieser Trend daran, daß es Klassen gibt, die wie eine Prozedurbibliothek aussehen und deren Beziehungen zu anderen Klassen unklar sind.

·         Die Dinge zu komplex sehen
Unangemessene Komplexität in einem OO-Projekt kann generell als Warnzeichen betrachtet werden. Komplexität innerhalb einer Klasse kann ein Zeichen dafür sein, daß die Klasse zu viele Funktionalitäten beinhaltet, die sich besser auf mehrere Klassen aufteilen läßt. Eine zu komplexe Schnittstelle der Klasse deutet darauf hin, daß in der Klasse zu viele Funktionen zusammengefaßt wurden. Zu viele Relationen zwischen Klassen deuten auf zu geringe Kapselung hin.
Daumenregeln: nicht mehr als 10 - 15 originäre Methoden in einer Klasse (Init etc. nicht gerechnet), nicht mehr als 10 - 20 Properties und Methoden in der Schnittstelle, nicht mehr als 5 Level in der Vererbung, nicht mehr als 5 - 10 Klassen, mit denen Kommunikationsbeziehungen notwendig sind.

·         Design per Statistik
heißt, alle denkbaren Zustände, Anwendungsfälle und/oder Umgebungen einer Klasse auflisten und die Klasse dann für diese Szenarien zu erstellen ohne die tatsächlich auftretenden Anwendungsfälle vorher abstrahiert zu haben. Das führt zu schwer wartbaren Systemen die nur schlecht zu testen sind und die vollgestopft sind mit Code, der nur ganz speziellen Zwecken dient.

·         Für das falsche Publikum arbeiten
Bei der A&D ist es wichtig, Input von den Anwendern des Systems zu bekommen. Leider ist es nicht immer einfach, genau die Leute herauszufinden, die wirklich mit der zu erstellenden Software arbeiten müssen. Wenn man jedoch Vorgaben umsetzt, die jemand anderes gemacht hat, ist Ärger mit den späteren Anwendern förmlich vorprogrammiert.

·         Den Anwendern eine neue Arbeitsweise aufzwingen
Objektorientiert aufgebaute Systeme sind oft intuitiver zu bedienen, besser an den realen Bedingungen ausgerichtet und bieten mehr Funktionalität als die vorangegangenen Programmsysteme. Die Benutzer klammern sich aber möglicherweise sehr an ihre gewohnte Arbeitsweise. Nimmt das neue Programm drauf keine Rücksicht, kann es zu erheblichen Widerständen auf seiten der Anwender kommen. Erkennbar ist diese Falle an kleinen gelben Haftnotizen am Monitor der Benutzer, auf denen Tastenkombinationen notiert sind.

Risiken der Entwicklungsumgebung

Die Wahl der Entwicklungsumgebung ist möglicherweise die größte Einzelentscheidung, den man in einem Projekt treffen kann. Bei einem Beitrag zu einer VFP-Konferenz stellt sich die Frage so herum vielleicht nicht. VFP ist ein hervorragendes Tool, es läßt sich auf vielerlei Weise verwenden und erweitern (ActiveX, OLE, ODBC, etc.). Trotzdem müssen Sie entscheiden, ob VFP als alleiniges Entwicklungswerkzeug für die Anforderungen Ihres Projektes geeignet ist. Eine der besten Möglichkeiten ist hier, zum Beispiel in Compuserve-Foren mit anderen Entwicklern zu diskutieren.

Nicht in Tools und Training investieren

OOT ist ein Werkzeug, das man beherrschen muß oder von dem man wenigstens wissen muß, wie es funktioniert. Sie gehen nicht in den Werkzeugladen, einen Hammer kaufen, wenn Sie eine Kommode neu lackieren wollen, weil Sie wissen, daß man dafür Farbe und Pinsel braucht. Wenn Sie dann Pinsel und Farbe haben, aber noch nie damit gearbeitet haben, werden Sie statt der teuren Kommode vielleicht erstmal den Gartenzaun streichen. Sie üben und erwerben so Fähigkeiten, die Sie dann an kritischen Projekten einsetzen können. Vielleicht brauchte der Gartenzaun nicht gestrichen zu werden. Dann hat die Zeit, die Sie dafür aufgewendet haben, keinen direkten Nutzen gehabt: es war eine Investition, die sich erst später bezahlt macht. Auch wenn Sie während Ihrer Arbeit am Gartenzaun merken, daß Sie mit einer Spritzpistole bessere Ergebnisse erzielen würden, müssen Sie die erstmal kaufen, sprich: investieren.

Genau so ist es mit der Entwicklung von objektorientierter Software. Es gibt Werkzeuge, mit denen man bessere Ergebnisse erzielt. Leider sind diese Werkzeuge oft nicht billig. Sie liegen typischerweise zwischen 500,- DM und 5.000,- DM pro Entwicklerplatz. Oft werden solche Kosten als Argument dafür verwendet, diese Tools nicht einzusetzen. Aber letztlich zahlen sich gut genutzte Werkzeuge immer aus. Das Argument, daß die Tools möglicherweise nicht das bringen, was man sich von Ihnen verspricht, läßt sich durch Testberichte oder das Erfragen von Erfahrungen bei anderen Anwendern mildern.

Wenn man dann schon in solche Tools investiert hat, macht es kein Sinn, sie nicht richtig zu nutzen. Es werden möglicherweise weitere Kosten für Schulung und Training fällig. Aber hier gilt ganz besonders: ein geschulter Entwickler holt mit Hilfe eines gut genutzten Tools die Kosten dafür oft schon mit dem ersten Projekt wieder heraus.

Anzeichen: Ständige Beteuerungen des Managements, daß für Test und Kauf von Tools keine Mittel vorhanden sind.

Auswirkungen: Geringere Produktivität; Schwächen in Design und Implementation; längere Entwicklungszeiten.

Erkennung: Sehen Sie sich die z.Z. eingesetzten Werkzeuge an. Fragen Sie die Entwickler nach den Tools, die ihre Arbeit ideal unterstützen könnten. Schlagen Sie Werkzeuge vor, von denen Testversionen angeschafft werden können.

Beseitigung: Suchen Sie nach Tools, die nützlich sein könnten, versuchen Sie, Testversionen und Adressen von Firmen zu erhalten, die die Tools schon einsetzen. Machen Sie eine Vorführung, an der Sie die Vorteile erläutern können. Beschaffen Sie nur jeweils ein Werkzeug gleichzeitig.

Prävention: Starten Sie die Arbeiten zur Suche von Tools vor einem Projekt. Machen Sie eine Liste, welcher Entwickler welches Tool braucht; normalerweise brauchen nicht alle Entwickler alle Tools. Evtl. können Tools auch in-house entwickelt werden. Obwohl das normalerweise die teuerste Variante ist, lassen sich die Kosten oft leichter vertreten oder verstecken.

VFP verwenden

Es ist nicht schwer, Kritiker von VFP zu finden. Für viele Entwickler, die mit anderen Systemen arbeiten, ist es zu schwer zu lernen, ist es nicht sicher genug oder es wird der Systembruch von OO-Programmierung und relationalem Datenmodell bemängelt.

Daneben bietet VFP nur wenige Möglichkeiten, ohne zu Programmieren zu Ergebnissen zu kommen. Es ist nur für Windows-Plattformen erhältlich, also nicht portierbar.

Anzeichen: Entwickler brauchen lange, VFP zu lernen und sträuben sich, unter VFP zu entwickeln.

Auswirkungen: Projekt für OS/2 <g> oder andere Rechner lassen sich nicht erledigen.

Nicht VFP verwenden

Visual FoxPro ist die Entwicklungsumgebung mit der höchsten Produktivität im Bereich Datenbank-basierten Anwendungen. Es hat die beste Verbindung von Entwicklungsumgebung und Datenbankengine. Es läßt sich gut in der Entwicklungsumgebung testen, ohne daß Compilerläufe gestartet werden müssen. Datenbankanwendungen unter VFP lassen sich gut skalieren, laufen auf Einplatz-Rechnern ebenso wie als Fileserver-Datenbank oder auf SQL-Backends. VFP hat eine gute Verbindung von objektorientierter Programmierung und schneller relationaler Datanbankengine. Es gibt eine gute Unterstützung mit Tools. Es läuft auf mehr als 80% aller installierter PC, also warum Multi-Plattform?

Alle diese Gründe und noch viel mehr treffen in dieser Kombination nur auf Visual FoxPro zu. Wenn Sie also in die Versuchung kommen, VFP nicht einzusetzen, prüfen Sie, welche Gründe wirklich für ein anderes Tool sprechen.

Anzeichen: Sie merken, daß Sie das falsche Entwicklungswerkzeug eingesetzt haben, wenn:

·         die Performance nicht stimmt

·         keine Usergroup existiert

·         Ihre VFP-Entwickler sträuben sich, mit Access, VB oder Delphi zu arbeiten.

Auswirkungen: Entwicklungszeiten verlängern sich. Die Applikation hat nicht die Performance, die die Anwender sich versprochen haben, besonders, wenn die Datenmengen größer werden.

Erkennung: Fragen Sie Ihre Entwickler, welche Funktionen (Vererbung, Datenmanipulation in der Entwicklungsumgebung) sie sich von der aktuellen Umgebung wünschen und welche Zusatztools sie benötigen. Vergleichen Sie, was davon bereits in VFP enthalten ist.

Implementationsfehler

Irgendwo zwischen Design, verwendeten Tools und der Erstellung von Klassen liegen Entwicklungspraktiken, die zu Schwierigkeiten im Projektverlauf führen können. Gemeinsam ist diesen Praktiken oft, daß sie dazu verführen, das zu tun, was man will und nicht das, was man tun soll. Der Kern des Problems ist, daß die Arbeit in einem Projekt, die wir am wenigsten mögen, möglicherweise die wichtigste ist. Wenn Sie oder Ihre Entwickler eine Arbeit nicht gerne tun, kann das daran liegen, daß sie dafür zu wenig ausgebildet sind und sich daher unsicher fühlen. Wir haben alle eine Entwicklung zum Foxpro-Programmierer hinter uns. Wir programmieren gerne und fühlen uns sicher in dem, was wir tun. Aber nichtsdestotrotz gibt es Notwendigkeiten in einem Projekt, die über das Entwickeln von Programmcode hinausgehen.

Zu früh mit der Codierung beginnen

Wie auch schon viele der genannten zu treffenden Entscheidungen, passiert es nicht nur in OO-Projekten, daß, ohne es offensiv zu entscheiden, mit der Programmierung begonnen wird. Es ist eine durchaus gängige Panne in Softwareprojekten verschiedener Implementationsstrategien. Allerdings ist es so, daß durch die neuesten Tools, die unglaublich leistungsfähig sind und ganz besonders durch Visual FoxPro die Gefahr sehr groß ist, daß man bereits in einer sehr frühen Phase Ideen bekommt, wie man eine Problemstellung lösen kann. Wie schon angesprochen, ist der Produktivitätsfortschritt bei OO-Sprachen nach einer Lernphase wirklich überwältigend. Die Möglichkeiten, die ein Entwickler sieht (bzw. erahnt), begeistern ihn. Sie haben eine fast süchtig machende Wirkung. Es gibt wahre Wunder, die man mit OO-Tools bewirken kann. Und oft wird dann auch ansatzlos damit begonnen, Wunder zu vollbringen. Dieser Trend ist dann schwer zu beheben, denn durch die schnellen Fortschritte, die erzielbar sind, scheint diese Fehlentwicklung ja keine zu sein. Im Gegenteil: die am Projekt beteiligten Personen (Anwender, Manager etc.) sind erfreut über die Fortschritte, die erzielt werden. Das zentrale Problem ist hier, daß auf diese Weise möglicherweise eine Applikation gebaut wird, die der Kunde nie wollte. Nachher ist dann die Verwunderung groß, wenn die Anwender eine Funktion finden, die die Schuhgröße von Mitarbeitern automatisch berechnet.

Anzeichen: Programmierer, die Code entwickeln, bevor Analyse und Design abgeschlossen sind.

Auswirkungen: Die Notwendigkeit von Analyse und Design werde in Frage gestellt. Eine unpassende Architektur wird erstellt. Später wird der Zeitplan überschritten, da ein Redesign zu einem ungünstigen späteren Zeitpunkt notwendig wird.

Erkennung: Wenn weniger als ca. 25 - 35% der geschätzten Zeit für das Gesamtprojekt abgelaufen sind, sollte ausschließlich A&D gemacht worden sein. Beachten Sie dabei, daß die Zeitschätzungen für Projekte oft äußerst optimistisch sind.

Beseitigung: Stoppen Sie die Codierung, bis A&D zu einem befriedigenden Ergebnis gekommen sind. Ändern Sie ggf. Ihr Vorgehensmodell, indem Sie einen iterativen Projektverlauf verfolgen. Das erlaubt, A&D für einzelne Schritte durchzuführen und das Ergebnis zu implementieren, während Analyse und Design für das nächste Inkrement gemacht werden. Beachten Sie dabei, daß eine iterative Vorgehensweise nur dann machbar ist, wenn Sie als erstes eine solide Architektur festgelegt haben.

Prävention: Die Notwendigkeit, eine gründliche Analyse und ein klares Design zu machen, wird oft als nebensächlich erachtet. Hinzu kommt, daß das Management nichts mehr zu sehen liebt, als schnelle Resultate. Das Management darf nicht nur tolerieren, daß erst spät codiert wird, sondern muß dies verlangen, um eine solide Anwendung zu erhalten und spätere Terminverschiebungen zu vermeiden.

Die Möglichkeit, Prototypen zu bauen, bedeutet natürlich eine sehr frühe Codierung. Das Erstellen von Prototypen birgt aber auch wieder neue Risiken, über sie man sich bewußt sein muß. Insbesondere dürfen Prototypen auf keinen Fall eine Analyse- und Designphase ersetzen, sondern dürfen nur zu deren Unterstützung dienen. Und - ohne hier auf die speziellen Gefahren bei der Prototypenerstellung einzugehen - Prototypen dürfen nicht mit fertigen Funktionen verwechselt werden!

Weitere Implementationsfehler

·         Konzepte und Entscheidungen nicht dokumentieren
Im Verlauf eines OO-Projektes wird viel besprochen. Es wird besprochen, welche Klassen zu implementieren sind, welche Funktionalität sie erhalten sollen, in welcher Stufe der Vererbung welche Funktion implementiert werden soll. Die Trennung von Implementation und Interface, die als einer der großen Vorteile gilt, kann sich hier zu einem der größten Nachteile der OO entwickeln. Durch diese Trennung sind die Schnittstellen einer Klasse nicht mehr selbsterklärend, so daß, solange kein Quellcode existiert, der Kommentare über das Verhalten dieser Klasse enthält, die einzige Möglichkeit, die Designentscheidungen nachzuvollziehen, darin besteht, alle Entscheidungen zu dokumentieren.

·         Annehmen, daß Kapselung Programmierstandards überflüssig macht
Das Ziel "Design for an interface, not for an implementation" ist richtig. Dies bedeutet jedoch nicht, daß es egal ist, wie implementiert wird. Denken Sie nur an die verheerenden Folgen, die es haben kann, wenn z.B. die local-Deklaration weggelassen wird und alle Variablen in Methodencode private erzeugt werden.

·         Sich von schnellen Erfolgen täuschen lassen
Diese Gefahr wurde schon in verschiedenen anderen Kategorien angesprochen und gilt auch für die Implementation. Da es speziell in VFP so unglaublich leicht geht, mit Hilfe der visuellen Designtools z.B. Formulare zu bauen und Basisfunktionalität zu implementieren, kann man leicht annehmen, daß auch die restlichen Funktionen so schnell zu realisieren sind. Insbesondere, wenn keine kompletten Spezifikationen vorliegen, kann man sich leicht vom schnellen Fortschreiten blenden lassen. Dabei stellt sich dann meist erst später heraus, daß es einige Anforderungen gibt, die durchaus etwas höheren Aufwand brauchen, um sauber umgesetzt zu werden.

·         Zu viele Versprechungen machen, ohne Zeit zu haben, sie zu halten
Als Entwickler hat man oft die Tendenz, die Anfrage für eine Feature mit "klar, ist ganz einfach" zu beantworten. Speziell in OO-Entwicklungsumgebungen und hier wieder besonders in gut aufgebauten Klassenmodellen fällt einem oft spontan eine Lösung auf eine Anforderung ein. Das Problem hiermit ist ein zweifaches: jede Zusage und sei sie auch noch so klein, braucht ihre Zeit, um umgesetzt zu werden und das kann sich sehr summieren. Zweitens zieht die Zusage für ein Feature nicht nur die Programmierung nach sich, sondern es muß ja getestet werden, die Dokumentation muß angepaßt werden und es muß geprüft werden, ob es nicht mit anderen Zusagen kollidiert.

·         Details auf später verschieben
Des ist kein Fehler im klassischen Sinne, sondern ein Entwicklungsentscheidung, die besonderer Aufmerksamkeit bedarf. Hat man sich entschieden, die Funktionalität von verschiedenen Methoden nur rudimentär zu implementieren und dann mit dem Design der anderen Klassen fortzuschreiten, darf man nicht vergessen, daß hier noch Arbeit versteckt ist, um die volle Funktionalität aufzubauen und zu testen. Die Gefahr hier ist vor allem die Aufsummierung von Arbeiten, die schon als 'fertig abgehakt' gelten.

·         Sich von der dunklen Seite der Macht verführen zu lassen
Die Anwendung einer OO-Sprache heiß nicht, daß die damit erstellten Programme automatisch besser sind. Die größeren Möglichkeiten bieten nämlich auch mehr Fallstricke, mit denen man sich hervorragend im doppelten Wortsinne selbst fesseln kann. Wenn man sich von den grandiosen Möglichkeiten, die VFP bietet davontragen läßt, findet man sich irgendwann vielleicht an einem Punkt wieder, an den man gar nicht wollte. Nur, weil man Buttons bauen kann, die unter dem Mauszeiger wegrutschen, ist es ja nicht sinnvoll, das zu tun.

Risiken in Klassen und Objekten

Wenn man von FPW 2.6 zu VFP wechselt, hat man plötzlich ganz neue Möglichkeiten, ein Problem zu lösen. Dadurch, daß es nicht nur ein oder zwei Lösungswege, sondern gleich viele verschiedene gibt, beschleicht einen oft ein Gefühl der Unsicherheit über die eingeschlagene Richtung. Aber im Lauf der Zeit wird man immer sicherer darin, aus den gebotenen Mitteln das passende zu finden und anzuwenden. Mt Hilfe einer Prüfung aufgebauten Klassenmodells auf eine kanonische Form, auf Programmierstandards, auf Ein- und Ausgangsbedingungen kann man Klassen finden, die logisch, leichtgewichtig, vererbbar, nur lose gekoppelt und leicht wiederverwendbar sind. Dazu gibt es eine Reihe von Fragen, mit deren Hilfe ein Design geprüft werden kann.

Klassen überladen

Eine überladene Klasse ist eine mit zu vielen Properties oder zu vielen Methoden oder eine, die sich nicht mehr kompakt dokumentieren läßt. Die Begriffe "zu viele" oder "nicht mehr kompakt" sind natürlich relativ. Ein Anhaltspunkt dafür, wann eine Klasse überladen ist, ist, daß die Entwickler es zunehmend schwierig finden, die Klasse zu debuggen, zu erweitern oder zu benutzen. Es kann aus den verschiedenen Gründen passieren, daß eine Klasse überladen wird. es kann sein, daß sie zu viele Funktionen erfüllen soll, z.B. einen kompletten Texteditor bereitstellen. Oder es kann eine Basisklasse sein, die zu viele Funktionen für die abgeleiteten Klassen enthält. Es kann so passieren, daß der Code zu viele verschiedene, erst in den Subklassen auftretende Situationen behandelt.

Anzeichen: Sehr langer Methodencode (> 100 Zeilen), eine lange Liste von Properties und Methoden, Schwierigkeiten, eine Klasse zu verstehen und zu debuggen.

Auswirkungen: Stark ansteigende Komplexität des Programms, schwer zu findende Bugs, unvorhergesehenes Verhalten, hoher Speicherbedarf.

Erkennung: Zählen Sie die Anzahlen de Properties, die Anzahl der Methoden und die Anzahl der Zeilen für jede Klasse und für jede Methode. Erstellen Sie je eine Liste der Klassen mit absteigender Anzahl und überprüfen Sie die jeweiligen Top-ten der Listen.

Beseitigung: Überladene Klassen kann man durch sukzessives Aufbauen von Vererbung, Aggregation und Kooperation mehrerer Klassen abbauen. Möglichkeiten sind:

·         Migration des Codes zu vorhandenen Superklassen (Nutzen der Vererbung)

·         Aufteilen der Klasse in eine Basisklasse und mehrere davon abgeleitete Klassen (Vererbung)

·         Aufteilen der Klasse in eine Containerklasse, die mehrere Komponenten enthält (Aggregation)

·         Auslagern von Funktionen in Klassen, die nur bei Bedarf instanziiert werden (Kooperation)

Prävention: Prüfen Sie bereits während des Designs die entstehenden Klassen immer wieder anhand der Listen für die Anzahl Properties, Methoden und Codezeilen, die Sie aus anderen Projekten oder Klassenbibliotheken gewonnen haben.

Weitere Risiken in Klassen und Objekten

·         Die verschiedenen Relationen von Klassen verwechseln
Es ist relativ einfach, umgangssprachlich Vererbung auszudrücken. So war in der Analyse eines Systems, das wir entworfen haben, klar, daß ein Jurist des Anwendungsgebiets eine Person (die als Klasse ebenfalls definiert wurde) ist, also zwischen beiden eine Vererbungsbeziehung besteht. Nachher stellte sich heraus, daß die Tatsache, daß der Jurist im "richtigen Leben" eine Person ist, für die Applikation völlig unerheblich war. Es reichte also aus, der Juristenklasse zu ermöglichen, auf die Funktionalitäten der Personenklasse zuzugreifen, wir brauchten nicht alle Eigenschaften zu ererben und konnten dadurch die Vererbungshierarchie der Klassen weniger komplex designen.

·         Unpassende Nutzung von Vererbung
Man kann Vererbung z.B. nutzen, um auf Properties und Methoden einer Klasse zuzugreifen, die eigentlich als Private deklariert sind. Das birgt die Gefahr, daß mit einer neuen Version der Basisklasse die abgeleiteten Klassen nicht mehr funktionieren, weil z.B. die privaten Properties für andere Zwecke verwendet werden oder ganz entfallen sind.

·         Basisklassen mit zuviel oder zuwenig Funktionalität
Basisklassen sind unter anderem dazu da, eine Schnittstelle bereitzustellen. Wenn eine Klasse innerhalb eines Modell existiert, die keine öffentlichen Methoden hat, hat sie zuwenig Funktionalität, möglicherweise wurde sie als Platzhalter für eine gute Idee eingebaut, aber wenn keine der abgeleiteten Klassen von der Schnittstelle Gebrauch macht, ist die Basisklasse überflüssig. Eine Basisklasse hat zuviel Funktionalität, wenn die meisten der abgeleiteten Klassen die Implementation, den die Basisklasse bereitstellt, wieder überschreiben.

·         Prozeduralen Code 1:1 in Objekte überführen
Das Überführen von datenzentrierten oder prozeßzentrierten Ansätzen in ein Klassenmodell birgt die Gefahr, daß der Daten- oder der Prozeßteil überbewertet wird. Die Umsetzung von datenzentrierten Ansätzen in ein Objektmodell führt oft dazu, daß die Datenfelder in Properties umgesetzt werden, Methoden hinzugefügt werden, um die Propertywerte zu setzen und daß damit die Klasse als fertig betrachtet wird. Das führt zu Klassen, die kein wirkliches Verhalten haben. Die Zusammenfassung von Funktionssammlungen zu Methoden einer Klasse läßt dagegen oft unberücksichtigt, daß eine Klasse Eigenschaften braucht, die sie zu einem Lösungsaspekt für die Aufgabenstellung macht, eine Klasse wird hier oft als Ersatz für ein Modul oder eine Prozedursammlung gesehen.

·         Klassen zerbröseln lassen
Die bessere Handhabbarkeit von Komplexität und die Wiederverwendbarkeit von Code in OO-Projekten ist eine direkte Folge davon, daß Klassen eine klare und saubere Schnittstelle haben. Leider kann es leicht passieren, daß diese Schnittstelle sich auflöst, indem man Zugriff auf Properties erlaubt, die eigentlich verborgen sein sollten oder daß es notwendig ist, zum Erledigen einer Funktion mehrere Methoden (in der richtigen Reihenfolge) aufzurufen. Dies hat zur Folge, daß viel Code und ggf. weitere Methoden notwendig werden, um immer wieder die Umgebung zu prüfen oder daß die Klasse zweckentfremdet benutzt wird, indem einzelne Methoden in falschem Zusammenhang aufgerufen werden.

·         Allzweckklassen bauen
Eine Klasse zu bauen, die wie ein schweizer Offiziersmesser alle möglichen Funktionen zusammenfaßt, mag sehr bequem sein, da man bei der Programmierung nicht immer nach einer passenden Klasse suchen muß. Allerdings erfüllt eine solche Allzweckklasse - wie das Taschenmesser eine Dose nicht so gut öffnet wie ein spezieller Dosenöffner - meist die Funktionen nicht hundertprozentig. Die Entscheidung, eine Funktion zu einer existierenden Klasse hinzuzufügen, statt eine eigene Klasse zu bauen, die die Funktion wirklich voll erfüllt, mag harmlos erscheinen, aber durch das ständige Wiederholen solcher "harmloser" Entscheidungen wird das Klassenmodell sehr bald unübersichtlich und Ihre Klassen werde überladen oder zerbröseln.

QS-Fallen

Die Qualitätssicherung (auch QA, quality assurance) in OO-Projekten ist keinesfalls deshalb überflüssig, weil es Kapselung gibt. Man kann mit OO-Systemen zwar stabilere Programme bauen, aber neben der Stabilität des Programmcodes gehört zur Qualitätssicherung auch, daß sichergestellt wird, daß die Anforderungen, die an die Software gestellt werden, erfüllt werden. Das Durchsetzen von Qualitätssicherungsmaßnahmen ist nicht leicht, weil OO-Projekte generell als besser wartbar gelten. Wie wir oben gesehen haben, ergibt sich das aber nicht automatisch. Auch bei OO-Software machen die Kosten für die Wartung ca. 80% sämtlicher Kosten über die gesamte Lebensdauer aus. Entscheidend ist hier, welchen Anteil "schlechte" Kosten wie Bugfixes zu "guten" Wartungskosten wie Erweiterungsmaßnahmen haben. Ein gut getestetes objektorientiertes System ist eine sehr gute Basis für weitere Entwicklungen und bietet die Möglichkeit, neue Features schneller, stabiler und billiger zu implementieren und damit näher an zukünftigen Marktentwicklungen zu sein.

Das Testen von Komponenten vernachlässigen

Das Testen von kompletten Programmen bietet in OO-Software mit Ihren komplexen Verbindungen zwischen den Objekten nicht immer die Gewähr, alle Zustände, die ein Objekt möglicherweise annimmt, zu simulieren. Hier ist eine Möglichkeit, einzelne Komponenten, also Klassen oder Gruppen von Klassen, zu testen. Testen heißt hier, das tatsächliche Verhalten mit dem in den Spezifikationen beschriebenen zu vergleichen. Damit wird auch deutlich, daß die Tester nicht irgendwelche Leute sein können, die nur den sogenannten "Affentest" beherrschen. Die Tester müssen qualifiziertes Personal sein, das die Spezifikationen versteht und mit dem implementierten Verhalten vergleichen kann.

Für das Testen von Komponenten gibt u.a. es zwei Verfahren:

·         der White Box Test wird von jemandem ausgeführt, der Zugang zum Quellcode hat und sich das Verhalten des Codes bei der Übergabe von ungültigen Parametern ansehen kann oder der die Properties beobachten kann, wenn er den Verdacht hat, daß das Objekt einen ungültigen Status annimmt.

·         der Black Box Test wird von jemandem ausgeführt, der nur die compilierte Version einer Komponente hat und diese anhand der Spezifikation testet. Dies z.B., indem er Programmcode schreibt, der alle möglichen Parameter an die Methoden übergeben und daran feststellt, ob die Komponente in der gewünschten Weise auf ungültige Werte reagiert.

Anzeichen: fortbestehende Instabilität und Bug in verschiedenen Subsystemen

Auswirkungen: Instabilität, unerwartetes Verhalten und darauf folgende Terminverschiebungen

Erkennung: Wenn es keine Pläne oder Anweisungen gibt, wie Komponenten getestet werden sollen, ist besondere Aufmerksamkeit angesagt.

Beseitigung: Versuchen Sie, eine einfache Prozedur für White Box Tests aufzubauen, indem Sie möglichst einen Entwickler, der nicht an dem Projekt arbeitet, einige problematische Komponenten durchsehen und Testprozeduren aufbauen lassen. Das wird ggf. etwas Unruhe in ein Projekt bringen, aber letztlich zahlt es sich aus, wenn Stück für Stück für alle Komponenten Testpläne existieren.

Prävention: Planen Sie die Erstellung der Testpläne und die Tests der Komponenten von vornherein in den Zeitplan des Projektes ein.

Weitere QS-Fallen

·         Die kombinatorische Lawine vergessen
OO-Programmierung bietet die Freiheit, Objekte zu instanziieren und diese miteinander kommunizieren und Dienste in Anspruch nehmen zu lassen. Diese Freiheit birgt allerdings das Risiko, daß irgendwann alle Objekte mit allen anderen Nachrichten austauschen. Die Anzahl der rechnerischen Verbindungen zwischen Objekten beträgt n * (n - 1). Bei nur 10 Objekten sind dies 90 Objektverbindungen, bei 100 Objekten schon 9.900. In Zusammenhang mit den Methoden ergibt sich die Formel m * (n - 1), wobei m die Summe aller Methoden aller Objekt ist. Wenn man nun annimmt, daß jedes Objekt 8 Methoden hat, die aufgerufen werden können, ergeben sich bei 10 Objekten 720 Methodenaufrufe, bei 100 schon 80.000. Hier hinzu kommen auch noch die verschiedenen Kombinationen von Parametern. Seien Sie sich dieser Berechnung bewußt und versuchen Sie, die Schnittstelle der Klassen möglichst einzuschränken.

·         Die Tests erst nach der Implementation planen
Wie oben schon gesagt, sollten Testpläne bereits vor der Implementation bestehen. Einige Dinge, die man bereits vor der Implementation machen kann, ist, in den Programmierstandards festlegen, daß die Entwickler einer Klasse eine Methode mit Code für deren Test entwickeln müssen. Betrachten Sie Code Reviews als eine Möglichkeit, zu testen und planen Sie sie ein, nutzen sie den assert-Befehl, nutzen Sie die Möglichkeit, coverage-logging zu machen.

·         Unterschätzen der Kosten für Test und Support
OO-Projekte verringern die Notwendigkeit für Tests nicht. Wie Sie an den anderen Beispielen gesehen haben, bringt OO sogar neue Anforderungen für den Test mit sich. Dafür muß ein adäquates Budget an Zeit und Geld eingeplant werden.

Probleme bei der Wiederverwendung

Wiederverwendung - der nochmalige Einsatz von Komponenten aus vorangegangenen Projekten - ist der am meisten genannte Vorteil von Objektorientierung. Leider ist es der Vorteil, der nur sehr selten wirklich im erwarteten Umfang erreicht wird. Der Grund dafür ist leicht zu sehen: Wiederverwendung fällt nicht vom Himmel. Sie muß geplant werden und der Entwicklungsprozeß muß mit Mechanismen versehen werden, um wiederverwendbare Komponenten zu finden, zu katalogisieren und bereitzustellen.

Unrealistische Annahmen über den Umfang von Wiederverwendung haben (oder verbreiten)

Dies kann der Grund für die größte Enttäuschung bei der Wiederverwendung von Software sein: die Annahme, daß der prozentual größte Teil der entwickelten Klassen wiederverwendbar ist. Leider ist das meist nicht der Fall. Dafür gibt es mehrere Gründe:

·         der 'hype', der mit der Objektorientierung kommt, hört sich für viele so dramatisch an, daß wahre Wunder erwartet werden

·         Komponenten und Klassen, die für einen Applikationstyp gebaut wurden, passen für einen anderen Typ von Applikation nicht oder nur sehr schlecht

·         die Wiederverwendung wurde nicht richtig geplant, es gibt keine strukturierte Bibliothek oder keine Kriterien, anhand derer eine wiederverwendbare Komponente identifiziert werden kann.

Generell gilt, daß aus Pilotprojekten, die als erstes als OO-Projekt durchgeführt werden, praktisch nichts wiederverwendbar ist, bei weiteren Projekten basierend auf früheren Erfahrungen kann sich dieser Anteil auf 30 - 40% erhöhen, aber solche Raten sind schon sehr gut.

Anzeichen: Termine für neue Projekte werden immer weiter vorverlegt, weil ja 'alles, was wir bisher gemacht haben, wiederverwendet werden kann'.

Auswirkungen: Terminverschiebungen, weil ja der erhoffte Anteil nicht erreicht werden kann.

Erkennung: Vergleichen Sie die Annahmen der Projektbeteiligten über den Anteil der wiederverwendbaren Klassen im aktuellen Projekt. Versuchen Sie, die Klassen, die als wiederverwendbar gelten, unverändert in einem anderen (Test-) Projekt zu verwenden.

Beseitigung: Diskutieren sie die Diskrepanzen in den Schätzungen und versuchen Sie damit, die zu optimistischen Erwartungen zu relativieren.

Prävention: Machen Sie in jedem Projekt eine Liste der Komponenten, die wiederverwendbar sein sollten und teilen Sie sie in Kategorien ein. Nennen sie für jede Komponente die möglichen Einsatzzwecke, um für kommende Projekte die Einschränkungen klar zu machen.

Weitere Probleme bei der Wiederverwendung

·         Nicht in Wiederverwendung investieren
Die Geschichte der OOT hat viele Enttäuschungen hervorgebracht: zuerst wurde angenommen, daß sich objektorientierte Software schneller entwickeln läßt, bis sich dann herausstellte, daß die erste Projekte meist länger dauerten und schwieriger zu handhaben waren. Dann wurde reklamiert, daß die Vorteile sich erst über längere Zeit zeigen, daß die Gewinne erst später mit der Wiederverwendung eintreten. Aber auch diese Gewinne kommen nicht von selbst: sie müssen durch vorangegangene Investitionen erarbeitet werden. Diese Investitionen betreffen verschiedene Gebiete:

·         wiederverwendbare Komponenten müssen globaler programmiert sein und viele verschiedene Fälle berücksichtigen

·         es muß ein Katalog der Komponenten erstellt und gepflegt werden

·         die Entwickler müssen in der Anwendung des Kataloges und der enthaltenen Komponenten geschult werden

·         es kann notwendig sein, Entwickler ausschließlich damit zu beschäftigen, Basistechnologie zu entwickeln.

·         Die Schwierigkeiten unterschätzen, Wiederverwendung richtig zu machen
Einen relevanten Betrag von Wiederverwendung zu erreichen, ist schwierig, weil Komponenten, die wiederverwendet werden sollen, viele vielleicht erst in der Zukunft auftretenden Fälle berücksichtigen müssen. Hinzu kommt, daß sie Ähnlichkeiten zwischen verschiedenen Projekten oft recht klein sind und damit die Chancen selbst für gut geplante Wiederverwendung dahin schmelzen. Außerdem verändert sich auch die Entwicklungsumgebung: Komponenten, die unter Windows 95 noch den letzten Schrei bedeuteten, sind unter Windows 98 vielleicht überflüssig oder unnütz.

·         Zu versuchen, bereits erstellte Klassen zu generalisieren
Innerhalb eines Projektes wird auf vielerlei Arten Druck auf das Projektteam ausgeübt: die Kunden wollen endlich die neue Software, die Features müssen endlich fertig werden, das nächste Projekt muß begonnen werden, usw. Darüber wird der Zusatzaufwand, der nötig ist, um wiederverwendbare Komponenten zu erhalten, oft als überflüssig erachtet. Trotzdem sollen nach Fertigstellung der Software natürlich die einzelnen Klassen wieder im neuen Projekt verwendet werden. Aus den so spezifisch für das eine Projekt erstellten Klassen läßt sich nur unter höherem Aufwand als dem, der nötig wäre, neue Klassen zu bauen, eine generelle Bibliothek erstellen.

Wie man es trotzdem schafft!

In diesem Beitrag wurde eine Menge Punkte genannt, mit deren Hilfe man ein Projekt prima scheitern lassen kann. Es besteht aber kein Grund, nun schwarz zu sehen, denn natürlich lassen sich Projekte auch erfolgreich zu Ende bringen, wenn Sie ein paar Dinge beachten:

Projektbeobachtung

Machen Sie regelmäßig eine Betrachtung Ihres Projektes. Nutzen Sie dazu eine 'stille Stunde'. Dokumentieren Sie Ihre Entscheidungen, damit Sie nicht die gleichen Fragen, die bei Ihren Projektbetrachtungen auftauchen, unterschiedlich beantworten und damit Sie nachvollziehen können, auf welcher Grundlage Sie diese Entscheidung getroffen haben.

Wir haben nun eine ganze Reihe von Fallen aufgelistet, in die man tappen kann. Wir haben besprochen wie man sie erkennen kann. Was aber tun, wenn Sie feststellen, daß Sie nicht das eine oder andere Problem haben, sondern die gesamte Palette in Ihrem Projekt vorkommt?

Hart auf die Bremse steigen

Wenn Sie in Ihrem laufenden Projekt mehr als ca. 10 Punkte gefunden haben, die auf Schwierigkeiten im Projekt hindeuten, tun Sie sofort etwas. Jeder vertane Tag beim Einleiten von Gegenmaßnahmen kostet Zeit und Geld.

Welche Maßnahmen kann man ergreifen? Hier ist eine Liste von Möglichkeiten. Diese Maßnahmen stellen kein Vorgehensmodell zum Planen eines Softwareprojektes dar, sondern sollen nur Anhaltspunkte liefern, wo Ihre Chancen zum Eingreifen liegen. Einiges davon mag unrealistisch erscheinen, einiges völlig unmöglich. Aber bedenken Sie: wenn Sie nichts tun, kann Ihr Projekt scheitern.

1.      stoppen Sie die Entwicklung

2.      werfen Sie den Zeitplan weg

3.      diskutieren Sie alle Designentscheidungen, Features und Implementationen

4.      prüfen Sie die Durchführbarkeit des Projektes

5.      starten Sie Nachverhandlungen über Features, Spezifikationen und Zeitplan

6.      finden Sie heraus, auf welchem Stand die Implementation der unbedingt notwendigen Features ist

7.      stellen Sie eine Prioritätenliste auf

8.      erstellen Sie einen neuen Zeitplan

9.      veröffentlichen Sie den Zeitplan

10.  setzen Sie den neuen Plan um.

OO als psychologische Herausforderung

"Nur Optimisten können komplexe Systeme bauen."
Optimismus kann aber auch über Gefahren, die definitiv vorhanden sind, hinwegtäuschen.

Alle Probleme, die in diesem Beitrag aufgelistet sind, können in OO-Projekten auftauchen und tauchen auch auf. Die Entwicklung von Software wird immer komplizierter und teurer und damit auch risikoreicher, aber auch faszinierender. Wenn Sie das als Chance annehmen, werden Sie sich ungeahnte neue und interessante Arbeitsfelder erschließen. Dazu gehören definitiv auch psychologische Aspekte, denn OO-Projekte lassen sich vernünftig nicht mehr im 1-Mann-Team bewältigen.

Softwareentwicklung hat heutzutage viel mehr damit zu tun, daß man sich klar macht: was will ich, wann will ich es und was bin ich bereit, dafür zu investieren? Es kommt in modernen Softwareprojekten in Relation zur Gesamtzeit viel weniger darauf an, den 562ten Programmiertrick zu finden und ihn anwenden können, sondern darauf, ein Projekt gemanagt zu bekommen.

Bibliographie

Brooks, The Mythical Man Month, Addison-Wesley, 1979

Gilb, Principles of Software Engineering Management, Addison-Wesley, 1988

Maguire, Debugging The Development Process, Microsoft Press, 1994

Oestereich, Objektorientierte Softwareentwicklung mit UML, Oldenbourg 1997

Page-Jones, Praktisches DV-Projektmanagement, Hanser,1991

Pagel/Six, Software Engineering, Addison-Wesley, 1994

Pigoski, Practical Software Maintenance, Wiley, 1996

Webster, Pitfalls of Object-Oriented Development, M&T, 1995

Yourdon, Objektorientierte Analyse, Prentice Hall, 1994

Yourdon, Death March Projects, Prentice Hall, 1997

-------------------------------------------------------------------------------------

Alf Borrmann
denk-modell Software
An der Oberpforte 2
55128 Mainz
Tel. 06131-794518
Alf.Borrmann@denk-modell.de