Download doc - Systematische Softwareentwicklungftp.diebuerger.de/sse/Inhalt/Systematische... · Web view"Mit dem PC lösen wir die Probleme, die wir ohne nicht hätten." (Unbekannt) Wer sollte

Systematische Softwareentwicklung(C)opyright Ralf Bürger 2001-2003

"Viele möchten in einem Tag verschlingen,was sie kaum im ganzen Leben verdauen können"

(Balthasar Gracián)

Systematische Softwareentwicklung

Inhalt

1 Einführung........................................................................................................................................41.1 Vorwort.....................................................................................................................................41.2 Zielgruppe.................................................................................................................................51.3 Konventionen............................................................................................................................61.4 Download..................................................................................................................................71.5 Änderungen..............................................................................................................................8

2 Vorgehensweise..............................................................................................................................102.1 Systematik..............................................................................................................................102.2 Modelle...................................................................................................................................122.3 Meine Vorgehensweise...........................................................................................................152.4 UML.......................................................................................................................................162.5 Wozu MS-Project?.................................................................................................................18

3 Anforderungen................................................................................................................................203.1 Funktionale Anforderungen....................................................................................................203.2 Technische Anforderungen.....................................................................................................203.3 Anforderungen fixieren..........................................................................................................21

4 Pre-Analyse....................................................................................................................................224.1 Projektmappe..........................................................................................................................224.2 Verantwortung........................................................................................................................224.3 Name und Hauptziel...............................................................................................................234.4 Zweck und Tragweite (engl. "Purpose & Scope")..................................................................234.5 Prosatext.................................................................................................................................254.6 Was also ist die Pre-Analyse?................................................................................................264.7 Geschäftsprozesse...................................................................................................................274.8 Angebote und Verträge...........................................................................................................28

5 Analyse...........................................................................................................................................305.1 Analyseaspekte.......................................................................................................................305.2 In/Out-Liste............................................................................................................................315.3 Protokolle................................................................................................................................315.4 Interviews...............................................................................................................................325.5 Problemzerlegung...................................................................................................................33

5.5.1 Hierarchisierung.............................................................................................................345.5.2 Modularisierung..............................................................................................................345.5.3 Strukturierung.................................................................................................................34

5.6 Analysemuster (engl. analysis patterns).................................................................................355.7 Anwendungsfälle....................................................................................................................355.8 Spezifikationsmuster..............................................................................................................37

5.8.1 Spezifikationsmuster zur Ablaufsteuerung.....................................................................375.8.2 Spezifikationsmuster zur Inhaltssteuerung.....................................................................415.8.3 Weitere Gedanken..........................................................................................................45

5.9 Prototyp..................................................................................................................................465.10 Testfälle..................................................................................................................................47

2


5.11 Dokumente..............................................................................................................................475.12 Gesamt-Anwendungsfalldiagramm........................................................................................48

6 Design.............................................................................................................................................496.1 Realisierung............................................................................................................................496.2 Kick-Off-Meeting...................................................................................................................496.3 Architekturen..........................................................................................................................50

6.3.1 MVC Paradigma.............................................................................................................506.3.2 n-tier-Model....................................................................................................................516.3.3 MDA...............................................................................................................................54

6.4 Design der Modelle................................................................................................................546.4.1 Klassenmodell................................................................................................................556.4.2 Datenmodell....................................................................................................................55

6.5 Design Patterns.......................................................................................................................596.6 Software Ergonomie...............................................................................................................60

7 Implementierung.............................................................................................................................617.1 Implementierungsaspekte.......................................................................................................617.2 Codierung...............................................................................................................................617.3 Leitung....................................................................................................................................627.4 Iterationen...............................................................................................................................647.5 Änderungsanforderungen.......................................................................................................64

8 Test.................................................................................................................................................668.1 Warum testen?........................................................................................................................668.2 Testen bis zum jüngsten Tag..................................................................................................678.3 Weiche Tests...........................................................................................................................688.4 Systematische Tests................................................................................................................698.5 Qualität...................................................................................................................................73

9 Übergang........................................................................................................................................749.1 Übergang der Software an den Kunden..................................................................................74

10 Wartung......................................................................................................................................7510.1 Wartung..................................................................................................................................75

11 Verweise.....................................................................................................................................7611.1 HTTP-Links............................................................................................................................7611.2 Bücher.....................................................................................................................................77

12 Anlagen.......................................................................................................................................7912.1 Hütchenspiel...........................................................................................................................79

13 Index...........................................................................................................................................84

3


1 Einführung

1.1 Vorwort"Ich sage, was ich denke, damit ich höre, was ich weiß."(Unbekannt)

Ich habe im Laufe der letzten 20 Jahre schon viele Projekte und viel Software gemacht und sehr viel mit Kunden, Projektmitarbeitern und Kursteilnehmern über die "richtige" Vorgehensweise bei der Softwareentwicklung diskutiert. Nun fange ich doch tatsächlich auch mal damit an, meine Erfahrungen und meine Meinung aufzuschreiben. Es gibt zwar schon so einige Bücher zur Software-Entwicklung, aber die Branche ist noch immer sehr jung und es gibt noch viel Handlungsbedarf zur Weiterentwicklung der Systematik. Mein persönlicher Schwerpunkt liegt eindeutig bei den ersten Phasen eines Software-Projekts - der Rest ist für mich nur technische Realisierung, die sich im Laufe der Jahre zunehmend vereinfacht hat und in Zukunft auch recht stark automatisiert werden wird. Wenn erst einmal klar ist, was wie gemacht werden soll, dann ist die Umsetzung kein unüberwindbares Problem mehr - daher sind die ersten Projektphasen einfach die wichtigsten.Ein Mini-Beispiel für all das, was ich hier schreibe, ist ein kleines Hütchenspiel, dessen Beschreibung und Code Sie in der Anlage finden.Momentan ist dieses Dokument noch in großen Teilen eine Stichwortsammlung, aber der Umfang nimmt (fast) täglich zu. Feedback heiße ich jederzeit sehr willkommen, also scheuen Sie sich bitte nicht: [email protected]

rabu - 23.12.2001

An dieser Stelle einen herzlichen Dank an die Kunden, die mir gestatten, einen Teil unserer gemeinsamen harten Arbeit als Beispiele zu verwenden.

rabu - 21.05.2003

4

mailto:[email protected]?subject=Feedback%20zur%20Systematischen%20Softwareentwicklung


1.2 Zielgruppe"Mit dem PC lösen wir die Probleme, die wir ohne nicht hätten."(Unbekannt)

Wer sollte diese Abhandlung lesen? Nun, momentan tun Sie es! Das ist auf jeden Fall schon einmal gut, denn Sie scheinen sich für Softwareentwicklung zu interessieren. Welche Aufgabe Sie bei der Softwareentwicklung übernehmen, ist dabei egal, denn ich versuche, den gesamten Entwicklungsprozess abzudecken.Es ist keinesfalls erforderlich, die gesamte Abhandlung auf einmal zu lesen - oder überhaupt ganz zu lesen -, denn ich bemühe mich, sehr kompakt zu schreiben und möglichst viel für Sie hinein zu packen. Ich habe halt nicht vor, ein möglichst dickes Buch zu schreiben, damit ich es möglichst teuer verkaufen kann. Lesen Sie einfach mal hinein, nehmen Sie einen Tipp auf, setzen ihn um und schon sind Sie ein Stück weiter gekommen (falls nicht, lassen Sie es mich bitte wissen, damit ich den Tipp ändern kann). Diese Arbeitsweise ist in der Regel effizienter, als 1000 Seiten auf einmal zu lesen oder ins Regal zu stellen. Wenn Sie aber ganz ganz ganz viel lesen möchten, kaufen Sie alles, was Sie an Büchern im Kapitel „11 Verweise“ finden, lesen das alles durch, setzen es in die Praxis um und schicken mir dann ein paar weitere Tipps ;-)

5


1.3 Konventionen"Entweder man lebt, oder man ist konsequent."(Erich Kästner)

Mit "Anwender" meine ich natürlich auch immer "Anwenderin", ich sollte also eigentlich besser immer "AnwenderIn" schreiben. Gleiches gilt natürlich bei Programmierern, Analytikern, Leitern und allen anderen Personengruppen. Dies ist dann aber im weiteren Verlauf lästig, weil es dann auch immer "sie/er" oder "ihr/ihm" heißen muss. Es geht mir hier im Wesentlichen darum, gewisse inhaltliche Aussagen zur systematischen Softwareentwicklung herüber zu bringen. Daher gestatten Sie mir bitte, dass ich immer nur in einer Form zu formulieren brauche. Da ich es in meinem Job leider fast nur mit Männern zu tun habe, fiel meine Entscheidung auch zugunsten der männlichen Form. Also "Anwender" - basta!Wenn etwas wie auf Papier gedruckt, nach Quelltext oder wie an Command-Line eingetippt aussehen soll, sehen Sie diese nichtproportionale Schreibmaschinen-Courier-Schriftart.Die auf dieser Seite geschilderten Konventionen wende ich konsequent in der gesamten Abhandlung an, aber ich hoffe dennoch, dass ich lebe (s. Spruch oben).

6


1.4 Download"Free as a bird."(Simon Phipps über Open Source)

Sie haben diese Abhandlung über "Systematische Softwareentwicklung" heruntergeladen und vielleicht sogar gedruckt, weil Sie sie lieber mit zum Kunden nehmen möchten, im Garten oder auf dem Klo lesen möchten oder auch einfach nur mit einem Textmarker drin rummalen möchten. Da sich im Ausdruck immer noch eine Serifenschrift besser liest, habe ich das Dokument dafür auf Times New Roman umgestellt. Ferner gibt es - wie Sie bereits festgestellt haben – in der Download-Version ein Inhaltsverzeichnis mit Seitennummern statt Links und einen kleinen Index. Ich finde das Online-Lesen generell praktischer wegen der Links und der ständigen Aktualität (ich arbeite an dieser Abhandlung selbst auch Online und übernehme ab und zu die Änderungen in die Offline-Dokumente), aber ich akzeptiere es, wenn mich auch heute noch viele IT-ler fragen: "Hast du das auch in einer druckbaren Version?"Wenn Sie Teile meiner Abhandlung für Artikel oder Präsentationen oder was auch immer verwenden möchten, können Sie das gerne tun. Geben Sie mir bitte kurz per eMail Bescheid - mich interessiert einfach nur, wer was wofür benutzt. Achten Sie bei Zitaten und Verweisen aber bitte ggf. auf die Rechte Dritter.Ich bin selbst ein großer Befürworter von "Open Source", denn ich weiß, dass "Open" (Offen) in Wirklichkeit eher "Free" (Frei) bedeutet, und zwar "Free" wie in "Free as a bird" ("Frei wie ein Vogel"). Sie können die Quellen von Programmen vielleicht frei bekommen, aber wenn Sie sich in die Quellen einarbeiten möchten, sie anpassen möchten und in Ihr Unternehmen einführen möchten und die Daten Ihres Altsystems dahin übernehmen möchten (jedes Unternehmen hat heute bereits für alle zentralen Funktionen ein Altsystem), dann wird das richtig teuer. Eine Migration ist in aller Regel nicht ohne professionelle Hilfe möglich. Man kann also sehr wohl auch mit all dem Open-Zeug Geld verdienen. Nämlich nicht, indem man auch so was programmiert und zu verkaufen versucht, sondern sich einarbeitet, es unterstützt und den Kunden den Service verkauft.Momentan erfahre ich das aus erster Hand, weil ich mich bei der OpenOffice.org engagiere. Den Ausspruch oben ("Free as a bird") habe ich denn auch einem Gespräch mit Simon Phipps (Chief Technology Evangelist, Sun Microsystems) auf der Konferenz "Linux on Wall Street" im April 2003 in New York entnommen. Sie sehen daran auch, dass sich auch wirklich namhafte Leute für die Open Source Bewegung engagieren.Ich sehe meine Abhandlung über Systematische Softwareentwicklung denn auch als "Open Resource": Ich stelle sie Ihnen kostenfrei zur Verfügung, aber zum Lesen müssen Sie schon Zeit und damit auch Geld investieren. Zum Verstehen und Anwenden sogar noch viel mehr. Um die gleichen Erfahrungen zu machen, wie ich sie gemacht habe, brauchen Sie vielleicht sogar mehrere Projekte über mehrere Jahre. Es kann also auch durchaus sein, dass Sie schnell zu dem Schluss kommen, dass Sie trotz der kostenfreien Verfügbarkeit letztendlich viel sparen können, wenn Sie mich oder einen anderen unserer Software-Architekten beispielsweise als Trainer, Coach, Designer oder Entwickler beauftragen ;-)Sie lesen übrigens die Download-Fassung von 2003-06-19.

7


1.5 Änderungen"Beständig ist nur der Wechsel."(mein Physiklehrer)

Hier eine Liste mit den letzten Änderungen in dieser Abhandlung, damit Sie nicht immer wieder Alles lesen müssen. Die neuesten Änderungen stehen oben, die ältesten unten:

2003-06-08: „Systematische Tests“ gefüllt 2003-06-08: Buch [B24] neu 2003-06-03: „Weiche Tests“ gefüllt 2003-06-02: Link [L20] MDA neu 2003-06-01: „Warum testen?“ und „Testen bis zum jüngsten Tag“ gefüllt 2003-05-25: Zwei Beispiele für statische „Prototypen“ neu 2003-05-25: Assistentenseite bei den „Anwendungsfällen“ neu 2003-05-21: „Analysemuster“ begonnen (mehr durfte ich heute nicht mehr machen) 2003-05-21: Link [L19] neu 2003-05-21: Ok, ok, ab jetzt mit Datum (bis zur CeBIT zurück konnte ich es sogar rekonstruieren) 2003-05-21: „UML“ um Mindmap und mehr erweitert 2003-05-20: Link [L18] neu 2003-05-19: Beim „Design der Modelle“ die Beschreibung der "small diamonds" in Datenmodellen

ergänzt. 2003-05-19: Jede Seite hat jetzt ihren Spruch (damit kann ich mich wieder um die Inhalte kümmern) 2003-05-19: „Design Patterns“ gefüllt. Da mag noch was hinzu kommen, aber die wichtigsten

Verweise stehen drin 2003-05-18: Die „Modelle“ jetzt übersichtlich mit den Erläuterungen auf einer Seite 2003-05-16: Und wieder ein Spruch 2003-05-16: Bei „Konventionen“ den Screenshot mitsamt Erläuterung hinzugefügt und alle

Imagelinks daran angepasst 2003-05-11: Seite „Leitung“ erstellt 2003-05-04: Buch [B22] und [B23] neu 2003-04-30: Download als PDF-Dokument (Danke, André) 2003-04-28: Download als Word-Dokument; gleichzeitig auch das Kapitel Download überarbeitet 2003-04-28: „Konventionen“ erweitert 2003-04-27: Und noch ein, zwei, drei, vier, fünf Sprüche 2003-04-27: Kapitel „Systematik“ überarbeitet 2003-04-26: Und wieder ein Spruch 2003-04-25: Zweites Pre-Analyse-Blatt 2003-04-21: Navigationssymbole oben und unten auf allen Seiten 2003-04-20: Navigationsbaum im linken Frame jetzt ohne Links auf den Kapiteln, nur noch auf den

Seiten 2003-04-20: Kapitelangabe im Balken oben auf den Einzelseiten 2003-04-19: Weitere Sprüche oben auf den Einzelseiten 2003-04-19: Umstellung auf Einzelseiten 2003-04-19: Subdomain sse.RalfBuerger.de etabliert

8


2003-04-05: Navigationsbaum im linken Frame 2003-03-30: Inhaltsverzeichnis um Kurzangaben ergänzt 2003-03-25: Jedes Kapitel hat jetzt oben auf der Seite einen - meines Erachtens - passenden Spruch - Link L17 und Absatz zu SPICE ergänzt - Kapitel Übergang endlich mal angefangen - Buch B21 ergänzt - Datenmodell erweitert um Normalisierung - Neues Diagramm in "Meine Vorgehensweise" - Datenmodell neu - Spezifikationsmuster fertig - Problemzerlegung fertig - Zielgruppe neu - Änderungsanforderungen neu - Download und Konventionen neu - Design erweitert um MVC-Architektur - Analyse erweitert - n-tier-Modell überarbeitet - Kapitel Anforderungen erweitert - n-tier-Modell neu - Weitere Beispiele für MS-Project - Analyseaspekte angefangen - Modelle erläutert, Prosatext überarbeitet und Verantwortung eingefügt. - neue Beispiele für Zweck- und Tragweiten-Diagramme - Ein Vorwort gibt es nun auch - Pre-Analyse fertiggestellt - Pre-Analyse-Blatt neu - Inhaltsseite zu "Systematische Softwareentwicklung" (so heißt es jetzt) - Vorgehensweise: Ein aktuelles Problem - Pre-Analyse: Name und Hauptziel - Vorgehensweise: Sichten-Diagramm - Pre-Analyse: Diagramme und Textänderungen - Vorgehensweise: großes USDP-Diagramm und MS-Project-Screenshot

9


2 Vorgehensweise

2.1 Systematik"Künstliche Intelligenz ist kein Schutz vor natürlicher Dummheit."(Unbekannter)

Im März 1967 erschien im Magazin "Fortune" ein Artikel über den für damalige Begriffe neuartigen Prozess der "Softwareentwicklung". Ein Auszug daraus: "In der Programmierung herrscht nicht annähernd die Disziplin wie beispielsweise in den Naturwissenschaften. Deshalb spielt die Intuition eine große Rolle. Noch unterscheiden sich die Programmierer in ihren kreativen und intuitiven Fähigkeiten." Im Jahre 1968 prägten Softwareprofis auf einer NATO-Konferenz zur Softwareentwicklung den Ausdruck "Softwarekrise" und beschrieben damit Schwierigkeiten bei der Erstellung zuverlässiger Systeme. Ist die Softwarekrise vorüber? Probleme auch aus jüngster Zeit zeigen, dass dies offensichtlich noch immer nicht der Fall ist:

Raumstation ISS nach Computerpanne ins Trudeln geraten4. Feb. 2002Die Internationale Raumstation ISS ist nach einem Computerproblem im russischen Teil des Komplexes ins Trudeln geraten. Für sechs Stunden konnte die Station nicht korrekt gesteuert werden, was zu Problemen bei der Stromversorgung führte, da die Solarzellen nicht auf die Sonne ausgerichtet waren.Wie die Nasa am Montag mitteilte, konnte das Problem von der russischen Bodenkontrolle schließlich gelöst werden. Der fehlerhafte russische Computer, der die Ausrichtung der ISS im All kontrolliert, wurde neu gestartet und arbeitete danach wieder normal, wie es hieß.Text: dpaBildmaterial: Nasa

Die Zeitschrift CIO schreibt in der Ausgabe 6/2002: "Ein Viertel aller Projekte scheitert, die Hälfte hält Zeit- und Budget-Rahmen nicht ein. In den regelmäßigen Befragungen der Standish Group haben sich diese Zahlen bis heute kaum verändert." Am 25.03.2003 gibt die Standish Group bekannt, dass die Fertigstellung der Projekte auf 34% gestiegen ist, eine Verdopplung gegenüber 16% in 1994. Andererseits sind die Projekte mit Zeitüberschreitungen auf 82% gestiegen, gegenüber 63% im Jahr 2000. Und während 2000 noch 67% der angeforderten Funktionalitäten im endgültigen Produkt enthalten waren, sind es jetzt nur noch 52%.Woran liegt das? Es ist sehr schwer, die reale Welt im Computer mit Software nachzubauen, weil dabei alle relevanten Gesetze der realen Welt nachempfunden werden müssen. Das ist stets deutlich aufwändiger, als man zunächst denkt. Wenn man dann noch mit den Schwierigkeiten durch ständige Änderungen an den bei der Entwicklung benutzten Systemen und Tools sowie gänzlich neuen Technologien kämpfen muss und dann noch Probleme im Team auftreten, ist das Projekt kaum noch zu retten. Dann kommen noch die Fehlerbehebungen hinzu und all die Änderungen, die der Kunde noch wünscht. Und wenn man dann vermeintlich fertig ist, weiß man ziemlich genau, welcher

10


unglaublich große Aufwand eigentlich noch ins Projekt gesteckt werden müsste, um alles wirklich wasserdicht zu bekommen. Und dafür hat man nie die benötigte Zeit und das benötigte Geld, weil bis dahin sowieso schon Zeitplan und Budget überschritten sind. Also wird es nicht zeitig fertig, enthält nicht alles, was man wollte, aber dafür wurde es teurer und hat viele Fehler!Das Wesentliche dabei dürfte die Unterschätzung der Komplexität der realen Welt sein. Wenn beispielsweise eine Verwaltungssoftware eines Schlachthofs das Gewicht eines Schlachtviehs über das Wochenende von 450 kg auf 300 kg reduziert hat, so weiß diese Software offensichtlich zwar, dass durch Verdunstung das Gewicht eines Schlachtviehs in der Halle über zwei Nächte am Wochenende stärker abnimmt als über eine Nacht innerhalb der Woche, aber diese Software hat offensichtlich kein Gespür dafür, dass die Reduzierung von 450 kg auf 300 kg bei nur einer weiteren Nacht (und selbst bedingt durch einen Feiertag über zwei weitere Nächte) völlig "unrealistisch" ist. Dieses "Gespür" müsste man eigentlich in Form von teilweise komplexen Plausibilitätsprüfungen an sehr vielen Stellen implementieren, womit sich der Aufwand aber noch mal unerwartet erhöht - zumindest für den Entwickler unerwartet, denn der Mitarbeiter der Firma sagt zu dem ganzen Problem sowieso nur: "Das war doch wohl klar, habt Ihr das etwa nicht berücksichtigt? Das weiß man doch wohl!" (Ich bin diesem Problem übrigens wirklich 1994 bei einem türkischen Fleischgroßhandel in Köln begegnet.)Aber warum kann eine Werft ein 200 Meter langes Kreuzfahrtschiff mit zwölf Decks für 1200 Passagiere und 400 Personen Besatzung rechtzeitig, fehlerfrei, zum vereinbarten Preis und mit allen geforderten Leistungen liefern, und warum geht das bei Software offensichtlich nicht? Ist es schwieriger Software zu schreiben als ein Kreuzfahrtschiff zu bauen? Oder liegt es daran, dass wenige Spezialfirmen wenige Kreuzfahrtschiffe bauen und an jeder Ecke selbsternannte Softwareentwickler sich mit selbst überlegten Methoden an zu großen Softwareprojekten versuchen? Auch wenn man den Aufwand für die Entwicklung gigantisch hochschraubt und tatsächlich keine Rücksicht auf Zeit und Geld nehmen muss, wird Software nie fehlerfrei! Dieses haben unzählige wirklich große unternehmenskritische Projekte gezeigt. Liegt es vielleicht doch daran, dass man Software nicht anfassen kann und mehrere Entwickler gemeinsam an einem virtuellen Gebilde arbeiten, während man ein Kreuzfahrtschiff modular aus realen Bausteinen zusammensetzt? Kann man tatsächlich das Problem der Software-Fehler auf folgende einfache Formel reduzieren: "Software hat Fehler, weil sie aus Logik besteht." [B4].Was können wir tun, um bei der Softwareentwicklung Fehler zu vermeiden oder zumindest möglichst früh zu finden und die Entwicklung von Software und damit die Software selbst robuster zu gestalten? Und wie können wir Software-Projekte vorhersehbarer, kalkulierbarer und damit planbarer gestalten? Betrachten wir doch mal die Definition für "Software-Engineering" (deutsch: "Software-Technik") vom ANSI-Komitee [L14]: "The systematic approach to the development, operation, maintenance and requirement of software." (deutsch: "Der systematische Ansatz für die Entwicklung, den Betrieb, die Wartung und die Anforderung von Software.")Ich denke, die meisten Softwareentwickler sollten überhaupt erst mal die erprobten und bewährten systematischen Ansätze kennen lernen und auch anwenden. Das würde vielen Projekten und damit auch den Statistiken schon mal sehr gut tun. Denn die einfacheren Projekte werden naturgemäß auch von den unerfahrenen Leuten abgewickelt, die sich noch gar nicht mit Systematischer Softwareentwicklung beschäftigt haben und deshalb auch nicht professionell mit diesem "virtuellen Gebilde" umgehen können. Die großen, wirklich komplexen Projekte scheitern wohl wirklich daran, dass es in just diesen Projekten immer noch zu wenig verfügbare Erfahrung, zu wenig Standards, zu wenig anerkannte Schnittstellen für die Umsetzung des jeweiligen Stücks der realen Welt gibt. Es gibt beispielsweise noch nicht so viele internationale Flughäfen mit vollautomatisiertem Gepäckbeförderungssystem und erst recht gibt es noch nicht viele Entwickler, die dieses komplexe Projekt schon mehrfach abgewickelt haben. Auch die Technologien, die dort zum Einsatz kommen, sind teilweise noch keine 15 Jahre alt. Die wirklichen Professionals können meines Erachtens nur durch viele viele Projekte der gleichen Komplexität sowie eine evolutionäre Verbesserung der bestehenden, angewandten, systematischen Ansätze dem Ziel näher kommen, ein Softwareentwicklungsprojekt rechtzeitig, im Kostenrahmen, fehlerfrei, vollständig und zur Zufriedenheit des Kunden abzuschließen!

11


2.2 Modelle"Manche leben mit einer so erstaunlichen Routine, dass es schwerfällt zu glauben, sie lebten zum ersten mal."(Stanislaw Jerzy Lec)

Betrachten wir doch zunächst mal einige Beispiele aus der evolutionären Entwicklung der Modelle, nach denen Software entwickelt wurde bzw. wird.

Beim "Wasserfall-Modell" werden alle Schritte, die bei einem Softwareentwicklungsprojekt erforderlich sind, nacheinander

durchlaufen. Im ersten Augenblick scheint dies vernünftig und richtig zu sein, bei weiterem Nachdenken (oder Ausprobieren) stellt man

jedoch fest, das es sich bei dem Wasserfall-Modell um eine Idealisierung handelt. Kein Projekt läuft wirklich so ab!

"Aber sobald mit der Umsetzung begonnen wird, zeigt sich irgendwo eine Unstimmigkeit, die sich mit der

Spezifikation nicht klären lässt. Ein praktisch denkender Mensch würde jetzt vielleicht einfach den Kunden

anrufen und ein paar Fragen stellen, was aber peinlich ist, wenn der Kunde bereits eine Rechnung über »1 Stck. Vollständige Leistungsbeschreibung« erhalten hat." [B4]

Erst am Ende der Entwicklung wird getestet, d.h. das wahre Ende des Projekts ist terminlich nicht vorhersehbar, weil kein Mensch ahnen kann, wie viele Fehler auftreten werden und wie lange deren Korrektur dauern wird. Dieses Modell hat Ähnlichkeiten mit einem echten Wasserfall, der das Wasser (in unserem Fall die Probleme) von Stufe zu Stufe weiter reicht und am Ende in einem See sammelt.

Das "V-Modell" ist eine Fortentwicklung des Wasserfall-Modells und berücksichtigt das Testen in allen Phasen, um die Überraschung

am Ende zu vermeiden. Die Erfahrung hat jedoch gezeigt, dass die Überraschung nicht

einfach durch intensivere Tests zu vermeiden ist, weil der Umgang mit

Änderungsanforderungen (engl. "Change Requests") während der Entwicklung damit nicht

abgedeckt wird.

Das "Spiral-Modell" von Barry Boehm ist quasi ein mehrfacher Wasserfall, bei dem Analyse, Entwurf, Codierung und Test mehrfach hintereinander durchlaufen werden. Dies ermöglicht eine schrittweise Verfeinerung der Software durch mehrstufige Implementierung der Funktionalität. Da die Analyse mehrfach erfolgt, können Änderungsanforderungen (engl. "Change Requests") bei diesem Modell besser berücksichtigt werden. Außerdem wird dabei mehrfach getestet, wodurch die Problematik des Wasserfall-Modells durchaus entschärft wird. Am Ende der Spirale steht das Idealprodukt.Das "Prototypen-Modell" heißt auch Casey-Modell, womit ein junger Entwicklungsleiter geehrt wird. Dieser kam auf die Idee, einen Prototypen zu bauen, der bereits die gesamte Funktionalität enthält, aber nicht getestet ist, keine Hilfen und keine Plausibilitätskontrollen sowie keine Fehlerbehandlung enthält, weder kommentiert noch

12


dokumentiert ist und auch unter optischen Aspekten völlig anspruchslos ist - also noch kein Produkt ist!

Es geht ganz einfach darum, möglichst schnell ein Stück Software zu haben, das dem Kunden als Basis für weitere Diskussionen dienen kann und den Entwickler spüren lässt, wo die größten technischen Probleme verborgen sind. Ein Prototyp zeigt sehr deutlich, ob der Anbieten seinen Kunden verstanden hat und der Kunde wirklich weiß, was er will.Heute ist das Prototypen-Modell weiter entwickelt und erzeugt evtl. sogar ein Pilotsystem, das mit den Anwendern des Kunden getestet werden kann. Parallel dazu erfolgt heute auf jeden Fall die Entwicklung des Echtsystems nach einem anderen Modell, denn der Prototyp wird halt weggeworfen (schließlich ist es ein Prototyp und kein Echtsystem!). Mehr zur Prototypen-Entwicklung in meinem Kapitel Prototyp.

Die Modelle "USDP" ("Unified Software De-velopment Process") bzw. "RUP" ("Rational Unified Prozess") gehen auf die drei Amigos Grady Booch, Jim Rumbaugh und Ivar Jacobson von der Firma Rational Software [L7] zurück. Grady Booch ist der Papst der Objektorientierung und Ivar Jacobson der Vater der Anwendungsfälle. In Deutschland ist die Firma oose [L4] ("OOSE" = Object Orientied Software Engineering) rund um Bernd Oesterreich sehr aktiv in der Verbreitung des objektorientierten Ansatzes.Beim USDP-Modell stelle ich gerne die

Unterscheidung zwischen der Managementsicht und der technischen Sicht gemäß nebenstehendem Diagramm heraus: Die Managementsicht besteht aus Projektphasen mit Meilensteinen für Konzept, Entwurf, Konstruktion und Übergabe. Die technische Sicht besteht aus Prototypen und Produktversionen. Bei jeder Versionsstufe werden die Prozesse Anforderung, Analyse, Design, Implementierung und Test durchlaufen (iterative Vorgehensweise). Das Produkt wächst dadurch inkrementell in seinem Leistungsumfang.Es wird dabei gerne auch vom "Lebenszyklus" des Software-Entwicklungsprojektes gesprochen (engl. "Software Development Life Cycle"). Die vier Phasen werden von Rational als "Etablierung" (engl. "Inception"), "Ausarbeitung" (engl. "Elaboration"), "Konstruktion" (engl. "Construction") und "Übergang" (engl. "Transition") bezeichnet.

Ich meine, dass dieses Modell sehr gut um weitere Sichten (Rollen) des Projekts ergänzt werden kann, denn neben der technischen Versionssicht und der Management-Phasensicht gibt es mindestens noch eine Produktsicht, die für Marketing, QS, Training und Support relevant ist, sowie eine kaufmännische Sicht (Verträge, Zahlungen und Strafen), die für den Vertrieb sehr wichtig ist.

13


Sie können an der Breite der Dreiecke sehen, welche Prozesse wie intensiv iteriert werden. So reicht die Konzeptphase der Projektleitersicht beispielsweise vom Anforderungsprozess bis zum Designprozess, wobei ein Schwerpunkt auf dem Anforderungsprozess liegt. Die Version 1.0 der

Marketingsicht hingegen hat ihren Schwerpunkt bei der Übergabe.

FazitIm Prinzip war das Wasserfallmodell gar nicht so verkehrt, denn es ist sicherlich immer gut, einen Schritt nach dem anderen zu tun (auch wenn es heute modern zu sein scheint, alles auf einmal zu versuchen (wobei bekanntermaßen ohnehin nur Frauen mehrere Dinge gleichzeitig tun können)). Ein ganzes Software-Projekt strikt stufig durchzuführen geht aber auf jeden Fall schief. Wie ist es denn bei einem echten Wasserfall? Am Ende wird man doch nass, oder? Im Ernst: Das Problem beim Wasserfallmodell ist, dass man am Anfang noch gar nicht alle Eventualitäten abschätzen kann, während der Entwicklungszeit viele neue Änderungsanforderungen (Change Requests) eintreten und am Ende weder zeitlich ("in time") noch preislich ("in budget") noch qualitativ ("in quality") das herauskommt, was sich der Auftraggeber vorgestellt hat. Damit ist der Ärger vorprogrammiert.Zerteilt man das Software-Projekt in viele Phasen, durchläuft jede Phase stufig und bezieht den Kunden (auch dessen Anwender!) in jeder Phase mit ein, so sieht es schon viel besser aus, weil jede einzelne Phase abschätzbar wird und Änderungen sowie bekannt gewordene Details nach jeder einzelnen Phase in die Planungen integriert und getestet werden können. Diese Vorgehensweise wird heute als "iterativ inkrementell" bezeichnet, weil das Produkt in vielen schleifenähnlichen Durchläufen von Version zu Version vollständiger wird.Übrigens können die Prozesse selbst auch noch in Teilprozesse unterteilt werden, die dann wiederum für eine gewisse Zeit iterativ inkrementell innerhalb des Prozesses durchlaufen werden. Die Analyse kann beispielsweise sehr wohl durch verschiedene Sichten und Detaillierungsgrade in mehreren interativen Schritten inkrementell erstellt werden. Wenn Sie die Entstehung dieser Abhandlung betrachten, so stellen Sie fest, dass ich eine gewisse Zeit lang Stichworte sammel und verteile, Sprüche hinzufüge, Graphiken und Diagramme ergänze, Mengen in Einzelseiten aufteile, eine Seite dann erst als durchgehenden Prosatext formuliere und irgendwann nochmal eine Überarbeitung fahre. So sind

14


einige Seiten offensichtlich schon fertig, während in manchen Kapiteln erst eine einzelne Seite mit Stichworten existiert. Da ich hier eine iterativ inkrementelle Softwareentwicklung beschreibe, füllt sich das Dokument zwar im Groben "von vorne nach hinten", aber die ersten Stichworte waren tatsächlich zum Kapitel "Test" entstanden.Bedenken Sie aber auch bei aller Systematik immer, dass das eigentliche Ziel der Softwareentwicklung natürlich nicht die Entwicklung selbst, sondern die Auslieferung einer fertigen Software mit den drei oben genannten Teilzielen ist.

2.3 Meine 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

15


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.4 UML"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].

16


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]

17


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.

2.5 Wozu MS-Project?"Wenn du den Hals noch so lang machst, du kannst doch nicht hinter den Berg schauen."(Tao Chi)

Microsoft Project ist eine Software für das PC-gestützte Projektmanagement. Sie können Vorgänge zeitlich festlegen und zu Sammelvorgängen zusammen fassen. Darüber hinaus können Sie Ressourcen (Mitarbeiter) zuordnen und über hinterlegte Stundensätze Kosten berechnen. Abhängigkeiten zwischen den Vorgängen sorgen für automatische Verschiebungen ganzer Vorgangsketten bei unerwarteten Ereignissen. Mit Meilensteinen können Sie wesentliche Zeitpunkte des Projekts definieren und deren Einhaltung bzw. Überschreitung prüfen.In verschiedenen Ansichten können Sie beispielsweise überlastete Mitarbeiter ermitteln oder Kostenverteilungen darstellen. Letztendlich können Sie MS-Project über die integrierte Programmiersprache VBA (Visual Basic for Applications) auch um eigene Funktionalitäten erweitern. Weitere Infos zum Produkt MS-Project erhalten Sie direkt von Microsoft [L15].In einem Software-Projekt dient MS-Project immer wieder zur Beruhigung des Managements, das in der Regel keinen genügenden technischen Hintergrund besitzt, um sich selbst ein Bild über den Projektstand zu machen.

Denken Sie bei all der Begeisterung über die Möglichkeiten von MS-Project daran, das ein Tool nicht die Erfahrung eines Projektleiters ersetzen kann! Hier greift einer meiner

18


Lieblingssprüche: "A fool with a tool remains a fool!" (dt. "Ein Dummer mit einem Werkzeug bleibt noch immer ein Dummer!").Nutzen Sie MS-Project beim ersten Mal nur zur nachträglichen Dokumentation Ihres Projekts, beim zweiten Mal zur Protokollierung der aktuellen Geschehnisse und erst beim dritten Mal zur aktiven Kontrolle bzw. für Vorhersagen. Danach werden Sie MS-Project als Planungsinstrument in Ihren Projekten nicht mehr missen wollen.Übrigens: Sie sollten beachten, dass Microsoft Project keine Feiertage kennt und diese frühzeitig eintragen. Ich habe wegen diesem Patzer meinem Team dieses Jahr Ostern versaut und werde in Zukunft wahrscheinlich immer dran denken.Über das Management von Terminen, Ressourcen und Kosten hinaus sollten Sie sich die folgenden offenen Fragen stellen, um einen Eindruck von Ihrem Projekt zu bekommen:Wann wird dieses Projekt fertig sein?Was kostet dieses Projekt?Worin besteht die Leistung dieses Projekts?Welche Prioritäten gibt es in diesem Projekt?Wer ist der Auftraggeber dieses Projekts?Welche Rolle spiele ich in diesem Projekt?Wer ist alles an diesem Projekt beteiligt?Welche Bedeutung hat dieses Projekt für die Beteiligten?Worin unterscheidet sich dieses Projekt von den anderen?Sie werden feststellen, dass jedes Projekt, jeder Kunde und jeder Mitarbeiter anders ist, vor allem bei Software-Projekten. Und dies ist gut so, denn gerade das macht den Reiz bei Software-Projekten aus - es sein denn, Sie befinden sich in einem "Scheissprojekt" [L10] ;-)

19


3 Anforderungen

3.1 Funktionale Anforderungen"Das Schicksal mischt die Karten und wir spielen."(Arthur Schopenhauer)

Im Erstgespräch mit dem Kunden wird zunächst über Wünsche und Vorstellungen gesprochen, die in aller Regel noch nicht konkretisiert oder zumindest noch nicht abschätzbar sind. Meistens ist sich der Kunde sehr unsicher über Realisierbarkeit und Aufwand. Als Auftraggeber wird der Kunde zum Anforderungssteller und liefert in aller Regel ein Fachkonzept mit den funktionalen Anforderungen (engl.: functional requirements). Dies geschieht in irgendeiner Form, also als protokolliertes Gespräch, als Handschrift-Zeichnung, als unstrukturierter oder auch strukturierter Text oder vielleicht sogar schon als Software-Lastenheft.Oft denkt der Kunde leider, dass bereits genügend Informationen zur Entwicklung der Software vorliegen, aber davon darf sich der Anbieter auf keinen Fall beeindrucken lassen, weil dies wirklich praktisch nie so ist. Der Anbieter sollte hier den Kunden unbedingt über die weitere Vorgehensweise aufklären und erläutern, welcher immenser Detaillierungsgrad noch erarbeitet werden muss. Es gibt halt nur zwei Möglichkeiten: entweder lernt der Kunde, wie professionell Software entwickelt wird oder der Anbieter lernt die Fachlichkeit und die Geschäftsprozesse des Kunden; in aller Regel ist Letzteres einfacher und billiger!Sollte das Fachkonzept bereits als fertige Spezifikation aller Details ausgeprägt sein (beispielsweise bei Ausschreibungen auf Basis bereits erstellter Analysen), kann direkt eine Aufwandsabschätzung folgen. Legt der Kunde eine Anforderungsliste vor, sollte diese in der Analyse auf Vollständigkeit, Widerspruchsfreiheit und Implementierbarkeit geprüft und anhand eines Fragenkatalogs abgerundet werden. Meistens enthält das Fachkonzept aber so viele Lücken und Unklarheiten, dass in der Analysephase die wirklichen Anforderungen erst noch erarbeitet werden müssen. Hier sollte auch darauf geachtet werden, ob der Anforderungskatalog mehr einer Weihnachts-Wunschliste entspricht, in der alles enthalten ist, was man schon immer mal haben wollte, aber nicht sinnvoll abgegrenzt wurde, was wirklich in der ersten Stufe implementiert werden sollte. Hier sollte dann die Regel "Reduce to the Max" ("Reduziere auf das Maximum") befolgt werden. Gemäß dem Spruch oben auf dieser Seite haben Sie als Auftragnehmer zunächst keinen Einfluss darauf, was Ihnen alles vorgelegt wird, aber sehr wohl einen Einfluss darauf, was Sie daraus machen.Beim Analyseprozess muss genau ein definierter Ansprechpartner des Kunden mit repräsentativen Vertretern aller Endanwendergruppen (Akteure) aktiv mitarbeiten, um auch wirklich den echten Bedarf zu ergründen und nicht an den Bedürfnissen der Anwender vorbei zu entwickeln. Nur so können die während der Entwicklung auftretenden gefürchteten Änderungsanforderungen (englisch "change requests") vermieden werden.Die Zeitschrift CIO schreibt in ihrer Ausgabe 6/2002: "Caper Jones, Chef-Forscher beim PM-Software-Anbieter Artemis, hat herausgefunden, dass sich in 90 Prozent aller Fälle die Anforderungen während der Projektlaufzeit verändern. Um dieses Problem zu begrenzen, rät er, IT-Lösungen gemeinsam mit den Endbenutzern zu entwickeln, wodurch sich die Hälfte der Änderungswünsche eliminieren lasse. Prototypen könnten weitere 10 bis 25 Prozent der Änderungen in eine frühe Phase verlagern. Für große Projekte empfiehlt Jones so genannte Change Control Boards aus Management, Benutzerrepräsentanten und Entwicklern."

3.2 Technische Anforderungen"Who in their right mind would ever need more than 640K of RAM?"(dt.: "Welcher vernünftige Mensch würde jemals mehr als 640K RAM benötigen?")(Bill Gates, Microsoft Gründer, 1981)

20


Die technischen Anforderungen stellt ebenfalls der Kunde und sie werden als Kapitel in die Anforderungsanalyse integriert. Dabei ist auf Grenzwerte und Plausibilitäten genauso zu achten wie auf Leistungsanforderungen (performance requirements), z.B. Übertragungsraten von Standorten oder Antwortzeiten einer Datenbank. Die Technologieplattform (Soft- und Hardware) wird hier festgelegt und die Testlandschaft beschrieben.Natürlich sollte der Anbieter auch bei den technischen Anforderungen dem Kunden mit Rat und Tat zur Seite stehen, aber er sollte auf keinen Fall den Kunden zu einer Technologie überreden, nur weil er diese selbst am besten beherrscht. In der Regel hat der Kunde auch bereits hohe Investitionen in der technischen Infrastruktur gebunden, so dass die Flexibilität hier eher gering ist.Genauso sollte ein professioneller Softwareentwickler in der Lage sein auf die Betriebssystem-Neigungen des Kunden einzugehen und die momentan so beliebte Religions-Diskussion um UNIX-Derivat/MS-Windows oder Sun-ONE/MS-.NET/IBM-Websphere sachlich zu führen! Vor allem mit Prognosen sollte man vorsichtig sein, wie der Spruch oben auf dieser Seite und oben auf der Folgeseite zeigt.

3.3 Anforderungen fixieren"I think there's a world market for maybe five computers."(dt.: "Ich denke, es gibt einen Weltmarkt für vielleicht fünf Computer.")(Thomas Watson, IBM chairman, 1943)

Ganz wichtig ist, dass die gestellten Anforderungen fixiert werden, d.h. als Anlage ins Angebot der Realisierung genommen werden. Denn wenn es am Ende des Projekts um die Abnahme und Bezahlung geht, muss gegen diese geforderte Leistung getestet werden. Sehen Sie es mal anders herum: Wenn Sie nicht wissen, was gefordert wurde, wie wollen Sie dann wissen, was bezahlt werden muss und wie wollen Sie überhaupt wissen, wann Ihr Projekt zu Ende ist? Sie werden im weiteren Verlauf noch sehen, dass beim Angebot für die Realisierungsphase sehr gut die Ergebnisse der Analyse als Anforderungskatalog betrachtet werden können.Dabei sollte grundsätzlich beachtet werden, dass Spezifikationslücken einen Spielraum für den Entwickler darstellen: Wird nur angegeben, was realisiert werden muss und nicht, wie es realisiert werden muss, kann sich der Entwickler den einfachsten Weg aussuchen. Dieser Weg wird dann sicherlich die fachlichen Anforderungen des Kunden erfüllen, aber vielleicht nicht gerade die Variante repräsentieren, die sich der Kunde immer vorgestellt - aber leider nicht spezifiziert - hat.Bei wesentlichen und vor allem offensichtlichen Auslassungen hingegen wird jeder Richter darauf pochen, dass Sie als Auftragnehmer von der Lücke wussten und eine Pflicht zur Forderung nach Ausbesserung der Anforderungen hatten. In diesem Fall ist die Nicht-Spezifikation ein klarer Vorteil für den Kunden! Wenn der Kunde also ein "Kennzahlensystem" fordert, keine weiteren Details liefert und später - entgegen Ihrer Meinung als Auftragnehmer - annimmt, dass eine Trendanalyse doch wohl selbstverständlich dazu gehört, dann hat wohl der Auftragnehmer schlechte Karten, weil er eine präzisere Beschreibung des Satzes "Die Software muss ein Kennzahlensystem enthalten" hätte fordern müssen. Beide Parteien sollten ein Interesse an einer dauerhaften guten Beziehung haben, der Auftraggeber wegen einer guten Betreuung in der Wartungsphase und der Auftragnehmer wegen Folgeaufträge und einer guten Referenz. Es sollten also beide bestrebt sein, solche Lücken zu füllen.

21


4 Pre-Analyse

4.1 Projektmappe"Kunde sein verdirbt den Charakter."(Ein Kunde von uns, den ich hier lieber nicht nenne ;-)

Bereits bei der geringsten Wahrscheinlichkeit für einen Auftrag sollte ein Projektordner mit Deckblatt angelegt werden. Darin werden auch die ersten Notizen des ersten Vertriebsgesprächs abgeheftet (und sei es ein bekritzelter Bierdeckel). Im weiteren Projektverlauf wird Alles, wirklich ALLES, in diesem Ordner abgeheftet. Idealerweise gibt es im Projekt kein relevantes Papier außerhalb dieses Ordners! Natürlich sollten Sie auch auf Alles, was Sie abheften, Datum und Namenskürzel schreiben.Das Deckblatt sollte Angaben wie beispielsweise Projektnummer, Projektname, Projektleiter sowie Anfangs- und Enddatum des Projekts enthalten. Natürlich gehören auch Kundenangaben wie beispielsweise der Ansprechpartner dazu. Daran sehen Sie schon, dass bei mir der Projektordner in aller Regel erst einmal ein dünner Schnellhefter mit durchsichtigem Frontumschlag ist. Erst wenn sich das Projekt als größer erweist und wir tatsächlich den Auftrag erhalten, wird es Zeit, auf einen richtigen Ordner umzusteigen. Den beschrifte ich dann eigentlich auch gar nicht mehr vernünftig, weil der dann eh immer im Projektraum steht und ohnehin immer jeder weiß, wo er gerade ist.Kopien von Angeboten, Aufträgen und Rechnungen können in den Projektordner - Analysen, Spezifikationen, Architekturbeschreibung und Protokolle müssen in den Projektordner. Die Registeraufteilung des Ordners passe ich immer ans Projekt an und bei großen Projekten lege ich auch gerne zwei oder mehr Ordner an, weil sie dann von verschiedenen Rollen gleichzeitig benutzt werden können. Der Projektordner hat in Zeiten der UML und umfassenden Softwaretools ohnehin nicht mehr die Bedeutung, die er früher mal hatte. Spannend wird es immer, wenn ein Kunde gemäß dem Titelspruch dieser Seite seine Macht ausspielen will und einfach etwas behauptet. Dann brauche ich oft nur sagen: "Ich meine, wir hatten dazu eine Notiz; soll ich mal nachschauen?" Da ich sehr viel auf Papier zeichne (oder besser: kritzel), finde ich fast immer was Passendes und nach kurzer Zeit reicht dann auch schon die Frage alleine.

4.2 Verantwortung"Nichts auf der Welt ist so gerecht verteilt wie der Verstand: Jeder glaubt, er hätte genug davon."(Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650)

Die Pre-Analyse ergibt ein grobes Bild über den zu betreibenden Aufwand, liefert einen ersten Einblick in das Unternehmen des Kunden und führt zu der Entscheidung über die Machbarkeit. Außerdem lernen Kunde und Anbieter sich persönlich kennen, was der erste Schritt zum Aufbauen von Vertrauen ist. Man merkt in diesen Gesprächen sehr schnell, wer sich profilieren will und wer wirklich wichtig ist.Der Kunde hat in den Pre-Analyse- und Analysephasen als Auftraggeber die Verantwortung für die Korrektheit und Vollständigkeit der Fachlichkeit, der Auftragnehmer hat als systematisch arbeitender Software-Experte hingegen die Verantwortung für die Konsistenz und Implementierbarkeit. Ferner muss der Auftragnehmer den Kunden darüber aufklären, was überhaupt möglich und sinnvoll ist. Manchmal denkt der Kunde, dass die eine oder andere Implementierung doch sehr einfach sein müsste, und ist überrascht, wenn nachher ein immenser Aufwand angeboten wird. Andererseits wagt der Kunde oft gar nicht, nach Funktionen zu fragen, deren Implementierung wirklich sehr einfach wäre.Bei der Pre-Analyse wird der Grundstein für die Analyse und damit für das gesamte Projekt gelegt. Ganz wichtig ist es daher, von vornherein die Verbindlichkeit, d.h. Schriftlichkeit, zu pflegen. Alle Informationen sollten dabei kurz, klar und konkret formuliert werden. Wenn Sie es hier nicht schaffen,

22


die nötigen Handhabungen und Instrumente zu plazieren, wird es später umso schwieriger. Daher behaupte ich immer, dass in der Pre-Analyse beide Parteien die Verantwortung haben, eine vernünftige Kommunikation aufzubauen, die alle Schwierigkeiten eines Projekts wegsteckt.Dies ist ein weiterer Vorteil in der Abspaltung der Pre-Analyse von dem eigentlichen Analyseprozess: Wenn einer der Partner merkt, dass er sich den falschen Partner ausgesucht hat, oder der zu erwartende Aufwand bei weitem das Limit übersteigt, kann das Ende der Pre-Analyse als frühestmöglicher Exit-Punkt des Projekts genutzt werden.

4.3 Name und Hauptziel"Der ziellose Mensch erleidet sein Schicksal, der zielbewusste gestaltet es."(Immanuel Kant)

Zuerst sollte der Name (ggf. Arbeitstitel) für das Projekt gefunden werden. Dieser sollte kurz und prägnant sein. Wenn es sich um ein Produkt handelt, dass im Markt vertrieben werden soll, so ist natürlich zu prüfen, ob der Name nicht bereits geschützt ist. Ferner sollte ggf. geprüft werden, ob der Name in andere Sprachen übersetzbar ist oder in anderen Sprachen oder Ländern eine völlig andere Bedeutung hat. Danach muss das zu erreichende Hauptziel des Projekts formuliert werden. Dies ist die schwierige Antwort auf die einfache Frage: "Wofür ist die neue Software gedacht?" Es ist ganz wichtig, dass das Hauptziel des Projekts in einem einzigen Satz formuliert wird. Sie werden sich wundern, wie oft Sie diesen Satz noch verwenden werden! Ob Sie in der Kantine von Kollegen nach ihrer momentanen Aufgabe gefragt werden, dem Marketing die Bedeutung des Produkts erläutern sollen, eine Produktbeschreibung für eine Messe suchen, einen Einstieg für ein Handbuch brauchen oder nach der Analyse noch mal schauen wollen, ob Sie überhaupt noch auf dem richtigen Weg sind: dieser eine Satz hilft Ihnen!Ziele sollten immer SMART sein: Specific (spezifisch), Measurable (messbar), Achievable (erreichbar), Realistic (realistisch) and Time-related (zeitbezogen).Beispiele:Zu entwickeln ist eine Software, mit der die Kunden (Mitarbeiter) schneller und effizienter unterstützt und alle Störungen und Anfragen chronologisch vom Support oder Fachbereich erfasst, über eine Wissensdatenbank ausgewertet und nachgehalten werden können.Zu entwickeln ist eine Software, mit der alle Bar-Einnahmen und -Ausgaben in einem Kassenbericht, der mit der Kasse an jemand anderes übergeben werden kann, zusammengefasst und nachgehalten werden können.Das Hauptziel des Systems ist eine Konsolidierung der wesentlichen Daten aus den einzelnen Projekten zum Zweck der Steuerung, Dokumentation und Erfüllung des Berichtswesens bei der Abwicklung der Investitionspläne von Firma unter wirtschaftlichen Gesichtspunkten.Ziel des Projektes "LUDOware" ist die Entwicklung einer Software zur Unterstützung einer Spieleausleihe inklusive einer Mitglieder- und Spieleverwaltung und einem Internetzugriff.Ziel des Projektes "PHW-OWL" ist die Schaffung eines Internet-Portals für Hochschulen und Unternehmen aus dem Raum OWL, welches Praktika, Themen für akademische Arbeiten und Stellen vermittelt.Es soll ein professionelles Management-Werkzeug namens "Firma-inventar" für die zentrale Hard- und Softwareinventarisierung mit Zuordnung zu Räumen und Personen erstellt werden.

4.4 Zweck und Tragweite (engl. "Purpose & Scope")"Sobald der Geist auf ein Ziel gerichtet ist, kommt ihm vieles entgegen."(Johann Wolfgang von Goethe)

23


Wenn Sie als Analytiker vom Kunden das Hauptziel bekommen haben, fragen Sie nach allen Leuten, die an der Definition dieses Hauptziels beteiligt waren. Es erscheint unglaublich, aber ich habe schon erlebt, dass acht(!) Leute aus verschiedenen Bereichen ein halbes Jahr für die Definition dieses einen Satzes gebraucht haben! In einem solchen Fall sollten Sie diese acht Leute auch alle das gemeinsam gefundene Ziel unterschreiben lassen! Über die Diskussion um die Beteiligten am Zielsatz finden Sie die ersten Hauptakteure und Interessensgruppen.Die Akteure (engl. "actors") des neu zu erstellenden softwareintensiven Systems sind die Unternehmensrollen (z.B. "Buchhalter"), die später direkt mit dem System arbeiten werden. Wenn Sie zu viele Akteure finden (mehr als 7), sollten Sie die Hauptakteure (die wichtigsten Akteure) (engl. "main actors") bestimmen.Die Interessensgruppen (engl. "stakeholders") bedienen das System nicht direkt, haben aber bestimmte Interessen daran, dass die Akteure dies tun.Sprechen Sie mit den Akteuren und Interessensgruppen und nehmen deren Hauptanforderungen auf. Diese werden in der späteren Analyse weiter zerlegt und mit den Informationen aus dem Fachkonzept weiter gefüllt. Dadurch führen die Hauptanforderungen Sie auch zu den Teilzielen des Systems.Beschreiben Sie mit den Hauptanforderungen was das System leisten soll, noch nicht wie es das tun soll, denn das System selbst ist in diesem Stadium noch eine Unbekannte (engl. "black box").Zeichnen Sie ein "Zweck- und Tragweiten-Diagramm" als besondere Form des UML-Anwendungsfalldiagramms. Dabei zeichnen Sie das zu erstellende Software-System als innere Systemgrenze und die Unternehmensgrenze als äußere Systemgrenze. Nun können Sie die gefundenen Hauptakteure mit ihren Hauptanforderungen an das zu erstellende Software-System einzeichnen. Spätestens jetzt wird allen Beteiligten deutlich, wofür das zu erstellende Software-System eigentlich gut ist ("Zweck") und wen es alles betrifft ("Tragweite").

24


Dieses Verfahren zum Aufnehmen von Anforderungen kann natürlich nicht nur für die Erstellung von softwareintensiven Systemen genutzt werden: wer sind wohl die Hauptakteure von folgendem kleinen Netzwerk und welche Hauptanforderungen wurden bzw. werden wohl an folgendes Netzwerk gestellt?

4.5 Prosatext"Es war einmal ..."(Der Anfang eines jeden guten Märchens)

Beschreiben Sie nun in Prosa mit wenigen(!) kurzen und einfachen Sätzen die gefundenen Hauptanforderungen und damit die wesentlichen Teilziele des zu erstellenden Software-Systems. Dies ist sehr wichtig, weil dies die Sprache des Kunden ist (nicht jeder Kunde versteht UML-Diagramme mit Systemgrenzen und Strichmännchen!). Der Kunde kann an diesem Text das Verständnis seiner eigenen Fachlichkeit durch den Anbieter testen.Denken Sie immer daran, dass der Kunde und der Anbieter verschiedene Sprachen sprechen: der Kunde denkt an seine Fachlichkeit und Organisation, der Anbieter denkt an Datenstrukturen und Modulschnittstellen. Unter dem Begriff "Ordner" beispielsweise verstehen der Kunde und der Anbieter oft ganz verschiedene Dinge: der Kunde meint den Ordner, in dem er mit Trennblättern Papier abheftet, den er auf eine definierte Art und Weise beschriftet und der in einem bestimmten Schrank unter der Obhut eines Mitarbeiters oder einer Mitarbeiterin verwahrt wird. Der Anbieter meint den Ordner, den er in einem Festplattenvolumen des PC-Netzwerks anlegt und mit Rechten eines Benutzers seines technischen Systems versieht, der darin Dateien speichern darf. Beides ist vielleicht nur die unterschiedliche Sicht auf den Informationsspeicher des Unternehmens und meinen damit letztlich das Gleiche, aber sind sich wirklich der Kunde und der Anbieter darüber im Klaren?Der Prosatext ist auch ein Test für das Ziel- und Tragweiten-Diagramm, das formulierte Hauptziel sowie den Namen des neuen Softwaresystems. Wenn diese vier Sichten nicht übereinstimmen, muss entsprechend korrigiert werden.

25


4.6 Was also ist die Pre-Analyse?"Wir bringen immer nur eins auf einmal durcheinander."(Kernighan/Ritchie)

Die Pre-Analyse dient also dazu, festzustellen, in welcher Liga das Projekt spielt und welche Bedeutung es für den Kunden hat. Nach der Pre-Analyse können bereits die ersten Aussagen zu Machbarkeiten, Risiken, groben Aufwänden und den Kosten der Analyse getroffen werden.Kern der Pre-Analyse sollte genau ein Blatt Papier sein, das die drei Elemente "Name und Hauptziel", "Zweck- und Tragweiten-Diagramm" und "Prosatext" enthält:

Da ich mir zuerst in den Interviews beim Kunden Notizen mache, dann später daraus das Diagramm erstelle und zuletzt den Prosatext schreibe, kennt der Kunde maximal meine Notizen. In einer abschließenden Diskussionsrunde mit allen Hauptakteuren lege ich jedem Teilnehmer das Blatt wie folgt gefaltet vor:

26


Nachdem wir uns das Ziel in Erinnerung gerufen haben, lesen wir gemeinsam den kurzen Prosatext und steigen in die Diskussion ein. Dafür klappen wir das Blatt dann auseinander, weil das Diagramm gegenüber dem Text den großen Vorteil hat, dass ein Einstieg an jedem Punkt möglich ist. Meine Erfahrung mit dem Diagramm ist bei dieser Vorgehensweise durchweg positiv, weil der Kunde einerseits bereits am Text gemerkt hat, das ich ihn ernst nehme und verstanden habe und andererseits jeder Kunde das Diagramm nach nur kurzen Erklärungen auch versteht.

4.7 Geschäftsprozesse"Der Irrtum ist die tiefste Form der Erfahrung."(Martin Kessel)

Oft sind den Unternehmen die Prozesse besser bekannt als die Beteiligungen oder gar Anforderungen einzelner Rollen im Unternehmen. Dies liegt wohl auch daran, dass in den letzten Jahren Heerscharen von Beratern "Prozessoptimierungen" gepredigt haben. Daher kann es für die Unternehmen verständlicher sein, mit den Prozessen anzufangen und daraus dann die Hauptakteure und deren Hauptanforderungen abzuleiten. Bei großen Systemen oder bei vielen Prozessen wird sich dies schnell als der schwierigere Ansatz erweisen; wenn das zu erstellende Software-System aber hauptsächlich einen einzelnen Geschäftsprozess abdecken soll, ist es durchaus sinnvoll, im ersten Schritt diesen Prozess zu analysieren. Betrachten Sie als Beispiel den Mitarbeiter-Support, der in dem folgenden Sequenzdiagramm beschrieben ist (IV_HelpDesk ist dabei das zu entwickelnde System):

Sie sehen in den ersten drei "Spalten" die drei Akteure des Systems. In der vierten "Spalte" ist das zu erstellende Software-System selbst aufgeführt und alle Pfeile, die dort beginnen oder enden, sind letztendlich Anforderungen, die von den Akteuren an dieses System gestellt werden. Das Zweck- und Tragweiten-Diagramm kann also aus diesem Sequenz-Diagramm abgeleitet werden.

27


Bei größeren Systemen werden Sie aber gar keine Chance haben, alle Prozesse verknüpft in einem einzelnen Diagramm unterzubringen. Dies gelingt schon allein deshalb nicht, weil an jedem Prozess viele Abteilungen und damit viele Abteilungsleiter und sehr viele Mitarbeiter beteiligt sind, die alle eine andere Sicht auf die jeweiligen Prozesse haben. Wenn es dann noch Zentralabteilungen oder Stabsstellen gibt, die "von außen" auf die Prozesse schauen, wird es völlig kompliziert. Wenn das zu erstellende Software-System (die innere Systemgrenze im Zweck- und Tragweiten-Diagramm) im Laufe der Analysephase von der Blackbox zur Whitebox wird, dann werden die Prozesse, an denen das System beteiligt ist, deutlich sichtbar. Dann wird auch erkennbar, welche Prozesse nur teilweise von dem neuen System begleitet werden.Es ist auf jeden Fall extrem wichtig, in der Pre-Analyse nur die Fachlichkeit des Kunden, also das reine Geschäftsmodell zu betrachten. Die Benutzeroberfläche oder technische Aspekte der Software spielen hier überhaupt gar keine Rolle! Noch mal: in dieser frühen Phase darf nur betrachtet werden, was gefordert wird, nicht wie es realisiert werden kann - es wird schließlich nichts eingebaut, nur weil es eingebaut werden kann, oder? Jeder Kunde kennt mindestens 90% seines Geschäftsmodells, weil er es jeden Tag lebt! Also sollten Sie als Analytiker nicht raten, wie etwas laufen könnte, oder an allen Ecken sofort vermeintliche Verbesserungen vorschlagen. Führen Sie stattdessen Interviews und lernen Sie den Kunden kennen: er sagt Ihnen schon, was Sie tun müssen, wenn Sie ihn nur fragen!In [B13] gibt es ein Kapitel "2.3.4. Der Umgang mit politischen Risiken". Dieses Kapitel besteht aus nur zwei Sätzen: "Dazu kann ich keine ernsthaften Ratschläge geben, da ich kein »Unternehmenspolitiker« bin. Ich raten Ihnen nachdrücklich ab, jemanden zu finden, der dies ist." Das stimmt!

4.8 Angebote und Verträge"Wohin wir auch blicken, überall entwickeln sich die Chancen aus den Problemen."(Nelson A. Rockefeller)

Die Pre-Analyse sollte zum Festpreis realisiert werden. Dadurch wird bereits ganz am Anfang des Projekts der wichtigste Aspekt eines jeden Projekts gepflegt: die Verbindlichkeit. Dem Kunden wird dabei klar, dass er sich auch für Software-Leistungen bewusst entscheiden und dafür auch bezahlen muss (was erstaunlicherweise vielen gar nicht klar zu sein scheint, weil sie offensichtlich immer noch viele fertige Software-Produkte kostenlos zu bekommen scheinen!) und der Anbieter wird gezwungen, ein Dokument (also etwas schriftliches) abzugeben. Gleichzeitig kann dabei gegenseitig das Verhalten bei der Geschäftsabwicklung (ich meine die Prozesskette "Angebot, Auftrag, Lieferung, Rechnung, Zahlung") erkundet werden."Murray wies immer darauf hin, wie wichtig es sei, einen Verkauf auch wirklich abzuschließen. Wir stellten fest, dass sich die meisten unserer Leute in den Anfangsstadien des Verkaufens gut bewährten, aber dann eine solche Angst vor Ablehnung hatten, dass sie potentielle Kunden oft wieder zur Tür hinausgehen ließen. Sie brachten es einfach nicht fertig, zu sagen: Unterschreiben Sie hier." ([B6] S. 57).Der Aufwand für die Pre-Analyse kann bei zwei Stunden liegen, ich habe aber auch schon eine ganze Woche benötigt. Wichtig ist, dass hier auf jeden Fall zum Festpreis angeboten wird und das dieser Aufwand auch nicht überschritten wird, denn wenn die Pre-Analyse schon nicht verbindlich gehandhabt werden kann, wie soll es dann bei der Realisierung aussehen? Achten Sie als Anbieter also darauf, dass sich bereits bei der Pre-Analyse Ihre ganze Professionalität zeigt!Den Aufwand können Sie nur aus den Fakten des vorhergehenden Vertriebsgesprächs ermitteln. Falls es offensichtlich ein größeres Projekt wird (wobei natürlich jeder selbst entscheiden muss, was für ihn ein "größeres" Projekt ist), kann es Sinn machen, einen weiteren Kundentermin zu vereinbaren, bei dem Vertrieb und Analytiker zugegen sind. Dies ist insbesondere sinnvoll, wenn der Vertrieb nicht wirklich Ahnung von Softwareentwicklung hat und der Analytiker kein guter Vertriebler ist (und seien wir ehrlich: meistens ist doch beides der Fall, oder?).Bedenken Sie bitte in jedem Fall, dass die Pre-Analyse per Definition unvollständig ist (s. "Was also ist die Pre-Analyse?")! Sie brauchen also nicht das Festpreis-Angebot zu scheuen.

28


Nach der Pre-Analyse sollte auch der Kunde ein Gefühl dafür bekommen haben, worauf er sich bei dem Projekt wirklich einlässt. Dieser Eindruck weicht häufig sehr stark von den ursprünglichen Vorstellungen ab. Da noch immer die meisten Unternehmen und Menschen recht wenig Erfahrung mit der Softwareentwicklung haben, sorgt die Pre-Analyse in der Regel für eine unangenehme Überraschung in Punkto Aufwand und Kosten. Oft wird hier dann schon zwischen Pflicht und Kür getrennt und eine Folgeversion geplant.Je nach Projektgröße und Unternehmen wird entweder ein Festpreis-Angebot für die Analyse folgen oder ein Rahmenvertrag für den gesamten Rest des Projekts gemacht. Letzteres ist bei Festpreisprojekten immer schwierig, weil der Aufwand erst nach der Analyse genau genug bekannt. Bei einem reinen Aufwandsprojekt besteht für den Anbieter hier natürlich kein Risiko. Eigentlich tun sich beide einen Gefallen, wenn die Analyse zum Festpreis erfolgt und danach die einzelnen Anwendungsfallpakete ebenfalls zum Festpreis angeboten werden können.

29


5 Analyse

5.1 Analyseaspekte"Wenn wir nur zuerst herausfinden könnten, wo wir stehen und wohin wir tendieren,dann könnten wir besser beurteilen, was zu tun ist und wie es zu tun ist."(Abraham Lincoln)

Der Anbieter wird in dieser Phase zum Analytiker, der das Fachkonzept des Kunden strukturiert aufbereitet und in vielen Interviews ganz viele Fragen stellt, um die Antworten systematisch und strukturiert in die Analyse einzuarbeiten. Der Analytiker prüft alle Informationen auf Auslassungen, Widersprüche, Mehrdeutigkeiten, Ungenauigkeiten, Prioritäten und Irrelevanz. Stellt er Mängel fest, muss er Informationen nachfordern und nachbessern. Die Analys etätigkeit verlangt also extrem viel Disziplin.Es geht zunächst noch immer ausschließlich um die Fachlichkeit - also das Geschäftsmodell - des Kunden: alles, was die Software "wissen" muss, um die reale Welt des Kunden nachzubilden, gehört in das Analysedokument - aber mehr nicht! Das System soll ja auch nicht mit überflüssigen Funktionen überlastet und dadurch unbenutzbar werden! Es ist häufig extrem schwer zu beurteilen, was rein gehört und was nicht, d.h. zu bewerten ob es nötig ist, ein Detail zu spezifizieren, oder nicht. In [B4] gibt es phantastische Beispiele für softwareintensive Systeme, in denen Fehler teilweise mehrere Jahre gelauert haben, bis sich Mechanismen außerhalb des Systems oder implizite Voraussetzungen geändert haben, so dass die Fehler endlich zum Vorschein kommen konnte.Ein Beispiel aus [B4]: "Der höheren Sicherheit wegen rüstete British Rail ihre Züge von Backenbremsen auf Scheibenbremsen um. Die neuen Bremsen arbeiteten gut, aber der Austausch verwirrte das Signalsystem gründlich. Das Signalsystem ist sicherheitskritisch, da sein Zweck die Verhütung von Zusammenstößen ist. Dabei greift es auf drei redundante computerisierte Systeme zurück, die die Position jedes Zugs über Sensoren in den Schienen ermitteln, die mit den Rädern des Zugs in Kontakt kommen. Die Position sämtlicher Züge ist im Stellwerk als Markierung auf einem Display verfügbar. Das Problem entstand im Herbst, als das Laub von den Blättern fiel und feuchtes Wetter herrschte. Nasse Blätter bildeten auf den Schienen eine breiige Masse und überzogen als isolierende Paste die Räder, die von den Scheibenbremsen nun nicht mehr wie von den Backenbremsen blank poliert wurden. Die Paste bildete eine immer dickere Schicht, bis die Züge keinen elektrischen Kontakt mehr zu den Sensoren im Gleis hatten. Aus Sicht des Signalsystems waren die Züge einfach verschwunden. Am Montag, den 11.11.1991 warteten Hunderte von Passagieren stundenlang auf ihre Züge, während die Betriebsleitung bei British Rail herauszufinden versuchte, welche Züge wo waren."Dies belegt auch sehr schön, dass sich jedes Gesamtsystem aus Teilsystemen ("Weltausschnitten") zusammen setzt, die sich gegenseitig beeinflussen. Selbst wenn die Entwickler des Signalsystems in ihrer Analyse der Anforderungen die Voraussetzung definiert hätten, dass die Räder immer Kontakt zu den Gleisen haben müssen, wäre dieser Fehler aufgetreten, weil die Verantwortlichen des Bremssystems vor dem Umbau der Bremsen bestimmt nicht die Spezifikation des Signalsystems gelesen hätten. Hier hatte eine unbeabsichtigte und unbewusste Funktion des alten Bremssystems (nämlich das sauber halten der Räder) zufällig zu einer unbedingten Voraussetzung der Funktionalität des Signalsystems geführt - und da hilft auch die Redundanz von drei Computern nicht weiter. Es gibt wohl auch kaum keine Möglichkeit, solche Zusammenhänge in die Spezifikation des Gesamtsystems mit aufzunehmen, weil diese zufälligen Zusammenhänge niemandem bewusst sind.Sehr wohl zeigt sich gerade in solchen Fällen, ob professionell gearbeitet wird: "Professionalität" setzt sich hier aus strenger Formalität, viel Systematik, noch mehr Test auf Vollständigkeit und Widerspruchsfreiheit sowie das Einnehmen verschiedener Positionen zur Ausübung verschiedener Sichten zusammen. Hier sei schon mal der besondere Charakter von "Fehlern" vorweg genommen, das sie umso billiger sind, je eher man sie findet und beseitigt [B16]. Die Analysephase wird wie jede Phase und der gesamte Software-Erstellungsprozess iterativ inkrementell durchlaufen, d.h. die Analyse wächst in mehreren Schritten. Bei jedem Schritt werden

30


alle Bestandteile genauer beschrieben. So werden zunächst alle Bestandteil konzeptionell betrachtet, indem nur kurz erläutert wird, welche Anforderung überhaupt dazu gehört. Danach wird konzeptionell kurz beschrieben, worum es bei jedem Bestandteil geht. Als nächstes wird spezifiziert, wie der Bestandteil genau aussieht. Schließlich werden erstmalig Realisierungsaspekte ins Spiel gebracht. So wird aus einer sehr rohen Liste (Anforderungen) eine detaillierte Beschreibung (Spezifikation).

5.2 In/Out-Liste"Das Aussortieren des Unwesentlichen ist der Kern aller Lebensweisheit."(Laotse)

Bei der Analyse ist wichtig, dass sehr viel Klärung stattfindet: alle Anforderungen müssen aus- und bewertet und gegen das Hauptziel getestet werden, das während der Pre-Analyse definiert wurde. Es müssen also Entscheidungen getroffen werden, ob eine an das System gestellte Anforderung wirklich realisiert werden soll oder nicht. Bei vielen Entscheidungen werden Sie als Analytiker feststellen, dass sich Ihr Kunde sehr schwer tut und schwankt und eine große Unsicherheit an den Tag legt. Es ist aber wichtig, dass eine Entscheidung getroffen wird, die dann auch genauso formal und verbindlich wie alles andere behandelt wird. Erstellen Sie eine In/Out-Liste und nehmen Sie die Entscheidung dort auf:

In Out Beschreibung Datum

- Out Erfasste Artikel werden mit Zeitstempel versehen 2002-07-15

In - Stücklisten 2002-07-19

Dieses Instrument ist höchst einfach, aber genauso effektiv. Es entspricht einer meiner Grundregeln für jedes Projekt: KISS (Keep it small and simple). Eine Entscheidung kann ja durchaus später revidiert werden, aber dann ist wenigstens klar, dass die Konsequenzen (d.h. der zeitliche und damit finanzielle Aufwand) ermittelt und in Rechnung gestellt werden können. Manchmal ist es auch sinnvoll, die In/Out-Liste parallel auf einem Flipchart-Blatt zu führen und dieses gut sichtbar im Projektraum aufzuhängen. Dann kann man immer schön mit dem Finger drauf zeigen :-)Wenn bereits klar ist, dass die Software in mehreren Schritten erstellt wird, so kann der In/Out-Liste natürlich auch eine Spalte hinzugefügt werden, in der bei einem "In" eine Versions- oder Modulnummer oder vielleicht auch ein Datum eingetragen wird. Die Liste hilft in jedem Fall ganz deutlich dabei, die Pflicht und Kür zu trennen: die "Pflicht" muss rein und die "Kür" fliegt raus oder wird dann gemacht, wenn die Pflicht erledigt ist. Dies ist wieder eine meiner Grundregeln für jedes Projekt: Erst die Pflicht, dann die Kür!

5.3 Protokolle"Es gibt Wichtigeres im Leben, als beständig dessen Geschwindigkeit zu erhöhen."(Mahatma Gandhi)

Dies ist eine gute Stelle, um ein leidiges Thema anzusprechen: Ich verstehe nicht, warum Projektteilnehmer so ungern Protokolle erstellen! Vielleicht liegt es daran, dass man sich festlegen muss. Vielleicht ist es auch, weil man dann zu einer Entscheidung stehen muss und später festgestellt werden kann, wer den Fehler gemacht hat. Es ist wahrscheinlich genau die große Verbindlichkeit, die ein Protokoll bedeutet, wovor sich die Menschen fürchten. Aber gerade diese Verbindlichkeit sorgt stets für klare Verhältnisse im Projekt und damit für ein hohes Maß an Objektivität und Fairness. Ich habe das Thema "Verbindlichkeit" bereits in der Pre-Analyse angesprochen und werde beim Design erneut darauf zurück kommen, denn es zieht sich wirklich durch das gesamte Projekt! Eine Entscheidung, die zu einem "In" oder "Out" führt, wird in einer Sitzung mit dem Kunden getroffen. Zu einer Sitzung mit dem Kunden gehört ein Protokoll, das bei mir immer wie folgt aussieht und mit Microsoft Word geschrieben wird:

31


Sie sehen in dem Protokoll Unterschriftsfelder, denn ich drucke tatsächlich jedes Protokoll zwei mal aus; mein Ansprechpartner des Kunden und ich unterschreiben beide Protokolle, so dass jeder ein Exemplar mit beiden Unterschriften hat und dieses in seinem Projektordner abheften kann. Dabei folge ich einfach dem Motto: "Was am Freitag nicht unterschrieben ist, ist am Montag vergessen." Spätestens bei der Unterschrift merkt der Kunde, dass ich es ernst meine und er überlegt sich seine Ins und Outs sehr gut. Ich habe allerdings noch nie ein Problem damit gehabt, die Unterschrift zu bekommen, denn auch der Kunde lernt diese Verbindlichkeit sehr schnell zu schätzen. Probieren Sie es mal aus! Die Protokolle sind natürlich in der Sprache des Kunden zu führen. Ich erstelle Programmdokumentationen, Team-Spezifikationen und Quellcode-Kommentare grundsätzlich in Englisch, weil zum einen alle Programmiersprachen in Englisch arbeiten und damit auch englische Variablen-, Funktions- und Klassennamen selbstverständlich sind, und weil zum anderen zumindest bei größeren Projekten doch häufiger Leute beteiligt sind, die immer mindestens Englisch verstehen können. Alle Dokumente, die der Kommunikation mit dem Kunden dienen, müssen aber natürlich in der Sprache des Kunden erstellt werden.

5.4 Interviews"Das Problem zu erkennen ist wichtiger als die Lösung zu finden,denn die genaue Darstellung des Problems führt fast automatisch zur richtigen Lösung."(Albert Einstein)

32


Es ist äußerst wichtig, dass es bei jedem Projekt sowohl auf Anbieter- als auch auf Kundenseite genau einen verantwortlichen Ansprechpartner - also einen Vertreter - gibt, denn in der Regel wird nur bei der beidseitigen Bündelung der Verantwortung die Verbindlichkeit akzeptiert. Das heißt aber nicht, dass der Vertreter des Kunden auch die gesamte Fachlichkeit des Kunden beherrschen muss. Gerade bei größeren Projekten kann eine Person alleine unmöglich die gesamte Fachlichkeit des Kunden beherrschen. Daher sollte der Vertreter des Kunden für jeden Akteur stellvertretend einen Vertreter suchen, bei dem er sich erkundigen kann. Die Verantwortung für das Ergebnis liegt gegenüber dem Anbieter dann natürlich wieder bei dem einen einzigen Vertreter des Kunden, aber die Sicherheit und Qualität der Antworten steigt und es vergeht dennoch nicht viel Zeit bis zur Antwort. Es macht durchaus sehr viel Sinn, dass der Vertreter des Anbieters an diesen fachlichen Interviews der Vertreter der Akteure teilnimmt, zum einen um den Stille-Post-Effekt zu vermeiden, zum anderen aber auch, um sich selbst einen Eindruck von der Sicherheit in der Fachlichkeit der Akteure zu verschaffen. Es kommt schließlich nicht selten vor, dass auch die Akteure selbst die Fachlichkeit nicht sauber formulieren können, weil sie nie systematisch darüber nachgedacht haben, warum sie was wie tun. Nicht selten kommt es vor, dass ein "Cheffe" meint, am besten zu wissen, was seine Leute wie tun, weil er es ihnen vorgibt. Meine Erfahrung hat aber gezeigt, dass dies noch lange nicht heißt, dass seine Mitarbeiter auch wirklich so arbeiten. Oft müssen die Mitarbeiter "Korrekturen" ansetzen, die sie auch nur zugeben können, wenn der Vorgesetzte bei den Interviews nicht teilnimmt. Wie bei allen anderen Menschen kann auch Chefs nur geholfen werden, wenn sie wirklich bereit sind, sich helfen zu lassen).Ich denke, nach dem vorhergehenden Unterkapitel ist es selbstverständlich, dass bei jedem Interview ein Protokoll erstellt wird und dass der Ansprechpartner des Kunden ebenfalls an dem Interview teilnimmt und dass beide "Parteien" das Protokoll unterschreiben.Ich nehme grundsätzlich in das Analysedokument eine kleine Tabelle mit auf, wann mit wem ein Interview stattgefunden hat. Ich vermerke in dieser Tabelle auch, ob die Ergebnisse des Interviews bereits in die Analyse eingearbeitet sind. Ich nehme grundsätzlich alle Ergebnisse (also insbesondere alle Anforderungen) in die Analyse mit auf, kennzeichne dann aber mit meinem Ansprechpartner zusammen die Anforderungen, die nicht als "offizielle" Anforderungen des Kunden stehen bleiben sollen (natürlich erstellt hier jeder Interview-Partner einen fetten Wunschzettel!).

FachabteilungGruppe Datum in Analyse

eingearbeitet

Buchhaltung 2002-07-18 ja

Lager 2002-07-19 nein

5.5 Problemzerlegung"Verwandle große Schwierigkeiten in kleine und kleine in gar keine."(aus China)

Wie im Eingang dieses Kapitels erläutert, geht es bei der Analyse darum, das Hauptziel des Projekts über das Fachkonzept und die vielen geführten Interviews in Teilziele und Teilprobleme mit Teillösungen zu zerlegen und die ursprünglich gestellten Anforderungen systematisch einzuarbeiten. Im Eingang dieses Kapitels habe ich auch zur Sprache gebracht, dass die Analyse iterativ inkrementell erstellt wird. Dabei sind die im Folgenden erläuterten Methoden hilfreich (die übrigens alle auch schon vor der Objektorientierung in der Software-Entwicklung angewandt wurden). In den folgenden Kapiteln wird dann eine Arbeitsweise vorgestellt, die diese Methoden konsequent anwendet.

33


5.5.1 HierarchisierungDie Hierarchisierung dient der Zerlegung eines Problems in Teilprobleme Die Teilprobleme können dann isoliert für sich betrachtet werden. Es ist immer einfacher mehrere Teilprobleme zu lösen als ein Gesamtproblem. Die Vorgehensweise ist hierbei typischerweise top-down (von oben nach unten), weil ein großes Problem in mehrere mittlere Probleme zerlegt wird, die dann in noch mehr kleine Probleme zersplittert werden. So wird das Projektziel in Teilziele und weiter in konkretere Schritte zerlegt, ganz nach dem chinesischen Sprichwort: "Verwandle große Schwierigkeiten in kleine und kleine in gar keine". Aus den Teilzielen ergeben sich bei der späteren Realisierung dann auch die Arbeitspakete und damit die Projektmeilensteine und Programmversionen.Weil ganze Sub-Bäume der Hierarchie voneinander getrennt verlaufen, können in den späteren Projektphasen auch mehrere Entwickler oder gar mehrere Entwicklerteams parallel arbeiten und auch die Qualitätssicherung und die Handbuchschreiber können ihre Arbeit besser aufteilen.5.5.2 ModularisierungAus der Zerlegung bei der Hierarchisierung entstehen einzelne Module, die nur über definierte Schnittstellen mit den umgebenden Modulen kommunizieren können und ansonsten kontextunabhängig sind. Wenn diese Schnittstellen vorab präzise definiert werden kann ein Modul in späteren Projekten vielleicht auch wieder benutzt werden und zum treuen Begleiter über mehrere Jahre werden. Durch diese Widerverwendbarkeit verringert sich in den Folgeprojekten der Entwicklungsaufwand und gleichzeitig erhöht sich die Robustheit der Software, weil bereits getestete, erprobte und sogar bewährte Module zum Einsatz kommen. Diese Module werden zunächst sicherlich in Prosa mit dem Kunden besprochen und dann iterativ immer präziser spezifiziert und durch Änderungsanforderungen im Laufe der Zeit auf dem aktuellen fachlichen Stand gehalten.Bei der späteren Programmierung der Module werden Code und Daten der gekapselt und über eine gemeinsame Schnittstelle von der Umgebung isoliert. Daher können auch Fehler recht schnell auf Module eingegrenzt und damit lokalisiert werden. Ändert sich durch die Fehlerbehebung die Schnittstelle des Moduls nicht, so ist in der Regel auch der Folgetest nach der Änderung auf eine kleine Anzahl von Modulen begrenzt. Diese Aspekte zeigen deutlich die Wichtigkeit sowohl von Definition als auch von Dokumentation der Schnittstellen.5.5.3 StrukturierungDie Module selbst ergeben zusammengesetzt wieder die Hierarchie, wobei die Schnittstellen das Zusammenspiel der Module definieren. Die Module selbst sind aus Sicht der Hierarchie Black Boxes, denn es sind nur deren Namen, Aufgabenbeschreibungen und Schnittstellen, aber nicht die Inhalte sichtbar.Bei der fortschreitenden Entwicklung des Software-Systems müssen natürlich alle Module spezifiziert und letztendlich programmiert werden. Hierfür ist übrigens ein außerordentlich hohes Maß an Disziplin erforderlich, weil sehr viel Detailkram entdeckt, analysiert, diskutiert, hinterfragt, dokumentiert, getestet und manchmal auch wieder verworfen werden muss. Dabei das gesamte Analysedokument stets aktuell und konsistent zu halten, erfordert wirklich eine immer wieder erstaunliche Akribie. Jeder gefundene Lösungsansatz einer analysierten Fragestellung wirft in aller Regel wieder weitere Fragen auf, die wieder analysiert werden müssen. Dies scheint lange Zeit kein Ende zu finden, weil der Fragenberg immer größer statt kleiner wird. Dabei ist es sehr wichtig, stets das passende Abstraktionsniveau zu finden und zu halten. Gegebenenfalls muss ein Modul nochmals gesplittet werden, weil sich bei der Strukturierung des Moduls noch zuviel Komplexität

34


zeigt. Vielleicht zeigt sich aber auch, das es in dem Modul kaum etwas zu strukturieren gibt und das Modul sehr gut mit einem Nachbarmodul verschmolzen werden kann. An dieser Stelle wächst oft die Ungeduld, weil man sich schon viel weiter wähnte, als man in Wirklichkeit ist. Aber unser Kopf ist schließlich rund, damit das Denken die Richtung ändern kann - also sollte man die neu gewonnenen Ansichten auch umsetzen!Miller [L8] zeigte schon sehr früh, dass der Mensch sehr gut 7 ± 2 Aspekte überschauen kann. Daran sollten Sie sich orientieren, wenn Sie Ihr Problem zerlegen, hierarchisieren und aufgrund der Ergebnisse der Strukturierungsansätze die Module neu verteilen. Nach jeder Neuverteilung können Sie die nächste Iteration einläuten, also wieder auf Lücken und Widersprüche prüfen und die angepassten Module neu strukturieren.Für viele Programmierer hat dies nichts mit Programmierung zu tun und sie haben Recht! Denn dies hat vielmehr was mit Softwareentwicklung zu tun; die Programmierung ist nur ein Teil der Softwareentwicklung, aber eben genau der, den die meisten Softwareentwickler am liebsten mögen. Daher wählen sie oft eine vermeintliche Abkürzung und lassen den ganzen Analyse-, Spezifikations- und Dokumentationskram einfach weg. Der Erfolg gibt ihnen zunächst Recht, denn sie haben sehr schnell ein Stück Software am Laufen - aber die Rache der Software ist stets so groß, dass die gewonnene Zeit schnell wieder aufgebraucht ist - von Stabilität, Wartbarkeit und Widerverwendbarkeit ganz zu Schweigen!In der Regel wird bei der Programmierung der fertig spezifizierten Module die mittlerweile klassische Form der Realisierung mit Funktionen, Variablen, Entscheidungen, Schleifen, usw. eingesetzt. Auch bei der objektorientierten Programmierung sehen beispielsweise die Methoden der Klassen der Geschäftslogik oft sehr strukturiert aus! Es sollten allerdings stets möglichst moderne Verfahren für Fehler-Reporting, Transaktionskontrolle und Protokollierung benutzt werden. Der Entwicklungsrahmen muss natürlich auch Verteilungskonzepte für Server-Landschaften und Skalierbarkeit berücksichtigen.

5.6 Analysemuster (engl. analysis patterns)"Was man zu verstehen gelernt hat, fürchtet man nicht mehr."(Marie Curie)

"Analysemuster" (engl.: "analysis patterns") sind - wie der Name schon sagt - Muster, also wiederkehrende Konstellationen von Irgendwas, die während der Analyse der Anforderungen hochkommen bzw. angewandt werden. Dies kann beispielsweise eine Beziehung zwischen Lieferanten und Kunden sein, die beispielsweise in Form von Ärzten und Patienten, Beratern und Mandanten, Wohnungsverwaltern und Mietern oder schlicht Produzenten und Konsumenten in der Fachlichkeit auftauchen. Typischerweise handelt es sich hier immer um eine 1:n-Beziehung (ein Rechtsanwalt hat viele Mandanten) und beide haben eine Adresse, die die gleiche Struktur hat und deshalb letztendlich in der gleichen Datenbanktabelle geführt wird. Hier kommt es zu einer "Eltern-Kind"-Beziehung (engl.: "Parent-Child"), die gewissen Regeln gehorcht und auf eine bestimmte Art im Datenmodell dargestellt wird. Ein ganz ähnliches Muster findet sich zwischen Organisationseinheiten, seien es Abteilungen oder Niederlassungen eines Unternehmens.

5.7 Anwendungsfälle"Es ist nicht genug zu wissen; man muss es auch anwenden.Es ist nicht genug zu wollen, man muss es auch tun."(Johann Wolfgang von Goethe)

Leistungsbeschreibung, Szenarieneinzelne LeistungsmerkmaleAnwendungsfälle (Use Cases) casual, fully dressed, Sequenzdiagramm, Prototyp (s.u.) Merkmal-Schnittstellen

35


Zerlegung des AF in Seiten oder Dialogfenstern, allgemein "Flächen" zur Darstellung von Aspekten einer bestimmten Anwender-PC-Kommunikation. Diese Assistenten sorgen für gleichmäßige Fragmentierung der AF.

Alistair Cockburn, Humans and TechnologyIm Buch "Writing Effective Use Cases" zitiert Alistair Cockburn sehr passend ein kleines Gedicht des Iren Jonathan Swift:So, naturalists observe, a fleaHath smaller fleas that on him preyAnd these have smaller still to bite 'emAnd so proceed ad infinitum. Ich betone hier deutlich, dass ich aus meiner Erfahrung heraus NICHT mit Cockburn darin übereinstimme, dass es zwei Stile für die Beschreibung von Anwendungsfällen (nämlich casual und fully dressed) gibt und man sich im Projekt für einen der beiden Stile entscheiden wird (S. 9). Vielmehr habe ich festgestellt, dass es Sinn macht, für jede Anwendungsfallbeschreibung einzeln zu entscheiden, welche Form man wählt. Ich halte es manchmal für sehr sinnvoll, einen Anwendungsfall als Sequenzdiagramm oder als Screenshot aus dem Prototypen (s.u.) zu beschreiben. Das sagt manchmal viel mehr aus als jede fully dressed Beschreibung.Akzeptanzkriterien für Anwendungsfälle (mindestens eins) (Rösch Consulting)s. auch "Systematische Tests"z.B. konkretes Beispielkonkrete Ziele definierenabnahmefähig (juristisch stabil)fachlich fehlerfrei! KundenverantwortungAnwendungsfallfragmente zur Wiederverwendung von FachlichkeitenAspektorientierte Programmierung (AOP)

36


Mit den Anwendungsfällen sollten sofort auch die Testfälle erstellt werden.

5.8 Spezifikationsmuster"Wenn zwei Menschen immer dasselbe denken, ist einer von ihnen überflüssig."(Winston Churchill)

Wenn während der Analyse der Anforderungen die konzeptionelle Sicht auf die Fachlichkeit erledigt ist und die Anwendungsfälle alle im Rohbau stehen, wird es Zeit, sich über Prototypen oder Prosatexte für die genauere Spezifikation als Vorgabe für die Implementierung der Programmpräsentation Gedanken zu machen. Hier kommt es zu solchen Diskussionen zwischen Analytiker und Kunde: "Wie wird denn bei Ihnen eigentlich eine Stückliste erstellt?" "Wir nehmen ein neues Stücklistenformular, tragen eine neue Nummer ein und ordnen dieser Liste verschiedene Artikel zu." "Und wie viele Artikel kann eine Stückliste umfassen?" "Oh, das ist ganz verschieden - aber mindestens zwei, sonst ist es keine Stückliste." "Und wir erfolgt die Zuordnung?" "Wir tragen einfach die Nummern der Artikel in das Formular ein."Dieses Beispiel zeigt die Verwendung typischer Begriffe: Liste, erstellen, Formular, eintragen, zuordnen. Solche Worte kommen immer wieder vor und führen in der Regel auch zu einer ähnlichen Implementierung. Statt einer langen detaillierten Prosabeschreibung oder einem Prototypen für die Bildschirmdarstellung könnte man im obigen Beispiel auch einfach schreiben: "Die Nummer der Stückliste wird eingegeben und die Artikel werden zugeordnet." Wenn Analyst und Kunde einmal definiert haben, was "eingeben" und "zuordnen" bedeutet, ist dieser eine Satz schon eine sehr genaue Spezifikation.Immer wieder vorkehrende Elemente, Begriffe oder Konstellationen werden auch als "Muster" bezeichnet. In diesem Fall dienen die erkannten Muster zur Vereinfachung der Spezifikation, daher bezeichne ich sie als "Spezifikationsmuster" (englisch Specification Patterns). Ich muss allerdings betonen, dass es sich hierbei jetzt nicht um ein allgemein bereits anerkanntes oder gar genormtes Instrument handelt. Betrachten Sie diese Art der Muster als Vorschlag meinerseits. Ich verwende sie derzeit in einem recht großen Projekt und alle Beteiligten kommen sehr gut damit klar.Ich unterscheide zwischen Spezifikationsmustern zur "Ablaufsteuerung", mit denen der Bedienfluss innerhalb der Software gesteuert wird und Mustern zur "Inhaltssteuerung", mit denen die Erfassung und Darstellung von Informationen gesteuert wird. Da die Visualisierung der Muster bei einem Windows-Programm anders ist als bei einer Internetseite oder auf einem WAP-Handy, versuche ich, die optische Darstellung so neutral wie möglich zu beschreiben und eine Form zu wählen, für die es bei jeder erdenklichen Oberfläche eine Implementierungsmöglichkeit gibt. Auf jeden Fall sind die Spezifikationsmuster von der Fachlichkeit des Kunden unabhängig, so dass sie für alle neuen Kunden, Branchen und Projekte wieder verwendet werden können.Die Spezifikationsmuster sind teilweise sehr einfach und atomar, teilweise aber auch sehr komplex und setzen sich aus weiteren Spezifikationsmustern zusammen oder verwenden weitere Muster in variabler Anzahl und Kombination.5.8.1 Spezifikationsmuster zur AblaufsteuerungEin Assistent führt den Anwender schrittweise durch einen programmierten Ablauf und sammelt auf seinem Weg Informationen ein, nimmt Einstellungen vor oder führt abhängige Arbeiten aus. Ein Assistent besteht typischerweise aus einer oder mehreren "Flächen". Das Spezifikationsmuster "Assistent" kann für das Analysemuster "Arbeitsprozess" angewandt werden.

37


Einen "Assistent" zeichne ich sehr gerne mit Microsoft Visio als UML-Diagramm vom Typ "Aktivitätsdiagramm". Dabei stellen die einzelnen Zustandskästchen "Flächen" dar und die Kontrollflusspfeile die Schritte beim Übergang von einem Zustand zum anderen (in der Regel ausgelöst durch "Aktionen" oder "Detaillierungen").Das hier gezeigte Beispiel stammt aus einem umfangreichen Intranetprojekt; die "Flächen" sind also Webseiten und die typische Abfolge ist 1-2-3. Die vierte Seite wird in einem zweiten Browserfenster als reine Infoseite angezeigt (da gibt es als Navigation nur die Möglichkeit, den Browser zu schließen; Infoseiten wurden in diesem Projekt in den Assistentendiagrammen immer grau dargestellt). Die Seiten 5 und 6 sind in diesem Beispiel alternative Pfade für Anwender mit höheren Berechtigungsstufen. Der Endzustand wird in diesem Beispiel typischerweise durch Ausstieg aus Seite 3 erreicht, indem der Browser dort geschlossen wird.Inhaltlich geht es hier darum, dass in den Seiten 1 und 2 inhaltlich erst zwei Angaben spezifiziert werden, wodurch ein Thema so eingekreist wird, dass dessen Daten auf Seite 3 zur Bearbeitung zur Verfügung gestellt werden können. Seite 5 dient zum Erfassen neuer Themen und der Weg von 3 nach 2 beschreibt das Löschen eines Themas. Ein gelöschtes Thema kann durch Neuerfassen in 6 reaktiviert (bzw. reanimiert) werden (es wird nämlich nicht endgültig gelöscht, sondern nur zum Löschen markiert).In der Anforderungsanalyse wird bei dem Anwendungsfall genau dieses Diagramm dargestellt und jede einzelne Seite beschrieben. Die Beschreibung erfolgt dabei tabellarisch und bezieht sich auf die Nummern im Diagramm:

1. erste Angabe spezifizieren

Input - -

Output 1 erste Angabe

Datenbank -

Beschreibung "Suche" erste Angabeeine "Aktion" zum Wechseln auf Seite 2

2. zweite Angabe spezifizieren

Input 1 erste Angabe

Output1 erste Angabe

2 zweite Angabe

Datenbank -

Beschreibung

Input 1 als "Text""Suche" zweite Angabeeine "Aktion" zum Wechseln auf Seite 3eine "Aktion" Neu zum Wechseln auf Seite 5

...

Ein "Assistent" kann also zum Installieren eines Druckers in mehreren Schritten genauso benutzt werden wie für eine Hilfe in einem Helpdesk-System, das Erstellen eines Serienbriefes in einer

38


Textverarbeitung oder das Anlegen einer Stückliste in einer Warenwirtschaft. Allgemein formuliert ist dieses Spezifikationsmuster immer sinnvoll, wenn der Anwender in mehreren Schritten durch einen komplexen Ablauf geführt werden soll.Eine Fläche dient zur Aufnahme weiterer Spezifikationsmuster und führt damit einerseits zur Kapselung dieser Muster und andererseits zur Isolation dieser Muster gegen andere. Dadurch wird die Widerverwendbarkeit von bestimmten Muster-Konstellationen vereinfacht. Ein Fenster (bei einer Windows-Anwendung) oder eine Seite (bei einer Internet-Anwendung) besteht in der Regel aus einer Fläche und einem zusätzlichen Satz von "Aktionen" wie beispielsweise OK und Abbrechen oder vor und zurück.Die Datenerfassung gruppiert mehrere Spezifikationsmuster auf einer "Fläche" zur Erfassung eines bestimmten Satzes von Daten. Dabei kann es sich beispielsweise um ein automatisch generiertes Formular zur Pflege einer Datenbanktabelle handeln. Auf einer Internetseite wird dieses Muster typischerweise auch als form implementiert. Dieses Beispiel zeigt die "Datenerfassung" eines Beleges:

Hier ein äußerst komplexes Beispiel zur täglichen "Datenerfassung" von Dosierungen bei einem Herzmedikament (in diesem Fall habe ich allerdings statt der Prosabeschreibung mit Spezifikationsmustern einen Prototyp in Visual Basic entworfen):

39


Eine Aktion wird immer auf die gleiche Art ausgeführt und präsentiert sich dem Anwender als feste Programmfunktion. Dieses Muster wird typischerweise als Schaltfläche implementiert, ein Steuerelement, das es bei nahezu allen Entwicklungsumgebungen gibt.Bei einigen Oberflächen gibt es frei programmierbare Tasten: für Microsoft Windows gibt es Tastaturen mit kleinen Displays in den Tastenkappen, die von Anwendungen frei belegt werden können und bei Mobiltelefonen (in Deutschland Handys genannt) gibt es häufig direkt unter dem Display zwei Tasten, deren Bedeutung vom Programm situationsabhängig definiert und am unteren Rand des Displays in der Nähe der Tasten erläutert wird.Ein "Assistent" endet oft mit einer "Fläche", in der eine "Aktion" zum permanenten Speichern der Information angeboten wird. Diese "Aktion" sollte nur den Speichervorgang selbst durchführen und keine Navigation zu einer anderen "Fläche" irgendeiner Form vornehmen. Wenn dies gewünscht ist, sollte die "Aktion" anders lauten, z.B. Speichern und Beenden, Speichern und Weiter oder OK."Aktionen" wie Neu hingegen implizieren einen Wechsel zu einer anderen "Fläche", so dass diese Zusatzaktion nicht separat mit genannt werden muss.An vielen Stellen soll der Anwender die Möglichkeit haben, zu einer Information eine Detaillierung durchzuführen, also weitere Details abzurufen. Es handelt sich hier eigentlich um eine "Aktion", aber um eine sehr gebräuchliche, die noch dazu fest mit dem Inhalt gekoppelt ist. Bei vielen Oberflächen ist es möglich, die zu detaillierende Information selbst besonders hervorzuheben und mit einer speziellen "Aktion" fest zu verdrahten. Ein gutes Beispiel ist der Hyperlink im Internet: er zeigt immer auf die Seite, die den Begriff, der als Link dargestellt ist, detailliert.Bei der "Detaillierung" wird also eine einzelne inhaltliche Information angeboten, die weiter detailliert werden kann. Ein Beispiel dafür ist die Suche nach Stücklisten, die einen bestimmten Artikel enthalten: das Ergebnis wird wahrscheinlich mehrere Stücklisten umfassen und es soll wahrscheinlich die Möglichkeit geben, zu jeder dieser Stücklisten den Inhalt (also weitere Details) abzurufen, um prüfen zu können, welche die richtige ist. Jede Stückliste wird also sicherlich als "Detaillierung" dargestellt.Bei einer Intra-/Extra-/Internet-Applikation würde hier die Wahl der Darstellung sicherlich auf einen Link fallen, wie folgendes Beispiel aus www.ebay.de bei der Suche nach "Nikon 24" zeigt (dies ist nur ein Beispiel, daher sind die links selbst hier ohne Funktion):

Objektive (Autofokus) (31)Foto-Zubehör (14)Spiegelreflex-Kameras (4)Objektive (Manueller Fokus) (2)

Das gleiche Beispiel finden Sie übrigens bei dem Spezifikationsmuster "Liste", weil dieses sich aus "Detaillierungen" zusammensetzt.Ein Menü bietet immer eine Auswahl an Programmfunktionalität und unterscheidet sich dadurch deutlich von der "Liste", die ausschließlich Werte (Daten) enthält. Das "Menü" wird in der Regel mehrstufig aufgebaut sein und sich inhaltlich von Stufe zu Stufe verfeinern. In jedem Softwaresystem sollte nur ein einziger Menübaum existieren. Menüs kommen in jeder Software vor, die eine graphische Oberfläche hat, da es sich hierbei um die gängigste Form des Angebots der Funktionalität handelt. Nebenstehend ein Ausschnitt des Microsoft Internet Explorers mit aufgeklappten Menüs.

40


Im Internet werden ebenfalls Menüs für die Wahl des Inhalts einer Website angeboten. Dabei wird häufig das Verhalten von Software mit graphischer Oberfläche nachgebaut wie nebenstehendes Beispiel sehr schön zeigt.Hier werden die Menüpunkte "Kläranlagen" und "Pumpwerke / Deiche" erst eingeblendet, wenn der Anwender auf den Menüpunkt "Erklärte Technik" klickt. Die farbliche Veränderung zeigt dem Anwender in diesem Fall stets, wo er zuletzt geklickt hat.Auch ein extrem großer Inhalt lässt sich mit gewissem Geschick vernünftig in ein Menü packen. Dies ist das Hauptmenü von www.microsoft.com, sicherlich eine der größten Websites, die es gibt:

Letztendlich ist auch das Inhaltsverzeichnis eines Buchs oder meiner Abhandlung, in der Sie momentan lesen, eine Art von Menü, da Sie eine Auswahl über den Inhalt bekommen und mit den Augen im Inhaltsverzeichnis so lange weiter verzweigen, bis Sie die gewünschte Inhaltsangabe gefunden haben. Nichts anderes tun Sie mit der Maus in einem Programm-Menü, wenn Sie eine Funktion des Programms suchen. Hier bietet sich allerdings der technische Vorteil, dass die Menüs von Ebene zu Ebene dynamisch geöffnet werden können, so dass nicht das gesamte Angebot auf einmal zu sehen sein muss.Auch bei zeichenorientierten (d.h. nicht-graphischen) Programmen gibt - oder besser: gab - es Menüs. Wie der Screenshot nebenan zeigt, werden hier die Funktionen natürlich nicht mit der Maus gewählt, sondern durch die Eingabe eines entsprechenden Buchstabens.Der Screenshot zeigt übrigens auch, dass es sehr wohl unter zeichenorientierten Systemen (z.B. MSDOS oder alten Unix) schon fensterorientierte Programme gab (davon habe ich sogar mehrere Jahre gelebt!), denn die Rahmenzeichen boten die Möglichkeiten, auf dem Bildschirm "Flächen" abzustecken. So wurde hier bei der Auswahl eines Menüpunkts teilweise versetzt ein weiteres Menüfenster geöffnet, in dem eine weitere Auswahl stattfinden konnte.Die Kaskade ist von Wasserfällen her bekannt, wo das Wasser in mehreren Stufen bis auf das tiefste Niveau fällt. Es gibt in Softwaresystemen häufig Inhaltsbereiche, die sich stufig innerhalb einer "Fläche" ergeben. Oft sind zwischen diesen einzelnen Stufen "Aktionen" des Anwenders erforderlich. Ein "Menü"baum kann auch als "Kaskade" betrachtet werden; das passt allerdings nicht ganz, weil ein "Menü" ausschließlich Funktionalitäten des Programms enthält, wogegen eine "Kaskade" sich vorrangig mit Daten beschäftigt.5.8.2 Spezifikationsmuster zur InhaltssteuerungFester, statischer Text auf einer "Fläche" dient der reinen Ausgabe einer Beschreibung, Bezeichnung oder Information. Der "Text" kann nicht durch den Anwender geändert werden kann. "Text" ist wohl das einfachste Spezifikationsmuster, schon allein deshalb, weil es statisch ist, also keine weitere Funktionalität besitzt (es passiert nichts!). Sie erfassen "Text" in Ihrer Textverarbeitung und Sie lesen "Text" in einem Buch oder einer Zeitschrift. 90% des Internets besteht aus "Text". Dieser Absatz, den Sie momentan lesen, besteht übrigens aus purem "Text".

41


Der "Text" Straße: dient hier zur Beschreibung der "Eingabe":

Straße: Eine Eingabe dient dem Anwender zum spezifizieren des Datenteils einer Information. Im Gegensatz zum "Text" kann die "Eingabe" vom Anwender geändert werden. Eine "Eingabe" kann auch leer sein, das Programm muss darauf entsprechend reagieren. Wenn ein Anwender nicht das Recht zum ändern hat, so sollte die "Eingabe" deutlich sichtbar gesperrt werden oder besser gleich stattdessen als "Text" angezeigt werden. Die "Eingabe" ermöglicht es dem Anwender, in einem dafür vorgesehen reservierten Flächenbereich einen dynamischen Text zu erfassen. Dies kann der Name des Anwenders sein, ein Kennwort, eine Angabe für eine Schriftgröße, ein Straßenname, eine Projektnummer oder irgendeine andere Angabe. Der Anwender erkennt den gewünschten Typ der Angabe durch einen Bezeichnungstext, der über oder links neben der "Eingabe" angezeigt wird.Die Voreinstellung (englisch default) dient der Software als fest eingestellter Vorschlag für eine bestimmte noch leere "Eingabe" bei deren erster Verwendung. Es handelt sich also um einen in der Regel vom Kunden festgelegten Startwert. Eine "Voreinstellung" (englisch default) dient dem Setzen eines Standardwertes. Wenn der Anwender keinen anderen Wert definiert, wird dieser in der Software voreingestellte Wert genommen. Die Voreinstellungen in der Software müssen sehr sorgfältig während der Analysephase definiert werden, damit sie von den Entwicklern (möglichst konfigurierbar) implementiert werden können und dem Anwender zur Verfügung stehen. Wenn sich also Ihr Analysedokument durch detaillierte Angaben in eine Spezifikation wandelt, sollten die "Voreinstellungen" darin genannt werden.Beispiele für "Voreinstellungen" in Programmen sind das Verzeichnis für Speichern unter in einer Textverarbeitung und die am meisten benötigte Mehrwertsteuer in einer Warenwirtschaft genauso wie die gebräuchlichsten Antworten in Fragebögen und das Folgejahr des aktuellen Wirtschaftsjahres für die Budgetplanung.Oft soll der Anwender die Möglichkeit der Wahl eines Wertes aus einer Menge von mehreren Werten haben. Dabei wird diese Menge möglichst nur kurz angezeigt und der gewählte Wert bleibt stehen. Eine typische Implementierung mit VisualBasic ist die Combobox, mit HTML der Select. Eine Erweiterung ist die "Wahleingabe" und eine besondere Rolle spielt die "Ja/Nein-Wahl" sowie die "Optionen-Wahl".Mit der "Wahl" kann der Anwender einen Punkt aus vielen wählen. Dies ist häufig erforderlich, um das Programm fortsetzen zu können: ein Projekt muss gewählt werden können, damit die Daten zum Projekt erfasst werden können, eine Zugverbindung von vielen muss gewählt werden, damit die Buchung erfolgen kann und ein Standort von allen möglichen muss gewählt werden, damit das passende Kassenbuch geöffnet werden kann.Standardmäßig werden die einzelnen Elemente, die zur "Wahl" stehen, aufsteigend sortiert (also nach unten wachsend); wenn absteigende Sortierung gewünscht ist, sollte dies bei der Nutzung des Musters in Klammern angegeben werden. Findet für die "Wahl" eine Einschränkung der Gesamtmenge statt, so sollte dies ebenfalls in der Spezifikation angezeigt werden (beispielsweise: "Wahl aus allen Projekten vom aktuellen Jahr an absteigend").Die "Wahleingabe" ist die Erweiterung der "Wahl" um eine "Eingabe". Während bei der reinen "Wahl" nur aus den vorhandenen Elementen der Wertemenge gewählt werden kann und bei der "Eingabe" immer ein individueller Wert eingegeben werden muss, kann bei der "Wahleingabe" entweder ein Wert aus der Menge gewählt werden oder auch individuell ein Wert eingegeben werden, der nicht in den Vorschlägen der Menge enthalten ist.Mit der "Ja/Nein-Wahl" kann der Anwender eine Entscheidung treffen. So kann er kennzeichnen, ob er eine Datei, deren Name in der Nähe der Ja/Nein-Wahl steht, löschen möchte, oder ob er die Seiten in umgekehrter Reihenfolge drucken möchte, oder dass er die AGB vor der Bestellung gelesen hat. In einer Internet-Applikation kann die Ja/Nein-Wahl wie folgt aussehen:

Protokoll beim Schließen versenden Bei einer "Optionen-Wahl" kann der Anwender wie bei der reinen "Wahl" eine einzige Option aus mehreren Möglichkeiten wählen. Während die reine "Wahl" in der Regel für

42


Daten gilt, wird eine "Optionen-Wahl" in der Regel für Funktionalitäten oder Programmkonstanten genutzt. So könnte die Entscheidung für ein Papierformat vor dem Drucken (A4, A5, Letter) über eine "Optionen-Wahl" getroffen werden, oder die Benachrichtigungsmethode des Administrators bei einem Netzwerkfehler (Pieper, Handy, eMail, Fax), oder die Art der Zahlung beim Online-Kauf (Kreditkarte, Barnachnahme, Vorabüberweisung). In einer Internet-Applikation kann die "Optionen-Wahl" wie nebenstehend aussehen.Eine Liste enthält eine lineare Anordnung (Aufzählung) von "Detaillierungen". Jeder einzelne Punkt dieser "Liste" ist also ein Spezifikationsmuster für die Ablaufsteuerung, aber die "Liste" selbst dient als Ganzes der Darstellung von Inhalt.Eine "Liste" ist oft das Ergebnis einer Suche oder dem allgemeinen Abruf von Informationen. Die Liste stellt jedes Element als "Detaillierung" dar. Dabei wird typischerweise jede "Detaillierung" in einer eigenen Zeile dargestellt, so dass die "Liste" sich von oben nach unten aufbaut.Standard ist aufsteigend (also nach unten wachsend); wenn absteigend gewünscht ist, sollte dies bei der Nutzung des Musters in Klammern angegeben werden. Dies kann beispielsweise bei einem Archiv der Fall sein, wo die neuesten Dokumente zuerst (also oben) gelistet werden sollen.Folgendes Beispiel aus www.ebay.de zeigt als Ergebnis der Suche nach "Nikon 24" folgende "Liste" (dies ist nur ein Beispiel, daher sind die "Detaillierungen" selbst hier ohne Funktion):

Objektive (Autofokus) (31)Foto-Zubehör (14)Spiegelreflex-Kameras (4)Objektive (Manueller Fokus) (2)

Das gleiche Beispiel finden Sie übrigens bei dem Spezifikationsmuster "Detaillierung", weil die "Liste" sich ja aus "Detaillierungen" zusammensetzt.Die Festlegung ähnelt sehr stark der "Liste", aber zusätzlich gibt es zu jeder "Detaillierung" noch die Zusatzaussage, ob das Element ausgewählt ist für Irgendwas oder nicht. Damit ergänzt die "Festlegung" die "Liste" um eine Art Filter. In der Regel wird hier festgelegt, welche Elemente für bestimmte "Aktionen" benutzt werden sollen und welche nicht. Bevor der Anwender die Elemente festlegt, kann er sich anhand der "Detaillierung" noch über die einzelnen Elemente informieren.Die "Festlegung" als mehrzeilige Kombination der "Liste" (die aus "Detaillierungen" besteht) und der "Ja/Nein-Wahl" kann in einer Internet-Applikation beispielsweise wie folgt aussehen:

Eine Tabelle ist eine Matrixanordnung von Daten, also so etwas wie eine zweidimensionale "Liste", also eine Übersicht von einem Wertetyp über einem anderen. Ein Teil der "Tabelle" kann auch wie eine "Liste", als einzelne "Detaillierung", als "Eingabe" oder einfach als "Text" ausgeprägt sein.Eine "Tabelle" ist hervorragend zur Eingabe oder Darstellung von Rabattstaffeln für Warengruppen oder Verkaufsstatistiken von Produkten oder Fragebogenantworten verschiedener Probanden oder monatlich abgegebenen Leistungsstandprognosen oder Parametern von Standorten (Niederlassungen) geeignet. In dieser Abhandlung benutze ich eine "Tabelle" beispielsweise zur Darstellung der Buchreferenzen (s. Links)Oft werden "Tabellen" in Datenbanken gespeichert; dann stellt eine Zeile der "Tabelle" meistens einen Datensatz dar und jede Spalte einer Zeile ein Feld innerhalb des Datensatzes. Zur Eingabe oder Bearbeitung einer "Tabelle" kann die "Kaskade" zum Einsatz kommen.Auf einer Internet-Seite wird eine Tabelle mit dem entsprechenden HTML-Element (<table>...</table>) gebildet, in Microsoft Visual Basic beispielsweise mit einem DataGrid-Objekt.Die Zuordnung ist quasi eine "Wahl" einiger Elemente aus vielen (die "Wahl" selbst kann nur genau eins aus vielen wählen). Der Anwender hat nicht wie bei der "Liste" die Möglichkeit, sich über die einzelnen Elemente zu informieren, weil diese nicht als "Detaillierung" ausgeprägt sind. Dafür kann der Anwender aber aus einem Vorrat beliebig viele Elemente einzeln wählen und einzeln abwählen.

43


Ideal ist es, wenn der Anwender dabei eine Gegenüberstellung der bereits gewählten (links) und der noch wählbaren (rechts) Elemente sieht.

Mitarbeiter können Abteilungen zugeordnet werden, Anwendungsfälle können Akteuren zugeordnet werden, Rechte können Anwendern zugeordnet werden (vielleicht auch anders herum), Artikel können Stücklisten zugeordnet werden, Wohneinheiten können Objekten zugeordnet werden, Belege können Kassenbüchern zugeordnet werden, Verträge können Kunden zugeordnet werden, Stückgut kann LKWs zugeordnet werden, Bachläufe können Gebieten zugeordnet werden, Turnierpferde können Prüfungen zugeordnet werden, etc. etc. etc.

Die Einstellung ist deutlich mehr als die "Eingabe". Sie wird immer dann genutzt, wenn ein Wert nicht einfach so eingetippt werden kann, sondern erst eine Ermittlung des Wertes erfolgen muss. Daher bietet die "Einstellung" eine separate "Fläche" zur Spezifikation des Wertes über die "Suche" oder prüft vor Akzeptanz des Wertes erst noch Plausibilitäten oder führt noch komplexe Zusatzaktionen aus. Die "Einstellung" eines Wertes wird häufig auch einmalig für mehrere "Aktionen" gleichzeitig durchgeführt, um den Dialog mit der Software zu vereinfachen.Bei nebenstehendem Diagramm sehen Sie oben und unten die gleiche Internetseite, oben vor und unten nach der "Einstellung". Die "Einstellung" selbst erfolgt in der anderen Seite, die hier in der Mitte dargestellt ist. Zur Vereinfachung wird hier die "Einstellung" nur über eine "Eingabe" vorgenommen. In Wirklichkeit würde hier sicherlich ein kompliziertes Prozedere, beispielsweise verbunden mit einer "Suche", durchgeführt.Beispielsweise kann auch über mehrere voneinander abhängige "Wahlen" zu einem Auto erst die Marke, dann die Baureihe, dann die Karosserieform und schließlich die Motorleistung gewählt werden, nur um letztendlich anhand dieser "Wahlen" automatisch berechnet die Typklasse für die Versicherung "einzustellen".Das Ergebnis der "Einstellung" kann dann auf der Ursprungsseite auch mit einer "Detaillierung" verbunden sein, über die der Anwender weitere Informationen zum festgelegten Wert erhalten kann. Aber auch die hier gezeigte "Eingabe" kann als separate "Einstellung" Sinn machen, wenn damit beispielsweise nicht nur das Projekt "eingestellt", sondern ggf. auch ein neues Projekt generiert werden kann. Dann müssen sicherlich noch weitere Informationen beim Anwender erfragt werden.Bei einem Archivsystem wird vielleicht einfach nur ein Dokument zur weiteren Bearbeitung eingestellt, aber dabei auch gleichzeitig von einer Bildplatte eines Archivturms gelesen und dort mit einem neuen Barcode als entnommen gekennzeichnet.Eine "Einstellung" erfolgt häufig auch für einen gewissen Zeitraum. Wenn ein Projektleiter etliche Daten für ein Projekt erfassen und verschiedenste Funktionen dafür aufrufen muss, so wird er dankbar sein, wenn er die Projektnummer einmal "einstellen" kann und alle folgenden Aktionen dann automatisch für diese Projektnummer erfolgen.

44


Ich finde den Begriff "Einstellung" sehr passend, weil die Anwender damit häufig mechanische "Einstellungen" über Rädchen und Tasten verbinden; solche Einstellungen gelten auch immer für einen gewissen Zeitraum. So denken viele an die "Einstellung" der Zündung an ihrem Auto oder die "Einstellung" ihrer Heizung oder die optimale "Einstellung" ihres PC-Monitors. Alle diese "Einstellungen" müssen leider auch regelmäßig wieder vorgenommen oder geändert werden.

Anhand der Suche können Werte recht aufwändig ermittelt werden. Hier können mehrere andere Spezifikationsmuster kombiniert werden, um dem Anwender einen gewissen Komfort zu bieten. Die "Suche" kann auch bei der "Einstellung" mitbenutzt werden.Eine "Suche" erfolgt in der Regel mehrstufig oder nach mehreren Kriterien. Im nebenstehenden Beispiel wird ein passender Projektleiter für ein neues Projekt "gesucht". Dafür werden erste einige Kriterien vorgegeben und über die "Aktion" suchen wird dann die "Wahl" gefüllt. Hieraus kann der Anwender mit einem einzelnen Klick einen gewünschten Projektleiter bestimmen, der letztendlich als "Detaillierung" dargestellt wird; darüber kann der Anwender noch einige Informationen zum Projektleiter abrufen, um sich endgültig zu vergewissern, den Richtigen gefunden zu haben.Sie kennen ähnliche "Suchen" vielleicht von Internetseiten der DB (Zugverbindung), Teleauskunft (Telefonnummer), Expedia (Hotel) oder Wetter (Vorhersage) (alle jeweils www.x.de).5.8.3 Weitere GedankenSie erhalten durch diese Muster die Möglichkeit, mit einem einzigen Prosasatz den Prototyp für eine ganze Funktion darzustellen. Es könnten Ihnen als Analytiker also passieren, dass Sie irgendwann einen Anruf vom Kunden erhalten und folgenden Satz hören: "Können wir den Assistenten von Anwendungsfall 85 noch so ergänzen, dass er auf der Seite 1 eine absteigende Liste von Jahreszahlen mit Detaillierungen zum Wechseln auf Seite 2 und eine Aktion "Ändern" zum Wechseln auf eine neue Seite 4 enthält?" Beide haben dann automatisch das gleiche Bild vor Augen und können präzise Funktionalität und Aufwand aushandeln - und zwar am Telefon!Spezifikationsmuster helfen beim Erlangen der Implementierungssicherheit für das zu erstellende Softwaresystem, denn die Implementierbarkeit eines solchen Musters ist sicherlich auf allen gängigen Systemen gegeben. Wenn sich also ein Anwendungsfall weitgehend anhand der Spezifikationsmuster beschreiben lässt, so steht der Implementierung eigentlich nichts mehr im Wege.Im ersten Moment könnte man denken, dass Spezifikationsmuster sich nur auf den Presentation Tier beziehen, weil sie die Interaktion zwischen Anwender und Software beschreiben und stets sehr gut helfen, sich einfacher ein Bild zu verschaffen als durch den Bau eines Prototyps. Aber bei vielen dieser Muster sind Business Tier und Data Tier sehr wohl beteiligt: wenn beispielsweise im Gewächshaus die Messwerte mehrerer Fühler in mehreren Kaskaden mit Zusatzinfos erfasst werden, so muss bei jeder Kaskade eine Interaktion mit dem Business Tier stattfinden, um den Messwert des nächsten Fühlers zu holen, und nachdem der Wert mit Zusatzinfos versehen ist, muss er vom Business Tier nochmals validiert und an den Data Tier zur permanenten Speicherung weiter gereicht werden.

5.9 Prototyp"Wenn dir das Leben Zitronen serviert mach einfach Limonade draus!"(Unbekannt)

45


Es gibt jedoch viele Fälle, wo die Spezifikationsmuster allein nicht reichen. Dies kann daran liegen, dass die Situation einfach zu komplex ist, aber auch daran, dass ein Linienvorgesetzter, der das Vokabular und die Methodik natürlich nicht beherrschen kann, eine teure Entscheidung fällen muss. Oft sollen aber auch die gewählten Vertreter der Akteure sich vorab ein Bild von ihrer zukünftigen Software machen können, um noch Einwände oder Anregungen äußern zu können. Vielleicht will sogar der Vertreter des Kunden selbst gerne mit seinen Pilotanwendern Vorschläge erarbeiten. Dann ist es erforderlich, mit möglichst einfachen Mitteln einen möglichst realistischen Prototypen auf den Bildschirm zaubern zu können.

Dafür kann schon die Erstellung eines statischen Screenshot-Prototyps mit Microsoft PowerPoint oder Microsoft Visio ausreichen. Dies hat dann auch den Vorteil, dass man auf evtl. vorhandene "Photos" von ähnlichen Bildschirmen zurückgreifen kann, die man nur noch ergänzen muss. Gerade Visio hat sich bei mir super bewährt, denn dort kann man sich eine eigene "Schablone" erstellen, die wie eine Toolbox

Standardelemente aufnimmt, die man dann durch Anklicken auswählen und sofort verwenden kann. Per Maus kann man Logos, Texte, Windows-Elemente (sehen echt aus, aber können nichts), Pfeile, Beschriftungsschildchen und viele andere spannende Dinge einfach auf die Schablone ziehen und weiter verwenden. Damit sind Entwürfe für Fenster oder Seiten wirklich in Minuten gemeinsam mit dem Kunden gebaut und schaffen ein Bild der Lage.Dynamische ("funktionierende") Prototypen können natürlich mit einem einfachen System statt der geplanten Echtumgebung (beispielsweise Access statt VB/SQL-Server) realisiert werden. Der Aufwand ist aber auf jeden Fall größer als bei einem statischen Prototyp, und in Zeiten, wo eigentlich jeder den Umgang mit Software gewohnt ist, reichen die statischen Prototypen zur Vorstellung des endgültigen Programms eigentlich schon aus. Früher, als wir noch Software für Leute entwickelt habe, die noch nie in ihrem Leben vor einem PC gesessen haben, war ein dynamischer Prototyp zwingend erforderlich.Auch heute noch ist übrigens der Spielraum bei der Realisierung so groß, dass es durchaus völlig verschiedene Wege für die Umsetzung eines Problems gibt. Hier eine geschickte, ergonomische und technisch sichere Variante zu finden, erfordert manchmal eine Menge Übung und Erfahrung. Aber oft gelingt es doch, im Sinne des Spruchs oben, das Beste draus zu machen.Es kann aber auch aus technischen Gründen erforderlich sein, einen - oder sogar mehrere - Prototypen zu bauen. Wenn der Anbieter beispielsweise noch keine Projekte auf der geforderten Plattform realisiert hat oder eine neue Technologie zum Einsatz kommen soll oder Zweifel an der Realisierung der Performance bestehen, können die Architekten, Designer und Entwickler ohne Rücksicht auf

46


Programmierkonventionen oder Dokumentation Prototypen zusammenschießen, um zu prüfen, ob die aufgestellten Gedanken richtig sind.Ein Prototyp ist kein Umweg! Zwar weiß man nach einem Projekt nicht, wie viel Zeit man durch einen Prototypen insgesamt gespart hat, aber der Vergleich zwischen ähnlichen Projekten mit und ohne Prototyp hat gezeigt, dass sich der Aufwand für den Auftraggeber bezahlt macht! Einige meiner eigenen Projekte wären ohne Prototyp gnadenlos gescheitert, weil nach der Diskussion des Prototyps die Gestaltung der Software massiv geändert wurde. Einmal wurde sogar wegen Uneinigkeit der Beteiligten über den Prototyp das ganze Projekt verworfen! Aber vielleicht lag es ja auch daran, dass elf Leute darüber diskutiert haben! Doch wie wäre das Projekt wohl abgelaufen, wenn es diesen Prototyp nicht gegeben hätte? Dies zeigt, dass man als Anbieter den Prototyp nicht nur unter dem Aspekt der gewonnenen Zeit verkaufen sollte.Wie bereits beim Prototypen/Casey-Modell im Kapitel Modelle beschrieben, wird der Prototyp weggeworfen, schließlich ist es nur ein Prototyp: "Plan to throw one away; you will, anyhow." ("Planen Sie, einen wegzuwerfen; sie werden es sowieso.") [B10]. Hier sind sich nun wirklich alle einig (auch [B4] und [B12] beziehen sich auf [B10]). Sie sollten wirklich niemals den Prototyp in ein Echtsystem wandeln, denn Sie haben bei der Entwicklung des Prototyps per Definition die vereinbarten Konventionen nicht eingehalten, keine Fehlerbehandlung eingebaut, nicht systematisch getestet und keine Dokumentation erstellt!

5.10 Testfälle"Die meiste Zeit geht dadurch verloren, dass man nicht zu Ende denkt."(Alfred Herrhausen)

separates Dokument priorisiert Zeitdauer stoppen aus Anwendersicht mit den Anwendungsfällen zusammen erstellenkann teilweise sogar der Kunde (Anwender) erstellen oder zumindest daran mitarbeiten

5.11 Dokumente"Es macht keinen Sinn, präzise zu sein, wenn man überhaupt nicht weiß, wovon man spricht."(John von Neumann)

Pre-Analyse/Analyse/SpezifikationProtokolleProjektplanEinsatzplanReleaseplanRisikoanalyse"We usually foresee the future by reviewing the past, seeking longterm trends."(dt.: "Wir sehen die Zukunft im allgemeinen vorher, indem wir die Vergangenheit prüfen und nach lang anhaltenden Trends suchen.")("Deep Time" by Gregory Benford) Kunde vergibt Prioritäten (hoch, mittel, niedrig) für Anwendungsfälle nach WichtigkeitAnalytiker legt Risikograd für Anwendungsfälle festAnwendungsfälle auf Iterationen verteilen (höchstes Risiko zuerst!)Aufwand für Anwendungsfälle schätzen (Mitarbeiter einbeziehen, Verantwortung delegieren, Expertenbefragungen, mehrere Schätzungen)Manpower kalkulieren+20% für Übergabe, +20% Buffer

47


Iterationsintervalle als Meilensteine definieren (MS Project)Projektmanagement selbst als Aufwand berücksichtigenJedes Projekt entwickelt auch eigene Fachlichkeiten und damit ein eigenes Vokabular. Modern sind dabei die TLA geworden: Three Letter Acronyms (dreibuchstabige Abkürzungen). Ironischerweise ist TLA selbst ein Beispiel für eine TLA. Abkürzungen, aber auch Fachbegriffe des Kunden sowie technische Begriffe aus der IT sollten in einem Glossar geführt werden, in dem jeder Projektteilnehmer, jeder Pilotanwender oder einfach jeder Interessierte jederzeit nachschlagen kann. Glossar nur für Fachwörter des Auftraggebers und -nehmers, nicht für Informationen, Daten oder Algorithmen des Softwaresystems; diese gehören in die Spezifikation selbst.The future IS uncertain!The spec IS incomplete!80% IS enough!20% buffer time IS minimum!"The Answer to the Great Question ... of Life, the Universe and Everything ... is ... Forty-two."("The Hitchhiker´s Guide to the Galaxy" by Douglas Adams, Chapter 27 - dt. "Die Antwort auf die Große Frage ... nach dem Leben, dem Universum und allem ... lautet ... Zweiundvierzig." aus " Per Anhalter durch die Galaxis" von Douglas Adams, Kapitel 27)

5.12 Gesamt-Anwendungsfalldiagramm"Einen bitteren Schluck sollte man nicht auf mehrere Gläser verteilen."(Unbekannt)

Beziehungenenthält (includes, uses): LinkGeneralisierung (generalization): Alternativenerweitert (extends): AbleitungBasis-AnwendungsfälleVarianten-AnwendungsfälleGeschäftsanwendungsfälle (Kunde, Ereignis)Systemanwendungsfälle (Software)

48


6 Design

6.1 Realisierung"Wer steilen Berg erklimmt, hebt an mit ruhigem Schritt."(William Shakespeare)

Spätestens nach Abschluss der Analyse wird ein Resümee über Machbarkeit und Sinnhaftigkeit gezogen. Dies kann dazu führen, dass das gesamte Projekt wegen zu hoher Risiken verworfen wird, wegen einer zu langen Zeitachse portioniert wird oder wegen der Überschreitung finanzieller Schwellen in Vergleichsangebote oder Ausschreibungen läuft.Ich selbst habe auch schon ein Projekt erlebt, bei dem in der Mitte der Analysephase ein Zwischenresümee ergeben hat, dass die Anforderungen keineswegs einzigartig sind und wahrscheinlich von Standardprodukten abgedeckt werden können. Hier bestand die Gefahr, dass für einen einzelnen Kunden individuell ein Standardprodukt in der n-ten Ausprägung entwickelt wird. Die Anforderungsanalyse wurde daher nach fünf Tagen abgebrochen und durch eine Marktanalyse ersetzt. Tatsächlich konnte der Kunde schon nur wenige Wochen ein Standardprodukt einführen, das obendrein auch noch preiswerter war.Wenn das Projekt machbar ist und der Kunde die Durchführung nach wie vor für sinnvoll hält und der Auftrag zur Realisierung (Implementierung, Konstruktion) erteilt wird, sollte es ein Kick-Off-Meeting innerhalb des Entwicklungsteams und ein weiteres Kick-Off-Meeting mit dem Kunden geben. Auf diesen Veranstaltungen können Mitarbeiter vorgestellt, Regeln definiert, Rollen verteilt und Vorgehensweisen vereinheitlicht werden. Außerdem ist die Stimmung zu dieser Zeit stets noch sehr positiv, so dass sich auch die Linienvorgesetzten aus den verschiedenen Eskalationspfaden im Guten kennen lernen können.

6.2 Kick-Off-Meeting"Wir werden vom Schicksal hart oder weich geklopft; es kommt auf das Material an."(Marie von Ebner-Eschenbach)

Historie des Projekts Vorstellung des Kunden Namen (Namenskürzel), Positionen (Organigramm) und Tel.-Nummern des Kunden Vorgehensweise im Projekt (Modelle, Methoden) Eckdaten des Projekts (time, budget, quality) Rollen (Aufgaben) der Teammitglieder (Alias, Namenskürzel) Eskalationspfad / Verhaltensregeln (Offen!, Ordentlich und Korrekt) / Kommunikationsregeln (Fragen!) Rechte und Pflichten (Umgang mit Fehlern und KnowHow, Arbeitszeiten, Räume, Geheimhaltung, Datenschutz) Kleiderordnung Raumordnung für den Projektraum Gesetze (KISS, Code-Optimierung) Verbindlichkeit (Protokolle) Terminplanung mit den wichtigsten Eckdaten des Projekts, Projektplan mit MS-Project (Balkendiagramm) Konventionen, Definitionen English names and comments please! Name-Prefixes: c for class, i for int, s for String, ...; no underscores! Alle Literale (beispielsweise 5 oder "Hallo") werden benannt Use only int, double, String!

49


Use In-Line-Comments to make the source readable! Alias-Stamps (Namenskürzel yyyy-mm-dd) Die Formatierung der Blockklammerung ist frei Die Plausibilität der Parameter wird immer in(!) der Funktion geprüft Eine Klasse pro Quelle, Sourcenverwaltung (beispielsweise VSS oder CVS) Fehlerbehandlung und Log-Mechanismus sind zu benutzen und ebenfalls zu testen Jede Klasse wird vor Veröffentlichung getestet und abgenommen Änderungskennzeichen für Dokumente (beispielsweise ## oder **) Bei Dokumenten Dateinamen "yyyy-mm-dd ..." Projektkennwort (beispielsweise zur Verschlüsselung von eMails Projektlenkungskreise und Projektsteuerungsgremien Meeting-KulturDie Verantwortungsmatrix kann bei einem Festpreisprojekt so aussehen:

Auftragnehmer Auftraggeber Fachabteilung Auftraggeber IT-Abteilung

Technischer Geschäftsführer Fachbereichsleiter IT-Leiter

Projektleiter Fachlicher Ansprechpartner Technischer Ansprechpartner

Softwareteam Pilotanwender Support

Bei einem Aufwandsprojekt ist eine solche Matrix durchaus üblich:

Auftragnehmer Auftraggeber IT-Abteilung Auftraggeber Fachabteilung

Technischer Geschäftsführer IT-Leiter Fachbereichsleiter

Leiter Entwicklerteam Projektleiter Fachlicher Ansprechpartner

Softwareteam Support Pilotanwender

Wichtig ist, dass immer nur direkt benachbarte Positionen der Matrix miteinander kommunizieren sollten.

6.3 Architekturen"Zuweilen habe ich im Schlafe die Lösung solcher Probleme gefunden, die im wachen Zustand unlösbar schienen."(Anton Hansen Tammsaare)

6.3.1 MVC ParadigmaMVC steht für "Model-View-Controller" und geht auf das EVA-Prinzip zurück: die Eingabe, Verarbeitung und Ausgabe von Daten sollte immer getrennt betrachtet werden. Im Zusammenhang mit Smalltalk wurde in den 70er Jahren im Xerox PARC das EVA-Prinzip erstmalig auf die graphische Benutzerschnittstelle übertragen und als weiterentwickelte MVC-Architektur etabliert.Das Model ist die genau eine Programm-Repräsentation, stellt also die eigentlichen Daten und Funktionalitäten zur Verfügung, die eng mit dem Problem verbunden sind und deshalb so lange unverändert bleiben, wie auch das Problem unverändert besteht. Die Views sind all die Präsentationen des Models gegenüber dem Anwender, also auch die echte Visualisierung der Daten und damit die Verbindung des Models zur Aussenwelt. Die Controller steuern das Verhalten der Software, nehmen

50


also Ereignisse vom Anwender aus den Views entgegen, beeinflussen das Model und führen dadurch zur Veränderung der Views.Strikt genommen kann das Model in ein Domain Model (MD) und ein Application Model (MA) geteilt werden: das MD kümmert sich ausschließlich um das eigentliche fachliche Problem, wogegen das MA die Schnittstellen zu den Views und Controllern enthält. Die Kommunikation zwischen MD, MA, V und C erfolgt häufig über Ereignisse (englisch events) oder Nachrichten (englisch messages).Die Begrifflichkeiten sind hier übrigens nicht immer sauber abzugrenzen: MVC wird je nach Kontext als Muster, Idiom, Paradigma, Prinzip, Architektur oder auch Modell betrachtet. Wenn Sie weitere Informationen zu MVC suchen, geben Sie einfach in einer Internet-Suchmaschine "MVC Smalltalk" ein.6.3.2 n-tier-ModelBei jeder auch nur halbwegs ernst gemeinten Software für einen kommerziellen Kunden mit mehr als drei Anwendern sollte die Architektur immer eine Zerlegung in Komponenten mit einer Verteilung dieser Komponenten im Netzwerk ermöglichen. Der CORBA-Standard [L16] der OMG [L3] beschreibt seit Jahren, wie eine Software auf mehrere Computer verteilt werden kann. "CORBA" ist die Abkürzung für "Common ORB Architecture" und "ORB" ist die Abkürzung für "Object Request Broker". Ein ORB ist eine Systemsoftware, die im Netzwerk mit Objekten - also Softwaremodulen - makelt. Wenn also ein Objekt ein anderes im Netzwerk sucht, kann der ORB dieses finden. CORBA ist ein allgemeiner Architekturstandard für die Implementierung von ORBs in ein System. Bekannte CORBA-Implementierungen sind beispielsweise Microsoft-COM (Component Object Model) und EJB (Enterprise Java Beans). Es ist also sehr wohl möglich, von einem Programm auf dem einen Computer eine Funktion in einem Programm auf einem anderen Computer aufzurufen. Dies führt in der Praxis dazu, dass heutzutage die wesentliche Logik der Software von den Modulen auf den zentralen Servern erledigt wird, denn hier steht die größte Rechenleistung zur Verfügung und hier können die Änderungen so durchgeführt werden, dass sie sofort allen Anwendern zur Verfügung stehen. Die Software-Module, die wirklich auf den Anwender-PCs installiert werden, kümmern sich heutzutage nur noch um die reine Kommunikation mit dem Anwender, d.h. die Eingabe der Daten, das Auslösen von Aktionen und die Präsentation der Ergebnisse. Die Daten werden auf speziellen Datenbank-Servern gespeichert, wo sie gegen direkte Zugriffe durch die Anwender geschützt sind. Selbst die Software-Module auf den Anwender-PCs fordern diese Daten indirekt über die zentralen Logik-Server an.Damit haben wir in der PC-Welt sowohl die Zeit hinter uns gelassen, in der die Software ausschließlich auf den PCs läuft, als auch die Zeit, in der nach Client-/Server-Technik die gesamte Logik auf dem PC läuft und nur die Daten, Dateien und Drucker zentral verwaltet werden. Heute kann auch nicht mehr nur vom "3-tier-Model" gesprochen werden, weil größere Programme noch feiner modularisiert und im Netz verteilt werden.Das n-tier-Model ermöglicht im Wesentlichen die Kapselung und Trennung von Wissen im Software-System. So kann beispielsweise die Umrechnung von Währungen oder die Ermittlung von Rabatten mit speziellen Modulen auf speziellen Servern realisiert werden. Das Wissen über die Umrechnungsfaktoren der Währungen oder der Staffeln des Rabattsystems liegt dann in zentralen Komponenten und kann in der Regel ohne Einfluss auf den Rest des Software-Systems geändert werden. Noch wichtiger ist anders herum, dass alle anderen Module des Software-Systems zwar wissen, was es gibt und dies auch benutzen können, aber nicht wissen müssen, wie es funktioniert und wie es implementiert ist.Die zentrale Schicht, die als "Business Tier" die Geschäftslogik implementiert, weiß also nicht, ob oder gar wie die Daten in einer Datenbank gespeichert werden; sie weiß auch nicht, welche Daten dem Anwender wie präsentiert werden. Durch die Kapselung des Wissens in Module entsteht also gleichzeitig eine Trennung des Wissens und durch klar definierte Schnittstellen kann die Entwicklung der Software auch leicht auf mehrere Entwickler gleichzeitig verteilt und nahezu beliebig skaliert werden.

51


Mit Microsoft Visual Basic (VB) werden vorrangig Programme geschrieben, die für den Eigenbedarf oder für kleinere Anwendungen gedacht sind. Dies liegt wohl daran, dass BASIC ursprünglich eine sehr einfache und unstrukturierte Programmiersprache war. Microsoft ist der Sprache BASIC auch bei Windows treu geblieben und hat diese stets weiterentwickelt. Heute kann mit VB auch objektorientiert programmiert werden und selbst zentrale Serverkomponenten können mit VB erstellt werden. Dennoch ist die Programmierung mit VB recht einfach geblieben, weil viele Details der Windows-API dem Programmierer verborgen bleiben.Auch wenn keine zentralen Serverkomponenten erstellt werden (was bei 90% der VB-Anwendungen der Fall sein dürfte), kann der Programmierer verteilt denken und zumindest die zentrale Logik in eigenen Klassen verbergen und den Datenzugriff in wieder andere Klassen legen. Wenn dann die Anwendung mal wächst (bei Anwendungen für den Eigenbedarf werden ja leider selten Anforderungen spezifiziert, die dann auch noch hinreichend analysiert werden) kann beispielsweise ein Wechsel von Microsoft Access auf den Microsoft SQL-Server leicht erfolgen. Hier können dann auch Stored Procedures zum Einsatz kommen, mit denen die Daten wirklich nur über die Programmfunktionalität zugänglich werden. Von solchen Änderungen sind dann oft nur einige wenige Objekte im gesamten Softwaresystem betroffen.VB wird übrigens auch von Microsoft .NET unterstützt, so dass auch die Investitionen in große Systeme, die in VB erstellt wurden, geschützt sind. Mit .NET können nahezu beliebige Programmiersprachen kombiniert werden, so dass beispielsweise auch die Erstellung zentraler, komplexer und schwieriger Komponenten in C# und deren Aufruf vom PC in VB möglich ist.

52


Das Internet bekam 1990 von Tim Berners-Lee das www inkl. HTML und http zu den anderen Services und Protokollen hinzu. Im Gegensatz zu den vorherigen Diensten war nun das einfache Erzeugen, Abrufen und Verknüpfen von Seiten möglich, die sogar Graphiken enthalten konnten. Damit wurde das www zu einem großen Buch, das bereits wenige Jahren später ein unglaubliches Wissen enthielt und deshalb die Aufmerksamkeit der Öffentlichkeit weckte. Das www war aber in keinster Weise als Plattform für kommerzielle Software gedacht. Mit der Entwicklung zu Intra- und Extranets ist es aber durch die einfache Verwendung des Browsers auf dem Client und der zentralen Verwaltung der Seiten auf den Servern zunehmend dafür "missbraucht" worden.Heute genießen es die Administratoren von größeren Unternehmensnetzwerken, wenn ein großes Software-Paket für alle Anwender installiert und konfiguriert werden kann, ohne dass der Serverraum verlassen werden muss. Der PC verkommt damit allerdings zum dummen Terminal, das nur noch für die "nackte" I/O im Browserfenster zuständig ist. Nach der vollständigen Verarbeitung von Software auf dem PC verfällt die Branche damit auf das Gegenteil: auf die vollständige Verarbeitung auf dem Server. Dies ist weder sinnvoll noch technisch empfehlenswert - erst recht nicht auf der Basis des www!Die Integration von Script-Sprachen und Controls in HTML sowie die Parameterübergabe zwischen Seiten per http und die Entwicklung von "dynamischen" serverseitigen Seiten waren Erweiterungen, um größere programmierte Unternehmensprozesse mit dem Browser und dem www realisieren zu können.Diese Entwicklung ist noch lange nicht abgeschlossen: bei der Betrachtung von CORBA und den bisherigen Entwicklungsplattformen wird schnell klar, welche enormen Änderungen uns im www in den nächsten Jahren erwarten werden. Dazu gehört eine objektorientierte Seitenstruktur genauso wie eine Objektkommunikation zwischen Client- und Server.Für klassische Softwareentwickler verlangt das www eine Änderung der Sicht, denn statt Fenster zu öffnen und zu schließen, die im Aufbau starr sind, wird nun zwischen Seiten gewechselt, die serverseitig dynamisch passend erstellt werden. Es gibt auch in aller Regel keinen Weg zurück, weil per Link und Submit immer eine nächste Seite aufgerufen wird (und sei es die, die der Anwender

53


eigentlich vorher schon mal gesehen hatte). Mit dem Öffnen weiterer Browser muss man äußerst sparsam umgehen, weil es keine Modalität zwischen den Fenstern gibt.Die serverseitige dynamische Erstellung von Webseiten war in der ursprünglichen Planung des www nicht enthalten und beispielsweise von Microsoft mit ASP, von Sun mit JSP und von anderen mit PHP nachgerüstet. Hier will ich mit JSP die Java-Variante betrachten, weil Java sehr modern, sehr offen und sehr leistungsfähig ist. Nach seiner Veröffentlichung 1995 hat Java einen enormen Zulauf gefunden und hat sich mit seiner gesamten Umgebung mittlerweile so weit entwickelt, dass es äußerst professionell aufgestellt ist.Die JSP (Java Server Page), die heutzutage (06/2002) in der Entwicklungsumgebung (IDE) erstellt wird, gelangt als Servlet auf einen http-Server (Web-Server, z.B. Apache oder Microsoft IIS) und wird dort von einer Servlet-Engine ausgeführt. Von dem Code des Servlets aus (also eigentlich von der Seite aus) kann echter Java-Code in Form von lokalen (also auf dem http-Server befindlichen) Komponenten aufgerufen werden; dies sind die sogenannten "beans". Diese stellen die Verbindung zu zentralen beans (Enterprise Java Beans = EJB) auf anderen Servern (Applikationsservern) her, die wiederum eine Verbindung zu den Datenbankservern aufbauen können. Damit ist auch bei der Internet-Technologie die Anwendung des n-tier-Models möglich geworden.Gewöhnungsbedürftig ist die Tatsache, dass der Klick auf einen Link im Browser zur Aktivierung (request) eines Servlets führt, welches die Paramter des Links vom http-Paket an die beans übergibt und als response (Antwort) ein neues http-Paket mit der HTML-Seite als Inhalt aufbaut, das dann als "angeklickte" Seite zurück an den Browser des Clients geschickt wird.Von SunTM gibt es für den SunTM ONE (iPlanetTM) Application Server eine Beispiel-Applikation "Java Pet Store", deren Architektur im Internet öffentlich beschrieben ist:6.3.3 MDA

MDA bezeichnet die Model Driven Architecture [L20] von der OMG. Dort gibt es reichlich weitere Infos und von dort habe ich auch obiges Bild entnommen.

6.4 Design der Modelle"Je planmäßiger die Menschen vorgehen, desto wirksamer trifft sie der Zufall."(Friedrich Dürrenmatt)

"Design" bedeutet hier nicht das "Aussehen" der Software, sondern das "Entwerfen" der Software, d.h. die Ableitung der wesentlichen Modelle aus der Spezifikation. Daran sollte auf jeden Fall der Anlalytiker beteiligt sein, der in der Analysephase des Projekts die Spezifikation mit dem Ansprechpartner des Kunden gemeinsam aufgestellt hat, weil dieser sowohl die Fachlichkeit des

54


Kunden kennengelernt hat als auch die entscheidenden Mitglieder des Projektteams (oder zumindest den Projektleiter) wahrscheinlich schon lange kennt. Außerdem wird der Analytiker auch genug Erfahrung und aktuelles IT-Know-How mitbringen, um die wesentlichen Befürchtungen und Probleme des Entwicklerteams zu kennen.In dieser Design- oder Entwurfsphase werden vorrangig drei Hauptmodelle entwickelt: das Datenmodell, das Objektmodell der Geschäftslogik (engl. business logic, also middle tier) sowie das Präsentationsmodell. Wenn Sie die Architektur nach dem n-tier-Modell entwerfen, werden Sie bei größeren Anwendungen auch Objektmodelle im presentation tier und data tier bauen, wenn Sie auf die Serverfarmen mehrerer Unternehmen gleichzeitig zugreifen, werden Sie mit mehreren Datenmodellen arbeiten und wenn Sie verschiedene Typen von Clients (Browser, Windows, Handy) implementieren werden Sie mehrere Präsentationsmodelle benötigen. Bei den meisten Anwendungen kommen Sie aber sicherlich mit den drei Hauptmodellen aus.Die Erstellung der Modelle ist jeweils eine Wissenschaft für sich - es gibt beispielsweise Entwickler, die sich ausschließlich auf den Entwurf von Datenmodellen spezialisiert haben. Andere wiederum haben über mehrere Projekte hinweg im Laufe von einigen Jahren viel Erfahrung mit ganz bestimmten objektorientierten Plattformen gesammelt und sind von daher absolut fit im Entwurf von Klassenhierarchien.Es geht mir in dieser Abhandlung insgesamt um die systematische Arbeitsweise bei der Entwicklung von Software. Daher ist es mir sehr wichtig zu betonen, dass diese Modelle erstellt werden sollten, aber ich will hier nicht im Detail erläutern, wie das geht. Dafür gibt es bereits reichlich Literatur und Tools. Ich gebe daher nur einen kurzen Überblick.6.4.1 Klassenmodell...

6.4.2 DatenmodellIn den Anwendungsfällen werden Sie bereits Basisdaten erkannt haben, die eigentlich weitgehend konstant sind und an vielen Stellen in dem Software-System benutzt werden, z.B. Städtenamen, Verbandsmitglieder, LKW-Typen, Lagerhallenbezeichnungen. Sie werden auch schon für die Funktionsanwendungsfälle Datengruppierungen erkannt haben, die dort typisch sind und als Stammdaten für mehrere Detail- oder auch Funktionsanwendungsfälle gelten, z.B. Artikeldaten, Kundendaten, Projektdaten, Rechnungsdaten, Adressdaten, technische Datenblätter.Dies sind Ihre ersten Entitäten (engl. entities), also Einzelinformationen und Informationseinheiten. Sie werden auch schon Beziehungen (engl. relations oder relationships) zwischen diesen Entitäten erkannt haben, z.B. Stücklisten bestehen aus Artikeln, Kunden erhalten mehrere Rechnungen, Datenblätter gehören zu Maschinen. Ein Datenmodell wird auch als ER-Model (Entity-Relationship-Model) bezeichnet. Sie nutzen für die Erstellung des Datenmodells ein Werkzeug, dass manchmal in die Entwicklungsumgebung integriert ist, manchmal aber besser auch separat erworben wird. Sie können damit die Strukturen (Spaltennamen und -typen) Ihrer Datentabellen festlegen, Standardwerte für Informationen vorgeben, Regeln für Informationen definieren (z.B. "zwischen 0 und 100" bei Prozentangaben) und auch die Beziehungen zwischen den Datentabellen mitsamt der Kardinalitäten definieren.Die Erstellung des Datenmodells ist ein erster akribischer Test der Spezifikation durch Entwickler, die mit der Fachlichkeit noch nicht sehr vertraut sind. Daher sollte der Analytiker dabei sein und sehr genau darauf achten, wo seine Spezifikation wackelt und daher noch weiterer Analysebedarf besteht.

55


Das obige Bild zeigt einen ersten Entwuf eines Datenmodells, der eine Woche Zeit beansprucht hat. Sie sehen an einigen Lücken, dass dieses Modell noch nicht fertig ist, aber Sie sehen an den sauber getrennten Bereichen auch, dass die Analyse und Spezifikation erfolgreich verlaufen war und klar abgegrenzte Übersichtsanwendungsfälle ergeben hat.Die Designphase wird - wie alle anderen Phasen und überhaupt das ganze Projekt auch - iterativ inkrementell durchlaufen, d.h. in einem ersten Design-Durchlauf wird zunächst mit einer konzeptionellen Sicht grob entworfen, in einem weiteren Durchlauf werden mit spezifizierender Sicht Details definiert und in einem anderen Durchlauf wird dann mit implementierender Sicht eine Umsetzung in das echte System erfolgen. Bei größeren Projekten können hier noch mehr Iterationen stattfinden, wobei das System immer weiter verfeinert wird und daher inkrementell wächst.

56


Während gerade das Bild eine konzeptionelle Sicht zeigte sehen Sie jetzt óben ein Bild der implementierenden Sicht. Denn es wird zunächst in der konzeptionellen Sicht nur ein logisches Datenmodell erstellt, welches nur allgemeine abstrakte Datentypen kennt (z.B. Nummer, Text). Erst bei der spezifizierenden Sicht werden die Datenbanksysteme festgelegt, so dass dann die physikalischen Modelle erstellt werden können. Diese enthalten dann wirklich schon die Datentypen, Regeln und Beziehungen des jeweiligen Datenbanksystems. Mit der implementierenden Sicht werden dann wirklich die echten Datenbanken aus den physikalischen Modellen realisiert, die dann auch mit Daten gefüllt werden können.Das soeben gezeigte logische Modell wurde in dem Projekt sowohl in Microsoft Access (als Zwischenlösung für die Datenübernahme aus dem Altsystem) als auch in Oracle (für die endgültige Lösung) implementiert. Dazu wurden aus dem einen logischen Modell zwei physikalische Modelle abgeleitet (was von ordentlichen Modellierungstools unterstützt wird), aus denen dann die Datenbanken halbautomatisch erstellt werden konnten. Dazu generieren die Tools Skripte, die dann im Datenbanksystem gestartet werden können oder die Tools erstellen direkt die Datenbanken in den Datenbanksystemen.In dem genannten Projekt wurde nebenstehende Access-Datenbank direkt aus dem Tool erstellt. Hier muss zwar noch aufgeräumt werden, aber die meiste Arbeit hat das Tool erledigt - und zwar gar nicht mal schlecht.

Das obige Bild zeigt einen Ausschnitt des gleichen Datenmodells ein halbes Jahr später. Es sind Tabellen hinzugekommen, Beziehungen haben sich geändert, Typen wurden genauer spezifiziert (NULL zugelassen oder nicht) und Bereiche getauscht, aber das logische Modelle wurde konsequent gepflegt und sieht daher jederzeit aus "wie neu".Bei dem Design des Datenmodells ist darauf zu achten, dass es vollständig normalisiert wird, d.h. alle folgenden Normalformen durchlaufen werden:

57


1. Normalform: Die Feldinhalte müssen einfach - also atomar - sein. Dazu werden die Daten in Tabellen mit Zeilen und Spalten eingetragen.2. Normalform: Jeder Zeile wird ein Schlüsselfeld hinzugefügt, über das jede Zeile eindeutig identifiziert werden kann. Jedes Feld muß funktional vom Schlüsselfeld abhängig sein. Der Schlüssel kann sich aus mehreren Feldern zusammensetzen.3. Normalform: Es dürfen keine funktionalen Abhängigkeiten zwischen Nicht-Schlüssel-Feldern existieren. Die Tabelle darf somit keine transitiven Abhängigkeiten aufweisen. Dazu wird die Tabelle so lange in kleinere Tabellen mit Verweisen zerlegt, bis funktionale Abhängigkeiten nur noch zwischen den Tabellen bestehen und nicht mehr zwischen Nicht-Schlüssel-Feldern.Boyce-Codd Normalform: Sie liegt zwischen der 3. und 4. Normalform und arbeitet mit der Existenz von Kandidatenschlüsseln. Eine Tabelle befindet sich in der Boyce-Codd Normalform, wenn sie sich für alle Felder, die alternative Kandidatenschlüssel sind, in der dritten Normalform befindet.4. Normalform: Eine Tabelle darf keine paarweise auftretenden, mehrwertigen Abhängigkeiten aufweisen, d.h. die 4. Normalform erfordert, dass die Tabelle keine unabhängigen zusammengesetzten Primärschlüssel enthält.5. Normalform (Project-Join-Normalform): Eine Tabelle enthält keine paarweisen zyklischen Abhängigkeiten des Primärschlüssels, die aus drei oder mehr Komponentenfeldern zusammengesetzt sind. Relationen in Fünfter Normalform lassen sich nicht weiter aufteilen.Die Normalisierung der Daten entfernt die Redundanzen, so dass die Daten klar beschrieben werden, eindeutige Beziehungen zwischen Datenteilen bestehen, die Datenintegrität gewährleistet ist, ein schneller Zugriff auf die Daten möglich ist und nicht zuletzt Platz beim Speichern der Daten gespart wird.Es handelt sich bei der Normalisierung um eine bewährte Technologie, die schon seit vielen Jahren erfolgreich von Programmierern eingesetzt wird. Wird beim Design des Datenmodells von vornherein mit ER-Diagrammen gearbeitet und jeder Datentabelle grundsätzlich ein internes Schlüsselfeld zugeordnet, so sind bereits wichtige Schritte auf dem Weg zur normalisierten Datenbank erledigt.Ich pflege meine logischen Datenmodelle - wenn irgendwie möglich - so, dass sich keine Linien kreuzen und alle Beziehungen sich 1:n von links nach rechts über das Diagramm ziehen. Dies erfordert viel Disziplin und ich kenne bereits mehrere Leute, die das ziemlich albern finden, aber es hat einen entscheidenen Vorteil: ich kann einen wichtigen Test durchführen. Wenn ich eine Konstruktion erkenne, die ich "small diamond" ("kleiner Diamant") nenne, stimmt in der Regel etwas mit den Beziehungen nicht. Oft gibt es dann eine redundante Beziehung, was von den Normalisierungsstufen nicht abgedeckt wird. Falls eine solche Beziehungskiste aber erforderlich ist, muss sie auf jeden Fall im business tier oder presentation tier plausibilisiert und damit abgedichtet werden. Als "small diamond" bezeichne ich eine rautenförmige Beziehungskonstruktion zwischen vier bis etwa acht Tabellen.

58


Das obige Bild zeigt einen solchen "small diamond": Ursprünglich gehörte ein Projekt (tblProject) zu einem Planabschnitt (tblSegmentAssetsPlan) und stand n:m mit Arbeitstypen (tblWorkType) in Beziehung, d.h. ein Projekt bestand aus mehreren Arbeitstypen und ein Arbeitstyp kam bei mehreren Projekten vor. Später stellte sich der fachliche Zusammenhang heraus, dass ein Planabschnitt durch mehrere Arbeitstypen beschrieben wird. Wie kann nun sicher gestellt werden, dass die zugeordneten Arbeitstypen des Projekts alle zum gleichen Planabschnitt gehörten, und zwar zu dem vom Projekt verwendeten Planabschnitt? Tatsächlich wurde die zuerst gefundene Beziehung von den Planabschnitten zu den Projekten überflüssig und barg sogar ein Fehlerrisiko.

Modellierung- Klassenhierarchie; Integrationsmodell (OOA-Modell)- Datensammlung; Datenmodell (ER-Modell)- GUI; Simulationsmodell (fachlicher Prototyp)Identifikation von Klassen, Assoziationen, Aggregationen, Generalisierung, SubsystemeZustandsautomatenArchitekturentwurf- Anbindung an Benutzeroberfläche- Anbindung an Datenhaltung- Verteilung auf vernetzte ComputerImplementierungsentwurf- Verfeinerung des Architekturentwurfs- Anpassung an Programmiersprache

6.5 Design Patterns"Kein Problem wird gelöst, wenn wir träge darauf warten, daß sich andere darum kümmern."(M.L. King)

Es gibt eine "Gang of Four", das ist ein Team von vier Leuten, die ein mittlerweile sehr berühmtes Buch geschrieben haben [B20]. Darin geht es um Muster, die bei dem Entwurf von vielen objektorientierten Programmen ("Design Patterns" kann mit "Entwurfsmuster" übersetzt werden) und bei der Gestaltung von vielen Softwarearchitekturen immer wieder aufgetaucht sind. Wer ernsthaft häufiger objektorientierte Software entwickeln will, sollte sich damit beschäftigen und diese

59


bewährten Muster anwenden, denn in Analogie zu oben genanntem Spruch hat sich die Gang of Four schon um dieses Problem gekümmert.Beispielsweise gibt es immer wieder Systeme, die ein anderes System vertreten. Diese Stellvertreterrolle wird als "Proxy" bezeichnet. In IT-Netzwerken gibt es für den Webzugriff Proxyserver, die bereits benutzte statische Seiten für eine definierbare Zeit zwischenspeichern, um den Zugriff für alle Mitarbeiter der Firma zu beschleunigen, die Leitungen freier zu halten und die Kosten für das Unternehmen somit zu reduzieren. Ein anderes Beispiel sind "Observer", die etwas beobachten. So können beispielsweise Importprogramme ein Verzeichnis eines Servers beobachten und auf neue Dateien lauern: sobald eine neue Datei kommt, wird diese verarbeitet und in ein Archivverzeichnis verschoben. Als letztes Beispiel möchte ich den "Iterator" nennen, der viele Elemente von Irgendwas eines nach dem anderen bearbeitet. Wenn also ein bestimmter Projektleiter gesucht wird, so kann ein Stück Software über eine Liste von Projektleitern iterieren, um den richtigen zu finden.Die Kenntnis dieser Muster mit ihren Namen und ihrer Bedeutung hat viele Vorteile: sie vereinfacht die Kommunikation zwischen den Teammitgliedern ("... wir haben dafür einen Observer implementiert ..."), trägt zu klaren Strukturen in der Software bei, vereinfacht die Dokumentation und verhindert obendrein, dass das warme Wasser immer wieder neu erfunden wird. Damit ist auch klar, dass dieses Thema nicht nur für den harten Kern des Teams gilt, sondern für alle Entwickler und auch für die Tester, Analytiker und viele andere Rollen im Team.Natürlich gibt es mittlerweile auch weitere Bücher und selbstverständlich reichlich Infos zu Design Patterns im Web, z.B. unter [L5] und [L6].

6.6 Software Ergonomie"Die Menschen muss man nehmen wie sie sind, nicht wie sie sein sollten."(Franz Schubert)

First principle: know the userMeet the expectationsLook and feel of GUIs: Style guidesThe Dos and Don'tsScreen designJoin the sensesKeep it small and simple (Kiss)Help your user ("RTFM")NIMPLsNicht-Irrtümer belohnen, d.h. nicht permanent fragen, um Irrtümer zu vermeiden.

60


7 Implementierung

7.1 Implementierungsaspekte"Amateure bauten die Arche, Profis bauten die Titanic."(Unbekannter)

Höchste Risiken zuerst erledigenAktivitätendiagrammetechnische EntscheidungenJedes Softwareprodukt hat einen Helden, der einen Teil seines Lebens für die Fertigstellung der Software geopfert hat. In unendlich vielen Stunden hat er das Projekt fast von Anfang an bis fast zum bitteren Ende begleitet und stellt die Seele des Quellcodes dar.Bau der DatenbankFinden von DatenstrukturenErstellen der ObjekteKonzeption von AlgorithmenMnemonik, Inline-DokErstellen der TestumgebungenGUI-Verfeinerung build Feature Teams with own schedule!Fixed Shipping Date, but target milestones!Code Complete!Eine Software ist wie eine Modelleisenbahn - sie wird nie fertig!

7.2 Codierung"Glühlampen brennen heller, wenn man sie vor dem Einschrauben aus der Verpackung nimmt!"(Unbekannt)

Vergessen Sie bei der Implementierung nicht all die unzähligen alten Tipps, die immer noch ihre Gültigkeit haben: Die erste Regel der Optimierung heißt: "tu's nicht"Die zweite Regel der Optimierung heißt: "wenn überhaupt, tu's erst am Schluss"Hier ein paar Überschriften aus "The Practice of Programming" von Brian W. Kernighan & Rob Pike:"Use descriptive names for globals, short names for locals" (dt. "Benutze beschreibende Namen für globale Variablen, kurze Namen für lokale Variablen")"Use active names for functions" (dt. "Benutze aktive Namen für Funktionen")"Indent to show structure" (dt. "Einrücken um die Struktur zu zeigen")"Break up complex expressions" (dt. "Komplexe Ausdrücke aufbrechen")"Give names to magic numbers" (dt. "Benenne Zahlen" (Konstanten, Arraygrößen, Indizes, etc.))"Don´t comment bad code, rewrite it" (dt. "Schlechten Code nicht kommentieren, sondern neu schreiben")ANTI-Beispiele aus oben genanntem Buch zur Codierung (natürlich in C, ist schließlich von Kernighan):*x+=(*xp=(2*k<(n-m)?c[k+1):d[k--]));child=(!LC&&!RC)?0:(!LC?RC:LC);"Code Complete" von Steve C. McConnell "Writing Solid Code" von Steve Maguire

61


Wir haben im Februar 2002 bei dem Review eines VisualBasic-Programms folgenden Code gefunden:' Update the caption and fill in the list of options.If CurrentUser = "xxx" Then mde_kopieren.Visible = FalseIf CurrentUser <> "xxx" Then mde_kopieren.Visible = FalseIf CurrentUser = "yyy" Then Label1.Caption = ...Was sagen uns die beiden ersten Zeilen? Und die Namen der Benutzer waren auch tatsächlich hart codiert! Und Label1 ist doch auch selbst erklärend, oder?Quellverwaltung (z.B. Microsoft Visual Source Safe) einsetzen, um saubere Teamarbeit zu ermöglichen.Nur im Notfall während der Implementierung die Tools, die Versionen oder gar die technische Plattform wechseln. Dies bedarf schon sehr kräftiger Gründe.

7.3 Leitung"Willst du mit jemandem ein Schiff bauen, wecke in ihm die Sehnsucht nach dem Meer."(Gert Kupfer)

Der amerikanische Slogan "My way or the highway!" (dt.: "Auf meine Art oder du bist auf der Straße!") hat heute als Führungsstil nur noch bedingt Gültigkeit. Selbst wenn ein Projekt vor die Wand fährt und ein Experte eingeschaltet wird, um das Projekt zu retten, kann er es nicht allein, sondern nur mit Unterstützung durch das Team schaffen. Und Wasser kocht unter Druck bekanntlich auch nicht schneller, sondern langsamer! Auf der Suche nach der richtigen Art der Motivation kommt vielleicht jeder mal zu dem Punkt, dass er nicht eine Konkurrenz zwischen den Teammitgliedern, sondern eine Konkurrenz jedes Teammitglieds mit sich selbst benötigt. Wenn man jemanden lobt, weil dieser etwas richtig getan hat, oder zumindest besser als sonst, so wird derjenige seinen persönlichen Fortschritt erkennen und weiter an sich arbeiten. Dies kann sich auf Soft Skills und Hard Facts gleichermaßen beziehen. Auf diese Art wird auch das ganze Team als Ganzes immer besser werden. Es bringt mehr, bei guten Taten zu loben, als bei schlechten zu strafen. Wer mehr über diesen Ansatz erfahren möchte, sollte [B22] lesen, ein kleines Buch mit einem großen Inhalt!Wer diesen Ansatz verstanden hat und mit erster positiver Erfahrung anwendet, kann auch die so beliebten "Zielvereinbarungen" einführen. Denn Ziele und die Messungen dessen Erreichungsgrades sollten nicht als Druckmittel oder gar zum Aussortieren von Versagern dienen, sondern zur persönlichen Weiterentwicklung der einzelnen Teammitglieder. "Goals Begin Behaviors - Con-sequences Maintain Behaviors." (dt.: "Mit Zielen beginnt Verhalten - Konsequenzen pflegen Verhalten.") aus [B11] signalisiert denn auch eine sehr hohe Disziplin und eine ständige Beobachtung sowie Steuerung durch die Teamleitung. Gemäß dem Ansatz aus dem vorherigen Absatz kann ein Teamleiter seine Mitarbeiter zum Ziel steuern, wenn er sie in dem Moment lobt, wenn sie etwas tun, was sie dem Ziel näher bringt. Jeder wird das an sich selbst positiv spüren und motiviert sein, immer häufiger Dinge immer besser zu tun.Eine Komponente der "Leitung" sollte also immer auch "Monitoring" sein. Wenn ein Projekt in einer späten Iterationsstufe in Schwierigkeiten durch Erschöpfung, Krankheit, Kündigung oder Mehrarbeit gerät, so ist es in der Regel schwierig, neue Leute ins Team zu integrieren. Ein Projekt wird in dieser Phase durch weitere oder neue Mitarbeiter zunächst nicht beschleunigt, sondern erst mal gebremst. Dies liegt daran, dass neue Mitarbeiter sich erst in die Architektur, die Tools, das Objektmodell und den bestehenden Code einarbeiten müssen und dabei auf die Hilfe der Veteranen des Projekts angewiesen sind (die ohnehin schon genug zu tun haben). Die neuen Mitarbeiter werden zu Beginn ggf. auch die eine oder andere Änderung vornehmen, die mehr schadet als nutzt. Es ist also wichtig, einen guten Kontakt zu den Teammitgliedern zu haben und Engpässe früh zu erkennen, denn dann lohnt sich die Einarbeitung weiterer Mitarbeiter auf jeden Fall. In diesem Moment zeigt sich dann auch, ob das Team wirklich funktioniert!Zu einem Team gehören auch Rollen. Dies hat was mit "Effektivität" und "Effizienz" zu tun. "Effektivität" bedeutet: "Die richtigen Dinge tun.", "Effizienz" bedeutet: "Die Dinge richtig tun." Es ist also wichtig, erst einmal zu erkennen, was alles getan werden muss. Dann sollte der Teamleiter mit

62


seinem Team gemeinsam überlegen, wer was am besten tun kann und auch möchte. Und erst dann sollte er verbindlich diese Aufgaben verteilen und sich von jedem Teammitglied einen Plan wünschen, wie dieses die Aufgaben zu tun gedenkt. Bei Bedarf kann die Rollenverteilung ja auch noch mal geändert werden. Falls jemand ein alter Hase in einer Rolle oder einem Thema ist, aber mal was anderes machen möchte und jemand neues erstmalig diese Rolle oder dieses Thema übernehmen möchte, ist es sicherlich sinnvoll, hier eine "Patenschaft" einzurichten. Wenn dann noch Ziele an die Rollen gekoppelt werden, wird auch jedem Teammitglied sein Beitrag zum Projekt und seine Verantwortung im Team sehr schnell klar. Viele Rollen haben Schnittstellen zu anderen Rollen, und diese Schnittstellen müssen sehr wohl ebenfalls erarbeitet und definiert werden. Beispielsweise muss ein Entwickler seine Quellen schon in das Sourcen-Verwaltungssystem einchecken, damit ein Quell-Tester den zugehörigen Prüfstandtest fahren kann. Wo Licht ist, ist natürlich auch Schatten. Es macht sicherlich auch Sinn, Mitarbeitern mal zu sagen, wo sie etwas schlecht gemacht haben. Schon allein, weil die Leute sonst nach wenigen Monaten nur noch glauben, sie seien die Größten, weil sie ja nur noch gelobt werden und mit minimaler Steuerung ihre Ziele immer besser erreichen. Eine solche Erfahrung steigt Leuten schnell in den Kopf und sie fangen an sich aufzuspielen, weniger zu arbeiten und stattdessen mehr Geld zu verlangen. Zum Loben gehört also natürlich auch Tadeln ("Zuckerbrot und Peitsche"), das spielt auch in [B11] eine wichtige Rolle. In Notfällen und absolut dringenden Situationen kann es kurzzeitig sogar erforderlich sein, dass einer aus dem Team die absolute Führung übernimmt und bestimmt, wo es lang geht. Auch in den besten Projekten mit den bewährtesten Teams kann dies vorkommen, allein schon durch äußere Zwänge. Ich erinnere mich an ein Projekt einer Embedded Software (ein Betriebssystem eines Consumer-Produktes), bei dem die Produktion der Geräte Anfang der Woche angelaufen war und in der Folgewoche die Chips mit der Software eingesetzt werden sollten. Natürlich wurde Ende der Woche ein schwerwiegender Fehler gefunden ("Wenn etwas schief gehen kann, dann wird es auch schief gehen."). Also setzten wir uns Freitag nachmittag - gerade Zuhause angekommen - direkt wieder ins Flugzeug, um das ganze Wochenende durchzuarbeiten, damit am Montagmorgen die Chips mit der Software produziert werden konnten. Ansonsten hätten die Bänder im Produktionswerk gestoppt werden müssen! An diesem Wochenende hat aus Effizienzgründen genau einer gesagt, wer was wann wo tut! In solchen Momenten gelten die Regeln der christlichen Seefahrt: Es gibt genau einen Kapitän, und es wird gemacht, was dieser sagt - alles andere ist Meuterei! Und wie die bestraft wird, weiß ja jeder ;-)In solchen schwierigen Situationen wird typischerweise nicht der Projektleiter das Sagen haben und evtl. nicht einmal der Teamleiter, sondern vielleicht eher eine Rolle, die gerne "DevLead" ("Development Leader", dt.: "Entwicklungsleiter") genannt wird. Dies wird der erfahrenste, respektierteste und fitteste Entwickler des Teams sein. Dennoch sind Projektleiter und Teamleiter natürlich in so einem Moment zugegen, koordinieren unterstützend Aktivitäten und Kommunikation, lösen einzelne Konflikte und holen die Pizza! Auch wenn es gerade nicht brennt und demzufolge auch nichts gelöscht werden muss, sollten Sitzungen von Projektlenkungskreisen und Projektsteuerungsgremien stattfinden. Diese Routinen sollten zu Beginn des Projekts durch Vorstellung im Kick-Off-Meeting etabliert und wirklich in einem festen Tournus durchgeführt werden. Alle Leute der Verantwortungsmatrix sollten daran teilnehmen. In diesen Sitzungen wird natürlich ein Sachstandbericht zum Projekt geliefert, die Pläne werden kontrolliert und projektgefährdende Probleme werden signalisiert, damit gemeinsam eine Lösung gefunden werden kann. Typischerweise werden übergreifende, ganzheitliche Probleme diskutiert und gelöst, lokale dagegen nur angeschnitten und delegiert. Wichtig ist, dass die gesamte Verantwortungsmatrix große Probleme frühzeitig signalisiert bekommt (am besten gleich mit mehreren Lösungsansätzen), denn nur so kann das Vertrauen in der gesamten Matrix aufgebaut und erhalten werden. Offenheit und Fairness ist in der Verantwortungsmatrix genauso wichtig wie im Entwicklungsteam oder auch im Fachteam.Wovon ich persönlich überhaupt nichts halte, sind diese Routinen in Entwicklerteams, die womöglich sogar zweimal wöchentlich mit allen zwanzig Entwicklern stattfinden. Da werden die wesentlichen Probleme eh nicht angesprochen, weil man diese nicht in einer solchen Gruppe diskutieren kann. Demzufolge werden da auch keine wesentlichen Entscheidungen getroffen. Also kann man sich den Quark auch gleich sparen! Man sollte sich einfach mal ausrechnen, wieviel Personenstunden da in schlechter Luft auf heißen Kohlen verbracht werden, dann kommt man schnell zu dem Schluss, dass

63


einen dieser Aktionismus nicht weiter bringt. Operative Hektik ersetzt hier geistige Windstille! Dann doch lieber ein wöchentliches Projektfrühstück, zu dem jeder was Leckeres mitbringt. Dabei werden dann zwischendurch von ganz allein in kleinen Grüppchen auch mal die Probleme besprochen, die auf den Nägeln brennen. Wenn Projektleiter und Teamleiter da nicht auf den Ohren sitzen, erfahren sie die wichtigen Sachen, ohne danach fragen zu müssen - vor allem die Stimmung im Team!Lesen Sie doch auch mal die Reports aus dem Windows 2000 Team von Microsoft, z.B.: "What the Boss Should Know".

7.4 Iterationen"Kein Mensch ist so beschäftigt, dass er nicht die Zeit hat, überall zu erzählen, wie beschäftigt er ist."(Robert Lembke)

Die Versionskennungen bei Software werden typischerweise als v.rr dargestellt, wobei v die Nummer der Version und r die Nummer der Revision ist. Wenn also Fehler behoben wurden und villeicht einige Funktionen aufgrund der Rückmeldungen der Kunden noch mal angepasst wurden, wird eine neue Revision des Produktes auf den Markt gebracht. Einige große Hersteller haben noch kleinere Schritte eingeführt, weil der Aufwand für die Produktion einer neuen Version/Revision bei Millionenstückzahlen in verschiedenen Sprachen für mehrere Kontinente extrem aufwendig ist. So gab es von Microsoft ein Word 6.0a, in dem nur geringe Änderungen vorgenommen wurden, die in die laufende Produktion eingeflossen sind, aber nicht zum Ankurbeln der gesamten Marketingmaschinerie geeignet waren.Oft wird auch die Build-Nummer (Herstellungsnummer) noch mit angegeben. Diese Nummer wird immer hochgezählt, wenn die Software wieder neu generiert wird. Wenn also Entwickler eine Änderung vorgenommen haben und alle ihre Quellen übersetzt haben, brauchen sie einen neuen fertigen Stand der Software, um ihre Änderungen erst selbst testen zu können und dann in die Qualitätskontrolle geben zu können. Zur Kommunikation ist eine eindeutige Identifizierung des Stands erforderlich, und genau hierfür wird bei jeder Erstellung eines neuen Standes die Build-Nummer hochgezählt. So wird beispielsweise bei Microsoft von einem Build-Team jede Nacht ein neuer Stand von Windows generiert, der dann von einem Burning-Team (Brenn-Team) noch in der gleichen Nacht auf CDs gezogen wird. [B21]Meilenstein "Close Shop"Lieferung auf CD-ROMZwischenabnahmen?ca. fünf Iterationen pro Jahr

7.5 Änderungsanforderungen"Man muss sich einfache Ziele setzen, dann kann man sich komplizierte Umwege erlauben."(Charles de Gaulle)

Änderungsanforderungen (englisch Change Requests) sind die Tücke eines jeden Software-Projekts. Wenn Sie bisher alles richtig gemacht haben und optimal im Plan liegen und endlich die Fachlichkeit und die Technik im Griff haben, kommt der Kunde jetzt garantiert mit neuen Ideen, damit Sie als Anbieter auch garantiert ins Schleudern kommen. Hier danke ich einem Kunden für den ehrlichen Spruch: "Kunde sein verdirbt den Charakter"!Das Problem ist ja nicht die neue Idee, der geänderte Geschäftsprozess oder der bisher so zurückhaltende Anwender, der nun anhand der Prototypen die neuen technischen Möglichkeiten entdeckt hat - das Problem ist der Umgang damit! Ist die neue Idee nun wirklich neu oder ist darüber nicht schon ganz häufig gesprochen worden und das war schon immer so gemeint? Hat sich der Geschäftsprozess wirklich geändert oder haben Sie als Anbieter den Kunden nur nicht richtig

64


verstanden? Ist der bisher so zurückhaltende Anwender wirklich nie gefragt worden und hat jetzt erst vom neuen System erfahren?Wenn Sie als Anbieter die Anforderungen verbindlich fixiert, umfangreich analysiert und detailiert spezifiziert haben und wenn Sie all diese Prozesse in Stufen mit Zwischenabnahmen und Protokollen begleitet haben und wenn Sie wirklich nur einen einzigen Ansprechpartner haben, der seinerseits genau einen benannten Vertreter für jeden Akteur hat und wenn alle Dokumente und Prototypen all diesen Vertretern vorgeführt wurden, dann können Sie sehr genau feststellen, welche Anforderung wirklich neu oder geändert ist.Sie können diese Änderungsanforderung "oben" in Ihren Prozess einstreuen und beobachten, welche Auswirkungen sie worauf hat: Passt die Änderungsanforderung überhaupt ins Hauptziel? Welcher Akteur stellt diese Änderungsanforderung? Welche Anforderungen kamen noch von diesem Akteur? Auf welchen Übersichts-AF und auf welche Funktions-AF wirkt sich diese Änderungsanforderung aus? Welche Detail-AF müssen alle wie geändert werden? Welche Daten werden dabei neu entstehen oder können verworfen werden? Was bedeutet dies für das Datenmodell? Welche Geschäftslogik muss geändert oder ergänzt oder verworfen werden? Welche Teile des Datenmodells und der Geschäftslogik und welche Teile in anderen tiern sind bereits implementiert und müssen wie umcodiert werden? Welche Team-Mitglieder sind also betroffen, wofür sind diese in nächster Zeit eingeplant und welchen Stundensatz haben sie? Welche neuen Testfälle zieht die Änderung nach sich und wie aufwändig ist die Qualitätssicherung jetzt? Welche Dokumentation muss in welchem Umfang geändert werden und welche Teile des evtl. bereits begonnenen Handbuchs müssen wie geändert werden?Wie viel Zeit wird also alles in allem für diese Änderung benötigt und was kostet diese letztendlich? Wird das Produkt vielleicht sogar billiger, weil die Änderung eine Reduzierung mit sich bringt, die eintritt, bevor mit den betroffenen Stellen überhaupt irgendjemand begonnen hat? Eine Änderungsanforderung kann durchaus auch zur Minderung statt zur Mehrung führen, auch wenn dies eher untypisch ist.Wenn Sie als Anbieter Ihrem Kunden also nachweisen können, dass es sich um eine Änderung handelt und vorrechnen können, welchen Einfluss diese Änderung auf Zeit und Kosten hat, dann kann der Kunde für sich abwägen, ob er die Änderung dennoch möchte oder nicht. Vielleicht möchte der Kunde die Änderung dann ja auch in einer späteren Version, zusammen mit einigen anderen Änderungen. Es soll nämlich schon Projekte gegeben haben, die vor lauter Änderungsanforderungen nie fertig geworden sind! Eine Änderung in einer Folgeversion ist zwar in der Regel teurer als eine Änderung in der aktuellen Version, aber eine Version später auf den Markt zu bringen als ursprünglich geplant und versprochen kann noch viel teurer werden!Hier sei nochmals erwähnt, dass eine Änderungsanforderung natürlich umso teurer ist, je später sie in das Projekt "einschlägt". In der Pre-Analyse ist eine Änderung gedankenschnell vollzogen, in der Analyse kostet die Änderung der bereits erstellten Dokumentteile vielleicht einen Tag, nach dem Design kann es schon eine Woche sein und wenn weite Teile bereits codiert und im Handbuch verewigt sind, wird es bestimmt schon ein Monat sein. Ist das Produkt erst im Markt und muss in der nächsten Version kompatibel geändert werden, bedeutet es vielleicht ein halbes Jahr!

65


8 Test

8.1 Warum testen?"Man muss immer das Beste hoffen, das Schlimme kommt von alleine."(Deutsches Sprichwort)

"Kein Produkt menschlicher Intelligenz kommt fehlerfrei zur Welt. Wir formulieren Sätze um, trennen Nähte wieder auf, setzen Pflanzen um, planen Häuser neu und reparieren Brücken. Warum sollte es uns mit Software anders gehen?" [B4] Bei der Softwareentwicklung nach dem oben genannten Sprichwort zu verfahren, wäre also töricht. Denn wenn Sie wissen, dass Software Fehler hat, diese aber nicht suchen und erst recht nicht beheben, dann werden Sie nie zuverlässig bestimmen können, wann Ihr Projekt zuende und Ihr Produkt fertig sein wird.Wir sollten also zunächst akzeptieren, dass Software per Definition fehlerhaft ist. Wie wir später noch sehen werden, ist im Qualitätsmanagement ein Fehler als die Nichterfüllung einer Anforderung definiert und stellt damit einen Mangel im Produkt dar, der in aller Regel ausgebessert werden muss. Wir sind schließlich nicht nur verantwortlich für das, was wir tun, sondern auch für das, was wir nicht tun! Daher sollten Fehler nach bestem Wissen und Gewissen gesucht, gefunden und behoben werden, bevor der Kunde das Produkt erhält. Nur mit dieser Einstellung kann beim Kunden ein hohes Maß an Zufriedenheit sichergestellt werden - und nur ein zufriedener Kunde ist ein guter Kunde! Also muss getestet werden, denn "Testen" ist der Prozess zur Prüfung der Erfüllung/Nichterfüllung der Anforderungen.Natürlich muss militärische Software, die in Serienherstellung Verwendung finden soll, gründlicher getestet werden, als eine Verwaltungssoftware, die individuell für einen einzelnen Kunden erstellt wird. Aber man sollte darüber mit dem Kunden reden, bevor der Aufwand für das Projekt geschätzt wird - nicht, dass der Kunde später auf einmal eine ganz andere Einstellung zum Testen hat, als man zuvor angesetzt hat. Und selbst wenn der Kunde auf Tests verzichten will und nur die Fehler beheben will, die nach der Einführung im Betrieb hochpoppen, sollte man die Software nicht ohne Testprozesse in den Iterationen erstellen, denn ein nicht behobener Fehler in einer Iterationsstufe kann drei neue in der nächsten Iterationsstufe nach sich ziehen. Dann zahlt man als Entwickler die Strafe dafür, dass der Kunde kein Geld fürs Testen ausgeben will. Außerdem sollte man die Fehler möglichst finden, solange die Quellen noch "frisch" sind, denn auch mit phantastischer Dokumentation kann es später evtl. schwierig werden, sich wieder in die Quellen einzuarbeiten. Ungetestete Software wird - wie ungetestete Produkte in anderen Branchen auch - gerne als "Banana Products" bezeichnet: dies sind Produkte, die frühzeitig ihren Produktionsort verlassen und erst beim Kunden ausreifen - halt wie Bananen.Einsatz- oder sicherheitskritische Software (z.B. militärische oder medizinische Software) muss ggf. schon bei der ersten Inbetriebnahme fehlerfrei funktionieren. Dazu muss das Softwaresystem formal spezifiziert werden und verlangt eine mathematische Kontrollmöglichkeit. Hier kann man spezielle Spezifikationssprachen verwenden, die im Gegensatz zur menschlichen Sprache streng logisch aufgebaut sind. Dadurch können die Spezifikationen dann teilweise sogar automatisch verarbeitet werden. Da der Anwender in aller Regel eine solche Sprache nicht verstehen wird, muss diese formale Spezifikation immer zusätzlich zur normalen Spezifikation erstellt werden und dient damit im Wesentlichen zum mathematischen Testen der normalen Spezifikation und ggf. zum automatischen Testen der Software. Diese Verfahren werden beispielsweise bei der Entwicklung von Software für Herzschrittmacher eingesetzt und sind äußerst aufwändig. Außerdem erfordern logische symbolische Sprachen eine enorme Konzentration und keiner hat wirklich Lust, diesen Kram zu schreiben oder gar zu lesen. Daher sind diese Verfahren nur für kleinere Softwareprodukte interessant. Wie umfangreich wäre wohl auch die formale Spezifikation für die Cockpitsteuerung einer Boeing, wenn doch die englische schon mehrere Ordner umfasst? Erfahrungsgemäß müssen bei formaler Verifizierung die Mitarbeiter auch alle sechs Wochen durch ausgeruhte Kräfte ausgetauscht werden. Machbar ist das sicherlich alles, aber bevor Sie das als Entwickler einplanen, sollten Sie zuerst den Kunden finden, der das auch bezahlen kann und will!

66


8.2 Testen bis zum jüngsten Tag"Einen Fehler begangen haben und ihn nicht korrigieren: Erst das ist ein Fehler."(Konfuzius, Lunyu 15.30)

Nachdem wir soeben festgestellt haben, was "Testen" eigentlich bedeutet und warum man auf keinen Fall darum herum kommt, sollte wir nun klären, "was wann" getestet und behoben werden sollte. Das "was wann behoben" ist schnell geklärt: alles Gefundene zeitnah (oder wie mein Rechtsanwalt so gerne sagt: unverzüglich)! Gemäß obigem Spruch ist ein Fehler schließlich nur dann ein Fehler, wenn er nicht korrigiert wird.Aber "was wann testen"? Nun, pauschal sage ich immer: Teste mit dem nächsten Schritt den vorherigen und am besten auch noch mit dem übernächsten den nächsten und den vorherigen. Beispielsweise können Sie die gefundenen Teilziele gegen das Hauptziel auf Vollständigkeit und Widerspruchsfreiheit testen: Sollte ein Teilziel nichts mit dem Hauptziel zu tun haben oder diesem widersprechen, ist dies wahrscheinlich ein Fehler. Haben Sie in der In/Out-Liste etwas bei "Out" stehen, was vorher als Teilziel formuliert wurde, ist dies wahrscheinlich ein Fehler. Formulieren Sie später in einem Anwendungsfall etwas, was in der In/Out-Liste bei "Out" eingetragen wurde, ist auch dies wahrscheinlich ein Fehler. In diesem Fall sollten Sie den gleichen Sachverhalt auch nochmal gegen die Teilziele testen, denn vielleicht ist ja auch hier der "Out"-Eintrag der Fehler. Vielleicht finden Sie auch beim Übergang vom AF-Modell zum Klassenmodell doppelte Anwendungsfälle. Vielleicht stellen Sie auch fest, dass ein Anwendungsfall gar nicht so implementiert wurde, wie er spezifiziert wurde (passiert immer wieder, weil die Entwickler immer wieder ohne Rücksprache was einbauen, was sie viel besser finden). Vielleicht bekommen Sie ja auch einfach beim Klick auf eine Schaltfläche einen "Fatal internal error 0xAFFE". Vielleicht wird auch bei einem Report in den Zwischensummen falsch gerundet, weil gar nicht spezifiziert wurde, dass mit den präzisen Werten weiter gerechnet werden soll und der Entwickler sich die einfachste Variante rausgesucht hat. Und so können Sie vom ersten Akquisegespräch beim Kunden bis weit in die Wartungsphase immer und immer wieder an allen Ecken testen. Es gibt reichlich Gelegenheiten, man muss nur die Augen aufhalten.Wie heißt es bei [L13] so schön: "I've always said that the last bug will be found when the last cus-tomer dies." (dt.: "Ich habe immer gesagt, dass der letzte Fehler gefunden sein wird, wenn der letzte Anwender stirbt.") Ich bin im Jahr 2000 von einer Firma angemailt worden, die einen Fehler in einem Programm auf SCO-Xenix gefunden hat, das wir 1989 ausgeliefert hatten! Ich bin auch 2001 von einem Großhandel angesprochen worden, ob es nicht ein Fehler sei, dass das Filialprogramm, das ich 1986 für die vier Standorte geschrieben hatte, den Euro nicht unterstützt! Dies führt auch zur Frage nach der Beurteilung bzw. Klassifizierung von Fehlern, zu der ich etwas weiter unten bei den Systematischen Tests komme.Unter "Testen" wird landläufig nur das Testen des programmierten Codes verstanden, aber was nutzt es denn, wenn man die korrekte Implementierung einer falschen Annahme überprüft? Das Testen muss also bereits beim Erstellen der Spezifikation und sogar noch früher, nämlich beim Aufnehmen der Anforderungen, erfolgen. Wenn sich beispielsweise Anforderungen widersprechen, kann auch der sicherste Programmierer kein vernünftiges Programm daraus machen. Und wenn die Anforderungen nicht verbindlich fixiert wurden, kann man oft nicht einmal feststellen, ob es eigentlich überhaupt ein Fehler ist. Das stinkt dann immer mächtig nach Streit. Das Testen ist also keine Phase des Projekts, sondern ein Prozess, der am Ende jeder Phase angezogen wird.Darüber hinaus reicht es oft nicht, nur das Softwaresystem zu testen. Stattdessen muss das Gesamtsystem inklusive des Softwaresystems getestet werden. Eventuell versagt die Software der Gewächshaussteuerung oder der Waschanlage ja nur dann, wenn die elektrische Schnittstelle wegen Feuchtigkeit durch Spritzwasser nicht spezifizierte Signale auf die Ports haut, die dann von der Software falsch ausgewertet werden. Sehr häufig ist die Ursache des Fehlers einfach überhaupt nicht da, wo man sie zunächst vermutet. So erinnere ich mich auch an eine Situation, wie ich auf der Suche nach der Ursache eines Fehlers in einem ISAM Datenbanksystem beim Debuggen auf den Kundendaten einen völlig anderen Fehler gefunden hatte, dessen Effekt die Testmannschaft mit mehreren Leuten seit einer Woche zu reproduzieren versuchte. ("Debuggen" ist englisch für "entwanzen"; so nennt man die schrittweise Ausführung eines Programms zwecks Fehlersuche. Der

67


Begriff stammt noch aus der Zeit, wo in den Relaismaschinen die Fehler als Kurzschlüsse durch Käferchen und andere kleine Haustierchen entstanden waren. Der Fehler wurde dann durch das Herausnehmen der toten Tierchen und das Erneuern der Kabel und Kontakte behoben.)

8.3 Weiche Tests"Eine dicke Haut ist ein Geschenk Gottes."(Konrad Adenauer)

Als "weiche Tests" bezeichne ich gerne die unsystematischen Tests, obwohl ja durch eine Klassifizierung und gezielte Anwendung dieser Tests schon wieder eine gewisse Systematik aufkommt. Der wesentliche Charakter dieser Tests ist die Intuition, mit der vorgegangen wird. Entsprechend benötigt man dafür Leute, die einfach ein gewisses Gespür oder "Händchen" haben und manchmal auch mit einer gewissen Respektlosigkeit an dieses eigentlich phantastische Produkt herangehen. Ganz wichtig ist dabei also, dass diese Leute völlig unvoreingenommen und frei vorgehen können, weshalb diese Tests auch niemals von den Entwicklern des Produkts vorgenommen werden können. Da hier nicht systematisch getestet wird, ist es manchmal extrem schwer, die Fehler zu reproduzieren. Ich habe bei solchen Tests schon Video-Kameras benutzt, um genau festhalten zu können, wann der Tester welche Tasten gedrückt hat, wann er wo geklickt hat und was er ansonsten gemacht hat. Gleichzeitig können diese Aufnahmen dazu dienen, das Produkt in der Bedienung (Ergonomie) zu verbessern, denn wenn jeder Anwender an den gleichen Stellen stolpert, sollte man da was dran ändern.Ich habe schon erlebt, dass es für einen Fehler entscheidend war, dass der Anwender zwischen zwei bestimmten Funktionen mehrere Minuten gar nichts gemacht hatte, weil in der Zeit eine Variable in einer Schleife so hoch gezählt wurde, dass sie überlief und dann erst in der folgenden Funktion einen Fehler verursachte. Das Programm musste Proben analysieren, die eine bestimmte Mindestabkühlzeit benötigten, bevor die nächste Untersuchung stattfinden konnte. Jeder dachte, dass die Untersuchungen so schnell wie möglich hintereinander erfolgen würden, weil die Wartezeit nervig war und jeder auf das Ergebnis der Untersuchung gespannt war. Die Entwickler hatten bei ihren Tests immer ungedulig gewartet und so schnell wie möglich fortgesetzt, weil sie wissen wollten, ob es funktioniert. Bei den systematischen Tests wurde getestet, was passiert, wenn man nicht lange genug wartet und was, wenn man exakt die Zeit wartet und was, wenn man etwas länger wartet. Aber der unbedarfte Anwender, der für einen weichen Test eingeladen wurde, interessierte sich überhaupt nicht für den Sachverhalt oder das Ergebnis der Untersuchung und war für mehrere Minuten aus dem Kamerabild verschwunden. Er hat nämlich einfach die Zeit genutzt, um zwischendurch aufs Klo zu gehen. Dadurch hat er als einziger die zweite Funktion erheblich später nach der ersten ausgeführt.Voraussetzung für so einen Test ist, dass der Tester nicht die geringste Ahnung davon hat, was eigentlich in der Software vorgeht - er muss das Produkt als "Black Box" betrachten. Kein anderer würde sonst wahrscheinlich auf die Idee kommen, in das Postleitzahlfeld "unbekannt" reinzuschreiben, eine Datei auf der Diskette zu eröffnen und dann einfach die Diskette rauszunehmen, die erste Filialadresse zehnmal zu kopieren und dann erst die Kopien anzupassen (statt sie jedesmal sofort nach dem Kopieren anzupassen) oder sich auch ansonsten wie ein DAU (Dümmster Anzunehmender User) zu verhalten (die Abkürzung ist vom GAU = Größter Anzunehmender Unfall eines Atomkraftwerks abgeleitet). Ein früherer Projektleiter von mir sagte mal: "Ich setze mich mit dem Arsch auf die Tastatur - und wehe, ich höre auch nur einen Piep von der Kiste!" Es gibt auch Software-Hersteller, die sich für den Black-Box-Test in der Stadt oder an einer Uni Anwender von der Straße einkaufen, um zu testen, wie die Erstkäufer des Produkts wohl damit umgehen werden. Bei einer Individualsoftware, die für ein Unternehmen entwickelt wird, kann man sich gut in der Kantine bedienen - viele Mitarbeiter haben super viel Spaß an solchen Tests und erzählen hinterher rum, wie sie das Programm "aufs Kreuz gelegt" haben. Ein positiver Nebeneffekt davon ist, dass sich rumspricht, dass es bald eine neue Software gibt.Damit sich dabei nicht allzu viel Schlechtes rumspricht, sollte man jede Version, die man in einen Black-Box-Test gibt, natürlich gründlich - vor allem auch systematisch - vortesten. Den ersten Test macht natürlich immer der Entwickler, der schaut, ob das, was er gerade programmiert hat, auch das macht, was es soll. Danach sollte ein anderer Entwickler einfach mal provokant und brutal mit dem

68


Programm umgehen und schauen, ob es raucht und wie stark es raucht. Deshalb wird so ein Test gerne "Smoke-Test" genannt. Sie werden feststellen, dass viele Entwickler ganz jeck darauf sind, die Funktionen der Kollegen abrauchen zu lassen. Ich habe da schon regelrechte Turniere und Wettlisten gesehen. Ein positiver Nebeneffekt davon ist, dass die Entwickler auch mal den Rest des Produktes kennen lernen und spätestens dann genau wissen, wer was programmiert hat. Wenn das Produkt dann hinterher in den Black-Box-Test geht und die Fehlermeldungen der DAUs auf den Tischen der Entwickler landen, explodieren diese meistens, weil sie dann die Respektlosigkeit, Nüchternheit, Objektivität und natürlich teilweise auch Blödheit der echten Anwender zu spüren bekommen. Ich kannte mal einen Entwickler, der dann jedes mal voller Wut in den Testtrakt stürmte und dort einen riesigen Aufstand veranstaltete. Damit ist auch klar, warum ich obigen Spruch für diese Seite gewählt habe.Wenn Sie ein Altsystem mit modernen Technologien neu programmieren oder eine andere Software nachprogrammieren, sollten Sie mit verschiedenen Leuten einen "Pepsi-Test" durchführen. Dies ist eine Art Geschmacksvergleich, bei dem ganz subjektiv beurteilt wird, ob das Produkt besser oder mindestens genauso gut schmeckt. Hier kann verglichen werden, ob Funktionen schneller, komfortabler oder sicherer ablaufen, besser zu finden sind, der längst veränderten Fachlichkeit näher kommen und vielleicht auch einfach mehr Spaß machen. Dieser letzte Aspekt ist natürlich gerade bei Spiele-Software sehr entscheidend. Ich konnte mal mit den führenden deutschen Spieleentwicklern über Systematiken der Softwareentwicklung diskutieren und das entscheidende Argument für eine iterativ inkrementelle Entwicklung war, dass man möglichst früh die Performance messen, die Realitätsnähe beurteilen und vor allem den Spielspaß prüfen kann. Macht es keinen Spaß oder läßt der Spaß schnell nach, kann man die Entwicklung (oder die betroffenen Teile oder Charaktere) direkt in die Tonne hauen.Der Black-Box-Test eignet sich also gut, um die Praktikabilität zu testen, der Smoke-Test prüft im Wesentlichen, ob Fehlermeldungen hochkommen oder etwas kaputt geht und der Pepsi-Test zeigt einfach, wie es gefällt. Natürlich ist nicht jede Art von Test für jedes Produkt oder jede Phase geeignet. Sie werden keinen Smoke-Test mit einer Software für Herzschrittmacher durchführen und Sie werden auch keinen Black-Box-Test mit Software für Mittelstreckenraketen durchführen. Aber Sie können bei einer individuellen Verwaltungssoftware sehr wohl bereits in der Analysephase (also sehr früh) einen Pepsi-Test anhand des Prototypen durchführen; deshalb auch im Inhaltsverzeichnis bei "Prototyp" der Spruch: "Etwas zum Spielen braucht der Mensch". Sie können beim Schreiben der Anwendungsfälle auch sehr gut gedanklich einen Black-Box-Test durchlaufen, denn die Implementierungswege sind ja zu dieser Zeit noch unbekannt. So können Sie bereits dann die ersten Testfälle für die systematischen Tests finden. Einen Smoke-Test sollten Sie bei "harmloser" Software nach jeder Iterationsstufe durchführen, vielleicht auch einen Black-Box-Test mit ausgewählten Pilotanwendern.Systematisch sollte man bei weichen Tests bei der Auswertung vorgehen. Die Fehler sollten genauso aufgenommen, priorisiert, weitergeleitet und behoben werden, wie die Fehler von systematischen Tests auch. Ferner sollten gute Ideen der Tester zu neuen Testfällen führen, damit diese bei späteren Tests nach Korrekturphasen, weiteren Iterationsstufen oder neuen Produktversionen erneut angewendet werden können. Die systematischen Tester sollten diese Testfälle einsehen können, damit sie daraus vielleicht Ideen für neue systematische Tests entwickeln können.

8.4 Systematische Tests"Der Fehler liegt in der Eile."(Aus China)

Worum geht es beim systematischen Testen? Die Software wirklich fertig zu bekommen und die geforderte Qualität zu erreichen; oder anders gesagt: "Make it fly!" Dies ist ein zäher Prozess, der extrem an den Nerven zerrt, weil man mit jedem neu entdeckten Fehler das Gefühl bekommt, wieder ein Stück schlechter gewesen zu sein, als erwartet. Versuchen Sie es, anders herum zu sehen. Der Projektleiter eines Projekts, in dem ich 1985 teilnahm, sagte immer: "Kaum macht man's richtig, schon geht's." Mit dieser Einstellung ist es jedes Mal ein tolles Gefühl, wenn ein weiterer Fehler vernichtet ist!

69


Systematisch zu testen, bedeutet vor allem, zu wissen, was man testet und wie man es testet. Ein zentraler Aspekt sind sicherlich "Testfälle", die möglichst schon gemeinsam mit den Anwendungsfällen geschrieben werden sollten. Wenn Sie nämlich die Anwendungsfälle schreiben, fallen Ihnen oft schon die Bedingungen auf, die erfüllt sein müssen, damit der Anwendungsfall erfolgreich verläuft. Diese Annahmen sind sehr gut als Ansätze für Testfälle geeignet. Wenn es in einem Anwendungsfall heißt "Der Name der gespeicherten Datei wird der Liste hinzugefügt.", so frage ich mich sofort, wie sich die Software wohl verhält, wenn die Datei nicht gespeichert werden konnte? Was kann dazu führen? Beispielsweise eine volle Festplatte (war bei Testern schon immer beliebt, weil dabei immer was passiert; gleiches gilt natürlich für Quoten) oder mangelnde Berechtigungen des Anwenders in dem gewählten Ordner oder ein doppelter Dateiname oder, oder, oder. Mit etwas Erfahrung findet man schnell Ansätze zum Testen, die man direkt in einem zugehörigen Testfall festhalten sollte. Darin sollte auch beschrieben werden, wie sich das Softwaresystem verhalten sollte. Es ist schließlich ein Unterschied, ob der Anwender eine Fehlermeldung erhält (natürlich immer zusammen mit einem Hinweis, wie er sich weiter verhalten sollte) oder das System beispielsweise bei mangelnden Berechtigungen automatisch und still das Homeverzeichnis des Anwenders wählt.Tester verwenden diese Testfälle, um die Situationen zu provozieren und das Verhalten der Software zu prüfen. An dieser Stelle eine Bitte an alle Tester: seid mal nicht zu systematisch und fangt nicht immer mit den einfachsten Tests an; langt ruhig mal in der ersten Testphase sofort richtig in die schwierigen Töpfe, damit die Entwickler erst einmal beschäftigt sind und ihnen viel Zeit zur Behebung zur Verfügung steht. Dann habt ihr auch genug Luft, in Ruhe systematisch vorne anzufangen und habt auch gleich ein Gefühl für die Komplexitätsschwelle, ab wo die Software "buggy" (dt. "fehlerhaft") wird. Einige Testfälle sind auch gar nicht gut für professionelle Tester geeignet. Ich habe gute Erfahrungen damit gemacht, in einer Art Feldversuch einige Anwender zu einer Testmannschaft zusammen zu stellen und mit diesen dann bestimmte Anwendertests durchzuführen. Denn oft wissen Tester auch nicht besser als die Entwickler, wie Artikel- oder Vertragsnummern korrekt aufgebaut werden und wann eine Sammelrechnung inhaltlich verhunzt ist und wann nicht. Bei den Anwendertests "im Feld" gewinnt man oft noch entscheidende Testfälle hinzu. Natürlich sind aber auch mindestens 2/3 der Anmerkungen dieser Anwender Optimierungs- oder Erweiterungswünsche.Es gibt aber natürlich noch mehr Möglichkeiten, systematisch zu testen, als nur die Testfälle durchzugehen. Den ersten Test wird der Entwickler selbst durchführen, denn ein Entwickler, der seinen Code ungetestet zu einem offiziellen systematischen Test in die Testabteilung gibt, wird garantiert ausgepeitscht, wenn das Ding dort überhaupt nicht läuft! Beim "Developer Test" schaut der Entwickler zuerst, ob seine Funktionalität für die Anwender überhaupt erreichbar ist und durchläuft, ohne "Bumm" zu machen. Ferner wird er einige Randbedingungen sofort durchprüfen, weil es ihm irgendwann einfach zu peinlich ist, wenn die Tester bei ihm immer wieder sofort auf bestimmte einfache Situationen treffen. Dazu gehört beispielsweise, ob die Prüfung auf die Pflichtfelder funktioniert, ob leere Felder auch leer gewertet werden, wenn ein Leerzeichen drin steht, ob bei Summierungen auch richtig gerechnet wird, ob die Formatierung und Rundung von Zahlen stimmt, ob Tippfehler in den Texten auf dem Bildschirm sind, ob bei langsamen Passagen die Sanduhr angezeigt wird, etc.Weitere Tests sind "Schnittstellentests", die auch von Prüfständen durchgeführt werden. Dabei wird das Verhalten der Programmschnittstellen geprüft. Wenn beispielsweise eine Funktion als Parameter einen Provisionssatz bekommt (ein Argument ist übrigens etwas, was an eine Funktion gegeben wird, ein Parameter ist etwas, was eine Funktion bekommt; die unterschiedliche Begrifflichkeit stammt also von der unterschiedlichen Sicht), so kann man ja mal testen, wie sich die Funktion bei einem negativen Provisionssatz verhält, oder bei einem, der größer ist als 100%. Schließlich kann es ja schon morgen passieren, dass ein Entwickler des Teams diese Funktion falsch versorgt. Einem Fehler vorzubeugen ist besser, als einen Fehler tagelang zu suchen.Mit diesem Gedanken macht es auch Sinn, die Quellen einem zweiten Entwickler zu zeigen, damit er sich die einfach mal durchliest - vielleicht fällt ihm ja was auf. So etwas nennt man "Code Review". Dies führte beim Extreme Programming [L2] zum Ansatz des "Pair Programming": der eine Entwickler schreibt die Funktion und der andere parallel den Schnittstellentest dazu; dann tauschen die beiden ihre Quellen und sichten sie. Erst danach wird der Test auf der Funktion durchgeführt. Ich

70


denke gerne an ein Softwaremodul zurück, dass ich Anfang 2002 entwickelt habe. Durch eine ordentliche Zeitabschätzung hatte ich genug Luft für meine Developer Tests und konnte sogar noch meine Teamkollegen eine Code Review durchführen lassen und die Quellen nachträglich mit noch ausführlicheren Kommentaren versehen, wobei mir auch noch die eine oder andere Gelegenheit zur Plausibilitätsprüfung aufgefallen war. Das eingeflogene Testteam war nach fünf Tagen so verzweifelt, weil sie keinen einzigen Fehler fanden, dass sie selbst einen Code Review durchführen wollten. Es kommt sicherlich nicht oft vor, dass ein Testteam so viel Entwicklungserfahrung mitbringt und dass man als Entwickler dem Tester auch noch dabei über die Schulter blicken darf. Die Tester hatten zwar beim Code Review auch nicht mehr viel gefunden, konnten sich aber nun auch vergewissern, warum dies so war ;-)Die oben beschriebenen Schnittstellentests können auch als "Prüfstand" automatisiert werden. Prüfstände testen aber noch mehr, nämlich auch, ob ein Geschäftsprozess oder eine komplexe Softwarefunktionalität durch eine Aneinanderreihung von Einzelfunktionen sauber abläuft (Test ganzer Anwendungsfälle). So kann man beispielsweise die ganze Serienbrieffunktion eines Textverarbeitungsprogramms automatisiert testen, oder das Erstellen von Sammelrechnungen aus einzelnen Lieferscheinen bei einem Warenwirtschaftssystem. Ich habe mal mit einem Kollegen in den 80ern in Assembler die Software für eine elektronische Speicherschreibmaschine mit Display entwickelt (übrigens ein Projekt von ca. sechs Mannjahren Aufwand), bei dem die Testmannschaft unter anderem die fertigen Schreibmaschinen in eine Apparatur gespannt hat, die mit Hydrostößeln über jeder Taste die Finger des Anwenders simulieren konnte. Diese Apparatur konnte nun ihrerseits mit einfachen Makros programmiert werden. Darin wurde nur festgehalten, welche Taste mit welcher anschließenden Pause gedrückt werden sollte. Dadurch wurde ein echtes Verhalten eines Anwenders für eine Vielzahl von Bedienfunktionen (Display- und Delay-Modus, Tabulationen, Löschfunktionen auf dem Papier, Totzeichen, etc.) simuliert - und zwar ganze Nächte hindurch! Vor diesem Prüfstandtest habe ich immer viel Respekt gehabt, weil auf ganz natürliche Art und Weise der Speicher gefüllt wurde, seitenweise Text in verschiedensten Modi generiert wurde und vor allem, weil uns morgens ein dickes Protokoll auf den Tisch geknallt wurde, in dem alle Fehler markiert waren! Wir konnten auch davon ausgehen, dass es kein Fehler in der Apparatur war, weil diese Makros äußerst einfach und sicher zu erstellen waren. Anders ist es bei Softwareprüfständen, die automatisiert Testfälle testen. Ich frage mich da immer, warum diese Software eigentlich fehlerfreier sein soll als die, die sie testet. Wird Prüfstandsoftware von Göttern programmiert?Ein Test führt also zu einem positiven oder negativen Ergebnis. Ein positives Ergebnis ist ein Fehler, der bewertet und festgehalten werden muss. Insbesondere der Weg zum Fehler ist wichtig, denn nur ein reproduzierbarer Fehler ist ein guter Fehler! Daher sollte ein Bug-Reporting-System zum Melden von Fehlern eingesetzt werden. Dies kann eine professionelle webbasierende Software sein, bei kleinen Projekten aber beispielsweise auch eine Access-Datenbank oder gar nur ein Textdokument. Fehler sollten dort eingetragen, gewichtet (priorisiert) und Bearbeitern zugeordnet werden. Die Behebung des Fehlers sollte exakt beschrieben werden und der Fehler zum Nachtest freigegeben werden. Fehler sollten immer zeitnah behoben und nicht aufgeschoben werden. Dabei spielt natürlich die Dringlichkeit und Wichtigkeit des Fehlers eine große Rolle. Der Projektleiter muss ggf. den Projektplan anpassen und eine Statistik der Fehler und Behebungen führen. Solange noch 1er Prios oder Class-A-Bugs drin sind, kann die Software nicht guten Gewissens freigegeben werden. Bei Individualsoftware sollte der Kunde in die Statistik eingeweiht werden. Vor allem sollten die Prioritäten der Fehler mit dem Kunden diskutiert werden, damit klar ist, ob es sich wirklich um einen Fehler oder einen Wunsch handelt und ob ein Fehler die Abnahme der Software behindert oder nicht. Anhand eines Bug-Reporting-Systems können Kennzahlen aus den Projekten ermittelt werden, die zu einer besseren Messbarkeit der nächsten Projekte führt. Denn wenn sehr viele Fehler gefunden werden, ist dies genauso verdächtig als wenn sehr wenige Fehler gefunden werden. Aber dazu muss man erst einmal wissen, was "sehr viele" und "sehr wenige" bedeutet, und dies hängt vom Team, vom Zeitrahmen, von der Komplexität der Aufgabenstellung, von der Erfahrung mit der technischen Plattform und vielen weiteren Faktoren ab.Führen Sie regelmäßig "Regressionstests" durch, d.h. testen Sie regelmäßig alte Fehler, die vor scheinbaren Ewigkeiten behoben wurden, denn nicht selten tauchen diese wieder auf. Es gibt in jeder Software Fehler, die wie Tischtennisbälle immer oben schwimmen, egal, wie oft Sie sie wieder unter Wasser drücken. Die iterativ inkrementelle Vorgehensweise im Projekt sorgt automatisch für häufige

71


Tests der Basisfunktionalität, weil diese ja nach jeder Iterationsstufe wieder mitgetestet wird. Diese Arbeitsweise stellt auch sicher, dass Sie immer nur auf geprüftem Code weiter entwickeln. Dies erspart Ihnen viele unangenehme Überraschungen am Ende des Projekts."Zero Defects" ist eine Methode, bei der die Regressionstests auf die Spitze getrieben werden, denn dabei wird durch tägliche (!) "Quick Tests" über die ganze Projektlaufzeit hinweg sichergestellt, dass dicke Hunde erst gar nicht auftauchen. Alle Fehler aus den Quick Tests werden sofort (wirklich sofort) gesucht und behoben - vorher wird nicht weiter entwickelt! Anhand von Checklisten kann ermittelt werden, welcher Umfang von den Quick Tests abgedeckt wird, denn bei halbwegs komplexer Software in halbwegs großen Projekten ist es nicht mehr möglich, an einem Tag alles zu testen. Sämtliche Testfälle, andere systematische Tests und auch Situationen aus weichen Tests und vor allem sämtliche Situationen, die schon einmal zu einem Fehler geführt haben, sollte man dann in einer fetten Checkliste führen, in der die Tests priorisiert und die Zeit für deren Durchführung gestoppt und notiert wird. Dann kann die Zeitsumme für die einzelnen Prioritäten gebildet werden. So ist eine zuverlässige Aussage möglich, innerhalb welcher Zeit welche Qualität geprüft werden kann. Ich habe dies mal bei der Entwicklung eines graphischen Textverarbeitungssystems mit der Testabteilung, den Vertrieblern sowie dem Entwicklungsteam durchgezogen. Vor Präsentationen einer neuen Version bei Key-Kunden konnten wir den Vertrieblern genau sagen, welche Qualität wir bei der verbleibenden Testzeit noch gewährleisten können, und die Vertriebler konnten anhand der Checklisten auch genau prüfen, was das bedeutet. Gleiches galt für Messen: auf der CeBIT wollten wir im Kino natürlich nur Gutes zeigen und wussten genau, dass wir acht Tage vor der Messe die Entwicklung stoppen mussten, wenn wir wissen wollten, was bei einer 2er-Qualität nicht vorgeführt werden durfte. Der Aufwand für solche Verfahren sollte genauso wenig unterschätzt werden wie die Schwierigkeit der Projektsteuerung mit solchen Verfahren!Bei kritischer Software sollte natürlich auch das Ausfallverhalten getestet werden: wenn die Software oder das von der Software gesteuerte System versagt, muss ein möglichst harmloser oder neutraler Zustand erreicht werden. Wie der aussieht, sollte natürlich nach gründlicher Absprache mit dem Auftraggeber in der Spezifikation festgehalten sein. Wenn beispielsweise an einer Kreuzung die Ampeln die Verbindung zur Steuerzentrale verlieren, könnten sich alle Ampeln der Kreuzung auf rot stellen. Wenn die Verbindung nicht innerhalb einer Minute wieder hergestellt werden kann, sollten vielleicht besser alle Ampeln gelb blinken. Wenn hingegen nur eine einzige Fahrtrichtung an einer Kreuzung total ausfällt, sollten sich vielleicht alle anderen Ampeln ebenfalls ganz ausschalten und die Regelung des Verkehrs den Schildern überlassen. All diese Situationen müssen definiert sein und gründlich - am besten vollautomatisch - getestet werden können.Alle Einzelfehler zu Testen ist schon schwer, aber wie sieht es mit Mehrfachfehlern aus, vor allem, wenn sich diese gegenseitig aufheben? Hat schon mal jemand die Zeit gehabt, die extrem aufwendigen Mehrfachfehlertests bei einem Softwaresystem durchzuführen? Es gibt da das berühmte Beispiel des Atomkraftwerks, bei dem die Software eine Störung melden und sich danach "möglichst neutral" verhalten sollte. Es kam, wie es kommen musste: Ein Ventil verursachte eine völlig harmlose Störung, die Software meldete diese und danach verhielt sich die Software so, wie die Entwickler "neutral" verstanden: sie ignorierte weitere Fehler. Dummerweise trat direkt nach dem harmlosen Ventilfehler eine ernsthafte Störung auf, die beinahe einen GAU verursacht hätte, weil sie nicht gemeldet wurde.Ich möchte hier noch einen Aspekt erwähnen, der beim Testen sehr oft vergessen oder extrem unterschätzt wird: Die "Datenversionierung". Wenn Sie einen Fehler feststellen und die Entwickler diesen zur Behebung reproduzieren können sollen und die Tester später testen können sollen, ob er wirklich behoben ist, müssen Sie nicht nur exakt beschreiben können, was getan werden muss, um diesen Fehler zu provozieren, sondern Sie müssen genauso exakt beschreiben können, wie die Daten aussehen, die bei diesen Schritten verwendet werden. Sie werden also oft die Daten "einfrieren" können müssen und diesen Eisblock mit einer bestimmten Fehlernummer oder Versionsnummer kennzeichnen können müssen. Dafür sind ggf. Tools oder Zusatzprogrammierungen (beispielsweise umfangreiche Protokollmechanismen) erforderlich. Noch schwieriger wird es, wenn Sie zur Durchführung eines Tests eine ganz bestimmte Datensituation benötigen. Wenn beispielsweise bei einer Verwaltungssoftware die Übertragung von Restmitteln aus Budgets ins neue Wirtschaftsjahr getestet werden soll, so müssen Sie wahrscheinlich für alle Monate eines Jahres plausible Daten vorliegen haben, zum Ausführen des Tests müssen alle Rechneruhren des Neztes ein Datum vom Ende eines Wirtschaftsjahres haben und dann müssen auch noch alle anderen Abhängigkeiten für den

72


Wechsel in ein neues Wirtschaftsjahr korrekt eingestellt sein. Dies zeigt, dass die Schaffung der Ausgangssituation eines Tests oft das Aufwändigste am ganzen Test ist. Aber die Bestimmung des genauen Aufwands zur Festlegung der Testprozesse im Projektplan ist in einem frühen Stadium des Projekts sicherlich auch sehr aufwändig.Diese Seite verdeutlicht, wie unglaublich groß der Gesamtaufwand beim systematischen Testen werden kann. Es ist stets mehr Zeit erforderlich, als man vorher glaubte und der erste Fehler, den man dabei macht, ist vielleicht der, der durch den Spruch oben auf dieser Seite beschrieben wird. Denn die Software (bzw. die Iterationsstufe) ist ja "eigentlich" fertig und man möchte den Rest jetzt nur noch möglichst schnell hinter sich bringen.

8.5 Qualität"Es kann passieren, was will: Es gibt immer einen, der es kommen sah."(Fernandel)

Reduzieren Sie das Thema zunächst einfach auf diese beiden Aussagen:- Qualität ist die Erfüllung aller Anforderungen.- Wenn eine Anforderung nicht erfüllt ist, so ist dies ein Fehler.ISO 8402: "Qualität ist die Gesamtheit von Merkmalen einer Betrachtungseinheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen"EN 29004 / ISO 9004 "Qualitätsmanagement und Elemente eines Qualitätssicherungssystems-Leitfaden" Absatz 14.1 definiert Fehler als die Situation, "dass Materialien, Bauteile oder Endprodukte die festgelegten Forderungen nicht erfüllen können." [B5].Qualität heißt MessbarkeitTesten ist die Methode, mit der Qualität nachgewiesen wirdTestszenarien (programmierte Test Cases) im Simulationsmodell automatisiert (mit Protokoll)"SPICE" steht für "Software Process Improvement and Capability Determination" (Verbesserung des Softwareprozesses und Bestimmung der Leistungsfähigkeit) und stellt eine internationale Initiative zur Entwicklung eines Standards zur Beurteilung der Softwareprozesse dar. Im Wesentlichen handelt es sich um einen Satz von Dokumenten, die als Vorlage verwendet werden können und 1995 erstmalig vorgestellt wurden. Darin wird nicht nur die Softwareentwicklung betrachtet, sondern beispielsweise auch die Evaluierung von Softwareprodukten, so dass dieser Dokumentensatz für alle interessant ist, die in irgendeiner Form mit Software konfrontiert werden.Oder wie es in [L17] ausgedrückt wird: "This framework can be used by organizations involved in planning, managing, monitoring, controlling and improving the acquisition, supply, development, operation, evolution and support of software" (Dieser Rahmen kann von Unternehmen genutzt werden, die mit Planung, Organisation, Überwachung, Kontrolle und Verbesserung von Anschaffung, Lieferung, Entwicklung, Betrieb, Fortschritt und Unterstützung von Software beschäftigt sind).Begriffsdefinitionen: Gefahr = Bedingung, die einen Unfall verursachen kann, wenn zusätzlich weitere Ereignisse eintreten Versagen = Unvermögen einer Systemkomponente, seine vorgesehene Funktion zu erfüllen Risiko = Kombination der Wahrscheinlichkeit eines Versagens mit dessen Konsequenzen Unfall = Ereignis, das Schaden anrichtet Zuverlässigkeit = Maß für die Wahrscheinlichkeit, dass die geforderten Funktionen über eine bestimmte Zeit hinweg erfüllt werden Sicherheit = Wahrscheinlichkeit, mit der Gefahren auftauchen

73


9 Übergang

9.1 Übergang der Software an den Kunden"Sagt der Walfisch zum Thunfisch: 'Das kannst du doch nicht tun Fisch.'Sagt der Thunfisch zum Walfisch: 'Da hab ich keine Wahl Fisch.'"(Unbekannt)

Von einem "Launch" ("Start") spricht man eher bei einem kommerziellen Produkt (so richtig mit Handbuch im Vierfarbkarton), das in Stückzahlen hergestellt und über Distributionskanäle verkauft wird. In dem Moment, wo die Auslieferung des Produkts beginnt, spricht man auch von "Shipping" (Lieferung). Es gab mal einen sehr interessanten Vortrag auf einem der ersten Microsoft TechTalks von dem Produktmanager von Excel 3; er nannte den Vortrag "Shipping Software", weil er dies als Hauptziel einer jeden Softwareentwicklung betrachtete und damit den Entwicklern klar machen wollte, dass eben nicht die Entwicklung selbst das Wesentliche ist, sondern das Produkt, das am Ende steht! Eine weitere Bezeichnung für die Auslieferung der fertigen Software ist "Roll Out". Diese ist der Luftfahrtindustrie entnommen; dort wird das erstmalige Herausrollen des Flugzeugs aus dem Hanger nach der Fertigstellung so bezeichnet. Ich persönlich finde diesen Begriff allerdings für neue Netzwerkverkabelungen viel passender als für Software, denn Netze werden ja auch ausgerollt.

Abnahme nach Leistungsbeschreibung (Akzeptanzkriterien der Anforderungen)

Abnahmeprotokoll mit Restpunkteliste für die Nachbesserungenauf vereinbarte Konventionalstrafen achten

Inbetriebnahme- direkte Umstellung- Parallellauf- Versuchslauf- Pilotinstallation

Installation nur mit Administratoren des Kunden zusammen!!!

74


10 Wartung

10.1 Wartung"Und immer wenn du denkst, es geht nicht mehr, kommt von irgendwo ein Lichtlein her."(altdeutsche Weisheit)

Haftung, Garantie, Gewährleistung, Sachmängel Software IST fehlerhaft!- Serviceplan definieren Auch Software altert!- Update-Stufen entwerfen- Versionsmanagement Helfen Sie!- Coaching- Training- Support Nachvertrag

75


11 Verweise

11.1 HTTP-Links"Der moderne Mensch hat ein neues Laster erfunden: die Schnelligkeit."(Aldous Huxley)

[L1] http://members.aol.com/acockburn/ Firma Alistair Cockburn, Humans and Technology[L2] http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap Extreme Programming Roadmap[L3] http://www.omg.org OMG (Object Management Group)[L4] http://www.oose.de/gmbh/ Firma oose[L5] http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html Patterns and Software: Essen-

tial Concepts and Terminology[L6] http://hillside.net/patterns/ Patterns Home Page[L7] http://www.rational-software.de/ Firma Rational Software[L8] http://www.well.com/user/smalin/miller.html The Magical Number Seven[L9] http://www.roesch.com/ Firma Rösch Consulting[L10] http://www.scheissprojekt.de Scheissprojekt[L11] http://www.uml.org UML (Unified Modeling Language)[L12] http://www.usecases.org Use Cases[L13] http://www.microsoft.com/windows2000/server/evaluation/news/fromms/kanovalentine.asp

What the Boss Should Know[L14] http://www.ANSI.org ANSI[L15] http://www.microsoft.com/germany Firma Microsoft[L16] http://www.corba.org CORBA[L17] http://www.sqi.gu.edu.au/spice/ SPICE[L18] http://www.mindjet.de MindManager[L19] http://www.therationaledge.com/ The Rational Edge[L20] http://www.omg.org/mda/ MDA (Model Driven Architecture)

76

http://www.omg.org/mda/

http://www.therationaledge.com/

http://www.mindjet.de/

http://www.sqi.gu.edu.au/spice/

http://www.corba.org/

http://www.microsoft.com/germany

http://www.ANSI.org/

http://www.microsoft.com/windows2000/server/evaluation/news/fromms/kanovalentine.asp

http://www.usecases.org/

http://www.uml.org/

http://www.scheissprojekt.de/

http://www.roesch.com/

http://www.well.com/user/smalin/miller.html

http://www.rational-software.de/

http://hillside.net/patterns/

http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html

http://www.oose.de/gmbh/

http://www.omg.org/

http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

http://members.aol.com/acockburn/


11.2 Bücher"Ein guter Spruch ist die Wahrheit eines ganzen Buches in einem einzigen Satz."(Theodor Fontane)

Titel Autoren ISBN

[B1] Code Complete Steve C. McConnell 1-556-15484-4

[B2] Das UML-Benutzerhandbuch Grady Booch - Jim Rumbaugh - Ivar Jacobson 3-827-31486-0

[B3] Deep Time Gregory Benford 0-380-97537-8

[B4]Digitales Verhängnis - Gefahren der Abhängigkeit von Computern und Programmen

Lauren Ruth Wiener 3-89319-672-2

[B5] Qualitätssicherung und angewandte Statistik, Verfahren 3: Qualitätssicherungssysteme DIN-Taschenbuch 226, Beuth 1992 3-410-12761-5

[B6] Iacocca. Eine amerikanische Karriere Lee Iacocca & William Novak 3-430-14937-1

[B7] Lehrbuch der Objektmodellierung, Analyse und Entwurf Heide Balzert 3-827-40285-9

[B8] Per Anhalter durch die Galaxis Douglas Adams 3-453-14697-2

[B9] The Hitchhiker´s Guide to the Galaxy Douglas Adams 0-517-14925-7

[B10] The Mythical Man Month Frederick P. Brooks, Jr. 0-201-835959

[B11] The One Minute Manager Kenneth Banchard, Ph.D. & Spencer Johnson, M.D. 0-688-01429-1

[B12] The Practice of Programming Brian W. Kernighan & Rob Pike 0-201-61586-X

[B13] UML konzentriert Martin Fowler und Kendall Scott 3-8273-1617-0

[B14] Writing Effective Use Cases Alistair Cockburn 0-201-70225-8

[B15] Writing Solid Code Steve Maguire 1-556-15551-4

[B16] Software Engineering Economics Barry W. Boehm 0-138-22122-7

[B17] Analysemuster - Wiederverwendbare Objektmodelle Martin Fowler 3-8273-1434-8

[B18] Best of Booch Grady Booch 0-13-739616-3

[B19] Cyber Rules Thomas M. Siebel, Pat House 0-385-49412-23478245206

[B20] Entwurfsmuster Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

3-89319-950-03827318629

[B21] Der Krieg des Codes. Wie Microsoft ein neues Betriebssystem

G. Pascal Zachary 345511038X

77


entwickelt. (Englischer Titel: Showstopper)

[B22] Whale Done! The Power of Positive Relationships

Ken Blanchard, Thad Lacinak, Chuck Thompkins, Jim Ballard 0-7432-3538-X

[B23] Who Moved My Cheese? Spencer Johnson, M.D. 0-399-14446-3

[B24]

Erfolgreich mit ObjektorientierungVorgehensmodelle und Managementpraktiken für die objektorientierte Softwareentwicklung

Oestereich (Hrsg.), Hruschka/Josuttis/Kocher, Krasemann/Reinhold

3-486-25277-1

78


12 Anlagen

12.1 HütchenspielDiese Quelle habe ich während eines C-Kurses mit den Teilnehmern gemeinsam gebaut. Wir haben dabei viel Wert auf eine systematische Vorgehensweise gelegt. Wer mich kennt, der weiß, dass ich kein Command-Line-Junkie bin; ich wollte hier aber zeigen, dass selbst nur mit dem vi (ein sehr spartanischer UNIX-Editor) systematisch und in kurzer Zeit entwickelt werden kann. Übersetzt haben wir diese Quelle mit dem GNU C-Compiler der Linux-Distribution RedHat 7.0.Gemäß meiner Darstellung in dieser Abhandlung haben wir das Problem über den Namen, den Zielsatz, einem kleinen Fachkonzept, einer Sammlung der fachlichen und technischen Anforderungen, einem Zweck- und Tragweiten-Diagramm, einer Sammlung von Anwendungsfällen, einem Aktivitätendiagramm mit konzeptioneller, spezifizierender und implementierender Sicht, einer Datensammlung und schließlich einer Schnittstellenbeschreibung herunter gebrochen - wohlbemerkt, alles im vi!Das eigentliche Programmieren bestand nachher nur noch aus einem Herunterschreiben der Schnittstellen als Funktionen, dem Ausfüllen der Funktionen mit den Informationen aus der implementierenden Sicht des Aktivitätendiagramms, dem Deklarieren der gesammelten Daten sowie dem weiteren Ausfüllen der Funktionen. Die Teilnehmer des Kurses waren überrascht, dass der Compiler nach nur zwei Syntaxfehlern durchlief und das Programm dann auf Anhieb funktionierte ;-) Es ist zwar ein super kleines Programm, aber keiner hatte erwartet, dass die gesamte Entwicklung dieses Spielchens live im Kurs nur drei Stunden dauern würde (und die Dokumentation ist integriert!).Die Quelle folgt auf der nächsten Seite.

79


/*

SOFTWARE SYSTEM NAME:SoftHat

MAIN GOAL:SoftHat is a game where someone trys to lose money to the machine.

USER SPECIFICATION:A fix account of 100 bucks is assumed. A user places the money onto the desk and guesses under which of 3 hats the ball resides. Some strange guy is mixing the hats very quickly and the player has to decide under which hat the ball might be. If he's right he get's the money he placed onto the desk doubled; if he's wrong he loses his money. Then he might play again to get rich or poor.

BUSINESS REQUIREMENTS:starting money account of 100 buckssome money3 hats1 ballmixing algorithm1 player (the 2nd one is the machine)player guessesaccount modification (more if won, less if lost)decision for continuation

TECHNICAL REQUIREMENTS:implementation on some linux systemsC-languagerunnable on standard Intel machines

PURPOSE AND SCOPE DIAGRAM:

pays money +-------------------------+ O ----------------------------> | | /|\ guesses ball position | System Under Design | | ----------------------------> | | / \ mixes hats | | <---------------------------- | | gives results | | <---------------------------- | | +-------------------------+

BUSINESS USE CASES:<Rule>: User is named "player"UC1 Player pays moneyUC2 Player guesses ball positionUC3 Player decides for next turn

SYSTEM USE CASES:UC4 System sets starting accountUC5 System mixes the hatsUC6 System proofs resultUC7 Player gets payed back doubledUC8 Player looses his money

DERIVED USE CASES:UC9 SYSTEM: Welcome-messageUC10 SYSTEM: Display starting accountUC11 SYSTEM: increments the account by the doubled moneyUC12 SYSTEM: decrements the account by the money

USE CASE DESCRIPTIONS:UC5 System mixes the hats This use case should have an algorithm for generating a ball position (i.e. a hat number) randomly. We may use the system time in milliseconds as a base to generate a really new number every time.

USE CASE ORDER:UC9 UC4 UC10 UC1 UC5 UC2 UC6 UC7(UC11)/UC8(UC12) UC3

80


ACTIVITY DIAGRAM:

conceptual specifications implementation^| +---------------------------------+| | UC9: Welcome-message | "Hy, I'm SoftHat." printf (...);| +---------------------------------+| || || VBanner() +---------------------------------+| | UC4: set starting account | set variable "Account" int iAccount = 100| +---------------------------------+| || || V| +---------------------------------+| | UC10: display starting account | "You have n bucks." printf (". %d .\n", iAccount);| +---------------------------------+V | +-------------------->| do {^ | V| | +---------------------------------+Pay() | UC1: pay money | set variable "Money" int iMoney;| | +---------------------------------+ scanf ("%d", &iMoney);V | | | |^ V| +---------------------------------+Mix() | UC5: mixing | set variable "Position" srand (time (NULL));| +---------------------------------+ by randomizing algorithm int iPosition = (rand()%3)+1V | |^ V| +---------------------------------+Guess() | UC2: guess | set variable "Choice" int iChoice;| +---------------------------------+ scanf ("%d", &iChoice);V | |^ V| +---------------------------------+| < UC6: proof result (equal?) > "Position" equal to "Choice"? if (iPosition == iChoice)| +---------------------------------+| / \ | y / \ n| / \| / \Proof() V V| +-----------------+ +-----------------+| | UC7: pay back | | UC8: loose | modify variable "Account"| +-----------------+ +-----------------+| | || | || V V| +-----------------+ +-----------------+| | UC11: increment | | UC12: decrement | increment variable "Account" iAccount += iMoney;| | account | | account | or decrement variable "Account" iAccount -= iMoney;| +-----------------+ +-----------------+V \ / \ /^ V V| +---------------------------------+Decide() < UC3: decision > char cAnswer;| +---------------------------------+ scanf ("%c", &cAnswer);V / | ^ replay/ |exit | / | +------------ V } while (cAnswer == 'y');

81


DATA:int iAccount; used by: Banner(), Proof()int iMoney; used by: Pay(), Proof()

INTERFACES:void Banner(int *piAccount);void Pay(int *piMoney);int Mix(void); returns iPosition int Guess(void); returns iChoice void Proof(int iPosition, int iChoice, int *piAccount, int iMoney);int Decide(void); returns 1 for continue and 0 for exit

GLOSSAR:Player: is the user using the program, i.e. the player playing the game*/

#include "stdio.h"#include "stdlib.h"#include "time.h"

#define ACCOUNT 100

void Banner(int *piAccount);void Pay(int *piMoney);int Mix(void); /* returns iPosition */int Guess(void); /* returns iChoice */void Proof(int iPosition, int iChoice, int *piAccount, int iMoney);int Decide(void); /* returns 1 for continue and 0 for exit */

int main () {int iAccount;int iMoney;

Banner (&iAccount);do {

Pay (&iMoney);Proof (Mix (), Guess (), &iAccount, iMoney);

} while (Decide () == 1);return 0;

}

void Banner(int *piAccount) {printf ("Hy, I'm SoftHat.\n");printf ("You have %d bucks.\n", *piAccount = ACCOUNT);

}

void Pay(int *piMoney) {printf ("How much money do you want to lose ;-) ");scanf ("%d", piMoney);printf ("\n");

}

int Mix(void) {srand ((unsigned)time (NULL));return (rand() % 3) + 1;

}

int Guess(void) {int iChoice;

do {printf ("Where is the ball? (1,2,3) ");scanf ("%d", &iChoice);printf ("\n");

} while (iChoice < 1 || iChoice > 3);

return iChoice;}

82


void Proof(int iPosition, int iChoice, int *piAccount, int iMoney) {if (iPosition == iChoice) {

/* matches means: player found our ball */*piAccount += iMoney;printf ("$$$ Congratulations $$$\n");

} else {/* no match means: player missed it */*piAccount -= iMoney;printf ("--- Sorry, you missed it ---\n");

}printf ("Your current account is: %d bucks\n", *piAccount);

}

int Decide(void) { /* returns 1 for continue and 0 for exit */char cAnswer;

do {printf ("Do you wanna play again? (y/n) ");scanf ("%c", &cAnswer);printf ("\n");

} while (cAnswer != 'y' && cAnswer != 'n');

return cAnswer == 'y' ? 1 : 0;}

83


13 Index

A

Amigos...........................................................13Analyse..........................................................13

Ä

Änderungen.....................................................8

A

Anforderung...................................................13Ansatz............................................................11ANSI...............................................................11Anwendungsfall.............................................13Ausarbeitung..................................................13

B

Bausteine.......................................................11Beispiel............................................................4Boehm............................................................12Booch.............................................................13

C

Casey.............................................................12Construction...................................................13

D

Design............................................................13Download.........................................................7

E

Echtsystem.....................................................13Elaboration.....................................................13Engineering....................................................11Entwurf..........................................................13erprobt............................................................11Etablierung.....................................................13evolutionär.....................................................11

F

Fehler.............................................................11Fleischgroßhandel..........................................11Funktionalität.................................................10

H

Hütchenspiel...................................................4I

Idealprodukt...................................................12Implementierung............................................13Inception........................................................13inkrementell...................................................13ISS................................................................10

iterativ............................................................13

J

Jacobson.........................................................13

K

Komplexität...................................................11Konstruktion..................................................13Konzept..........................................................13

L

Lebenszyklus.................................................13Leistungsumfang...........................................13Life Cycle......................................................13Logik..............................................................11

M

Managementsicht...........................................13Meilenstein....................................................13Modell............................................................12

Prototypen..................................................12Spiral..........................................................12USDP.........................................................13V 12Wasserfall..................................................12

modular..........................................................11

N

Nasa.............................................................10NATO............................................................10

O

Objektorientierung.........................................13Oesterreich.....................................................13OOSE.............................................................13Open Source....................................................7OpenOffice.org................................................7

P

Phasen............................................................13Pilotsystem.....................................................13Plausibilitätsprüfung......................................11Produktversion...............................................13Professional...................................................11Projekt............................................................11Projektphasen.................................................13Prototyp.........................................................13Prozess

Analyse......................................................13Anforderung...............................................13Design........................................................13

84


Implementierung........................................13Test............................................................13

R

Rational..........................................................13reale Welt.......................................................10robuster..........................................................11Rumbaugh......................................................13RUP...............................................................13

S

Schlachthof....................................................11Schnittstelle...................................................11Software-Engineering....................................11Softwarekrise.................................................10Software-Technik..........................................11Standard.........................................................11

Standish Group.............................................10Statistik..........................................................10

T

Technik..........................................................11Test................................................................13Transition.......................................................13

Ü

Übergabe........................................................13Übergang.......................................................13

U

Unterschätzung..............................................11USDP.............................................................13

V

Versionsstufe.................................................13

85