load PDF
Wolfgang Fahl Frank Hoffmann Erfolgsfaktoren der Softwareentwicklung Best Practises für den Weg von den Anforderungen zum richtigen Produkt HANSER Fahl/Hoffmann Erfolgsfaktoren der Softwareentwicklung Wolfgang Fahl Frank Hoffmann Erfolgsfaktoren der Softwareentwicklung Best Practises für den Weg von den Anforderungen zum richtigen Produkt HANSER Wolfgang Fahl, Willich-Schiefbahn wf@bitplan.com Frank Hoffmann, Kaarst fh@bitplan.com www.hanser.de Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthalte- nen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Information – oder Teilen davon – entsteht. Ebenso übernehmen Verlag und Autoren keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsna- men, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Die Deutsche Bibliothek - CIP Einheitsaufnahme Ein Titeldatensatz für diese Publikation ist bei der Deutschen Bibliothek erhältlich Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckens und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) - auch nicht für Zwecke der Unterrichtsgestaltung - reproduziert oder unter Verwendung elektronischer Systeme vearbeitet, vervielfältigt oder verbreitet werden. © 2002 Carl Hanser Verlag, München Wien Lektorat: Margarete Metzger Copy-editing: Herstellung: Irene Weilhart Umschlaggestaltung: Datenbelichtung, Druck und Bindung: Printed in Germany ISBN 3-446-22305-3 Inhalt Vorwort der Autoren ................................................................................................. 1 Die Brücke als Sinnbild ........................................................................................... 1 Die Umfrage............................................................................................................. 5 Literaturtipp.............................................................................................................. 7 Das Projektverwaltungs-Projekt............................................................................... 8 1 VonMenschenundComputern............................................................................9 1.1 Menschen als Handelnde.............................................................................. 9 1.2 Die zwei Blickwinkel - Mensch und Maschine.......................................... 11 1.3 Die "Brücke" vom Wunsch zur Software................................................... 13 1.4 Welches Vorgehensmodell? ....................................................................... 18 1.5 Gemeinsames Erfolgsverständnis .............................................................. 19 1.6 Die Sprache des Auftraggebers sprechen ................................................... 24 1.7 Wie wird der Auftraggeber glücklich? ....................................................... 25 1.8 Wie sicher kann ich sein, dass die Software richtig ist? ............................ 27 1.9 Literatur......................................................................................................29 2 WassolldieSoftwareleisten?.............................................................................31 2.1 Projektauswahl ........................................................................................... 31 2.2 Anforderungen aufnehmen......................................................................... 32 2.3 Prüfbeispiele dokumentieren ...................................................................... 40 2.4 Anforderungsprofil erstellen ...................................................................... 42 2.5 Änderungen der Anforderungen................................................................. 45 2.6 Der Wert von Software .............................................................................. 48 2.7 Literatur......................................................................................................50 3 Vom Anforderungsprofil zum Modell................................................................ 51 3.1 Modellieren ................................................................................................ 51 3.2 Objektorientierter Ansatz ........................................................................... 53 3.3 Ableitung des Modells aus den Anforderungen ......................................... 55 3.4 Einfach, kurz und klar - komplizierte Modelle sind falsch!....................... 61 3.5 Die Abstraktionsfalle.................................................................................. 63 3.6 Literatur......................................................................................................66 4 Vom Modell zum Code ........................................................................................ 69 4.1 Umsetzen .................................................................................................... 69 4.2 Kurze Entwicklungszyklen......................................................................... 77 4.3 Abnahme und Einführung .......................................................................... 77 4.4 Literatur......................................................................................................78 V Inhalt 5 Änderung, Wartung, Pflege ................................................................................ 79 5.1 Schrittweises Vorgehen.............................................................................. 79 5.2 Fehlermeldungen und Änderungswünsche ................................................ 79 5.3 Literatur......................................................................................................81 6 InfrastrukturundWerkzeuge............................................................................83 6.1 Arbeitsumgebung ....................................................................................... 83 6.2 Werkzeugauswahl ...................................................................................... 87 6.3 Einzelteile und Versionen .......................................................................... 92 6.4 Generierung................................................................................................ 95 6.5 Literatur......................................................................................................96 7 Projektmanagement, Kommunikation, Politik ................................................. 97 7.1 Zielorientierung.......................................................................................... 99 7.2 Entscheidungen fällen .............................................................................. 101 7.3 Vom Umgang mit Eisbergen.................................................................... 103 7.4 Das Team ................................................................................................. 105 7.5 Führung und Förderung............................................................................ 110 7.6 Projektplanung und Steuerung ................................................................. 112 7.7 Umgang mit dem Zufall ........................................................................... 114 7.8 Erfahrungen teilen .................................................................................... 118 7.9 Literatur....................................................................................................120 8 Computerfachchinesischlexikon.......................................................................121 9 Anhänge..............................................................................................................123 9.1 Liste der Erfolgsfaktoren.......................................................................... 124 9.2 Fragebogen ............................................................................................... 129 9.3 extreme Programming .............................................................................. 131 9.4 Internet Referenzen .................................................................................. 132 9.5 Literaturverzeichnis..................................................................................133 9.6 Index.........................................................................................................134 VI Vorwort der Autoren Herzlichen Glückwunsch: Sie sind bereit, aus den Erfahrungen anderer zu ler- nen! Sie haben dieses Buch in die Hand genommen und begonnen zu lesen. Sie interessieren sich für Softwareentwicklung und wollen die wesentlichen Faktoren kennenlernen, die dazu führen, dass auch Ihr Softwareprojekt ein Erfolg wird. Die Brücke als Sinnbild Die Autoren haben auf der ICRE'98 in Colorado Springs, USA, erlebt wie es möglich ist, in kurzer Zeit das Wissen von vielen Dutzend Experten zu nutzen, um ein gemeinsames Ergebnis zu schaffen. Gary Weinberg sollte damals ei- nen Vortrag zum Thema Anforderungsmanagement halten. Am Anfang des Vortrages sagte er jedoch zu den zweihundert Softwareexperten im Saal, unter denen viele angesehene Namen wie Lary Constantine und Ed Yourdon waren, dass sein Wissen nicht ausreichen würde, um für die Teilnehmer etwas wirk- lich Interessantes, Wichtiges oder Neues zu bieten. Daher bat er die Teilneh- mer, den Vortrag selbst zu gestalten. Es wurden vier Gruppen gebildet, die jeweils eine halbe Stunde Zeit bekamen ein Thema zu bearbeiten. Das "Red Team" bearbeitete die Frage "Was wäre für Sie die wertvollste Fähigkeit, die eine Person erwerben müsste, um in der Softwareentwicklung übergreifend erfolgreich zu sein?"Als Antwort entstand die folgende Skizze: "Es wäre gut Bücher kaufen, wenn man die Zeit, sie zu lesen, mitkaufen könnte, aber man verwechselt meistens den Ankauf der Bücher mit dem Aneignen ihres Inhalts." Arthur Schopenhauer 1 Vorwort der Autoren Abbildung 0.1: Die Brücke als Sinnbild für die Softwareentwicklung Softwareentwicklung wurde von den etwa fünfzig Experten im roten Team als das Schlagen der Brücke von Menschen zur Computertechnik interpretiert. Die Fähigkeit, diese beiden Seiten miteinander zu verbinden, also menschliche Faktoren wie Kommunikation, Moderation, Forschen, Abstrahieren, Manage- ment und Organisation usw. mit technologischen Faktoren wie Fachwissen, Modellierung und Methoden, Werkzeugen usw. in Einklang zu bringen, wurde als Schlüssel zum sonnigen Leben unter der ewigen Frage "Warum" herausge- stellt. Die Brückenmetapher hat uns seither in vielen Projekten geholfen, die Heraus- forderung der Softwareentwicklung klarer zu sehen. Sie hat uns geholfen, Er- folgsfaktoren zu identifizieren. Wie ist es Ihnen bisher in Ihren Projekten ergangen? Gehören Sie zu den we- nigen Glücklichen, die bisher nur an erfolgreichen Projekten beteiligt waren? Wenn ja, dann sind wir daran interessiert zu erfahren, inwieweit die hier ge- nannten Erfolgsfaktoren mit Ihren Erfahrungen übereinstimmen. Nehmen Sie Kontakt mit uns auf! Was konnten Sie Neues entdecken? Was haben Sie an- ders erlebt? Unsere Kontaktangaben finden Sie am Ende des Vorworts. Wenn Sie wie wir jedoch zu denjenigen gehören, die gemischte Erfahrungen mit Softwareprojekten gemacht haben oder wenn Sie noch keine Erfahrungen haben, dann wird Ihnen dieses Buch praktische Hinweise geben, wie Sie Ihre Erfolgschancen erhöhen können. 2 Softwareprojekte sind unendlich komplexe Vorhaben. Es ist leicht, "den Wald vor lauter Bäumen nicht mehr zu sehen". Indem Sie sich die in diesem Buch genannten Faktoren zu eigen machen werden Sie sich erheblich sicherer in Ihrem Softwareprojekt fühlen - was immer auch Ihre spezielle Softwareaufga- be sein mag. Softwareprojekte bergen ein großes Frustrationspotential und oft führt dies zu persönlichen Folgen bei den Beteiligten. In den Projekten, die wir als Referenz heranziehen haben wir oft erlebt, wie das Wesentliche aus den Augen verloren wurde und Nebenkriegsschauplätze in den Vordergrund tra- ten. Profitieren Sie vom Blick auf das Wesentliche! Sie werden feststellen, wie sich Ihre Herangehensweise an Softwareprojekte verändert. Ihre Auftraggeber werden eine höhere Sicherheit haben, dass die Software, die Sie liefern, ihre Wünsche erfüllt, und Sie werden voraussichtlich dafür gelobt werden. Ihren Mitarbeitern werden Sie besser vermitteln können, worauf es in Softwarepro- jekten ankommt. Der Beitrag Ihres Teams zu diesen Veränderungen wird für alle Beteiligten positiv spürbar werden. In den Organisationen wird Software immer mehr zum kritischen Faktor - Ihre Organisation wird also erfolgreicher werden, da sie mit größerer Zuverlässigkeit "die richtige Software" liefern kann oder erhält. Ihre Mitarbeiter werden begeistert und Ihre Kunden glück- lich sein. Wir wollen Ihnen mit diesem Buch: ! einen einfach verständlichen Weg zur Entwicklung von Software aufzei- gen. ! Ihnen schrittweise vermitteln, was notwendig ist, um Software erfolgreich zu entwickeln. ! Ihr Verständnis dafür wecken, dass die Punkte, die wir nennen unabhängig vom Inhalt oder der Art Ihres Projektes anwendbar sind. ! erreichen, dass Sie die Erfolgsfaktoren in Ihrem Projekt zur Wirkung brin- gen. In diesem Buch werden Sie lernen, die Softwareentwicklung aus zwei Blickwinkeln zu betrachten - vom Menschen her und vom Computer her. Durch diese Trennung wird es möglich, den "politischen" Teil der Softwareentwicklung - die menschliche Seite der Aufgabenstellung - so getrennt wie möglich vom inhaltlichen Teil zu betrachten und zu bearbeiten. Damit werden Sie bereits viele Probleme vermeiden können, die in Projekten durch die Mischung dieser Blickwinkel entstehen. Die "Brücke" wird als Sinnbild für die Umsetzung der Wünsche der Beteiligten in die richtige Software dienen. In fünf Kapiteln wird die Brücke schrittweise vorgestellt und zu jedem Schritt über die Brücke werden die wesentlichen Erfolgsfaktoren aufgezeigt. Damit legen wir ein solides Fundament, auf das Sie in Ihrer Projektgestaltung aufbauen können. Ein durchgängiges Beispiel für den Brückenschlag hilft Ihnen beim Verständnis und der Umsetzung in Ihrem All- tag - dieses Beispiel ist so angelegt, dass alle wesentlichen Aspekte dieses Buches daran nachvollziehbar sind. Jedes Kapitel ist mit einer Liste von Die Brücke als Sinnbild 3 Vorwort der Autoren des Kapitel ist mit einer Liste von weiterführender Literatur versehen, die Sie für die Klärung von Detailfragen zu Rate ziehen können. Wenn Sie dieses Buch gelesen haben und Ihre Mischung von Erfolgsfaktoren für die persönliche Umsetzung in Ihrem Umfeld ausgewählt und angewendet haben, hoffen wir, dass Sie unsere Webseite www.b-agile.de/Erfolgsrezepte/feedback.html !!! besuchen und uns an Ihren eigenen Erfahrungen teilhaben lassen. Dadurch werden wir erfahren, welchen Nutzen Ihre Erfolgsrezepte für Sie entfalten. Wir sind fest davon überzeugt, dass über 95% der Antworten positiv ausfallen werden, da Sie den sofortigen Nutzen in Ihrem Projekt spüren werden, den der Blick auf das Wesentliche Ihnen bietet. Die Sammlung der Erfolgsfaktoren in diesem Buch lebt sowohl von unseren eigenen Projekterfahrungen als auch von denen zahlreicher anderer, die Soft- wareprojekte durchgeführt haben. Wolfgang Fahl war seit 1986 an über 50 Softwareprojekten persönlich beteiligt. Seine Leidenschaft sind Softwarepro- jekt-Desaster und die Analyse ihrer Ursachen. Frank Hoffmann hat seit 1992 über 110 Trainings zu Themen der Softwareentwicklung durchgeführt und war an Projekten bis zu mehreren hundert Personenjahren maßgeblich beteiligt. Die Essenz aus Dutzenden von Büchern mit den Erfahrungen von Autoren mit Weltrang sind in dieses Buch eingeflossen. Schließlich sind uns in unserem Berufsleben Hunderte von Projektleitern, Softwareentwicklern und Auftrag- gebern begegnet - alle diese Menschen haben ein komplexes Bild der Soft- wareentwicklung entstehen lassen, das wir so weit wir es vermögen vereinfa- chen. Es gibt nur wenige Projekte, denen es gelungen ist, fast alle in diesem Buch genannten Erfolgsrezepte anzuwenden. Bei einem Finanzdienstleister haben wir es 1999 jedoch auf beeindruckende Weise erlebt. Das Team stand von An- fang an im Vordergrund und einigte sich darauf, wie die Brücke geschlagen werden sollte. Es wurde systematisch auf die Trennung von fachlichen und technischen Themen gesetzt. Anforderungen wurden basierend aus Szenarien mit detaillierten Abnahmekriterien aufgenommen. Es wurde ein gemeinsames Intranet-basierendes Projekttagebuch geführt, das von allen Teammitgliedern intensiv zum Austausch von Randergebnissen und offenen Punkten genutzt wurde. Entscheidungen wurden (nach anfänglichen Schwierigkeiten) systema- tisch vorangetrieben. Es wurde objektorientiert entwickelt, obwohl als Ziel- sprache lediglich klassisches COBOL zur Verfügung stand. Die fertige Soft- ware ist im April 2001 in Einsatz gegangen und hat bis heute wie gewünscht ihren Dienst getan. Die Software wird weiterentwickelt und ist äußerst anpas- sungs- und änderungsfreundlich - selbst der Wechsel der Programmiersprache nach Java ist bereits exemplarisch durchgeführt worden. Insbesondere sind alle Projektbeteiligten mit den Ergebnissen äußerst zufrieden und sprechen gerne über dieses Projekt. Sprechen Sie uns an: Wir bringen Sie mit diesem Team in Kontakt! 4 Die Umfrage Im Sommer 2002 haben wir mit einer Umfrage begonnen, um festzustellen, welche Relevanz die in diesem Buch genannten Erfolgsfaktoren für reale Pro- jekte haben. Dazu haben wir zunächst 45 Projekte im Umfang von 600 Perso- nenjahren befragt. Für jedes Projekt haben wir erfahren, wie das Projekt sei- nen Erfolg beurteilt und was die Erfolgskriterien für das Projekt sind. Zu den in diesem Buch genannten Erfolgsfaktoren gaben die Projekte an, ob der Er- folgsfaktor angewendet wurde und welchen Einfluss der Faktor auf den Erfolg des Projektes hatte. Dazu stand eine Skala von „++/stark gefördert“ bis „-- stark behindert“ zur Verfügung. Die Ergebnisse dieser Umfrage sind in dieses Buch eingeflossen. Wir nennen hier die mehrheitlich als fördernd genannten Erfolgsfaktoren. Die Liste der Erfolgsfaktoren wird von uns mit Ihrer Hilfe ständig weiter gepflegt, und sie finden diese immer aktuell unter www.b-agile.de/Erfolgsrezepte. Beteiligen Sie sich dort an der Umfrage und erfahren Sie den aktuellen Stand der Ergeb- nisse! CHAOS-Studie der Standish Group Die CHAOS-Studie wird von der Standish Group [Url5], seit 1994 durchge- führt und hat bisher über 35.000 Projekte untersucht. Die Chaos-Studie unterscheidet folgende Projektverläufe: ! Erfolgreich: Das Projekt wird im Zeit- und Kostenrahmen fertig und liefert alle Eigenschaften und Funktionen wie vereinbart ab. ! Gefährdet: Das Projekt wurde fertig und das Ergebnis läuft, aber das Bud- get oder der Termin wurde überschritten und weniger Eigenschaften und Funktionen wurden geliefert als vereinbart. ! Gescheitert: Das Projekt wird vor Fertigstellung abgebrochen, lieferte nie ein Ergebnis ab oder das Ergebnis wurde vor der Installation verworfen. In der folgenden Tabelle sind die 10 Erfolgsfaktoren aufgeführt, die laut dieser Studie die wichtigsten sind. Wir betrachten diese Erfolgfaktoren unter ihrer deutschen Bezeichnung in diesem Buch ebenfalls. Die Umfrage Rang Erfolgsfaktor lt. CHAOS 1 Executive Support 2 User Involvement 3 Experienced Project Manager 4 Clear Business Objectives Erfolgsfaktor in diesem Buch Seite Förderung durch die Verantwortlichen. 111 Identifizieren und beteiligen Sie alle 47 Betroffenen, insbesondere die Anwen- der. Erfahrener Projektleiter. 111 Definieren Sie die Projektziele klar an- 80 hand von messbaren Kriterien und fest- 5 Vorwort der Autoren Rang Erfolgsfaktor lt. CHAOS 5 Minimized Scope 7 Firm Basic Requirements 9 Reliable Estimates 10 Skilled Staff Erfolgsfaktor in diesem Buch gelegten Werten. Seite Die richtig priorisierte Auswahl der An- 42 forderungen legt das zu realisierende Anforderungsprofil fest. Achten Sie darauf, dass die Rahmenan- 48 forderungen für Ihr Projekt stabil blei- ben. Je zuverlässiger Ihre Schätzungen sind, 111 desto besser. Fähige Mitarbeiter. 110 6 Standard Infrastructure Kümmern Sie sich rechtzeitig um eine adäquate und standardisierte Infrastruk- tur/Arbeitsumgebung für Ihr Software- projekt. 84 8 Formal Methodology Einigen Sie sich auf ein für Ihr Projekt geeignetes Vorgehensmodell und wenden Sie dieses aus Überzeugung an. 18 Kennzeichnung der Erfolgsfaktoren Wir haben viel weggelassen. Das was übrig bleibt, sind unserer Ansicht nach die Punkte, die in praktisch jedem Projekt eine Rolle spielen. Entsprechend der Ergebnisse der Umfrage und der CHAOS-Studie haben wir die Relevanz der Erfolgsfaktoren wie folgt gekennzeichnet: Symbol Relevanz Wichtiger Erfolgsfaktor, der laut Umfrage/Studie den Erfolg der Projekte mehrheitlich stark gefördert hat. Erfolgsfaktor, der laut Umfrage/Studie den Erfolg der Projekte mehrheitlich gefördert hat. Entscheiden Sie für sich selbst, welche Faktoren für Sie wichtig sind. Und achten Sie darauf, dass es wichtiger ist, die richtigen Dinge zu tun als die Din- ge richtig zu tun! Ihre Meinung ist uns wichtig Unter www.bitplan.com/Erfolgsfaktoren/index.html finden Sie weiteres Hin- tergrundmaterial zu diesem Buch. Dort finden sie auch alle Details des Bei- spiels. # Praxistipp der Autoren, der unserer Erfahrung nach den Projekterfolg fördert.. 6 Ihre Meinung interessiert uns! Über die Web-Site können Sie Kontakt mit uns aufnehmen. Danksagungen Dieses Buch hat schon einige Jahre „gegärt“ bevor es geschrieben wurde. Vie- le der hier vorgestellten Ideen sind schon in der Zeit von 1996-1999 geboren worden, in der die Autoren noch für Martin Rösch tätig waren. Ihm danken wir für die Inspiration und das fundamentale Verständnis des Softwareengi- neering, das wir durch ihn gewonnen haben. Den Teilnehmern an der Umfrage – insbesondere der ersten Version bei den Agility Days in Herrsching 2002 – danken wir für die spontante Bereitschaft, bei der Bewertung der Erfolgsfaktoren mitzuwirken. Viele weitere Kunden, Lieferanten, Partner, Freunde und Verwandte haben an diesem Buch mitgewirkt und verdienen unseren Dank dafür. Wolfgang Fahl (fahl@b-agile.de) !!! Frank Hoffmann (hoffmann@b-agile.de) !!! Literaturtipp Literaturtipp [Ber93] R. Berth: Erfolg, Econ, 1993 Das Buch heisst schlicht „Erfolg“. Es richtet sich an Manager und hat das vorliegende Buch inspiriert. Insbesondere gibt es eine Übersicht von Erfolgfaktoren für die innovative Zukunftsbewälti- gung von Unternehmen zusammen mit einer durch Unternehmens- daten fundierten Bewertung. Erfolgsfaktor Nr. 1 für Unternehmen mit einer Wirkung von 347% gegenüber dem Durchschnitt ist dem- nach „Ergänzendes Aufeinanderzugehen“ 7 Vorwort der Autoren Das Projektverwaltungs-Projekt Die folgende fiktive Ausgangssituation wird in diesem Buch durchgängig als Beispielprojekt herangezogen: Hr. Aufenberg ist Vorstand der Gründer Software AG. Dieses Software- Unternehmen wurde 1989 als GmbH gegründet und hat in seiner 13-jährigen Firmengeschichte mit kundenspezifischer Software für die unterschiedlichsten Branchen ein stürmisches Wachstum erreicht. Die Gründermannschaft von fünf erfahrenen Softwareentwicklern ist inzwi- schen auf die stolze Größe von 178 Mitarbeitern gewachsen, davon sind 120 ak- tiv in der Softwareentwicklung im Kundenauftrag tätig. Vor einem Jahr erfolgte die Umwandlung in eine AG. Inzwischen wickelt das Unternehmen ca 20 Soft- ware-Projekte jährlich ab, die eine durchschnittliche Größe von sechs Personen- jahren haben. Das vor Jahren selbst im Hause (noch unter Beteiligung des Unternehmens- gründers Dr. Gründer) entwickelte System PVW zur Projektverwaltung ent- spricht nicht mehr den Ansprüchen des Unternehmens, und Hr. Aufenberg be- schließt daher selbst als Auftraggeber aufzutreten. Er möchte sich ein neues Projektverwaltungssystem entwickeln lassen. Das vielversprechenste Angebot hat die PV-Soft GmbH gemacht. Fr. Probst ist dort die Projektleiterin. Das von ihr zusammengestellte Team besteht aus Hr. Anglet, Fr. Entrop und Hr. Teschner. Von den ursprünglichen Entwicklern des hauseigenen Projektverwaltungsystems der Gründer-Software AG ist nur noch Hr. Exner im Unternehmen. Er soll helfen, PV-Soft zu erklären, was für die neue Lösung unbedingt genauso gelöst werden muss wie im alten System. Die Namen der Personen in diesem Beispiels sind so gewählt, dass die Rolle der Beteiligten durch die ersten Buchstaben des Nachnamens angedeutet wird: ! Hr. Aufenberg ist Auftraggeber ! Frau Probst ist Projektleiterin ! Hr. Anglet kümmet sich um die Anforderungen ! Fr. Entrop ist Entwicklerin ! Hr. Teschner hat die Verantwortung für die Tests ! Hr. Exner hat das „Ex“-System PVW mitentwickelt 8 „Wir alle haben aus der Welt nur zu sehr einen Computer gemacht und diese abermalige Erschaffung der Welt hat lange begonnen, bevor es elektronische Computer gab.“ Joseph Weizenbaum 1 Wie können wir sicherstellen, dass die Computer dieser Welt das tun, was wir Menschen von ihnen wollen? Wie kann ich sicherstellen, dass mein Computer tut, was ich von ihm will? Alle Computer dieser Welt werden durch Software gesteuert. Das Verhalten von Computern lässt sich im Wesentlichen dadurch verändern, dass die zuge- hörige Software geändert wird. Der entscheidende Moment dafür ist das Soft- wareprojekt, in dem die Software erstellt bzw. gewartet wird. Im Softwarepro- jekt stellen die beteiligten Menschen die Weichen dafür, was der Computer tun kann und welche Möglichkeiten die späteren Anwender haben, um zu be- einflussen, was der Computer tun soll. 1.1 Menschen als Handelnde Im Mittelpunkt aller Softwareprojekte stehen Menschen, die Software- Wünsche haben. Sie haben eine mehr oder weniger grobe Vorstellung vom neuen System. Sie sind die potentiellen Anforderungssteller. Ihre Vorstellun- gen müssen in die Software systematisch einfliessen. Ein Team von weiteren Menschen ist dafür verantwortlich, dass dies ge- schieht. 1 Von Menschen und Computern Von Menschen und Computern Wie Menschen den Erfolg beeinflussen Wie schätzen Sie die Chancen Ihres Projektes ein, wenn "die richtigen Men- schen" beteiligt wären? Wie sehr ist das Scheitern eines Projektes auf "das falsche Team" zurückzuführen? Der Erfolg Ihres Projektes steht und fällt mit den beteiligten Menschen. Die sogenannten "weichen" Faktoren beeinflussen das Projekt weit mehr als die Bezeichnung "weich" andeutet. Wir stellen diesen Erfolgsfaktor als ersten und wichtigsten Faktor heraus. Die weiteren in diesem Buch genannten Faktoren können nur dann ihre Wirkung entfalten, wenn die beteiligten Menschen sich diesen ersten zu eigen machen und ihr gemeinsames Handeln danach ausrichten. Dazu ist viel Überzeugungs- arbeit und eigene Überzeugung erforderlich. In diesem Buch gehen wir bewusst auf die „weichen“ Themen der Software- entwicklung vor allem im Rahmen weiterer konkreter Erfolgsfaktoren ein. Es ist unserer Ansicht nach im Zusammenhang mit Menschen unmöglich, allge- meine Ratschläge zu geben, die in jeder Situation helfen. Jede Begegnung von Menschen ist einzigartig. Es ist hilft aber im Umgang mit Menschen grundsätzlich zu verstehen, wie Kommunikation „funktioniert“. Nach [Thu81] verläuft jede Verständigung auf vier Ebenen: ! Sachinhalt ! Beziehung ! Appell ! Selbstkundgabe Der Auftraggeber Hr. Aufenberg und die Projektleiterin Fr. Probst sowie das vorgesehene Team Hr. Anglet, Fr. Entrop und Hr. Teschner kennen sich seit mehren Jahren und haben schon mehrere Projekte in Kooperation für gemein- same Kunden erfolgreich absolviert. Die „Chemie“ zwischen diesen Beteiligten stimmt. Hr. Exner betrachtet das Projekt jedoch skeptisch. Er hat Angst um sei- nen Arbeitsplatz und identifiziert sich vor allem mit der jetzigen Lösung, die er ja noch mit Dr. Gründer zusammen entwickelt hat. Er betrachtet den Versuch von Hr. Aufenberg, dieses System abzulösen als „Frevel“. Wenn Hr. Exner also einen Satz spricht wie „Das PVW-System läuft doch noch prima!“, dann stecken darin mehrere Aussagen gleichzeitig: ! auf der Sachebene: „Das PVW-System ist im Einsatz und die Verfügbar- keit und Fehlerrate entspricht den Vorgaben“ ! auf der Beziehungsebene kann etwas wie: „Ich mag den Hr. Aufenberg umso weniger, je mehr er versucht das PVW-System abzulösen. 10 Erfolgsfaktor: Menschen bilden das Fundament des Erfolges ! auf der Appellebene könnte es „Lasst das PVW-System bestehen!“ bedeu- ten ! im Rahmen der Selbstkundgabe hört jemand vielleicht „Ich bin ein hervor- ragender Softwareexperte - das PVW-System ist von mir“. Was beim Hörer einer Aussage ankommt entscheided dieser viel mehr als der- jenige, der die Aussage formuliert. Wichtiger noch, die Aussage in Textform spielt eine unbedeutende Rolle - der „Ton macht die Musik“. Gestik, Mimik und Haltung werden viel stärker wahrgenommen als der Inhalt einer Nach- richt. Im Abschnitt 7.3 „Vom Umgang mit Eisbergen“ gehen wir noch näher darauf ein, wie 90% der Kommunikation von nicht direkt wahrnehmbaren An- teilen geprägt sind. Die Art, wie wir mit anderen umgehen ist stark von einigen Grundstilen ge- prägt, die in [Thu89] geprägt sind. Unserer Erfahrungen und das Wertesystem in dem wir aufgewachsen sind prägt sehr stark, wie wir gegenüber Anderen auftreten. Manchmal kommt es bei der Begegnung von zwei Menschen mit gegensätzlichem Umgangsstil zu „Teufelskreisen“. Eine solche Situation ensteht zum Beispiel oft, wenn ein Mensch mit „Helfer“-Charakter auf jeman- den triff, der dazu neigt die Rolle des „Hilflosen“ einzunehmen. Die Abhän- gigkeit des Hilflosen vom Helfer verstärkt sich je mehr der Helfer versucht Unterstützung zu geben. Alle diese Zusammenhänge spielen in der Softwarentwicklung deswegen eine so grosse Rolle, weil in den Anfängen der Informatik die Technik und Ma- thematik im Vordergrund stand. Es herrschte lange Jahre die Vorstellung, dass die Verbesserung der technischen Verfahren die Softwareentwicklung erheb- lich rationalisieren würde. In Wirklichkeit sind die Verbesserungen auf diesem Weg weit hinter den Erwartungen zurückgeblieben. Die Möglichkeiten, die in den Menschen stecken, wenn sie gemeinsam Software erstellen, sind noch lange nicht ausgeschöpft. 1.2 Die zwei Blickwinkel - Mensch und Maschine Probleme, die mit dem Computer gelöst werden sollen, kann man von zwei Blickwinkeln aus betrachten: ! vom Menschen aus ! vom Computer aus Woran liegt es, dass es so schwer ist, Probleme, die sich mit dem Computer lösen lassen, auch wirklich mit dem Computer zu lösen? Wie oft haben Sie schon erlebt, dass Computerlösungen, die Sie gekauft, in Auftrag gegeben o- der erstellt haben, wirklich das tun, was Sie sich gewünscht haben oder was Ihnen beim Kauf versprochen wurde? Die zwei Blickwinkel - Mensch und Maschine 11 Von Menschen und Computern # Eine der Ursachen für die Antworten, die Ihnen in den Sinn gekommen sind lautet: "Es ist schrecklich schwer, Ihr Problem zu lösen, wenn man es aus- schliesslich oder vorwiegend aus Sicht des Computers betrachtet". Erfolgsfaktor: Betrachten Sie das zu lösende Probleme aus den zwei Blickwinkeln: 1. Vom Menschen aus 2. Vom Computer aus Verbinden Sie dann die Sichten miteinander. Normalerweise stossen bei der Aufgabe, ein Problem mit dem Computer zu lösen, zwei Parteien aufeinander: ! Auftraggeber Die eine Partei betrachtet das Problem aus der Sicht des Auftraggebers, Kunden bzw. Nutzers - das ist die vorwiegend menschliche Betrachtungs- weise. Es geht hier um die "wirklichen Dinge des Lebens" - es kann um Grundbedürfnisse wie Wasser oder Brot oder alltägliche Güter wie Autos, Versicherungen oder Strom gehen. Manchmal sind Spezialgebiete betrof- fen, wie medizinische Geräte, Sprachwissenschaft oder Theologie. In unse- rem Beispiel ist die Gründer Software AG der Auftraggeber. Der Auftraggeber weiss oder hofft, dass sein Problem aus der Alltagswelt, in der er sich bewegt, mit dem Computer lösen lässt. Er hat eine halbwegs klare Vorstellung davon, was sein Problem ist und wie die Lösung in seiner mehr oder weniger laienhaften Vorstellung ungefähr aussehen könnte. Er ist in der Lage, sein Problem zu beschreiben und zu sagen, wann er mit ei- ner vorgeschlagenen oder wirklich erstellten Lösung zufrieden wäre. Ne- ben dem sachlichen Problem, das zu lösen ist, "menschelt" es hier gehörig: Es sind Wünsche und Hoffnungen und Gefühle, Phantasien und Ängste im Spiel. Oft ist der "Auftraggeber" nicht eine einzelne Person sondern tritt als eine Gruppe von Personen auf, die sich erst einmal einigen müssen, was sie eigentlich gemeinsam wollen. Die menschlichen Faktoren vervielfachen sich nun, in vielen solchen Auftraggebersituation entsteht eine richtig "po- litische" Situation. Unterschiedliche Interessen treffen aufeinander und es müssen Entscheidungen getroffen, sowie Kompromisse ausgehandelt wer- den. Die obigen Aussagen bzgl. der "klaren Vorstellung, was das Problem ist, und wie die Lösung aussehen könnte" sind zunächst nicht sofort zutref- fend, sondern es bedarf bereits einiger Anstrengung, um diesen Zustand zu erreichen. ! Auftragnehmer Die andere Partei betrachtet das Problem aus der Sicht eines Auftragneh- mers, Lieferanten bzw. Lösungserstellers. Hier treten die Spezialisten aus dem Computerbereich auf - und wer wird ihnen verdenken, dass hier vor- wiegend die Sichtweise aus dem Blickwinkel "Computer" anzutreffen ist. Hier geht es um die technische Seite des Problems und da hat die Compu- terei ja einiges an Kauderwelsch und Fachchinesich zu bieten, um diese 12 Sichtweise auszudrücken. In unserem Beispiel ist die PV-Soft GmbH der Auftragnehmer. Der Auftragnehmer hat die Verantwortung dafür, das was der Auftraggeber verlangt, in eine funktionierende Computerlösung umzu- setzen. Hr. Aufenberg interessiert sich als Manager kaum für die technische Umsetzung des Problems. Ihm kommt es darauf an, den Überblick über die Projekte zu be- halten und aus den Projektzahlen die Angaben für den Quartalsbericht zusam- menstellen zu können, damit er seinen Aktionären Rede und Antwort stehen kann. Hr. Exner kennt noch jedes Bit der ursprünglich in Assembler und COBOL realisierten ersten Projektverwaltungslösung, die Hr. Gründer noch aus seiner Urzeit als Entwickler mitgebracht hatte. Die Techniker der Firma PV- Soft sind vor allem daran interessiert, die neuesten Webtechnologien bei diesem Projekt endlich ausprobieren zu können. Fr. Probst sieht es als Projektleiterin als ihre wichtigste Aufgabe an zwischen den Beteiligten zu vermitteln und einen Interessenausgleich zu schaffen. Es ist eigentlich also ganz einfach: Der Auftraggeber sagt, was er verlangt und der Auftragnehmer sorgt dafür, dass der Computer das Verlangte leistet. Wa- rum gelingt das nicht immer wie erhofft? Wie steigen die Chancen dafür, dass es gelingt? In den folgenden Abschnitten finden Sie einige Antworten auf diese Fragen. 1.3 Die "Brücke" vom Wunsch zur Software Die "Brücke" vom Wunsch zur Software Im Vorwort haben wir Ihnen bereits die „Brücke“ als Sinnbild für die Softwarentwicklung vorgestellt. Die folgenden Abbildungen zeigen dieses Sinnbild mit einem typischen objektorientierten Vorgehen als Unterteilung der Schritte über die Brücke Abbildung 1.1 zeigt die grobe Einteilung in vier Ab- schnitte: ! Was - Was soll die Software leisten? ! Wie - Wie soll das Verlangte umgesetzt werden? ! Umsetzung ! Prüfen - Ist das Verlangte umgesetzt worden? 13 Von Menschen und Computern Mensch - - Ideen Wünsche Erwartungen Gefühle Prüfen Bits Maschine und Bytes Abbildung 1.1: Die Brücke mit den wichtigsten Klärungsschritten Ausgehend von den Ideen, Wünschen, Erwartungen und Gefühlen der betei- ligten Menschen geht es darum, festzustellen: ! Was - Was soll die Software leisten? Klärung des konkreten Auftrags. Was will der Auftraggeber? Was soll die fertige Computerlösung leisten? Wie wird der Auftraggeber prüfen, dass das Verlangte umgesetzt wurde? Ausgehend von den Ideen, Wünschen, Erwartungen und Gefühlen der beteiligten Menschen dienen die Schritte Geschäftsprozessanalyse, Anforderungsaufnahme und objektorientierte Analyse (OOA) dazu Klarheit und Verbindlichkeit herzustellen. Aus Wün- schen wird eine ausgehandelte, verbindliche Liste von Anforderungen. Der Schlussstein der Brücke ist erreicht. Es herrscht Klarheit über den Auf- trag. Das Softwareprojekt hat von nun an die Mission diesen Auftrag in funk- tionierende Bits und Bytes die auf den gewünschten Maschinen laufen umzu- setzen. Als nächstes muss geklärt werden: ! Wie - Wie soll das Verlangte umgesetzt werden? Mit den Analyse- und Design-Mitteln Strukturieren, Konzipieren und Mo- dellieren (siehe Kapitel 3) wird das Gesamtproblem in Einzelteile zerlegt und Schritt für Schritt der Problemlösung näher gebracht. Das Ergebnis ist eine vollständige Beschreibung der Problemlösung, die zur Umsetzung ge- eignet ist. In den Schritten objektorientierte Analyse und objektorientiertes Design wird die Umsetzung geplant und vorbereitet. Die Klärung des „Was“ und „Wie“ ist Voraussetzung für die Umsetzung: 14 © BITPlan, 2000 Wie? Was? Umsetzung ! Umsetzung Aus der Problemlösungsbeschreibung werden Computerprogramme und andere Lösungselemente hergeleitet. Die so entstehenden Lösungsteile werden zu einem Ganzen zusammengefügt. Der Schritt Implementierung leistet dies. Die erstellte Software sollte nun mit den Vorstellungen des Auftraggebers ü- bereinstimmen. Dies gilt es zu prüfen: ! Prüfen - Ist das Verlangte umgesetzt worden? Sicherstellen, dass die fertige Computerlösung dem entspricht, was die Software leisten soll. Innerhalb der (in der Abbildung nicht eingezeichne- ten) Schritte Abnahme, Test und Inbetriebnahme hat diese Prüfung zu er- folgen, damit sichergestellt ist, dass die an den Auftraggeber gelieferten Bits und Bytes, die von der Maschine ausgeführt werden, dem entspre- chen, was Auftraggeber wollte. Die einzelnen Schritte über die Brücke brauchen nicht strikt nacheinander zu erfolgen. Es ist möglich in Iterationen und Zyklen zu arbeiten, d.h. wie bei einer Springprozession einen Schritte rückwärts zu gehen, bevor der nächste Schritt gemacht wird oder das Team aufzuteilen, so dass einige schon ein paar Schritte weiter vorne sind und jeweils Ergebnisse über die Brücke durchge- reicht werden (siehe Abschnitt 4.2 „Kurze Entwicklungszyklen“). Abbildung 1.2 zeigt die Brücke mit Details für ein objektorientiertes Vorge- hen: Die "Brücke" vom Wunsch zur Software Analyse (OOA) Anforde- rungen Geschäfts- prozesse Projektmanagement Werkzeuge/Infrastruktur Prüfen Design (OOD) Implemen- tierung (OOI) Mensch Ideen Wünsche Erwartungen Gefühle Bits und Bytes Maschine © BITPlan, 2000 Abbildung 1.2: Die Brücke mit den Softwareprozessschritten für ein typisches objektorien- tiertes Vorgehen 15 Wie? Was? Umsetzung Von Menschen und Computern Die Themen Projektmanagement sowie Werkzeuge und Infrastruktur spielen im gesamten Verlauf des Softwareprojektes eine Rolle und sind daher unter- halb der Brücke als begleitende Aufgaben dargestellt. Bitte lesen Sie dazu Ka- pitel 6 „Infrastruktur und Werkzeuge“, insbesondere wenn Sie interessiert, wie das Projektverwaltungsprojekt mit diesen Themen umgegangen ist. Einstieg in ein neues Projekt Wie können Sie schnell den inhaltlichen Einstieg in ein neues Projekt finden? Eine Möglichkeit ist es mit den relevanten Beteiligten des Auftraggebers je- weils ein Erstinterview zu führen. Jeder Beteiligte wird dabei einzeln für sich nach folgenden Regeln befragt: ! Vorstellung Was ist die wahrgenommene betriebliche Rolle? Woran arbeitet der Betei- ligte in seinem „normalen“ Arbeitsleben ausserhalb der Anforderungsauf- nahme? Für die Vorstellung sind ca. 5 Minuten vorgesehen. ! Ausgangslage Was ist die subjektive Sicht der Ausgangslage? Wie ist er persönlich Be- betroffenen? Welche Fakten kennt er? Welche Kompetenzen hat er? Wel- che Gefühle entstehen beim Gedanken an das was ist und kommen soll? Bis zu. 30 Minuten. ! relevante Themen und Begriffe Nach der 7+/-2 Regel (siehe Abschnitt 3.4) werden die wichtigsten Din- ge/Begriffe/Themen genannt, die im Zusammenhang mit dem geplanten Projekt eine Rolle spielen. Bis zu 10 Minuten. ! Aktivitäten - Was soll mit den genannten Begriffen/Themen getan werden? - 3 bis 5 Zeilen zur Beschreibung je Aktivität - bis zu 45 Minuten. ! Erste Anforderungen und konkrete Beispiele dazu - Woran wird erkannt, dass die Aktivitäten „richtig“ laufen? Welche Anforderungen müssen er- füllt sein? - Zeitrahmen je nach Verfügbarkeit. Bis auf Punkt Vorstellung und Ausgangslage werden alle Ergebnisse vollstän- dig schriftlich erfasst. Zu Ausgangslage und Vorstellung werden nur die Punk- te erfasst, die der Interviewte explizit schriftlich festgehalten haben möchte. Fr. Probst führt zu Beginn des Projektes nacheinander zwei kurze Erstinter- views mit den Auftraggebervertretern Hr. Aufenberg und Hr. Exner. durch Sie erklärt jeweils kurz die Regeln des Interviews: Das Interview mit Hr. Exner verläuft so: 1. Vorstellung: Hr. Exner ist 54 Jahre - von der Ausbildung Hr. Industriekauf- mann und seit Beginn bei der Fa. Gründer. Dr., Gründer und Hr. Exner hatten schon im Vorgängerunternehmen zusammen gearbeitet. Vor drei Jahren sollte Hr. Exner Leiter des Supportbereiches werden, aber eine mehrmonatige Erkran- kung führte dazu, dass er die Gelegenheit nicht wahrnehmen konnte. Hr. Marx leitet diesen Berich jetzt. Hr. Exner bekam nach seiner Rückkehr die Leitung 16 eines grossen Bankprojektes übertragen bekam. Dieses Projekt wird in Kürze beendet sein. Wie es nach diesem Projekt weitergeht weiss Hr. Exner noch nicht. 2. Ausgangslage: Hr. Exner beschreibt wie das bestehende System vor 13 Jah- ren entstanden ist und seitdem tadellos läuft. Die Mitarbeiter, die damals daran gearbeitet haben sind inzwischen bis auf Hr. Exner alle nicht mehr im Unter- nehmen. In den letzten drei Jahren hat Hr. Exner das System neben seinem Bankprojekt immer wieder unter hohem persönlichen Einsatz betreut und dabei weder Überstunden noch das Opfern von Freizeit gescheut. Hr. Exner bittet Fr. Probst dies nicht schriftlich festzuhalten und Bitte auch nicht den Umstand, dass er überhaupt nicht nachvollziehen kann, warum das schöne existierende System nun unbedingt von Hr. Aufenberg weggeschmissen werden soll. Fr. Probst möge das nicht persönlich nehmen. 3. relevante Themen und Begriffe: Projekt, Mitarbeiter, Kunden, Zeiten, Verantwortlicher, Budget, Priorität, Pro- jektstatus 4. Aktivitäten: Projekt anlegen, Mitarbeiter erfassen, Kunden erfassen, Mitarbeiter Projekten zuordnen, Verantwortlichen festlegen, Zeiten erfassen, Restbudget ermitteln mit den entsprechenden Beschreibungen dazu. 5. Erste Anforderungen und Prüfbeispiele Hier nennt Hr. Exner, dass es unbedingt möglich sein muss, das Zeitbudget zu überziehen. Als Beispiel nennt er ein Projekt mit 3000 Personentagen, bei dem tatsächlich 6500 Personentage angefallen sind. Das Verfügbare Restbudget war dann zum Schluss natürlich -3500 Personentage - aber das sei schon o.k. so. Für weitere Anforderungen reicht die Zeit von 90 Minuten, die für das Inter- view bereit stand dann leider nicht mehr. In unserem Beispiel hat die Projektleiterin sich rechtzeitig darum gekümmert, die Weichen für den weiteren Projektverlauf zu stellen. Nach den beiden In- terviews vermutet Sie, dass Hr. Exner um seinen Arbeitsplatz fürchtet und sie erfährt von Hr. Aufenberg, dass einer der Hauptgründe für die Ablösung des Altsystems darin besteht die Abhängigkeit von Hr. Exner zu beseitigen, die zudem von Hr. Aufenberg als Innovationshürde empfunden wird. Die vorlie- gende Mischung von menschlichen und inhaltlichen Problemen ist typisch für Softwareprojekte. Die meisten Softwareprojekte haben schliesslich zum Ziel Veränderungen in der Arbeitsweise der Beteiligten herbeizuführen. Frau Probst weiss durch Ihre Interviews sehr früh, wo Schwierigkeiten auf der fach- lichen und menschlichen Seite auftauchen können. Durch die Fragen nach Begriffen, Aktivitäten und ersten Anforderungen hat sie sich rasch mit den wichtigsten Geschäftsobjekten und Anwendungsfällen vertraut machen können die ihr voraussichtlich im Rahmen der objektorientierten Analyse später be- gegnen werden ohne einen Begriff der Objektorientierung überhaupt in den Mund zu nehmen. Die "Brücke" vom Wunsch zur Software 17 Von Menschen und Computern 1.4 Welches Vorgehensmodell? Welches Vorgehensmodell ist für mein Softwareprojekt das Beste? Welche Kriterien kann ich zur Entscheidung dafür heranziehen? Zur Zeit streiten sich die Softwareexperten darüber, welche Vorgehensweise jeweils einer anderen überlegen ist. Folgende Punkte kristallisieren sich dabei heraus: ! Es gibt kein generell für alle Softwareprojekte gleichermassen geeignetes Vorgehensmodell ! Die richtige Balance zwischen den Extremen „chaotisches Vorgehen“ und „strikte Einhaltung eines vorgegebenen detaillierten Vorgehensmodells“ zu finden verspricht den größten Projekterfolg ! Auf der Suche nach neuen Vorgehensweise sind in den letzten Jahren viele neue Begriffe für Vorgehensweisen eingeführt worden: extreme Program- ming, Personal Software Process, Agile Software Development, Rational Unfied Process. Wichtig für die richtige Auswahl des Vorgehensmodells und der Elemente des Vorgehensmodells, die Sie einsetzen wollen ist es, den Zusammenhang zwi- schen den angewendeten Verfahren und Methoden und dem damit zu errei- chenden Projekterfolg zu kennen. Dafür leistet dieses Buch Hilfestellung. Praktisch alle hier genannten Erfolgsfaktoren finden Sie unter gleichem oder anderem Namen in den einschlägigen Vorgehensweisen wieder. Prüfen Sie für sich selbst die Relevanz jedes Faktors anhand der Erfahrungswerte, die aus der Umfrage zu diesem Buch gewonnen wurden. Beachten Sie vor allem, dass die Einhaltung eines Vorgehensmodells an sich keinen Wert hat. Es kommt darauf an, dass alle Beteiligten von diesem Vorgehen überzeugt sind und es aus die- ser Überzeugung heraus anwenden. Dazu gehört auch, dass die vorgegebenen Regeln bewusst gebrochen werden, dürfen, wenn es dem Projekt nützt1. Fr. Probst lädt zu Beginn des Projektes zu einer Anfangsbesprechung ein. Bei dieser Besprechung lernen sich alle Teammitglieder kennen und die Kernpunkte des Projektes werden besprochen. Hr. Aufenberg fragt, welches Vorgehensmo- dell angewendet werden wird. Fr. Probst erläutert, dass erst Aufgabe und Ziele geklärt werden und dann das Vorgehen. Sie bitte also die Teammitglieder bzgl. dieses Punktes noch um etwas Geduld. Im Grundsatz gehört die Frage der Klärung des Vorgehensmodells für ein Softwareprojekt an die dritte Stelle der Klärung von Aufgabe, Zielen und Vor- 1 Hewlett-Packard war Vorreiter auf diesem Gebiet, indem es in den Unternehmensgrundsät- zen festlegte, dass jeder Mitarbeiter Regeln bewusst brechen darf, wenn er davon über- zeugt ist, dass dies dem Unternehmen nützt. 18 Erfolgsfaktor: Einigen Sie sich auf ein für Ihr Projekt geeignetes Vorgehensmodell und wenden Sie dieses aus Überzeugung an. gehen. Das Vorgehensmodell sollte also erst ausgewählt werden, wenn Auf- gabe und Ziele des Projektes klar sind (siehe nächster Abschnitt 1.5 „Gemeinsames Erfolgsverständnis“). Bei der Auswahl des Vorgehensmodells hilft es sich die Grundsätze zu überlegen, die Sie an Ihr Vorgehen anlegen wollen. Wir vertreten zum Beispiel folgende Vorgehensgrundsätze, die sich in unseren Projekten bewährt haben: ! Modellgestützte Anwendungsentwicklung ! Hohe Wartbarkeit durch Nachverfolgbarkeit von der Anforderung bis zur Implementierung ! Frühzeitige Absicherung der Berücksichtigung der fachlichen Anforderun- gen schon in der Analysephase ! Iteratives Vorgehen in überschaubaren Zyklen ! Saubere Trennung zwischen Fachlichkeit und Technik 1.5 Gemeinsames Erfolgsverständnis Wie kann in einem Projekt zügig ein gemeinsames Erfolgsverständnis herbeigeführt werden? Das folgende schrittweise Vorgehen zur Klärung von Aufgabe, Ziele und Vorgehen hat sich für die Kooperation in Teams bewährt. Nacheinander wer- den dabei geklärt: ! Aufgabenverständnis Worum geht es? ! Ziele Was soll erreicht werden? Bis wann soll es erreicht werden? In welchem Umfang soll es erreicht werden? ! Vorgehen Auf welchem Wege sollen die Ziele erreicht werden? Welche Schritte sind erforderlich ? In welcher Reihenfolge sollen die Schritte bearbeitet werden? Wer macht was bis wann? Diese Zerlegung ist gleichermaßen für das Gesamtprojekt wie auch für Teil- aufgaben geeignet. In Verlaufe eines Projektes lohnt es sich also immer wie- der, Aufgabenverständnis, Ziele und Vorgehen auf den verschiedensten Detai- lierungsniveaus zu klären. Wichtig ist dabei, dass die Schritte konsequent nacheinander durchgeführt werden und unter den Beteiligten nach jedem Schritt eine Einigung herbeigeführt wird. Nach dem Schritt "Aufgabenver- ständnis" müssen also alle Teammitglieder bereit sein die Aussage "Ja - das ist unser gemeinsames Aufgabenverständnis!" zu unterschreiben. Erst dann geht Gemeinsames Erfolgsverständnis 19 Von Menschen und Computern es mit der Klärung der Ziele weiter - bis hin zum dem Punkt "Ja - das sind un- sere gemeinsamen Ziele!". Erst zum Schluß wird dann das Vorgehen abge- stimmt bis auch darin Einigkeit erzielt wird. Die Trennung in diese drei Schritte bringt den großen Vorteil mit sich, dass die Bandbreite der zu untersuchenden Möglichkeiten viel kleiner ist. Es müs- sen nur noch die Ziele betrachtet werden, die zum Aufgabenverständnis pas- sen und später nur die Vorgehensweisen diskutiert werden, die zu den Zielen führen, auf die sich das Team geeinigt hat. Zusatzaufwand, der durch Missver- ständnisse entsteht und langwierige Diskussionen aufgrund von falschen An- nahmen lassen sich so vermeiden. Fr. Probst bitte alle Teammitglieder, ihr Aufgabenverständnis in einem Satz auf einer Metaplankarte zu formulieren und die Karten werden dann an eine Pin- wand geheftet. Die Karten lauten: Hr. Anglet: „Gründer möchte ein webbasiertes Projektplanungssystem haben“ Hr. Aufenberg: „PVW wird so abgelöst, dass die Projektdaten direkt in die Un- ternehmensquartalsberichte einfliessen können“. Hr. Teschner: „Hr. Aufenberg möchtel ein Zeiterfassungsystem für die Mitar- beiter der Softwareprojekte“ Hr. Exner „PVW soll um eine Internetkomponente ergänzt werden“ Fr.. Probst: „Auf Basis der Funktionalität von PVW soll ein neues System ent- stehen, das Webfähig ist und mit dem System zum Erstellen der Quartalsberich- te zusammenarbeitet“. Fr. Entrop: „Gründer hat Interesse die Vorgehensweise von PV-Soft näher ken- nenzulernen und daher die Projektverfolgung als Pilotprojekt ausgewählt“ Gemeinsames Verständnis der Projektziele erreichen Wie häufig sind Ihnen schon Projekte begegnet, bei denen die Beteiligten un- terschiedliche Ziele verfolgt haben? Die wichtigste Voraussetzung für den Erfolg eines Softwareprojektes ist, dass die Beteiligten von Beginn an Klarheit und Einigkeit darüber haben was sie als Projekterfolg ansehen. Ein Microsoftteam, das eine neue Word für Windows Version erstellt hat mit Sicherheit ein anderes Erfolgsverständnis als ein Team der European Space Agency, das Software für die nächste Ariane-Mission er- stellt. Bei Microsoft wird viel Wert darauf gelegt, dass die Software schnell fertig wird und ausgeliefert werden kann. Ein Betatest mit einigen tausend Annwender dient dazu, die wichtigsten Fehler noch vor der Auslieferung zu beheben. Der Rest der Fehler wird später oder gar nicht beseitigt. Ausfälle der Software dürfen bei Microsoft vorkommen, solange nur wenige Anwender 20 Erfolgsfaktor: Klären Sie zu Beginn des Projektes und bei Bedarf im weiteren Verlauf Aufgabenverständnis, Ziele und Vorgehen. betroffen sind. Das Arianeteam hat im Fokus eine Software zu erstellen, die auf Anhieb die für die Weltraummission entscheidenen Funktionen zuverläs- sig bereitstellt. Die Software darf an entscheidenden Stellen überhaupt nicht ausfallen. In unserem Beispielprojekt haben die wenigen Beteiligten bereits relativ un- terschiedliche Vorstellungen davon, was die Aufgabe des Projektes ist. Die Erfolgschancen eines Softwareprojektes sinken dramatisch, wenn unter den Beteiligten unterschiedliche Vorstellungen konkurrieren, was als Erfolg des Projektes anzusehen ist. Die Erfolgskriterien bestimmen schliesslich die Ziele des Projektes. Klassische Konkurrenten für Projektziele sind z.B.: ! Termin versus Kosten versus Qualität $ Der Auftraggeber möchte das Ergebnis möglichst schnell (Termin) $ Der Auftragnehmer möchte ein möglichst hohen Gewinn erzielen (Kosten) $ Der Endanwender möchte, dass die Software seine Bedürfnisse erfüllt (Qualität) ! Auftrag versus Produkt $ Der Auftraggeber möchte gerne eine kundenspezifische Lösung $ Der Auftragnehmer möchte die Lösung als Produkt vermarkten ! Form versus Funktion $ Die Software soll hübsch aussehen und angenehm in der Handhabung sein (Form) $ Die Software soll die geforderten Funktionen in allen Details realisieren Je besser es den Beteiligten gelingt, so früh wie möglich einen Interessenaus- gleich bzgl. konkurrierender Zielvorstellungen zu erreichen, um so zufrieden- stellender wird das Ergebnis werden. Nach einiger Diskussion einigen sich die Teammitglieder auf folgende Aufga- benformulierung: “Auf Basis der Funktionalität des bestehenden Projektverfolgungsystems PVW soll für Gründer Software AG eine neu zu erstellende Lösung entstehen, die webbasiert die Erfassung von Projekten und der von den Mitarbeitern dafür ge- leisteten Zeiten ermöglicht damit daraus für die Quartalsberichte die Aus- lastungs- und Budgetsituation sowie der Status der Projekte abgeleitet werden kann.“ Erst nachdem alle Beteiligten zugestimmt haben, dass dies das gemeinsame Aufgabenerständnis der Beteiligten ist, werden Ziele und Vorgehen geklärt. Im Verlauf der Diskussion um die Aufgabe werden die Ideen zu Zielen und Vorgehen bereits gesammelt. Die Einigung darüber findet jedoch erst danach statt. Die Liste der Stichpunkte aus der Aufgabendiskussion umfasst: “automatische Erfassung am Arbeitsplatz-PC, Java, maximal 3 Monate Projekt- dauer, Enterprise Java Beans, JUnit, extremeProgramming, DB2-Datenbank Gemeinsames Erfolgsverständnis 21 Von Menschen und Computern muss bleiben, Hr. Exner ist nur 1 Tag die Woche verfügbar, ....“ Auf folgende Ziele einigen sich die Anwesenden noch im Laufe der Sitzung: - maximal 5 Monate Projektdauer, eine Projektdauer von 4 Monaten wird ange- strebt. - es soll das „moderne“ Entwicklungsvorgehen von PV-Soft ausprobiert wer- den- dabei soll das möglichst frühe Testen der Einhaltung der Wünsche des Auftraggebers eine grosse Rolle spielen- zwischen der Nennung eines Wun- sches, der Implementierung und dem Test soll nicht mehr als drei Wochen Zeit vergehen. Dies bedeutet, dass die Wünsche schrittweise aufgenommen werden. - es soll mit Java auf Basis einfacher Applets entwickelt werden - die Anwen- dung soll sowohl mit Netscape ab Version 4 als auch mit Internet-Explorer ab Version 5 laufen. - die DB2-Anbindung entfällt zugunsten einer einfachen XML-Datenhaltung - die Reaktionszeit beim Start der Anwendung darf sich dafür auf bis zu 10 Se- kunden verschlechtern, bei Abfragen auf bis zu 3 Sekunden. - Hr. Exner steht jeweils Montags den ganzen Tag für das Projekt zur Verfü- gung Bei der Festlegung von Zielen kommt es darauf an, dass diese in nachprüfba- rer Weise festgelegt werden. Sowohl der Inhalt muss klar bestimmt sein, als auch die Werte für die Kriterien anhand derer geprüft werden kann wie gut das jeweilige Ziel später erreicht wird. Abgestimmtes Vorgehen Wann ist der richtige Zeitpunkt das Vorgehen festzulegen? Welche Freiheits- grade bestehen begzüglich der Einhaltung des Vorgehens? Wer bestimmt, wie vorgegangen wird? Es ist nicht sinnvoll einem Softwareprojekt ein Vorgehen von aussen aufzu- zwingen. Die Beteiligten müssen selbst vom Vorgehen überzeugt sein. Der beste Weg dazu, ist das Vorgehen gemeinsam im Team abzustimmen, nach- dem Aufgabe und Ziel des Projektes klar sind. Erst dann kann festgestellt werden, was ein angemessenes Vorgehen im Verhältnis zu dieser konkreten Aufgabe und den konkret zu erreichenden Zielen ist. Zunächst sollten die Be- teiligten eine Vorstellung entwickeln, wie das Vorgehen aussehen wird. Dabei muss noch nicht jedes Detail klar sein, lediglich die Linie muss soweit stim- men, dass deutlich zu erkennen ist, dass alle Probleme und Hindernisse die aus der Startsituation heraus bereits erkennbar sind auf dem vorgeschlagenen Weg ausgeräumt oder umgegangen werden können. Im Verlaufe des Projektes wer- den sich je nach Typ des Projektes Aufgabe, Ziele und Vorgehen unterschied- lich stark ändern. Versuchen Sie sich vorzustellen, wie gross die auf Sie zu- 22 Erfolgsfaktor: Definieren Sie die Projektziele klar anhand von messbaren Krite- rien und festgelegten Werten. kommenden Änderungen sein werden. Jetzt ist der Zeitpunkt das Vorgehen abzustimmen, damit für die ersten Schritte klar ist, wer wann was wie macht. Am nächsten Montag trifft sich das Projektteam bei PV-Soft. Frau Probst zeigt anhand eines Projektes, dass PV-Soft vor einigen Monaten bei einem anderen Unternehmen erfolgreich abgewickelt hat das bei PV-Soft erprobte Vorgehen auf. Sie erläutert, dass der Kern des Vorgehens darin besteht, die Wünsche sys- tematisch so zu erfassen, dass alle Beteiligten jeweils Einblick haben. Die Wün- sche werden dann priorisiert und dort wo entschieden wird, dass die Umsetzung erfolgen soll müssen Prüfbeispiele gesammelt werden. Meistens werden diese jedoch schon bei der Nennung des Wunsches erfasst, um bessere Klarheit über den Wunsch zu bekommen. Frau Probst nennt ein Beispiel aus dem Vorprojekt, wo es um eine Bankanwendung ging: Wunsch: Es sollen die fälligen Zinsen berechnet werden. Dafür ist tagesgenaue Zinsrechnung anzuwenden. Die Zinsformel lautet also: Zinsen=Restschuld * Zinssatz/100*Zinstage/Anzahl Tage im Jahr. Die Genauigkeit der Berechnung beträgt 5 Nachkommastellen. Ausgangssituation des Prüfbeispiels: Die Restschuld eines Darlehens beträgt 10.000 Währungseinheiten. Der Zinssatz beträgt 6% per anno. Das Dar- lehen ist für 200 Tage im Jahr 2002 zu verzinsen. Im Beispiel soll als Aktion die Zinsrechnung erfolgen. In diesem Prüfbeispiel wird erwartet, dass die Zinsen als 328,76712 Währungs- einheiten berechnet werden. Die Textbeschreibungen der Anforderungen und Prüfbeispiele werden in einer webbasierten Datenbank gehalten. Aus den Textbeschreibungen lassen sich Rahmen für JUnit-Tests generieren. Während aus den Anforderungen ein Mo- dell abgeleitet wird und daraus Java-Code entsteht wird parallel dazu oder oft auch schon vorher pro Prüfbeispiel ein Testprogramm erstellt. Frau Probst er- läutert die Zusammenhänge anhand der Abbildung 1.3. Gemeinsames Erfolgsverständnis ARnefqouridremruenngtesn gmeparsüuftreddurbcyh AccePprütafbneciespCierilteria dabegpelneditsetoanus adbegpelneditsetoanus UML Model TestbSepsecchirfeiciabtuionng Gen gmeparsüuftreddurbcyh Gen Gen Gen adbegpelneditsetoanus dabegpelneditsetoanus ImpPleromgeranmtamtion gmeparsüuftreddurbcyh TestpCrogdreamm Abbildung 1.3: Das von PV-Soft verwendete Vorgehensmodell Die Rückfragen, die im Rahmen dieses Vorgehens entstehend werden – soweit sie einigermassen spannend sind – dokumentiert. Dies ist insbesondere nützlich, 23 Von Menschen und Computern wenig nicht gleich eine Antwort erhältlich ist und zunächst mit einer Annahme darüber, wie die Antwort ausfallen wird, weitergearbeitet werden muss. Bis auf Hr. Exner und Hr. Teschner kennen alle Teammitglieder dieses Vorgehen be- reits und sind davon begeistert. Fr. Entrop berichtet, wie skeptisch sie selbst am Anfang des letzten Projektes war und wie sie nun selbst Feuer und Flamme da- für ist. „Es war einfach toll, wie gut alle Beteiligten auf dem Laufenden waren. Man konnte ruhig mal eine Woche in Urlaub sein - nach der Rückkehr reichte es sich im System Einblick über die neuen Themen zu verschaffen und dann die einzenen Autoren jeweils anzusprechen, bei der näcshten Teamsitzung war man dann ohne grosse Rückfragen wieder voll im Boot!“ Hr. Exner fragt, wie teuer denn das Projekt bei all dem Aufwand geworden ist. Das müsste doch mindestens dreimal soviel Aufwand gewesen sein wie sonst. Fr. Probst beruhigt ihn und erläutert, dass es tatsächlich in den ersten Projekten mit diesem Verfahren Probleme gegeben hat, den Aufwand im Griff zu halten. Damals wurde von Anfang an zu jeder Anforderung sofort sehr viele Prüfbei- spiele aufgenommen. Inzwischen haben die Teammitglieder ein Gefühl dafür entwickelt, zwischen „Wunsch“ und „Anforderung“ zu unterscheiden. Zum Schluss der Sitzung einigen sich alle darauf, dass Vorgehen anzuwenden. Hr. Exner erklärt jedoch, dass er gerne nach einem Monat auf Basis der bis da- hin vorliegenden Erfahrungen noch einmal mit Hr. Aufenberg sprechen möchte, ob dieser an diesem Verfahren festhalten will. 1.6 Die Sprache des Auftraggebers sprechen Wie können Sie sicherstellen, dass Sie als Auftragnehmer Ihren Auftraggeber verstanden haben? Woher wollen Sie wissen was die Spezialbegriffe und Aus- drucksweisen bedeuten, die Sie im Rahmen des Projektes zum ersten Mal kennenlernen? Wenn Ihnen klar wird, wie wichtig es ist Missverständnisse, die bereits in den sprachlichen Unterschieden zwischen Auftraggeber und Auftragnehmer liegen zu vermeiden, dann ist der erste Schritt getan. Sie werden sich bemühen, die Sprache des Auftraggebers zu sprechen. Seien Sie sich bewusst, dass Ihr Auftraggeber Begriffe möglicherweise anders benutzt, als Sie selbst es gewohnt sind. Auch wenn der Auftraggeber es zu- nächst möglicherweise als lästig empfinden wird: Fragen Sie nach! Sammeln Sie die Bedeutung von unklaren Begriffen am Besten in einem systematischen Glossar, dass für alle Projektbeteiligten zugreifbar ist. Bereits nach den ersten Interviews hat Fr. Probst begonnen ein Glossar aufzu- stellen. Sie hat die Begriffe aus den Interviews in das Glossar eingetragen und zunächst Ihr eigenes Verständnis der Begriffe eingetragen: Begriff Bedeutung Erfolgsfaktor: Sprechen Sie als Auftragnehmer die Sprache Ihres Auftraggebers! 24 Wie wird der Auftraggeber glücklich? Begriff Projekt Mitarbeiter Kunde Zeiten Verantwortlicher Priorität Projektstatus Bedeutung Mit Ziel, Zeit- und Geldbudget, Mitarbeitern und Verantworli- chem ausgestattete benannte Aktivitätenfolge. Potentieller Projektbeteiligter / Angestellter der Gründer AG Auftraggeber eines Projektes, derjenige der durch das Projekt einen Nutzen erzielen soll Arbeitszeit der Mitarbeiter die dem Projekt zugute kommt bzw. dem Projekt als Kosten zugerechnet wird. Pro Projekt übernimmt ein Mitarbeiter die Verantwortung für das Projekt. Er zum einen Ansprechpartner für Kunden und Ge- schäftsführung, zum anderen für die Mitarbeiter des Projektes. Die Priorität eines Projektes wird nach Dringlichkeit (dringend, weniger dringend, nicht dringend) und Wichtigkeit (wichtig, weni- ger wichtig, nicht wichtig) bemessen. Bearbeitungszustand des Projektes: Ein Projekt kann in Vorbe- reitung, aktiv oder beendet sein. Beispieldokument 1.1: Entwurf des Glossars für das Projektverwaltungsprojekt Das Projektteam wird das Glossar im Rahmen des Projekts ergänzen und Pfle- gen, insbesondere in Situationen in denen deutlich wird, dass es Verständnis- unterschiede für Begriffe gibt. 1.7 Wie wird der Auftraggeber glücklich? Wie glücklich macht Softwarequalität Ihren Auftraggeber? 1994 schrieb Martin Rösch einen Artikel mit der Überschrift „ISO9000: Qua- lität oder Zertifikat“ [Roe94b]. Ihm ging es darum den Unterschied zwischen ISO-9000 Zertifizierung und wirklicher Qualität in der Softwareentwicklung aufzuzeigen. Qualität ist die Übereinstimmung zwischen dem was Ihnen gelie- fert wurde mit dem was Ihnen versprochen wurde. Zufriedenheit ist die Über- einstimmung zwischen dem was Sie erhalten haben und dem was Sie sich ge- wünscht haben. Das ist häufig genug ein Unterschied – denn nicht immer wird Ihnen das versprochen, was Sie eigentlich haben wollen. Die folgende Version der Brücke veranschaulicht den Unterschied: 25 Von Menschen und Computern gesagt Mensch Maschine gewünscht geliefert © BITPlan,2000 Abbildung 1.4 Woran macht der Auftraggeber seine Zufriedenheit mit der Software fest? Im linken Teil der Brücke spielt der Auftraggeber die Hauptrolle. Seine Aus- sagen führen zu einem möglichst gut abgestimmten Bild, was die Software leisten soll. Nur die schriftlich hinterlegten oder unter Zeugen gemachten Aus- sagen sind ab jetzt rechtsverbindliche Grundlage der Umsetzung. Sollte es zu einem Streit vor Gericht kommen, spielt lediglich die Übereinstimmung zwi- schen Lieferung und dieser „gesagt“ vorliegenden Spezifikation eine Rolle. Die Qualitätsdefinition nach ISO 9000 geht von dem gleichen Prinzip aus. Ihre Organisation soll systematisch und nachprüfbar in der Lage sein die Überein- stimmung zwischen „geliefert“ und „gesagt“ herzustellen. Was nutzt es Ihnen aber, wenn Sie als Softwarelieferant zwar Gerichtsprozesse gewinnen können und ein ISO-9000 Zertifikat regelmässig bestätigt bekommen, Ihr Kunde aber nicht das geliefert bekommt, was er sich gewünscht hat? Im linken Teil der Brücke spielt die Musik. Software nach Pflichtenheft ablie- fern können heute viele Unternehmen auf der ganzen Welt. Der Konkurrenz- druck durch Billiganbieter aus fernen Ländern, die über Internet prinzipiell spielend leicht mit potentiellen Auftraggebern kommunizieren können wird immer größer. Die Chancen liegen im Verbesserungspotential das in der Ü- bereinstimmung von „gesagt“ und „gewünscht“ liegt. Denn wenn das Gesagte schon mit dem Gewünschten nicht übereinstimmt oder wenn die Wünsche gar nicht geäußert wurden (z.b. mangels Gelegenheit – niemand hat gefragt) - dann ist sicher, dass auch das Gelieferte nicht mit dem Gewünschten überein- stimmt. 26 Wie sicher kann ich sein, dass die Software richtig ist? Seien Sie sich bewusst, dass sie auf die Wünsche Ihres Auftraggebers Einfluss nehmen! Gerade wenn Sie sich gegenüber Mitbewerbern durchsetzen müssen, um ein Softwareprojekt für einen Auftraggeber durchführen zu können ist die Versuchung gross, Erwartungen zu wecken. Indem Sie Termine, Preise oder Inhalt versprechen beeinflussen Sie das gesamte Spektrum der Wünsche Ihres Auftraggebers. Der Zauberlehrling von Goethe „Die ich rief, die Geister .....werd' ich nun nicht los." mag es Ihnen oder Ihrem Team anschliessend durch den Kopf gehen. Tipps zu diesem Thema finden Sie im Abschnitt „Erwartungsmanagement und Verbindlichkeit“. 1.8 Wie sicher kann ich sein, dass die Software richtig ist? Wie können Sie feststellen, dass Ihre Softwarelieferung mit dem Software- wunsch Ihres Auftraggebers übereinstimmt? Im%Kapitel 2 Was soll die Software leisten? werden Sie einige hoffnungsvolle Antworten auf diese Frage finden. An dieser Stelle möchten wir jedoch eine kurze warnende Betrachtung einschieben. In den folgenden Kapiteln werden wir argumentieren, dass es möglich ist mit Computerunterstützung zu prüfen, ob die Wünsche des Auf- traggebers erfüllt worden sind. Zumindestens die Projektleiterin aus unserem Beispiel, Frau Probst wird in diese Richtung agieren und damit passable Er- folge erringen. Grundlage dafür ist, dass wir nicht nur eine Software erstellen, die das umsetzt, was der Auftraggeber sich gewünscht hat. Entscheiden ist, dass wir auch Testsoftware erstellen, die Prüfbeispiel für Prüfbeispiel ermit- telt, ob die Vorstellungen des Auftraggebers eingehalten wurden. Es gibt je- doch eine wichtige Grenze für diesen Ansatz. Diese Grenze liegt in der Wahr- nehmung der Ergebnisse, die ein Computer liefert. Die Menschen, die später Nutzer unserer Software sind haben eine ggf. völlig andere Wahrnehmung der Ergebnisse, die unsere Software liefert, als unsere Prüf- und Testprogramme. Nehmen wir als klassisches Beispiel das Programm „Hello World!“. Eine Ja- va-Version dieses Programm lautet: } } Ein Testprogramm dazu würde nun prüfen, dass tatsächlich die Zeichenfolge „Hello World!“ ausgegeben wird. Die Wahrnehmung eines Computers von Hello World! ist jedoch nur ein Bitmuster. Das Testprogramm testet die Zei- chenkette in dieser Form. Zur Anzeige kommt die Zeichenkette dann jedoch ganz anders. Es kommt stark darauf an, auf welchem Computer und auf wel- chem Art die Anzeige erfolgt. Hier zwei Beispiele: public class Hello { public static void main(String args[]) { System.out.println(“Hello World!”); 27 Von Menschen und Computern Abbildung 1.5: Ausschnitt aus der Anzeige von „Hello World!” auf einem PC Abbildung 1.6: „Hello World!” auf einem Palm Taschencomputer Auch wenn inhaltlich „Hello World!“ gleich „Hello World!“ ist, macht die Dar- stellung des Ergebnisses einen grossen Unterschied aus. Die Bandbreite ist dabei enorm. „Hello World!“ kann von einem Computer vorgelesen werden, als E-Mail verschickt, im Internet angezeigt oder als haushohe Reklame am New Yorker Time Square angezeigt werden. Die zugrunde liegende Digital- darstellung als Bitmuster ist jeweils eine völlig Andere. Dieser letzte Teil der Übereinstimmung von „geliefert“ und „gewünscht“ spielt in der heutigen mul- timedialen Computerwelt eine immer größere Rolle. Wir menschen nehmen nicht die Bits des Computers wahr sondern nur das was unsere Sinnesorgane schliesslich als Umsetzung der Bits in wahrnehmbare Signale geboten be- kommen. 28 1.9 Literatur Literatur [Bal96] [Bun02] [Con01] [DeM97] [DeM98] H. Balzert: Lehrbuch der Software-Technik, Spektrum Akademi- scher Verlag, 1996 Lehrbuch mit umfangreicher Abhandlung aller Themen der Soft- wareentwicklung. C. Bunse, A. v. Knethen: Vorgehensmodelle kompakt, Spektrum Akademischer Verlag, 2002 Eine kurze und bündige Übersicht zu den verschiedenen Vorge- hensmodellen, die bis heute für Softwarprojekte entwickelt worden sind. L. L. Constantine: The Peopleware Papers, Prentice-Hall, 2001 Eine über Jahre gewachsene Sammlung von Aufsätzen über Men- schen in Softwareprojekten. T. DeMarco: Warum ist Software so teuer?, Hanser, 1997 Warum ist Software eigentlich so teuer? Jerry Weinberg’s Antwort „Im Vergleich zu was?“ ist die Basis für die Thesen dieses Buches. T. DeMarco: Der Termin, Hanser, 1998 Ein Roman: Ein Softwareprojektleiter wird entführt und findet sich in einer idealen Experimentierumgebung für Projekte wieder: es gibt reichlich Leute und Wissen. Die Zeit ist trotzdem knapp ... [DeM99] T. DeMarco, T. Lister: Wien wartet auf dich, Hanser, 1999 Der Originaltitel „Peopleware“ bringt den Inhalt dieses Buches auf den Punkt - sehr empfehlenswert! [DeM01] T. DeMarco: Spielräume, Hanser, 1999 DeMarco räumt mit dem Mythos auf, dass Erhöhung von Druck und das Entfernen von „Überflüssigem“ Projekte und Unterneh- men erfolgreicher macht. [HUM95] W. S. Humphrey: A Discipline for Software Engineering, Addi- son-Wesley, 1995 Detaillierte Beschreibung eines systematischen und disziplinierten Ansatzes zur Softwareentwicklung, die sich an den einzelnen Soft- wareentwickler wendet. Durch beobachten der eigenen Fehlerquel- len werden diese systematisch ausgemerzt. [Kru01] P. Kruchten: Der Rational Unified Process - Eine Einführung, Addison-Wesley, 2001 Eine Sammlung von Best Practices für Softwareprojekte, die von Rational unter dem Namen Rational Unified Process vermarktet wird. 29 Von Menschen und Computern [Spre96] [Thu81] [Thu89] R. K. Sprenger: Mythos Motivation - Wege aus einer Sackgasse, Campus, 1996 Laut Sprenger gilt „Alles Motivieren ist Demotivieren“. Die Moti- viation des Menschen liegt in ihm selbst. Sie kann geweckt, aber nicht erzwungen werden. F. Schulz von Thun: Miteinander Reden 1 - Störungen und Klä- rungen, Rowohlt, 1981 Grundprinzipien der Kommunikation von einem Psychologen für Laien verständlich erklärt. F. Schulz von Thun: Miteinander Reden 2 - Stile, Werte und Persönlichkeitsentwicklung, Rowohlt, 1989 Auch ohne [Thu81] zu lesen äußerst aufschlußreich. Die wichtigs- ten Themen sind: ausgehaltene Balance zwischen extremen Aus- prägungen von Werten innerhalb eines erträglichen Toleranzberei- ches, z.B. Geiz -Verschwendung mit dem Toleranzbereich Spar- samkeit - Großzügigkeit und die Erklärung von acht typischen Kommunikationsstilen, wie z.B. dem „Sich beweisen“. http://www.systemsguild.com/GuildSite/TDM/June2002Computer. pdf Erfrischende Debatte zwischen Barry Boehm und Tom DeMarco über die Einführung von agilen Methoden. [Url1] [Url2] http://epic.onion.it/workshops/w10/slides02/index.htm:Pro-active Quality or Re-active Quality? - Workshop on ISO 9000 03/11/98 Zurück zur ursprünglichen Bedeutung von Qualität - „Kundenzu- friedenheit“. 30 „Nie aber weiß man genau, was man denkt, bevor man nicht versucht hat, darüber zu sprechen.“ Kurt Marti 2 Der Abstimmungs- und Einigungsprozeß was die Software leisten soll ist das für die Softwareentwicklung wichtiger als es scheint. Die Zufriedenheit der Auftraggeber hängt direkt davon ab, wie gut es gelingt ausgehend von den Wünschen zu einem schlüssigen Anforderungsprofil zu gelangen. 2.1 Projektauswahl Wo soll als nächstes Zeit- und Geld in die Softwareentwicklung investiert werden? Die Analyse der Geschäftsprozesse eines Unternehmen leistet für ein Soft- wareprojekt doppelte Vorarbeit: ! Die Geschäftsprozessanalyse stellt die Entscheidungsgrundlagen für die Auswahl des richtigen Softwareprojektes bereit, indem sie aufdeckt wo Geschäftsprozesse verändert und verbessert werden können. ! Die Geschäftsprozessanalyse liefert wichtige Grundlagen für die Rahmen- anforderungen des Softwareprojektes - es werden bereits die Geschäftspro- zesse, Geschäftsobjekte und die beteiligten Rollen festgestellt. Zudem werden bereits die Entscheidungen bestimmt, die den Ablauf der Ge- schäftsprozesse steuern. Motivation für den Vorstand der Gründer AG, Hr. Aufenberg ein neues Pro- jektverfolgungssystem entwickeln zu lassen ist die seit einem Jahr wirksame Rechtsform des Unternehmens „Aktiengesellschaft“. Zu den Pflichten einer AG gehört die regelmässige Veröffentlichung von Berichten. Die Projeksituation geht in die Quartalsberichte direkt ein. Dieser Geschäftsprozess wird von dem Projektauswahl 2 Was soll die Software leisten? 31 Was soll die Software leisten? alten System, das noch zu GmbH-Zeiten entstanden ist nicht ausreichend unter- stützt. Zudem dauert der Weg von der Zeiterfassung auf Papier über die Erfas- sung im System bis zur Auswertung zu lange - die Ergebnisse liegen oft erst nach 6-8 Wochen vor. Von einer Änderung des Prozesses auf Direkteingabe durch die Mitarbeiter erhofft sich Hr. Aufenberg und sein Aufsichtsrat die Mög- lichkeit tagesaktueller Berichte. In zweierlei Hinsicht ist unser Beispielprojekt typish: ! Die Geschäftsprozessanalyse ist vor der Auftragsvergabe für die Software bereits erfolgt ! Eine formale Analyse, zudem unter Einsatz von Beratern und Werkzeugen, hat es gar nicht gegeben. Eine kurze Betrachtung der geschäftlichen Abläu- fe im Kreis der Betroffenen bringt bereits den Kern des zu lösenden Prob- lems zu Tage. In grossen Unternehmen mit vielen untereinander abhängigen Geschäftspro- zessen ist die Analyse der Situation wesentlich aufwendiger und die Ableitung von Softwareprojekten eine eigenständige Aufgabe. Es gilt dann Software- komponenten und Geschäftsprozesse aufeinander abzustimmen. 2.2 Anforderungen aufnehmen Anforderungen dokumentieren die Forderungen an die gewünschte Software- lösung - klar verständlich in einfacher Sprache für Fachleute und Anwender ohne Computer-Fachchinesisch. Würden Sie ein Haus kaufen oder bauen lassen, dessen Größe, Raumauftei- lung, und verwendete Materialien erst nach Beginn der Bauarbeiten festgelegt würden? Wie oft würden Sie akzeptieren, dass die Bauarbeiter Entscheidungen für Sie fällen? Wie weit entspräche das fertige Haus später Ihren Bedürfnis- sen? Für Softwareprojekte wird heute oftmals genau das absurde Vorgehen akzep- tiert, dass die obigen Fragen nahelegen. Software hat scheinbar die Eigen- schaft, dass sie jederzeit geändert werden kann, wenn etwas nicht so ist, wie es sein soll. Das ist nur scheinbar so, denn jeder Änderung hat Kosten und Auf- wände zur Folge und da Geld und Zeit beschränkt sind werden immer nur die wichtigsten Änderungen durchgeführt werden. Im Hausbau hat sich bewährt, dass die Fragen nach Größe, Raumaufteilung und Verwendung von Materia- lien für den Rohbau am Anfang geklärt werden. Detailfragen nach Steckdosen, Fliesen, Tapeten usw. werden später geklärt und anfangs nur grob geschätzt. Was ist bei Softtware der richtige Zeitpunkt für eine in Auftrag gegebene Software präzis festzulegen, was sie leistet? Die Angaben dazu müssen recht- zeitig vorliegen. Die Rahmenanforderungen sind bereits für die Planungsphase erforderlich, im Verlaufe des Projektes muss sichergestellt sein, dass die An- 32 forderungen rechtzeitig vorliegen. Eine Weg dies zu erreichen ist die enge Einbindung der Auftraggeber in das Projekt. Wer als Auftraggeber rechtzeitig klar sagt, was er will, legt damit das zentrale Fundament des Projekterfolges. Nur auf Basis dieser Aussagen können Auf- wände, Kosten und Termine abgeleitet werden und der Auftraggeber kann dann entscheiden, welche seiner Wünsche er tatsächlich zu den genannten Be- dingungen realisiert haben möchte. Anforderungen aufnehmen Erfolgsfaktor: Nur wer rechtzeitig sagt, was er will, kann sicher gehen, dass er es auch bekommt. Abbildung 2.1: Was haben die Auftraggeber des Eiffelturms über den fertigen Turm in diesem Moment der Bauphase gewusst? Auftraggeber und Auftragnehmer müssen daher gemeinsam die Liste der An- forderungen klären. Jede Anforderung beschreibt für einen überschaubaren Teil des Systems das geforderte Verhalten. Die größte Klarheit wird erreicht, wenn alle Anforderungen schriftlich vorliegen und es zu jeder Anforderung mindestens ein Prüfbeispiel gibt. Wenn die Auftraggeber dann sagen: "Ja, das ist das, was wir haben wollen" bedeutet dies für die Auftragnehmer: "Wir wissen, was wir liefern sollen. Ich 33 Was soll die Software leisten? weiss, womit mein Kunde zufrieden sein wird. Ich weiss, mit welchen Inhalten das Projekt ein Erfolg wird." Das Anforderungsprofil gibt in der Sprache des Auftraggebers wieder was die Software leisten soll. Damit ist der erste Schritt in Richtung auf die Realisier- barkeit mit dem Computer getan. Aus den zu Beginn unbekannten und viel- leicht auch unklaren und widersprüchlichen Gedanken, Wünschen und Ideen der Auftraggeber ist nachlesbarer Text geworden. Vollständigkeit von Anforderungen Wie können Auftraggeber und Auftragnehmer feststellen, ob eine vorliegende Liste der Anforderungen vollständig ist? Die Problemkreise bei der Frage nach der Vollständigkeit von Anforderungen sind: ! Durch die Erklärung der Vollständigkeit erfolgt die Übernahme der Ver- antwortung durch den Auftraggeber ! Bei einer großen Menge von Anforderungen ist die Übersicht über das An- forderungsprofil nötig%Abschnitt „Gliederung von Anforderungen“. ! Die Verantwortlichen brauchen Klarheit über die Folgen des Anforde- rungsprofilinhaltes (z.B. für Kosten/Termine/Erfolgschancen der zu erstel- lenden Lösung). ! Übersicht über das Anforderungsprofil Zur Gewinnung der Übersicht über das Anforderungsprofil muß zunächst einmal der Inhalt des Profils festgelegt werden%Abschnitt 2.4 Anforderungsprofil erstellen. Das Anforderungsprofil stellt den vollständi- gen Satz von Anforderungen dar, den ein zu erstellendes Informationssys- tem zu erfüllen hat. Auftraggeber haben häufig Angst, dass sie im Anforderungsprofil etwas ver- gessen haben. Denn aus der Erfahrung der Vergangenheit wissen sie, dass spät abgelieferte Anforderungen teuer werden, zu Projektverzögerungen führen oder im schlimmsten Fall gar nicht mehr umgesetzt werden können (Abschnitt 2.5 „Änderungen der Anforderungen“). Schliesslich ist die vollständige Berücksichtigung aller Quellen für Anforderungen zu prüfen: ! Alle Kundendokumente berücksichtigt? ! Alle Verantwortliche beteiligt? ! Alle Partnersysteme beteiligt? ! Sonstige vom Kunden benannte Quellen berücksichtigt? 34 Gliederung von Anforderungen Gewöhnliche Menschen sind nicht in der Lage mehr als etwa 5-9 verschiedene Dinge gleichzeitig so wahrzunehmen, dass sie die einzelnen Dinge gedanklich auseinander halten können. Dies erkannte Miller [Mil56] und stellte die 7±2 Regel auf, wonach die größte Verständlichkeit bei einer Gliederungstiefe von 7 plus oder minus 2 Elementen erreicht wird. Ein Buch sollte daher zwischen 5 und 9 Kapiteln haben und jedes Kapitel zwischen 5 und 9 Unterkapiteln und so weiter. Bei einer Gliederungstiefe von 7 liegt in etwa das Optimum. Aus dieser Regel lässt sich direkt ableiten, wie wieviele Gliederungsebenen erfor- derlich sind, um eine gegebene Anzahl von Anforderungen wohlstrukturiert bearbeiten zu können: Anforderungen aufnehmen Anzahl Gliederungsebenen keine 1 2 3 4 Anzahl Anforderungen ab 5 Teilungen pro Ebene mittel 7 Teilungen pro Ebene bis 9 Teilungen pro Ebene 1 6 26 126 625 7 9 49 81 343 729 2401 6561 16807 59049 Mit nur 3 Gliederungsebenen lassen sich schon einige hundert Anforderungen strukturieren. Mögliche Gliederungensebenen für Anforderungen sind: ! nach Themengebieten/Unternehmen/Anforderungsgebieten ! nach Geschäftsprozessen/Anwendungsfällen ! nach Geschäftsobjekten ! nach Partnersystemen ! nach Priorität ! nach Anforderungsdimensionen Abbildung 2.2 zeigt wie ein Anforderungsgebiet nach Themen gegliedert wer- den kann. 35 Was soll die Software leisten? Thema 1 Thema 2 Thema 4 Thema 3 Thema 5 Thema ... Abbildung 2.2: Gliederung des Anforderungsgebietes nach Themen Im Gespräch mit Hr. Exner schlägt Frau Probst vor, ausgehend von den Stich- punkten, die Hr. Exner und Hr. Aufenberg in den Erstinterviews genannt haben, Themengebiete auszufällen entlang der die detaillierte Anforderungsaufnahme nun erfolgen soll. Hr. Exner ist einverstanden und beide stellen folgende The- menliste auf: Projektdefinition, Mitarbeiter und Verantwortlicher, Kunden, Zeiterfassung, Projektberichte. Auf der letzten Gliederungsebene werden die Anforderungen erfasst. Abbildung 2.3 zeigt wie z.B. auf der Gliederungsebene „Thema 2“ Anforde- rungen zu diesem Thema voneinander abgegrenzt werden können. So wird Thema für Thema bearbeitet, bis alle Anforderungen zu allen Themen bekannt sind. 36 AF 2.1 AF 2.3 Anforderungen aufnehmen Thema 2 AF 2.2 AF 2.6 AF 2.x AF 2.5 AF 2.4 Abbildung 2.3: Gliederung eines Themas nach Anforderungen Entlang der Gliederung nach Themen soll so schliesslich schrittweise das ge- samte Anforderungsgebiet über feingranulare Anforderungen abgedeckt sein. Feingranulare Anforderungen erfassen Die schriftlich festgehaltene Anforderung ist der erste Schritt die Wünsche des Auftraggebers für die technische Umsetzung vorzubereiten. Die Klärung des Auftragsinhalts anhand schriflicher Anforderungen liegt im gemeinsamen In- teresse von Auftraggeber und Auftragnehmer, denn Mißverständnisse führen später zu unnötigen Kosten, Aufwänden und Verzögerungen die keinem nut- zen. Deswegen sollte die Anforderungsaufnahme sehr ernst genommen wer- den und ständig geprüft werden, ob man sich gegenseitig verstanden hat. Der Detailierunggrad ist dabei dem erwarteten Nutzen anzupassen - wichtige Punkte mit hohen Risiken sollten sehr genau betrachtet werden, bei Randthe- men ist es sinnvoll, sich kurz zu fassen. Als erstes Thema gehen Hr. Exner und Frau Probst das Thema „Zeiterfassung“ an. Hr. Exner erklärt, dass es darum geht die Aufwände der Mitarbeiter auf die Projekte zu verteilen. Die Länge des Personentages hängt dabei von der Wo- chenarbeitszeit ab. Beispieldokument 2.1 zeigt eine Anforderung, wie sie in unserem Beispielpro- jekt aufgenommen wird. Zur Projektverfolgung der tatsächlichen Personalaufwände eines Projekts werden die Zeitblöcke je Mitarbeiter mit Tagesdatum und geleisteten Stunden ausgewiesen. Je Projekt können die bisher geleisteten Personentage ermittelt werden. Ein Personen- 37 Was soll die Software leisten? tag besteht aus einem Fünftel der Wochenarbeitszeit der Person. Ein Zeitblock ist eindeutig einem Projekt zugeordnet. Beispieldokument 2.1: Eine Anforderung Die folgenden Abschnitte zeigen auf, wie der Klärungsprozess für Anforde- rungen im Detail durchgeführt und auf den Punkt gebracht wird. Reihenfolge der Bearbeitung Bei der Anforderungsaufnahme werden die relevanten Geschäftsprozesse, Anwendungsfälle, Geschäftsobjekte, Anforderungen und Prüfbeispiele ge- sucht bzw. verfeinert. Dabei entstehen offene Fragen, die geklärt werden müs- sen. Ein typischer Diskussionsstrang innerhalb einer Anforderungsaufnahme führt dabei kreuz- und quer durch die oben genannten Ergebnisse. Frau Probst fragt Hr. Exner nach dem Geschäftsprozess „Quartalsbericht erstel- len“. Im Rahmen der Diskussion kommen sie auf den Anwendungsfall „Pro- jektstatus ermitteln“. Sie diskutieren darüber, wie der Projekstatus dem Ge- schäftsobjekt „Projekt“ zugeordnet werden soll - es stellt sich die offene Frage, ob ein Teilprojekt einen eigenen Projektstatus haben soll. Hr. Exner formuliert die Anforderung: „Teilprojekte können den Status fertiggestellt haben. Das Ge- samtprojekt erhält den Status fertiggestellt, wenn alle seine Teilprojekte fertig- gestellt sind“. Als Prüfbeispiel nennt er ein Projekt mit drei Teilprojekten A, B und C. Nur A ist fertiggestellt - das Gesamtprojekt gilt dann als nicht fertigge- stellt“. Dieses Prüfbeispiel bringt den Gedanken auf, dass es einen Anwen- dungsfall geben muss, der den Projektstatus verfolgt ... Da eine typische Diskussion oft scheinbar unsystematisch abläuft erscheint es schwierig, den Überblick darüber zu behalten, ob wirklich alle für das System relevanten Punkte beleuchtet worden sind. Die Versuchung ist gross, lieber der Reihe nach vorzugehen, also z.B. einen Geschäftsprozess nach dem anderen zu bearbeiten, und „Abschweifungen“ nicht zuzulassen. In unseren Projekten wurden die besten Ergebnisse erreicht, wenn der freie Lauf der Diskussion eine Weile lang zugelassen wurde und dabei Nachbarergebnisse enstehen. Schliesslich geht es dann wieder nach Plan weiter. Wichtig ist es, den Über- blick zu behalten, welche Punkte bereits behandelt wurden. Dabei kann eine Mindmap wie in Abbildung 2.4 gezeigt helfen: Projektstatus ermitteln Quartalsbericht erstellen 26.09.2002 - v15 Teilprojekt Projekt Gesamtprojekt Projektstatus? Projektstatus Projektstatus verfolgen Abbildung 2.4: Mind-Map zu einer Diskussion innerhalb der Anforderungsaufnahme 38 Zum Schluss der Anforderungsaufnahme helfen folgenden Fragen bei der Klä- rung, ob alle Punkte angesprochen wurden: ! Sind zu diesem Geschäftsprozess alle Anwendungsfälle genannt worden? ! Sind zu diesem Anwendungsfall alle Anforderungen aufgenommen? ! Sind zu diesem Geschäftsobjekt alle Anforderungen aufgenommen? ! Sind zu dieser Anforderung alle Prüfbeispiele genannt worden? ! Sind alle Offenen Fragen beantwortet? ! Gibt es noch weitere Offene Fragen? Dokumentation offener Fragen Offene Fragen dokumentieren Unklarheiten, Auslassungen, Widersprüche, Verständnisprobleme und andere offene Punkte. Der englische Begriff TBD (to be defined) umschreibt solche offenen Punkte. Der richtige Umgang mit offene Fragen ist ungemein wichtig für den erfolgreichen Verlauf des Projek- tes. Offene Fragen müssen ausgesprochen und dokumentiert werden. Dies kann bereits ein Widerspruch sein, denn das Verfolgen von Offenen Fragen ist mit Arbeit verbunden und provoziert die Notwendigkeit des Fällens von Ent- scheidungen (siehe 7.2 „Entscheidungen fällen“). Da behält so mancher Mit- arbeiter seine Fragen doch lieber für sich. Unbeantwortete Offene Fragen und nicht getroffene Entscheidungen sind jedoch Gift für den Fortschritt des Pro- jektes. In unseren Projekten hat es sich bewährt, offene Fragen an zentraler Stelle zu erfassen, so dass alle Teammitglieder darauf zurückgreifen können. Zu jeder offenen Frage wird festgehalten: ! Inhalt der offenen Frage ! An wen die Frage gerichtet ist. ! Datum und Autor der Fragestellung ! Angenommene Antwort ! Tatsächliche Antwort ! Datum und Autor der Antwort Die angenommene Antwort ist immer dann notwendig, wenn der Fluss der Arbeit ohne die Antwort unterbrochen werden würde. Voraussetzung ist, dass der Fragesteller das eigene Urteilsvermögen für ausreichend hält, um eine wahrscheinlich richtige bzw. sinnvolle Antwort zu nennen. In dieser Form angewendet ergibt sich eine besonders schnelle Form des Treffens von Ent- scheidungen: der Fragesteller fällt die Entscheidung und lässt sich diese vom Empfänger der Frage bestätigen. Gerade, wenn das Risiko einer Fehlentschei- dung gering ist, ist dies der richtige Weg - abzuwarten bis die „offizielle“ Anforderungen aufnehmen 39 Was soll die Software leisten? Antwort kommt führt garantiert zu Zeitverlust und schadet bei geringem Risi- ko oft mehr, als die Entscheidung an Ort und Stelle unter Vorbehalt zu postu- lieren. Hat es sich eingespielt, dass nur in seltenen Fällen das Arbeiten in Richtung einer angenommenen Antwort „für die Katz“ war, gewinnt das ge- samte Projekt. Einige offene Fragen haben die Eigenschaft als „Dauerbrenner“ durch das Pro- jekt geschleppt zu werden. Bei wichtigen Punkten ist dies ein dringendes A- larmzeichen, dass eine Entscheidung überfällig ist. Bei unwichtigen Randthe- men ist es sinnvoller, das sich ein Verantwortlicher ein Herz nimmt und die Frage zu den Akten legt. Die simple Antwort „irrelevant, weil ...“ reicht in diesem Fall. Durchführung mit Fachleuten Wie wichtig die aktive Beteiligung der Anwender und Auftraggeber ist wird von uns im Kapitel 7 herausgestellt. Für die Anforderungsaufnahme ist es wichtig, dass Fachleute für das Thema beteiligt sind. Wenn Sie bei den Erstinterviews oder im Verlauf der Anforderungsaufnahme das ungute Gefühl nicht loswerden, dass die Ansprechpartner des Auftragge- bers ratlos sind, dann sollten Sie rechtzeitig reagieren. Es ist uns häufiger pas- siert, als uns lieb war, dass der Auftraggeber die Mitarbeiter für die Anforde- rungsaufnahme nach Kompetenz ausgesucht hat: diejenigen, die am wenigsten im Tagesgeschäft vermisst wurden waren unsere Gesprächspartner. Das waren dann manchmal Mitarbeiter die von dem Gebiet über das sie Auskunft erteilen sollten, keine Ahnung hatten - die kompetenten Mitarbeiter wurden ständig gebraucht und waren nicht verfügbar. Auf der Requirements Engineering Kon- ferenz 1998 [ICRE98] wurde geschildert, wie eine Softwarefirma ein System für Aktienhändler erstellen solle, diese aber auf keinen Fall bei der Arbeit un- terbrechen durfte. Nur wenn sie sicherstellen, dass dem Auftraggeber klar ist, welchen Folgen solch verschlechterte Bedingungen der Anforderungsaufnah- me haben, können sie den Erfolg des Projektes sicherstellen. Entweder indem der Auftraggeber die Bedingungen auf Ihr Anraten hin ändert oder die Folgen bzgl. Aufwand und Ergebnis akzeptiert. Zur Not müssen Sie sich ggf. auf Kos- ten des Auftraggebers selbst in das fachliche Thema einarbeiten. 2.3 Prüfbeispiele dokumentieren Woher wissen Sie, ob das von Ihnen in Auftrag gegebene Haus Ihren Anforde- rungen entspricht? Sie haben für alle Ihre Anforderungen Prüfmöglichkeiten. Sie können die Grundstücksfläche auf den Zentimeter genau ermitteln, ebenso die Wohnfläche. Sie können die Anzahl der Fenster zählen und die Farbe des 40 Putzes mit Referenzfarbkarte überprüfen. Sie können vergleichen, ob Ihr Haus zu den veranschlagten Kosten termingerecht erstellt werden wird. Alle rele- vanten Prüfkriterien haben Sie vor Baubeginn mit Ihrem Auftragnehmer ver- einbart. Wie beeinflusst die Anwendung dieses Prinzips den Erfolg Ihres Softwarepro- jektes? Die Erfüllung jeder Anforderung wird mittels eines oder mehrerer Bei- spiele prüfbar gemacht. Beispiele helfen erheblich zwischen Menschen und Maschine zu vermitteln. Die Verständlichkeit und Schlüssigkeit einer Anfor- derung erhöht sich mit jedem Prüfbeispiel, das für die Anforderung festgehal- ten wird. Prüfbeispiele werden in natürlicher Weise von Menschen bei der Erstellung von Modellen verwendet (siehe Abschnitt 3.1 „Modellieren“). Fr. Probst fragt Hr. Exner nach einem konkreten Beispiel für die Berechnung des Gesamtaufwandes für ein Projekt. Situation: Die Projekte „Autoteile Internet-Shop“ und „Vertragsmanager“sind beauf- tragt. Herr Friesen, Frau Meidrich, Hr. Sturm und Frau Sauer haben bisher folgende Aufwände geleistet: Prüfbeispiele dokumentieren Erfolgsfaktor: Nur das, was ich prüfen kann, kann ich auch beurteilen.2 Aufwände pro Projekt Mitarbeiter Herr Friesen Frau Meidrich Hr. Sturm Frau Sauer Autoteile Internet Shop 25,0 h 18,0 h - 13,0 h Vertragsmanager 42,5 h - 19,5 h - Aktion: Die Projekt- und Mitarbeiterangaben sowie die Aufwände werden erfasst und die Auswertung „Gesamtaufwand je Projekt“ angestossen. Erwartetes Ergebnis: Autoteile Internet Shop: 56 h, Vertragsmanager: 62 h. Beispieldokument 2.2: Ein Prüfbeispiel In den meisten Fällen brauchen Sie ihre Auftraggeber überhaupt nicht explizit um Prüfbeispiele zu bitten. Im Rahmen der Anforderungsaufnahme werden ihnen immer wieder konkrete Fälle und Dokumente genannt. Erarbeiten Sie aus diesen Ansatzpunkten die Prüfbeispiele. Zwei einfach Fragen helfen, weitere Prüfbeispiele zu finden: ! Ist das immer so? ! Was könnte dazu führen, daß das Beispiel in bestimmten Situationen nicht stimmt? 2 Vgl. auch “You can not control what you can not measure” - Tom DeMarco [DeM99] 41 Was soll die Software leisten? Die Prüfbeispiele werden zur Beurteilung nicht nur der Anforderungen son- dern auch aller folgenden Entwicklungsergebnisse herangezogen. Folgende Fragen sind mit dem Vorliegen von Prüfbeispielen jederzeit beantwortbar: Wie konsistent sind die Anforderungen mit ihren zugehörigen Prüfbeispielen? Wieviele der Prüfbeispiele werden von der bisher erstellten Software bzw. den dazugehörigen Modellen bestanden? Wie beurteilen Auftraggeber und Auf- tragnehmer die erstellten Ergebnisse im Verhältnis zur übrigen Projektsituati- on (bisher verursachte Kosten, abgelaufene Zeit usw.)?3 Am Ende des Projektes werden die Prüfbeispiele zu Abnahmekriterien für die ausgelieferte Software. Sie können Abnahmekriterien im Sinne von ISO 9000-3 sein, wenn sie als verbindlicher Test für die Erfüllung von Anforde- rungen deklariert werden. 2.4 Anforderungsprofil erstellen Wie können die Software-Wünsche aller Beteiligten mit den verfügbaren Mit- teln umgesetzt werden? Wo liegen die Grenzen? Was soll weggelassen wer- den? Wo kann der Umfang reduziert werden? Was wird später realisiert? Wo sind die Kosten im Verhältnis zum Nutzen einfach zu hoch? Welche Anforderungen machen nach dem Pareto-Prinzip 80% des Erfolges aus und sind mit 20% des Aufwands umzusetzen? Welche Prioritäten ergeben sich daraus? In den meisten Projekten ist es unmöglich alle vorliegenden Wünsche in vol- lem Umfang zu berücksichtigen. In der Liste der schriftlichen Anforderungen tauchen nur noch die Wünsche auf, bei denen sich die Beteiligen darauf eini- gen konnten zu untersuchen, welche Folgen (Kosten, Aufwände, technische Probleme) mit der Umsetzung in Abhängigkeit vom Umfang der Umsetzung verbunden sein werden. Für den Umfang der Umsetzung wird z.B. eine Skala von „fehlt“ bis „optimal gelöst“ verwendet. Die Ergebnisse dieser Untersuchung fliessen in die Festlegung der Anforde- rungsprofile ein. Auftraggeber und Auftragnehmer einigen sich pro Meilen- stein auf ein Anforderungsprofil. Die Entscheidung über den Inhalt des Anfor- derungsprofil erfolgt, indem für jede potentielle Anforderung explizit zu fest- 3 Diese Transparenz macht die politische Brisanz dieses Erfolgsfaktors aus. Es ist eine selbsterfüllende Prophezeihung, wenn aus Angst den Erfolg zu gefährenden, durch Ver- zicht auf diesen Erfolgsfaktor Probleme nicht offen gelegt werden. Die Probleme gehen davon nicht weg, nur der Erfolg des Projektes wird unwahrscheinlicher. 42 Erfolgsfaktor: Die richtig priorisierte Auswahl der Anforderungen legt das zu realisierende Anforderungsprofil fest. gelegt wird, ob sie ins Anforderungsprofil aufgenommen wird oder nicht. Die- se Entscheidung kann nur von einem Verantwortlichen wahrgenommen wer- den. Ein Verantwortlicher muss die Folgen die sich durch die Aufnahme der Anforderung in das Profil ergeben (Kosten, Termine, Veränderungen) authori- sieren können. Ein potentielle Anforderung kann also ! ins Profil aufgenommen werden ! zurückgestellt werden bis sie verantwortet wird ! verworfen werden Zur Klärung der Vollständigkeit von Anforderungen sollten in strittigen Fällen zurückgestellte und verworfene Anforderungen dokumentiert werden. Das Anforderungsprofil hat folgende Dimensionen: ! Umfang/Aufzählung der Anforderungen ! Höhe/Bewertung der Anforderungen ! Detaillierung der Anforderungen Im Einzelnen leisten die Dimensionen Folgendes: ! Umfang/Aufzählung der Anforderungen In dieser Dimension geht es darum die Anforderungen zu benennen und in eine übersichtliche Struktur einzuordnen. "Das System soll die Erfassung der Projekt durch die Mitarbeiter geleisteten Zeiten unterstützen. Das Sys- tem soll pro Projekt das noch verfügbare Restbudget ermitteln können ..." ! Höhe/Bewertung der Anforderungen In dieser Dimension wird eine Anforderung bzgl. des Grades der nötigen Umsetzung bewertet. Es wird zum Beispiel entschieden ob die Anforde- rung besonders gut/schön/schnell umgesetzt werden soll. "Der monatliche Projektbericht ist in Farbe auszudrucken und soll ein an- sprechendes Erscheinungsbild haben. Die Angaben im Projektbericht sol- len tagesaktuell sein und eine Genauigkeit von einem halben Personentag pro Mitarbeitermonat haben." ! Detaillierung der Anforderungen Die inhaltlichen Details der Anforderung stellen die dritte Dimension des Profils dar. Die Höhe/Bewertung ist prinzipiell eine besondere Form der Detaillierung - sie sollte jedoch unserer Ansicht nach von anderen Formen der Detaillierung abgegrenzt werden damit die Vollständigkeitsaussage klarer zu treffen ist. Das Anforderungsprofil legt für die vorliegenden Anforderungsbereiche den Umfang fest, in dem die Anforderungen aus dem jeweiligen Bereich umzuset- zen sind. Jedes Anforderungsprofilelement stellt damit einen verbindlichen Auftragsbestandteil dar. Anforderungsprofil erstellen 43 Was soll die Software leisten? Ein Mögliches System zur Bewertung von des Umfangs von Anforderungen nutzt folgende Stufen: Symbol für Bewertung ++ + o - -- Bedeutung optimal gelöst gut gelöst vorhanden vorhanden, aber unvollständig fehlt Die folgende Abbildung zeigt ein Beispiel für ein Anforderungsprofil, das mit diesen Symbolen erstellt wurde: Um- ++ fang O - -- Beispieldokument 2.3: Ein Anforderungsprofil Ausschnitte der Wunschliste werden zu Anforderungsprofilen, wenn ! klar ist, was wichtig ist, ! die Beteiligten sich einigen, was sie fordern wollen, ! der Umfang der Forderungen festgelegt ist, ! das Anforderungspaket geschnürt ist und ! die Umsetzung in Auftrag gegeben wird. Die Erstellung von Anforderungsprofilen hat sich bei der Entwicklung von Produkten außerordentlich bewährt. Nur die richtige Mischung von Eigen- schaften eines Produktes bewährt sich am Markt. Die Übertragung dieses Er- folgsrezeptes auf Auftragsprojekte führt zum selben Effekt: die Zufriedenheit der Auftraggeber steigt mit dem Grad der Abdeckung des vereinbarten An- forderungsprofils durch die fertige Software. Wie Anforderungsprofile für die Projektplanung optimal eingesetzt werden können, erfahren Sie unter www.b-agile.de/Erfolgsrezepte/Anforderungsprofile.html !!!. + Zeit- blöcke Projekt Mit- arbeiter status ten Projekt- Anforderungsbereich Kundenda- ... 44 2.5 Änderungen der Anforderungen Änderungwünsche und Anforderungen unterscheiden sich prinzipiell nur durch den Zeitpunkt der Nennung des Wunsches. Änderungwünsche entstehen nachdem bereits eine funktionierende Software ausgeliefert wurde. Zu diesem Thema finden Sie in Abschnitt 5.2 „Fehlermeldungen und Änderungswün- sche“ weitergehende Hinweise. Davon zu unterscheiden sind Änderungen an den Anforderungen während der Entwicklung noch bevor eine Anforderung in die funktionierende Software eingeflossen ist. Anforderungen ändern sich Es gibt viele Gründe warum sich Anforderungen an Software ändern. Der häu- figste Grund ist, dass sich das Aufgabenfeld verändert in dessen Kontext die Software eingesetzt wird. Technische Anforderungen ändern sich heute sehr schnell, da die Lebenszykluszeit der eingesetzten Softwareprodukte heute um vieles geringer ist als zu Beginn des Computerzeitalters. Neue Versionen von Datenbanken, Netzwerken, Betriebssysteme und anderer Infrastruktur bringen ständige Veränderung mit sich. Der Wechsel von Personen und Organisati- onsformen führt ebenfalls zur Schnellebigkeit von Anforderungen. Anforderungen ändern sich nicht Es gibt eine ganze Reihe von Anforderungen, die über viele Jahre stabil blei- ben. Dies betrifft Anforderungen an den grundlegenden Gang von Geschäften in Branchen, deren Verfahren sich über Jahrzehnte nicht geändert haben: Ver- sicherungen und Banken haben zum Beispiel solche stabilen Basisverfahren. Denken Sie an Darlehen oder Lebensversicherungen – hier werden Verträge mit sehr langen Laufzeiten geschlossen – es muss sichergestellt sein, dass auch noch am Ende der Laufzeit die Vertragsinhalte von der eingesetzten Software korrekt umgesetzt werden. Aber auch im Umfeld dieser stabilen Basisanforde- rungen ändern sich einige Details sehr schnell, z.B. wenn sich gesetzliche An- forderungen verändern. Projektlaufzeiten Die Projektlaufzeit hängt vom Umgang der Anforderungen ab, die dem Pro- jekt als Aufgabe gestellt werden. Es gilt, das „richtige“ Anforderungspaket zu Änderungen der Anforderungen 45 Was soll die Software leisten? schnüren. Hier beginnt der Teufelskreis. Die Auftraggeber sind aus der Ver- gangenheit vielfach gewohnt, dass es lange Projektlaufzeiten gibt und das ein einmal eingesetztes System dann möglichst nicht mehr geändert werden soll, da dies mit zusätzlichen Kosten und Folgeproblemen verbunden ist. Aus die- ser Erfahrung heraus entsteht zu Beginn eines neuen Projektes die Erwartung „dies ist für lange Zeit die letzte Gelegenheit, Anforderungen zu nennen“. So wird in so manches Projekt möglichst noch alles an Wünschen hineingepackt, was politisch durchsetzbar ist. Der Anforderungsrahmen wird damit größer. Mehr noch – da ja klar ist das nun für Monate, meistens jedoch eher Jahre kei- ne weiteren Anforderungen aufgenommen werden, muß auch für die Zukunft vorgesorgt werden. Alle Anforderungen die in absehbarer Zukunft auf die Auftraggeber zukommen werden bringen zusätzliche Brisanz. Bei diesen An- forderungen sind die Details noch nicht klar. Aber es ist sicher, wenn diese Anforderungen nicht mit in dieses Paket aufgenommen werden, dann werden die Anforderungen aufgrund der langen Projektlaufzeit nicht rechtzeitig erfüllt sein. „Sicherheitshalber“ nennt der Auftraggeber daher die unklaren Anforde- rungen und läßt sie – notgedrungen auch unscharf – in das Anforderungspaket aufnehmen. Nun nimmt das Schicksal seinen Lauf – ein Projekt, das mit un- scharfen Anforderungen arbeitet hat einen erheblich höheren Kommunikati- onsaufwand und viel größere Änderungshäufigkeiten als dies mit klaren, scharfen Anforderungen der Fall wäre. Das Projekt verzögert sich zusätzlich. Am Ende der nun noch größeren Projektlaufzeit haben sich noch mehr Anforderungen geändert und das geschnürte Anforderungspaket stimmt nicht mit den dann tatsächlich vorhandenen Anforderungen überein. Kleine Anforderungspakete Offensichtlich bieten kleinere Anforderungspakete höhere Erfolgschancen. Die Effekte, die durch „aufgeschaukelte“ Projektlaufzeiten entstehen können durch kleinere Anforderungspakete vermieden werden. Proaktivität Wenn man Anforderungspakete als „Vektoren“ begreift, die einen Ausgangs- punkt und eine Richtung haben, dann ist es möglich die zukünftigen Anforde- rungen vorherzuplanen. Dieses Vorgehen ist mit einer gewissen Unschärfe verbunden, da es in der Realität auch einmal zu heftigen Veränderungen von Anforderungsprofilen kommen kann. Aber die Chancen sind sehr gut bei die- sem Vorgehen den tatsächlichen zukünfigen Anforderungsbedarf zu decken, wenn mit kleinen Anforderungspaketen gearbeitet wird. 46 Änderungen der Anforderungen Erfolgsfaktor: Stellen Sie sich aktiv darauf ein, dass es zu Änderungen der Anforderungen kommen wird und berücksichtigen Sie diese so früh wie möglich! Abbildung 2.5 erläutert das Vorgehen. Zu Beginn des Projektes (1) wird von einem bestehenden Anfordersprofil aus entlang des Vektors in Richtung (2) gearbeitet. Durch die kurze Projektlaufzeit kann rechtzeitig auf die veränderte Richtung auf (3) zugearbeitet werden. Zu diesem Zeitpunkt ist die erneute Richtungsänderung bekannt und das Projekt passt sich entsprechend an. Stel- len Sie sich vor in der gleichen Zeit wäre einfach in Richtung des ersten Vek- tors weitergearbeitet worden – das Ergebnis würde zu weiten Teilen nicht mehr mit den wirklichen Anforderungen übereinstimmen. 1 23 Abbildung 2.5 Änderung der Richtung von Anforderungen Änderungsgeschwindigkeit von Anforderungen Eine zu grosse Änderungsgeschwindigkeit von Anforderungen gefährdet den Erfolg ihres Projektes. Wenigstens die Rahmenanforderungen müssen so stabil bleiben, dass in jedem Entwicklungsschritt ein Vorankommen in Richtung dieser Rahmenanforderungen möglich ist. 47 Was soll die Software leisten? Bei der Auswertung der Umfrage hat der Erfolgsfaktor „Änderungen berück- sichtigen“ zwei Gruppen von Projekten hervorgebracht, die diesen Faktor höchst unterschiedlich bewertet haben: Eine Gruppe von Projekten beurteilte diesen Faktor als fördernd, eine andere Gruppe von Projekten beurteilte diesen Faktor als behindernd. Es gab kein Mittelfeld! Es gibt also offensichtlich zwei grundsätzliche Ansätze, mit Änderungen umzugehen: ! Den Einfluss von Änderungen auf das Projekt grundsätzlich vermeiden. ! Mit Änderungen proaktiv umgehen. Wir empfehlen Ihnen sich klar zu entscheiden, welchen der Ansätze sie wäh- len wollen. Egal wie Sie sich entscheiden - auf jeden Fall sollten Sie darauf bestehen, dass die Rahmenanforderungen für das Projekt stabil bleiben. Wenn sich die Rahmenanforderungen ändern bedeutet dies, dass ein komplett ande- res Projekt von Ihnen verlangt wird. Es ist dann sinnvoll, auch explizit ein neues Projekt zu starten. Damit Sie festellen können, wann Ihre Rahmenanfoderungen drohen instabil zu werden, ist es wichtig, diese bereits zu Beginn des Projektes ausdrücklich und schriftlich festzuhalten. 2.6 Der Wert von Software Worin besteht eigentlich der Wert einer Software? Wie bei anderen Gütern auch gibt es natürlich verschiedene Wege den Wert von Software zu bemes- sen. Folgende Fragen sind zum Beispiel geeignet den Wert einer Software zu bemessen: ! Was ist der Preis, den die Software am Markt erzielt? ! Was ist der Nutzen, den die Software bei Ihrem Einsatz liefert? ! Was ist der Schaden, den die Software anrichtet, wenn sie nicht oder feh- lerhaft funktioniert? Software hat einen anderen Lebenszyklus als ander Güter. Betrachten wir ei- nige Beispiele: ! Ein typischer Lebenszyklus für ein Autokauf besteht aus: Geeignetes Auto anschaffen, Autobetrieb mit Wartung/Versicherung/Kraftstoff/Steuer usw. sicherstellen, Auto verkaufen oder Reparaturen vornehmen solange es sich lohnt und dann verschrotten. 48 Erfolgsfaktor: Achten Sie darauf, dass die Rahmenanforderungen für Ihr Projekt stabil bleiben. ! Ein typischer Lebenszyklus für einen Fernseher besteht aus: Geeignetes Gerät anschaffen, Gerät betreiben, Reparaturen vornehmen solange es sich lohnt, Gerät verschrotten. ! Ein typischer Lebenszyklus für Software besteht aus: Software erstellen , Software wegen Änderung des Computers ändern, Software wegen Ände- rung der Infrastruktur ändern, Software wegen Änderung der Anwender- wünche ändern, Software wegen neuer gesetzlicher Anforderungen ändern, ... Der Wert von Software liegt in der ständigen Anpassbarkeit an neue techni- sche und fachliche Gegebenheiten! Software verliert Ihren Wert wenn unter neuen Bedingungen die Änderung teurer als die Neuanschaffung wird. Soft- ware ist also so etwas wie ein unendlich reparierbares Auto. Der Wert von Software 49 Was soll die Software leisten? 2.7 Literatur [ICRE98] Proceedings Third International Conference on Requirements Engineering, IEEE Computer Society, 1998 Während dieser Konferenz entstand das im Vorwort gezeigte Ur- bild der von uns verwendeten Brücke. [Tha02] G. E. Thaller: Software-Anforderungen für Webprojekte Vorgehensmodelle, Spezifikation, Design, Galileo Press, 2002 [Rob99] S.Robertson:MasteringtheRequirementsEngineeringProcess, Addison-Wesley, 1999 Alles was man über die Anforderungsaufnahme wissen muss. Im Anhang finden sich Vorlagen für eine gute gegliederte Anforde- rungsaufnahme nach dem „Volere“ - Prinzip. [Rup02] C. Rupp, SOPHIST GROUP: Requirements Engineering, Hanser, 2002 Frau Probst hat sicher das Buch von Chris Rupp und den Sophisten gelesen 50 Modellieren . „Eine (wahre) Theorie hat die Wirklichkeit als Modell.“ Mick Krippendorf 3 3 Vom Anforderungsprofil zum Modell Aus dem Text des Anforderungsprofils gilt es im nächsten Schritt ein Modell zu machen, das bereits etwas mehr der Sicht des Computers entspricht. Auf der anderen Seite muss dieses Modell für die Projektbeteiligten verständlich bleiben. Modelle ermöglichen es, Ideen auf einfache Art auszutauschen und sie auf ihre Stichhaltigkeit hin zu überprüfen. 3.1 Modellieren Nach Untersuchungen aus den 80er Jahren haben kreative Softwareentwickler folgenden Ansatz zur Problemlösung [Gla95]: ! Im ersten Schritt erstellt der Entwickler ein geistiges Modell der Lösung ! Dann prüft er sein Modell auf Richtigkeit, indem er es anhand konkret ge- dachter Situationen durchspielt. Wenn er Unstimmigkeiten entdeckt, wird das geistige Modell angepasst und erneut durchgespielt. ! Dieser Vorgang der mentalen Simulation wird mit verschiedenen Sätzen von Prüfbeispielen wieder und wieder durchgespielt, bis der Entwickler mit dem Modell soweit zufrieden ist, dass er es für eine machbare Lösung hält. ! Erst zum Schluss bringt der Entwickler seine Gedanken zum Ausdruck. 51 Vom Anforderungsprofil zum Modell Modellieren bedeutet, das fertig gedachte Modell zum Ausdruck bringen zu können, bevor es zu Programmcode wird. In vielen Ingenieurwissenschaften ist es üblich Modelle zu entwickeln. Abbildung 3.1 zeigt als Beispiel den Originalplan des Eiffelturms in der frü- hen Phase der Planung. Abbildung 3.1 Originalplan des Eiffelturms ca. zwei Jahre vor Baubeginn Modelle haben folgende Vorteile: ! sie können sehr früh schon in der Planungsphase erstellt werden ! ein Modell zu verwerfen ist um vieles günstiger als eine erstellte Lösung ändern zu müssen ! Modelle veranschaulichen die Planung ! mit Modellen können Simulationen durchgeführt werden ! anhand eines Modells können Aufwände und Kosten abgeschätzt werden 52 Erfolgsfaktor: Erstellen Sie ein Modell der Realität. ! die Prüffälle, mit denen das Modell auf Tauglichkeit getestet wird, können später für das reale Ergebnis ebenfalls verwendet werden. Wenn Sie modellieren können Sie also für recht geringe Kosten viele Vorteile erreichen. In unseren Projekten haben wir jedoch die Erfahrung gemacht, dass es stark darauf ankommt, wie modelliert wird und wie mit den Modellen um- gegangen wird, ob diese Vorteile auch zum Tragen kommen. Folgende Punkte sind für den Erfolg entscheidend: ! Das Modell muss in beide Richtungen konkret sein - es muss eine hohe Übereinstimmung mit der Realität/den Anforderungen haben - es muss mit den für das Projekt vorgesehenen Mitteln realisierbar sein ! Das Modell muss entweder früh als solches an die Seite gelegt werden oder es muss durchgängig bis zum Projektende gepflegt werden4. Ob Sie sich für Datenmodellierung, Modellierung nach der Strukturierten Analyse, Simulationsmodelle oder Modelle nach Ihren eigenen Vorstellungen entscheiden - in jedem Fall stehen Sie besser da, als wenn Sie überhaupt nicht modellieren. Unserer Ansicht nach hat den größten Nutzen jedoch ein durch- gängig objektorientierter Ansatz. 3.2 Objektorientierter Ansatz Welche drei Methoden der Einordnung, die unser Denken bestimmen wenden wir ständig an, um unsere Welt zu verstehen?5 1. bei der Erfassung unserer Beobachtungen trennen wir zwischen Objek- ten und ihren Eigenschaften – z.B. unterscheiden wir zwischen einem Baum und seiner Größe oder Lage im Verhältnis zu anderen Objekten, 2. wir unterscheiden zwischen ganzen Objekten und ihren Bestandteilen – z.B. wenn wir einen Baum im Gegensatz zu den Ästen betrachten, aus denen er besteht und 3. wir bilden und unterscheiden verschiedene Gruppen von Objekten in- dem wir sie klassifizieren – z.B. wenn wir die Klasse aller Bäume und die Klasse aller Steine bilden und diese unterscheiden. „Objektorientierte Ansatz“ bedeutet lediglich auf diese Denkprinzipien aufzu- bauen und sie durchgängig anzuwenden und für alle Beteiligten sinnfällig zu machen. Damit sind die Beteiligten in einem Softwareprojekt in der Lage sich ein gemeinsames Modell der Wirklichkeit zu schaffen. Die zu erstellende Software basiert auf diesem Modell. Das Modell entspricht auf natürliche Weise den Denkstrukturen der beteiligten Menschen vom Auftraggeber bis 4 Bei generativen und round-trip Ansätzen (siehe 6.4 “Generierung“) ist diese Durchgängig- keit unabdingbar. 5 Nach [Coa90] - dort wird die Encylopaedia Britannica „Classification Theory“ zitiert Objektorientierter Ansatz 53 Vom Anforderungsprofil zum Modell zum Entwickler. Die einmal geprägten Begriffe für Klassen, Eigenschaften, Beziehungen zwischen Objekten bleiben dabei erhalten. Fr. Entrop stellt den Entwurf des objektorientierten Modells für die Projektver- waltung vor. Sie erläutert dabei die Klasse „Gesamtprojekt“ aller Projekte, die aus Teilprojekten bestehen. Die Eigenschaft „geplante Personentage“ hat sie dieser Klasse zugeordnet. Hr. Exner ist begeistert davon, dass heutzutage solch sprechende Namen benutzt werden können und das sogar Leerzeichen möglich sind. Frau Entrop erklärt, dass bei der Implementierung in Java später „geplan- tePersonentage“ als Feldname auftauchen wird. Hr. Exner erzählt, dass dieses Feld in der Altanwendung den Namen H47GMT01 hat. Anforderung 009 Zeitblöcke wf 2000-03-13 Projekt geleistetePersonentageErmitteln() : long 1 1..n 0..n 1 1 0..n Mitarbeiter Wochenarbeitszeit : fixed<4,2> Projekteinsatz Zeitblock Tagesdatum : Datum geleisteteStunden : long Abbildung 3.2 Sicht auf die Anforderung 009 - Zeitblöcke Am leichtesten wird Ihnen die objektorientierte Modellierung fallen, wenn Sie die Objektorientierung als „natürliche Sicht“ auf die Realität betrachten. Ver- suchen Sie inbesondere nicht, mit mathematisch scharfen und exakten Ansät- zen an die Objektorientierung heranzugehen. Wenn Sie das Gefühl haben, dass das Erstellen von Objektmodellen kinderleicht ist, dann liegen Sie richtig. Im folgenden Abschnitt und dort insbesondere im Unterabschnitt „Die Welt als Bühne“ finden Sie Hinweise, wie Sie sich das Modellieren erleichtern kön- nen. 54 Erfolgsfaktor: Verwenden Sie durchgängig den objektorientierten Ansatz. 3.3 Ableitung des Modells aus den Anforderungen Alle Analyseergebnisse basieren auf den Anforderungen - insbesondere soll nur modelliert werden, was gefordert ist. Für die Ableitung des Modells aus den Anforderungen gibt es keine strikten Regeln. Der Modellierer muss mit „Sinn und Verstand“ an die Arbeit gehen. Es ist jedoch möglich festzustellen, welche Analyserergebnisse für welche Anforderungen benötigt werden. Das Modellieren entlang der Anforderungen und Prüfbeispiele ist zudem besonders leicht, weil sie dabei auf natürliche Weise modellieren und sich immer nur mit einem überschaubaren Teilaspekt des Problems beschäftigen. Die Welt als Bühne - Objekte als Darsteller Stellen Sie sich Objekte als handelnde Darsteller auf einer Bühne vor. Sie selbst übernehmen die Aufgaben für Drehbuch und Regie. Sobald Sie einem Darsteller einen Namen gegeben haben, sind sie in der Lage seine Eigenschaf- ten zu beschreiben. Sie können festlegen zu welchen Handlungen er fähig ist und welche Kunststücke er beherrscht, was er weiss und wozu er aufgrund dieses Wissens fähig ist. Manchmal müssen Sie sich gedanklich in den Dar- steller hineinversetzen, um entscheiden zu können, wie die Szene weitergehen kann. Lesen Sie sich nun aufmerksam eine Anforderung und die zugehörigen Prüfbeispiele durch – welche Darsteller können Sie entdecken? Fangen Sie mit der Situation an, stellen Sie Ihre Darsteller auf die Bühne. Betrachten wir dazu die Situation aus dem Beispieldokument in Abschnitt 2.3: Die Projekte „Autoteile Internet-Shop“ und „Vertragsmanager“sind beauftragt. Herr Friesen, Frau Meidrich, Hr. Sturm und Frau Sauer haben bisher folgende Aufwände geleistet ... Um diese Situation auf Ihrer Bühne nachzustellen brauchen Sie sechs Darstel- ler: zwei der Sorte „Projekt“ und vier der Sorte „Mitarbeiter“. Die Projekte und Mitarbeiter sind einander wie in der Aufwandstabelle beschrieben zuge- ordnet. In der Situation sind die Namen der Projekte, die Namen der Mitarbei- ter und die Zahlen für die geleisteten Aufwände beschrieben. Dieses Wissen gilt es nun den Darstellern sinnvoll zuzuordnen. Bei den Namen fällt die Ent- scheidung leicht: die Projekte „Autoteile Internet-Shop“ und „Vertragsmana- ger“ sollen ihren Namen kennen genauso wie jeder der Mitarbeiter seinen ei- genen Namen wissen soll. In der UML6-Notation gibt es zwei Darstellungs- möglichkeiten für die Situation: Abbildung 3.3 zeigt ein passende Darstellung 6 Unified Modelling Language - eine standardisierte Form der Darstellung von objektorien- tierten Modellen Ableitung des Modells aus den Anforderungen 55 Vom Anforderungsprofil zum Modell der Darsteller, Abbildung 3.4 zeigt eine Version die sich auf die Sorten von Darstellern beschränkt.. Projekt "Autoteile Internet Shop" Mitarbeiter "Herr Friesen" Abbildung 3.3: Darsteller für die vorliegende Situation7 Abbildung 3.4: Sorten von Darsteller für die vorliegende Situation8 Welchen der Darsteller sollen wir nun aber nach den Aufwänden für die Pro- jekte fragen? Soll das Projekt jeweils wissen, wieviel Aufwand die Mitarbeiter die zu diesem Projekt gehören geleistet haben? Oder sollen die Mitarbeiter beantworten können, wieviel Aufwand sie für ein Projekt geleistet haben? Mit fünf weiteren Darsteller ist ein Mittelweg möglich: jede Projektbeteiligung wird als Bindeglied zwischen Projekt und Mitarbeiter in die Szene aufgenom- men. Projekt name name Mitarbeiter "Frau Meidrich" Mitarbeiter Mitarbeiter "Hr. Sturm" Mitarbeiter "Frau Sauer" Projekt "Autoteile Internet Shop" Projekt "Vertragsmanager" Projektbeteiligung 19,5 h Projektbeteiligung 25.0h Projektbeteiligung 18,0 h Projektbeteiligung 13,0 h Projektbeteiligung 42,5 h Mitarbeiter "Frau Meidrich" Mitarbeiter "Herr Friesen" Mitarbeiter "Hr. Sturm" Abbildung 3.5: Die Projektbeteiligungen betreten die Bühne 7 Es handelt sich um ein „Kollaborationsdiagramm“. Unserer Erfahrung nach lohnt es sich nicht, die Kollaborationsdiagramme explizit zu zeichnen oder mit einem Werkzeug zu er- fassen. Zur Veranschaulichung, wie die Angaben aus den Prüfbeispielen für die Modellie- rung genutzt werden können, ist ein solches Diagramm hier aber nützlich. 8 Ein Klassendiagramm 56 Projekt "Vertragsmanager" Mitarbeiter "Frau Sauer" Abbildung 3.5 und Abbildung 3.6 geben die Situation jetzt vollständig wieder. Indem Sie die verschiedenen Sorten von Darsteller klassifizieren und ihre ge- meinsamen Eigenschaften beschreiben, leisten Sie den wesentlichen Schritt der Modellierung - Sie abstrahieren. Abbildung 3.6: Charakterbild und Beziehungen der Darsteller Indem Sie die Situation auf verschiedene Charaktere verteilen und nicht ein- fach nur eine Person „Situation“ auf die Bühne stellen, strukturieren Sie und Sie verteilen Verantwortung. Stellen Sie sich die Welt einfach als Bühne vor und diese Schritte werden Ihnen als selbstverständlich vorkommen. Zudem erreichen Sie dabei, dass die Strukturen, die Sie bilden den Strukturen ihres Fachproblems sehr nahe kommen. Die Aussagen aus den Prüfbeispielen stammen ja direkt von den Fachleuten und geben die Denkstrukturen der von Ihnen befragten Fachleute wieder. So kommen Sie auch nicht in Versuchung in technischen Strukturen zu denken, denn die Anforderungssteller werden normalerweise auch nicht in technischen Strukturen denken. Die Begriffe aus der Anforderungsaufnahme fliessen so zudem ziemlich unverändert in Ihr Modell ein und Sie sprechen damit automatisch die Sprache Ihres Auftragge- bers. Vervollständigen wir nun das Modell, bis es das Prüfbeispiel ganz abdeckt. Betrachten wir als nächstes die Aktion: Aktion: Die Projekt- und Mitarbeiterangaben sowie die Aufwände werden erfasst und die Auswertung „Gesamtaufwand je Projekt“ angestossen. Nun soll Bewegung in die Szene kommen. Wie können die Darsteller durch ihr Zusammenspiel die gewünschte Aktion durchführen? Wer dafür welche Fähigkeiten haben? Wem wird die Verantwortung übertragen? Eine sinnvolle Lösung scheint zu sein, für Projekte, Mitarbeiter und Projektbeteiligungen je- weils einen Verwalter als Darsteller auftreten zu lassen. Die Verwalter über- nehmen die Aufgabe der Erfassung. Zudem übernimmt der Projektverwalter die Aufgabe die Auswertung „Gesamtaufwand je Projekt“ durchführen zu können. Damit die Arbeit leichter wird, fragt er dazu jedes Projekt nach sei- nem Gesamtaufwand. Die folgenden Abbildungen geben das Ergebnis dieser Überlegungen wieder: Projekt name Projektbeteiligung aufwand Ableitung des Modells aus den Anforderungen Mitarbeiter name 57 Vom Anforderungsprofil zum Modell Projekt "Vertragsmanager" Projektbeteiligung- Verwalter Projektbeteiligung 19,5 h Projektbeteiligung 13,0 h Projektbeteiligung 42,5 h Projektbeteiligung 25.0h Projektbeteiligung 18,0 h Mitarbeiter "Frau Meidrich" Mitarbeiter "Herr Friesen" Mitarbeiter "Hr. Sturm" Abbildung 3.7: Die Verwalter betreten die Szene und treten in Aktion In diesem Schritt haben Sie bereits einen Algorithmus konzipieren müssen. Sie haben sich überlegt, wie Projektverwalter und Projekt zusammenarbeiten, um die Auswertung „Gesamtaufwand je Projekt auswerten“ zu erreichen. Da- zu haben Sie sich in die Rolle des Projektverwalters versetzt und sich überlegt „Wie würde ich das Problem lösen, diese Auswertung zu bekommen?“ ProjektVerwalter Projekt erfassen() Gesamtaufwand je Projekt auswerten() Abbildung 3.8: Einbeziehung der Aktion in das Modell Eine mögliche Antwort in „ich-Form“ lautet „Ich bitte alle von mir verwalte- ten Projekte, Ihren Gesamtaufwand zu bestimmen und stelle anhand der Er- gebnisse dann eine sortiere Liste der Gesamtaufwände je Projekt zusammen“. Dies ist bereits eine gute Dokumentation für „Gesamtaufwand je Projekt aus- werten.“ Zum guten Schluss geht es darum, dass Modell auf Richtigkeit zu prüfen: Erwartetes Ergebnis: Autoteile Internet Shop: 56 h, Vertragsmanager: 62 h. 58 Projekt- Verwalter Projekt "Autoteile Internet Shop" name Projekt ProjektbeteiligungVerwalter Projektbeteiligung aufwand Mitarbeiter "Frau Sauer" Mitarbeiter- Verwalter M itar be ite rVerwalter Projektbeteiligung erfassen() Mitarbeiter erfassen() M i ta r be i te r name Gesamtaufwand bestimmen() Wenn Sie der Überzeugung sind, dass das oben erstellte Modell dieses Ergeb- nis liefern kann, dann haben Sie jetzt gerade den Teil der Lösung modelliert, der dafür sorgt, dass unser Prüfbeispiel funktioniert. Da wir dabei bereits vom Prüfbeispiel abstrahiert haben, können wir prüfen, ob die Anforderung mit diesem Modellausschnitt grundsätzlich erfüllt wird. Wir können offene Fragen stellen oder weitere Prüfbeispiele hinzuziehen. Insbesondere erfolgte die Mo- dellierung auf dem natürlichen Weg, denn wir zu Anfang dieses Kapitels im Abschnitt 3.1 beschrieben haben. Wenn Sie mit dem Modell noch nicht zu- frieden sind, werden Sie demnach jetzt beginnen es zu verändern und erneut zu prüfen. Bis jetzt haben wir beim Modellieren so gut es geht vermieden die Fachbegrif- fe der objektorientierten Analyse, wie Klasse, Objekt, Instanz, Operation, Att- ribut oder Beziehung zu verwenden. Wir glauben, dass diese Begriffe das Er- lernen der Modellierung und die richtige Anwendung unnötig erschweren, denn diese Begriffe sind künstlich von Informatikern geprägt worden und ge- hören nicht zur Alltagssprache. Nach unser Erfahrung besteht die größte Hürde für Neulinge in der objektori- entierten Modellierung darin, die Darstellung von einzelnen Darsteller und den Verwaltern dieser Darsteller in einem einzigen Symbol zusammenzufassen: Abbildung 3.9: Weglassen der Verwalter Verhalten und Wissen der Verwalter sind jetzt unter der Sortenbezeichnung der Darsteller zu finden zur Abgrenzung wird ein Symbol verwendet (hier ein „$“). Schliesslich ist es üblich, die Erfassungsmöglichkeit für Darsteller nicht explizit zu erwähnen: Abbildung 3.10: Weglassen der Erfassungsmöglichkeit Abbildung 3.10 gibt nun das gesamte Prüfbeispiel in UML-Notation so wie- der, dass damit das Prüfbeispiel zumindestens im Gedankenspiel richtig durchgespielt werden kann. Dies ist eine stabile Grundlage für die weitere Modellierung. name Projekt Projektbeteiligung aufwand Ableitung des Modells aus den Anforderungen name Mitarbeiter Gesamtaufwand bestimmen() $Gesamtaufwand je Projekt auswerten() $Projekt erfassen() name Projekt $Projektbeteiligung erfassen() Projektbeteiligung aufwand $Mitarbeiter erfassen() Mitarbeiter name $Gesamtaufwand je Projekt auswerten() Gesamtaufwand bestimmen() 59 Vom Anforderungsprofil zum Modell Sichtenbildung Die konsequente Anwendung der Modellierung entlang von Anforderungen und Prüfbeispielen ermöglicht es, immer überschaubare Teile des Modells zu erstellen. Dazu werden Sichten verwendet. Um die Konsistenz der Sichten zu erhalten empfehlen wir dringend, ein Modellierungswerkzeug zu verwenden (siehe Abschnitt 6.2 „Werkzeugauswahl“). Die Sichten bieten für den Model- lierer jeweils einen Ausschnitt zur Bearbeitung an, während das Modellie- rungswerkzeug im Hintergrund die volle Komplexität des Gesamtmodells be- rücksichtigt und auf Unstimmigkeiten automatisch aufmerksam macht. Abbildung 3.11 zeigt prinzipiell wie eine Sicht eine einzelne Anforderung um- fasst, Abbildung 3.2 zeigt eine konkrete Sicht aus dem Projektverwaltuns- beispiel. AF 2.1 AF 2.3 AF 2.4 AF 2.2 AF 2.6 AF 2.x AF 2.5 Sicht 1 Klasse 1 Attribut 1 Operation 1() Klasse2 Beziehung Vererbung Klasse 3 Abbildung 3.11: Modellierung von Anforderungen in Sichten Durch das Modellieren von Anforderungen Sicht für Sicht gelingt es, schritt- weise das gesamte Anforderungsprofil als Modell zu erfassen. Das systemati- sche Vorgehen stellt sicher, dass keine Themen, Anforderungen und Prüfbei- spiele vergessen werden und sich alle Beteiligten im Modell zu Recht finden. Abbildung 3.12 zeigt wie schliesslich alle Themen des Anforderungsprofils durch das Gesamtmodell abgedeckt werden. Das Modell erfüllt in diesem Zu- stand prinzipiell alle gestellten Anforderungen. Es muss nun noch der Nach- weis erbracht werden, dass die aus dem Modell abgeleitete Realisierung eben- falls diese Eigenschaft hat. 60 Anforderungsprofil OOA-Modell Thema 1 Thema 2 Thema 3 Thema ... Sicht 2 Klasse 1 Sicht 1 Klasse 1 Attribut 1 Operation 1() Klasse2 Beziehung Einfach, kurz und klar - komplizierte Modelle sind falsch! Thema 4 Thema 5 Vererbung Vererbung Klasse 3 Sicht 3 Klasse2 Beziehung Klasse 3 Klasse4 3.4 Einfach, kurz und klar - komplizierte Modelle sind falsch! In [Roe94] „Einfach, kurz, klar - komplizierte OOA Modelle sind falsch!“ be- schreibt Martin Rösch wie leicht es in Softwarprojekten passieren kann, dass Modelle entstehen, die unverständlich sind. Der Inhalt der Modelle mag dabei durchaus richtig sein - die Unverständlichkeit an sich stellt bereits ein unak- zeptables Hindernis dar. Die Negativen Folgen der Unverständlichkeit entwi- ckeln sich dadurch, dass den Auftraggebern mit zunehmender Unverständlich- keit die Möglichkeit genommen wird, die Modelle auf ihre Richtigkeit hin zu prüfen. David Parnas beschreibt in [Par91] wie bei der Festlegung von Anfor- derungen für die sicherheitskritische Software eines Atomkraftwerkes auf formale Methoden gesetzt wurde. Die formale Vorgehensweise sollte die Be- weisbarkeit der Sicherheit der Software erreichen. Tatsächlich konnte nach- gewiesen werden, dass die Software der formalen Spezifikation entspricht. Die formale Spezifikation war jedoch in mathematischer Sprache verfasst. Das Prüfteam hat diese Spezifikation abgesegnet, ohne die Spezifikation zu lesen - denn nach einem kurzen Blick darauf sahen die Prüfer, dass es sich um für sie unverständliche Formeln handelte. Sie vertrauten daraufhin „blind“ auf die Richtigkeit. Parnas zeigte anschliessend auf, dass die Spezifikation voller Wi- dersprüche war. Klasse 3 Bez iehung Klasse2 Klasse4 Abbildung 3.12: Schrittweise Erfüllung aller Anforderungen im Modell 61 Vom Anforderungsprofil zum Modell # Die drei Psychologen Langer, Schulz v. Thun und Tausch haben die Verständ- lichkeit von Texten wissenschaftlich untersucht [Lan99]. Sie fassten alle we- sentlichen Texteigenschaften zusammen und gruppierten sie. Diese werden als: Merkmale der Verständlichkeit ! Einfachheit ! Kürze - Prägnanz ! Gliederung - Ordnung - Klarheit ! Anregende Zusätze bezeichnet. Diese Merkmale der Verständlichkeit lassen sich auf die Modellie- rung vollständig anwenden. ! Einfachheit Einfachheit bezieht sich auf die Form, nicht den Inhalt eines Modells und der beschreibenden Texte. Ein einfacher Sachverhalt kann kompliziert dargestellt werden, genauso wie es gelingen kann, einen komplizierten Sachverhalt ein- fach darzustellen. Die folgende Tabelle zeigt was Einfachheit im Gegensatz zur Kompliziertheit ausmacht: Einfachheit einfache Darstellung kurze, einfache Sätze bekannte Wörter unbekannte Fachbegriffe erklärt konkret anschaulich ! Kürze - Prägnanz Kompliziertheit komplizierte Darstellung lange, verschachtelte Sätze unbekannte Wörter unbekannte Fachbegriffe nicht erklärt abstrakt unanschaulich Stimmt das Verhältnis von Inhalt und Aufwand der Darstellung? Klarheit be- deutet das Wesentliche mit geringen Mitteln zu modellieren. Eine zu knappe Darstellung behindert das Verständnis. Eine weitscheifige mit Ausschmü- ckungen versehene Form lenkt vom eigentlich wichtigen Inhalt ab. Kürze - Prägnanz (zu) wenig Inhalt beschränkt auf das Notwendige gedrängt aufs Ziel konzentriert Weitschweifigkeit (zu) viel Inhalt viel Unnötiges breit abschweifend, ausschmückend 62 Erfolgsfaktor: Achten Sie auf die Verständlichkeit Ihrer Spezifikationen und Modelle. Die Abstraktionsfalle Kürze - Prägnanz Weitschweifigkeit knapp ausführlich ! Gliederung - Ordnung - Klarheit Eine gute Gliederung eines Modells erleichtert das Verstehen und Merken des Inhaltes. Insbesondere ist es auch leichter, nach einem bestimmten Sachverhalt zu suchen. Entscheidend für die Verständlichkeit der Gliederung ist der logi- sche Aufbau des Modells. Die Informationen werden in sinnvollen Zusam- menhängen präsentiert. Durch Hervorheben und Zusammenfassen wird Wich- tiges deutlich gemacht. Gliederung - Ordnung - Klarheit Gliederung in Sichten Gliederung in Gruppen folgerichtig gute Unterscheidung von Wesentlichem und Unwesentlichem der rote Faden bleibt sichtbar alles erscheint im richtigen Zusammenhang ! Anregende Zusätze Zusammenhanglosigkeit ungegliederte Gesamtsicht ungegliederter Haufen von Information zusammenhanglos, wirr schlechte Unterscheidung von Wesentlichem und Unwesentlichem man verliert oft den roten Faden alles geht durcheinander In der nüchternen Welt der Computerexperten fehlt dieses Merkmal der Ver- ständlichkeit oft. Es dient dazu den Betrachter zu animieren und anzuregen, damit der Spass an der Sache erhalten bleibt. Als anregende Zusätze eignen sich die persönliche Ansprache des Betrachters, Ausrufe, praktische Beispiele, Fragen zum Mitdenken, humoristiche Einlagen, Bilder, Animationen usw. Anregende Zusätze anregend interessant, bunt abwechslungsreich persönlich bewegt ohne anregende Zusätze nüchtern farblos, grau gleichbleibend neutral unpersönlich statisch 3.5 Die Abstraktionsfalle Schon 1997 schrieb Brooks in [Bro87]: „Seit fast 40 Jahren hat man die ‚au- tomatische Programmierung’ oder die Generierung eines Programms zur Lö- sung eines Problems aus der Beschreibung der Problemspezifikation vorherge- sehen oder darüber geschrieben ... kurz gesagt, automatische Programmierung war immer eine Umschreibung für dass Programmieren mit einer Sprache auf höherem Niveau als die bisher für den Programmierer verfügbare.“ 63 Vom Anforderungsprofil zum Modell Abbildung 3.13 Die Abstraktionsfalle Tatsächlich sind die größten Fortschritte der Softwarenentwicklung der wei- terentwicklung der Ausdrucksmöglichkeiten auf der rechten Seite der Brücke zu verdanken. Es wird scheinbar immer einfacher, dem Computer mitzuteilen, was er leisten soll. Die Vereinfachung ging dabei in der Vergangenheit immer mit einer Erhöhung des Abstraktionsgrades einher: ! Binärcode Das von-Neumann Prinzip ermöglichte es erstmals binären Programmcode wie Daten zu betrachten. Dies war die erste Abstraktion von der Maschine - Programme wurden nicht mehr durch Schaltereinstellungen oder festver- drahtete Schaltungen erzeugt, sondern wie Daten in die Maschine geladen. Dies erhöhte die Flexibilität von Programmen bereits erheblich. ! Assembler Mit einer Textdarstellung von Maschinenbefehlen unter Nutzung von Kür- zeln wie ADD, MOV und JMP wurde es möglich von der konkreten Ma- schine zu abstrahieren. Ein einmal in Assembler geschriebenes Programme konnte von nun an auf unterschiedlichen Maschinen (ähnlichen Typs) er- neut in Binärcode umgesetzt werden9. 9 IBM lernte schmerzlich, wie wichtig es ist, dass Assemblercode auf neuen Maschinen lauf- fähig bleibt. Heute leisten weltweit noch Milliarden von Assemblercodezeilen aktive Dienste, die über 30 Jahre alt sind. 64 ! Prozedurale Sprachen Die Idee der ersten prozeduralen Programmiersprachen war es, möglichst nahe an die geschriebene „natürliche Sprache“ heranzukommen. Satzfol- gen wie „COMPUTE DISCOUNT = DISCOUNT/100. DIVIDE 100 INTO PRICE. COMPUTE SALES = PRICE * QTY - (PRICE * QTY) * DISCOUNT. ADD SALES TO YTD-SALES.” konnten von nun an zur Programmierung herangezogen werden. ! Objektorientierte Sprachen Von nun an wird die Zusammenfassung von Daten und Funktionen zu Ob- jekten die Verhalten zeigen und Wissen haben ermöglicht. Die Objekte können sich gegenseitig Nachrichten senden und so kann durch Zusam- menarbeit von Objekten ein Problem gelöst werden. ! Modellierungsprachen Die Unified Modelling Language (UML) ist ein Beispiel für die Abstrakti- on von Objektorientierten Sprachen. Über die üblichen objektorientierten Sprachkonstrukte Kapselung, Vererbung, Abstraktion, Polymorphismus, und Klassifizierung hinaus werden weitere Konstrukte angeboten. Dazu gehört die Modellierung von Beziehungen sowie die Beschreibung von dy- namischem Verhalten10. ! Meta-Sprachen Um noch weiter zu abstrahieren muss die nächst höhere Ebene zur Abs- traktion genutzt werden - die Metaebene wird betreten. Dies ist zum Bei- spiel erforderlich, wenn Regelwerke umgesetzt werden sollen, die sich auf beliebige Objekte beziehen sollen. Nun ist es nur noch möglich mit einer Metasprache das Regelwerk zu beschreiben, denn die Objekte die später in den Regeln vorkommen sollen, sind ja noch gar nicht bekannt. ! Meta-Meta-Sprachen Wenn eine Meta-Sprachen Lösung noch nicht einfach genug ist, dann muss halt eine Meta-Meta-Sprache her usw. Und so besteht heute der Irrglaube, die weitere Erhöhung des Abstraktionsge- rades würde es einfacher machen, richtige Software zu erstellen. Abbildung 3.13 Die Abstraktionsfalle verdeutlich jedoch worin der Irrglaube besteht. Da die Abstraktion von der Seite der Maschine aus gedacht ist, wird es zwar möglich immer abstrakter zu spezifizieren, was die Maschine leisten soll. Schliesslich entfernt sich diese Beschreibung aber immer mehr von dem wie Menschen denken und fühlen, wenn lediglich weitere Abstraktion die Verein- fachung vorantreibt. Um entlang der Brücke in Richtung auf den Menschen „abzubiegen“ ist etwas anderes erforderlich. Dafür ist es zum Beispiel wichti- ger, Widersprüchlichkeiten aufzulösen, Entscheidungen voranzutreiben und die Anpassbarkeit an die Bedürfnisse einzelner Anwender zu ermöglichen. Abstraktion verhindert jedoch derartige Vielfalt und Uneindeutigkeit eher. 10 Der Nachteil von UML besteht darin, dass es keine verbindliche Umsetzung von diesem abstrakten Niveau auf die objektorientierten Programmiersprachen gibt. Die Abstraktionsfalle 65 Vom Anforderungsprofil zum Modell 3.6 Literatur [Boo94] G. Booch: Object-Oriented Analysis and Design with Applicati- ons, Addison-Wesley, 1994 Grady Booch ist einer der „drei Amigos“ die gemeinsam bei Rati- onal Software die UML entwickelt haben. Sein Buch ist einer der Klassiker zum Thema. [Bro87] F. P. Brooks, F.P: No Silver Bullet; Essence and Accidents of Software Engineering, Computer, April 1987. [Bro02] M. Broy, J. Siedersleben: Objektorientierte Programmierung und Softwareentwicklung - eine kritische Einschätzung, Infor- matik Spektrum, Band 25, Heft 1/2002, pp. 3-11 Dieser kritische Artikel zeigt die Grenzen des Ansatzes der Objekt- orientierung auf und warnt vor dem Irrglauben mit der Objektori- entierung sei der Weisheit letzter Schluss gefunden. [Brö00] P. Brössler, J. Siedersleben: Softwaretechnik - Praxiswissen für Software-Ingenieuere, Hanser, 2000 Sammlung von Aufsätzen von Mitarbeitern der Firma sd&m zu praxisrelevanten Themen des Softwareengineering. [Coa90] P. Coad, E. Yourdon: Object Oriented Analysis, Yourdon Press, 1990 Coad und Yourdon sind Pioniere auf dem Gebiet der Objektorien- tierung. Sie sind in der Lage mit einfachen Mitteln zu erklären, was Objektorientierung nutzt und wie Analyse auf dieser Basis funktio- niert. [Gla95] R. L. Glass: Software Creativity, Pearson Professional Education, 1995 [Jac92] I. Jacobson: Object-Oriented Software Engineering - A Use Case Driven Approach, acmPress/Addison-Wesley, 1992 Ivar Jacobson bringt als zweiter Amigo die Anwendungsfälle (Use Cases) als Gliederungsmittel in die Modellierung von objektorien- tierten Systemen ein. [Jäh02] S. Jähnichen, S. Herrmann: Was, bitte, bedeutet Objektorientie- rung?, Informatik Spektrum, Band 25, Heft 4/ 2002, pp. 266-276 Gegenrede zum Artikel von Broy und Siedersleben [Bro02] [Lan99] I. Langer, F. Schulz von Thun, R. Tausch: Sich verständlich aus- drücken, Reinhardt, 1999 Verständlichkeit der zur Dokumentation von Modellen verwendeten Sprache ist Grundvoraussetzung für die Verständlichkeit von Mo- 66 [Oes98] dellen - dieses Buch zeigt die Ergebnisse einer wissenschaftlichen Untersuchung zum Thema Verständlichkeit – natürlich besonders verständlich – auf. B. Oestereich: Objektorientierte Softwareentwicklung, Olden- burg, 1998 Standardwerk für die Einführung in die Objektorientierung. Beson- ders als Einstieg in das Thema geeignet. [Roe94] M. Rösch: Einfach, kurz, klar - komplizierte OOA-Modelle sind falsch! in Objektspektrum 04/94, SIGS Datacom, 1994 Dieser Artikel aus dem Jahr 1994 hat schon früh das Dilemma der Verständlichkeit von OOA-Modellen aufgezeigt. [Rum91] J. Rumbaugh, W. Premerlani, W. Blaha: Object-Oriented Mode- ling and Design, Prentice Hall, 1991 [Roe94b] Rumbaugh ist der dritte Amigo und dieses Buch sein Beitrag aus der Zeit vor UML. M. Rösch: ISO 9000: Qualität oder Zertifikat? in Computerwo- che 51/52, 1994 67 Literatur Vom Anforderungsprofil zum Modell 68 „Irren ist menschlich. Aber wenn man richtig Mist bauen will, braucht man einen Computer.“ Dan Rather, amerikanischer Fernsehreporter 4 Umsetzen 4 Vom Modell zum Code Mensch - - Ideen Wünsche Erwartungen Gefühle Prüfen Bits Maschine und Bytes 4.1 Umsetzen © BITPlan, 2000 Bei der Umsetzung des Modells in Code ist die wichtigste Entscheidung, wie- viel Sie selber machen wollen und was sie als fertige Lösung dazkaufen. 69 Wie? Was? Umsetzung Vom Modell zum Code Selber machen oder kaufen? Was sind die Entscheidungskriterien für selber machen oder kaufen? Wo be- komme ich die Software her, die genau meinen Wünschen entspricht? Der nächste Erfolgsfaktor ist ein Angriff auf den heiligen Gral so mancher Softwareentwickler. „Selber machen“ ist über Jahrzehnte die beliebteste Ant- wort gewesen. Wenn Softwareentwickler mit einer Lösung konfrontiert wer- den, die sie nicht selbst entwickelt haben, dann greift der Virus des „Not in- vented here Syndrom“ um sich. Rein wirtschaftlich betrachtet ist selber ent- wicklen inzwischen in den meisten Fällen die teuerste Variante. Manches Softwareunternehmen ist durch diesen Ansatz in den Ruin getrieben worden. Die Erkenntnis, dass Kaufen sinnvoller ist, setzt sich durch – auf dem ersten Platz unserer Umfrage ist der folgende Erfolgsfaktor zu finden: Im Gegensatz zur vollständigen Eigenentwicklung ist es heute möglich mit vorgefertigten Halbfabrikaten nach dem Baukastenprinzip eine Software zu- sammenzusetzen und zu erweitern. Die einsetzbaren Halbfabrikate sind: ! Frameworks Eine Sammlung von kooperierenden Klassen die für das spezielle Problem angepasst und erweitert werden müssen. Das Framework gibt eine leer Hülle vor, die aber in sich bereits stabil ist. Ein Framework dient als Basis für eine Anwendung. ! Komponenten Fertige Teillösungen die in die eigene Lösung eingebunden werden können und ebenfalls anpassbar oder erweiterbar sind. Fachliche Komponenten lie- fern Bausteine für ihr Fachgebiet. Technische Komponenten sorgen dafür, dass ihre Lösung in der vorgesehenen Computerumgebung lauffähig ist. ! Klassenbibliotheken Allgemeine Sammlung von Basisklassen, insbesondere für die Lösung von technischen Standardprogrammen. Ein sehr bekanntes und beliebtes Bei- spiel ist die zum Java Development Kit (JDK) gehörende Klassenbiblio- thek. Für den Einsatz solcher Zukaufteile spricht die schnelle Verfügbarkeit und die hohe Qualität der Komponenten. Zudem werden die Komponennten vom An- bieter weiterentwickelt und dieser ist Spezialist für das Thema. Wir stark diese Vorteile wiegen hängt von der Wahl des Anbieters, dem Grad der Standardi- sierung der Technologie und der Durchsetzung am Markt ab. Erfolgsfaktor: Der Einsatz von Frameworks, Komponenten und Klassenbibliotheken verkürzt ihre Entwicklungszeit und macht Ihre Lösung zukunftssicherer. 70 Die Anbieter von Frameworks, Komponenten und Klassenbibliotheken haben erkannt wie wichtig es ist, die eigene Lösung als Standard zu positionieren und den Käufern klar zu machen, dass diese Lösung über Jahre verfügbar sein wird und gepflegt wird. Die grossen IT-Firmen Microsoft, IBM, Sun, Oracle usw. führen dazu einen Balanceakt zwischen der Verfolgung eigener Interes- sen im Konkurrenzkampf und dem Überzeugen der Käufer bzgl. dieser Punkte auf. In unseren Projekten haben wir mit Komponenten schon so einige Überra- schungen erlebt - aber schliesslich stellte sich dennoch der Vorteil von Kom- ponenten ein: ! In der Klasse java.sql.ResultSet für den Zugriff auf SQL- Datenbanken von Java gibt es die Methoden moveToInsertRow und insertRow(), mit denen neue Einträge in eine Tabelle geschrieben werden können. Diese Methoden funktionierten mit den standardmässig ausgelieferten JDBC/ODBC-Bridge Klassen nicht. Die Lösung brachte die gleiche Komponente von einem Drittanbieter. ! Eine Komponente zum versenden von Massenemails funktionierte plötz- lich nicht mehr mit der neuesten Version der Datenbank zusammen. Eine neue Version des Herstellers stand aber bereits zur Verfügung - diese hatte zu dem noch neue nützliche Funktionen. Hr.Angelet und Hr. Teschner stimmen sich über die XML-Schnittstelle für das Projektverwaltungssystem ab. Hr. Teschner schlägt vor, einen XML-Parser selbst zu schreiben, da ja nur ein Bruchteil der Funktionalität eines XML- Parsergs gebraucht würde und dies sicherlich schneller ginge, als sich erst in die XML-Technologie einzuarbeiten. Hr. Angelet berichtet von seinen guten Erfah- rungen mit den XML-Komponenten Xalan und Xerces in einem anderen Projekt - dort war es mit nur wenigen Zeilen Java Code gelungen die Java-Objekte aus einer XML-Datei heraus zu lesen und wieder zu schreiben. Als weiteres Argu- ment führt Hr. Teschner an, dass in den neueren JDK-Versionen die XML- Unterstützung bereits enthalten ist und somit zum Java-Standard gehört. Er ü- berzeugt Hr. Teschner schliesslich, möglichst wenig selbst zu entwickeln. Softwarekomponenten sind am leichtesten im Internet zu finden. Die Suche über Suchmaschinen ist dabei immer noch effektiver als bei speziellen Kom- ponentenbörsen nachzuschlagen. Bei einigen Komponentenanbietern und Standardisierungsgremien hat es sich bereits eingebürgert, dass die Prüfbei- spiele bereits mitgeliefert werden. Dies ist sehr zu begrüssen und zum Teil bitter nötig, um Inkompatibilitäten zu vermeiden. Die J2EE Spezifikation ent- hält zum Beispiel eine „conformance suite“, die diesem Anspruch gerecht wird. 71 Umsetzen Vom Modell zum Code Teile und Herrsche Das Prinzip der Modularisierung „teile und herrsche“ wurde in der Informatik schon früh eingesetzt, um komplexe Systeme erstellen zu können. Module kapseln Daten oder Verhalten und sind damit Vorläufer der Objekte. 1971 führte David Parnas zusätzlich das Geheimnisprinzip „Information Hiding“ ein. Er zeigte auf, dass zwischen den Modulen zu oft unsichtbare Abhängig- keiten bestehen, wenn nicht sichergestellt wird, dass die „Innereien“ eines Moduls verborgen werden. Daher wird zwischen der Spezfikation eines Mo- duls – seiner Schnittstelle und der Realisierung des Moduls unterschieden. Ein Modul kann somit durch eine andereres Modul mit gleicher Schnittstelle er- setzt werden. Das Prinzip der Modularisierung erreichte in unserer Umfrage den 6. ten Platz: Wir empfehlen Ihnen dringend, nicht auf Modularisierung nur deswegen zu verzichten, weil dieses Prinzip schon lange bekannt und damit „ein alter Hut“ ist. Die richtige Modularisierung zu erreichen bedeute nicht nur das Problem zu zerlegen, sondern auch eine Zerlegung zu finden, die möglichst optimal ist. Diese Aufgabe ist gar nicht so leicht: ! Wenn Sie wenig Module bilden können Sie die Vorteile der Modularisie- rung nicht geniessen, die einzelnen Probleme bleiben zu gross, die Bin- dung in den Modulen ist zu gering. ! Wenn Sie viele Module bilden, bekommen Sie sehr viele Schnittstellen - der Kommunikationsaufwand zwischen den Modulen und die Pflege der Module wird aufwendig, die Kopplung zwischen den Modulen ist zu gross. Regeln für die richtige Balance zwischen Bindung (cohesion) und Kopplung (coupling) von Modulen zu finden ist eine Wissenschaft für sich [Dar02]. Mo- dule sollen möglichst unabhängig voneinander sein und dennoch die Aufgaben untereinander aufteilen. Unserer Erfahrung nach sind vor allem die Unterschiede in den Teams bzgl. der Neigung zur Modularisierung sehr hoch. Einige Mitarbeiter zerlegen Prob- leme in kleinste Schnipsel, bevor diese gelöst werden, andere bauen monströs große Funktionen, die über riesige Parameterlisten gesteuert werden müssen. Diesen Unterschieden läßt sich am Besten entgegenwirken, wenn die Ergeb- nisse gemeinsam erstellt werden bzw. die Bearbeitung rotiert. 72 Erfolgsfaktor: Zerlegen Sie Problem und Lösung schrittweise in kleinere von ein- ander möglichst unabhängige Teile. Mit dem Einsatz von Werkzeugen zur Komplexitätsmessung haben wir keine Erfahrungen gemacht - es ist jedoch schade, dass in den heutigen integrierten Entwicklungsumgebungen diese Funktion nicht als Standard enthalten ist - dann würde sie sicherlich eher ihren Nutzen entfalten. Trennung von Fachlichkeit, Design und Architektur „Der Alptraum jeden Programmierers“ so wird in [Sie00] Software beschrie- ben, in der sich technische Probleme mit Anwendungsproblemen vermischen. Die Trennung der Lösung von fachlichen und technischen Themen erlaubt es die Lösungen unabhängig voneinander wiederzuverwenden. Lösungen von fachliche Themen werden häufig in unterschiedlichen technischen Zusam- menhängen benötigt. Ein Beispiel dafür ist die „Vertriebskanalunabhängig- keit“. Egal welche technische Infrastruktur ein Unternehmenspartner nutzt, ob Arbeitsplatzcomputer, Internet, Handy oder einen speziellen Automaten - die gleiche fachliche Funktion soll bereitstehen. Gelingt es nicht, auf die gleiche Lösung zurückzugreifen, entstehen oft Unstimmigkeiten - der Fahrkartenau- tomat nennt einen anderen Preis als die Auskunft - das Internet nennt einen Dritten - der Kunde ist verwirrt. Das Kreditangebot des Sachbearbeiters stimmt nicht mit den später zur Unterschrift vorliegenden Vertragsunterlagen überein - und dies wieder nicht mit dem Ergebnis des Kreditrechners auf der Werbe-CD der Bank. Weitere Motivation für die Trennung von Fachlichkeit und Technik ist das unterschiedliche Tempo mit dem sich die Anforderungen an beide Bereiche ändern. Technische Themen, wie Datenhaltung, Netzwerk, Darstellung, Be- triebssystem usw. ändern sich im Abstand von ein bis zwei Jahren pro Thema. Wenn also nur vier dieser Themen gleichzeitig in der Technik zu berücksich- tigen sind, kommt es bereits alle drei bis sechs Monate zu Änderungen. Fach- liche Themen können je nach Anwendungsgebiet sehr stabil sein - denken Sie z.B. an Lebensversicherungs- oder Darlehensverträge. Bei solchen Verträgen muss die Software auch 30 Jahre nach Vertragsabschluss noch korrekt entlang der ursprünglich vereinbarten Bedingungen arbeiten. Optimal ist es, wenn existierende technische Lösungen sich mit neuen fachli- chen Lösungen kombinieren lassen. Abbildung 4.1 zeigt wie drei fachliche und vier technische Lösungen miteinander verknüpft werden. Allgemein gilt, dass bei der Trennung von N fachlichen und M technischen Problem n+m Lö- sungen erforderlich sind. Umsetzen Erfolgsfaktor: Lösen Sie technische und fachliche Probleme getrennt voneinander. 73 Vom Modell zum Code Mitabeiter Kunde Projekt Anzeige Speicherung Abbildung 4.1: Kombination von 3 fachlichen und 4 technischen Lösungen (N+M) Werden technische und fachliche Probleme jedoch gemischt, sind N x M Lö- sungen erforderlich (siehe Abbildung 4.2). Zugriff Ausdruck Mitarbeiter- Anzeige Mitarbeiter- Speicherung Mitarbeiter- Zugriff Mitarbeiter- Ausdruck Kunden- Anzeige Kunden- Speicherung Kunden- Zugriff Kunden- Ausdruck Projekt- Anzeige Projekt- Speicherung Abbildung 4.2: Kombination von 3 fachlichen und 4 technischen Lösungen (NxM) Die folgende Tabelle stellt die beiden Ansätze anhand einiger Beispielzahlen für die Anzahl fachlicher und technischer Probleme gegenüber: 4 3 7 12 1,7 Projekt- Zugriff Projekt- Ausdruck N Anzahl fachlicher Probleme M Anzahl technischer Probleme Trennung Fachlichkeit/ Technik N+M Mischung Fachlichkeit/ Technik Mehraufwand für Mischung als Faktor 74 Umsetzen 20 3 23 60 2,6 20 6 26 120 4,6 40 10 50 400 8,0 Schon bei einem Projekt mittlerer Größe, bei dem 40 fachliche Probleme mit 10 technischen Problemen zu kombinieren sind, ist der Aufwand bei der Mi- schung der Lösungen 8 mal so hoch. Ein Beispiel für einen guten Ansatz für die Trennung von Fachlichkeit und Technik liefert das Interface-Konzept der Programmiersprache Java11. Mit Java-Interfaces ist es möglich, die Deklaration der Lösung von der Implemen- tierung zu trennen.: } Wenn im gesamten Code strikt „gegen“ Interfaces programmiert wird, dann kann nachträglich die Lösung verändert oder ausgetauscht werden. Die Code- teile, welche die Lösung verwenden können dabei völlig unverändert bleiben, solange die Beschreibung der Lösung – das Interface – sich nicht ändert. Eine rigorose Trennung von Fachlichkeit und Technik erlaubt der Model Driven Architecture (MDA) - Ansatz (siehe Abschnitt 6.4. „Generierung“). Richtiger Entwurf Ein guter Entwurf ist einfach, kurz, klar und damit verständlich. Auf Basis des Modells in der Sprache des Auftraggebers gilt es nun einen Entwurf in der Sprache des Computers und der Programmierer zu erstellen. Es ist äußerst schwierig, auf Anhieb einen richtigen und tragfähigen Entwurf zu gestalten. Bei der Lösung von neuen und unbekannten Themen sind viele Randbedin- gungen zu beachten und ein Teil des Systems wirkt mit vielen anderen zu- sammen. Es hat sich gezeigt, dass bewährte Lösungsstrategien für wiederkeh- rende Probleme zu immer ähnlichen Entwurfsmustern führen. Wenn Sie diese bekannten Muster nutzen, können Sie sich auf die Anwend- barkeit und Austauschbarkeit der Lösung weit mehr verlassen, als wenn Sie eine eigenen speziellen Ansatz erfinden. 11 Die CORBA (Common Object Request Broker Architecture) bietet ebenfalls diese Mög- lichkeit. public interface Projekt implements Anzeige, Speicherung, Zugriff, Ausdruck { Erfolgsfaktor: Vereinfachen und standardisieren Sie Ihre Entwürfe durch die Verwendung von Entwurfsmustern. 75 Vom Modell zum Code Solche Entwurfsmuster werden inzwischen unter standardisierten Namen mit einheitlichen (englischen) Bezeichnungen für ihre Elemente verwendet. Bei- spielsweise sieht das „Iterator“ - Entwurfsmuster vor (siehe Abbildung 4.3), dass es eine Möglichkeit gibt, das nächste Element eines Iterators mit „next“ zu erhalten. Abbildung 4.3 Das „Iterator“ Entwurfsmuster Der klassische Katalog der Entwurfsmuster ist [Gam95] - die dort aufgezähl- ten Entwurfsmuster haben inzwischen Einzug in viele Frameworks und Klas- senbibliotheken gefunden. Die Java-Klassenbibliothek nutzt zum Beispiel mit jeder neuen Version mehr dieser Muster. Entwurfsmuster sind keine fertigen Lösung - sie sind lediglich Beschreibun- gen eines Lösungswegs. Bei der Verwendung von Entwurfsmustern ergeben sich folgende Fragen: ! Wie finde ich ein Entwurfsmuster für das vorliegende Problem bzw. wie erfahre ich davon, dass es ein Entwurfsmuster gibt? ! Wenn ich ein Entwurfsmuster gefunden habe, wie komme ich von diesem Muster zur fertigen Lösung? Der Einsatz von Entwurfsmustern erfordert Erfahrung. Der erste Schritt dazu, ist, die bekanntesten Entwurfsmuster kennenzulernen und auszuprobieren. Da- zu müssen Sie erneut das „Not invented here“ - Syndrom bekämpfen. Mit zu- nehmender Übung wird es Ihnen immer häufiger gelingen, zu einem Problem die passenden Entwurfsmuster auszuwählen. Um daraus eine komplette Lö- sung zu machen können Sie sich entweder eines Generators bedienen oder das Muster manuell mit Inhalt füllen. Technischer Durchstich Technik hat Ihre Tücken! In Softwareprojekten sorgt die Technik unserer Er- fahrung für die größte Unsicherheit und Instabiliät. Die Ursache liegt darin, dass die Technik von vielen verschiedenen Lieferanten geliefert wird. Sich in schneller Folge änderde Produkten mit vielen Querabhängigkeiten dienen als Infrastruktur für die eigentlich zu realisierende Software. Iterator first() next() is done() current Item() 76 Hr. Anglet hat gerade die neueste Version des XML-Adapters der Datenbank aus dem Internet geladen. Er will damit den Export bestehender PVW-Daten in das neue System ausprobieren. Schon die Installation scheitert jämmerlich. Das Installationsprogramm fordert ihn auf Servicepack 3 des Betriebssystems zu in- stallieren. Nachdem er 120 MByte aus dem Internet geladen uns installiert hat, wird er als Nächstes darauf aufmerksam gemacht, dass sein Internet-Browser ebenfalls mindestens Version 5.5 Servicepack 2 braucht. Weitere 20 MByte Download sind erforderlich - die Installation dauert noch einmal eine Stunde. Als die XML-Adapter-Software installiert ist, liest er in den Release-Notes, dass er unbedingt noch die Patches P437290 und P448859 für die Datenbank- installieren soll und die Hinweise dazu zu beachten sind. Ob die Produkte der verschiedenen Hersteller tatsächlich Ihren Ansprüchen genügen, alle Funktionen wie dokumentiert oder in der Werbung angepriesen funktionieren ist nicht sichergestellt. Die Situation ist um so kritischer, je we- niger Erfahrung mit den technischen Komponenten aus anderen Projekten vor- liegt. Gerade bei innovativen Projekten werden Sie in der Regel neue Kompo- nenten ausprobieren müssen. Wir empfehlen Ihnen einen „technischen Durchstich“ durchzuführen. Dazu dient eine minimaler Ausschnitt der Fachlichkeit, der so als Prototyp realisiert wird, dass zumindestens die wichtigsten technischen Komponenten durch die- se Lösung beansprucht werden. Die Erfahrungen, die sie mit dem Durchstich machen ermöglichen Ihnen besser zu beurteilen, ob das Gesamtsystem später in der beabsichtigen technischen Umgebung lauffähig sein wird. Fachliche Prototypen Fachliche !!! 4.2 Kurze Entwicklungszyklen Erst testen dann codieren 4.3 Abnahme und Einführung Kurze Entwicklungszyklen 77 Vom Modell zum Code 4.4 Literatur [Dar02] [Gam95] [Knu97] D. P. Darcy, C. F. Kemerer: Software Complexity: Toward a Unified Theory of Coupling and Cohesion Fall Workshop 2002, Management Information Systems Research Center, Carlson School of Management, University of Minnesota http://misrc.umn.edu/workshop/spring2002/Darcy_020802.pdf E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns - Elements of Reusable Object-Oriented Software, Addison- Wesley, 1995 Standardwerk, das die bekanntesten Entwurfsmuster aufzählt und erläutert. D. E. Knuth: The Art of Computer Programming Volume 1 - Volume 3, Addison-Wesley, 1997 Klassisches voluminöses Werk, das die Grundlagen von Algorith- men und effizienten Lösungen für Standardprobleme beleuchtet: Vol 1: Sorting and Searching, Vol 2: Seminumerical Algorithms, Vol 3: Fundamental Algorithms. Die meisten der vorgestellten Al- gorithmen werden heute in Klassenbibliotheken, wie z.B. der Java- Klassenbibliothek angeboten. Hier erfährt man unter anderem de- tailliert, wie und warum ein Hashalgorithmus funktioniert (Vol 1. pp 514-558). J. Siedersleben, E. Denert: Wie baut man Informationssysteme? Informatik Spektrum, Band 23, Heft 4/2000, pp. 247-257 http://www-st.inf.tu-dresden.de/hs/Vortraege/Thema5.pdf Vorstellung der Originalpapier von David Parnas zum Thema Mo- dularisierung Kurzweilige Beschreibung von David Parnas selbst, wie er auf das Information Hiding gekommen ist und wie dies noch heute Bedeu- tung behält. T. Winograd: Bringing Design to Software, acmPress/Addison- Wesley, 1996 Sehr anregende Sammlung von Aufsätzen zum Thema Softwarede- sign mit vielen Bezügen zum Design in anderen Fachgebieten. [Sie00] [Url3] [Url6] [Win96] 78 5 Änderung, Wartung, Pflege 5.1 Schrittweises Vorgehen !!! Bezug auf CSMR Konferenz in Budapest 5.2 Fehlermeldungen und Änderungswünsche Schrittweises Vorgehen 5 Es gibt grundsätzlich drei Arten von Rückmeldungen, die vom Anwender Ih- rer Softwarelösung an Sie herangetragen werden: ! Änderungswünsche ! Fehlermeldungen ! Bitten um Hilfestellung Die Kontaktaufnahme kann dabei auf den unterschiedlichsten Wegen erfolgen z.B. per Telefon, E-Mail, Fax oder Brief. Die Rückmeldung gelangt vielleicht nicht direkt zu Ihnen sondern indirekt über Ihre Servicemitarbeiter, den Ver- trieb, Partner oder andere Kunden. 79 Änderung, Wartung, Pflege ! Änderungwünsche werden unter der Kategorie „Changerequest“ mit der Abkürzung CR ge- führt. Sie betreffen Wünsche des Kunden, die über die zugesagten Eigen- schaften der bisherigen Software hinausgehen. Ein Änderungswunsch kann vom Hersteller der Software angenommen, zurückgestellt oder abgelehnt werden. Bei Auftragssoftware muss der Auftraggeber für Änderungwün- sche bezahlen. Ein Produktkunde muss darauf warten, dass der Ände- rungswunsch im Rahmen einer der nächsten Produktversionen umgesetzt wird. ! Fehlermeldungen werden unter der Kategorie „Bugreport“ mit der Abkürzung BR geführt. Ein Fehler ist eine Abweichung des Verhaltens der Software von zugesag- ten Eigenschaften. Bei Fehlermeldungen liegen vom Anwender oft nicht genug Informationen vor, um eindeutig die Ursache feststellen zu können. Daher gehören zu den Fehlermeldungen auch vermutete Fehler – bei denen sich später herausstellen kann, dass es sich in Wirklichkeit um einen Ände- rungwunch oder eine Bitte um Hilfestellung handelt. ! Bitten um Hilfestellung werden unter der Kategorie „Supportrequest“ mit der Abkürzung SR ge- führt. Jede Meldung des Kunden, die keine Fehlermeldung oder Ände- rungwunsch darstellt wird hier eingeordnet. Typisch für diese Kategorie sind Fragen bzgl. der Installation, Konfiguration und Bedienung der Soft- ware. Die Zufriedenheit Ihres Kunden mit Ihner Software hängt sehr stark davon wie Sie mit seinen Rückmeldungen umgehen. Das Wichtigste ist, dass sich Ihr Kunde wahr- und ernstgenommen füllt. Die erste Voraussetzung dafür ist, dass er eine „Quittung“ für seinen Kontakt erhält. Darin sollte enthalten sein ! Wann der Kunde sich gemeldet hat ! Mit welcher Aussage ! In welcher Kategorie Sie die Aussage eingeordnet haben (BR/CR/SR) Damit Sie den Überblick behalten und Nichts in Vergessenheit gerät, sollten Sie den folgenden Erfolgsfaktor beherzigen: Wir empfehlen Ihnen ein Werkzeug für diesen Zweck einzusetzen. Praktisch alle gängigen Konfigurationsmanagement-Werkzeuge haben geeignete Ergän- zungen (siehe Abschnitt 6.3 „Einzelteile und Versionen“). Es gibt aber auch frei verfügbare Lösungen wie z.B. „Bugzilla“ [Url4]. 80 Erfolgsfaktor: Verfolgen Sie die Fehlermeldungen, Änderungswünsche und Bitten um Hilfe Ihrer Anwender systematisch. 5.3 Literatur Literatur [CSM02] [Rad94] [Url4] 6th European Conference on Software Maintenance and Reengineering (CSMR 2002) 11–13 March 2002 - Budapest, IEEE, 2002 D. Radin: Building a Successful Software Business, O’Reilly, 1994 Alles was Sie wissen müssen, wenn Sie eine Softwarefirma gründen und betreiben wollen. Vom Marketing bis zur Kundenunterstützung finden Sie hier viele Tipps mit guten konkreten Beispielen. http://www.bugzilla.org/ Opensource - Fehlerverfolgungssystem. 81 Änderung, Wartung, Pflege 82 "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." - IBM maintenance manual, 1925 6 Ohne Computer unterstütze systematische Softwareentwicklung (CASE) ist heute kein Softwareprojekt mehr denkbar. Integrierte Entwicklungsumgebun- gen (IDE) sind inzwischen Standard. Wie gut sind jedoch die einzelnen Werkzeuge in der Kette von Aktivitäten miteinander verbunden? Wie lassen sich einmal erzielte Ergebnisse durchgän- gig weiter nutzen? Wie arbeiten die für Softwareentwicklung verwendeten Werkzeuge mit den übrigen Programmen am Arbeitsplatzcomputer zusam- men? 6.1 Arbeitsumgebung Was brauchen Sie für die Arbeitsumgebung in einem Softwareprojekt? Die Umgebung sollte adäquat und standardisiert sein. Sogen Sie für eine adäquate Umgebung. Wir haben oft erlebt, dass in den Pro- jekten gerade an den preiswerten Werkzeugen und an einfachen Arbeitsmit- teln, wie Büchern, Computern und Druckern gespart wird. Die Personalkosten sind im Verhältnis um ein vielfaches höher. Sparen rechnet sich hier betriebs- wirtschaftlich nicht. Vermeiden Sie Medienbrüche! Das Umformatieren von Ergebnissen von ei- nem Werkzeug auf ein anderes ist mit Zeitaufwand und meistens sogar mit 6 Infrastruktur und Werkzeuge Arbeitsumgebung 83 Infrastruktur und Werkzeuge Verlust von Inhalten verbunden. Zudem läßt wird dadurch die Möglichkeit der automatischen Verknüpfung von Ergebnissen durchbrochen. Mit dem Arbeitsplatz und der Arbeitsplatzaustattung der Projektmitarbeiter steht und fällt ihre Leistungsfähigkeit- und bereitschaft. Die ganze Bandbreite der Leistung von 0 bis 100% ist über die Eigenschaften des Arbeitsplatzes be- einflussbar. Geben Sie einem Mitarbeiter keinen eigenen Platz, keinen oder einen schlecht funktionierenden Computer und lassen Sie ihn „Mädchen für alles“ sein und von seiner Arbeitskraft wird fast nichts übrig bleiben. Im fol- genden geben wir einige Tipps, wie sie nahe an die 100% kommen können. Wir empfehlen Ihnen die Investitionen für unsere Vorschläge im Verhältnis zu den Personalkosten durchzukalkulieren - sie werden überrascht sein wie die Verhältnisse liegen. Ein Beispiel dazu: Bürofläche macht in den Organisatio- nen etwa 3% der Kosten aus, Personalkosten mehr als die Hälfte. Tom De Marco hat in „Peopleware“ [DeM99] nachgewiesen, dass die Arbeitsplatzaus- stattung jedoch massiv auf die Produktivität der Softwareentwickler wirkt. Eine Einsparung von 0,5% kann also leicht 5% „versteckte Kosten“ erzeugen. Umgekehrt kann eine Investition von zusätzlichen 0,5% genauso leicht 5% „versteckte Produktivität“ freisetzen. Im folgenden finden Sie einige Tipps, wie mit absolut gesehen geringen Investitionen die Arbeitsplatzausstattung verbessert werden kann. Arbeitsplatz Vorschläge, wie die Arbeitsplätze angeordnet sein können, finden Sie bei [Coc01]. Wir gehen hier von Einzelarbeitsplätzen unabhängig von der Größe und Aufteilung der zugehörigen Räume aus: ! Mindestens gebraucht wird ein Computergerechter Arbeitsplatz mit ent- sprechendem Tisch, Stuhl und Beleuchtung. Besser sind drei Schreibtische - einer als Computerarbeitsplatz, einer zum Schreiben und einer zum Experimentieren/Ablegen von halbfertigen Ergebnissen. ! Whiteboards (im Gruppenraum mit Kopierfunktion), alternativ Whitebo- ard/Flipchart mit Digitalkamera ! Telefon/Telefonanlage Wichtig sind Funktionen, die es ermöglichen zeitweise ungestört zu arbei- ten, also Rufweiterleitung, Mailboxfunktion, Anzeige der Rufnummer / des Namens des Anrufers im Display bevor abgenommen wird. ! Kaffeeküche Es darf natürlich auch eine Teeküche sein. Da wo es zu Essen- und zu 84 Erfolgsfaktor: Kümmern Sie sich rechtzeitig um eine adäquate und standardisierte Infrastruktur/Arbeitsumgebung für Ihr Softwareprojekt. Trinken gibt ist der natürliche Treffpunkt der Projektbeteiligten. Dieser Be- reich sollte so gestaltet sein, das mehr möglich ist als nur das Zubereiten der Überlebensration. ! Infrastruktur für Post usw. Was müssen die Mitarbeiter nicht unbedingt selbst machen? Post eintüten und frankieren? Büromaterial beschaffen? Manche Organisationen sorgen dafür, dass die Mitarbeiter private Besorgungen nicht selbst machen müs- sen, in der Hoffnung das Mitarbeiter für solche Dinge ihre Arbeit nicht un- terbrechen brauchen. Arbeitsplatzausstattung Die folgende Ausstattungsliste erhebt keinen Anspruch auf Vollständigkeit, zeigt aber wichtige Punkte auf, die an einem Softwareentwicklungsarbeitsplatz vorhanden sein sollten, um effizient arbeiten zu können12: ! Adäquater Arbeitsplatzcomputer Steht hier an erster Stelle, da in vielen Projekten noch unsinnigerweise ge- nau hier gespart wird. Gute Rechner kosten heute weniger als eine Ent- wicklerwoche. Schlechte Rechner kosten so manches Projekt den Erfolg. ! Drucker/Fotokopierer Ein schneller und guter Drucker sowie ein Fotokopierer mit Einzelblattein- zug, Sortier- und Heftfunktion muss mit wenigen Schritten erreichbar sein. ! Dokumentation Werkzeuge zur Textverarbeitung, Tabellenkalkulation, und Präsentation sowie einfache Datenbankerstellung sollten an jedem Arbeitplatz vorhan- den sein. Ein einheitliches Office-Softwarepaket wird diesem Anspruch be- reits gerecht. ! Editor Ein eigenständiger guter Editor neben der später noch genannten integrier- ten Entwicklungsumgebung (IDE) ist Gold wert und kostet im Verhältnis wenig. Größtes Hindernis ist die Einigung auf einen Standard - den gerade im Bereich Editoren entwickeln so manche Entwickler ihre Vorlieben. ! Screen Painter/Prototyping Minimum ist hier der Zugriff auf eine Möglichkeit zur digitalen Erfassung von Handzeichnungen. Ein Screenpainter gehört ansonsten heute gewöhn- lich zur IDE dazu. ! Compiler Gehört heute gewöhnlich zur IDE. ! Debugger Gehört heute gewöhnlich zur IDE. 12 Ausnahmesweise verwenden wir hier die üblichen Begriffe aus dem Englischen Arbeitsumgebung 85 Infrastruktur und Werkzeuge ! Anforderungsaufnahme Bei kleinen Projekten wird hier kein spezifisches Werkzeug benötigt - dann reicht die Textverarbeitung bzw. zur systematischen Erfassung die Datenbank oder das Projektdiskussionsforum. Für größere Projekte ist es sinnvoll, dass die an der Anforderungsaufnahme beteiligten Mitarbeiter, Werkzeuge zur Geschäftsprozessanalyse und zur Anforderungsaufnahme an ihrem Arbeitsplatz vorfinden ! Modellierung Bei kleineren Projekten genügt ein „Malwerkzeug“, das auch Modellieren kann. In größeren Projekten sind Werkzeuge zur Datenmodellierung, Funktionsmodellierung bzw. objektorientierten Modellierung sinnvoll. ! Konfiguration Management Auf das Thema Konfiguration Management gehen wir im Abschnitt 6.3 „Einzelteile und Versionen“ noch detailliert ein. Zur Arbeitsplatzausstat- tung der Entwickler gehört der Zugriff auf mindestens das eigentliche Ver- sionsmanagement sowie ein Werkzeug zum Nachverfolgen von Fehlern, Änderungswünschen und Supportanfragen der Kunden/Auftraggeber. Zu- dem wird ein Build-Management-Werkzeug benötigt. ! Testen Werkzeuge für das Testen sind in drei Bereichen sinnvoll: Unit Test, Reg- ressionstest und Performancetest. ! Projektmanagement Für kleinere Projekt genügt sicherlich eine Tabellenkalkulation oder das Projektdiskussionsforum - für größere Projekte ist eine eigene Softwarelö- sung sinnvoll. ! Zusammenarbeit Für die Zusammenarbeit ist zunächst mal der Zugang zu allen Papierdo- kumenten des Projektes erforderlich, d.h. zu den Projektunterlagen, den Büchern und Handbüchern zum Thema. Beim Internet-Zugang mit E-Mail, Web und News-Groups lohnt sich ähnlich wie oben beim Arbeitsplatz- computer erwähnt das Sparen nicht. Die Themen Viren- und Datenschutz sollte jedoch auf jeden Fall gelöst sein. Ein Projekttagebuch/Entwicklerforum dient dem Austausch von informel- len Ergebnissen, Ideen, Vorschlägen und tagesaktuellen Informations- schnipseln, die sonst verloren gehen würden. Ein Kunden-Forum dient dazu, dass Kunden neben dem formellen Weg über Änderungwünsche, Fehlermeldungen und Support-Anfragen ebenfalls ein informelles Forum erhalten. ! Utility-Sammlung Entwickler auf Unix-Betriebssysteme haben hier die Nase vorn - dort sind kleinen „Helferlein“ zu dutzenden installiert. In anderen Umgebungen lohnt es sich Scriptsprachen wie awk/perl/python zur Verfügung zu haben, um Aufgaben zu automatisieren, die sonst mühsam mit der Hand erledigt 86 oder aufwendig mit „grossen“ Programmiersprachen gelöst werden müss- ten. ! Verbindung der Werkzeuge/IDE Der Abdeckungsbereich für integegrierte Entwicklungsumgebungen wird immer größer. Vom Grundumfang Editor/Compiler/Debugger/Screen- Painter aus sind die Einbindungen von Modellierung, Anforderungsauf- nahme, Änderungsverfolgung, Versionsmanagement, Projektverwaltung, und Testwerkzeug immer häufiger zu finden. Lediglich die Güte der An- bindung unterscheidet sich. Dabei ist nicht gesagt, dass die Anbindung der Werkzeuge am Besten ist, wenn alle Werkzeuge von einem Hersteller stammen. Eine ganze Reihe von Herstellern können die komplette Werk- zeugpalette nur deswegen anbieten, weil sie in den letzten Jahren verschie- dene andere Unternehmen aufgekauft haben. Die Integration dieser zuge- kauften Softwarepakete zu einer einheitlichen Linie dauert oft Jahre. Das Team von Fr. Probst hat für die Dauer des Projektes zwei eigene Räume bei PV-Soft bezogen. Ein Raum dient als Gruppenarbeitsraum, der andere Raum ist ein Großraumbüro, das lediglich durch Trennwände aufgeteilt ist. Kaf- feeküche und Kopierer befinden sich direkt nebenan und werden gemeinsam mit anderen PV-Soft Mitarbeitern genutzt. Der Gruppenarbeitsraum hat eine Computer-Projektionsmöglichkeit, und zwei Computerarbeitsplätze mit Netz- werkanschluss. An den zwei übrigen freien Wänden befinden sich Whiteboards und es ist ein Flipchart vorhanden. Im Schrank ist eine Digitalkamera verfügbar. Die einzelnen Arbeitsplätze im Großraumbüro sind in L-Form ausgelegt. Auf der Ecke befindet sich jeweils der Computer - leicht erhöht in Augenhöhe. Als Entwicklungsumgebung wird die gleiche Umgebung verwendet, die beim Autraggeber üblich ist: alle Werkzeuge stammen vom gleichen namhaften Her- steller Omnitool13. Im Team hat diese Entscheidung für Aufregung gesorgt, ins- besondere Hr. Teschner mag sich nicht an den Editor der Omnitol-IDE gewöh- nen. 6.2 Werkzeugauswahl Wie finden Sie unter der grossen Auswahl möglicher CASE-Tools das richtige Werkzeug für Ihren Zweck? Wir empfehlen Ihnen: Es ist nicht unbedingt nötig, dass Sie bei der Werkzeugauswahl nach dem 55 Seiten starken ISO-Standard vorgehen [ISO95], in diesem Abschnitt finden Sie bereits eine Liste wichtiger Kriterien für die CASE-Tool Auswahl. Für grössere Organisationen empfiehlt es sich zudem die Toolauswahl als eigen- 13 Nicht zu verwechseln mit dem gleichnamigen Hersteller von Formen für die Industrie Werkzeugauswahl Erfolgsfaktor: Wählen Sie Werkzeuge systematisch nach denen von Ihnen festge- legten Kriterien aus. 87 Infrastruktur und Werkzeuge Kriterium ständiges Projekt aufzusetzen. Durch die Investition von einigen tausend Euro können Sie so ggf. Millionen einsparen. Der folgende Ansatz führt zu einer systematischen Bewertung und Auswahl eines Werkzeugs: ! Stellen Sie Ihren eigenen Kriterienkatalog zusammen und gewichten Sie die Kriterien prozentual entsprechend ihrer Wichtigkeit. Die Gewichte aller Kriterien zusammen sollen dabei 100% entsprechen. ! Stellen Sie eine Liste aller Kandidaten-Werkzeuge zusammen, die poten- tiell in Frage kommen. Beschaffen Sie zunächst einfaches Informationsma- terial zu den Werkzeugen per Internet oder durch Anforderung beim Her- steller. ! Bewerten Sie die Kandidaten zunächst nach dieser „Papierform“ bzgl. der Kriterien und vergeben Sie dazu einen Erreichungsgrad von 0-100%. ! Bilden Sie eine Gesamtbewertung indem Sie pro Kriterium das Gewicht mit dem Erreichungsgrad multiplizieren und die so gebildeten Werte pro Kandidat addieren. Das Ergebnis ist wieder eine Prozentzahl. Diese Ge- samtbewertungszahl gibt an, wie das Werkzeug insgesamt mit Ihren An- sprüchen übereinstimmt. Sie werden in der Praxis kaum ein Werkzeug an- treffen, dass hier 100% erreicht. ! Treffen Sie nun eine engere Wahl und testen Sie einige der Werkzeuge bzw. lassen Sie sich diese vom Hersteller vorführen. Führen Sie dann er- neut die Bewertung durch - diesmal aber nicht nach Papierform, sondern anhand Ihrer konkreten eigenen Erfahrungen mit dem Werkzeug. Für eine faire Bewertung ist es hilfreich - wenn alle Werkzeuge anhand des gleichen „Beispielszenario“ getestet werden. Beispieldokument 6.1 zeigt eine Entscheidungsmatrix die dem dargestellten Auswahlverfahren entspricht. Im Beispiel wurde Kandid D nach der Voraus- wahl gestrichen und die Kandidaten A, B und C getestet. Die Entscheidung ist jetzt zwischen Kandidat B und Kandidat C zu treffen - der Zahlenwert alleine sollte für die Schlussentscheidung nicht ausschliesslich eine Rolle spielen sondern lediglich die Entscheidungsdiskussion leiten. Nr. Gewicht Kandidat A Papierform Test Test Kandidat C Test 85% 50% 60% 100% 90% 50% 40% 76% 74% Kandidat D 40% 100% 30% 55% Kandidat B Papierform 60% Papierform 90% Papierform 50% 1 2 3 4 65% 50% 90% 80% 67% 71% 77% Funktion 40% 80% 70% 75% 80% 80% 80% 80% 90% Hersteller 30% 60% Preis 20% 70% Sonstiges 10% 90% Summe 100% 73% Beispieldokument 6.1: Entscheidungsmatrix für eine Werkzeugauswahl 88 Im Folgenden nenne wir einige geeignete allgemeine Kriterien und dann je- weils mögliche spezifische Kriterien für die einzelnen Werkzeugarten. Allgemeine Kriterien ! Lebenszyklus Ab wann und wie lange soll das Werkzeug voraussichtlich eingesetzt wer- den? ! Verfügbarkeit Gibt es das Werkzeug auf dem deutschen Markt? Gibt es eine aktuelle Version? Wird das Werkzeug vom Hersteller noch gepflegt? ! Referenzen Welcher Kunde des Herstellers in ähnlicher Situation setzt die Lösung be- reits ein? Wie ist der Kunde mit der Lösung zufrieden? ! Hersteller Wie ist die wirtschaftliche Lage und Wettbewerbsfähigkeit des Herstellers - wird es ihn über den gesamten Lebenszyklus voraussichtlich noch geben? ! Wartung/Support durch den Hersteller Welche Reaktionszeiten und welche Wartungsmöglichkeiten bietet der Hersteller? Welche Qualität der Leistungen wird sichergestellt? ! Lizenzbedingungen/Preis Was kostet die Ausstattung der betroffenen Arbeitsplätze? Welche Li- zenzmodelle werden angeboten? ! Unterstützung durch den Hersteller Welche Dienstleistungen rund um das Werkzeug, wie Training und Ein- führungsberatung bzw. kundenspezifische Anpassung werden angeboten? ! Anforderugen an Werkzeug-Umgebung Welche Ausstattung müssen die Arbeitsplatzrechner haben? Ist ggf. ein spezieller Serverrechner erforderlich? Welche andere Software muss verfpflichtend vorhanden sein? ! Einbindung in die übrige Infrastruktur/Schnittstellen Wie arbeitet das Werkzeug mit anderen CASE-Tools zusammen? ! Import/Exportmöglichkeiten/API14 - Migrationspfade Von welchen anderen Werkzeugen gleicher Art können Daten übernom- men werden? An welche anderen Werkzeuge gleicher Art können Daten übergeben werden? Welche APIs werden zur Verfügung gestellt? ! Dokumentation Wie ist die Dokumentation für das Werkzeug gestaltet? Wie gut ist die On- 14 API=Application Program Interface Werkzeugauswahl 89 Infrastruktur und Werkzeuge line-Hilfe? Wie gut sind die mitgelieferten Beispiele für den Einstieg ge- eignet? ! Betreuungsaufwand Wieviel Betreuungsaufwand ist für dieses Werkzeug zu erwarten? IDE: Editor/Compiler/Debugger/Screen Painter ! IDE Mindestens wird eine Projektverwaltung benötigt - es muss leicht möglich sein, Dateien dem Projekt hinzuzufügen oder wieder daraus zu entfernen. Die Projektverwaltung soll den Status der Dateien anzeigen und die Ab- hängigkeiten der Dateien verfolgen. Auf Knopfdruck soll die Neuüberset- zung der veränderten und der davon abhängigen Dateien ausgelöst werden können. ! Editor • Volltext-Editor mit den üblichen nützlichen Funktionen • Anpassbar an Coding-Konventionen - d.h. Anzahl von Leerzei- chen für Tabs, Speicherformat usw. • Syntax highlighting für die gewählten Sprache, d.h. der Editor erkennt automatisch Schlüsselworte, Bezeichner und Kommen- tare und stellt diese farbig dar. ! Screen Painter Grafischer Editor mit dem Dialoge und Fenster erstellt werden können, oh- ne dafür Code zu schreiben. Die Steuerelemente wie Felder, Menüs und Schaltflächen und statischen Teile wie Text, Linien und Rahmen können nach dem WYSIWYG15 - Prinzip plaziert werden. ! Debugger Mindestens müssen Haltepunkte gesetzt werden können und der Zustand von Variablen angezeigt werden. Der Debugger muss im Einzelschritt und funktionsweise den Code abarbeiten können. Mehrere Threads müssen möglich sein. 15 WYSIWYG=What you see is what you get - Die Anzeige während der Arbeitung ent- spricht dem später zu erwartenden Ergebnis 90 Geschäftsprozessanalyse ! Werden alle gängigen Prozessmodellelemente wie Prozesse, Aktivitäten, Übergänge, Resourcen, Rollen, Dokumente, Geschäftsobjekte usw. unter- stützt? ! Wie können Prozesse simuliert, analysiert und optimiert werden? ! Wie können definierte Abläufe an Workflow-Werkzeuge weitergereicht werden? Anforderungsaufnahme ! Strukturierte Erfasssungmöglichkeit von Anforderungen ! Erfassungsmöglichkeit für Abnahmekriterien ! Ausgabemöglichkeit als geschlossener Text ! Testfallgenerierung ! Einbindung externer Dokumente und Referenzen ! Glossar Modellierung ! Unterstützung der aktuellen UML Konfiguration Management ! Versionsverwaltung ! Nachverfolgung von Fehlermeldungen, Änderungswünschen und Hilfean- fragen ! Automatische Erzeugung von Quittungen für den Anfrager Weitere Kriterien finden sieh in Abschnitt 6.3 „Einzelteile und Versionen“. Testen ! Unit Test ! Regression Test ! Performance Test Werkzeugauswahl 91 Infrastruktur und Werkzeuge Projektmanagement ! Projektplanung ! Projektverfolgung Zusammenarbeit ! Projekttagebuch/Entwicklerforum ! Kunden-Forum 6.3 Einzelteile und Versionen Wie gelingt es innerhalb der Softwareentwicklung den Überblick über tausen- de von Einzelergebnissen zu behalten, insbesondere wenn sehr viele Entwick- ler gleichzeitig daran arbeiten? Die modulare Softwareentwicklung (siehe „Teile und Herrsche“ in Abschnitt 4.1) führt dazu, dass zur Auslieferung einer Software viele Einzeldokumente (insbesondere Quellcode) aufeinanderabgestimmt werden müssen. Zu ver- schiedenen Auslieferungsanlässen werden Softwareversionen gebildet (vgl. Abbildung Abbildung 6.2). Basis der Versionen sind gemeinsame Dokumente, die es in verschiedenen Änderungszuständen gibt. Abbildung 6.1 illustriert dies indem die Teile „Haare“, „Augen“ und „Mund“ eines Kopfes als Stell- vertreter für drei Teildokumente einer Software stehen. Jedes Teildokument ändert sich im Laufe der Zeit und kann mit den anderen Teilen zu einer Vielzahl von Versionen kombiniert werden. Nur einige dieser Versionen dienen einem Auslieferungszweck, z.B.: ! Entwurf ! Prototyp ! Messe ! Betatest ! Auslieferung an den Kunden 92 Abbildung 6.1 Gemeinsame Teile mit verschiedenen Änderungszuständen. Die Softwarekonfigurationsverwaltung beugt dem Risiko vor, das durch falsch zusammengestellte Versionen entsteht. Ein einziges Teil, dass im falschen Zu- stand einer Version hinzugefügt wird kann bereits massiven Schaden anrich- ten. Fehler die durch die falsche Konfiguration von Software entstehen, sind zudem besonders schwer zu finden. Entwurf Prototyp Messe Betatest Abbildung 6.2: Versionen Wegen der hohen Zahl von Kombinationsmöglichkeiten ist es nur mit Compu- terunterstützung sinnvoll möglich, die Kontrolle über die Softwarekonfigurati- on zu behalten. Sehr gute Werkzeuge zu diesem Zweck gibt es in allen Preis- lagen. Achten Sie aber darauf, sich nicht nur auf das Werkzeug zu verlassen. Es ist erforderlich dieAbläufe um die Versionsverwaltung herum in den fol- genden Bereichen zu gestalten ! Konstruktion ! Mitverfolgen Auslieferung Einzelteile und Versionen 93 Infrastruktur und Werkzeuge ! Team ! Prozess ! Steuerung ! Komponenten ! Struktur Die Minimalanforderungen sind: ! Konstruktion Es muss möglich sein, Versionen aus einem Archiv heraus zu reproduzie- ren. Dies sollte auch für Momentaufnahmen möglich sein (z.B. tägliche „Schnappschüsse“). ! Mitverfolgen Der Status der Einzeldokumente und der Versionen muss ersichtlich sein. Es muss möglich sein, die Spur einer Änderung bis zum Autor und Datum der Änderung zu verfolgen. Es muss eine möglichst automatisierte Buch- führung über Änderungen geben. Statistiken und Berichte helfen den Ü- berblick zu behalten ! Team Entwickler und Gruppen von Entwicklern müssen unabhängig voneinander arbeiten können und dürfen durch die Versionsverwaltung nicht behindert werden. Konflikte zwischen widersprüchlichen Änderungen müssen berei- nigt werden können. Es muss möglich sein, zum Test Änderungen vorzu- nehmen, die in die endgültige Version nicht einfliessen. ! Prozess Die Dokumentation von Änderungen, der Austausch von Informationen über Änderungen und die Verteilung von Änderungsaufgaben soll un- terstüzt werden. ! Steuerung Die Verfolgung und Änderungen und Fehler muss mit der Versionsverwal- tung koordiniert erfolgen. Der Zugriff auf das Archive muss geregelt sein. ! Komponenten Es muss ein gemeinsames Archiv geben, aus dem heraus Versionen gebil- det werden können. Die Beschreibung von Versionen anhand von Stücklis- ten muss möglich sein und selbst wieder unter Versionskontrolle genom- men werden. Versionen müssen in einen Projektkontext gestellt werden können. ! Struktur Es muss möglich sein, Schnittstellen und Verbindungen zwischen Einzel- dokumenten anzugeben und daraufhin einen konsistenten Zustand zu bil- den. Die Softwareversions- und Konfigurationsverwaltung wird mit zunehmender Projektgrösse immer wichtiger. Während sich kleine Teams von drei bis fünf 94 Entwicklern noch mit einfachen Mitteln abstimmen können, ist die Verantwor- tung für dieses Thema bei Teams schon ab zwanzig Leuten leicht ein Vollzeit- job. Schätzen Sie das Risiko für Ihr Projekt ein, und wählen Sie danach eine geeig- nete Lösung für sich aus. Dazu gehört sowohl eine Software, als auch die Ver- fahren und die Besetzung des Themas mit einer verantwortlichen Person. Hr. Teschner ist schon seit 7 Uhr im Büro und begrüsst Hr. Angelet „Peter mei- ne Testfälle laufen seit heute nicht mehr - ich bekomme die Fehlermeldung `java.lang.NoClassDefFoundError: org/w3c/dom/Element` - um den Fehler zu finden habe ich schon die Version von gestern wiederher- gestellt, aber der Fehler bleibt“. Nach einiger Zeit stellen beide gemeinsam fest, dass die XML-Bibliotheken xalan.jar und xerces.jar nicht im Konfigurationsver- waltungssystem erfasst sind und gestern das gemeinsam genutzte Verzeichnis im Netzwerk umbenannt wurde. Sie informieren Fr. Besonders wichtig für die Konfigurationsverwaltung sind: ! Die Vollständigkeit - neben den eigenen Ergebnissen sollten Sie auch alle verwendeten und zugekauften Komponenten so wie nach möglichkeit auch Werkzeuge und Konfigurationsdateien unter Konfigurationsverwaltung nehmen. ! Die Beherrschung der Komplexität - teilen Sie die zu verwaltenden Einhei- ten in kleinere Bereiche auf die unabhängig voneinander gesteuert werden. Auch hier gilt wieder das Prinzip des „teile und herrsche“. 6.4 Generierung !!! Model Driven Architecture !!! [Hub02] Platform Dependent Model (PDM) Platform Independent Model (PIM) Generierung Erfolgsfaktor: Setzen Sie eine Ihren Bedürfnissen entsprechende Softwareversi- ons- und Konfigurationsverwaltung ein. 95 Infrastruktur und Werkzeuge 6.5 Literatur [Bab86] W. A. Babich: Software Configuration Management - Coordi- nation for Team Productivity, Pearson Higher Education, 1986 [Coc01] siehe [Coc01] in Abschnitt 7.9 [DeM99] siehe [DeM99] in Abschnitt 1.9. [Hub02] R. Hubert: Convergent Architecture - Building Model-Driven J2EE Systems with UML, Wiley, 2002 [ISO95] International Organization for Standardization: ISO/IEC DIS 14102 - Evaluation and Selection of Computer-Aided Software Engineering (CASE Tools), ISO, 1995 (siehe auch http://www.iso.ch) 96 „Gute Vorsätze sind wie Schecks, die man auf eine Bank ausstellt, bei der man gar kein Konto hat.“ Oscar Wilde 7 Worin unterscheiden sich der Teufel und die Familie? Warum finden die meis- ten Menschen Personal Computer besser als Mainframes obwohl Mainframes doch viel leistungsfähiger sind? Warum ist die Atomkraft unbeliebter als die Windkraft, obwohl doch mehr Atomstrom produziert wird? Akzeptanz ensteht aus dem Zusammenwirken von Problemlösungskompetenz und Vertrauen. Dem Teufel traut zwar niemand über den Weg aber man traut ihm alles zu. Deswegen hat selbst der Teufel eine gewisse Akzeptanz. Die Familie geniesst hohes Vertrauen und sorgt dabei für die wichtigstens Proble- me Grundbedürfnisse, wie Essen, Schlafen und Kleidung. Bei Atomkraft den- ken viele Menschen eher an die Folgen von Tschernobyl als an den Strom aus ihrer Steckdose - Windkraft dagegen gilt als saubere und zukunftsweisende Lösung. Problemlösungskompetenz und Vertrauen alleine genügen nicht - sie brauchen von beidem die richtige Menge, um Akzeptanz zu geniessen. Abbildung 7.1 zeigt die Einordnung der gezeigten Beispiele in eine grafische Darstellung: Literatur 7 Projektmanagement, Kommunikation, Politik 97 Projektmanagement, Kommunikation, Politik Abbildung 7.1: Akzeptanz als Kombination von Vertrauen und Problemlösungskompetenz Eines Ihrer Projektziele ist es, möglichst hohe Akzeptanz zu erreichen. Dies können Sie zum einen durch die Erhöhung Ihrer Problemlösungskompetenz erreichen. Dazu dienen ! Zielorientierung ! Wissensmanagement ! Planung und Steuerung ! Das Fällen von Entscheidungen ! Risikomanagement Zum anderen können Sie das Vertrauen in Ihr Projekt stärken. Dazu gehören ! Umgang im Team ! Kommunikation ! Führung und Förderung Die richtige Kombination führt zur höchsten Akzeptanz. In den Abschnitten dieses Kapitels finden Sie Hinweise darauf, wie Sie Ihre Akzeptanzposition verbessern können. 98 7.1 Zielorientierung In Abschnitt 1.5 „Gemeinsames Erfolgsverständnis“ haben wir darauf hinge- wiesen wie wichtig es ist, die Ziele des Projektes und den Weg dorthin zu klä- ren. Die Aufgabe des Projektmanagements ist es nun den Kurs auf das Ziel zu halten oder wenn nötig neue Ziele festzulegen und eine Kursänderung vorzu- nehmen. Zerlegung der Projektziele Setzen Sie sich Meilensteine, die Sie auf dem Weg zu ihrem eigentlichen Pro- jektziel erreichen wollen. Die Festlegung der Meilensteine hängt von der Art Ihres Vorgehens ab: ! Wenn Sie nach dem Wasserfall-Prinzip vorgehen, dann liefern Ihnen die Ergebnisse der ersten Phasen des Projektes die Grundlage für die nächste Phase des Projektes. Potentielle Meilensteine sind der Beginn einer neuen Phase (d.h. die Modellierung beginnt nach dem genügend Anforderungen vorliegen) und das Ende einer Phase (alle Anforderungen sind aufgenom- men). ! Wenn Sie iterativ vorgehen, dann lernen Sie aus den Fehlern erster Schrit- te. Sie gehen Ihre Projektziele an, indem Sie sich einen immer größeren Umfang zur Realisierung vornehmen. Jeder Iterationszyklus bringt sie dem Ziel näher und Sie lernen aus den Problemen der Anfangsschritte für die folgenden Schritte. ! Wenn Sie inkrementell vorgehen, dann teilen Sie das Projekt in Teilgebiete („Inkremente“) auf, die parallel zueinander bearbeitet werden und mit ei- genen zeitlichen und inhaltlichen Zielen versehen werden. Das Gesamtpro- jektziel wird duch Integration aller inkrementell erstellten Ergebnispakete erreicht. Die größten Vorteile erreichen Sie unserer Erfahrung nach durch iteratives oder inkrementelles Vorgehen. Dies hat die Umfrage bestätigt: Wenn Sie diesen Erfolgsfaktor beherzigen, dann wird: ! Das Gesamtrisiko kleiner, da Sie je Meilenstein ein Ergebnis bekommen, auf das Sie reagieren können. ! Das Tempo von Meilenstein zu Meilenstein höher, da Sie die Erkenntnisse der vorherigen Meilensteine zur Optimierung nutzen können. Zielorientierung Erfolgsfaktor: Schrittweise iterative oder inkrementelle Näherung an das Projektziel. 99 Projektmanagement, Kommunikation, Politik ! Das Reagieren auf Änderungen leichter, da jeder Schritt die Möglichkeit bietet, den Kurs zu ändern. Achten Sie bei der Gestaltung der Iterationen oder Inkremente auf die richtige Größe. Bei einer Projektlaufzeit von zwei Jahren sollten die Projektabschnitte zum Beispiel maximal etwa 3 Monate gross sein – sonst treten in den Abschnistten bereits die Probleme „ganzer“ Projekte auf. Bei kürzeren Projek- ten sollten Sie dennoch keine Abschnitte bilden, die kürzer als 3 Wochen sind, denn der Aufwand zum Fertigstellen, Integrieren, Präsentieren und Diskutie- ren der Zwischenergebnisse ist sonst im Verhältnis zu dieser Zeitspanne zu hoch. Erwartungsmanagement und Verbindlichkeit Eines der wichtigsten Ziele des Softwareprojektes ist es die Erwartungen der Beteiligten zu erfüllen. Alles was Sie dafür tun müssen: ! Dafür sorgen, dass sie überhaupt in der Lage sind Erwartungen zu erfüllen. ! Wissen welche Erwartungen sie mit den gegebenen Mitteln erfüllen kön- nen. ! Dafür sorgen, dass Sie nur so hohe Erwartungen wecken, wie Ihren Erfül- lungsmöglichkeiten entspricht. Bei diesem Erfolgsfaktor gilt - leichter gesagt als getan. Es ist niemals mög- lich alle Versprechungen zu 100% einzuhalten - alleine schon deswegen, weil es Unterschiede im Verständnis gibt. Es ist nur natürlich, dass jemand, dem Sie ein Verprechen geben, dieses zu seinen Gunsten auslegt. Auf der anderen Seite ist die Versuchung gross, mehr zu versprechen, als man halten kann, wenn damit Vorteile verbunden sind. Unserer Erfahrungen nach ist es wesentlich einfacher, Erwartungen im Rah- men zu halten, als zu versuchen, überzogene Erwartungen zu erfüllen. Zudem wirkt die Vorgeschichte Ihrer Beziehungen sich auf die Wahrnehmung der Beteiligten aus. Das Zuverlässigkeit in der Vergangenheit wird auf die Zu- kunft projeziert. Ein gleichmässiges Verhalten ist leichter nachvollziehbar als eine wechselhafte Erfüllung von Versprechungen. 100 Erfolgsfaktor: Seien Sie verbindlich - machen Sie nur Versprechungen, die sie auch halten können. Halten Sie sich an Ihre Versprechen! 7.2 Entscheidungen fällen Wie lassen sich Entscheidungen in Softwareprojekten vorantreiben? Wie oft haben Sie in den Zwischenergebnissen Ihrer Projekte schon den Hinweis „muss noch geklärt werden“ oder „to be defined“ vorgefunden? Das Treffen von Entscheidungen ist eine der wichtigsten Aktivitäten in Soft- warprojekten überhaupt. Erstaunlicherweise kommt die Aktivität „Entschei- dungen treffen“ in so manchem Vorgehensmodell überhaupt nicht vor! Unse- rer Erfahrung nach läßt sich an der Art- und Weise wie in einem Softwarepro- jekt Entscheidungen getroffen werden am schnellsten die Erfolgschance eines Projektes ablesen: ! Die Erfolgschance eines Projektes, indem keine Entscheidungen getroffen werden ist null. ! Werden Entscheidungen zu leichtfertig und ohne Abstimmung getroffen, dann kommt das Projekt scheinbar schnell voran, aber die Risiken steigen. ! Eine Entscheidungsfreudige Konsenskultur im Team hat die besten Er- folgschancen. Der Aufsatz „Decisions, Decision“ aus [Con01] verweist darauf, wie wichtig die Gruppenkultur für die Entscheidungsfindung und die Qualität der Ent- scheidungen ist. Die wichtigste Kernaussage ist, dass sich der Leiter einer Gruppe aus der Entscheidungsfindung so weit es geht heraushalten muss, da- mit es zu einer möglichst guten Entscheidung kommt. Klärung und Entscheidung trennen In unseren Projekten haben wir oft erlebt, dass die Klärung eines Themas sehr schleppend vorangeht, wenn die Beteiligten zur gleichen Zeit versuchen ein Thema durchzusetzen, also eine Entscheidung suchen. Hr. Angelet, Hr. Entrop und Fr.Teschner diskutieren darüber, wie die Projekt- verwaltung Internet-fähig gemacht werden soll. Hr. Angelet ist dafür Java Applets zu verwenden und will gerade erklären, wie das geht da unterbricht Hr. Entrop. Er argumentiert Java Applets seien veraltetet und man müsse Java Ser- ver Pages verwenden. Das geht eine Weile so hin- und her bis Frau Teschner unterbricht und gerne erstmal verstehen möchte, was denn überhaupt der Unter- schied zwischen Java Applets und Java Server Pages ist und was für das eine und was für das andere spricht. Die Trennung des Klärungsprozesses vom Einigungsprozess hilft sowohl bes- sere Entscheidungen zu bekommen als auch schneller zu einer Entscheidung zu kommen. Je genauer und präziser festgelegt ist, welches Problem gelöst, welche Ursachen abzustellen, welche Ziele zu erreichen sind, desto präziser, sicherer und klarer kann die Entscheidung getroffen werden. Wenn die Klä- Entscheidungen fällen 101 Projektmanagement, Kommunikation, Politik rung nicht von der Entscheidung getrennt wird, dann entsteht schnell ein Kli- ma des Mißtrauens und der Aggression. Statt einer Entscheidung kommt es zu: ! unendlichen ergebnislosen Diskussionen ! einem Kampf um persönliche Standpunkte ! konfliktloser Unterwerfung Das Ziel ist jedoch, durch Aushandeln, das gemeinsame entwickeln von Kom- promissen bzw. die gemeinsame Auswahl der „richtigen“ Entscheidung zu einer sachlich begründeten guten Entscheidung zu kommen. In einem Projekt haben wir monatelang um die richtigen Entscheidungen für die Softwarearchitektur gerungen und kamen nur sehr langsam voran. Die Be- teiligten waren schon ziemlich entnervt von den langen sich wiederholenden Ritualen der Sitzungen. Der Durchbruch gelang, als folgendes Muster für die Sitzungen angewendet wurde: ! Welche Entscheidungen liegen für heute zur Diskussion vor? ! In welcher Reihenfolge wollen wir diese Entscheidungen behandeln? ! Entscheidung über die einzelnen Punkte Zu jeder Entscheidung wurde folgender Verlauf gewählt: Klärung: ! Was steht im Detail zur Entscheidung an? ! Welche Ziele werden verfolgt? ! Welche Vorschläge/Möglichkeiten gibt es, diese Ziele zu erreichen? Entscheidung: ! Bewertung der Vorschläge bezüglich des Grades der Zielerreichung ! Vorläufige Entscheidung ! Analyse der möglichen Folgeprobleme ! Endgültige Entscheidung Entscheidend war, die sachliche Klärung bezüglich des Problems vollkommen zu trennen von den der eigentlichen Auswahl der Lösung. Bei der Protokollie- rung der Sitzungen wurden die unterschiedlichen Meinungen explizit fest- gehalten. Bei der eigentlichen Entscheidung wurde im Konsens entschieden - jeder Beteiligte musste mindestens sagen können „Mit dieser Entscheidung kann ich leben“. Risiko und Entscheidung !!! 102 Vom Umgang mit Eisbergen Erfolgsfaktor: Treffen Sie ihre Entscheidungen entsprechend dem Risiko das da- mit zusammenhängt und trennen Sie die Klärung und die eigentli- che Entscheidung. Gründe, Entscheidungen schnell zu fällen: ! Die Voraussetzung für weitere Entscheidungen in abhängigen Bereichen wird geschaffen. ! Das Risiko einer Fehlentscheidung ist gering, der Zeitverlust durch Abwar- ten käme auf jeden Fall teurer. Gründe, Entscheidungen aufzuschieben: ! Angst vor der Verantwortung, eine falsche Entscheidung getroffen zu ha- ben. ! Hohes Risiko einer Fehlentscheidung - es ist günstiger, die Entscheidung aufzuschieben, da die Wahrscheinlichkeit und Schwere der Folgen einer Fehlentscheidung hoch ist. ! Hoffnung, dass durch mehr Information später eine bessere Entscheidung möglich ist. 7.3 Vom Umgang mit Eisbergen Nach der Eisberg-Theorie stellen die formalen und beobachtbaren Teile der Zusammenarbeit nur etwa 10% aller Aspekte dar, die Zusammenarbeit aus- machen. Aufgabenbeschreibungen, Vorgehensmodelle, Pläne, Richtlinien, Vereinbarungen, Protokolle und andere greifbare Ergebnisse stellen demnach nur die Spitze des Eisbergs dar. Die 90% des Eisbergs, die sich als informaler nicht greifbarer Anteil unter dieser Oberfläche verbergen haben die größere Wirkung auf die Zusammenarbeit. Das liegt daran, dass Menschen viel stär- ker durch Ihr Unterbewußtsein gesteuert werden als durch den Verstand. Alle Entscheidungen werden grundsätzlich „aus dem Bauch heraus“ getroffen. Über den Verstand kann der Bauch beinflusst werden aber nur indirekt. Per- sönliche Beziehungen, Rollenverhalten, Machtverteilung, Projekt- und Unter- nehmenskultur sind deshalb wichtiger als es oberflächlich betrachtet erscheint. Für die Gestaltung eines Softwareprojektes ist die Kenntnis von beiden Ebe- nen des Beziehungsgefüges von Bedeutung (vgl. Abbildung 7.2). 103 Projektmanagement, Kommunikation, Politik Maximen für agiles Handeln - Pläne - Vorgehensmodelle - Protokolle - Handlungsanleitungen - etc. - persönliche Beziehungen - Ideen - Wünsche - Werte - Projektkultur - Unternehmenskultur - etc. Abbildung 7.2: Die Eisberg-Theorie der Kommunikation Die Macht des Eisberg-Teils, der unter der Oberfläche liegt ist gross. Ob sich dieser Teil zum Nutzen oder zum Schaden ihres Projektes bewegt hat erhebli- chen Einfluss auf den Erfolg des Projektes. Jahrzehntelang haben Verfasser von Methodenempfehlungen für die Softwareentwicklung sich darauf kon- zentriert, die Eisberg-Theorie zu ignorieren und lediglich immer neue Konzep- te für die formelle Organisation von Softwareprojekten angeboten. In den letz- ten Jahren hat sich das Bild deutlich gewandelt. Leichtgewichtige und agile Ansätze legen den Schwerpunkt darauf, dass die Zusammenarbeit auf den in- formellen Kanälen gefördert wird. implizites Wissen (tacit knowledge) spielt für das Handeln eine größere Rolle als der durch schriftliches Niederlegen er- reichbare Teil der Kenntnisse des Teams (siehe dazu auch Abschnitt 7.8 „Erfahrungen teilen“). Die maximen agilen Handelns lassen sich direkt aus der Eisberg-Theorie ableiten: ! eher offen für Änderungen als starres Festhalten an Plänen ! eher Menschen und Kommunikation als Prozesse und Tools ! eher ergebnisorientiert als prozessorientiert ! eher „darüber miteinander reden“ als „gegeneinander schreiben“ 104 Erfolgsfaktor: Gestalten Sie aktiv alle Ebenen der Kommunikation entsprechend der Eisberg-Theorie. ! eher Vertrauen als Kontrolle ! eher „Best Practices“ aus Erfahrung als verordnete Vorgaben ! ehere Angemessenheit als Extremismus Alle diese Maximen zielen darauf ab, dass der unsichtbare Teil des Eisbergs das größere Gewicht hat. Fr. Probst wird seit einigen Tagen das Gefühl nicht los, dass zwischen Hr. Teschner und Fr. Entrop „etwas nicht stimmt“. Die beiden sprechen kaum mit- einander und gehen sich aus dem Weg. Fr. Probst beschliesst, Augen und Ohren offen zu halten, um heraus zu bekommen, was die Ursache ist. Als Fr. Probst Hr. Angelet nachträglich zum Geburtstag gratuliert erfährt sie, dass dieser die- ses Jahr kein Geburtstagsgeschenk bekommen hat. Fr. Entrop war dies schreck- lich peinlich. Fr. Entrop hatte sich darauf verlassen, dass sich Hr. Teschner kümmern würde. Hr. Angelet fand es überhaupt nicht schlimm und hat sich schon alleine darüber gefreut, dass alle an ihn gedacht haben. Mit diesem An- haltspunkt weiss Fr. Probst nun mit der „dicken Luft“ besser etwas anzufangen. Nach einiger Zeit kommt Hr. Teschner zu ihr und bittet um Vermittlung. Es stellt sich heraus, dass Fr. Entrop Hr. Teschner gar nicht absichtlich aus dem Weg gegangen ist, sondern dass es sich nur zufällig so ergeben hat. Hr. Teschner glaubte jedoch, Fr. Entrop würde ihn wg. der Geschenk-Sache ab- sichtlich schneiden ... In unseren Projekten haben wir die Erfahrung gemacht, dass besonderes in größeren Organisationen der Wiederstand gegen die Erkenntnisse der Eisberg- Theorie gross ist. Dies gilt wohlgemerkt nur für die nach innen gerichten Ab- teilungen wie die Softwarentwicklung. In den gleichen Organisationen wird der Vertrieb oftmals in Seminaren geschult, um mit Hilfe der Eisberg-Theorie besser zu verstehen, wie Kunden gewonnen werden können. Gerade wenn Sie kein „Naturtalent“ im Umgang mit den Eisbergen sind, hel- fen folgende Punkte: ! Kümmern Sie sich aktiv um beide Ebenen der Kommunikation - sowohl den direkt spürbaren als auch den nur zu erahnenden Teil. ! Behandeln Sie Ihre Projektmitarbeiter wie Ihre Kunden. ! Unterstützen Sie anderen Ihre persönlichen Ziele zu erreichen, dann wer- den Sie auch Ihre Projektziele erreichen. ! Halten Sie Augen und Ohren auf – nutzen Sie Ihre „Antennen“ für das un- ter der Oberfläche ablaufende Geschehen. 7.4 Das Team Wer gehört alles zum Projektteam? Wie können die Projektziele gemeinsam erreicht werden? Das Team 105 Projektmanagement, Kommunikation, Politik Wer gehört dazu? Zum Projektteam gehören mindestens Vertreter des Auftraggebers und die Mitarbeiter des Auftragnehmers, die an der Erstellung der Softwarelösung mitwirken. Es gibt aber noch eine ganze Reihe von anderen Betroffenen. Dies können z.B. sein: ! Anwender ! Lieferanten ! Partner ! Kunden !!! 106 Erfolgsfaktor: Identifizieren und beteiligen Sie alle Betroffenen, insbesondere die Anwender. Ausrichtung des Teams auf die Ziele16 In einem gut funktionierenden Team ziehen die Menschen „an einem Strang“ in in etwa die gleiche Richtung. Tatsächlich wird es nie den Idealfall geben, dass alle Beteiligten das Projekt exakt in die gleiche Richtung vorantreiben. Persönliche Ziele, Erfahrung, Trägheit und Durchsetzungsvermögen spielen eine grosse Rolle für die Richtung und Stärke des Beitrags des einzelnen Teammitglieds (vgl. Abbildung 7.3). Das Team Abbildung 7.3: Durchschnittliches Team, das versucht ein rechts liegendes Ziel zu errei- chen. Es wird nie gelingen, die einzelnen Mitglieder in ihrem Verhalten radikal zu beeinflussen, aber schon eine Reihe von kleinen Änderungen können ein er- heblich besseres Ergebnis bringen (vgl. Abbildung 7.4). 16 vgl. [Coc01] - Teams as Communities 107 Projektmanagement, Kommunikation, Politik Abbildung 7.4: Ein etwas besser auf das Ziel ausgerichtetes Team. Die Menschen bringen einen etwas besser auf das Ziel ausgerichteten Beitrag, wenn: ! sie mehr und genaueres darüber erfahren, wo das Ziel liegt ! sie die Folgen ihres eigenen Handelns spüren, und daran feststellen können in welche Richtung ihre eigenen Aktivitäten ziehen ! sie mehr und bessere Gründe haben, in die Richtung auf das gemeinsame Ziel zu arbeiten Alle kleinen Richtungsänderungen bringen insgesamt einen erheblichen Ef- fekt. Schwimmen in Richtung auf das Ziel Beim Schwimmen entsteht der Vortrieb durch den richtigen Umgang mit dem Wasserwiderstand. Damit die Schwimmzüge die grösste Wirkung entfallen, muss der Schwimmer bei jedem Zug ! möglichst viel Widerstand gegenüber dem Wasser suchen. Er „greift Was- ser“ und zieht sich am Wasser nach vorne. ! möglichst viel Widerstand gegenüber dem Wasser vermeiden. Der Körper wird in einer möglichst Stromlinienförmigen Haltung belassen und der Schwimmer achtet darauf möglichst wenig Widerstandsflächen zu bieten. In Softwareprojekten ist es nicht anders als beim Schwimmen. Es geht darum, an den richtigen Stellen Widerstand zu suchen und Widerstand zu vermeiden. Wenn Ihr Team einem Hindernis begegnet und Sie Aussagen hören wie: ! das geht nicht ! das verstehen wir nicht 108 ! das ist nicht sinnvoll dann können Sie darauf reagieren, in dem Sie Widerstand suchen und das Hindernis versuchen zu bezwingen: ! wie könnte es doch funktionieren? ! was ist zu tun, damit wir es verstehen? ! wie könnte es sinnvoll werden oder was fehlt uns noch, um den Sinn zu erkenne? oder Widerstand vermeiden indem Sie nach Alternativen suchen: ! was für eine andere funktionierende Lösung gibt es? ! was für eine einfachere und verständlichere Lösung gibt es? ! was für sinnvolle Alternativen gibt es? Entscheiden Sie sich jeweils bewusst für den in der jeweiligen Situation an- gemessenen Weg. Das richtige Projektklima schaffen Begeisterung hilft enorme Kräfte der Projektbeteiligten freizusetzen. Begeiste- rung ist ansteckend. Wie eine Flamme oder eine Krankheit überträgt sie sich von einem zum anderen und wird genährt oder erstickt. Schaffen und Erhalten Sie das Klima für Begeisterung. Negative Bemerkun- gen, Unpünktlichkeit, Entscheidungen ohne Absprache fällen – all diese Punk- te gelten schnell als Kleinigkeiten. Jeder dieser und ähnlicher Punkte ist je- doch zur Eintrübung des Klimas für Begeisterung geeignet. Erfolgserlebnisse sind das wichtigste Mittel zur Förderung eines begeisternden Klimas. Dabei ist die Regelmäßigkeit der Erfolgserlebnisse wichtiger als die Größe. Gut sind viele kleine stetige Erfolgserlebnisse, die nur selten von nega- tiven Erfahrungen getrübt werden. Selbst große Erfolgserlebnisse nützen nichts, wenn sie so selten sind, dass sie von vielen kleinen negativen Erfah- rungen getilgt werden. Im Team von Fr. Probst hat sich eingebürgert, dass jedes zehnte laufende Prüf- beispiel gefeiert wird. Am Anfang führte das zu einem Treffen bei Kaffee und Plätzchen pro Woche. Inzwischen gibt es jeden zweiten Tag ein Zehnerpaket zu feiern - die Belohnung variiert ständig und besonderes Fr. Entrop und Hr. Teschner entwickeln viel Phantasie dafür eine Überaschungstüte zu füllen, die derjenige, der den Testfall implementiert hat für das Team öffnen darf. Das Team Erfolgsfaktor: Begeisterung ist ansteckend. Sorgen Sie für die Verbreitung indem Sie das richtige Klima dafür schaffen. 109 Projektmanagement, Kommunikation, Politik Einem Team aus der Schweiz haben wir beim Ausfüllen unseres Fragebogens zuschauen können, einer schrieb und die anderen Teilnehmer standen im Halbkreis um den Schreiber herum. Als es darum ging, den Punkt „Begeiste- rung“ auszfüllen kam sofort Stimmung in die Mannschaft - Anekdoten wurden über das Projekt erzählt und gemeinsam „Projektlatein“ gesponnen. Die Be- geisterung des Teams war zu spüren. Begeisterung kann man nicht verordnen. Wenn sie fehlt, dann wird das Pro- jekt dadurch behindert und geht nur schleppend voran. Ihre eigene positive innere Einstellung ist die wichtigste Voraussetzung dafür, dass Sie andere da- mit anstecken können. Offenheit der Beteiligten gegenüber neuen Vorgehensweisen Teamgröße, Harmonie und Konfliktbereitschaft 7.5 Führung und Förderung Kenntnisse und Fähigkeiten Aufgabenverteilung Erfolgsfaktor: Fähige Mitarbeiter. 110 Die Rolle der Verantwortlichen Führung und Förderung Erfolgsfaktor: Förderung durch die Verantwortlichen. Die Rolle des Projektleiters Abschätzung von Aufwänden, Terminen und Kosten Warum sind die Schätzungen von Aufwänden, Terminen und Kosten in Soft- wareprojekten so schlecht? ! Niemand wird für gute Schätzungen belohnt. Lob gibt es nur für irreal günstige Wunschträume. ! Die Frage nach einer Schätzung ist oft nicht ernst gemeint - in Wirklichkeit wird vom Fragensteller die Bestätigung seiner Vorstellung erwartet ! Was eine gute Schätzung ausmacht bleibt unklar ! Es gibt keine Erfahrungswerte aus der Vergangenheit Dennoch gilt: !!! Erfolgsfaktor: Erfahrener Projektleiter. Erfolgsfaktor: Je zuverlässiger Ihre Schätzungen sind, desto besser. 111 Projektmanagement, Kommunikation, Politik # Berichte über gelöste und noch vorhandene Probleme Vertretung des Projektes nach Aussen Projektmarketing Erfolgsfaktor: Vertreten Sie Ihr Projekt nach aussen mit gutem Marketing und po- litischem Geschick. Ausgleich zwischen Unternehmens- und Projektinteressen 7.6 Projektplanung und Steuerung Warum lassen sich Softwarprojekte schlechter planen und steuern als Projekte eines Handwerkers? Der Softwareentwicklung fehlt die Sinnfälligkeit, die im Handwerk auf natür- liche Weise gegeben ist. Wenn ein Handwerker seine Arbeit plant und den Fortschritt seines Werks verfolgt, dann ist dies mit dem blossen Auge mög- lich. Ob es sich um einen Maler handelt, der Ihre Wohung streicht, einen Zimmermann, der einen Dachstuhl baut oder einen Mauer beim Hausbau - immer ist es auch für den Laien möglich, den Fortschritt der Arbeit mit den eigenen Sinnen zu sehen, hören, schmecken, riechen und zu fühlen. In der Softwareentwicklung sind die meisten produzierten Ergebnisse nicht direkt mit den menschlichen Sinnen erfassbar. Selbst wenn sich tausende von Datei- en auf der Festplatte eines Projektes angegsammelt haben, kann dieser Fort- schritt nur mit Hilfe eines Computers und durch aktives Eingreifen sichtbar gemacht werden. 112 Projektplanung und Steuerung Abbildung 7.5: Sinnfälligkeit der Softwareentwicklung im Vergleich zum Handwerk Die Planung und Verfolgung eines Softwareprojektes kann sich nur an sicht- bar gemachten Ergebnissen orientieren. Schon das sichtbar machen ist aller- dings mit Aufwand und Fehlerquellen behaftet. Welche Ergebnisse eignen sich am besten zur Planung? ! leicht sichtbar zu machende Ergebnisse wie Geschäftsprozesse, Anwen- dungsfälle, Bildschirm und Druckformulare, Anforderungen, Prüfbeispiele, Modellelemente, Programmcode, Testfälle ! leicht bewertbare Ergebnisse wie Testfälle (geht/geht nicht), realisierte Funktionen (erstellt und besteht alle Tests/noch nicht erstellt) Planen geht nur mit Erfahrung. Stellen Sie sich vor, Sie nehmen sich ihren ersten Marathon vor und bevor Sie noch mit dem Training angefangen haben fragt Sie jemand: „Wie willst Du Dir das Rennen einteilen und welche End- zeit hast Du Dir vorgenommen?“. Sie werden entweder keine Antwort wissen oder versuchen aus Ihrer Erfahrung mit sehr viel kürzeren Strecken auf die Marathonstrecke zu schliessen. Nach einigem Training, der Beschäftigung mit dem Rennen und dem Gedankenaustausch mit erfahrenen Marathonläufern wird Ihre Antwort schon sicherer ausfallen. 113 Projektmanagement, Kommunikation, Politik Sie brauchen also zumindestens ein wenig Training mit bewerteten und sicht- bar gemachten Ergebnissen, die Sie für Ihre Planung heranziehen wollen. Bes- ser noch ist es, wenn Ihnen Vergleiche der geplanten und tatsächlichen Zahlen aus vorherigen Aufgaben vorliegen. Wer soll planen? Natürlich diejenigen, die das Ergebnis liefern sollen. Plan- zahlen haben den schrecklichen Nebeneffekt, das sie mit der Übernahme von Verantwortung einhergehen. Es hat keinen Zweck anderen Planzahlen und die damit einhergehende Verantwortung „überzustülpen“. Planung ist eine hoch- politische Angelegenheit, weil sowohl die Auftraggeber als auch die Auftrag- geberseite bemüht sein wird, die Planung zu ihren Gunsten zu beeinflussen. In [Bec00] beschreibt Kent Beck als Lösungstrategie dieses natürlichen Kon- flikts zwischen den Parteien das „Planungsspiel“. Es gliedert sich in die drei Phasen: ! Erforschungsphase ! Verpflichtungsphase Die Erforschungsphase und Verpflichtungsphase entspricht dem von uns vorgestellten Bilden eines Anforderungsprofils in mit „Storycards“ verein- fachter Form. ! Steuerungsphase In der Steuerungsphase wird iterativ gearbeitet und regelmässig der Fort- schritt des Projektes bzgl. der erfüllten Anforderungen geprüft. Änderun- gen an den Anforderungen und die ständige Einschätzung der Entwick- lungsgeschwindigkeit führen zur Anpassung des Plans in jedem Zyklus. Regelmässige direkte Abstimmung 7.7 Umgang mit dem Zufall Wir gut die Planung Ihres Softwareprojektes später mit dem wirklichen Ver- lauf übereinstimmt ist von Zufällen abhängig es gilt „Planung ist der Ersatz des Zufalls durch den Irrtum“. Das Risiko besteht aus folgenden Punkten: ! Welche zufälligen Ereignisse können Ihr Projekt - insbesondere negativ beeinflussen 114 Erfolgsfaktor: Planen. ! Wie wahrscheinlich ist es, dass diese zufälligen Ereignisse eintreten? ! Wie groß ist das Ausmass der Folgen dieser Ereignisse? Für jedes Ereignis können Sie das Risiko bewerten, in dem Sie die Auftre- tenswahrscheinlichkeit mit Schwere des Ereignisses multiplizieren. Wenn Sie zum Beispiel damit rechnen, dass jeweils etwa ein zwanzigstel der Mitarbeiter Ihres Projektes krank ist, dann ist die Auftretenswahrscheinlichkeit 1/20, die Schwere des Ereignisses ist ein verlorener Arbeitstag pro betroffenem Mitar- beiter. Das Risiko beträgt also täglich 0.05 * Anzahl der Mitarbeiter, gemessen in Personentagen. Die meisten Risiken in einem Projekt lassen sich leider nicht so schön berech- nen. In diesen Fällen hilft die Gruppierung in einen der Quadranten entspre- chend Abbildung 7.6 „Qualitative Risikoeinschätzung“. Abbildung 7.6: Qualitative Risikoeinschätzung Wenn sie bei der Beurteilung eines Risikos im unteren linken Quadraten lie- gen, es also unwahrscheinlich ist, dass Sie Schaden erleiden werden oder der Schaden gering sein wird, wenn er Eintritt, dann sollten Sie sich von einem solchen Risiko nicht von Entscheidungen abhalten lassen (siehe 7.2 „Entscheidungen fällen“). Wieviel Risiko sie sich in Ihrem Projekt erlauben können hängt von Ihrem Projekttyp ab. Risikovermeidung bringt zusätzlichen Aufwand mit sich. Mit Risikovermeidung tauschen Sie also vielleicht eintretende Probleme gegen mit Umgang mit dem Zufall Erfolgsfaktor: Schätzen Sie Ihre Risiken ein und verfolgen Sie diese aktiv. 115 Projektmanagement, Kommunikation, Politik Sicherheit auftretende Folgen ein. Die folgende Kurve stellt dar wie sich der Aufwand im Verhältnis zu zunehmend gewünschter Sicherheit verhält: Abbildung 7.7: Aufwand im Verhältnis zur Sicherheit Das Bedürfnis nach Sicherheit und die Bereitschaft dafür zu investieren hängt demnach stark vom Ziel Ihres Projektes und der Branche ab, in der sie agieren. Vollständige Sicherheit im Sinne von 100% gibt es nicht. Es ist gut möglich, 99,99... % zu erreichen. Aber jede „9“ zusätzlich hinter dem Komma erhöht den Aufwand um ein Vielfaches. In [Gla97] ist beschrieben, wie ein 8 Milliar- den US$ teures Projekt vor allem daran scheiterte, dass eine Ausfallrate von nur wenigen Sekunden pro Jahr gefordert wurde, d.h. eine Ausfallsicherheit von 99,99999%. Ein Mitarbeiter des Projektes dazu „die ersten drei neunen hinter dem Komma waren kein Problem, die nächsten zwei waren nicht zu schaffen ...“. Eine Ausfallrate von 99,999% bedeutet 5 Minuten pro Jahr. In fünf Minuten kann man einen Computer bequem neu starten. Die geforderte Rate von 99,99999% bedeutet einen Neustart in weniger als 5 Sekunden - das wäre nur mit unvermässig hohem Aufwand möglich gewesen. Die Verfolgung dieses Ziels wurde aufgegeben. Was geht um Sie herum vor? Irgendwann stellen Sie vielleicht überrascht fest, dass etwas mit Ihrem Projekt nicht in Ordnung ist. Das seltsame daran ist, dass alles mit Ihrem Projekt in Ordnung zu sein scheint - Sie liegen im Plan, im Projekt sind alle zufrieden - es geht voran. Das Besorgniseregende ist, dass sich um das Projekt herum in- 116 zwischen soviel verändert hat, dass Ihr Projekt dadurch gefährdet ist. Beispiele dafür können sein: ! Ihr Unternehmen fusioniert mit einem anderen Unternehmen, dort gibt es bereits die Lösung an der Ihr Projekt gerade arbeitet. ! Als das Projekt gestartet wurde, hat keiner so recht an den Erfolg geglaubt, jetzt ist abzusehen, dass der Bedarf erheblich grösser ist, als angenommen. ! Der Projekttitel lautet „ProjectWare 2003“, als aktuelles Schlagwort für Ihre Thema hat sich aber „TimeTracing“ durchgesetzt. ! Der Auftraggeber für Ihr Projekt hat sich entschieden, die Zuständigkeiten neu zu organisieren. In Zukunft werden Ihre Ansprechpartner in drei ver- schiedenen Bereichen arbeiten, ein Bereich wird dabei als selbständiges Unternehmen ausgegliedert. ! Die Technologie, die als Plattform für Ihre Lösung dient, wird vom Her- steller vom Markt genommen. Diese Beispiele zeigen, dass es rund um das Projekt viele Veränderungen ge- ben kann, die Ihr Projekt zwar nur indirekt, dafür aber umso massiver, betref- fen können. Verkriechen Sie sich also nicht in einen „Elefenbeinturm“ son- dern gehen Sie mit den Veränderungen aktiv um: Spencer Johnson hat eine schöne Parabel über den Umgang mit Veränderun- gen geschrieben [Joh00]. Er beschreibt wie Mäuse und Menschen unterschied- lich reagieren, wenn man ihnen Ihren Käse wegnimmt. Während die Mäuse schnell loslaufen und sich neuen Käse suchen verbringen die Menschen noch viel Zeit mit Jammern und Lamentieren. Machen Sie es wie die Mäuse - rie- chen Sie täglich an Ihrem Käse, ob er noch frisch ist und reagieren Sie auf Veränderungen in Ihrem Projektumfeld rasch und ohne zu klagen. Beim Zwischenreview nach zwei Monaten Projektlaufzeit verkündet Hr. Auf- enberg freudig, das die Gründer AG ihren Firmensitz nach Frankfurt verlegen wird. Damit soll größere Nähe zu den Hauptkunden in der Bankbranche erreicht werden. Hr. Exner ist das Entsetzen ins Gesicht geschrieben - offensichtlich be- fürchtet er, dass er vor seinem Ruhestand noch einmal umziehen muss. Bei den Mitarbeitern von PV-Soft löst die Nachricht ebenfalls Unruhe aus. Das Projekt selbst scheint noch nicht betroffen, da der Umzug erst in 6 Monaten erfolgen soll. Was wird aber in der Wartungsphase geschehen? Wird es dann häufiger nötig sein nach Frankfurt zu fliegen? Insbesondere Fr. Teschner ist bei dem Ge- danken mulmig zu, da sie ungern fliegt. In den nächsten Tagen zeigt sich die positive Seite dieser Nachricht: die gefor- derte Eigenschaft „Internetfähigkeit“ des Projektverwaltungssystem war bisher von Hr. Exner und den anderen Gründer AG Mitarbeitern sehr stiefmütterlich behandelt worden. Meistenteils wurde dies als „neumodischer Schnickschack“ oder als völliger Unsinn angesehen, da ja alle Gründer - Mitarbeiter bisher über das hauseigene Computernetz direkt miteinander verbunden waren. Mit dem Umgang mit dem Zufall Erfolgsfaktor: Beachten Sie das Umfeld Ihres Projektes und reagieren Sie rechtzeitig und angemessen darauf. 117 Projektmanagement, Kommunikation, Politik bevorstehenden Verteilen auf mehrere Standorte und der persönlichen Betrof- fenheit der Mitarbeiter wandelt sich die Einstellung zu dem Thema radikal - nun steht dieser Punkt in vielen Gesprächen im Fokus. Fr. Probst beschliesst beim nächten Projektreview darauf besonders einzugehen. Die rechtzeitige Reaktion auf Änderungen im Projektumfeld kann für Ihr Pro- jekt überlebenswichtig sein. 7.8 Erfahrungen teilen Wie stellen Sie sicher, dass die Informationen, Erkenntnisse und Erfahrungen über die Sie im Projekt und in Ihrer Organisation verfügen nutzbringend ein- gesetzt werden? Wissen ist die wichtigste Voraussetzung für Ihre Problemlösungskompetenz. Sie finden es in den folgenden Formen vor: ! Explizites Wissen Schriftlich festgehaltenes Wissen, das in Form von Büchern, Zeitschriften, Video, CDs, Datenbanken, Internet und anderen Medien mehr oder weni- ger schnell zugreifbar ist. Dieses Wissen ist bereits kommuniziert und zu- gänglich gemacht. ! Implizites Wissen Stillschweigendes Wissen der Beteiligten, dass sich aus (gemeinsamen) Er- fahrungen ergibt. Dieses Wissen läßt sich nur schwer und mit großem Aufwand erfassen und in explizites Wissen überführen. ! Privates Wissen Das Wissen jedes einzelnen, dass sein spezifisches Weltbild prägt. ! Kollektives Wissen Ausgetauschte oder gemeinsam gemachte Erfahrungen, die innerhalb der gesamten Gruppe bekannt und verfügbar sind. ! Strukturiertes Wissen Systematisch auffindbares Wissen, dass leicht zugreifbar und durch seine Struktur gegliedert ist. ! Unstrukturiertes Wissen Dokumente, die unstrukturiert abgelegt sind, wie Berichte und Notizen so- wie nicht dokumentiertes implizites Wissen. In unseren Projekten haben wir die besten Erfahrungen mit einem unkompli- zierten Austausch von Informationen gemacht. Kernpunkte dafür sind: 118 Erfolgsfaktor: Betreiben Sie Wissensmanagement: sorgen Sie dafür, dass Erfahrungen gemacht, ausgetauscht und genutzt werden. ! gemeinsame elektronische Ablage von Dokumenten ! ein leicht zugängliches einheitliches elektronisches Diskussionforum (Pro- jekttagebuch) mit Querverweisen zu den elektronischen Dokumenten ! Zentraler und freier Zugang zu allen anden Medien (Bücher, Akten, Kun- dendokumente) Der Schlüssel zum Erfolg liegt dabei nicht in der angewendeten Technik - ent- scheidend ist die Bereitschaft der Beteiligten mitzumachen. Dafür muss eine Anfangshürde überwunden werden: jede gemeinsame Ablage von Wissen ist zunächst leer und damit uninteressant. Keiner mag den ersten Schritt tun und die Ablage füllen. Es schaut auch keiner rein, weil ja noch nichts da ist. Die ersten Wochen Projektarbeit sind in dieser Hinsicht die Wichtigsten. Wenn es Ihnen gelingt in dieser Zeit genug interessantes Material zusammenzutragen. Wenn dabei möglichst von allen Beteiligten Beiträge kommen, die fair verteilt sind, dann wird der weitere Austausch von explizitem Wissen ein Selbstläufer. Für den Austausch von impliziten Wissen ist räumliche Nähe und die Schaf- fung von Gelegenheiten zum ungezwungenenen Gespräch wichtig. Wolfgang Fahl hat bei seinem Praktikum bei Hewlett-Packard erlebt, wie einfach eine gute Atmosphäre dafür geschaffen werden kann: jeden Morgen gab es in einer Ecke des Grossraumbüros Kaffee und Brötchen umsonst. Niemand schaute darauf, ob die Pausenzeiten eingehalten wurden - denn normalerweise entwi- ckelten sich rund um die Kaffeepause abteilungsübergreifende Gespräche zu den Themen der Projekte. Über die Frühstücksecke war es auch wesentlich leichter einen Gespräch mit dem Entwicklungsleiter zu suchen als über seine Sekretärin einen Termin mit ihm zu ergattern ... Der Unterschied zwischen Unternehmenskulturen ist am Umgang mit Wissen sehr leicht zu spüren. In Beratungsunternehmen finden Sie zum Beispiel oft eine Kultur vor, in der jeder Einzelne sein Wissen sorgsam hütet. Ein Aus- tausch von Wissen findet nur äußerst ungern statt. Im Gegensatz dazu nutzen OpenSource-Projekte das Internet zum regen Austausch von Erfahrungen. Viele Details werden dort explizit und größtenteil unstrukturiert der Öffent- lichkeit und damit potentiellen Beteiligten präsentiert. 119 Erfahrungen teilen Projektmanagement, Kommunikation, Politik 7.9 Literatur [Bec00] K. Beck: Extreme Programming, Addison-Wesley, 2000 Das Manifest zum Thema extreme Programming - “XP”. [Bro75] F. P. Brooks: The Mythical Man-month - Essays on Software Engineering, Addison-Wesley, 1975 Klassiker indem die Aussage “Adding more people to a late project makes it later” geprägt wurde. [Coc01] A. Cockburn: Agile Software Development, Addison-Wesley, 2001 Credo für „Agilität“ - Menschen in Softwareprojekten arbeiten demnach am Besten, wenn Sie nicht in starre Raster gepresst wer- den sondern entlang eigener Vorstellungen angemessen agieren können. Softwareentwicklung wird als kooperatives, zielorientiertes Spiel betrachtet. [Con01] L. L. Constantine: The Peopleware Papers, Prentice-Hall, 2001 siehe Abschnitt 1.9. [Gla97] L. R. Glass: Software Runaways Monumental Software Di- saster, Pearson Professional Education, 1997 Sammlung der größten Softwarefehlschläge, die es je gegeben hat, z.B. Flughafen Denver und amerikanisches Flugüberwachungssys- tem. Sehr lehrreich für alle Arten von politischen Problemen in Projekten. [Joh00] S. Johnson: Die Mäuse-Strategie für Manager - Veränderungen erfolgreich begegnen, Hugendubel, 2000 Wer hat mir meinen Käse weggenommen? Eine Parabel rund um die Reaktion von Menschen und Mäusen zeigt klar auf, worauf es beim Umgang mit Veränderungen ankommt. [Kell01] H. Kellner: Die Kunst IT-Projekte zum Erfolg zu führen, Carl Hanser Verlag, 2001 Projektverantwortliche finden hier reichlich Tipps aus der Praxis, die helfen die Klippen und Untiefen eines Projektes sicher zu um- fahren. [You97] E. Yourdon: Death March, Prentice-Hall, 1997 Beantwortet die Frage „Wie kann man als Softwareentwickler Pro- jekte mit unmöglichen Zielen überleben?“ 120 „Die meisten Menschen haben einen heiligen Respekt vor Worten, die sie nicht begreifen können und betrachten es als Zeichen der Oberflächlichkeit des Autors, wenn sie ihn begreifen können.“ Albert Einstein 8 Computer-Fachbegriffe, -Anglizismen und -Abkürungen mit ihrer Überset- zung in möglichst einfache deutsche Sprache Literatur 8 Computerfachchinesischlexikon Begriff API Bug Bug Report Business Object CASE Change Request Feature Erklärung Application Program Interface - Zugriffsmöglichkeit für Anwendungsprogramme auf Funktionen einer Komponente über vordefinierte Schnittstellen. Fehler Fehlermeldung Geschäftsobjekt Computer Aided Software Engineering - Computer unterstützte systematische Softwareent- wicklung Änderungswunsch Eigenschaft Algorithmus Vorschriften zur Lösung meist mathematischer oder technischer Verfahren. Eine Art Kochre- zept für die Lösung eines Teilproblems, dass einem Computer gestellt werden soll. Der Algo- rithmus beschreibt detailliert und in einzelnen Schritten, wie aus den Vorgaben eines Problems die erwarteten Ergebnisse erzeugt werden. Euklid (ca. 300 v. Chr.) gilt als der „Erfinder“ des algorithmischen Ansatzes – der Begriff nimmt auf den arabischen Mathematiker Al-Kowarizmi (ca. 800 n. Chr.) Bezug. Assembler Ein Assembler (to assemble := zusammensetzen) ist ein Programmierwerkzeug mit dem sehr maschinennah programmiert werden kann. Im Gegensatz zu Programmiersprachen wie COBOL, C, Basic oder Pascal entspricht ein Ausdruck in Assembler mehr oder minder einer Maschinen-Anweisung, nur eben in von Menschen lesbarer Form. Divide & Conquer Teile und Herrsche - ein aus der Politik übernommener Begriff. Durch zerlegen eines Problems in kleinere Teile verringern sich die Widerstände zur Problemlösung. Die kleineren Probleme sind leichter beherrschbar als das ganze Problem. So läßt sich schrittweise ein großes zu- nächst möglicherweise unlösbar erscheinendes Problem bewältigen. Framework EIn Framework (abgeleitet aus dem englischen Begriff für Drahtgittermodell) bildet nur das Grundgerüst einer Softwarestruktur, ohne Inhalte oder Oberflächen zu beinhalten. Es besteht aus anpassbaren oder erweiterbaren Klassen. Als Modellform sind Frameworks sehr breit verwendbar, es ist jedoch die Anpassung an das spezielle Problem erforderlich. 121 Computerfachchinesischlexikon Begriff IDE J2EE MDA Patterns Opensource PDM PIM Release planning Software Configu- ration Manage- ment TBD T ool UML WYSIWYG XP Erklärung Integrated Development Environment - integrierte Entwicklungsumgebung Java 2 Enterprise Edition Eine Erweiterung der Java 2 Standard Edition (J2SE) zur Entwicklung und für den Betrieb von unternehmensweiten Applikationen. Model Driven Architecture - Modell getriebener Architekturansatz Entwurfsmuster. Beschreibung allgemein anerkannter und weit verbreiteter Muster für den Entwurf von Software in standardisierter Form (meist UML). Software deren Quellcode offen gelegt ist und anderen Entwicklung sich jeder Beteiligen kann, der möchte und die Regeln einhält, die von dem Rechteinhaber festgelegt worden sind. Die Software unterliegt einem entsprechend angepassten Urheberrecht. Platform dependend Model - von der Zielumgebung abhängiges Modell Platform independent model - von der Zielumgebgung unabhängiges Model Planung der nächsten Auslieferung über ein vorgegebenes Anforderungsprofil Die Verwaltung und Steuerung von Softwareversionen zur Prüfung und Freigabe. to be defined - noch nicht geklärter Sachverhalt - eine offene Frage Werkzeug Unified Modelling Language What you see is what you get - Die Anzeige während der Arbeitung entspricht dem später zu erwartenden Ergebnis extreme Programming - ein leichtgewichtiger Ansatz zur Softwareentwicklung der auf Vermei- dumg von Überflüssigem Balast und enge Kooperation der Beteiligten setzt Knowledge Ma- nagement Wissensmanagement Systematischer Ansatz, mit dem Informationen, Erkenntnisse und Erfahrungen (Wissen) ge- schaffen, gebündelt, verbreitet und ausgetauscht werden. Ziel ist, das Wissen möglichst ge- winnbringend zu verwerten und zum Nutzen der Organisation einzusetzen.. Use Case Anwendungsfall - Ein Anwendungsfall beschreibt einen abgegrenzten Bereich von Aktionen eines Systems aus der Sicht seiner Anwender, die für die Anwender zu einem wahrnehmbaren Ergebniss führen. Ein Anwendungsfall wird stets durch einen Anwender initiiert. Anwendungs- fälle werden vollständig beschrieben. 122 9 Anhänge 9 9.1 Liste der Erfolgsfaktoren Erfolgsfaktoren der Umfrage Seite Kurzbezeichnung 33 Anforderungen aufnehmen 41 Beispiele dokumen- tieren Beschreibung Nur wer rechtzeitig sagt, was er will, kann sicher gehen, dass er es auch bekommt. Nur das, was ich prüfen kann, kann ich auch beurteilen. Relevanz laut Umfrage Wert Rang Symbol 1,4 2 1,3 3 84 Frameworks einsetzen Der Einsatz von Frameworks, Komponenten und Klassenbibliotheken verkürzt ihre Entwicklungszeit und macht Ihre Lösung zukunftssicherer. 1,5 1 42 Anforderungen prio- risieren Die richtig priorisierte Auswahl der Anforderungen legt das zu realisierende Anforderungsprofil fest. 1,3 4 70 Komponenten ein- setzen Der Einsatz von Frameworks, Komponenten und Klassenbibliotheken verkürzt ihre Entwicklungszeit und macht Ihre Lösung zukunftssicherer. 1,3 4 72 Modularisierung (Teile und Herrsche) Zerlegen Sie Problem und Lö- sung schrittweise in kleinere von einander möglichst unabhängige Teile. 1,2 6 103 Entscheidungen fällen Treffen Sie ihre Entscheidungen entsprechend dem Risiko das damit zusammenhängt und tren- nen Sie die Klärung und die ei- gentliche Entscheidung. 1,2 6 104 Kommunikation 99 Iteratives Vorgehen Gestalten Sie aktiv alle Ebenen der Kommunikation entsprechend der Eisberg-Theorie. Schrittweise iterative oder inkre- mentelle Näherung an das Projektziel. 1,2 6 1,2 6 Fehle r! Text mark e nicht Team Fehler! Verweisquelle konnte nicht gefunden werden. 1,2 6 124 Liste der Erfolgsfaktoren Seite Kurzbezeichnung defini ert. 24 Sprache des Auf- traggebers sprechen 52 Modellieren 75 Patterns verwenden Planen 22 Klare Zieldefinition 54 Objektorientierung 87 Werkzeuge 115 Risikomanagement Beschreibung Sprechen Sie als Auftragnehmer die Sprache Ihres Auftraggebers! Erstellen Sie ein Modell der Realität. Vereinfachen und standardisieren Sie Ihre Entwürfe durch die Ver- wendung von Entwurfsmustern. Definieren Sie die Projektziele klar anhand von messbaren Krite- rien und festgelegten Werten. Verwenden Sie durchgängig den objektorientierten Ansatz. Wählen Sie Werkzeuge systema- tisch nach denen von Ihnen fest- gelegten Kriterien aus. Schätzen Sie Ihre Risiken ein und verfolgen Sie diese aktiv. Relevanz laut Umfrage Wert Rang Symbol 1,2 6 70 Klassenbibliotheken verwenden Der Einsatz von Frameworks, Komponenten und Klassenbibliotheken verkürzt ihre Entwicklungszeit und macht Ihre Lösung zukunftssicherer. 1,2 6 109 Begeisterung Begeisterung ist ansteckend. Sorgen Sie für die Verbreitung indem Sie das richtige Klima da- für schaffen. 1,2 6 1,1 14 1,0 16 0,9 17 0,9 17 0,8 21 0,8 21 0,8 21 20 Aufgabe, Ziel und Vorgehen klären Klären Sie zu Beginn des Projek- tes und bei Bedarf im weiteren Verlauf Aufgabenverständnis, Ziele und Vorgehen. 1,1 14 117 Projektumfeld be- achten Beachten Sie das Umfeld Ihres Projektes und reagieren Sie rechtzeitig und angemessen dar- auf. 0,9 17 118 Wissensmanage- ment betreiben Betreiben Sie Wissensmanage- ment: sorgen Sie dafür, dass Erfahrungen gemacht, ausge- tauscht und genutzt werden. 0,9 17 95 Versionsverwaltung Setzen Sie eine Ihren Bedürfnis- sen entsprechende Softwarever- sions- und Konfigurationsverwal- tung ein. 0,8 21 125 Seite Kurzbezeichnung 73 Problem und Lö- sung trennen Information Hiding (Kapselung) Abstrahieren Redundanzen ver- meiden Durch Messen ver- folgen können Computerrealität berücksichtigen Beschreibung Lösen Sie technische und fachli- che Probleme getrennt voneinan- der. Relevanz laut Umfrage Wert Rang Symbol 0,8 21 0,8 21 0,8 21 0,7 28 0,7 28 0,5 32 47 Änderungen be- rücksichtigen Stellen Sie sich aktiv darauf ein, dass es zu Änderungen der Anforderungen kommen wird und berücksichtigen Sie diese so früh wie möglich! 0,7 28 80 Änderungen be- rücksichtigen Verfolgen Sie die Feh- lermeldungen, Änderungswün- sche und Bitten um Hilfe Ihrer Anwender systematisch. 0,7 28 18 Vorgehensmodell Einigen Sie sich auf ein für Ihr Projekt geeignetes Vorgehens- modell und wenden Sie dieses aus Überzeugung an. 0,6 31 100 Verbindlichkeit Seien Sie verbindlich - machen Sie nur Versprechungen, die sie auch halten können. Halten Sie sich an Ihre Versprechen! 0,5 32 84 Infrastruktur Kümmern Sie sich rechtzeitig um eine adäquate und standardisier- te Infrastruktur/Arbeitsumgebung für Ihr Softwareprojekt. 0,4 33 126 Praxistipps der Autoren Seite Kurzbezeichnung Beschreibung Relevanz Symbol Liste der Erfolgsfaktoren 12 Problem vom Men- schen und vom Computer her be- trachten Betrachten Sie das zu lösende Probleme aus den zwei Blickwinkeln: 1. Vom Menschen aus 2. Vom Computer aus # 112 Projektmarketing Vertreten Sie Ihr Projekt nach aussen mit gutem Marketing und politischem Ge- schick. # 62 Verständlichkeit Achten Sie auf die Verständlichkeit Ihrer Spezifikationen und Modelle. # 127 Erfolgsfaktoren der CHAOS-Studie Seite Kurzbezeichnung 47 Förderung 106 Beteiligung der Anwender 111 Erfahrener Projektleiter Beschreibung Förderung durch die Verant- wortlichen. Identifizieren und beteiligen Sie alle Betroffenen, insbe- sondere die Anwender. Erfahrener Projektleiter. Relevanz laut Studie Prozent- Rang Symbol wert 18% 1 16% 2 14% 3 22 Klare Zieldefinition Definieren Sie die Projektziele klar anhand von messbaren Kriterien und festgelegten Werten. 12% 4 42 Anforderungen priorisieren (zum Minimalumfang) Die richtig priorisierte Auswahl der Anforderungen legt das zu realisierende Anforderungs- profil fest. 10% 5 84 (Standard) Soft- ware infrastruktur Kümmern Sie sich rechtzeitig um eine adäquate und stan- dardisierte Infrastruk- tur/Arbeitsumgebung für Ihr Softwareprojekt. 8% 6 48 Stabile Rahmen- anforderungen 47 Zuverlässige Schätzungen 110 Fähige Mitarbeiter Achten Sie darauf, dass die Rahmenanforderungen für Ihr Projekt stabil bleiben. Je zuverlässiger Ihre Schät- zungen sind, desto besser. Fähige Mitarbeiter. 6% 7 5% 9 5% 10 18 Verbindliches Vorgehen Einigen Sie sich auf ein für Ihr Projekt geeignetes Vorge- hensmodell und wenden Sie dieses aus Überzeugung an. 6% 8 128 9.2 Fragebogen Hier finden Sie den im Vorwort erwähnten Fragebogen, wie ihn Frau Probst ausgefüllt hat: In Softwareprojekten erfolgreich zu sein, ist oft ein schwieriges Unterfangen. Von den Erfahrungen anderer zu lernen, ist deshalb umso wichtiger. Unter www.b-agile.de (!!!) sammeln wir Erfolgsrezepte, die sich in Ihren Projekten als entscheidend herausge- stellt haben. Über Ihren Beitrag würden wir uns freuen und die Ergebnisse stellen wir im Web öffentlich vor. Bitte verwenden Sie fünf Minuten Ihrer wertvollen Zeit um einige repräsentative Pro- jekte, an denen Sie beteiligt waren, nach deren Erfolg zu bewerten. Fragebogen Bitte füllen Sie diesen Fragebogen für bis zu drei Ihrer Projekte aus. Angaben zu den Projekten Projekt 1 3 IT Auftrag extern Internet Projekt 2 Projekt 3 Größe (in Personenjahren) Branche Auftrag oder Produkt? Intern oder extern beauftragt? Zielplattform Besonderheiten Ablösung COBOL- Altsystem Weitere Angaben zur Beschreibung meines Projekts 1. 2. 3. Bitte bewerten Sie im nach Schulnoten (trifft 1: vollständig zu — 6: gar nicht zu). Mein Projekt ist / war Erfolgreich Weil ... Termin gehalten Kosten eingehalten Anforderungen erfüllt 2 2 3 1 Weitere zur Messung des Projekterfolgs herangezogene Kriterien: 1. Kundenzufriedenheit 1 2 2. Mitarbeiterzufriedenheit 129 Bitte verwenden Sie die folgende Bewertung für den Einfluss auf das Projekt: ++ stark gefördert, + gefördert, o nicht beeinflusst, - behindert, -- stark behindert Folgende Erfolgsrezepte haben das Projekt beeinflusst Anforderungen aufnehmen Beispiele dokumentieren Anforderungen priorisieren Änderungen berücksichtigen Problem und Lösung trennen Aufgabe, Ziel und Vorgehen klären Modellieren Projekt 1 Projekt 2 Angewendet Einfluss Angewendet Einfluss (&/-) (&/-) & ++ & ++ & ++ & ö & + & ++ & ++ & + Komponenten einsetzen Knowledge Management betreiben - Objektorientierung Information Hiding (Kapselung) Klare Zieldefinition Iteratives Vorgehen Abstrahieren Divide & Conquer (Modularisierung) Redundanzen vermeiden Durch Messen verfolgen können Infrastruktur Versionsmanagement Werkzeuge Risikomanagement Frameworks einsetzen - & + & ++ & ++ & + & o & ++ & o & + & o & + & o & o Patterns verwenden Klassenbibliotheken verwenden Planen Kommunikation Entscheidungen fällen Verbindlichkeit Begeisterung Team Vorgehensmodell Projektumfeld beachten Computerrealität berücksichtigen - & + & ++ & + & ++ & ++ & o & ++ & ++ & + & + Sprache des Auftraggebers sprechen & ++ 130 9.3 extreme Programming Best Practices extreme Programming Abbildung 9.1 Die Regeln für extreme Programming 131 9.4 Internet Referenzen [Url5] [Url6] [Url7] [Url8] [Url9] [Url10] [Url11] [Url12] http://www.standishgroup.com/chaos_chronicles/index.php Liste der Erfolgsfaktoren, die von der Standish Group durch Unter- suchung von über 35.000 Projekten seit 1994 zusammengetragen wurden. http://www.sdm.de/dt/tec/eve/2001/ppts/f_3_parnas.pdf Kurzweilige Beschreibung von David Parnas selbst, wie er auf das Information Hiding gekommen ist und wie dies noch heute Bedeu- tung behält. http://beat.doebe.li/bibliothek/ Interaktive Literaturliste, Begriffslexikon und Fragenkatalog http://webquality.ethz.ch/verstaendlichkeit/ Zur Buchreferenz siehe [Lan99] in Abschnitt 3.6, Online-Kurs und Austauschplattform zum Thema „Verständlichkeit“ http://webquality.ethz.ch/verstaendlichkeit/ Buchreferenz, Online-Kurs und Austauschplattform zum Thema „Verständlichkeit“ http://www.esi.es/VASIE/ “Best Practices“ Sammlung des Europäischen Softwareinstituts ESI. http://www.xprogramming.com Alles über extreme Programming (XP). http://www.well.com/user/smalin/miller.html Der Artikel [Mil56] von George Miller über die 7+/-2 Regel mit freundlicher Genehmigung des Autors im Internet veröffentlicht. 132 9.5 Literaturverzeichnis Literaturverzeichnis [Con01] [Joll93] [May01] [Mil56] [Par91] [Weiz78] L. L. Constantine: The Peopleware Papers, Prentice-Hall, 2001 R. L. Jolles: How to run Seminars and Workshops, John Wiley & Sons, 1993 H. Mayr: Projekt Engineering, Fachbuchverlag Leipzig, 2001 G. A. Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, The Psychological Review, 1956, vol. 63, pp. 81-97 D. L. Parnas, G. Asmis, and J. Madey: Assessment of Safety- Critical Software in Nuclear Power Plants. Nuclear Safety 32(2), 1991 J. Weizenbaum: Die Macht der Computer und die Ohnmacht der Vernunft, suhrkamp, 1978 133 9.6 Index abstrahieren 57 Aktion 41, 57 Algorithmus 58, 121 Änderungswunsch 80, 121, 126 Anforderung 32 Anforderungsaufnahme 14 Anforderungsprofil 34, 42 Anwendungsfall Assembler 64 Attribut 59 Aufgabe 19 Auftrag 14 Auftraggeber 12 Auftragnehmer 12 Begeisterung 109 Begriffe %Glossar Geheimnisprinzip 72 Geschäftsobjekt 17, 31 Geschäftsprozess 31 Geschäftsprozessanalyse Gliederung 62, 63 Glossar 24 IDE 83, 122 implizites Wissen 104 Implizites Wissen 118 Information Hiding % 14, 31 Beispielprojekt 21, 23, 24, 54 17, 66, 122 8, 10, 13, 16, 18, 20, Geheimnisprinzip Infrastruktur 16, 83 ISO 9000 % Qualität Iteratives Vorgehen 19 Klarheit 62 Klasse 59 Klassenbibliothek 76 Klassenbibliotheken 70, 124, 125 Klassendiagramm 56 Knowledge Management %Wissesnsmanagement Kollaborationsdiagramm 56 Kompliziertheit %Einfachheit Komponenten 32, 70, 124, 125 konzipieren 58 Kopplung 72 MDA Siehe Model Driven Architecture Meilensteine 99 Model Driven Architecture 95 Modell 52, 125 Modellierung 59 Modularisierung 72, 124 Objekt 59 objektorientierte Analyse 59 Offene Frage 39 Operation 59 Ordnung 62, 63 Patterns %Entwurfsmuster PDM Siehe platform dependent model PIM Siehe platform independent model Planungsspiel 114 Beziehung 59 Bindung 72 Brücke 2, 13, 16, 25 Brückenmetapher %Brücke Bug %Fehler Bug Report %Fehlermeldung Business Object %Geschäftsobjekt CASE 83 Change Request % Änderungswunsch CHAOS-Studie 5, 128 Divide & Conquer % Teile und Herrsche Einfachheit 62 Eisberg-Theorie Entscheidung 39 Entwurfsmuster 75, 122 Erfolgsfaktor 18 Erstinterview 16 Erwartetes Ergebnis Erwartungen 14, 100 Erwartungsmanagement Feature %Eigenschaft Fehler 80, 126 Fehlermeldung 80, 126 Frameworks 70, 76, 124, 125 134 103 41, 58 27, 100 Prägnanz 62 Projektauswahl % Geschäftsprozessanalyse Projektleiter 111 Projektmarketing 112, 127 Projektverwaltungs-Projekt % Beispielprojekt Prüfbeispiele 16, 38, 39, 42, 51 Qualität 21, 25 Rahmenanforderungen 31, 47 Release planning 122 % Anforderungsprofil Risiko 114 teile und herrsche 72, 95 Tool %Werkzeug Umfrage 5 UML 55, 65, 66, 91, 122 Unified Modelling Language %UML Use Case Siehe Anwendungsfall Verantwortung 57 Risikomanagement Schätzung 111 Situation 41 Softwarequalität %Qualität Softwareversion 92 strukturieren 57 tacit knowledge %implizites Wissen TBD %offene Frage Verbindlichkeit 14, 100 Versionsverwaltung 94 Verständlichkeit 41, 62, 127 Vorgehen 19 Vorgehensmodell 18 Weitschweifigkeit %Prägnanz Werkzeug 83 Werkzeugauswahl 87 Wissensmanagement Wunsch 14 WYSIWYG 122 Ziele 19 Zusammenhanglosigkeit %Gliederung 98, 125 98, 122, 125 135 Index Die Autoren Wolfgang Fahl Wolfgang Fahl hat in Aachen Informatik studiert. Bei den Unternehmen Hewlett-Packard und Dräger lernte er Software mit Fokus auf Qualität zu entwickeln. Als Verantwortlicher für Methoden und Verfahren betreute er über 30 Softwareprojekte für lebenserhaltende Systeme. Seit 1996 ist er als Berater für Unternehmen in den Bran- chen Versicherung, Banken, Telekommunikation und Versorgung tätig. In seiner Freizeit macht er bei Volkstriathlonveranstaltungen unter der Devise „Ankommen und nicht Letzter sein“ mit. Mit Frau Maria und Kindern Sandra und Martin trifft man ihn am Niederrhein auch schon mal auf einer Radtour an. Sie erreichen Ihn unter wf@bitplan.com. Frank Hoffmann Frank Hoffmann studierte Informatik an der Technischen Universität in Berlin, wo er auch seine ersten 28 Lebensjahre verbrachte. Seit 1990 beschäftigt er sich mit objektorientierten Methoden. Seine berufliche Karriere begann er deshalb auch bei microTOOL, einem der führenden Toolanbieter. Mit der stärkeren Fokussierung auf das Beratungs- und Trainingsgeschäft verschlug es ihn nach Nordrhein-Westfalen zunächst zu Rösch Consulting. 1999 gründete er zusammen mit Wolfgang Fahl und Martin Gummersbach mit der BITPlan GmbH ein eigenes Beratungsunternehmen. Seitdem hat er in zahlreichen Softwareprojekten Objektorientierung eingeführt und umgesetzt. Zu seiner Passion gehören Trainings, in denen er sein Wissen an mehrere Hundertschaf- ten wissensdurstiger Teilnehmer weitergegeben hat. In seiner Freizeit erwi- schen Sie ihn entweder vor der Stereoanlage beim Hören guter Musik oder - bei entsprechendem Wetter - auf einem der vielen Seen, auf denen er mit sei- ner Frau Chris segelt. Sie erreichen Ihn unter fh@bitplan.com. 136 Erfolgsfaktoren der Softwareentwicklung Eine Umfrage unter Software-Projektleitern untermauert es: Es sind immer wieder die gleichen Faktoren, die zum Erfolg von Software-Projekten beitra- gen und deren Fehlen das Scheitern von Projekten verursacht. Basierend auf dieser Umfrage und auf ihrer jahrelangen Erfahrung haben die Autoren in die- sem Buch die Erfolgsfaktoren zusammengestellt, die in jedem Softwareent- wicklungsprojekt beachtet werden sollten. Sie stellen Best Practices vor sowohl für den gesamten Entwicklungsprozess von der Analyse bis zur Implementierung als auch für die begleitenden Mana- gementaufgaben. „Weiche" Faktoren, die sich auf Menschen, Management und Politik beziehen, sind dabei genauso wichtig wie z.B. die Auswahl des richtigen und angemessenen Vorgehens. Die Autoren analysieren die Erfolgsfaktoren, zeigen, wie man sie umsetzen kann, und bieten ein durchgängiges, anschauliches Beispiel. So ist ein Leitfa- den entstanden, der zahlreiche Praxistipps und Best Practices enthält und Softwareentwicklern und Projektmanagern den Weg zum Erfolg zeigt.