Aufwandsabschätzung und Projektplanung

Transkript

1 Aufwandsabschätzung und Projektplanung Software Engineering 1 WS 2012/2013 Prof. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (mit Folien von Dr. Gerhard Pews)

2 Charakteristika eines Projekts Abgrenzung zu Routinetätigkeiten: Ein Projekt hat ein Projektziel. Ein Projekt ist zeitlich befristet. Ein Projekt befasst sich in der Regel mit einem schwierigen Thema. Ein Projekt besteht aus einer Vielzahl von Einzelaufgaben und besitzt dadurch Komplexität. Ein Projekt umfasst oft neuartige Aufgaben und Inhalte. Ein Projekt hat in der Regel ein höheres Risiko als eine Routinetätigkeit. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 2

3 Wiederholung: Teufelsquadrat nach nach Sneed Sneed Qualität Zeit Leistungsumfang - Kosten Die Fläche (Produktivität) eine Projekts ist invariant Wenn ein Projekt z. B. in weni Beachte: Die Zeit Fläche und zu (Produktivität) geringeren Kosten eines Projekts abgeschlossen ist invariant: werden soll, verringert sich auch der Wenn ein Projekt Leistungsumfang z. B. in weniger und die Qua Zeit und zu Steuerung: geringeren Kosten abgeschlossen Fall werden 1: Planung soll, war nicht verringert sich umsetzbar: auch der Ecken neu justie Leistungsumfang und die Qualität. Fall 2: Produktivität im Team stimmt nicht (Fläche) 2011 Capgemini All rights reser Vortrag Projekt Management TU Braunschweig.p Prof. Dr. Ina Schaefer Software Engineering 1 Seite 3

4 Wichtige Aspekte des Projektmanagements Definition des Projektumfangs Komplexität Vorgehensmodell Planung Steuerung und Controlling Änderungsmanagement Risikomanagement Reporting Teammanagement Offene Kommunikation & Feedback Projekterfolg Prof. Dr. Ina Schaefer Software Engineering 1 Seite 4

5 Projektstrukturplan Der PSP ist die vollständige, hierarchische Zerlegung des Projekts in Aufgaben und Arbeitspakete (AP). m ersten Planungsschritt wird der Projektstrukturplan (PSP) erstellt dies bildet die Basis für den Projektplan Synonym: Work breakdown structure (WBS) rojektstrukturplan Projekt Aufgabenkategorien KON-A REA-A Aufgaben Dialog x Batch x Dialog y Batch y Arbeitspakete AP AP GUI AP AP AP AWK AP AP Test AP Definition Der PSP ist die vollständige, hierarchische Zerlegung des Projekts in Aufgaben und Arbeitspakete (AP) Prof. Dr. Ina Schaefer Software Engineering 1 Seite 5

6 Übersicht Schätzung Allgemeine Grundlagen Function Point Verfahren Expertenschätzung (Delphi-Verfahren) CoCoMo Verfahren Projektplanung Inhalte der Planung Planungstechniken Prof. Dr. Ina Schaefer Software Engineering 1 Seite 6

7 Schätzungen Voraussagen sind schwierig, vor allem, wenn sie die Zukunft betreffen. Mark Twain Prof. Dr. Ina Schaefer Software Engineering 1 Seite 7

8 Gewünschter Zeitpunkt der Schätzung Fachliche Konzeption Technische Konzeption Realisierung Test & Integration Umfang der Funktionalität bekannt Fachliche Funktionen, Masken Umsetzung bekannt Prof. Dr. Ina Schaefer Software Engineering 1 Seite 8

9 Tatsächlicher Zeitpunkt der Schätzung Fachliche Konzeption Technische Konzeption Realisierung Test & Integration Nur Anforderungen aus Auftrag sind bekannt Schätzungen sind unfair Finden zu einem sehr frühen Zeitpunkt statt. Man weiß dann wenig über die Aufgabe. Aber: Auf die Zahlen wird man später festgenagelt Prof. Dr. Ina Schaefer Software Engineering 1 Seite 9

10 Top-Down vs. Bottom-Up Schätzung Bottom-up Fragestellung: Wenn ich das alles machen will, wie viel kostet es dann? Von den Arbeitspaketen zur Aufwandszahl Schätzung der einzelnen Arbeitspakete Summe ergibt Gesamtaufwand Beispiel: Abschätzung der Gesamtkosten als Arbeitsgrundlage für weitere Planung Top-down Fragestellung: Wenn ich einen festen Kostenrahmen habe, wie viel dürfen die einzelnen Arbeitspakete dann kosten? Vom fixierten Aufwand zu den Arbeitspaketen Projekt so aussteuern, dass es im Kostenrahmen bleibt Aufgaben werden nur so gut erledigt, wie Geld da ist Beispiel: Validierung eines Kostenrahmens Prof. Dr. Ina Schaefer Software Engineering 1 Seite 10

11 Folgen von Fehlschätzungen Schätzung zu niedrig Beschreibung Geld reicht nicht, Projekt kann im Budget nicht durchgeführt werden zu hoch Schätzzahl liegt höher als die tatsächlich zu leistenden Aufwände. Im nachhinein kaum festzustellen. Jedes Projekt schöpft den Kostenrahmen voll aus. Konsequenz: Schätzungen sind gern zu hoch Gefahr: Business Case rechnet sich nicht, bzw. Projekt wird an Mitbewerber verloren. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 11

12 Schätzung als Planungsgrundlage Wenn Schätzungen so fehlerbehaftet und schwierig ist, warum schätzt man dann überhaupt? Top-down Auch eine falsche Schätzung ist besser als ein kompletter Blindflug. Eine Schätzung ist die Grundlage der Planung. Man merkt bei der Planausführung frühzeitig, ob eine Schätzung falsch ist und kann dann nachsteuern. Auch Schätzen ist ein Prozess: sobald erste Erfahrungen und ermittelte Aufwände im Projekt vorliegen, wird nachgeschätzt und die Schätzung korrigiert Die Schätzung wird im Laufe des Projekts immer genauer. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 12

13 Einflussfaktoren für Schätzungen Umzusetzende Wichtigste Fachlichkeit Einflussfaktoren (funktional) auf den Aufwand PM-Faktoren Masken Druckstücke Batches Berechnungen zu berücksichtigende Fehlersituationen Migrationen aus Altsystemen Abhängigkeit von andern Systemen Technologische Umsetzung nicht-funktionale Anforderungen Performance, Antwortzeitverhalten Mengengerüste Architektur Systemplattform, Basis-Technologien Team Mitarbeiterqualifikation Erfahrung Eingespieltes Team Projektorganisation Projetvorgehen, Methodik Unterstützung durch Tools Sonstige Faktoren Auftraggeber Aufwände steigen mit Größe der Aufgabe Prof. Dr. Ina Schaefer Software Engineering 1 Seite 13

14 Vorgehen bei einer Schätzung Vorbereiten Schätzen Messen, Vergleichen Lernen Nachschätzen Hinweise Eine gute Vorbereitung ist elementar für die Schätzung Komplettieren und Strukturieren der Schätzgrundlage (osintots oh shit, I never thought of this) Sammeln aller Faktoren Nachschätzen und aus Projekterfahrungen lernen ist ein stetiger Kreislauf während des Projekts Prof. Dr. Ina Schaefer Software Engineering 1 Seite 14

15 Schätzverfahren Schätzverfahren unterscheiden sich in Zielsetzung, Aufwand und Genauigkeit Vergleichsmethoden Kennzahlenmethode Algorithmische Methoden Experten- Schätzungen Analogieschätzung Kennzahlenmethode COCOMO Function-Points Use-Case-Points Einzelschätzung Delphi-Methode Schätzklausur Stellt Bezug zu durchgeführten Entwicklungsprojekten her Erfahrungswerte aus alten Projekten nötig Berechnung von Schätzposten aus explizit geschätzten Ähnlich Analogiemethode Aufwandsermittlung per empirisch gewonnenen Formeln Basis sind messbare Systemfunktionen, z. B. Use-Case-Points Schätzung von Stücklisten Zählen und bewerten Gibt eine Größenordnung zur Verifikation Erfahrungswerte für Kennzahlen aus abgeschlossenen Projekte nötig Teilw. aufwändig, aber gute Resultate ohne Justierung wenig präzise Erstmalige Schätzung neuer Anforderungen durch Expertenerfahrung Selten in Reinform, aber implizit in Expertenschätzung Kennzahlen aus dem Aufwandsmodell zur Plausibilisierung Use-Case-Points verwenden wir zur Plausibilisierung bei Capgemini hauptsächlich eingesetzte Methode Prof. Dr. Ina Schaefer Software Engineering 1 Seite 15

16 Function Point Verfahren Vorgehen im Überblick Bewertung der Komplexität der Fachlichkeit (Datenfluss) Bewertung sonstiger Einflussfaktoren Ermittlung der Gesamtkomplexität, Berechnung des Aufwands Hinweise Function Point Schätzungen werden in verschiedenen Firmen unterschiedlich gelebt. Alle arbeiten nach dem gleichen Prinzip, Unterschiede gibt es in: Kriterien, nach denen die Komplexität der Fachlichkeit gemessen wird Betrachtete sonstige Einflussfaktoren Unternehmensspezifische Gewichtung Im Folgenden: ursprüngliches Verfahren Prof. Dr. Ina Schaefer Software Engineering 1 Seite 16

17 Bewertung der Fachlichkeit Details zum ersten Schritt Bewertung der Komplexität der Fachlichkeit (Datenfluss) Bewertung sonstiger Einflussfaktoren Ermittlung der Gesamtkomplexität, Berechnung des Aufwands Inhalte Strukturierte Erfassung der Fachlichkeit: Eingabedaten (Bildschirm, Batch, etc.) Ausgabedaten (Bildschirm, Druck, Interface, etc.) Anfragen (Suchanfragen) Eigene Datenbestände (lesen & schreiben) Extern referenzierte Datenbestände (nur lesen) Zu jedem Punkt Bewertung: geringe/mittlere/hohe Komplexität Ableiten der FP aus Tabelle mit FP-Werten für die jeweilige Komplexität Prof. Dr. Ina Schaefer Software Engineering 1 Seite 17

18 Bewertung durch Function Points Beispiel für eine Function Point Bewertung Schätzposten Komplexität FP Eingabedaten Kunde gering 3 Bankverbindung mittel 4 Anfragen Kundensuche mittel 10 Summe 458 Schätztabelle Bewertungen Eingabedaten gering 3 mittel 4 hoch 6 Eigene Datenbestände gering 7 mittel 10 hoch 15 Prof. Dr. Ina Schaefer Software Engineering 1 Seite 18 FP-Werte für jeweilige Komplexitäten

19 Bewertung der Einflussfaktoren Details zum zweiten Schritt Bewertung der Komplexität der Fachlichkeit (Datenfluss) Bewertung sonstiger Einflussfaktoren Ermittlung der Gesamtkomplexität, Berechnung des Aufwands Inhalte Bewertung sonstiger Einflussfaktoren: Verflechtung mit anderen Systemen Dezentrale Verarbeitung und Datenhaltung Transaktionsrate und Antwortzeitverhalten Verarbeitungskomplexität (Rechenoperationen, Ausnahmebehandlungen, Logik, =) Wiederverwendbarkeit Migrationen Benutzerfreundlichkeit Auch daraus wird wieder ein numerischer Faktor abgeleitet. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 19

20 Berechung des Gesamtaufwands Details zum dritten Schritt Bewertung der Komplexität der Fachlichkeit (Datenfluss) Bewertung sonstiger Einflussfaktoren Ermittlung der Gesamtkomplexität, Berechnung des Aufwands Inhalte Gesamtkomplexität in Total Function Points (TFP) durch Verrechnung (i. d. R. Multiplikation) der Faktoren Errechnung des Aufwands z. T. mit Zwischenschritt über die zu erstellenden Codezeilen (Lines of Code LOC) für eine jeweilige Programmiersprache. TFP/LOC Personenmonate Prof. Dr. Ina Schaefer Software Engineering 1 Seite 20

21 Bewertung des FP-Verfahrens Bewertung Systematische Herangehensweise In Function Points wird die fachliche Komplexität der Aufgabe gemessen, nicht die Komplexität der technischen Lösung. Lebt von den jeweiligen Erfahrungswerten des Unternehmens und der Personen. Insbesondere in den zweiten Schritt gehen unternehmensspezifische Erfahrungen ein, die schwer zu begründen und in anderen Kontexten zu reproduzieren sind. Wird in unterschiedlichen Unternehmen auch unterschiedlich gehandhabt. Nach einiger Zeit der Anwendung erzielt man reproduzierbare Ergebnisse in der Function Point Messung. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 21

22 Expertenschätzung Hinweise zum Vorgehen Aufwände und Umsetzung werden explizit geschätzt, nicht über Lines of Code oder Faktoren. Bei einer Expertenschätzung sind in der Regel mindestens zwei Experten beteiligt, um Schätzergebnisse vergleichen zu können. Generelle Unterscheidung in der Vorgehensweise: Standard-Delphi-Verfahren: Experten schätzen komplett unabhängig Breitband-Delphi-Verfahren: Experten diskutieren Zwischenergebnisse. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 22

23 Expertenschätzung nach Delphi-Verfahren Erstellen Schätzpostenliste Liste mit jedem Experten durchsprechen, erläutern Experte schätzt jeden Schätzposten, Rückfrage möglich Falls Breitband-Verfahren: Experten-Diskussion Prüfung Ergebnisse Ergebnis = Durchschnittwerte der Einzel-Schätzungen z. B. falls unplausibel, Abweichungen zwischen Experten Neue Liste mit unklaren Posten, neu kommentiert Prof. Dr. Ina Schaefer Software Engineering 1 Seite 23

24 Schätzpostenliste Schätzposten Benötigt: vollständige funktionale Beschreibung des Systems Beispiele für Schätzposten Dialog Druckstück Funktionen, Services Entitäten & Persistenz der Entitäten Querschnittliche Funktionen (Drucken, Fehlerbehandlung, etc.) Granularität eines Schätzpostens (Daumenregeln) nicht kleiner als 1 Tag, sonst addieren sich Nichtigkeiten zu großen Aufwänden nicht größer als 20 Tage, sonst wird die Schätzung zu ungenau guter Bereich: 5 10 Tage Prof. Dr. Ina Schaefer Software Engineering 1 Seite 24

25 Schätzgröße in der Expertenschätzung Hinweise zur Schätzgröße BT Schätzgröße BT = Bearbeitungstag, auch PT = Personentag oder MT = Manntag Die Arbeit, die eine Person an einem Tag erledigen kann Die Arbeit ist brutto gerechnet, d. h. die wirkliche Zeit, die man benötigt, d. h. Entwicklung inklusive: Entwicklertest Code-Dokumentation Nacharbeiten Reisekostenabrechnung, Stundenkontierung in SAP, Kaffee trinken, Zigarrettenpause Teilnahme an Meetings Anderen Kollegen helfen Rechner ist abgestürzt, Netzwerk ist weg, Prof. Dr. Ina Schaefer Software Engineering 1 Seite 25

26 Vorgehen bei einer vereinfachten Schätzung Schritt Schätzung der Realisierung Hochrechnung auf alle Phasen Zuschläge Beschreibung Schätzung der reinen Realisierungs- Aufwände Hochrechnung von Fachlicher Konzeption Technischer Konzeption Test & Integration aus den Realisierungs-Werten Addieren von Zuschlägen, z. B. für Projektkoordination, Gewährleistung, Qualitätssicherung, etc. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 26

27 Schätzung der Realisierung Vorgehen Schätzung bei der Schätzung der Realisierung Geschätzt wird die reine Brutto-Realisierung. Annahmen dabei: Alle fachlichen Fragen sind geklärt Algorithmen sind klar Technologie ist klar Mitarbeiter ist geschult Normale Projektmitarbeiter, keine Technologie-Experten (wie diejenigen, die schätzen) Eigentlich ist eine detaillierte Schätzung erst nach Abschluss der fachlichen Konzeption möglich. Zu diesem Zeitpunkt kennt man die Aufwände der fachlichen Konzeption schon bzw. kann sie abschätzen. Diese Aufwände kann man zur Plausibilisierung mit den geschätzten Realisierungsaufwänden vergleichen. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 27

28 Hochrechnung von Realisierungsaufwänden Beispiel: Erfahrungswerte der Firma sd&m Realisierung 40% Test und Integr. 15% fachl. Konzept 30% tech. Konzept 15% Nutzung der Werte Hochrechnung: Nach diesen Erfahrungswerten ist der Gesamtaufwand 2,5x so hoch wie der Realisierungsaufwand Plausibilisierung: Nach Abschluss des fachlichen Konzepts sollten 30% des Projektbudgets verbraucht sein. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 28

29 Aufschläge bei der Realisierungsschätzung Erfahrungswerte für Zuschläge bei sd&m Zuschlag Erfahrungswerte Technik - Software-Entwicklungsumgebung Aufbau geplant, Pflege MA über Zeit - Technische Infrastruktur 5-10%, oder MA über Zeit - Konfigurationsmanagement Aufbau geplant, Pflege MA über Zeit Datenadministration (optional) 5-10% Abnahmesupport MA über Zeit Chefdesign (CD) 5-10%, oder MA über Zeit Qualitätssicherung (QS) Aktivitäten oder 10-20% Einarbeitung 2-4 Wochen bei Projekteinstieg Team-Meetings MA über Zeit PM/PL 10-25%, 1 PL pro ca. 7 MA über Zeit Puffer bzw. Risikozuschlag 10-40% Gewährleistung 3-12% Sonstiges Projektspezifisch Reisezeit MA über Zeit Reisespesen ableitbar aus Reisezeit Zugekaufte Leistungen tatsächliche Kosten Bei Großprojekten kann die Realisierung nach Berechnung aller Zuschläge nur noch 16% des Gesamtaufwands betragen! Prof. Dr. Ina Schaefer Software Engineering 1 Seite 29

30 Repräsentanten und Stützpunkte schätzen Tipps Problem zur Schätzung großer Schätzpostenlisten Problem: Was tun, wenn die Schätzpostenliste sehr groß ist, z. B. wenn das System mehrere hundert Dialoge umfasst? Der Aufwand zur Schätzung wird dann sehr groß Lösung 1: Beispiel mit Bildung von Klassen. Klassen: Einfache Dialoge, Mittelschwere Dialoge, Schwierige Dialoge Extrem schwierige Dialoge trotzdem individuell schätzen Schätzen von einem Repräsentanten jeder Klasse Lösung 2: Beispiel mit Schätzung von Stützpunkten Fünf Dialoge wählen, die das ganze Spektrum der Komplexität abdecken. Andere Dialoge werden nicht geschätzt, sondern mit den Stützpunkten verglichen. Aufwandszahlen der Stützpunkte werden übernommen und ggf. leicht angepasst. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 30

31 Schätzunsicherheit Vorgehen Problem bei einer Min-Max-Schätzung Schätzungen sind immer mit einer Schätzungenauigkeit und einem Risiko behaftet. Min-Max-Schätzung Idee: Experte schätzt minimalen und maximalen Aufwand für die Aufgabe. Wichtig: kein zu großes Delta zwischen Min und Max, guter Erfahrungswert ca.: 20%, in der Praxis aber leider oft höher. Die Planung wird am Minimalwert ausgerichtet, aber so mit Personen hinterlegt, dass die maximalen Aufwände in der Projektlaufzeit möglich zu erbringen sind. Weitere Möglichkeit zur Min-Max-Schätzung: Min, Max und Normalwert schätzen, dann rechen mit: (Min + Max + 4*Norm) / 6 Prof. Dr. Ina Schaefer Software Engineering 1 Seite 31

32 CoCoMo Verfahren Idee Schätzung der Projektgröße in LOC (Lines of Code) bzw. KDSI (Kilo Delivered Software Instructions), d. h. ohne Kommentare. Nach Verrechnung mit weiteren Kennzahlen wird der Gesamtaufwand E berechnet (MM DEV Entwicklungsaufwand in PM) und die Projektlaufzeit (TDEV) Formel MM DEV = a * KDSI b * m(x) Entwickelt von Barry Boehm (*1935) Prof. Dr. Ina Schaefer Software Engineering 1 Seite 32

33 Projektklasse Einfluss der Projektklasse auf die Aufwandsschätzung MM DEV = a * KDSI b * m(x) Organic Mode einfache SW-Projekte eingespieltes Team, bekannte Umgebung, wenig Neuland Größe <50 KDSI Faktor b = 1,05 Semi-detached Mode mittelschwere Projekte Größe <300 KDSI Faktor b = 1,12 Embedded Mode schwierige Projekte starker Kosten- Termindruck, viel Neuland Größe: beliebig Faktor b: 1,20 Prof. Dr. Ina Schaefer Software Engineering 1 Seite 33

34 Modellvarianten Einfluss der Modellvarianten auf die Schätzung MM DEV = a * KDSI b * m(x) Basismodell früh, zu Beginn eines Softwareprojekts ganzheitliche Betrachtung Ausgangspunkt für weitere Schätzungen Zwischenmodell Berücksichtigung von 15 Einflussparametern keine Differenzierung zwischen Phasen Detailmodell Berücksichtigung von 15 Parametern Abweichungen der Aufwände aus den einzelnen Phasen berücksichtigt Prof. Dr. Ina Schaefer Software Engineering 1 Seite 34

35 Weitere 15 Einflussfaktoren MM DEV = a * KDSI b * m(x) m(x) = m(x1) * m(x2) * * m(x15) Produkt RELY: geforderte Zuverlässigkeit der Software DATA: Größe der Datenbasis CPLX: Komplexität des Produktes Personal ACAP: Analysefähigkeit der Mitarbeiter AEXP: Erfahrung der Mitarbeiter im Arbeitsgebiet PCAP: Programmierfähigkeit der Mitarbeiter VEXP: Erfahrung der Mitarbeiter in der Systemumgebung LEXP: Erfahrung der Mitarbeiter in der Programmiersprache Projekt MODP: Verwendung moderner Entwicklungsmethoden TOOL: Verwendung von Tools SCED: Anforderungen an die Entwicklungszeit Computer TIME: benötigte Rechenzeit STOR: Nutzung des verfügbaren Speicherplatzes VIRT: Änderungshäufigkeit der Systembasis TURN: Bearbeitungszyklus Prof. Dr. Ina Schaefer Software Engineering 1 Seite 35

36 Berechnung des Gesamtaufwands in CoCoMo Prof. Dr. Ina Schaefer Software Engineering 1 Seite 36

37 Bewertung von CoCoMo Bewertung Die Schätzmethode CoCoMo bzw. CoCoMo II ist wenig verbreitet. Die Methode macht deutlich, welche Einflussfaktoren für die Schätzung relevant sind: Zeitpunkt der Schätzung Typ des Projekts 15 detaillierte Einflussfaktoren Prof. Dr. Ina Schaefer Software Engineering 1 Seite 37

38 Tipps zur Schätzung Tipps Keine Angst vor großen Zahlen. Schätzungen ergeben oft hohe Werte. Stehen Sie dazu. Software ist teuer. Eine ehrliche Schätzung ist die Grundlage für den Projekterfolg. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 38

39 Projektplanung Planung Ein Plan zeigt die Machbarkeit eines Vorhabens. Wenn man nicht einmal einen Plan erstellen kann, dann ist das Vorhaben nicht machbar. Ein Plan wird im Projekt ständig nachgeführt und aktualisiert. Dadurch kann der Projektleiter sein Projekt ins Ziel führen. Ein Plan ist die Grundlage, um ein Projekt zu steuern Ohne Steuerung und Plan erkennt man erst zu Projektende, ob sich der Projekterfolg einstellt Mit Steuerung: Gefährdungen sind früh erkennbar, man kann auf darauf reagieren è Auch ein falscher Plan ist besser als gar kein Plan. Die Alternative wäre ein totaler Blindflug. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 39

40 Planung als Prozess Fallbeispiel: Zitat Projektleiter Damals haben wir mit viel Aufwand den Plan gemacht und nach zwei Wochen hat er schon nicht mehr gestimmt. Grundideen einer Planung Eine Planung wird zu Projektbeginn erstellt und dann ständig verfeinert und angepasst. Eine Planung veraltet, sobald sie fertig ist. (Und manchmal auch schon, während sie erstellt wird) Eine Planung ist keine Vorhersage. Ein Projekt kann man nicht ausrechnen. Die Planung ist ein Werkzeug. Sie ist das wichtigste Arbeitswerkzeug des Projektleiters. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 40

41 Projektplanung im Projektmanagement Anpassen Planung SOLL Controlling (Überwachen) Steuern SOLL IST Meilensteine, Restaufwandsschätzungen Handlungsbedarf Maßnahmen Projektverlauf, Ausführen des Plans Prof. Dr. Ina Schaefer Software Engineering 1 Seite 41

42 Inhalte der Planung Fragestellung WER (Personen) macht WANN (Termine) WAS (Aufgaben) ggf. WOMIT (Arbeitsmittel)? Inhalte Im Projektplan finden sich die Elemente: Aufgabe, Aktivität/ Arbeitspaket (oft synonym verwendet) Ressourcen, insbesondere Personen Aufwände und Puffer Termine Prof. Dr. Ina Schaefer Software Engineering 1 Seite 42

43 Planungstechniken Gantt-Diagramm Stellt besonders gut den zeitlichen Verlauf dar In der Praxis größte Verbreitung Unterstützung durch Tools, oft Default-Ansicht Netzplan Z. B.: MPM-Methode Stellt besonders gut die Abhängigkeiten zwischen Arbeitspaketen dar Prof. Dr. Ina Schaefer Software Engineering 1 Seite 43

44 Definition eines Netzplans Netzplan In Netzplänen werden dargestellt: Vorgänge, Ereignisse und deren Abhängigkeiten. Definitionen DIN Definition Netzplan: Der Netzplan ist die graphische Darstellung von Ablaufstrukturen, welche die logische und zeitliche Aufeinanderfolge von Vorgängen veranschaulichen. Definition Vorgang: Ein Vorgang ist eine Zeit beanspruchende Tätigkeit, die über einen definierten Anfang und ein definiertes Ende verfügt. Definition Ereignis: Ein Ereignis signalisiert das Eintreten eines definierten und beschreibbaren Zustands im Projektablauf (z. B. Meilenstein). Prof. Dr. Ina Schaefer Software Engineering 1 Seite 44

45 Grundtypen von Netzplänen Vorgangspfeil-Netzplan Knoten: Ereignisse Pfeile: Vorgänge Ereignis Vorgang Ereignis Beispiel: Critical Path Method (CPM) Ereignisknoten-Netzplan Knoten: Ereignisse Pfeile: Abhängigkeiten Ereignis Ereignis Beispiel: Program Evaluation and Review Technique (PERT) Vorgangsknoten-Netzplan Knoten Vorgänge Pfeile: Abhängigkeiten Vorgang Vorgang Beispiel: Metra Potential Method (MPM) Prof. Dr. Ina Schaefer Software Engineering 1 Seite 45

46 Termine eines Vorgangs Früher Start FAT: Frühester Anfangstermin Der Termin, zu dem der Vorgang frühestens beginnen kann. FET: Frühester Endtermin Der Termin, zu dem der Vorgang frühestens abgeschlossen werden kann, wenn man zum FAT begonnen hat. (FAT + Dauer) Start Ende FAT FET Später Start SET: Spätester Endtermin Der Termin, zu dem der Vorgang abgeschlossen sein muss. SAT: Spätester Anfangstermin Der Termin, zu dem man spätestens angefangen haben muss, wenn man zum SET fertig sein will. (SET- Dauer) Start Ende SAT SET Prof. Dr. Ina Schaefer Software Engineering 1 Seite 46

47 Pufferzeiten Pufferzeiten Pufferzeit: Die Zeit, um die ein Vorgang verschoben werden kann. Freie Pufferzeit: Die Zeit, um die man einen Vorgang verschieben kann, ohne dass der nachfolgende Vorgang verschoben werden muss. Gesamtpufferzeit: Die Zeit, um die man einen Vorgang verschieben kann, ohne dass das Projektende verschoben werden muss. Pufferzeit Start Ende freie Pufferzeit Zeitfenster Prof. Dr. Ina Schaefer Software Engineering 1 Seite 47

48 Der kritische Pfad Kritischer Pfad Kritischer Pfad: Der Pfad vom Projektstart bis zum Projektende, auf dem ausschließlich Vorgänge ohne Pufferzeit liegen. Kritischer Vorgang: Vorgang auf dem kritischen Pfad Start krit. Vorgang krit. Vorgang Ende kritischer Pfad krit. Vorgang Kritische Vorgänge erfordern besondere Aufmerksamkeit im Projektmanagement. Jeder Verzug auf dem kritischen Pfad führt dazu, dass der Zieltermin des Projekts gefährdet ist. Prof. Dr. Ina Schaefer Software Engineering 1 Seite 48

49 Metra Potenzial Methode (MPM) Grundideen MPM Ausprägung der Netzplantechnik Spezielle Notation der Vorgänge mit FAT, FET, SAT, SET und Puffer Vorwärts- und Rückwärtsrechnung, um diese Daten für alle Vorgänge zu bestimmen durch die Unternehmensgruppe Metra entwickelt Nr. Vorgangsname Nr. Vorgangsname FAT Dauer FET SAT Gesamtpuffer SET Nr. Vorgangsname FAT Dauer FET SAT Gesamtpuffer SET Nr. Vorgangsname FAT Dauer FET SAT Gesamtpuffer SET FAT Dauer FET Nr. Nr. SAT Gesamtpuffer SET SAT Vorgangsname FAT Dauer FET Gesamtpuffer SET SAT Vorgangsname FAT Dauer FET Gesamtpuffer SET Prof. Dr. Ina Schaefer Software Engineering 1 Seite 49

50 Gantt Diagramme Grundideen Gantt Anderer Name: Balkendiagramm Vorgänge werden durch Balken auf einem Kalender dargestellt. Vorteil: intuitiv verständlich, man sieht sofort die Dauer der Vorgänge Abhängigkeiten weniger übersichtlich dargestellt Durch Henry L. Gantt ( ) entwickelt Prof. Dr. Ina Schaefer Software Engineering 1 Seite 50

51 Zusammenfassung Was ist ein Projekt? Aufgaben im Projektmanagement Aufwandsabschätzung Function Point Verfahren Expertenschätzung (Delphi-Verfahren) CoCoMo Verfahren Planungstechniken Netzplantechnik Gantt Charts Prof. Dr. Ina Schaefer Software Engineering 1 Seite 51