Projektmanagement im Software Engineering

Transkript

1 Technische Universität Berlin Fakultät IV (Elektrotechnik und Informatik) Institut für Softwaretechnik und Theoretische Informatik Fachgebiet Softwaretechnik Prof. Dr.-Ing. Stefan Jähnichen Software Engineering Projekt Marco Mosconi Projektmanagement im Software Engineering Wintersemester 2006 / 2007 Name: Benjamin Eisenführ Matrikelnummer: Anschrift: Tile-Wardenberg-Str Berlin

2 Geschichtliche Entwicklung des Software-Engineering I. Inhaltsverzeichnis I. INHALTSVERZEICHNIS 2 1 GESCHICHTLICHE ENTWICKLUNG DES SOFTWARE-ENGINEERING 4 2 RISIKEN UND ANFORDERUNGEN IN DER PROJEKTARBEIT Allgemein Teamarbeit Kommunikation 7 3 PROJEKTANALYSE ANFORDERUNGSMANAGEMENT ANGEBOTSERSTELLUNG 8 4 PROJEKTPLANUNG PROJEKTGLIEDERUNG AUFWANDSSCHÄTZUNG Möglichkeiten zur Aufwandsschätzung Algorithmische Aufwandsmodelle Formeln und Definitionen der Algorithmen Kombination verschiedener Methoden ZEITPLANUNG PERSONALPLANUNG WEITERE ARTEN VON PLÄNEN SOFTWARE-TOOLS ZUR PM-UNTERSTÜTZUNG 16 5 PROJEKTKONTROLLE RISIKOMANAGEMENT Risikoerkennung Risikoanalyse Risikoplanung 22 2

3 Geschichtliche Entwicklung des Software-Engineering Netzplan 23 6 PROJEKTABSCHLUSS PRÄSENTATION, BERICHTE 24 II. ABKÜRZUNGSVERZEICHNIS 25 III. ABBILDUNGSVERZEICHNIS 25 IV. TABELLENVERZEICHNIS 26 V. LITERATURVERZEICHNIS 26 3

4 Geschichtliche Entwicklung des Software-Engineering 1 Geschichtliche Entwicklung des Software-Engineering Zu Beginn der Informationstechnologie waren Hard- und Software kaum von einander zutreten. Gerade personell waren die Entwicklungen in diesen Bereichen verschmolzen und in Ihrer Komplexität von einer einzigen oder sehr wenigen Personen durchführbar. Dieser Kreis von Personen, häufig Wissenschaftler und Techniker, war gleichzeitig auch Anwender der Entwicklung. Dies änderte sich mit fortschreitender Entwicklung: Auf der einen Seite etablierte sich die Softwareentwicklung als selbstständige Disziplin, auf der anderen Seite waren mehr und mehr Entwickler und Anwender getrennt. Unabhängig davon wurde EDV- Anwendungen immer komplexer. Dies alles trug dazu bei, dass die Anforderungen an die Entwickler überproportional stiegen und immer häufiger nur noch im Team zu bewältigen waren, wodurch neue Probleme entstanden 1. Die Programmierer mögen zwar in ihrem Fach sehr qualifiziert gewesen sein, es fehlte aber ein Management. 2 In den 1960er Jahren kam es zur Softwarekrise, wirtschaftliche Anforderungen wie das Budget und der Zeitplan wurden regelmäßig überschritten. Auch ist Software besonders aus dieser Zeit kaum wartbar. Seit den darauf folgenden 70er Jahren entstand die hier weiter beschriebene Disziplin: Software Engineering. Der Name deutet schon an, dass von nun an ingenieurmäßige Maßstäbe an die Softwareentwicklung gesetzt werden. Es bedarf eines umfassenden und spezialisierten Management, dass sich um administrative Aufgaben wie Vorgehensmodelle, Requirement Management, wirtschaftlichen Planungen und vielem mehr engagiert, das: Projektmanagement im Software Engineering 3 1 (siehe Abschnitt 2.1.2: Risiken und Anforderungen in der Projektarbeit; Teamarbeit) 2 Vgl.: (Forbrig / Kerner, 2004) : Seiten 18 ff 3 Vgl.: (Pasch, 1994) : Seiten 32 ff 4

5 Risiken und Anforderungen in der Projektarbeit Abbildung 1: Bekannte Beispiele für Projektverzögerungen 4 2 Risiken und Anforderungen in der Projektarbeit Allgemein Die Leitung, Planung und Verantwortung von Projekten stellt ganz besondere Herausforderungen an das Projektmanagement. Dies trifft ganz besonders auf Software Engineering Projekte zu. Zum einen sind sie ganz besonders einzigartig, da keine andere Branche so schnell fortschreitenden Entwicklungen vorzuweisen hat, zum anderen wird ein immaterielles Produkt geschaffen. Letzteres beinhaltet marginale Produktionskosten, wodurch die Entwicklungsphase dramatisch in den Vordergrund rückt. Außerdem ist ein Softwareprodukt schwer greifbar, sein Fortschritt für Outsider unsichtbar und es gibt aufgrund der schnellen Entwicklung keinen standardisierter Softwareentwicklungsprozess. Selbst für kleinere und sogar Ein-Mann-Projekte lohnt sich eine genaue Projektplanung. Zur Einführung ist das Buch Software-Projektmanagement kompakt 5 von Ian Ricketts zu empfehlen. 4 aus (Wallmüller, 2004): Seite 1 5 (Ricketts, 1998) 5

6 Risiken und Anforderungen in der Projektarbeit Teamarbeit Ob die Erarbeitung der Projektaufgabe im Team erledigt werden soll ist nicht zuletzt eine Frage ihrer Komplexität und Dringlichkeit. Moderne Softwareprojekte sind häufig unheimlich komplex und arbeitsintensiv und unterstehen trotzdem dem wirtschaftlichen Druck kurzer Fertigstellungsfristen. Beide Faktoren für sich können schon eine Gruppenarbeit nötig machen. Komplexität erfordert Fachwissen mehrerer Spezialisten, kurze Fristen benötigen ebenfalls Arbeitsaufteilung. Nichtsdestotrotz ist die Entscheidung zur Gruppenarbeit keine einfache, da sie sowohl Vor- als auch Nachteile in sich birgt, wie die folgende Tabelle verdeutlicht: Chancen Benötigtes Wissen kann durch Kombination unterschiedlicher Kompetenzen erreicht werden Komplexe und dynamische Aufgaben können besser gelöst werden Gemeinsame Entscheidungen werden besser akzeptiert Bei schwierigen Aufgaben kann soziale Unterstützung gegeben werden Arbeitsmotivation und Engagement von Mitarbeitern kann gesteigert werden Arbeitszufriedenheit kann erhöht und Stress reduziert werden Risiken Gruppe kann mehr Wert auf Harmonie als auf kritische Auseinandersetzung legen Gruppe kann sich gegen externe Informationen und Einflüsse abschotten Soziale Anforderungen an die Gruppenmitglieder können zu hoch sein Zu viel Zeit und Energie kann für die Koordination der Arbeit benötigt werden Destruktive Konflikte können innerhalb der Gruppe und mit anderen organisationalen Einheiten entstehen Mitglieder können die Lust verlieren Abbildung 2: Chancen und Risiken von Gruppenarbeit 6 6 aus (Gemünden, 2005), Seite 38 6

7 Risiken und Anforderungen in der Projektarbeit Kommunikation Eine weitere Aufgabe des Projektmanagements ist die Steuerung und Translation der Kommunikation zwischen Auftraggeber und Auftragnehmer. Im Regelfall sollen zum Beispiel Vertreter des Kunden nicht direkt mit den Entwicklern sprechen, da diese unterschiedliche Verbalkompetenzen besitzen. Statt dessen werden Fragen und Anforderungen des Kunden an das PM gestellt. Dieses klärt sie mit dem Entwicklerteam oder einzelnen Spezialisten und berichtet anschließend dem Kunden in aufbereiteter Form. Andersherum werden Fragen der Entwickler ebenfalls an des PM gestellt, welches diese sammelt, eventuell selbst Entscheidungen trifft oder den Kunden interviewt. Aber auch auf diesen Wegen kann es zu Kommunikationsstörungen wie zum Beispiel Missverständnissen oder Uneinigkeit aufgrund vergessener Informationen kommen. Daher empfiehlt es sich für das PM, alle persönlichen Gespräche mit Kunden und Entwicklern penibel zu protokollieren. Projektleitung Produkt Kunde Entwickler Abbildung 3: Kommunikationswege und -störungen 7 7 Eigene Darstellung 7

8 Projektanalyse 3 Projektanalyse Zu Beginn der praktischen Arbeit des PM liegt die Projektanalyse. In dieser Phase müssen die Ziele und gegebenenfalls Zwischenziele des Projektes mit dem Kunden geklärt und spezifiziert werden. Eventuell kann an dieser Stelle schon eine erste grobe Projektplanung durchgeführt werden, damit das PM weitere Informationen über Ablauf, Dauer und Kosten des Projektes erhält. Dabei ist Im Detailgrad drauf zu achten, zu prognostizieren, ohne zu spekulieren. Auf dieser Grundlage wird anschießend ein Angebot erstellt, dass Preise und Liefertermine enthält. 3.1 Anforderungsmanagement Eine besondere Herausforderung ist das Anforderungsmanagement beziehungsweise das Requirement Management. Häufig werden Anforderungen erst im Entwicklungsprozess erkannt oder vom Kunden spezifiziert. Daher unterliegt dieses spezielle Management, wie der Großteil des Projektmanagements, einem ständigen Wandel und muss entsprechend regelmäßig an neue Gegebenheiten angepasst werden. Weiter Informationen können in einem Referat der selben Reihe unter 8 nachgelesen werden. 3.2 Angebotserstellung Die aus der Analyse und ersten Vorabplanung gewonnen Restriktionen wie Kosten, Entwicklungszeit und benötigte Ressourcen bilden einen ersten Richtwert für ein Angebot. So kann eine einfache Rechnung über die internen Kosten Aufschluss geben: 8 (Referat Anforderungsmanagement, 2006) 8

9 Projektplanung Kosten pro MannMonat * Entwicklungsdauer + Hard- und Softwarekosten = variable Kosten Um diese Prognose zu spezifizieren, kann die Entwicklungsdauer mithilfe einer Aufwandsschätzung 9 errechnet werden, die Kosten können von der interne Buchhaltung beziehungsweise dem Controlling erfragt werden. Nicht zu vergessen sind aber wirtschaftliche Überlegungen. Zum Beispiel kann die Entwicklungsdauer vergleichsweise gering geschätzt werden, da schon ausführliche Erfahrungen mit ähnlichen Projekten gesammelt wurden. Dieser Vorteil gegenüber der Kongruenz muss selbstverständlich nicht in vollem Umfang an den Kunden weiter gegeben werden. Entgegengesetzt kann ein Projekt auch mit Verlust geplant werden, sei es, um einen neuen Kunden zu gewinnen, oder um in eine Neue Sparte oder Technologie vorzudringen. Dabei wird das Angebot davon geleitet, den genannten Verlust in Folgeprojekten zu kompensieren Projektplanung Die Projektplanung hat zum Ziel, den gesamten Ablauf bis zur Beendigung des Projektes zu formalisieren. Sie soll eine optimierte Zielführung der Aktivitäten bieten, für eine effektive Auslastung der Ressourcen sorgen und den Fortschritt für das Projektmanagement, die Entwickler, die Unternehmensleitung und den Kunden transparent machen. 4.1 Projektgliederung Diese Gliederung ist entscheidend von der Wahl des Vorgehensmodells 11 abhängig. Im folgenden werden allgemeine Techniken, vorzugsweise zum Wasserfall-Modell, erläutert. Zunächst wird das Gesamtziel in kleinere Zwischenergebnisse zerlegt, da diese gerade für Personen außerhalb des Entwicklungsprozesses besser greifbar sind. 9 (siehe Abschnitt 4.2: Projektplanung; Aufwandsschätzung) 10 Vgl: (Klose, 1999) 11 Vgl.: (Pomberger, 1993): Seiten 17 ff 9

10 Projektplanung Werden diese Ergebnisse bereits dem Kunden präsentiert und zur Verfügung gestellt, werden sie Lieferschritte genannt. Geliefert werden können aber nicht nur Code-Teilergebnisse wie Prototypen oder Releases, sondern auch Vorstufen der Planung. Diese Vorab-Präsentationen umfassen häufig die Entwürfe, Spezifikationen oder die Zusammenstellung der Anforderungen im Pflichtenheft Viele Zwischenergebnisse sind aber nur interne Markierungen und werden als Meilensteine bezeichnet. 12 Diese Einteilung ist bei Softwareprojekten besonders wichtig, da ihnen im Gegensatz zu sonstigen Industrieprojekten keine greifbarer materieller Fortschritt anzuerkennen ist. Ohne eine Formalisierung ist es aber gerade für Outsider schwierig, den Arbeitsstand zu bewerten. Letzteres ist aber wiederum für jegliche Planung unerlässlich. Diese Problematik löst das Planen in Meilensteinen. Schon im Vorfeld werden klare Start und Endpunkte oder Mindestanforderungen definiert. Werden diese Abschnitte noch grafisch in die Planungsdiagramme eingebettet (Meilenstein-Endpunkte werden meist als schwarz ausgefüllte Raute gezeichnet), erleichtern sie dort die Übersicht. 4.2 Aufwandsschätzung Möglichkeiten zur Aufwandsschätzung Um eine realistische Planung durchführen zu können, bedarf es einer fundierten Schätzung der Arbeitsintensität. Dies kann sowohl für einzelne Arbeitspakete, Meilensteine oder die gesamte Projektaufgabe geschehen. Ein weiterer Vorteil der Größen- und Aufwandsschätzung besteht in der Einbeziehung in die Produktivitätsmessung. Ohne diese Referenzgröße ließe sich beispielsweise die Arbeitsintensität mehrerer Mitarbeiter schwer vergleichen. Im Laufe der Zeit haben sich verschiedene Modelle zur Aufwandsschätzung entwickelt 13 : Expertenbeurteilung 12 Vgl.: (Krallmann, 2002): Seiten 128 ff 13 Vgl.: (Sommerville, 2001): Seiten 526 ff 10

11 Projektplanung Ein oder mehrere Experten werden um eine empirische Schätzung auf Grundlage Ihrer persönlichen Erfahrungen gebeten. Hierbei sollten sowohl Erfahrungen allgemein im Software Engineering berücksichtigt werden, als auch in Teamarbeit und den angewandten Technologien. Verschiedene Schätzungen werden (eventuell gewichtet) gemittelt. Analogieschätzung Diese Methode kann nur angewandt werden, wenn bereits sehr ähnliche Projekte durchgeführt wurden. Ist dies der Fall, kann ein ähnlicher Aufwand angenommen werden. Parkinsons Gesetz Hier wird von dem ausgegangen, was der Kunde bereit ist zu bezahlen, oder was, einigermaßen willkürlich, vom Projektmanagement festgelegt wird. Laut C. Northcote Parkinson 14 wird sich der echte Aufwand daran anpassen. Price to win Dieser wirtschaftliche Ansatz setzt das Budget des Kunden als Restriktion, an welches das Produkt angepasst werden muss. Anders, als beim Parkinson schen Modell, variiert nicht die Produktivität der MA., sondern die Anforderungen werden verändert. Algorithmisches Aufwandsmodell Diese fortgeschrittenen formalen Modelle werden im folgenden Abschnitt erläutert Algorithmische Aufwandsmodelle Zwei bekannte fortgeschrittene Methoden zur Aufwandschätzung der Softwareentwicklung sind Cocomo und Function Point. Beide erfordern das Sammeln statistischer Daten über einen längeren Zeitraum sowie eine eingehende Beschäftigung mit diesem Thema. Nichtsdestotrotz sind beide Methoden 14 Vgl.: (Stallmann / Greene, 2006): Seiten 56, 61 ff 11

12 Projektplanung leistungsfähige Werkzeuge, die bei entsprechender Erfahrung zu sehr verlässlichen Schätzungen führen. Cocomo ist die Abkürzung für Constructive Cost Model und wurde erstmalig durch Barry Boehm 1981 vorgestellt. Das Modell basiert auf einer Analogieschätzung mittels Lines of Code (LOC) und gewichteten Einflussfaktoren wie Entwicklungsmodus (einfache Softwareentwicklung etc.) und Kostentreibern (benötigte Zuverlässigkeit, Änderungshäufigkeit im System, Erfahrung im Anwendungsbereich, Verwendung von Tools). Die Klassifikation der zu schätzenden Software und die Gewichtung der Einflussfaktoren geschehen mittels Tabellen, Richtlinien und Beispielen. Das Modell wurde weiterentwickelt und verbessert zu Cocomo 2, welches in 1999 offiziell verabschiedet wurde. Cocomo 2 ist eine skalierbare Familie von Softwareschätzmodellen, die auch neue Entwicklungen wie Wiederverwendung (objektorientierter Ansatz) und Reengineering berücksichtigt. 15 Die Function-Point-Methode wurde erstmalig 1979 durch Alan Albrecht veröffentlicht. Bei Function Point wird der Aufwand in einem ersten Schritt direkt aus den Produktanforderungen, basierend auf Kategorien wie Eingaben, Abfragen, Datenbeständen etc., ermittelt. Die Kategorien werden klassifiziert (einfach, mittel, etc.) und die so gewichteten Werte zu einer vorläufigen Function- Point-Summe zusammengefasst. Diese wird in einem zweiten Schritt mit Einflussfaktoren wie dezentrale Verwaltung, Transaktionsraten, Wiederverwendbarkeit, Komplexität, etc. gewichtet. Die Klassifikation und Gewichtung der Anforderungen geschieht mittels Tabellen, Richtlinien und Beispielen. Aus dem zweiten Schritt ergeben sich die endgültigen Function Points, die mittels Erfahrungskurven in die erwarteten Aufwände für das aktuelle Projekt umgerechnet werden Formeln und Definitionen der Algorithmen Codemenge o (K)LOC: (Kilo) Lines of code o (K)DSI: (Kilo) Delivered Source Instructions 15 Vgl. (Boehm, 1986) 12

13 Projektplanung Function Points o Funktionen zählen o Externe Ein- Ausgabe o Benutzerinteraktionen o Externe Schnittstellen o Vom System verwendete Dateien o Funktionen Zählen gewichten (3-15 fach) o Summieren =UFC (Unadjusted Funktion Point Count) o Codzeilen= AVC x UFC Object Points o Objekte zählen und gewichten o Bildschirmmasken o 1 bis 3 Points o Berichte o 2 bis 8 Points o 3GL-Module o 10 Points COCOMO 81 o PM = A x GrößeB x M o PM: Aufwand in Personenmonaten o A: Firmenabhängig o Größe: KDSI, Object Points o B: überproportionaler Aufwand o M: Multiplikator aus Prozess-, Produkt- und Entwicklungsmerkmalen o PM = 3,6 x (KDSI)1,20 x M COCOMO 2 o Frühe Prototypenstufe o PM =(NOP x (1 - %reuse / 100)) / PROD o NOP: Number of Object Points o %reuse: prozentualer Wiederwerwendungsanteil o PROD: Produktivität (4 bis 50, 13 ist Soll) o Frühe Entwurfsstufe, ähnlich wie COCOMO 81 13

14 Projektplanung o PM = A x GrößeB x (PERS x PCPX x RUSE x PDIF x PREX x FCIL x SCED) + ((ASLOC x (AT/100)) / ATPROD) Kombination verschiedener Methoden Die beschriebenen Methoden können auch miteinander kombiniert werden. Ebenso können Schätzergebnisse durch Vergleich der Ergebnisse aus zwei Schätzmethoden abgesichert werden. 4.3 Zeitplanung Zentrale Sammelstelle für viele Planungsentscheidungen ist das Zeitmanagement. Hier werden zunächst die definierten Meilensteine und Lieferschritte und die verfeinerten Aktivitäten samt ihrer Aufwandsschätzung eingetragen. Ebenso können die eingeteilten Ressourcen abgetragen werden. Klassische Darstellungsmethode ist das Gantt-Chart. Es ähnelt einem Kalender, in dem die geplanten Aktivitäten als Balken eingetragen werden. Außerdem zeigen Pfeile die Abhängigkeiten auf zwangsläufige Vorgänger und Nachfolger. 16 Abbildung 4: Gantt-Diagramm Vgl.: (Lang, 1989) 17 Eigene Darstellung 14

15 Projektplanung 4.4 Personalplanung Das passende Personal ist die wohl wichtigste Komponente für ein Team und entscheidet wohlmöglich über den Erfolg des Projektes. Daher empfiehlt sich eine besonders sorgsame Komposition Auswahl der Mitglieder, Wahl der Gruppengröße und der Kommunikationswege (z.b. bei MA. an verschieden Standorten). Zunächst müssen die notwendigen Spezialisierungen und Technologiekenntnisse erkannt werden. Nach Möglichkeit sollten immer mehrere Teammitglieder eine solche Spezialisierung abdecken, um eine bessere Auslastung zu gewährleisten und auch bei Personalausfällen reagieren zu können. Genauso Vorteilhaft sind ausreichende Erfahrungen der Teammitglieder, nicht nur technisch, sondern auch in Ihren Sozialkompetenzen. Leider sind aber auch Restriktionen zu beachten. Das für Personalkosten verfügbare Budget muss eingehalten werden, außerdem können passende Mitarbeiter nicht verfügbar sein. Letzteres gilt sowohl für Angestellte der eigenen Firma, die in anderen Projekten involviert sind, als auch für Personen in festen Vertragsbindungen zur Konkurrenz. Insgesamt ist auf einen ausgewogenen Mix zu achten. Zum Beispiel können erfahrene mit unerfahren Mitarbeitern kombiniert werden, um letztere weiterzubilden 4.5 Weitere Arten von Plänen Weiter Arten von Plänen, die hier nicht näher erläutert werden: Qualitätsplan 18 Konfigurationsplan 19 Wartungsplan 20 Personalentwicklungsplan (Hesse, 1992): Seiten 172 ff, (Hintel, 2006): Seite (Pomberger, 1993): Seite 172 ff 21 (Hintel, 2006): Seiten 113 ff 15

16 Projektplanung 4.6 Software-Tools zur PM-Unterstützung Freie Software ABOVO PM-EPMS CoP.Track dotproject EW-ProjectManager faces GanttProject GanttPV in-step Personal Edition InfoRapid KnowledgeMap MrProject OpenOffice Project Manager Openworkbench PHProjekt Planner Project/Open projekthandbuch.xs TaskJuggler ToutDoux Track+ Kommerzielle Software ACOS PLUS ACTANO RPlan - Kooperatives Projektmanagement Afinion Project-Viewer AGRESSO Project Allocatus - integriert Microsoft Project mit Lotus Notes und Microsoft Outlook Alpha Project WorkBench Artemis 7 Asta Easyplan Asta Powerproject Blue Ant BMPM PM4 Project Management for. cando project intelligence CIMBRIA Projects für IBM Lotus Notes CoP - Controlling of Projects EFFCOR - Projektcontrolling für Forschungseinrichtungen und Universitäten factro - integrative Projekt- und Managementsoftware Gantt Chart Designer Genius Project4Domino auf Basis von IBM Lotus Notes GRANEDA Dynamic help4project ibo netproject in-step jppm JCV Gantt PRO.0 Projektsoftware Journyx Timesheet - Projektzeiterfassung Keep in Mind KLUSA Merlin MS Project 2003 MindPlan Project Module Warehouse OPX ormiga Outlook Projektmanagement PACS Performer pmplus+ pms.voessing.de Public Folder Helpdesk für Outlook PONTE.project PPMS Invest Sign - Enterprise Project Management and Risk analysis ProjectCity projekthandbuch.xl projektportfolio.xs Primavera - Project Planner (P3) Primavera - Enterprise Project Management (P3e) Projectile Projectplace Projektron BCS Rillsoft Project 006 Sciforma PS Suite SuportisOne think PROFIT TimO - Time Management Office TICOS Virtuelle Projektverwaltung online web.pm.prozesse ZATORI - Planung für Dienstleistungsprojekte ZATORI PRO - Planung für Dienstleistungsprojekte ZEP - Zeiterfassung für Projekte Tabelle 1: Software-Tools Vgl.: (Wikipedia PM-Software) 16

17 5 Projektkontrolle Wie bei vielen Vorgängen im Projektmanagement ist ganz besonders die Überwachung ein ständiger Prozess. Die erstellten Pläne müssen regelmäßig auf Ihre Aktualität überprüft werden und an Änderungen und neuen Informationen angepasst werden. Ebenso sollte ein regelmäßiger Soll-Ist-Vergleich vorgenommen werden. Erfüllt der Fortschritt die Planungen nicht und werden die Ressourcen als konstant betrachtet, müssten die Ziele korrigiert werden. Es sei denn, dieser Zustand wird frühzeitig erkannt und alternative Lösungswege können eingeplant werden. Diese Kontrolle kann das Projektmanagement durch regelmäßige formelle Reviews erreichen. Dies hat aber den Nachteil, dass Mitarbeiter sich überwacht fühlen und zur Verschleierung von Rückständen tendieren. Größeren Erfolg in einer positiven Arbeitsatmosphäre versprechen unregelmäßige informelle Reviews. Die Mitarbeiter werden, am besten an ihrem Arbeitsplatz oder einem anderweitig informellen Ort, unverbindlich angesprochen, um ihre aktuelle Arbeit und den Fortschritt zu erläutern. Eine bereits erwähnte positive Arbeitsatmosphäre kann außerdem dazu führen, dass MA. selbstständig aktiv berichten: das informelle Feedback. Zur weiteren Risikoeindämmung helfen Pufferzeiten und ein kontinuierliches Risikomanagement, wie im folgenden Abschnitt 5.1 näher erläutert. 17

18 Projektkontrolle Ziele definieren (mit Kunden) Projektplan nach gegeben Informationen (geschätzt) Aufgabenabarbeitung Neue Informationen durch formelles Review Feedback Neue Informationen durch informelles Review Ja Reicht der Puffer aus? Nein Alternativer Lösungsweg Abbildung 5: Zyklus der Projektplanung Risikomanagement Das Risikomanagement lässt sich in 4 zyklisch wiederkehrende Phase einteilen: Risikoerkennung Risikoanalyse Risikoplanung Risikoüberwachung Abbildung 6: Zyklus des Risikomanagements Eigene Darstellung 18

19 Projektkontrolle Risikoerkennung Es sollen mögliche Risiken frühzeitig identifiziert werden. Dazu kann zunächst die Brainstorming-Methode eingesetzt werden. Hilfreich ist die Gedankenführung an Arten und Ursachen von Risiken. Ursachen von Risiken Technologie Personen Unternehmen Werkzeuge Anforderungen Schätzungen Tabelle 2: Ursachen von Risiken 25 Risikoart Auswirkungsziele Projektrisiken Produktrisiken wirtschaftliche Risiken Zeitplan, Ressourcen Qualität, Leistung Unternehmen (Anbieter oder Kunde) Tabelle 3: Arten von Risiken und ihre Auswirkungsziele Risikoanalyse In der Risikoanalyse werden die zuvor erkannten potentiellen Gefahren näher betrachtet. Es werden Eintrittswahrscheinlichkeiten geschätzt und die schwere der Konsequenzen bewertet. Dadurch lassen sie sich priorisieren und eine Auswahl an beachtungswerten Risiken treffen. 24 Eigene Darstellung 25 Vgl.: (Sommerville, 2001) 26 Vgl.: (Sommerville, 2001) 19

20 Projektkontrolle Risiko Wahrscheinlichkeit Auswirkungen Finanzielle Probleme des Unternehmens niedrig Katastrophal Krankheit des Personals hoch ernst Fehlerhafte Komponenten mittel ernst Kunden verstehen die Auswirkungen von Anforderungsänderungen nicht mittel tolerierbar Der Umfang wir unterschätzt hoch tolerierbar Generierter Code ist ineffizient mittel unbedeutend Tabelle 4: Beispiel Risikobewertung 27 Abbildung 7: 2-Dimensionale ABC-Analyse / Risikobewertung Vgl.: (Sommerville, 2005) 28 Aus (Wallmüller, 2004) 20

21 Projektkontrolle Abbildung 8: Beispiel einer schriftlichen Risikoanalyse: Risk Information Sheet Vgl.: (Wallmüller, 2004) 21

22 Projektkontrolle Risikoplanung Risiko könnte man als Kalkulierte Prognose eines möglichen Schadens bzw. Verlustes im negativen Fall 30 bezeichnen. Es soll also ein Weg gefunden werden, mit dieser Bedrohung umzugehen. Dabei bieten sich drei verschiedene Strategien an: Notfallplan Für den Fall des Risikoeintritts wird von vornherein ein Alternativplan erstellt. Ist die schwere des negativen Eintritts nicht bekannt, kann der schlimmste anzunehmende Fall geplant werden, dies nennt man Worth-Case-Szenario. Minimierungsstrategie Die reguläre Planung wird so erstellt, das im Fall des Risikoeintritts die Auswirkungen reduzieren werden. Vermeidungsstrategie Die reguläre Planung wird so erstellt, das die Eintrittswahrscheinlichkeit möglichst gering ist. Risiko Strategie Kategorie Finanzielle Probleme des Unternehmens Erörterung mit höherem Management Notfallplan Krankheit des Personals Überschneidungen in Teams verteilen Wissen Minimierungsstrategie Fehlerhafte Komponenten Zukauf von zuverlässigen Komponenten Vermeidungsstrategie Tabelle 5: Beispiel Risikostrategien Aus: (Wikipedia Risiko) 31 Vgl.: (Sommerville, 2005) 22

23 Projektkontrolle Netzplan Eine weit verbreitete Darstellungsform der Abhängigkeiten von Projekt-Aktivitäten ist der Netzplan. Hier werden neben diesen Abhängigkeiten auch die geplanten Anfangs und Endzeiten, die Dauer und die Pufferzeit jeder Aufgabe eingetragen. Früher Anfang Später Anfang Dauer Legende Puffer Früher Abschluss Später Abschluss Abbildung 9: Netzplanelement 32 Die erste Aufgabe des Projektmanagements besteht darin, die einzelnen Elemente in eine chronologische Reihenfolge zu bringen und die Abhängigkeitsbeziehungen durch Pfeile darzustellen. Danach wird zunächst eine Vorwärtsplanung und anschließend eine Rückwärtsplanung durchgeführt, um die Zeiten und Puffer zu bestimmen: Zeitpunkte o Frühester Anfangszeitpunkt (aus Vorwärtsplanung) o Frühester Endzeitpunkt (aus Vorwärtsplanung und jeweiliger Dauer) o Spätester Endzeitpunkt (aus Rückwärtsplanung) o Spätester Anfangszeitpunkt (aus Rückwärtsplanung und jeweiliger Dauer) Gesamtpuffer o errechnet sich aus der Differenz von o Spätester Anfangszeitpunkt und Frühester Anfangszeitpunkt bzw. o Spätester Endzeitpunkt und Frühester Endzeitpunkt. o Der Gesamtpuffer gibt an, um wie viel sich der Vorgang verschieben lässt, ohne das Projektende zu gefährden. 32 Eigene Darstellung 23

24 Projektabschluss Workshop Testen UseCase-Aufteilung Tests Design Automatisierte Tests Testauswertung Abbildung 10: Netzplan-Beispiel 33 6 Projektabschluss 6.1 Präsentation, Berichte Zum Abschluss eines Projektes oder der Übergabe an ein neues Projektmanagement sind ein Abschlussbericht und eine Arbeitsdokumentration erforderlich. Sie sollen den aktuellen Stand des Projektes aufzeigen, wichtige Entwurfsentscheidungen begründen, Spezifikationen und Konfigurationsparameter sowie alle weiteren Informationen enthalten, um eine möglichst nahtlose Weiterarbeit zu ermöglichen. Diese Präsentationen und Berichte sind knapp, präzise und zusammenhängend zu verfassen und sollten schriftlich festgehalten werden. Sie können mündlich, zum Beispiel durch einen Vortrag, ergänzt werden. 33 Eigene Darstellung 24

25 Projektabschluss II. Abkürzungsverzeichnis bzw. etc. ca. d.h. EDV HTML IT MA. u.a. usw. Vgl. z.b. beziehungsweise et cetera circa das heißt Elektronische Datenverarbeitung Hypertext Markup Language Informationstechnologie Mitarbeiter und andere und so weiter vergleiche zum Beispiel III. Abbildungsverzeichnis Abbildung 1: Bekannte Beispiele für Projektverzögerungen... 5 Abbildung 2: Chancen und Risiken von Gruppenarbeit... 6 Abbildung 3: Kommunikationswege und -störungen... 7 Abbildung 4: Gantt-Diagramm Abbildung 5: Zyklus der Projektplanung Abbildung 6: Zyklus des Risikomanagements Abbildung 7: 2-Dimensionale ABC-Analyse / Risikobewertung Abbildung 8: Beispiel einer schriftlichen Risikoanalyse: Risk Information Sheet Abbildung 9: Netzplanelement Abbildung 10: Netzplan-Beispiel

26 Projektabschluss IV. Tabellenverzeichnis Tabelle 1: Software-Tools 16 Tabelle 2: Ursachen von Risiken 19 Tabelle 3: Arten von Risiken und ihre Auswirkungsziele 19 Tabelle 4: Beispiel Risikobewertung 20 Tabelle 5: Beispiel Risikostrategien 22 V. Literaturverzeichnis (Boehm, 1995) Barry Boehm, Software engineering economics Verlag für Wirtschaft & Verkehr Forkel & Co, Stuttgart 1986 ISBN (Forbrig / Kerner, 2004) Prof. r. rer. Nat. habil. Immo O. Kerner, Prof. Dr.-Ing. habil. Peter Forbrig, u.a., Software-Entwicklung Carl Hanser Verlag, München, Wien 2004 ISBN (Gemünden, 2005) Prof. Dr. Hans Georg Gemünden u.a., Management von Teams (3. Auflage) Deutscher Universitätsverlag, Wiesbaden 2005 ISBN (Hesse, 1992) Wolfgang Hesse u.a., Software-Entwicklung R. Oldenbourg Verlag, München 1992 ISBN (Klose, 1999) Burkhard Klose, Projektabwicklung Wirtschaftsverlag Ueberreuter, Wien 1999 ISBN

27 Projektabschluss (Krallmann, 2002) Prof. Dr. Hermann Krallmann u.a., Systemanalyse im Unternehmen R. Oldenbourg Verlag, München Wien 2002 ISBN (Lang, 1989) Hans-Dieter Lang, Microsoft Project Friedr. Vieweg & Sohn Verlagsgesellschaft, Braunschweig 2004 ISBN (Pasch, 1994) Jürgen Pasch, Software Entwicklung im Team Springer Verlag, Berlin, Heidelberg 1994 ISBN (Pomberger, 1993) O. Univ.-Prof. Dipl.-Ing.Dr. Gustav Pomberger, Dipl.-Ing. Dr. Günther Blaschek, Grundlagen der Software Engineering Carl Hanser Verlag, München, Wien 1993 ISBN (Referat Anforderungsmanagement, 2006) Online im Internet AnforderungsMgmt_Ausarbeitung.pdf [Stand ] (Ricketts, 1998) Dr. Ian. Ricketts, Software-Projektmanagement kompakt Springer-Verlag, Berlin 1998 ISBN (Sommerville, 2005) Ian Sommerviller, Software Engineering (6. deutsche Auflage) Pearson Studium, München 2001 ISBN