Aufwandsabschätzung und Projektplanung

Transkript

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

2 Übersicht Sätzung Allgemeine Grundlagen Function Point Verfahren Expertenschätzung (Delphi-Verfahren) CoCoMo Verfahren Projektplanung Inhalte der Planung Planungstechniken Seite 6

3 Schätzungen Seite 7

4 Gewünschter Zeitpunkt der Schätzung Fachliche Konzeption Technische Konzeption Realisierung Test & Integration Umfang der Funktionalität bekannt Fachliche Funktionen, Masken Umsetzung bekannt Seite 8

5 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 Seite 9

6 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 Seite 10

7 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. Seite 11

8 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. Seite 12

9 Einflussfaktoren für Schätzungen Wichtigste Einflussfaktoren auf den Aufwand Umzusetzende Fachlichkeit (funktional) 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 Seite 13

10 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 Seite 14

11 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 Seite 16

12 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 Seite 17

13 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 FP-Werte für jeweilige Komplexitäten Seite 18

14 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. Seite 19

15 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 Seite 20

16 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. Seite 21

17 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. Seite 22

18 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 Seite 23

19 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 Seite 24

20 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, Seite 25

21 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 Rea-Werten Addieren von Zuschlägen, z. B. für Projektkoordination, Gewährleistung, Qualitätssicherung, etc. Seite 26

22 Schätzung der Realisierung Vorgehen bei der Schätzung der Realisierung Schätzung 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. Seite 27

23 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. Seite 28

24 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! Seite 29

25 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. Seite 30

26 Schätzunsicherheit Vorgehen Problembei 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 Seite 31

27 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 Seite 32

28 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 Seite 33

29 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 Seite 34

30 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 Seite 35

31 Berechnung des Gesamtaufwands in CoCoMo Seite 36

32 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 Seite 37

33 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. Seite 38

34 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. Seite 39

35 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. Seite 40

36 Projektplanung im Projektmanagement Anpassen Planung SOLL Controlling (Überwachen) Steuern SOLL IST Meilensteine, Restaufwandsschätzungen Handlungsbedarf Maßnahmen Projektverlauf, Ausführen des Plans Seite 41

37 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 Seite 42

38 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 Seite 43

39 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). Seite 44

40 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) Seite 45

41 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 Seite 46

42 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 Seite 47

43 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. Seite 48

44 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 SET Nr. Vorgangsname FAT Dauer FET SAT Gesamtpuffer Gesamtpuffer SET Nr. Vorgangsname FAT Dauer FET SAT Gesamtpuffer SET FAT Dauer FET Nr. Nr. SAT Gesamtpuffer SET SAT Vorgangsname FAT Dauer FET SET SAT Vorgangsname FAT Dauer FET Gesamtpuffer Gesamtpuffer SET Seite 49

45 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 Seite 50

46 Zusammenfassung Was ist ein Projekt? Aufgaben im Projektmanagement Aufwandsabschätzung Function Point Verfahren Expertenschätzung (Delphi-Verfahren) CoCoMo Verfahren Planungstechniken Netzplantechnik Gantt Charts Seite 51