Systematische Softwareentwicklung

2.3Meine Vorgehensweise

„Es ist ein Vorteil im Leben, die Fehler, aus denen man lernen kann, frühzeitig zu machen"
(Sir Winston Churchill)

Wie Sie schon an der Struktur dieser Site sehen, setze ich im Vertriebsgespräch mit einer Diskussion der Anforderungen an und biete dem Kunden eine kurze kostenpflichtige Pre-Analyse an. Diese ergibt ein grobes Bild über den zu betreibenden Aufwand, liefert mir einen ersten Einblick in das Unternehmen des Kunden und führt zu der Entscheidung über die Machbarkeit. Am Ende der Pre-Analyse-Phase steht eine Grobspezifikation (früher "Lastenheft" genannt) des zu erstellenden Systems.

Auch die Analyse biete ich in aller Regel zum Festpreis an, so dass sich der Kunde über den Aufwand möglichst klar ist. Die Analyse ist per Definition unvollständig, schafft aber genug Sicherheit für ein präzises Angebot, für eine Zeitabschätzung, für einen Releaseplan der Funktionsblöcke und für die Skizzierung des geplanten Produkts. Häufig soll am Ende der Analysephase auch eine vollständige Feinspezifikation (früher "Pflichtenheft" genannt) des zu erstellenden Systems stehen, also eine Beschreibung darüber, wie das System exakt aussehen wird und was es wie genau leisten wird. Oft macht eine vorläufige Aufwandsabschätzung nach der Hälfte der Analysezeit Sinn. Nach der Analysephase kenne ich jedenfalls definitiv die Fachlichkeit des Kunden und kann die Widerspruchsfreiheit der Anforderungen gewährleisten. Dadurch, dass der Kunde bei der Analyse sehr viel Zeit für Interviews zur Verfügung stellt, kann auch die Vollständigkeit und fachliche Fehlerfreiheit gewährleistet werden.

In der Designphase erfolgt das technische Design der Architektur der Software, d.h. die Klassenhierarchie, das ER-Modell, die Verteilung der Komponenten innerhalb der Server-Farm und schließlich auch die Struktur der Clients. Der Designer gewährleistet die Implementierbarkeit der erstellten Analyse und Spezifikation. Die Implementierung ist schließlich die Umsetzung in die physikalische Technik, d.h. die Generierung der Tabellen in der Datenbank, die Programmierung mit der gewählten Sprache und die Gestaltung des GUI (Graphical User Interface, deutsch: Graphische Benutzerschnittstelle).

Tests erfolgen immer, wirklich andauernd! Bereits mit dem Zielsatz kann der Name der Software auf seinen Bezug getestet werden, mit der Pre-Analyse wird das Fachkonzept getestet, mit der Analyse die ersten Strukturen aus der Pre-Analyse, etc. etc. etc. Der letzte Test erfolgt nach dem Übergang der Software in das Echtsystem des Kunden durch die Anwender. Die bei der Abnahme anhand des Analysedokuments festgestellten und im Laufe des Betriebs auftretenden Mängel werden unverzüglich in der Wartungsphase behoben. Hier werden auch in Folgeversionen die aufgeschobenen Wünsche realisiert.

Ein wesentlicher Vorteil der iterativ inkrementellen Arbeitsweise wird von Siebel in [B19] sehr schön mit diesem Spruch ausgedrückt: "Get it in the water now - launch and learn; it's better to float something than to have a perfect vessel in drydock" (dt. "Bring es nun ins Wasser - starte und lerne; es ist besser irgendwas zu fluten als ein perfektes Schiff im Trockendock zu haben"). Das soll nicht heißen, dass man jeden Quark ungetestet auf den Markt werfen soll, denn das sind dann "banana products" (das Produkt reift beim Kunden), aber man soll auch nicht warten bis das Produkt zwar perfekt, aber dafür veraltet ist und die Firma zwischendurch vielleicht schon ausgehungert ist.

2.4UML

"Ein Bild sagt mehr als tausend Worte."
(Deutscher Volksmund)

Die "Unified Modeling Language" (dt.: "vereinheitlichte Modellierungssprache", UML [L11]) wurde von der Object Management Group (OMG [L3]) am 17.11.1997 in der Version 1.1 als Standard verabschiedet. Die UML bietet Möglichkeiten, um von der ersten Aufnahme eines Geschäftsprozesses über die Analyse von Anwendungsfällen bis zum Entwurf von Klassendiagrammen und Aktivitätendiagrammen lückenlos graphisch arbeiten zu können. "Zur Zeit sprechen alle Anzeichen dafür, dass die UML die Notation der Zukunft für die Objektorientierung wird." [B7]. Ein UML-Beispiel haben Sie bereits auf der vorherigen Seite am rechten Rand gesehen.

Der Vorteil von der Anwendung der UML liegt in der graphischen Notation. Im Gegensatz zu einem Prosatext, den Sie nur von links oben nach rechts unten lesen können, haben Sie bei vielen Diagrammformen die Möglichkeit, an mehreren Stellen einzusteigen und das Diagramm in verschiedene Richtungen zu diskutieren. Statt sequentiell kann hier flächig gedacht, diskutiert und gearbeitet werden. Vielleicht haben Sie selbst schon einmal am Flipchart die Erfahrung gemacht, dass die Entwicklung einer Mindmap viel einfacher ist als die Entwicklung einer Liste. Falls nicht, kann ich es Ihnen nur empfehlen. Wir sind zwar alle durch unsere schulische Ausbildung dazu verzogen, mit einem Stift auf dem Papier einen Aufsatz, ein Diktat, eine Übersetzung, eine Liste oder gar einen mathematischen Beweis von links oben nach rechts unten aufzuschreiben, aber wenn Sie sich davon testweise lösen können, um mal in einer Form zu notieren, wie Gehirnforscher sie als passender für uns herausgefunden haben, werden Sie es vielleicht mögen. Oben sehen Sie, wie ich das Inhaltsverzeichnis dieser Abhandlung als Mindmap entwickelt habe - es gibt natürlich auch längst Software dafür [L18].

Die Mindmap ist kein Diagrammtyp der UML, aber die graphische Denk- und Arbeitsweise haben beide gemeinsam. So können Sie bei der Sammlung der Anforderungen in Kundengesprächen durch Notieren der Gedanken in einer Mindmap auf dem Whiteboard bereits eine erste Struktur in die Gedanken bringen und Schwerpunkte erkennen. Oft ergibt sich sogar schon eine mehrstufige Hierarchie. Sie können natürlich zusätzlich aufschreiben, welcher Gedanke von wem kam. Nach Diskussionen können Sie einige der notierten Gedanken an den Ästen vielleicht direkt schon mit "IN" oder "OUT" kennzeichnen, weil schon definitiv abgegrenzt werden kann, ob diese Anforderungen abgedeckt werden sollen oder nicht. Und Sie werden sehen, dass Sie noch immer den Überlick behalten (zumindest, wenn Sie etwas großzügiger gezeichnet haben).

Von dieser Mindmap können Sie direkt ein "Purpose and Scope"-Diagramm ableiten, in dem die Akteure des geplanten Systems als Strichmännchen eingezeichnet werden und deren Anforderungen an das System mit Pfeilen dargestellt werden. Damit kann halt der Zweck des Systems und auch die Tragweite des Systems im Unternehmen sehr schön dargestellt werden. Dies ist bereits ein UML-Diagramm und die Erstellung am PC wird von vielen Tools unterstützt. Daraus können auch direkt Fälle abgeleitet werden, für die das System angewendet werden soll, sogenannte "Anwendungsfälle", die in eine Kopie des soeben geschilderten Diagramms eingezeichnet werden können. Aus einer Hierarchie der Anwendungsfälle können erste Menüstrukturen entstehen. Hier werden auch die Teilziele des neuen Systems fixiert. Aus dem Anwendungsfalldiagramm kann in einer weiteren Iteration in der Designphase durch ergänzende Informationen aus dem Prototypen und dem Prosatext eine erste Klassenstruktur abgeleitet werden, die in eine echte Klassenhierarchie weiter entwickelt werden kann. Darin kann eine Klassifizierung der Klassen vorgenommen werden, wodurch sich die Verteilung der Komponenten auf die "tier" (dt.: etwa "Schichten" oder "Säulen") ergibt. Dadurch entsteht ein erster Architekturentwurf. All diese Diagramme können mit der UML-Notation erstellt werden und teilweise ineinander überführt werden.

So unterstützt uns die graphische Notation der UML von der ersten Ideensammlung bis hin zur fertigen Klassenhierarchie und weiter. Dies kann zur Zeit kein Prosatext, kein Prototyp, keine Programmiersprache und kein anderes Instrument leisten, weil diese immer nur bestimmte Phasen der Entwicklung abdecken. Aber gerade deshalb sind sie zur Ergänzung auch so wichtig, weil ein UML-Diagramm nämlich wiederum nicht einen Prosatext oder einen Prototyp oder die Programmierung ersetzen kann. UML formuliert den roten Faden durch den gesamten Entwicklungszyklus und sollte auch genau so gesehen werden. Es ist kein Allheilmittel, es ist nichts, was man ausschließlich einsetzen sollte und es löst nicht alle Probleme. Es ist lediglich eine Sprache, mit der man sehr viele Aspekte des Entwicklerlebens darstellen und ineinander überführen kann - Punkt.

Es gibt zahlreiche Bücher, die UML verheiligen und die Bedeutungen der graphischen Symbole bis ins letzte Detail auf vielen hundert Seiten erläutern, aber finden Sie mal ein Buch, welches Ihnen an praktischen Beispielen verrät, wann Sie welches Diagramm wie einsetzen sollten und vor allem: Wie kommen Sie mit den Diagrammen von einer Phase oder Iteration zur nächsten? Wie ein Anwendungsfalldiagramm aussieht, können Sie nachlesen, wie ein Klassendiagramm aussehen sollte, finden Sie an jeder Ecke; aber wie überführen Sie beispielsweise als Designer oder Entwickler ein Anwendungsfalldiagramm, das von einem Analytiker mit Fachleuten zusammen entwickelt wurde, in ein Klassendiagramm? Und ich rede hier gar nicht mal von Software-Tools! Und dann kommt das spannende Thema "Reverse-Engineering", also die Rückwärtsentwicklung: Angenommen, ein Entwickler stellt bei der Implementierung einen Widerspruch fest (was ja durchaus vorkommt) und ist tatsächlich so offen, kommunikativ und weitsichtig, dieses seinem Designer anzuzeigen. Wie wird das ins Klassendiagramm integriert, um es ins Anwendungsfalldiagramm zurück zu übertragen und in den Prosatext und Prototypen einzubringen, um es dann mit dem Kunden zu diskutieren? Da wird die Luft schnell dünn! Ich werde in dieser Abhandlung einige dieser Aspekte abdecken, da ich selbst schon häufig in verschiedenen Projektrollen vor diesen Problemen stand und dafür auch gemeinsam mit meinen jeweiligen Teams Lösungen entwickeln konnte.

Wenn Sie jetzt nicht alles direkt nachvollziehen konnten, ist das überhaupt nicht schlimm, denn wir sind ja hier im Kapitel "Vorgehensweise", wo ich zunächst nur einmal einen Überblick über die Ausgangssituation, die Aufgabenstellung sowie meinen praktischen Weg gebe. Genauer: wir sind hier auf einer Seite, auf der ich den Sinn und Unsinn von UML ganz kurz abgrenze, weil das Thema einfach nach wie vor mega-hip ist. In den nächsten Kapiteln wird Alles nach und nach verfeinert und - soweit unsere Kunden einverstanden sind - mit Beispielen belegt.

Sie finden übrigens alle Originaldokumente zur UML bei der OMG selbst [L11]. Falls Sie statt der Online-Spezifikation ein echtes Buch aus echtem Papier bevorzugen, empfehle ich [B2] und [B13]. Die UML hängt immer stark mit den "drei Amigos" der Firma Rational [L7] zusammen, weil diese den Vorschlag über mehrere Jahre ausgearbeitet und bei der OMG zur Standardisierung eingereicht haben. Mittlerweile ist Rational von IBM übernommen worden. Ich kann Ihnen übrigens nur wärmstens den monatliche Report "The Rational Edge" [L19] empfehlen.