[ 1 ] [ 2 ]
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.
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 Design erfordert dann noch folgende Spezifikationen:
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.
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.
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.
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.
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:
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.
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.
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!
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.
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:
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.
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 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:
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.
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:
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.
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:
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?
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.
„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.
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
[ 1 ] [ 2 ]