Lerntext erarbeitet aus: Ian Sommerville, Software Engineering. 6. Auflage (dt.), München, LERNZIELE

Transkript

1 Projektmanagement 1 4 Projektmanagement Lerntext erarbeitet aus: Ian Sommerville, Software Engineering. 6. Auflage (dt.), München, LERNZIELE Ziel dieses Kapitels ist, einen Überblick über das Management von Softwareprojekten zu geben. Wenn Sie dieses Kapitel gelesen haben, werden Sie: die Unterschiede zwischen Softwareprojektmanagement und dem Projektmanagement in anderen Entwicklungsprojekten verstehen, die Hauptaufgaben eines Softwareprojektmanagers kennen; verstehen, warum Projektplanung bei allen Softwareprojekten unverzichtbar ist; verstehen, wie grafische Darstellungen (Balken- und Netzpläne) von Projektmanagern benutzt werden, um die zeitliche Planung darzustellen; den Vorgang des Risikomanagements kennen und einige Risiken kennen, die bei Softwareprojekten auftreten können. 1. Managementaufgaben 2. Projektplanung INHALT 3. Aufstellen eines Projektzeitplans 4. Risikomanagement Das Fehlschlagen vieler großer Softwareprojekte in den Sechzigern und frühen Siebzigern war ein Anzeichen für die Schwierigkeit des Softwaremanagements. Software wurde zu spät ausgeliefert, war unzuverlässig, kostete das Vielfache des Vorhergesehenen und legte oft schlechte Leistungen an den Tag (Brooks: "The Mythical Man-Month", 1975). Diese Projekte schlugen nicht fehl, weil Manager oder Programmierer inkompetent waren. Der Fehler lag im Management. Managementtechniken aus anderen technischen Disziplinen wurden einfach übernommen, waren aber für die Softwareentwicklung ineffektiv. Die Notwendigkeit eines Managements ist ein wichtiger Unterschied zwischen professioneller und "hobbymäßiger" Programmierung. Wir brauchen das Softwareprojektmanagement, weil die professionelle Softwareentwicklung immer Budget- und Zeitbeschränkungen unterliegt. Diese werden durch das Unternehmen festgelegt, das die Software entwickelt. Der Projektmanager muss sicherstellen, dass das Softwareprojekt diesen Beschränkungen gerecht wird, und Software abliefern, die die wirtschaftlichen Ziele erfüllt. Softwaremanager sind für die Konzeption und die Zeitplanung der Projektentwicklung verantwortlich. Sie überwachen die Arbeit, um sicherzustellen, dass sie nach den geforderten Maßstäben durchgeführt wird. Gutes Management kann den Erfolg eines Projekts nicht garantieren. Aber schlechtes Management führt gewöhnlich zum Fehlschlagen des Projekts. Die Software wird zu Notwendigkeit für Projektmanagement Aufgaben des Projektmanagers

2 2 Managementaufgaben spät ausgeliefert, kostet mehr als geplant und wird den Anforderungen nicht gerecht. Softwaremanager erledigen dieselbe Arbeit wie Projektmanager in anderen Entwicklungsbereichen. Jedoch unterscheidet sich die Softwareentwicklung von anderen Projekten in einigen Punkten, die das Softwaremanagement besonders schwierig machen können. Einige der Unterschiede sind: 1. Das Ergebnis ist nicht greifbar. Der Manager eines Schiffbauprojekts oder eines Bauvorhabens kann sehen, wie sich das Ergebnis entwickelt. Wird ein Zeitplan nicht eingehalten, ist die Wirkung auf das Produkt unmittelbar erkennbar. Teile der Struktur sind offensichtlich unfertig. Software ist hingegen nicht greifbar, denn sie kann nicht gesehen oder berührt werden. Softwareprojektmanager können den Fortschritt nicht wahrnehmen! Sie verlassen sich darauf, dass ihnen andere über den Fortschritt des Projekts Bericht erstatten. 2. Es gibt keinen standardisierten Softwareprozess. In den klassischen technischen Disziplinen mit einer langen Geschichte ist der Fertigungsprozess erprobt und getestet. Der Fertigungsprozess für Systeme wie eine Brücke ist wohlbekannt. Unser Verständnis des Softwareprozesses hat sich in den letzten Jahren zwar entscheidend weiterentwickelt, jedoch können wir nicht mit Sicherheit vorhersagen, wann ein bestimmter Softwareprozess Probleme bei der Entwicklung verursachen kann. Unterschied zwischen Software- und anderen Projekten 3. Große Softwareprojekte sind oft "einmalige" Projekte. Große Softwareprojekte unterscheiden sich fast immer von vorhergehenden Projekten. Es ist daher schwieriger, Probleme vorauszusehen. Weiter sind frühere Erfahrungen bei den schnellen technologischen Entwicklungen im Computer- und Kommunikationsbereich schnell überholt. Das aus diesen Erfahrungen Erlernte ist nicht oft auf neue Projekte übertragbar. Wegen dieser Probleme ist es nicht überraschend, dass einige Softwareprojekte das Budget überziehen und ihren Zeitplan überschreiten. Softwaresysteme sind oft neuartig und technisch innovativ. Innovative Entwicklungsprojekte in den klassischen Bereichen (wie beispielsweise neue Transportsysteme) haben ebenfalls oft Zeitplanprobleme. Unter den gegebenen Schwierigkeiten ist es bemerkenswert, dass so viele Softwareprojekte pünktlich ausgeliefert werden und innerhalb des Budgets liegen! Softwareprojektmanagement ist ein weites Feld und kann nicht mit einem einzigen Kapitel abgehandelt werden. Deshalb stelle ich in diesem Kapitel lediglich das Thema vor und beschreibe drei bedeutende Managementaufgaben. Sie lauten Projektplanung, Aufstellen eines Projektzeitplans und Risikomanagement. Spätere Kapitel (in Teil 6) befassen sich mit anderen Aspekten des Softwaremanagements, nämlich dem Umgang mit Menschen, der Schätzung von Softwarekosten und mit Qualitätsmanagement. 4.1 Managementaufgaben Man kann keine allgemeingültige Beschreibung der Aufgaben eines Softwaremanagers geben. Die Aufgabe verändert sich in Abhängigkeit vom Unternehmen und dem zu entwickelnden Softwareprodukt ganz erheblich. Die meisten Manager tragen

3 Projektmanagement 3 jedoch bis die Verantwortung für einige oder alle der folgenden Aufgaben: Erstellung des Angebots Projekt- und Zeitplanung Projektkostenkalkulation Projektüberwachung und Reviews Auswahl und Beurteilung des Personals Präsentationen und Erstellen von Berichten Die erste Etappe eines Softwareprojekts ist oft mit dem Erstellen eines Angebots zur Durchführung dieses Projekts. Das Angebot beschreibt die Ziele des Projekts und wie es durchgeführt werden soll. Es enthält normalerweise Schätzungen der Kosten und des Zeitplans, und es begründet, warum der Projektauftrag einem bestimmten Unternehmen oder Team erteilt werden soll. Das Erstellen des Angebots ist eine entscheidende Aufgabe, da die Existenz vieler Softwareunternehmen davon abhängt, ob genügend Angebote angenommen werden und Verträge zustande kommen. Es kann keine festen Richtlinien für diese Aufgabe geben; das Erstellen des Angebots ist eine Fertigkeit, die man durch Erfahrung erhält. Die Projektplanung legt die Aufgaben, Meilensteine und Lieferschritte eines Projekts fest. Anschließend muss ein Plan erstellt werden, um die Entwicklung zum Projektziel zu führen. Die Aufwandsschätzung ist eine verwandte Aufgabe, die die Abschätzung der benötigten Ressourcen zur Durchführung des Projektplans betrifft. Ich erörtere dieses Thema später in diesem Kapitel und in Kapitel 23 genauer. Die Projektüberwachung ist eine ständige Projektaufgabe. Der Manager muss den Überblick über den Fortschritt des Projekts behalten und die tatsächlichen Fortschritte und Kosten mit den geplanten vergleichen. Obwohl die meisten Unternehmen formelle Mechanismen zur Überwachung haben, kann sich ein geschickter Manager oft durch informelle Gespräche mit dem Projektpersonal ein Bild des Geschehens verschaffen. Durch solch informelle Überwachung können potenzielle Probleme beim Projekt erkannt werden. Schwierigkeiten werden enthüllt, sobald sie auftreten. Zum Beispiel könnten tägliche Sitzungen mit dem Projektpersonal Probleme beim Finden eines Softwarefehlers aufdecken. Anstatt auf eine Zeitplanüberschreitung zu warten, kann der Manager einen Experten auf das Problem ansetzen oder entscheiden, das Problem zu umgehen. Während eines Projekts ist es normal, dass das Projektmanagement eine Reihe von formellen Reviews vornimmt. Diese umfassen die Überprüfung des Gesamtfortschritts und der technischen Entwicklung des Projekts und die Bewertung des Projektstatus im Vergleich zu den Zielen des Auftraggebers. Die Entwicklungszeit eines großen Softwareprojekts kann mehrere Jahre betragen. Es ist fast sicher, dass sich die Ziele des Auftraggebers in dieser Zeit verändern. Diese Veränderungen können bedeuten, dass die Software nicht länger benötigt wird oder dass ursprüngliche Projektanforderungen nicht mehr gelten. Das Management kann entscheiden, die Softwareentwicklung zu stoppen oder das Projekt zu ändern, um es den Zielen des Auftraggebers anzupassen. Erstellen eines Angebots Projektplanung Projektüberwachung Reviews

4 4 Projektplanung Projektmanager müssen normalerweise die Menschen auswählen, die an dem Projekt arbeiten sollen. Ideal wäre, wenn fähiges Personal mit ausreichender Erfahrung für die Arbeit am Projekt zur Verfügung stünde. Jedoch müssen sich Manager in den meisten Fällen für ein Projektteam entscheiden, das dem Ideal nicht entspricht. Die Gründe dafür sind: Personalauswahl 1. Das Budget des Projekts kann den Einsatz von hoch bezahltem Personal nicht erlauben. Weniger erfahrenes, weniger gut bezahltes Personal muss eingesetzt werden. 2. Personal mit ausreichender Erfahrung ist oft weder innerhalb des Unternehmens noch außerhalb verfügbar. Es ist vielleicht unmöglich, neues Personal für das Projekt zu rekrutieren. Innerhalb des Unternehmens arbeiten die besten Leute meist schon an anderen Projekten. 3. Das Unternehmen will eventuell die Entwicklung seiner Mitarbeiter fördern. Unerfahrenes Personal wird deshalb einem Projekt zugeteilt, um zu lernen und Erfahrung zu sammeln. Der Softwaremanager muss innerhalb dieser Beschränkungen die Auswahl des Projektpersonals vornehmen. Jedoch sind Probleme wahrscheinlich, wenn nicht wenigstens ein Projektmitglied Erfahrung mit der Art des zu entwickelnden Softwaresystems hat. Ohne diese Erfahrung sind auch einfache Fehler kaum zu vermeiden. Ich erörtere die Teambildung und Personalauswahl in Kapitel 22. Gewöhnlich ist der Projektmanager dafür verantwortlich, sowohl dem Kunden als auch dem Hersteller über das Projekt Bericht zu erstatten. Projektmanager müssen knappe, zusammenhängende Berichte schreiben, welche die wichtigsten Informationen aus detaillierten Projektberichten enthalten. Sie müssen in der Lage sein, diese Informationen während der Reviews über den Projektfortschritt zu präsentieren. Deshalb ist die Fähigkeit zu effektiver Kommunikation, sowohl mündlich wie schriftlich, eine unverzichtbare Fertigkeit eines Projektmanagers. Bericht erstatten 4.2 Projektplanung Das effektive Management eines Softwareprojekts hängt von der gründlichen Planung des Projektablaufs ab. Der Projektmanager muss mögliche Probleme vorhersehen und vorläufige Lösungen der Probleme vorbereiten. Ein am Beginn des Projekts erstellter Plan sollte als Leitfaden für das Projekt dienen. Dieser anfängliche Plan sollte der bestmögliche Plan unter Berücksichtigung der verfügbaren Informationen sein. Er entwickelt sich weiter, wenn das Projekt fortschreitet und bessere Informationen verfügbar werden. Die Struktur eines Plans zur Softwareentwicklung wird in Abschnitt beschrieben. Neben dem Projektplan müssen Manager auch andere Arten von Plänen erstellen. Diese werden in Tabelle 4.1 kurz erklärt und in dem darauf bezogenen Kapitel an einer anderen Stelle des Buchs detaillierter behandelt.

5 Projektmanagement 5 Plan Qualitätsplan Validierungsplan Wartungsplan Konfigurationsmanagementplan Personalentwicklungsplan Tabelle 4.1: Arten von Plänen Beschreibung Welche Qualitätsmaßnahmen und -standards werden in dem Projekt verwendet? (siehe Kapitel 24) Welche Methoden, Ressourcen und welcher Zeitplan gelten für die Systemvalidierung (den Gesamttest)? (siehe Kapitel 19) Welche Prozeduren und Strukturen sind für das Konfigurationsmanagement einzusetzen? (siehe Kapitel 29) Welche Wartungsanforderungen stellt das System, welche Wartungskosten und welcher Aufwand ist nötig? (siehe Kapitel 27) Wie werden die Fähigkeiten und die Erfahrung der Mitglieder des Projektteams gefördert? (siehe Kapitel 22) Der Pseudocode in Listing 4.1 beschreibt den Prozess der Projektplanung für die Softwareentwicklung. Er zeigt, dass Planung ein sich wiederholender Prozess ist, der erst dann endet, wenn das Projekt selbst abgeschlossen ist. Sobald während des Projekts neue Informationen verfügbar werden, muss der Plan überarbeitet werden. Die wirtschaftlichen Gesamtziele sind ein wichtiger Faktor, der bei der Erstellung des Projektplans berücksichtigt werden muss. Ändern sich diese Ziele, so sind Änderungen am Projektplan notwendig. Prozess der Projektplanung Randbedingungen aufstellen Erste Einschätzungen der Projektgrößen treffen Die Meilensteine und Lieferschritte des Projekts definieren while Projekt nicht fertiggestellt oder abgebrochen loop Projektzeitplan aufstellen Aktivitäten gemäß Zeitplan beginnen (einige Zeit) warten Projektfortschritt überprüfen Schätzungen der Projektparameter überarbeiten Projektzeitplan auf den neuesten Stand bringen Nochmals über Randbedingungen und Lieferschritte verhandeln if (Probleme auftreten) then Technischen Review und mögliche Überarbeitung einleiten end if end loop Listing 4.1: Projektplanung Der Planungsprozess beginnt mit dem Festsetzen der Randbedingungen (gefordertes Auslieferungsdatum, verfügbares Personal, Gesamtbudget usw.), denen das Projekt unterliegt. Dies geschieht in Verbindung mit einer Einschätzung der Projektgrößen, also der Struktur, der Größe und der zu leistenden Dienste. Anschließend werden Fortschrittsmeilensteine und -lieferschritte festgelegt. Dann tritt der Prozess in eine Art Schleife ein. Es wird ein Zeitplan für das Projekt erstellt und mit den im Zeitplan festgelegten Randbedingungen, Projektgrößen

6 6 Projektplanung Aufgaben begonnen bzw. die Erlaubnis zur Fortsetzung gegeben. Nach einiger Zeit (normalerweise etwa 2-3 Wochen) wird der Fortschritt auf Abweichungen überprüft, die dabei festgehalten werden. Da anfängliche Schätzungen der Projektparameter nur vorläufig sind, wird der Plan immer wieder geändert werden müssen. Projektmanager überarbeiten die Annahmen über das Projekt immer dann, wenn neue Informationen verfügbar werden. Sie gestalten den Zeitplan um. Verzögert sich das Projekt, müssen sie mit dem Kunden erneut über die Randbedingungen des Projekts und Lieferschritte verhandeln. Verläuft diese Verhandlung nicht erfolgreich und kann der Zeitplan nicht eingehalten werden, sollte ein technischer Review des Projekts erfolgen. Ziel dieses Reviews ist es, einen alternativen Weg in der Entwicklung zu finden, der die Randbedingungen und den Zeitplan einhält. Natürlich gehen kluge Projektmanager nicht davon aus, dass alles gut verlaufen wird. Probleme treten während eines Projekts fast immer auf. Die anfänglichen Annahmen und Zeitpläne sollten eher pessimistisch als optimistisch sein. Der Plan sollte genügend Spielraum enthalten, damit die Randbedingungen nicht bei jedem Planungsdurchlauf erneut verhandelt werden müssen. Ändern der Pläne Der Projektplan Der Projektplan teilt die verfügbaren Ressourcen für das Projekt, die Arbeit und den Zeitplan dafür ein. In einigen Unternehmen ist der Projektplan ein einziges Dokument, das alle weiter oben vorgestellten Pläne enthält. In anderen Fällen bezieht sich der Projektplan ausschließlich auf den Entwicklungsprozess. Verweise auf andere Pläne sind zwar enthalten, aber die Pläne selbst existieren voneinander getrennt. Die Struktur des Plans, den ich hier beschreibe, gilt für die letztere Art. Abhängig von der Art des Projekts und des Unternehmens variieren die Details des Projektplans. Jedoch sollten die meisten Pläne folgende Abschnitte enthalten: Struktur eines Projektplans 1. Einführung: Dieser Teil beschreibt die Ziele des Projekts und legt die Randbedingungen (z.b. Budget, Zeit usw.) für das Projektmanagement fest. 2. Projektorganisation: Dieser Teil gibt Auskunft über die Organisation des Entwicklungsteams, die beteiligten Personen und ihre Rollen im Team. 3. Risikoanalyse: Dieser Teil beschreibt mögliche Projektrisiken, die Wahrscheinlichkeit für deren Auftreten und vorgeschlagene Strategien zur Risikoreduzierung. Risikomanagement wird in Abschnitt 4.4 behandelt. 4. Anforderungen an Hard- und Softwareressourcen: Dieser Teil beschreibt die benötigte Hardware und Software zur Durchführung der Entwicklung. Für anzuschaffende Hardware und Software sollten Angaben über Kosten und Lieferzeiten enthalten sein. 5. Arbeitsaufteilung: Dieser Teil beschreibt die Aufteilung des Projekts in verschiedene Aufgabenbereiche und stellt die Meilensteine und Lieferschritte vor, die mit jeder Aufgabe verbunden sind. Meilensteine und Lieferschritte werden in Abschnitt behandelt.

7 Projektmanagement 7 6. Projektzeitplan: Dieser Teil beschreibt die Abhängigkeiten zwischen den Aufgaben, die geschätzte Zeit zum Erreichen eines jeden Meilensteins und die Zuordnung der Menschen zu verschiedenen Aufgaben. 7. Überwachungs- und Berichterstattungsmechanismen: Dieser Teil beschreibt die zu erstellenden Managementberichte, wann diese erstellt werden sollten und die zu einzusetzenden Überwachungsmechanismen. Der Projektplan sollte während des Projekts regelmäßig überarbeitet werden. Einige Teile, wie der Projektzeitplan, werden sich ständig verändern, andere beständiger bleiben. Die Dokumentenverwaltung muss unkompliziertes Ersetzen von Abschnitten ermöglichen Meilensteine und Lieferschritte Manager benötigen Informationen. Da Software nicht greifbar ist, können diese Informationen nur in Form von Berichten bereitgestellt werden, die den Status der zu entwickelnden Software beschreiben. Ohne diese Informationen ist es unmöglich, den Fortschritt zu bewerten oder Aufwandsschätzungen und Zeitpläne zu aktualisieren. Bei der Planung des Projekts sollte eine Reihe von Meilensteinen festgelegt werden, wobei ein Meilenstein den Endpunkt einer Aufgabe der Softwareentwicklung darstellt. An jedem Meilenstein sollte eine formelle Erklärung, zum Beispiel ein Bericht, abgegeben werden, die dem Management vorgelegt werden kann. Meilensteinberichte müssen keine großen Dokumente sein, sondern können einfach nur das bei einer Projektaufgabe Erreichte kurz zusammenfassen. Meilensteine sollten das Ende eines Teils oder logischen Abschnitts der Entwicklung darstellen. Nicht eindeutige Meilensteine, wie»programmierung zu 80 Prozent abgeschlossen«, die unmöglich zu überprüfen sind, sind für das Projektmanagement nutzlos. Ein Lieferschritt ist ein Projektresultat, das an den Kunden ausgeliefert wird, wobei die Auslieferung normalerweise am Ende einer wichtigen Projektphase erfolgt wie zum Beispiel nach der Spezifikation, dem Entwurf usw. Meilenstein Abbildung 4.1 : Meilensteine im Anforderungsprozess größer Lieferschritte sind auch Meilensteine, aber nicht jeder Meilenstein muss ein Lieferschritt sein. Bei Meilensteinen sind z.b. interne Projektresultate, die der Projektmanager zur Überprüfung des Projektfortschritts benutzt, die aber nicht an den Kunden geliefert werden. Um Meilensteine zu erhalten, muss die Softwareentwicklung in Grundaufgaben mit dazu gehörenden Lieferschritt

8 8 Aufstellen eines Projektzeitplans Ergebnissen aufgeteilt werden. Als Beispiel zeigt Abbildung 4.1 Aufgaben im Zusammenhang mit der Anforderungsspezifikation, wobei zur Überprüfung der Anforderungen Prototypen eingesetzt werden. Die wichtigsten Ergebnisse jeder Aufgabe (die Projektmeilensteine) werden dargestellt. Lieferschritte sind in diesem Beispiel die Benutzer- und die Systemanforderungen. 4.3 Aufstellen eines Projektzeitplans Das Aufstellen eines Projektzeitplans ist eine besonders anspruchsvolle Aufgabe eines Softwaremanagers. Manager schätzen die benötigte Zeit und die benötigten Ressourcen zum Abschließen der Aufgaben und bringen diese in eine zusammenhängende Abfolge. Außer wenn das Projekt einem vorangegangenen Projekt gleicht, sind vorherige Schätzungen eine ungenaue Basis für das Aufstellen eines Zeitplans für ein neues Projekt. Die Zeitplanabschätzung wird dadurch noch komplizierter, dass verschiedene Projekte andere Entwurfsmethoden und Programmiersprachen verwenden. Wenn das Projekt technisch anspruchsvoll ist, sind anfängliche Schätzungen selbst dann zu optimistisch, wenn Manager versuchen, alle Eventualitäten einzukalkulieren. In dieser Hinsicht unterscheidet sich das Aufstellen eines Zeitplans für die Softwareentwicklung nicht von allen anderen großen, anspruchsvollen Projekten. Neue Flugzeuge, Brücken und sogar neue Automodelle verzögern sich häufig wegen nicht vorhergesehener Probleme. Zeitpläne müssen daher beim Eintreffen besserer Informationen über den Fortschritt ständig aktualisiert werden. Das Aufstellen eines Projektzeitplans (Abbildung 4.2) umfasst die Aufteilung der Gesamtarbeit eines Projekts in verschiedene Aufgaben, ebenso die Beurteilung der benötigten Zeit zur Fertigstellung dieser Aufgaben. Normalerweise werden einige der Aufgaben parallel durchgeführt. Projektplaner müssen diese parallel ausgeführten Aufgaben so koordinieren, dass die Arbeitskraft optimal ausgenutzt wird. Sie müssen Situationen vermeiden, in denen sich das ganze Projekt verzögert, weil ein wichtiger Teil noch nicht fertig gestellt ist. Aufstellen und Pflege eines Projektzeitplans Bestandteile des Projektzeitplans Abbildung 4.2: Ablauf der Zeitplanung größer Projektaufgaben sollten mindestens eine Woche dauern. Eine feinere Aufteilung würden bedeuten, dass eine überproportional große Zeit auf die Abschätzung und Diagrammüberarbeitung verwendet werden müsste. Es ist auch nützlich, die maximale Zeit für eine Aufgabe auf acht bis zehn Wochen festzusetzen. Dauert sie Größe von Projektaufgaben

9 Projektmanagement 9 länger, so sollte sie für die Projekt- und Zeitplanung aufgeteilt werden. Bei der Abschätzung von Zeitplänen sollten Manager nicht annehmen, dass jede Etappe des Projekts problemfrei sein wird. Am Projekt mitarbeitende Menschen können krank werden oder kündigen, Hardware kann ausfallen, und unverzichtbare Unterstützungssoftware oder -hardware kann zu spät geliefert werden. Ist das Projekt neu und technisch anspruchsvoll, können sich gewisse Teile als schwieriger herausstellen und länger dauern als ursprünglich erwartet. Neben der Zeit müssen Manager auch die Ressourcen zur Fertigstellung jeder Aufgabe kalkulieren. Die Hauptressource ist die benötigte menschliche Arbeitskraft. Andere Ressourcen sind der erforderliche Festplattenspeicher auf einem Server, die Zeit für den Betrieb spezieller Hardware, zum Beispiel eines Simulators, und das nötige Reisebudget des Projektpersonals. Ich beschäftige mich mit der Kalkulation dieser Faktoren in Kapitel 23 eingehender. Ein gute Vorgehensweise ist, zunächst den Fall zu kalkulieren, bei dem nichts schief läuft, und dann die Kalkulation zu erweitern, um erwartete Probleme zu behandeln. Ein weiterer Eventualitätsfaktor kann zur Behandlung unerwarteter Probleme hinzugefügt werden. Dieser zusätzliche Faktor hängt vom Typ des Projekts, den Entwicklungsparametern (Termin, Standards usw.) und der Qualität und Erfahrung der an dem Projekt tätigen Softwareentwickler ab. Als eine Faustregel addiere ich für erwartete Probleme immer 30 Prozent und für die Behandlung von mir nicht erwarteter Dinge weitere 20 Prozent zu meiner ursprünglichen Kalkulation hinzu. Der Projektzeitplan wird gewöhnlich durch eine Reihe von Diagrammen dargestellt, die die Arbeitsaufteilung, die Abhängigkeiten der Aufgaben und die Personalzuteilungen aufzeigen. Diese Diagramme werden im folgenden Abschnitt behandelt. Mittlerweile kommen für die automatische Erstellung solcher Diagramme in der Regel Werkzeuge für das Softwaremanagements wie Microsoft Project zum Einsatz. Berücksichtigen von Problemen Balkendiagramme und Netzpläne Balkendiagramme und Netzpläne sind grafische Notationen, die zur Darstellung des Projektzeitplans benutzt werden. Balkendiagramme zeigen, wer für jede Aufgabe verantwortlich ist und wann die Aufgabe gemäß Zeitplan beginnen und enden soll. Netzpläne stellen die Abhängigkeiten zwischen den verschiedenen Aufgaben dar, aus denen sich das Projekt zusammensetzt. Balken- und Netzpläne können mit Hilfe einer Datenbank mit Projektinformationen und eines Projektmanagementwerkzeugs automatisch erzeugt werden. Diagramme zur Darstellung des Projektzeitplans Aufgabe Dauer (in Tagen) Abhängigkeiten T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1)

10 10 Aufstellen eines Projektzeitplans T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) Tabelle 4.2: Dauer von Aufgaben und Abhängigkeiten Sehen Sie sich die in Tabelle 4.2 gezeigten Aufgaben an. Diese Tabelle stellt die Aufgaben, ihre Dauer und die Abhängigkeiten zwischen den Aufgaben dar. Aus Tabelle 4.2 können Sie ersehen, dass Aufgabe T3 von Aufgabe T1 abhängt. Das bedeutet, T1 muss abgeschlossen sein, bevor T3 beginnt. Zum Beispiel könnte T1 die Vorbereitung des Entwurfs für eine Komponente sein, während T3 die Implementierung dieses Entwurfs ist. Bevor die Implementierung beginnt, sollte der Entwurf fertig sein. Mit den gegebenen Abhängigkeiten und der geschätzten Dauer aller Aufgaben kann ein Netzplan erstellt werden, der die Aufgabenabfolge darstellt (Abbildung 4.3). Er zeigt, welche Aufgaben parallel ausgeführt werden können und welche nacheinander durchgeführt werden müssen, weil eine Abhängigkeit zu einer früheren Aufgabe besteht. Aufgaben werden als Rechtecke dargestellt, während Meilensteine und Lieferschritte abgerundete Ecken aufweisen. Die Datumsangaben im Diagramm zeigen das Datum des Meilensteins bzw. die Dauer der Aufgabe an. Sie sollten den Netzplan von links nach rechts und von oben nach unten lesen. Aufgaben in einem beispielhaften Projekt Netzplan Start T4 10 Tage M T5 10 Tage T6 5 Tage M T10 15 Tage Ende M T8 25 Tage T12 10 Tage T1 8 Tage M T7 20 Tage T11 7 Tage M T3 15 Tage M T9 15 Tage M T2 15 Tage M Abbildung 4.3: Ein Netzplan (erstellt mit MS Project 2000) größer Bevor von einer zur nächsten Aufgabe fortgeschritten werden kann, müssen alle Pfade dorthin fertig gestellt sein. Zum Beispiel kann Aufgabe T9 aus Abbildung 4.3 nicht begonnen werden, bevor nicht T3 und T6 beendet sind. Das Erreichen von Meilenstein M4 zeigt, dass diese Aufgaben abgeschlossen wurden. Die minimale benötigte Zeit zur Fertigstellung des Projekts kann durch das Berücksichtigen des längsten (so genannten kritischen) Pfades aus dem Netzplan abgeschätzt werden. In diesem Fall beträgt dieser elf verstrichene Wochen oder 55 Arbeitstage. In Abbildung 4.3 ist der kritische Pfad als eine Folge von fettgedruckten Kästen dargestellt. Der Gesamtzeitplan eines Kritischer Pfad

11 Projektmanagement 11 Projekts hängt vom kritischen Pfad ab. Jeder Fehler bei der Fertigstellung einer kritischen Aufgabe führt zur Verzögerung des Projekts. Verzögerungen bei Aufgaben, die nicht auf dem kritischen Pfad liegen, lösen jedoch nicht unbedingt eine Verzögerung im Gesamtzeitplan aus. Solange die Verzögerungen die Aufgaben nicht so sehr verlängern, dass die Zeit des kritischen Pfades überschritten wird, wird der Projektzeitplan nicht beeinflusst. Wenn sich zum Beispiel Aufgabe T8 verzögert, muss sich das nicht unbedingt auf das Abschlussdatum des Projekts auswirken, da die Aufgabe nicht auf dem kritischen Pfad liegt. Das Balkendiagramm des Projekts (Abbildung 4.4) zeigt den Umfang der möglichen Verzögerungen als schattierten Balken. Manager verwenden Netzpläne auch zur Zuteilung von Projektarbeit. Diagramme können Einblicke in Projektabhängigkeiten liefern, die nicht intuitiv erkennbar sind. Es könnte möglich sein, den Systementwurf so zu modifizieren, dass der kritische Pfad verkürzt wird. Der Projektzeitplan könnte verkürzt werden, wenn die Wartezeit auf die Komplettierung von Aufgaben geringer wird. Abbildung 4.4 zeigt eine alternative Art der Darstellung von Informationen über den Projektzeitplan: ein Balkendiagramm (manchmal nach seinem Erfinder ein Gantt-Diagramm genannt), das einen Projektzeitplan und die Start- und Endzeiten der Aufgaben aufzeigt. Balkendiagramm Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Ende Abbildung 4.4: Ein Balkendiagramm (erstellt mit MS Project 2000) In einer anderen Darstellung (vgl. Abb. 4.5) folgt manchen Aufgaben ein dünner Balken, deren Länge durch die Planungssoftware ermittelt wurde und die andeutet, dass es eine gewisse Flexibilität beim Beendigungsdatum dieser Aufgaben gibt (sogenannter "Puffer"). Ist eine Aufgabe nicht pünktlich fertig, wird der kritische Pfad bis zum Ende der Pufferzeit nicht beeinflusst. Aufgaben, die auf dem kritischen Pfad liegen, haben keinen zeitlichen Spielraum

12 12 Aufstellen eines Projektzeitplans und können dadurch erkannt werden, dass sie keinen Puffer besitzen. Genauso wie Zeitpläne müssen Manager auch die Aufteilung von Ressourcen und besonders die Zuteilung des Personals auf Projektaufgaben beachten. Tabelle 4.3 schlägt eine Zuteilung des Personals zu den in Abbildung 4.4 dargestellten Aufgaben vor. Tabelle 4.3 kann auch mit Hilfe spezieller Projektmanagementwerkzeuge erstellt werden. Entsprechend ist es möglich, ein Balkendiagramm zu erstellen, das die Zeitperioden zeigt, in denen das Personal am Projekt tätig ist (Abbildung 4.5). Das Personal muss nicht ständig einem Projekt zugeordnet sein. In der Zwischenzeit könnten die Mitarbeiter ihren Urlaub nehmen, an anderen Projekten arbeiten, an Schulungen teilnehmen oder einer anderen Aktivität nachgehen. Große Organisationen stellen in der Regel eine Reihe von Spezialisten ein, die an einem Projekt arbeiten, wenn sie benötigt werden. Dies kann Zeitplanprobleme verursachen. Verzögert sich ein Projekt, an dem ein Spezialist arbeitet, kann das einen schweren Schlag für andere Projekte bedeuten. Diese können sich ebenfalls verzögern, weil der Spezialist nicht verfügbar ist. Zuteilung von Personal und Ressourcen Aufgabe Entwickler T1 Heinzelmann T2 Maier T3 Heinzelmann T4 Meißner T5 Suárez T6 Maier T7 Weiß T8 Meißner T9 Heinzelmann T10 Maier T11 Meißner T12 Meißner Tabelle 4.3: Zuweisung von Aufgaben an Mitarbeiter

13 Projektmanagement Heinzelmann Heinzelmann Heinzelmann Maier Maier Maier Meißner Meißner Meißner Meißner Suárez Weiß Abbildung 4.5: Belegung von Mitarbeitern über die Zeit, mit Puffern (erstellt mit MS Project 2000) Dass die ersten Projektzeitpläne Fehler enthalten, lässt sich nicht vermeiden. Im Verlauf eines Projekts sollten die Schätzungen mit der verstrichenen Zeit verglichen werden. Dieser Vergleich kann als Grundlage zur Überarbeitung des Zeitplans für spätere Teile des Projekts verwendet werden. Sind aktuelle Werte bekannt, sollte der Netzplan nochmals überprüft werden. Danach ist es möglich, spätere Projektaufgaben neu zu organisieren, um die Länge des kritischen Pfades zu verkürzen. 4.4 Risikomanagement Eine weitere wichtige Aufgabe eines Projektmanagers ist, Risiken vorauszusehen, die sich auf den Zeitplan oder die Qualität der entwickelten Software auswirken könnten, und Maßnahmen zur Vermeidung dieser Risiken zu ergreifen. Die Ergebnisse der Risikoanalyse sollten zusammen mit den sich aus einem auftretenden Risiko ergebenden Konsequenzen im Projektplan dokumentiert sein. Das Erkennen von Risiken und das Erstellen von Plänen zur Minimierung der Auswirkungen auf das Projekt wird Risikomanagement genannt (Hall, 1998; Ould, 1999). Vereinfachend kann man ein Risiko als die Wahrscheinlichkeit dafür betrachten, dass ein nachteiliger Umstand tatsächlich auftreten wird. Risiken können das Projekt, die entwickelte Software und das Unternehmen gefährden. Man unterscheidet folgende Kategorien von Projektrisiken: Risikomanagement = Risikoanalyse + Konsequenzen 1. Projektrisiken sind Risiken, die sich auf den Projektzeitplan oder die Ressourcen auswirken. 2. Produktrisiken sind Risiken, die die Qualität oder die Leistung der entwickelten Software beeinträchtigen. 3. Wirtschaftliche Risiken sind Risiken, die sich auf das Unternehmen auswirken, welches das Projekt entwickelt oder beschafft. Risikomanagement ist wegen der in den meisten Softwareprojekten enthaltenen Unwägbarkeiten besonders wichtig. Diese stammen aus ungenau definierten Anforderungen, Arten von Risiken

14 14 Risikomanagement Schwierigkeiten bei der Kalkulation der für die Softwareentwicklung benötigten Zeit und Ressourcen, Abhängigkeiten von den Fähigkeiten einzelner Mitarbeiter und Veränderungen der Anforderungen durch geänderte Bedürfnisse des Kunden. Der Projektmanager sollte Risiken voraussehen, deren Auswirkungen auf das Projekt, das Produkt und den Betrieb verstehen und Schritte zur Vermeidung dieser Risiken unternehmen. Notfallpläne können so aufgestellt werden, dass beim Eintreten eines Risikos sofort eine Rettungsaktion durchgeführt werden kann. Der Ablauf des Risikomanagements besteht aus den folgenden Schritten: 1. Risikoerkennung: Bestimmung möglicher Projekt-, Produkt- und wirtschaftlicher Risiken 2. Risikoanalyse : Beurteilung von Wahrscheinlichkeit und Konsequenzen dieser Risiken 3. Risikoplanung: Aufstellen von Plänen zur Begegnung des Risikos durch Umgehen oder durch das Minimieren seiner Auswirkungen 4. Risikoüberwachung: Ständiges Überprüfen des Risikos und Überarbeiten der Pläne zur Risikominimierung, sobald mehr Informationen über das Risiko verfügbar werden Bei der Risikoanalyse werden alle erkannten Risiken der Reihe nach betrachtet, ihre Wahrscheinlichkeit und ihre Konsequenzen beurteilt. Es gibt hierzu keinen einfachen Weg alles hängt vom Urteilsvermögen und der Erfahrung des Managers ab. Diese Analysen sollten im Allgemeinen keine genauen zahlenmäßigen Bewertungen sein, sondern auf einer Reihe von Zahlenbereichen basieren: 1. Die Wahrscheinlichkeit des Risikos kann als sehr gering (<10%), niedrig (10-25%), mittel (25-50%), hoch (50-75%) oder sehr hoch (>75%) eingeschätzt werden. 2. Die Auswirkungen des Risikos können als katastrophal, ernst, tolerierbar oder unbedeutend eingeschätzt werden. Die Resultate dieses Analyseprozesses sollten dann tabellarisch angeordnet werden, wobei die Tabelle nach der Bedeutung des Risikos sortiert ist. Tabelle 4.4 veranschaulicht dies. Offensichtlich ist die Beurteilung der Wahrscheinlichkeit und der Schwere der Konsequenzen hier willkürlich. In der Praxis benötigt man detaillierte Informationen über das Projekt, die Entwicklung, das Entwicklungsteam und das Unternehmen, um diese Beurteilung vorzunehmen. Risiko Finanzielle Probleme des Unternehmens zwingen zu Kürzungen des Projektbudgets. Es ist unmöglich, genügend Personal mit den für das Projekt benötigten Fähigkeiten zu rekrutieren. Schlüsselpersonen werden zu wichtigen Zeitpunkten des Projekts krank. Wahrscheinlichkeit niedrig hoch mittel Auswirkungen katastrophal katastrophal ernst

15 Projektmanagement 15 Zur Wiederverwendung vorgesehene Softwarekomponenten enthalten Fehler, die ihre Funktionalität einschränken. Es werden Änderungen der Anforderungen vorgeschlagen, die eine beträchtliche Nachbearbeitung des Entwurfs nach sich ziehen. Das Unternehmen wird umstrukturiert, so dass ein anderes Management für das Projekt verantwortlich zeichnet. Die im System verwendete Datenbank kann nicht so viele Transaktionen pro Sekunde durchführen wie erwartet. Die zur Entwicklung der Software benötigte Zeit wird unterschätzt. CASE-Werkzeuge können nicht eingebunden werden. Kunden verstehen die Auswirkungen von Anforderungsänderungen nicht. Es gibt keine Möglichkeit, erforderliche Schulungen durchzuführen. Die Anzahl der Fehlerbehebungen wird unterschätzt. mittel mittel hoch mittel hoch hoch mittel mittel mittel ernst ernst ernst ernst ernst tolerierbar tolerierbar tolerierbar tolerierbar Der Umfang der Software wird unterschätzt. hoch tolerierbar Der durch CASE-Werkzeuge generierte Code ist ineffizient. Tabelle 4.4: Risikoanalyse mittel unbedeutend Boehm (1988) schlägt vor, die»top-10-risiken«zu erkennen und zu überwachen, aber ich denke, dass diese Zahl eher willkürlich ist. Die richtige Zahl der zu überwachenden Risiken muss vom Projekt abhängen. Sie kann fünf oder 15 sein. Jedoch sollte sich die Anzahl der zur Überwachung ausgewählten Risiken an der Praxis orientieren. Eine große Anzahl von Risiken würde einfach eine zu umfangreiche Informationssammlung voraussetzen. Bei den in Tabelle 4.4 erkannten Risiken ist es angemessen, alle acht Risiken zu beachten, die katastrophale oder ernste Konsequenzen haben. Der Prozess der Risikoplanung zieht alle erkannten Hauptrisiken in Betracht und entwickelt Strategien zum Umgang damit. Wieder gibt es kein einfaches Verfahren, nach dem vorgegangen werden kann, um Pläne zum Umgang mit Risiken zu erstellen. Auch hier hängt alles vom Urteilsvermögen und der Erfahrung des Projektmanagers ab. Diese Strategien fallen in drei Kategorien: 1. Vermeidungsstrategien: Bei diesen Strategien wird versucht, die Wahrscheinlichkeit für das Auftreten des Risikos zu verkleinern. 2. Minimierungsstrategien: Bei diesen Strategien besteht das Ziel darin, die Auswirkungen des Risikos zu reduzieren. 3. Notfallpläne: Wenn Sie diese Strategien verfolgen, versuchen Sie, sich auf den schlimmsten Fall einzustellen, damit Sie vorbereitet sind und sofort eine Strategie zum Umgang damit parat haben.

16 16 Risikomanagement ZUSAMMENFASSUNG Gutes Management ist bei Softwareprojekten unverzichtbar, wenn Softwareprojekte innerhalb des Zeitplans und des Budgets entwickelt werden müssen. Das Softwaremanagement unterscheidet sich vom Management in anderen Entwicklungsbereichen. Software ist nicht greifbar. Projekte können neuartig oder innovativ sein, so dass es keine Erfahrungswerte für das Management gibt. Die Softwareprozesse sind wissenschaftlich noch nicht erschöpfend erforscht. Softwaremanager spielen verschiedene Rollen. Ihre bedeutendsten Aufgaben sind die Projektplanung, die Projektkalkulation und die Zeitplanung. Planung und Kalkulation sind sich wiederholende Prozesse. Sie setzen sich während des ganzen Projekts fort. Sobald neue Informationen zur Verfügung stehen, müssen Pläne und Zeitpläne überarbeitet werden. Ein Projektmeilenstein ist ein vorhersehbares Ergebnis einer Aufgabe, über das dem Management ein formeller Bericht über den Fortschritt erstattet werden sollte. Meilensteine sollten während des Projekts regelmäßig auftreten. Ein Lieferschritt ist ein Meilenstein, der an den Kunden des Projekts geliefert wird. Die Zeitplanung des Projekts schließt die Erstellung verschiedener grafischer Darstellungen von Teilen des Projektplans ein. Hierzu gehören Netzpläne, die die Beziehungen zwischen den Projektaufgaben zeigen, und Balkendiagramme, die die Dauer der Aufgaben darstellen. Die Hauptrisiken des Projekts sollten erkannt und beurteilt werden, um ihre Wahrscheinlichkeit und ihre Auswirkungen auf das Projekt zu ermessen. Für wahrscheinliche und möglicherweise ernste Risiken sollten Pläne erstellt werden, um sie zu vermeiden, zu bewältigen oder zu behandeln. Risiken sollten bei jeder Sitzung über den Projektfortschritt explizit erörtert werden. ERGÄNZENDE LITERATUR Managing Software Quality and Business Risk. Kapitel 3 dieses Buches ist schlicht die beste Erörterung zum Thema Risiken, die ich je gelesen habe. Das Buch ist auf Risiken ausgerichtet, und ich denke, es ist wahrscheinlich das beste Buch über dieses Thema, das zur Zeit erhältlich ist. (M. Ould, 1999, John Wiley and Sons.) Vom Mythos des Mann-Monats. Die Probleme des Softwaremanagements sind seit den Sechzigern unverändert geblieben, und dieses ist eines der besten Bücher über dieses Thema. Als Aufhänger für eine interessante und lesenswerte Erläuterung des Managements dient eines der ersten sehr großen Softwareprojekte, das OS/360-Betriebssystem von IBM. Die zweite Auflage enthält andere klassische Niederschriften von Brooks. (F. P. Brooks, 1975/2003, Addison-Wesley/mitp.) Assessment and Control of Software Risks. Es gibt zur Zeit mehrere Bücher über das Risikomanagement. Dieses ist eine besonders

17 Projektmanagement 17 umfangreiche Erörterung der Arten von Risiken, warum diese auftreten und wie sie zu vermeiden sind. (C. Jones, 1994, Prentice- Hall.) Principles of Software Engineering Management. Dies ist eine etwas eigenartige Behandlung des Softwaremanagements, enthält aber gute Anweisungen. Das Buch ist in einem leicht zu lesenden Stil geschrieben. (T. Gilb, 1988, Addison-Wesley.) In Teil 6 finden Sie weitere Literaturhinweise zum Thema Management. ÜBUNGEN 4.1. Beschreiben Sie, warum die Nichtgreifbarkeit von Softwaresystemen ein außerordentliches Problem für das Management eines Softwareprojekts darstellt Beschreiben Sie, warum die besten Programmierer nicht immer die besten Softwaremanager sind. Es könnte hilfreich sein, Ihre Antwort auf der Liste der Aufgaben des Managements aus Abschnitt 4.1 aufzubauen Beschreiben Sie, warum der Prozess der Projektplanung ein sich wiederholender ist und warum ein Plan während eines Softwareprojekts ständig überprüft werden muss Beschreiben Sie kurz den Zweck jedes Abschnitts eines Softwareprojektplans Was ist der entscheidende Unterschied zwischen einem Meilenstein und einem Lieferschritt? 4.6. Tabelle 4.5 legt eine Reihe von Aufgaben, ihre Dauer und Abhängigkeiten fest. Zeichnen Sie einen Netzplan und ein Balkendiagramm zur Darstellung des Projektzeitplans. Aufgabe Dauer (in Tagen) Abhängigkeiten T1 10 T2 15 T1 T3 10 T1, T2 T4 20 T5 10 T6 15 T3, T4 T7 20 T3 T8 35 T7 T9 15 T6 T10 5 T5, T9 T11 10 T9 T12 20 T10 T13 35 T3, T4 T14 10 T8, T9 T15 20 T12, T14 T16 10 T15 Tabelle 4.5: Dauer von Aufgaben und Abhängigkeiten Tabelle 4.5

18 18 Risikomanagement 4.7. Tabelle 4.2 zeigt die Dauer einiger Aufgaben des Softwareprojekts. Nehmen Sie an, dass sich ein ernster, unerwarteter Rückschlag ereignet und dass Aufgabe T5 nicht nur zehn, sondern 40 Tage benötigt. Überarbeiten Sie den Netzplan dementsprechend, und kennzeichnen Sie den neuen kritischen Pfad. Stellen Sie neue Balkendiagramme auf, die zeigen, wie das Projekt umorganisiert werden könnte Listen Sie unter Benutzung der in der Literatur angegebenen Fälle von Projektproblemen Schwierigkeiten beim Management auf, die bei diesen fehlgeschlagenen Programmierprojekten auftraten. (Beginnen Sie mit dem Buch von Brooks, wie in der ergänzenden Literatur vorgeschlagen.) 4.9. Benennen Sie zusätzlich zu den in Tabelle 4.4 dargestellten sechs andere mögliche Risiken, deren Auftreten in Softwareprojekten wahrscheinlich ist Sie werden von Ihrem Manager aufgefordert, Software nach einem Zeitplan abzuliefern, von dem Sie wissen, dass er nur eingehalten werden kann, wenn Sie von Ihrem Projektteam verlangen, unbezahlte Überstunden zu leisten. Alle Teammitglieder haben kleine Kinder. Erörtern Sie, ob Sie die Aufforderung Ihres Managers akzeptieren und Ihr Team überzeugen sollten, mehr Zeit dem Unternehmen und weniger den Familien zu widmen. Welche Faktoren sind für Ihre Entscheidung ausschlaggebend? Sie arbeiten als Programmierer, und Ihnen wird eine Beförderung zum Projektmanager angeboten. Sie spüren jedoch, dass Sie in einer technischen Position einen wirksameren Beitrag leisten können als in einer Position im Management. Erörtern Sie, ob Sie der Beförderung zustimmen sollten.