Projektmanagement - Block 6 Aufwands- und Ressourcenplanung Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische.

Präsentation zum Thema: "Projektmanagement - Block 6 Aufwands- und Ressourcenplanung Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische."—  Präsentation transkript:

1 Projektmanagement - Block 6 Aufwands- und Ressourcenplanung Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität Graz, Austria Christian Gütl Version 1.00 http://www2.iicm.edu/pm/vorlesungsunterlagen/block6_ss2006.ppt

2 © 2006 - Christian Gütl 18.09.2016 2 PPA und Aufwandsbestimmung Abschätzung d. Projektumfanges  Grobe Aufwands-bestimmung Abschätzung d. Projektumfanges  Detaillierte Aufwands-bestimmung Abschätzung d. Projektumfanges und Zeitplan  Personen-basierte Aufwands-bestimmung

3 © 2006 - Christian Gütl 18.09.2016 3 Agenda Grundlagen der Aufwandsabschätzung –Operative Aktivitäten –Organisatorische Aktivitäten Ermittlung der Projektkosten Zeitplan Besonderheiten der Softwareentwicklung

4 © 2006 - Christian Gütl 18.09.2016 4 Ziele Aufwandsabschätzverfahren erklären und anwenden können Projektkosten ermitteln Projektzeitpläne erstellen können Softwarespezifische Kenngrößen und Aufwandsabschätzungen erklären und anwenden können

5 © 2006 - Christian Gütl 18.09.2016 5 Abschnitt 1 Allgemeines und Einleitung

6 © 2006 - Christian Gütl 18.09.2016 6 Zuverlässigkeit der Abschätzungen

7 © 2006 - Christian Gütl 18.09.2016 7 Arten den Aufwandsschätzung 1 Arten der Aufwandsschätzung –Größenordnungsanalyse Ohne detaillierte technische Daten Mittels Skalierungsfaktoren od. parametrische Methode Fehlerbereich von +/(-) 35 % –Näherungswertverfahren Ohne detaillierte technische Daten Erfahrungen aus vergangenen, ähnliche Projekten  Analogiemethode Fehlerbereich von +/(-) 20 % –Definitive od. Detaillierte Aufwandsschätzung Berücksichtigung genauer technische Daten (Berücksichtigung der Einzelheiten) Fehlerbereich von +/(-) 5 %

8 © 2006 - Christian Gütl 18.09.2016 8 Arten den Aufwandsschätzung 2 Die Aufwandsunterschätzung kann unterteilt werden in –Operative Aufwand –Organisatorischen Aufwand (Managementaktivitäten) Die Kosten ergeben sich mit Bewertung der Arbeitsleistung –Operative Kosten –Organisatorische Kosten und –Sonstige Kosten

9 © 2006 - Christian Gütl 18.09.2016 9 Abschnitt 2 Abschätzung des operativen Projektaufwandes

10 © 2006 - Christian Gütl 18.09.2016 10 PPA und Aufwandsbestimmung Abschätzung d. Projektumfanges  Grobe Aufwands-bestimmung Abschätzung d. Projektumfanges  Detaillierte Aufwands-bestimmung Abschätzung d. Projektumfanges und Zeitplan  Personen-basierte Aufwands-bestimmung

11 © 2006 - Christian Gütl 18.09.2016 11 Phasen-basierte Abschätzung 1 Phasen-basierte Aufwandsabschätzung –Ist ein algorithmisches Aufwandsmodell –Grundprinzip Unterteilt das Projekt in Phasen (Abschnitte) Einbezug von Erfahrungen aus der Vergangenheit  Aufteilungsschlüssel des Aufwandes von ähnlichen Projekten Adaptiert man den Aufteilungsschlüssel je nach Projektcharakteristiken Abschätzung einer Phase und Extrapolation auf die anderen Phasen Bestimmung der Vollzeit-Äquivalenten Bestimmung der geschätzten Zeitdauer der Phasen, der möglichen Überlappungen und der Gesamtprojektdauer

12 © 2006 - Christian Gütl 18.09.2016 12 Phasen-basierte Abschätzung 2 Summe 10Implement 20System Testing 15Code & Unit Test 30Design 25Requirements %Phase Schritt 1: Erstelle od. wähle Phasen-basiertes Modell –Quelle Eigene, Team- od. Unternehmens-Erfahrungen Aufzeichnungen/Auswertungen fertiger Projekte Literatur (Industriedaten)

13 © 2006 - Christian Gütl 18.09.2016 13 Phasen-basierte Abschätzung 3 109,5Summe 10Implement 20System Testing 15+7Code & Unit Test 30+2,5Design 25Requirements %Phase Schritt 2: Passe Phasen-basiertes Modell an –Berücksichtigt Abweichungen des spezifischen Projektes zu den Erfahrungen/Daten aus der Vergangenheit –Z.B. Code & Unit Test +7 % –Prozentsatz kann von 100 % abweichen !!!

14 © 2006 - Christian Gütl 18.09.2016 14 Phasen-basierte Abschätzung 4 2240109,5Summe 20010Implement 40020System Testing 300+14015+7Code & Unit Test 600+10030+2,5Design 50025Requirements Stunden%Phase Schritt 3: Schätze Aufwand einer Phase und extrapoliere Aufwand aller Phasen –Herausforderung Auswahl der Phase für die Abschätzung Annahmen/Fehler extrapolieren sich –Z.B. Abschätzung d. Requirementphase  500 h für 25 %

15 © 2006 - Christian Gütl 18.09.2016 15 Phasen-basierte Abschätzung 5 2240109,5Summe 1,7520010Implement 3,5040020System Testing 3,85300+14015+7Code & Unit Test 6,13600+10030+2,5Design 4,3850025Requirements PMStunden%Phase Schritt 4: Bestimme die geschätzten Personenmonate (PM) für jede Phase –Abhängig von der Produktivität („Produktivstunden am Tag“ und durchschn. Arbeitstage pro Monat) –Annahme: 6,5 h/d * 17,5 d/m = 114 h/m

16 © 2006 - Christian Gütl 18.09.2016 16 Phasen-basierte Abschätzung 5 2,0 3,0 3,5 3,0 OVZA 2240109,5Summe 21,7520010Implement 33,5040020System Testing 33,85300+14015+7Code & Unit Test 36,13600+10030+2,5Design 34,3850025Requirements WVZAPMStunden%Phase Schritt 5: Bestimme die Vollzeit- Äquivalente –Rechnerische, optimale Vollzeit-Äquivalente  Formel gut in Praxis getestet  Versagt bei sehr großen PM mit vielen Parallelaufgaben und bei PM=1  OVZA=1 –Bestimmung der wahrscheinlichen Vollzeit-Äquivalente (WVZA)  Verfügbarkeit !!!

17 © 2006 - Christian Gütl 18.09.2016 17 Phasen-basierte Abschätzung 6 2 3 3 3 3 WVZA 1 1,2 1,3 2,1 1,5 M 2,0 3,0 3,5 3,0 OVZA 2240109,5Summe 1,7520010Implement 3,5040020System Testing 3,85300+14015+7Code & Unit Test 6,13600+10030+2,5Design 4,3850025Requirements PMStunden%Phase Schritt 6: Bestimme die geschätzte Dauer d. Phasen –Ergibt sich aus M = PM/WVZA –Achtung!!! Gesamtdauer kann nicht einfach aufsummiert werden  Überlappung der Phasen berücksichtigen  Gannt Chart Abschätzen durch Projektcharakteristik und Vorwissen Unsicherheitsbereich angeben (je Projektcharakteristik  Auswirkung auf Projektdauer und Ressourcen)

18 © 2006 - Christian Gütl 18.09.2016 18 Phasen-basierte Abschätzung 7 Anwendung dieser Abschätzungsmethode –Für … gut definierte und wiederkehrende Anwendung von Projektphasen Verfügbarkeit von geeigneten Erfahrungen –Für mittelgroße Projekte Etwa Projektlaufzeit von 6 bis 12 Monate Hinweise –Größere Projekte können in mehrere kleinere Projekte aufgeteilt werden –Bei Projekten mit kürzerer Laufdauer ist Deliverable-basierte Abschätzung besser  man erhält exaktere Abschätzungen

19 © 2006 - Christian Gütl 18.09.2016 19 Deliverable-basierte Abschätzung 1 Deliverable-basierte Abschätzung –Basiert auf der Aufwandsabschätzung von Projektergebnissen bzw. vom Aufwand von Tätigkeiten, die zum Ergebnis führen –Prinzipielle Vorgehensweise Definiere die Phasen des Projektes Unterteile die Phase in Deliverables Beschreibe jedes Deliverable Aufwandsabschätzung für jedes Deliverable Bestimme Projekt Gannt-Chart und Projektlaufdauer Bestimme die Projektkosten Hinweis aus der Praxis –Häufigste Probleme bei fehlerhaften Abschätzungen sind übersehene Deliverables !!!

20 © 2006 - Christian Gütl 18.09.2016 20 Deliverable-basierte Abschätzung 2 Template zur Aufwandsabschätzung 1 –Deliverable Name –Deliverable Owner Verantwortliche des Deliverables –Beschreibung Klare, kurze, prägnante Beschreibung –Erfolgskriterien Festlegung des positiven Abschlusses –Benötigte Ressourcen Type der Ressourcen und Skills –Mögliche Ressourcenbesetzung Wenn möglich Personen nennen Sonst Stellenbeschreibungen

21 © 2006 - Christian Gütl 18.09.2016 21 Deliverable-basierte Abschätzung 3 Template zur Aufwandsabschätzung 2 –Geschätzter Aufwand unter Berücksichtigung der Ressourcen den Aufwand abschätzen –Geschätzte Fertigstellungsdauer –Geschätzte Kosten –Lag Darstellung von Abhängigkeiten zwischen Tasks bzw. zwischen Deliverables

22 © 2006 - Christian Gütl 18.09.2016 22 Deliverable-basierte Abschätzung 4 Noch nicht bestimmtGeschätzte Kosten 5 TageLag 6 TageGeschätzte Fertigstellungsdauer 24 h Mid-Level Technical Writer 10 h Mid-Level Business Analyst Geschätzter Aufwand Wie obenMögliche Ressourcenbesetzung 1 Mid-Level Business Analyst, 1 Mid-Level Technical WriterBenötigte Ressourcen Geeignet für KundenreviewErfolgskriterien Dokument zur Beschreibung der Anforderungen der Benutzer an das grafische User InterfaceBeschreibung Business AnalystDeliverable Owner Kundenanforderung für GUIDeliverable Name

23 © 2006 - Christian Gütl 18.09.2016 23 Deliverable-basierte Abschätzung 5 Anwendung dieser Abschätzungsmethode –Für Mittelgroße Projekte Etwa 4 bis 6 Monate Laufzeit Bei wichtigen technischen Projekten Hinweis –Projektdauer unter 4 Monate  Anwendung von Task-basierten Abschätzungen  Analoger Vorgang –Projektdauer über 6 Monate  Deliverables lassen sich über große Zeitspanne schwer planen  Abhilfe durch Aufsplitung  Ersten 6 Monate Deliverable-basierte Abschätzung  Dann Phasen-basierte Abschätzung

24 © 2006 - Christian Gütl 18.09.2016 24 Einzuplanende Reserven –Die Praxis hat sich gezeigt, dass das Einplanen von Reserven sinnvoll ist Aufwand für Überarbeitungen Aufwand für wachsenden Projektumfang Reserven für schwer vorhersehbare Risken „10 % Reserve für Unvorhergesehenes!“ Hinweis –Alle 3 Punkte zusammen werden auch als Managementreserve bezeichnet

25 © 2006 - Christian Gütl 18.09.2016 25 Reserve für Überarbeitungen Unvermeidlich fallen Überarbeitungen an bei –Hochkomplexen Projekten –Laufdauer über 4 Monate Begründung –Technologie-Änderungen –Design-Überarbeitungen –Lernkurve (neue Einsichten im Verlaufe des Projektes) Nach [Kapur 2005]

26 © 2006 - Christian Gütl 18.09.2016 26 Reserve für wachsenden Projektumfang Komplexität und Unsicherheiten gehen Hand in Hand Begründung –rührt her vom fehlenden Verständnis der Kundenbedürfnisse und einer instabilen Projektumgebung  Neue Deliverables werden identifiziert  Neue Tasks werden identifiziert Hinweis –Kann auch zusätzliche technologische Infrastruktur bedeuten Nach [Kapur 2005]

27 © 2006 - Christian Gütl 18.09.2016 27 PPA und Aufwandsbestimmung Abschätzung d. Projektumfanges  Grobe Aufwands-bestimmung Abschätzung d. Projektumfanges  Detaillierte Aufwands-bestimmung Abschätzung d. Projektumfanges und Zeitplan  Personen-basierte Aufwands-bestimmung

28 © 2006 - Christian Gütl 18.09.2016 28 Detaillierte Aufwandsabschätzung 1 Detaillierte Aufwandsabschätzung –Grundprinzip Basiert auf Task-basierter Aufwandsabschätzung –Zusätzlich Bestimmung der notwendigen Tasks für die einzelnen Deliverables –Abschätzung der Aufwandes für die einzelnen Tasks (Analog zu Deliverable-basierten Abschätzung) –Sog. Baseline Effort wird bestimmt –Zusätzlich Berücksichtigung von Projekteinflüssen Nutzung von Korrekturfaktor bzw. Effort Variance Factor (EVF) Nach [Kapur 2005]

29 © 2006 - Christian Gütl 18.09.2016 29 Detaillierte Aufwandsabschätzung 2 Baseline Effort –Aufwand für die Umsetzung eines Task eines Mitarbeiters unter folgenden Randbedingungen Exzellente Kenntnisse/Fähigkeiten (Skill Factor SK) –Sehr gute Kenntnisse des Anwendungsbereiches –Sehr gute technologische Kenntnisse Keine Arbeitsunterbrechungen (Working Interuption Factor WIF) Vollzeit an einem Projekt (Multiple Project Factor MPF) Sehr produktive Arbeitsumgebung (Project Productivity Influence Factor PPIF) Effort Variance Factor (EVF) –Tatsächlicher Aufwand durch reale Bedingungen gewichtet durch Einflussfaktoren

30 © 2006 - Christian Gütl 18.09.2016 30 Detaillierte Aufwandsabschätzung 3 4,0keine Erfahrungen im Fachbereich, intensives Training zur Erreichung der notwendigen Kompetenzen erforderlich, keine Arbeitserfahrung1,0 3,5wenig Erfahrungen im Fachbereich, intensives Training zur Erreichung der notwendigen Kompetenzen erforderlich, gute Arbeitseinstellung1,5 3,0Etwas Erfahrungen im Fachbereich, intensives Training zur Erreichung der notwendigen Kompetenzen erforderlich, gute Arbeitseinstellung2,0 2,5Weniger als 50 % der notwendigen Kompetenzen für Task, etwas Einblick in Fachbereich, mäßig erfahren2,5 2,0Grundlegende Kompetenzen für Task, etwas Einblick in Fachbereich, mäßig erfahren3,0 1,5Kompetent in allen Task-relevanten Fähigkeiten, solides Fachbereichswissen, erfahren3,5 1,0Exzellente Erfahrung, Fachbereichsexperte4,0 SFBeschreibungSkill Level Skill Factor (SK) –Einzelne MA bewerten und Faktor bestimmen

31 © 2006 - Christian Gütl 18.09.2016 31 Detaillierte Aufwandsabschätzung 4 Working Interuption Factor (WIF) –Drückt den Verlust von Produktivität durch nichtprojektrelevante Aktivitäten und ungeplante Unterbrechungen aus Z.B. Telefon u. E-Mail, ungeplante Meetings, …. –Formaler Zusammenhang –Ist ein nichtlinearer Zusammenhang, d.h. zur Unterbrechungszeit kommt die „Wiedereinarbeit-ungszeit hinzu“ (25 %  WIF=1,33) Hinweise –Nie mehr als 80% der Arbeitszeit verplanen –Mitarbeiter von Störungen abschatten

32 © 2006 - Christian Gütl 18.09.2016 32 Detaillierte Aufwandsabschätzung 5 1,25bis zu 20 %4 1,18bis zu 15 %3 1,11bis zu 10 %2 1,000 %1 MPF% ZeitverlustAnzahl Projekte Multiple Project Factor (MPF) –Höchst Produktivität erhält man, wenn Personen an Projekten vollzeitbeschäftigt sind –Mitarbeit an mehreren Projekten bedeutet ständiges Umdenken, Zwischenrufe, … –Formaler Zusammenhang –Empfohlene Zeitverluste

33 © 2006 - Christian Gütl 18.09.2016 33 Detaillierte Aufwandsabschätzung 6 Project Productivity Influence Factor (PPIF) –Nachfolgende Charakteristiken bewerten und Mittelwert bilden Number of Nemesis (1,0 und 1,5) Team Location u. Customer Location (1,0 und 1,5) –„1“ bei einem Ort, sonst je Kommunikationsaufwand Team size (1,0 und 1,5) –„1“ bei TS<=7, sonst je Größe u. Komplexität Team Synergy (1,0 und 1,5) –„1“ gute Zusammenarbeit, „1,5“ chaotische Struktur Team-Customer Synergy (1,0 und 1,5) –„1“ gute Zusammenarbeit, „1,5“ chaotische Struktur Tool Stability (1,0 und 1,5) –„1“ gut eingeführte Tools, bei Veränderungen >1 Vendor Support (1,0 und 1,5) Project Manager‘s Skill (1,0 und 2,0) –„2“ bei PM Anfänger, „1“ sehr erfahren

34 © 2006 - Christian Gütl 18.09.2016 34 Detaillierte Aufwandsabschätzung 7 Weitere Schritte der Abschätzung –Aus dem Zeitaufwand für die Tasks die geschätze Dauer der Tasks bestimmen –Lags bestimmen –Überlappungen und Gesamtdauer bestimmen Anmerkungen –Je nach Taskzuordnung zu verschiedenen Personen kann es zu großen Aufwandsunterschieden kommen –An dieser Stelle kann man nur von geplanter Zuordnung von Personen zu dem Projekt ausgehen; u.u. muss die Abschätzung auch mit Stellenbeschreibungen erfolgen

35 © 2006 - Christian Gütl 18.09.2016 35 PPA und Aufwandsbestimmung Abschätzung d. Projektumfanges  Grobe Aufwands-bestimmung Abschätzung d. Projektumfanges  Detaillierte Aufwands-bestimmung Abschätzung d. Projektumfanges und Zeitplan  Personen-basierte Aufwands-bestimmung

36 © 2006 - Christian Gütl 18.09.2016 36 Der Projektzeitplan 1 Projektzeitplan –Umfasst den Vorgang konkrete Ressourcen (Personen) zu den einzelnen Tasks zuzuordnen  erst jetzt sind die tatsächlichen Personen bekannt den geschätzten Aufwand anzupassen  die tatsächlichen Projektmitarbeiter bewerten und den jeweiligen Effort Variance Factor (EVF) bestimmen Netzplan (PERT Chart) überprüfen oder mit tatsächlichen Ressourcen festlegen und einen ersten Projektzeitplan (Baseline Schedule) mit tatsächlichen Terminen festzulegen  Balkendiagramm oder Gannt Chart

37 © 2006 - Christian Gütl 18.09.2016 37 Der Projektzeitplan 2 Beispiel Task Gannt Chart Beispiel Resource Gannt Chart Nach [Kapur 2005]

38 © 2006 - Christian Gütl 18.09.2016 38 Der Projektzeitplan 3 Beispiel Gannt Chart (Software erstellt) –Allgemein können Phasen, Deliverables, Tasks und Milestones dargestellt werden Hinweis –Hilfreich ist zusätzlich Liste der Deliverables und der Verantwortlichen Liste der Milestones –Pläne müssen über Projektverlauf aktuell gehalten werden

39 © 2006 - Christian Gütl 18.09.2016 39 Abschnitt 3 Abschätzung des Organisatorischen Aufwandes

40 © 2006 - Christian Gütl 18.09.2016 40 Organisatorischer Aufwand –zum Aufwand der Projektumsetzung fällt zusätzlich Aufwand an für Projektmanager Projektkunden Projektsponsor Steering Board  kann im Rahmen der allgemeinen Aufgaben gesehen werden  kann jedoch für die Mitglieder auch lästig werden –Der Aufwand hängt natürlich sehr stark vom Art des Projektes ab  Komplexität des Projektes

41 © 2006 - Christian Gütl 18.09.2016 41 Aufwand Projektmanager u. -kunde Aufwand Projektmanager  Projektleitung (Dirigent)  Abhängig v. Projekttyp  Fragestellung: Wieviele VZA kann Projektmanager leiten? Aufwand Projektkunde  Wird sehr oft vergessen, dass auch für Projektkunden Aufwand anfällt Anmerkungen –Sind Richtwerte –Eigene Erfahrungswerte aufbauen Nach [Kapur 2005]

42 © 2006 - Christian Gütl 18.09.2016 42 Aufwand Projektsponsor –Zeitaufwand soll/muss dem Projektsponsor bewusst werden –Projektmanager soll dies dem Sponsor kommunizieren Hinweis –Probleme im Projekt entstehen, wenn sich der Projektsponsor nicht die nötige Zeit nimmt Nach [Kapur 2005]

43 © 2006 - Christian Gütl 18.09.2016 43 Abschnitt 4 Abschätzung der Projektkosten

44 © 2006 - Christian Gütl 18.09.2016 44 Abschätzen der Projektkosten 1 Abschätzen der Projektkosten (1) „Personalkosten“ –Detaillierung und Zuverlässigkeit abhängig von Schätzverfahren bzw. Aufwandsschätzmethode –Grundsätzliche Möglichkeiten Kosten für bestimmte Stellenprofile gemäß geplanten Stellenprofil Mischkostensatz (Erfahrungswert aus der Vergangenheit) –Erst wenn Personen und die Zuordnung zu Tasks feststeht können Projektkosten genau geplant werden  tatsächliche Kosten ansetzen  u.U. Datenschutzprobleme vs. Lohnkosten

45 © 2006 - Christian Gütl 18.09.2016 45 Abschätzen der Projektkosten 2 Abschätzen der Projektkosten (2) „Sonstige Aufwendungen“ –Reisekosten –Consultants –Sonstige Lieferungen u. Leistungen –Benötigte Hard- u. Software –Sonstiges Equipment –Training –Bürokosten (*) –Verbrauchsgüter (*) –Telekommunikationskosten (*) –Administration (*) –„Zuckerln“ für die Mitarbeiter (*) –Abschlussfeier –…

46 © 2006 - Christian Gütl 18.09.2016 46 Fixpreisangebote 1 Anmerkungen zu Fixpreisangebote –Jener festgelegte Preis für ein bestimmtes Projekt  tatsächliche Kosten + Gewinn –Kostenabschätzung muss sehr genau sein !!! –… man benötig dafür Genaue Produkt bzw. Projektanforderungen Umfassenden „Work Breakdown Structure (WBS)“ mit Phasen, Deliverables und Tasks Realistische Annahmen über einzusetzenden Ressourcen Auf Aufwand für Sponsor, Projektmanager und sonstige Aufwendungen nicht vergessen Genauen und pragmatischen Netzplan Genügend Managementreserve Auf Gewinn nicht vergessen !!!

47 © 2006 - Christian Gütl 18.09.2016 47 Fixpreisangebote 2 Projektphasen 1.Projekt Charter 2.Requirements 3.Design 4.Development 5.Implementation Nach [Kapur 2005]

48 © 2006 - Christian Gütl 18.09.2016 48 Abschnitt 5 Softwarespezifische Aufwandsschätzung

49 © 2006 - Christian Gütl 18.09.2016 49 Allgemeines Verfahren der Aufwandsschätzung –Algorithmisches Aufwandsmodell Modell erstellt aus historischer Daten unter Nutzung einer Softwaremetrik (z.B. LOC)  Aufwand –Expertenbeurteilung Mehrer Experten schätzen der Projektaufwand, dann Konsensmeeting –Analogischätzung Ähnliche Projekte (auf dem selben Anwendungsgebiet) als Basis für die Aufwandsbestimmung –Parkinson Gesetz Arbeit dehnt sich immer so aus, dass alle erübrigte Zeit verbraucht wird –„Price to Win“ Softwareentwicklungskosten werden mit Kundenbudget abgeglichen

50 © 2006 - Christian Gütl 18.09.2016 50 Produktivität 1 Produktivität (nach [WIKIPEDIA] u. [Sommerville 2001]) –Z.B. bei Fertigungssystem: Produzierte Stückzahl / Arbeitsstunden  durch bekannten Output kann man Input abschätzen Besonderheiten d. Softwareentwicklung –Unterschiedliche Lösungsansätze für z.B. Performantes System Leichte Weiterentwicklung u. Erweiterung  Ansätze schwierig untereinander zu Vergleichen  Dennoch von Management gewünscht  Brauchbar für Aufwandsabschätzung

51 © 2006 - Christian Gütl 18.09.2016 51 Produktivität 2 Outputmaße für Software –Größenspezifische Maße = „Größe“ der Software Programmzeilen (line of code  LOC) Objektcode Abweisungen Umfang (Seiten) der Dokumentation –Funktionsspezifische Maße = Gesamtfunktionsumfang der Software Function Points Object Points

52 © 2006 - Christian Gütl 18.09.2016 52 Produktivität 3 Anzahl der Programmzeilen –Wird bezogen auf den Gesamtaufwand (Anforderung, Design, Programmierung, Testen und Dokumentation) –Verschiedene Zählweisen Alle Zeilen außer Leerzeilen Nur ausführbaren Code (ohne Kommentare) –Gleichartige Softwareentwicklungen lassen vergleichen –Problem: Produktivitätsvergleich von verschiedener Programmiersprachen unmöglich Anmerkung: Zusammenhang besteht über Funktion Points –Abhilfe: Andere Maße verwenden  Function Points  Object Points

53 © 2006 - Christian Gütl 18.09.2016 53 Produktivität 4 Function Points –Funktionalitätsumfang wird gemessen durch folgende Programmcharakteristiken: Externe Ein- und Ausgaben Benutzerinteraktionen Externe Schnittstellen Vom System genutzte Dateien –Gewichtung Unterschiedlichen Komplexitätsgrad der Charakteristiken berücksichtigen  Gewichtsfaktor 3 … 15 –3 (sehr einfach), z.B. einfache Eingabe –15 (sehr komplex), z.B. Verarbeitung e. komplexen Datenfiles Woher bekommt man Gewichtsfaktoren –Verfügbare Tabelle –Erfahrungswerte d. Unternehmung

54 © 2006 - Christian Gütl 18.09.2016 54 Produktivität 5 Function Points (ff) –Unadjusted function-point count (UFC) –Adjusted function-point count (AFC) Berücksichtigt zusätzlich Gesamtkomplexität des Softwareprojektes mit Faktor –Performanz –Schwierigkeitsgrad –Neuheitsfaktor –… Siehe auch COCOMO Modell –Hinweise: Ergebnisse werden stark geprägt –Vom „Schätzer“ –Vom Art des Projektes

55 © 2006 - Christian Gütl 18.09.2016 55 Produktivität 6 Object Points (Application Points in COCOMO) –Wird für Programmiersprachen wie für Datenbank-Programmierung oder Skriptsprachen genutzt –Objects Point ≠ Zählen von Objekten –Object Point setzt sich zusammen aus Anzahl von unterschiedlichen „Screens“ –Gewichtet n. Komplexität: 1 (einfach) … 3 (komplex) Anzahl von erzeugten Reports –Gewichtung nach Komplexität »2 (einfach zu erzeugen) »5 (moderat aufwendig) »8 (schwierig zu erzeugen) Anzahl von ergänzenden Modulen in C++, Java, … –Je Modul 10 Object Points V: kann in früher Projektphase bestimmt werden

56 © 2006 - Christian Gütl 18.09.2016 56 Produktivität 7 Final Code Size Estimation –Kann aus Function Point bzw. Object Points ermittelt werden –Wird mit „Average number of lines of code (AVC)“ multipliziert Produktivitätseinfluss d. Mitarbeiter –Erfahrungen im Anwendungsbereich –Gewählter Entwicklungsprozess –Projektgröße Verursacht zunehmend Overhead, z.B. Kommunikation und Koordinierungsaufwand –Unterstützende Tools (z.B. CASE Tools) –Arbeitsumgebung

57 © 2006 - Christian Gütl 18.09.2016 57 Aufwandsabschätzung Algorithmische Aufwandsabschätzung –Aufwandsmodell kann gebildet werden aus Aufwand der Softwareentwicklung Charakteristika des Projektes –Allgemeines algorithmisches Modell –A … Faktor zur Beschreibung von Art der Software und der Unternehmungsorganisation –Size … Softwareumfang in LOC bzw. Function oder Object Points; meist LOC –B … Exponentialfaktor; liegt zwischen 1 und 1,5  Modelliert zunehmenden Overhead mit Projektgröße –M … Multiplikator  Modelliert Prozess, Produkt- und Entwicklungscharakteristiken

58 © 2006 - Christian Gütl 18.09.2016 58 Unsicherheit der Abschätzung Nach [Sommerville 2005]

59 © 2006 - Christian Gütl 18.09.2016 59 DAS COCOMO Modell COCOMO Allgemein –„COnstructive COst Model“ –Entwickelt von B.W. Boehm –Empirisches Modell aus Analyse von einer Vielzahl von Softwareprojekten –COCOMO 81 (1981) für Wasserfallmodell Programmiersprachen C und FORTRAN –COCOMO II (2000) Unterstützt Spiralmodell Abschätzungen für –Prototypentwicklung (Object Points) –Grobe Abschätzung (Function Points) –Entwicklung bei Wiederverwertung –Detaillierte Abschätzung nach Systemdesign (LOC)

60 © 2006 - Christian Gütl 18.09.2016 60 COCOMO II Modell 1 Grobe Abschätzung –Anwendung bei bekannten Anforderungen und groben Architekturdesign –A … Faktor nach Angaben von Boehm A=2,94 –Size … Softwareumfang in kLOC (kilo LOC) Wird gebildet aus Function Points Standardtabelle zum Umrechnen auf kLOC –B … Exponentialfaktor liegt zwischen 1,1 und 1,24 Berücksichtig –Neuartigkeit des Projektes –Kooperationsfähigkeit des Entwicklerteams –Reife des genutzten Prozess … im Personen-Monate (PM)

61 © 2006 - Christian Gütl 18.09.2016 61 COCOMO II Modell 2 Grobe Abschätzung (ff) –M … Multiplikator wird durch 7 Projekt- und Prozess-Charakteristiken bestimmt Zuordnung von 1 (gering) … 6 (hoch) –PERS … Fähigkeiten des Projektteams –RCPX … Produktzuverlässigkeit und -komplexität –RUSE … Wiederverwertung gefordert –PDIF … Schwierigkeitsgrad d. verwendeten Plattform –PREX … Erfahrungen des Projektteams –FCIL … Support-Einrichtung –SCED … Zeitplan

62 © 2006 - Christian Gütl 18.09.2016 62 Softwareentwicklungsdauer Abschätzung d. Softwareentwicklungsdauer –Zusammenhang zwischen Gesamtaufwand, beteiligte Personen und Entwicklungsdauer ist nichtlinear –Mehr Programmierer  mehr Aufwand Koordination und Kommunikation Schnittstelledefinition –Softwareentwicklungsdauer (Time Development) –Erkenntnis: In dieser Schätzformel wirkt sich die Anzahl der Programmierer nicht auf die Entwicklungszeit aus In der Praxis genau prüfen wie viel Parallelisieren Sinn macht … in Monaten

63 © 2006 - Christian Gütl 18.09.2016 63 Quellen 1 [Kapur 2005] Kapur, G.K.: Project management for information, technology, business, and certification; Pearson Prentics Hall, Ohio, USA, 2005. [Kerzner 2003] Kerzner, H.: Projektmanagement. Ein systemorientierter Ansatz zur Planung und Steuerung; mitp Verlag, Bonn, Germany, 2003. [Sommerville 2001] Sommerville, Ian: Software Engineering; 6. Auflage, München, Germany, 2001. [Sommerville 2005] Sommerville, Ian: Software Engineering 7; 7. Auflage, Addison-Wesley, Boston, USA, 2005. [WIKIPEDIA] Produktivität http://de.wikipedia.org/wiki/Produktivit%C3%A4t

64 © 2006 - Christian Gütl 18.09.2016 64 Fragen und Anmerkungen! Danke! Thanx!