Aufwandsschätzung und Projektkalkulation von Großprojekten. Thomas Engeroff

Transkript

1 Aufwandsschätzung und Projektkalkulation von Großprojekten

2 Studium der Informatik an der TU Darmstadt Abschluss mit Schwerpunkt Software Engineering und Nebenfach BWL : freiberufliche Software Entwicklung & IT Beratung : bei sd&m als Software-Ingenieur Projektleiter Abteilung Research: Aufwandsschätzung, insb. Use Case Points (12 Monate) danach Schwerpunkt Telekomunikation seit 2011 bei der der msg systems ag Privates Project Manager / Berater / Scrum Master Bereich Telecommunications & Media Aktuell als Consultant bei der Telekom zur Unterstützung der Projektleitung eines Großprojektes im Bereich Planungs-/Release-management tätig Keine Kinder, aber ;) Hobbys: Kernsanierung & Motorrad letzter Urlaub

3 AGENDA 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur 3

4 AGENDA 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur 4

5 Aufwandsschätzungen beruhen immer auf praktischer Erfahrung und Intuition Prognosen sind besonders dann schwierig, wenn sie sich auf die Zukunft beziehen. Aufgaben durchführen Aufwände messen Erfahrung kalibrieren Aufwände (neu) schätzen 5

6 Die Grenzen der Intuition sind in Großprojekten erreicht Expertenschätzungen beruhen auf Erfahrungen von Experten: Jedes Element der Stückliste wird individuell vom Experten taxiert Experte: Mindestens 3 x eine vergleichbare Aufgabe/Projekt selber durchgeführt Annahme: ein typisches (kleines) Projekt dauert 9 Monate: Projekt A Projekt B Projekt A Projekt C Projekt A Monate Experte nach 3,75 Jahren Annahme: ein Großprojekt bzw. Programm dauert 3 Jahre: Projekt A Projekt B Projekt A Projekt C Projekt A Jahre Experte nach 15 Jahren 6

7 Schätzdatenbanken mit FSM (Funktional Size Measurement) überwinden die Grenzen der Intuition bei Großprojekten Projekt 1 Projekt 2 Projekt 3 Projekt n + 1 Schätz-DB Projekt 100 t Normierung nötig bzgl.: Größe (FSM) Komplexität Umfeld 7

8 Der Kontenrahmen strukturiert Aufgaben nach Aufgabenkategorien (Beispiel: sd&m AG) Projekt PI Projektinhalt SP Spezifikation SP-IST IST-Systemanalyse SP-ALLG Allg. Spezifizikationsaufwände SP-THEMA Spezifikation von Themen und Daten SP-NACH Nacharbeiten (FK V1.1) SP-QS QS auf Spezifikation PQ Projektquerschnitt PK Projektkoordination PK-PL Projektleitung PK-CD Chefdesign UM Umsetzung KON Konstruktion KON-T Konstruktion der T-Stufen KON-A Konstruktion der A-Stufen KON-DB Konstruktion DB-Design & Datentypen KON-MIG Konzeption v. Migration etc. KON-ALLG Allg. Konstruktionsaufwand KON-QS QS in der Konstruktion PK-PM Projektmanagement In Releases REA Realisierung PK-QK Qualitätsmanagement PK-MTG Meetings REA-T Realisierung T-Stufen REA-A Realisierung A-Stufen REA-DB Aufbau und Pflege DB REA-MIG Migration & Erstbefüllungen REA-QS QS in der REA INT Integration INT-TVO alle Testvorbereitungen INT-SYS (Sub-) Systemtest INT-VBD Verbundtest INT-BUGFIX Fehlerbehebung INT-NFKT Nicht-Funktionale Tests INT-QS Durchführung QS PT Projekttechnik PT-TI Technische Infrastruktur PT-KM Konfigurations-/ Releasemanagement 100% = Netto IB Inbetriebn. IB-ABN Abnahme IB-EIN Einführung & Betrieb IB-DOK Dokumentationen IB-SCHUL Schulungen IB-QS Durchführung QS PT-SEU Software- Entwicklungsumgebung Ebene 0, Für Kennzahlen und Auswertungen Ebene 1 Ebene 2 Jedes Projekt schätzt und erfasst seine Aufwände auf einer dieser Ebenen. Ab einer Projektgröße von 15 BM ist die Ebene 2 verbindlich. Darunter kann beliebig detailliert werden. Die Ebene 1 & 2 definiert die Aufgabenkategorie PN Projektneben- PN PN-EIN Einarbeitung, Teamaufbau aufwände CR Change Requests PN-REISE Reisezeiten BERAT Beratung PN-STORT Mehrere Standorte 8

9 Projekt In Releases PI Projektinhalt UM Umsetzung 100% = Netto SP Spezifikation SP - IST IST - Systemanalyse KON Konstruktion KON - T Konstruktion der T - Stufen REA Realisierung REA - T Realisierung T - Stufen INT Integration INT - TVO alle Testvorbereitungen IB Inbetriebn. IB - ABN Abnahme SP - ALLG Allg. Spezifizikations - aufw ä nde SP - THEMA Spezifikation von Themen und Daten SP - NACH Nacharbeiten (FK V1.1) SP - QS QS auf Spezifikation KON - A Konstruktion der A - Stufen KON - DB Konstruktion DB - Design & Datentypen KON - MIG Konzeption v. Migration etc. KON - ALLG Allg. Konstruktionsaufwand KON - QS QS in der Konstruktion REA - A Realisierung A - Stufen REA - DB Aufbau und Pflege DB REA - MIG Migration & Erstbef ü llungen REA - QS QS in der REA INT - SYS (Sub - ) Systemtest INT - VBD Verbundtest INT - BUGFIX Fehlerbehebung INT - NFKT Nicht - Funktionale Tests INT - QS Durchf ü hrung QS IB - EIN Einf ü hrung & Betrieb IB - DOK Dokumentationen IB - SCHUL Schulungen IB - QS Durchf ü hrung QS PQ Projektquerschnitt PK Projektkoordination PK - PL Projektleitung PK - CD Chefdesign PK - PM Projektmanagement PK - QK Qualit ä tsmanagement PK - MTG Meetings PT Projekttechnik PT - TI Technische Infrastruktur PT - KM Konfigurations - / Releasemanagement PT - SEU Software - Entwicklungsumgebung PN Projektneben - PN PN - EIN Einarbeitung, Teamaufbau aufw ä nde CR PN - REISE Reisezeiten BERAT PN - STORT Mehrere Standorte 9

10 Exkurs: Wo erfassen wir folgende Aufwände / Tätigkeiten? Im aktuellen Projekt bzw. grundsätzlich? Phase IT-Konzept: Teammeeting (Statusrunde) 2 Std. Phase Fachkonzept: Teammeeting: Abstimmung Dialoglayout 30 min. Rea-Phase: Mitarbeiter findet Fehler in Modul x nicht. PL und MA suchen gemeinsam den Fehler. 4 Std. Wohin bucht der MA? Wohin der PL? 10

11 Was ist das Aufwandsmodell? Grundüberlegungen und Ziele Das Aufwandsmodell definiert für Entwicklungsprojekte die verbindliche Struktur für Aufwandsschätzung, Aufwandserfassung und Nachkalkulation. Diese Struktur wird durch abstrakte Aufgabenkategorien definiert. Jede Aufgabe bzw. Tätigkeit in einem Entwicklungsprojekt lässt sich einer dieser Aufgabenkategorien zuordnen. Auf diese Weise definiert das Aufwandsmodell eine gemeinsame Sprache in der Welt eines Entwicklungsprojekts Die Aufgabenkategorien definieren zugleich Aufwandskategorien und den Kontenrahmen, in dem wir den Aufwand eines Entwicklungsprojekts erfassen. Auf diese Weise schaffen wir die Voraussetzung dafür, - unsere Projekte vergleichbar zu machen - Wir erleichtern QS und Vollständigkeitsprüfung Vergleichbarkeit ist wiederum die Voraussetzung, um aus unseren Projekten systematisch zu lernen und Kennzahlen sowie Erfahrungswerte zu gewinnen. 11

12 Was sind die Instrumente des Aufwandsmodells? Die Instrumente des Aufwandsmodells sind: Die einheitlichen Aufwandskategorien mit dem zugehörigen Kontenrahmen Das Aufwandsblatt zur Dokumentation der Aufwandsschätzung Die Nachkalkulation nach Aufwandsmodell zur Erfassung des Ist-Aufwands am Ende des Projekts Die Kennzahlen mit den Erfahrungswerten zur Plausibilisierung von Schätzungen 12

13 Weitere gängige Begriffe Festpreisrisiko- Zuschlag Gewährleistungs- Aufschlag ggf. Zuschlag für Festpreisgarantie als unternehmerische Risiko (falsche Annahmen, Pönalen, Vertragsforderungen die in Schätzung vergessen wurden, ) ggf. Rückstellung für Gewährleistungsforderungen nach der Abnahme Nettoaufwand Aufwand zur unmittelbaren Erstellung der Projektergebnisse, also des Projektinhalts (PI) ohne Projektquerschnitt (PQ) oder Projektnebenaufwände (PN) Bruttoaufwand (= Gesamtaufwand) Gesamter regulärer Aufwand zur Abwicklung eines Projekts ohne Festpreisrisiko ohne Gewährleistungsaufschlag Entspricht also der Summe der Aufwände für: Projektinhalt (PI), z.b. Spezifikation Projektquerschnitt (PQ), z.b. Projektleitung Projektnebenaufwand (PN), z.b. Einarbeitung 14

14 Wir unterscheiden Bottom-Up undtop-down Schätzverfahren Bottom-Up Top-Down 1 Spezifikation?? 2 FSM # Fenster # Ziegel Umsetzung f (x) 15

15 Bottom up ist die bevorzugte Schätzstrategie Schätzstrategien Top-Down Gesamthafte Schätzung des Projektaufwandes mit Hilfe von mathematischen Algorithmen auf Basis der funktionalen Anforderungen. Verwendet msg in der Regel nur zur Plausibilisierung. Bottom-Up Aufwände jedes Aufwandspostens werden getrennt ermittelt und zum Gesamtprojektaufwand summiert. Im typischen msg Projekt gehen wir Bottom-Up vor. 16

16 Schätzverfahren im Überblick Algorithmische Methoden Vergleichsmethoden Kennzahlenmethoden Experten- Schätzungen COCOMO Function Points Use Case Points Analogiemethode Multiplikatormethoden Prozentsatzmeth. Einzelschätzung Delphi-Methode Schätzklausur Aufwandsermittlung per Formel, in der Regel empirisch nachgewiesen Basis sind messbare Produktgrößen, z. B. LoC, Anforderungen oder Spezifikation Teilw. aufwändig, aber gute Resultate Stellt Bezug zu durchgeführten Entwicklungsprojekten her Keine messbaren Produktgrößen wie LoC nötig Nachkalkulationen alter Projekte nötig Ähnlich Analogiemethode, allerdings braucht man Messdaten abgeschlossener Projekte Greifen wenn möglich auf Analogiemethode zurück Erstmalige Schätzung neuer Anforderungen durch Expertenwissen Top-Down Bottom-Up 17

17 AGENDA 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur 18

18 Experten-Schätzungen stellen ein weit verbreitetes Verfahren für alle Arten von Entwicklungsprojekten dar Prognosen sind besonders dann schwierig, wenn sie sich auf die Zukunft beziehen. Systematische Bottom-Up Schätzung von Experten, basierend auf ihrem Erfahrungsschatz Schätzposten werden als Aufwandsposten projekt-spezifisch abgeleitet Für inhomogene oder stark kundenspezifische Projekte häufig der einzig gangbare Weg Verschiedene Varianten der Experten- Schätzung unterscheiden Systematik und Umfang der Einbindung von Experten: Einzelschätzung: Ein einziger Experte legt die Schätzwerte für einen bestimmten Aufwandsposten fest Delphi-Methode: Mehrere Experten führen ihre Schätzung anonym und getrennt voneinander durch Schätzklausur: Mehrere Experten schätzen im Rahmen eines gemeinsamen Schätzworkshops 19

19 Experten-Schätzung Vertiefende Informationen: Gegenüberstellung der Varianten Einzelschätzung Delphi-Methode Schätzklausur Ein einziger Experte legt die Schätzwerte für einen bestimmten Aufwandsposten fest. Genauigkeit hängt wesentlich von der Erfahrung dieses Experten ab. Hohe Verantwortung für eine Person Einseitige Beurteilung von Aufwänden und Unsicherheiten Mehrere Experten führen ihre Schätzung anonym und ohne Abstimmung untereinander durch. Zusammenführung der Schätzung durch den PL ggf. in Iterationen bei (großen) Abweichungen. Korrektur-Möglichkeiten der Schätzzahl ohne Gesichtsverlust Keine Gruppenzwänge Mehrere Experten schätzen online im Rahmen eines gemeinsamen Workshops. Sofortige Zusammenführung von Aufwänden und Plausibilisierung Inhaltliche Diskussionen bei großen Abweichungen Gruppe einigt sich auf Aufwand pro Schätzposten Risiken werden bewusst Gleichmäßiger Informationsstand im Team Pragmatisch aber leicht ungenau Verlässlich aber sehr zeitaufwändig Besser als Mittelwerte aber ebenfalls zeitaufwändig 20

20 Die Aufwandsschätzung besteht aus mehreren Schritten Tätigkeit Zerlegung in Aufgaben (Stückliste) Aufgaben einzeln schätzen mehrere unabhängige Schätzungen + Querschnittsaufwände als %-Erfahrungswerte Ergebnis Nettoaufwand Bruttoaufwand Bewertung mit kalkulierten Stundensätzen, + FP-Risiko + Gewährleistung Gesamtbudget Plausibilisieren durch Projektplan und Mitarbeitergebirge Verhältnis der Projektphasen Vergleichsprojekte Plausibilisiertes Budget Soll - / Ist-Vergleich Budgethochrechnung 21

21 Alles, was Aufwand macht, Aufwandsposten (Schätzposten) Alle aufwandstragenden Tätigkeiten im Projekt Die Liste aller Aufwandsposten gibt die Stückliste Nicht jeder Aufwandsposten muss 1:1 ein Arbeitsergebnis sein Aufwandsposten müssen nicht mit den späteren Planungseinheiten übereinstimmen Arbeitsergebnis Deliverable Ergebnis z. B. Fachkonzept, Dialog, Systemdokumentation sonstige Tätigkeiten z. B. Review durchführen, Projektleitung, Meeting, Kickoff-Veranstaltung 22

22 Wir schätzen Aufwände in Bearbeitertagen (BT) zu 8 h Ein Aufwand von 1 Bearbeitertag (BT) muss in 8 Stunden (!) erbracht werden können nicht in einem 10-Stunden- Tag (oder 24h-Tag ). Wir schätzen Rüstzeiten nicht extra, d.h. in jeder Aufwandszahl sind also auch Zeiten für Kaffeetrinken, kleinere Pausen, Mails lesen, Schreibtisch aufräumen etc. enthalten Planungs- und Schätzungssicht 1 BT 8 Bh 1 BW 40 Bh 1 BW = 5 BT 1 BM 160 Bh 1 BM = 20 BT 1 BJ 1600 Bh 1 BJ = 10 BM 23

23 Für jeden Schätzposten wird Aufwand und Schätzunsicherheit ermittelt Gesamtaufwand := Schätzung + Aufwandsrisiko Vorgehen zur Ermittlung des Aufwands und des Schätzrisikos unter Zuhilfenahme eines Schätzverfahrens. Schätzung [Bh, BT] Grundlage sind in jedem Fall feststehende Anforderungen oder mindestens als Prämissen dokumentierte Annahmen über Projektinhalt und Rahmenbedingungen. Das Ergebnis der Schätzung ist der vollständige Aufwand des Projekts in Bh oder BT (im Gegensatz zur Kalkulation: ). Aufwandsrisiko [Bh, BT] X% der Schätzunsicherheit. Die Schätzunsicherheiten wird nicht bei jedem Aufwandsposten zugeschlagen, die Festlegung hängt von der Einschätzung des Angebotsverantwortlichen ab. 24

24 Beispiel: Strukturierung einer Stückliste Konto Thema/ Komponente Schätzposten (Arbeitspaket/Aktivität) SP SP-THEMA Register Visa Spezifikation der Komponente Visa-Auskunft (Grundlage sind die bestehenden 4 AWF der Masterspez.) Schätzung 12,0 Strukturierung nach den Aufgabenkategorien des Aufwandsmodells SP-THEMA Register Visa Spezifikation der Komponente Visa-Meldung (Wahrscheinlich 5 AWF in der neuen Spez.) SP-THEMA Register Visa Spezifikation der Protokollierung durch das Register 8,0 (Wahrscheinlich ein AWF zum Protokollieren und einen zum Abfragen, Exportschnittstelle) SP-THEMA Register Visa Spezifikation der Komponenten Administration und 5,0 Datenpflege SP-THEMA Register Visa Spezifikation der Komponente Fristenkontrolle 10,0 SP-THEMA Register Visa Spezifikation der Komponente Bereitstellung Analyse 9,0 (Schnittstellenbeschreibung oder Druckausgabe für Rohdatenexport, AWF zum Exportieren, ggf. AWF/Enitäten zum Zählen von Kennzahlen) SP-THEMA Register Visa Spezifikation Datenmodells für das Register Visa 10,0 SP-THEMA Register Visa Dokumentenquerschnitt mit Einleitung, Referenzen, NFAs 4,0 usw. SP-THEMA Visa-Regelwerk Überarbeitung bestehende Regeln (24) 12,0 SP-THEMA Visa-Regelwerk Identifikation und Ergänzung fehlende Regeln 5,0 SP-THEMA Visa-Regelwerk Berechtigungen prüfen und ergänzen 5,0 SP-THEMA Visa-Regelwerk Schnittstelle Regelkomponente definieren 3,0 30,0 Abstrakte, projektspezifische Strukturierung des Projektinhalts nach Komponenten & Themen Projektspezifische Detaillierung in einzelne Aufwandsposten (Schätzposten) Aufwandsschätzung in Bearbeitertagen (BT) 25

25 In der Stückliste werden alle Schätzposten in BT erfasst und bereits einer Aufgabenkategorie gemäß Kontenrahmen zugeordnet Aufgabenkategorie Thema/Komponente Aufwandsposten Schätzung Aufwandsrisiko Gesamtaufwand SP-ALLG Initialisierung: fachliche Workshops, Themenabgrenzung, Spez-Pattern, etc SP-ALLG Einleitung, Glossar, Überblick, Redaktion etc SP-THEMA Stammdatendialoge Spez Dialog: Pflege Skilehrer 1 0,5 1,5 SP-THEMA Stammdatendialoge Spez Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 1 0,5 1,5 SP-THEMA Stammdatendialoge Spez Dialog: Pflege Stammdaten Skischule 1 0,5 1,5 SP-THEMA Kursplanung & -abwicklung Spez Dialog: Verfügbarkeit Skilehrer 2 0,5 2,5 SP-THEMA Kursplanung & -abwicklung Spez Dialog: Skikurse anlegen/pflegen 2 0,5 2,5 SP-THEMA Kursplanung & -abwicklung Spez Dialog: Kursbuchung SP-THEMA Kursplanung & -abwicklung Spez Dialog: Fakturierung SP-THEMA Druckausgaben Rechnung 1 0,5 1,5 SP-THEMA Druckausgaben Übersicht über alle Kurse 1 0,5 1,5 SP-THEMA Druckausgaben Übersicht zu einem Kurs 1 0,5 1,5 SP-NACH Erstellen Version SP-QS Qualitätssicherung Spez KON-ALLG Vorbereitung IT-Konzept: Nutzungskonzept/EHB für Access, Pattern IT-Konzept, KON-A Stammdatendialoge Kon Dialog: Pflege Skilehrer 0,5 0,5 1 KON-A Stammdatendialoge Kon Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 0,5 0,5 1 KON-A Stammdatendialoge Kon Dialog: Pflege Stammdaten Skischule 0,5 0,5 1 KON-A Kursplanung & -abwicklung Kon Dialog: Verfügbarkeit Skilehrer 0,5 0,5 1 KON-A Kursplanung & -abwicklung Kon Dialog: Skikurse anlegen/pflegen 1 0,5 1,5 KON-A Kursplanung & -abwicklung Kon Dialog: Kursbuchung 1 0,5 1,5 KON-A Kursplanung & -abwicklung Kon Dialog: Fakturierung 1 0,5 1,5 KON-A Druckausgaben Rechnung 0,5 0,5 1 KON-A Druckausgaben Übersicht über alle Kurse 0,5 0,5 1 KON-A Druckausgaben Übersicht zu einem Kurs 0,5 0,5 1 KON-QS Qualitätssicherung IT-Konzept REA-A Stammdatendialoge Pflege Skilehrer REA-A Stammdatendialoge Pflege Kurstypen (Art, Übungen, Preise etc.) REA-A Stammdatendialoge Pflege Stammdaten Skischule REA-A Kursplanung & -abwicklung Verfügbarkeit Skilehrer (Planung) 2 0,5 2,5 REA-A Kursplanung & -abwicklung Skikurse anlegen/pflegen (Planung) 3 0,5 3,5 REA-A Kursplanung & -abwicklung Kursbuchung REA-A Kursplanung & -abwicklung Fakturierung REA-A Druckausgaben Rechnung in Word REA-A Druckausgaben Übersicht über alle Kurse (Access Bericht) 1,5 0,5 2 REA-A Druckausgaben Übersicht zu einem Kurs (Access Bericht) 1,5 0,5 2 REA-DB Aufbau DB REA-QS Codereviews 2 2 INT-TVO Testfälle & Testkonzept erstellen

26 Zuschläge für Querschnittsaufgaben werden konkret geschätzt oder prozentual ermittelt Querschnittsaufgabe Alle Querschnittsaufgaben Projektleitung Chef Design Qualitätssicherung Software-Entwicklungs- Umgebung, Technik Abschätzung möglichst konkret schätzen Mitarbeiter x Laufzeit ab 7 Mitarbeiter ein Vollzeit-PL Mitarbeiter x Laufzeit möglichst Einzelmaßnahmen schätzen sehr projektspezifisch: Aufbau und lfd. Support getrennt betrachten Erfahrungswerte in % vom Nettoaufwand % % 5-25 % Anzahl Reisen x durchschn. Reisezeit Reisezeiten bis zu 15 % über die Laufzeit Anzahl Meetings x Teilnehmer x Dauer Meetings, Präsentationen etc. bis zu 15 % über die Laufzeit Team-Training möglichst Einzelmaßnahmen schätzen 27

27 Im Kalkulationsschema sind die verschiedenen Anteile des Gesamtaufwands sichtbar Aufgabe Aufwand [BT] Funktion Funktion Funktion Nettoaufwand 600 Projektleitung 15% 90 Qualitätssicherung 15% 90 Team-Training 5% 30 Systembetreuung 15% 90 Reisezeit 7% 42 Einführungsunterstützung 8% 48 Querschnittsaufgaben 65% 390 Bruttoaufwand 990 Festpreis-Risikoaufschlag 10% 99 Gewährleistung 10% 99 Gesamtaufwand

28 Zur Ermittlung des Nettoaufwands werden die Schätzposten gezählt und bewertet Typ Zählbaustein Kategorie Anzahl Einzel Aufwand Gesamt Aufwand Klassen leicht mittel schwer Einzelfall 1 Einzelfall BT 5 BT 10 BT 25 BT 20 BT 44 BT 75 BT 80 BT 25 BT 20 BT Dialoge leicht mittel schwer extrem x = 3 BT 5 BT 8 BT 18 BT 39 BT 125 BT 48 BT 36 BT Batches Schnittstellen Tabellen 29

29 Verwendete Grundbegriffe der Statistik Jede Verteilung von unabhängigen Zufallsvariablen entwickelt sich bei genügend großer Stichprobenanzahl in Richtung einer Normalverteilung (Gauß-Glocke). Sie ist typisch für Messungen, die sich aus sehr vielen verschiedenen Einflüssen zusammensetzen, die man nicht mehr trennen kann. Wir gehen bei der Analyse der Kennzahlen des Aufwandsmodells vereinfacht von einer Normalverteilung der Erfahrungswerte aus. Der Erwartungs- oder Mittelwert μ einer Normalverteilung ist der Wert mit der höchsten relativen Wahrscheinlichkeit f. Je weiter man sich vom Mittelwert μ entfernt, desto unwahrscheinlicher wird dieser Wert in der Praxis zu beobachten sein. Die Standardabweichung σ ist ein Maß für die Streuung um den Mittelwert, sie beschreibt die Breite der Normalverteilung. 68 % aller Messwerte haben eine Abweichung von höchstens σ vom Mittelwert, liegen also im 1σ-Bereich um den Mittelwert. Median bezeichnet eine Grenze zwischen zwei Hälften. In der Statistik halbiert der Median eine Stichprobe. Gegenüber dem Mittelwert hat der Median den Vorteil, robuster gegenüber Ausreißern zu sein, das gilt insbesondere bei einer geringen Stichprobenanzahl. In einer echten Normalverteilung sind beide Werte identisch. Die Konfidenz κ ist in ein Maß für die Güte/Präzision des Mittelwerts. Die Konfidenz wird anhand einer vorgegebenen Wahrscheinlichkeit (1-α) berechnet. Das Konfidenzintervall um den Mittelwert μ± κ gibt dann den Bereich an, in dem sich der Mittelwert mit dieser Wahrscheinlichkeit befindet. Ein breites Konfidenzintervall weißt auf eine zu geringe Stichprobenanzahl hin. In der Auswertung des Aufwandsmodells verlangen wir eine Konfidenz von mindestens 5% für das 90%-Konfidenzintervall (Vertrauensintervall mit α = 0,1). Damit legen wir ein Mindestmaß für die Schärfe und Belastbarkeit des Mittelwerts und damit auch des Medians fest. 31

30 Die Kennzahlen des Aufwandsmodells dienen der Plausibilisierung einer Schätzung Kennzahlenplausibilisierung <Bitte AKQA-Bezeichnung in 0-Übersicht eintragen> <bitte Statusdatum in 0-Übersicht pflegen> Projektklasse: alle (Durchschnitt über alle sd&m-projekte) Erfahrungswerte aus Kennzahlen Schätzung Aufw.-Modell (~1σ-Bereich) von bis Median SP / PI 23% 8% 28% 18% KON / UM 29% 9% 25% 17% REA / UM 46% 35% 65% 53% INT / UM 25% 18% 40% 32% INT-BUGFIX / UM 10% 5% 19% 13% PK / PI 31% 15% 40% 28% PL / PI 13% 6% 18% 12% PM / PI 5% 2% 7% 4% CD / PI 10% 4% 11% 7% PT / PI 11% 3% 10% 6% EIN / PI 3% 2% 7% 4% QS / PI 3% 2% 7% 5% Kommentar Unter einer Kennzahl verstehen wir jeden Quotienten aus zwei Aufgabenkategorien des Aufwandsmodells. Damit steht hinter jeder Kennzahl eine klare inhaltliche Bedeutung, was die Voraussetzung für einen unternehmensweiten Gebrauch von Kennzahlen darstellt. Im Angebotsprofil wird in der Kennzahlenplausi die Schätzung automatisch neben die Erfahrungswerte aus dem Aufwandsmodell der passenden Projektklasse gehalten. Die Kennzahlenplausi unterstützt so die kritische Reflexion der Schätzung. 32

31 Als erster Anhaltspunkt für Teamgröße und Projektlaufzeit dient Brooks Faustformel Zeit t Entwicklungsdauer Minimale Dauer Kommunikativer Anteil Weniger Arbeitsteilung möglich Mehr Abstimmung notwendig Produktiver Anteil (1) Optimale Mitarbeiteranzahl n = Anzahl der Mitarbeiter Optimale Teamgröße ~ Aufwand in BM Der Mann-Monat als Maßstab für den Umfang des Arbeitsaufwandes ist ein gefährlicher und irreführender Mythos. Der Begriff will uns glauben machen, Bearbeiter und Monate seien austauschbare Faktoren Fred Brooks in Vom Mythos des Mann-Monats 34

32 Die Aufwandsschätzung wird durch ein Mitarbeitergebirge plausibilisiert Den Projektablauf mit geschätzter Dauer und Teamgröße skizzieren Fläche ausrechnen hier: 30 Zeitmonate (ZtM) 1 ZtM = 0,8 BM wegen Feiertagen, Fortbildung, Krankheit, Meetings, etc. Hier ergibt die Umrechnung von ZtM auf BM: 30 * 0,8 = 24 BM Passt das zur Aufwandsschätzung? Anzahl Mitarbeiter Jun Jul Aug Sep Okt Nov Dez 35

33 Aus dem Mitarbeitergebirge und dem Gesamtaufwand kann die Projektdauer ermittelt werden In diesem Beispiel wurde der Gesamtaufwand von 104 BM auf 14 Monate verteilt: Maximum 11 Mitarbeiter, im Schnitt 8,9 Mitarbeiter bzw. 7,4 BM, Teamaufbau und maximale Teamgröße sind vernünftig. Anzahl MA M J J A S O N D J F M A M J Anzahl MA Aufwand [BM] (10/12) kumulierter Aufwand 4,2 6,5 7,3 8,6 9,4 9,4 9,4 9,4 9,4 8,5 8,5 8,1 3,9 1,7 4,

34 In die Budgetierung des Projekts fließen neben dem Aufwand weitere Parameter ein Parameter alle Parameter Stundensatz Methode kalkulatorische Vorgaben Festlegung durch Management; nach Qualifikation oder Mischstundensatz Erfahrungswert Konkret oder % von Bruttoaufwand Bruttoaufwand * Stundensatz Reisekosten Festpreis Risikozuschlag durchschn. Stunden / Tag festlegen Überstunden kalkulieren Anzahl Reisen * durchschn. Kosten 8-9 h / Tag bis zu 14 % % Gewährleistung 3-10 % sonstige Kosten Anschaffungskosten für Hardware, Software per Einkaufsliste Nur Durchreichen oder mit Zuschlag 37

35 Zusammenfassung der Grundsätze Konkret Möglichst viele Aufwandsposten werden konkret geschätzt; möglichst wenige durch prozentuale Aufschläge bestimmt. Schätzunsicherheit Zu jedem geschätzten Aufwandsposten wird die Schätzunsicherheit festgehalten. Für jeden Schätzposten wird dann aber nur eine Aufwandszahl festgehalten, welche die Grundlage für die spätere Projektplanung und die Kalkulation bildet. Aufwandsblatt Das Ergebnis der Schätzung wird im so genannten Aufwandsblatt dokumentiert. Vollständigkeit Über das Aufwandsblatt wird die Vollständigkeit und Plausibilisierung der Zahlen zueinander sichergestellt. Prämissen Häufig stößt man an Grenzen (weil etwas nicht sauber spezifiziert ist, weil etwas unklar ist, weil etwas vergessen wurde). In diesem Fall formuliert man Prämissen für die Schätzung, die Grundlage des Angebots werden. 38

36 AGENDA 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur 39

37 Die Top-Down Schätzung basiert auf der Messung von funktionaler Größe (FSM) der fachlichen Anforderungen Top-Down Schätzung Gesamthafte Schätzung des Projektaufwandes mit Hilfe von mathematischen Algorithmen auf Basis der funktionalen Anforderungen Annahme: Vergleichbarkeit des Projektaufwands bei gleichem funktionalem Umfang Funktionale Größe der Anforderungen werden in Punkten (Points) ausgedrückt 1 2 Spezifikation Umsetzung BzA funktionale Anforderungen nicht funktionale Anforderungen 40

38 Entwicklung der funktionalen Größenmessung De Marco's Bang Metric Data Points Object Points ISO "FSM" Standard DeMarco1982 Sneed1989 Sneed 1994 ISO 1994 Feature Points 3D Function Points Metrics for Objectory Use Case Points UCP 1.0 UCP 2.0 Rational 1999 Capgemini sd&m Jones 1986 Boeing 1991 Karner 1993 Full Function Points 1.0 COSMIC FPP 2.0 COSMIC FPP 2.1 ISO 19761: 2003 COSMIC Version 3.0 COSMIC 2007 Function Point Analysis Function Point Analysis Function Point Analysis 3.4 Function Point Analysis 4.0 Function Point Analysis 4.1 Function Point Analysis ISO 20926: 2003 Function Point Analysis 4.2 IBM 1975 Albrecht 1979 Albrecht 1984 IFPUG 1990 IFPUG 1994 IFPUG 1999 IFPUG 2001 IFPUG 2004 ISO 29881: 2008 Mark II FPA 1.0 Mark II FPA ISO 20968: 2002 FiSMA Symons 1988 UKSMA 1998 ISO 24570: 2005 NESMA Quelle: Lother, M.; Dumke, R.: Points Metrics - Comparison and Analysis. in: Dumke et al (Eds.): Current Trends in Software Measurement Proceedings of the 11th IWSM, Montréal, Shaker Verlag. Aachen. pg: ; ergänzt durch S. Frohnhoff, sd&m AG 41

39 Übersicht der wichtigsten FSM-Methoden (= Functional Size Measurement) Entstehungsjahr Methode ISO/IEC Charakterisierung 1979 Albrecht FPA (=Function Point Analysis) 1988 IFPUG FPA (=International Function Point User Group) 20926:2003 Aktuell: IFPUG # externer Eingaben # externer Ausgaben # externer Anfragen # externer Dateien # internen Dateien User oriented: #In, #Out 1999 COSMIC FFP (=COmmon Software Measurement Consortium Full Function Point) 1993 =>1999 UCP (=Use Case Points) 19761: 2003 Aktuell: COSMIC- FFP Transaction oriented: #Entry, #Exit, #Read, #Write, #Use Cases

40 Use Case Points (UCP) sind ein vergleichsweise junger Ansatz aus dem Rational-Umfeld mit Einsatz in der Praxis Gustav Karner Entwickelte UCP unter Betreuung von Ivar Jacobsen bei Objectory AB (später von Rational akquiriert) Metrics for Objectory. Diploma thesis, University of Linköping, Sweden. No. LiTHIDA-Ex-9344:21. December 1993 John Smith The Estimation of Effort Based on Use Cases. Rational Software. Cupertino, CA.TP-171. October 1999 Bestandteil des Rational Unified Process (RUP) Dokumentierte Praxiserfahrungen von Rational, Sun, IBM, Capgemini, msg,... Neueste Werkzeuge zur UML-Modellierung integrieren UCP-Tools Bsp.: Sparx Enterprise Architect (Mid-Price-Tool) Ein Excel-Sheet reicht aber völlig aus... 43

41 Die Use Case Points (UCP) Methode setzt direkt auf einer Use Case basierten Spezifikation auf und ist sehr einfach anzuwenden Use Case Komplexität Use-Case- Gewicht Aktor Typ Aktoren- Gewicht Auftrag verwalten hoch 15 Stammdaten Nachbarsystem (API) 10 Kunde verwalten einfach 5 Geschäftspartner Nachbarsystem (Protokoll) 5 Produkt verwalten mittel 10 Händler Benutzer-Interface Σ Use-Case-Gewichte + Σ Aktoren-Gewichte M-Faktor x T-Faktor x A-Faktor = Bereinigte Use Case Points Fragebogen mit Kostenfaktoren Fragebogen mit Kostenfaktoren Use Case Points Produktivitätsfaktor Aufwand über alle Phasen 1 ABC Individuelle Analyse Berechnung nach Standard-Metrik (einfach, mittel, komplex) Berechnung nach firmeneigener Metrik 1) gemäß Mapping auf Aufwandsmodell 45

42 Die erweiterte UCP-Methode (UCP 2.0) reduziert die Schätzvarianz auf unter 20% UCP-Methode (nach Karner) Verbesserte Methode UCP 2.0 Ist- Aufwand Aufwand geschätzt Abweichung Aufwand geschätzt Abwei- Projekt [h] UUCP [h] A-Faktor T-Faktor M-Faktor [h] chung Auto % 259 0,97 1, % Auto % 367 1,01 1, % Auto % 253 1,02 1, % Bekleidung % 70 0,87 0, % Finanz % 205 1,06 2, % Finanz % 160 1,03 1, % Finanz % 115 0,89 1, % Industrie % ,05 1, % Industrie % 261 1,05 1, % Logistik % 125 1,14 1, % Logistik % 300 1,14 1, % Logistik % 105 0,68 0, % Logistik % 295 0,96 0, % Logistik % 241 0,97 0, % Public % 198 1,04 1, % TelCo % ,17 2, % TelCo % 210 0,94 0, % TelCo % 195 1,04 0, % Standardabweichung ± 34% ± 13% Quelle: sd&m AG,

43 Die UCP-Methode wird bei der msg zur Plausibilisierung der Expertenschätzung und bei Nachkalkulationen eingesetzt Auftraggeber Budgetierung/ Ausschreibung Auftragnehmer Angebot Initialisierung Projektdurchführung Abschluss Angebotsfreigabe 2 Projektabschluss Zur Angebotsfreigabe wird die Expertenschätzung mit der UCP-Schätzung verglichen Basis der Schätzung ist eine Grobspezifikation bzw. Pflichtenheft, das Format ist variabel, aber Use- Case-basiert Zum Projektende wird eine Nachkalkulation durchgeführt. Der Ist-Aufwand wird mit der UCP-Schätzung verglichen Basis der Nachkalkulation ist die Spezifikation (Stückliste der Realisierung) 47

44 Die UCP-Methode setzt auf einer Grobspezifikation auf und schätzt die Phasen Feinspezifikation und Umsetzung ab Vorbedingung Grobspezifikation liegt vor (RUP: Inception) Spezifikations-Format ist variabel Schätzumfang Feinspezifikation bis Bereitstellung zur Abnahme (RUP: Elaboration + Construction) inklusive QS-Maßnahmen d.h. folgende umrandete Aufwände aus dem Kontenrahmen 1) : Projekt ggf. in Releases ohne FP - Risiko! Systemerstellung Brutto = PI Projektinhalt UM Umsetzung 60-90% PI 100% = Netto SP Spezifikation 10-30% PI KON Konstruktion 20-30% UM REA Realisierung 50-70% UM INT Integration 10-25% UM IB Inbetriebnahme 0-10% PI SP - IST IST - Analyse Analyse von Ist - Systemen Analyse von Ist - Prozessen SP - THEMA Spez. von Themen u. Daten Spezifikation der fachlichen Themen bis Abnahme Spezifikation des logischen Datenmodells Testfallerstellung Alle notwendigen Abstimmungen dazu Einarbeiten von internen Review - Anmerkungen (Abgrenzung: SP - NACH ) SP - NACH Nacharbeiten nach Review Alle Nacharbeiten zwischen Abnahme veranstaltung bis zur endgültigen Abnahme Typisch: Erstellung Fachkonzept V1.1 SP - ALLG Allg. Spezifikationsaufwände Dokumentenstruktur - Redaktion und Auslieferung Allgemeine Kapitel gem. Spezifikations - Bausteinen z. B. Projektgrundlagen, Ziele & Rahmenbedingungen, Stufung & Einführung etc. Themenübergreifende Workshops SP - QS QS auf Spezifikation Abnahmeveranstaltungen mit Kunden Durchführen & Besprechen von Reviews Schreibtischtests KON - T Konstruktion der T - Stufen Konstruktion der T - Stufen z. B. Tracing, Logging, Drucken, technische Frameworks Schreiben zentrales IT - Konzept Einarbeiten von Review - Anmerkungen KON - A Konstruktion der A - Stufen Konstruktion der A - Stufen z.b. Modulkonstruktion, Dialoge, Batches, Schnittstellen Einarbeiten von Review - Anmerkungen Feinabstimmungen nach FK - Abnahme KON - DB Konstruktion DB - Design & Datentypen Physisches DB - Design Konzeption Indexe Konzeption übergreifende Datentypen KON - MIG Konstruktion Migr. & Einführungsstrategie Konzeption von Migration, Einführungsstrategie & Erstbefüllungen KON - ALLG Allgemeine Konstruktionsaufwände Initialisierung & Gesamtarchitektur Technischer Durchstich & Proof of Concept Interne Handbücher (Entwicklerhandbuch, Nutzungskonzepte, Styleguides etc.) Redaktion & Auslieferung IT - Konzept Allg. Teile im ITK (Einleitung, Glossar, Überblick ) Einarbeiten von Review - Anmerkungen KON - QS Durchführung QS in der Konstruktion Durchführung & Besprechen von Reviews, Review - oder Abnahmeveranstaltungen mit Kunden Schreibtischtests REA - T Realisierung T - Stufen Codieren incl. Persistenz & Datentypen Modul - und Komponententests incl. Bugfix Einarbeiten von Code - Reviews REA - A Realisierung A - Stufen Codieren incl. Persistenz & Datentypen Modul - und Komponententests incl. Bugfix Einarbeiten von Code - Reviews REA - DB Aufbau und Pflege DB Realisierung DDLs etc. DB - Admin - Aufgaben Übergreifende Datentypen realisieren REA - MIG Durchführung Migration & Erstbefüllungen Realisierung & Test von Migrationstools Erstellen von Skripten zur Erstbefüllung Durchführung Migration REA - QS Durchführung QS in der REA Code Reviews incl. Durchsprechen Code Walk - Throughs & sonst. QS - Maßnahmen Hierzu gehört nicht der Entwicklertest! ( REA - T, REA - A ) INT - TVO alle Testvorbereitungen Alle Testkonzepte und Testdaten Testfallerstellung Konzept/Tools Fehlerverfolgung Testtools (Evaluierung, Realisierung ) INT - SYS Durchführung ( Sub - )Systemtest Systematischer, fachlicher & technischer Test der integrierten Inkremente/Stufen eines Projekt - Releases, ohne Teilsysteme von anderen Projekten bzw. Drittsysteme. Oft durch ein unabhängiges Team Auch Paralleltests INT - VBD Durchführung Verbundtest Integrativer Test mit allen Nachbarsystemen auf einer produktionsnahen Umgebung Fokus auf Systemschnittstellen kein vollständiger fachlicher Test Manchmal sind System - und Verbundtest nur gemeinsam sinnvoll durchzuführen. In diesem Fall wird der Aufwand mit INT - SYS erfasst. INT - BUGFIX Fehlersuche & Fehlerbehebung Bugfixing aus System -, Verbund - und Abnahmetest Performancetuning INT - NFKT nichtfunktionale Tests Z. B. Last -, Performance -, Ausfalltests INT - QS Durchführung QS Reviews auf Testkonzepte u. ä. Reviews auf Testfälle IB - ABN Abnahme Nach Vereinbarung: Unterstützung Abnahmetest IB - EIN Einführung & Betrieb Produktionseinführung Installation & Betrieb Unterstützung Rollout IB - DOK Dokumentationen Systemdokumentationen Benutzerhandbücher Betriebshandbücher Installationshandbuch Schreiben der Online - Hilfetexte IB - SCHUL Schulungen Vorbereitung und Durchführung von Schulungen Schulungsunterlagen Train the Trainer IB QS Durchführung QS Reviews von Dokumentationen Reviews von Schulungsunterlagen PQ Projektquerschnitt 25-60% PI PK 20-50% PI Projektkoordination PT Projekttechnik 5-15% PI PK - PL Projektleitung & Teilprojektleitung PK - PM Projektmanagement PK - QK Qualitäts - und Wissensmanagement PT - KM Konfigurations -/Releasemanagement PT - TI Technische Infrastruktur Jede Teamführung (auch von Test - Teams) Kunden - und Risikomanagement Rolle QB und KB, z. B. auch Pflege ISIS KM aufbauen und pflegen Einrichten und Installation Server Planung und Controlling Gremienarbeit, Erwartungsmanagement Steuernde QMS - Aufgaben, QMS - Audits Build - Management Netzwerkverbindung Risikomanagement Controlling auf PM - Ebene QM - Pläne Auslieferungskoordination, Releaseverantwortung Software - Installationen Abstimmung Parallelprojekte Trouble - Shooting Installations - CD erstellen PK - MTG organisat. Meetings und Bestückung von Umgebungen, Transport von Software Workshops PT - SEU PK - CD Software - Entwicklungsumgebung Chefdesign Fachliches und Technisches Chefdesign Inhaltliche Arbeit ist in der Statusmeetings, Kickoff, Touchdown, Schätzworkshops SEU aufbauen und pflegen Auch Teamdesign bzw. SP zu berücksichtigen Keine fachlichen Meetings ( PI ) Service, Support, Hotlines PN Projektnebenaufwände PN PN - EIN Einarbeitung (fachlich/technisch) Auch Teamaufbau, Teamfindung, insb. bei steilem Teamaufbau in Gr Der gefühlte Einarbeitungsaufwand, keine Pauschalen oßprojekten 0-30% PI 1) SP ohne Aufwände für Grobspezifikation 48

45 Die UCP-Schätzung erfolgt in 5 Schritten und differenziert nach Systemanforderungen und Projekteinfluss Use-Cases klassifizieren Aktoren klassifizieren T-Faktor ermitteln M-Faktor ermitteln Use Cases beschreiben das Verhalten und die Interaktion eines Systems als Reaktion auf die zielgerichtete Anfrage oder Aktion eines Aktors (menschlicher oder technischer Nutzer des Systems) Use Cases und Aktoren definieren den funktionalen bzw. abwendungsfachlichen Umfang des Projekts (= A-Faktor). Dieser wird als Use Case Points erfasst Der T-Faktor berücksichtigt die nichtfunktionalen Anforderungen und technologischen Randbedingungen des Projekts. Er wird anhand eines Fragenkatalogs ermittelt Der M-Faktor berücksichtig die organisatorische Komplexität und das Umfeld des Projekts. Er wird anhand eines Fragenkatalogs ermittelt Über den Produktivitätsfaktor (PF) wird der Aufwand berechnet. Dieser Faktor wurde auf Basis der Nachkalkulationen ermittelt und ist vorgegeben. Der Aufwand umfasst sowohl fachliche als auch technische Komponenten und ist proportional zu den ermittelten Use Case Points 5 Aufwand berechnen Aufwand = Systemanforderungen A-Faktor x T-Faktor x Projekteinfluss M-Faktor x PF funktionale Anforderungen nicht funktionale Anforderungen 49

46 Die Größe / Komplexität eines Use Cases wird durch dessen Anzahl Schritte, Dialoge und Szenarien normiert MAX (# Schritte # Dialoge # Szenarien) >= 8 Komplexität Einfach Mittel Hoch Punkte

47 Definition von Schritten in der UCP-Methode als entscheidende Kenngröße Ein Schritt im Ablauf eines Use-Cases ist ein in sich geschlossener fachlicher Teil des Use-Cases, der vom folgenden und davorliegenden Schritt eindeutig getrennt ist, z.b. durch den Wechsel des Akteurs, oder der verarbeitenden "Schicht" (z.b. Eingabe im Dialog durch den Nutzer-> Verarbeitung der Eingabe am Server-> Anzeige des Ergebnisses an der Oberfläche) Erzeugen eines definierten (Zwischen-)Ergebnisses (z.b. Erzeugen von Druckdokumenten) Aufspalten eines neuen Szenarios Es werden die Schritte in allen Szenarien gezählt. Ist ein Schritt in mehreren Szenarien enthalten, wird er nur einmal gezählt. Typische Beispiele für Schritte sind: Eingabe eines oder mehrerer Werte in einen Dialog (ohne dass dazwischen ein Server-Roundttrip erfolgt) Aufrufe von Anwendungsfunktionen Server-Transaktionen 51

48 Schätzbeispiel aus der Praxis: Adresse anlegen Zählen der Schritte 1. Schritt: Dialog Adressdaten anzeigen Adressdaten erfassen 2. Schritt: Benutzereingaben 4. Schritt: Ergebnisse Serveraufrufanzeigen Adresse ist nicht korrekt Prüfung auf postalische Korrektheit Adresse ist korrekt 3. Schritt: Serveraufruf (A-Funktion) Auswahl aus Vorschlagliste Adressvergleich zur Dublettenprüfung 6. Schritt: Serveraufruf (A-Funktion) 5. Schritt: Auswahl der Adresse - Benutzereingaben Neue Adresse anlegen Vorschlagliste Die Adresse existiert nicht Die Adresse existiert Adresse bearbeiten 7. Schritt: Ergebnisse Serveraufruf anzeigen 8. Schritt: Auswahl der Adresse - Benutzereingaben 10. Schritt: Serveraufruf (A- Funktion) 9. Schritt: alternativen Anwendungsfall aufrufen 52

49 Schätzbeispiel aus der Praxis: Adresse anlegen Zählen der Dialoge 2. Dialog Auswahl aus Vorschlagliste 1. Dialog Adresse ist nicht korrekt 3. Dialog Neue Adresse anlegen Adressdaten erfassen Prüfung auf postalische Korrektheit Adressvergleich zur Dublettenprüfung Vorschlagliste Die Adresse existiert nicht Adresse ist korrekt Die Adresse existiert Adresse bearbeiten Zählregeln: Anzahl Dialoge Hier wird die Anzahl der unterschiedlichen Dialoge des Use Case gezählt. Dialoge werden wie folgt gezählt: Jeder Reiter eines Dialogs (mit siginifikanten fachlichen Unterschieden) wird als eigener Dialog gezählt, triviale Pop-Up-Meldungen, Bestätigungen und Menüs werden nicht gezählt, Anzeigeseiten werden nur gezählt, wenn Daten eingegeben werden können. Druckstücke werden auch als Dialoge gezählt Hinweis: Derzeit deckt die Methode Kompexitätsunterschiede bei unterschiedlichen Dialogarten noch nicht gut ab. 53

50 Schätzbeispiel aus der Praxis: Adresse anlegen Zählen der Szenarien 2. Szenario Auswahl aus Vorschlagliste 3. Szenario Adresse ist nicht korrekt Neue Adresse anlegen Adressdaten erfassen Prüfung auf postalische Korrektheit Adressvergleich zur Dublettenprüfung Vorschlagliste Die Adresse existiert nicht 1. Szenario Adresse ist korrekt Die Adresse existiert Adresse bearbeiten Zählregeln: Anzahl Szenarien Hier wird die Anzahl der unterschiedlichen Erfolgs-Szenarien und nichttrivialen Fehlerszenarien im Use Case gezählt. Ein Erfolgs-Szenario ist ein möglicher fachlicher Ablauf des Use Case, der zum Erfolg (Erreichen des Business Goal) führt, z.b.: das Haupt-Szenario ( Main Flow ) des Use Case fachliche Alternativszenarien des Use Case (triviale Abweichungen, z.b. Anzeige einer Meldung, dann Abbruch werden nicht mitgezählt) Fehlerszenarien sind solche, die nicht zum Erfolg (Erreichen des Business Goal) führen fachliche Fehlerszenarien werden gezählt (wenn fachliche Schritte zur Fehlerbehandlung durchlaufen werden) triviale Fehlerszenarien, z.b. Anzeige einer Meldung, dann Abbruch werden nicht gezählt. 54

51 Die Größe / Komplexität eines Use Cases wird durch dessen Anzahl Schritte, Dialoge und Szenarien normiert 2. Szenario 4. Schritt: Ergebnisse Serveraufrufanzeigen 1. Dialog Adresse ist nicht korrekt Adressdaten erfassen Prüfung auf postalische Korrektheit 1. Schritt: Dialog Adressdaten 1. Szenario anzeigen Adresse ist korrekt 2. Schritt: Benutzereingaben 3. Schritt: Serveraufruf (A-Funktion) Ergebnis für Use Case Adresse anlegen: 10 Schritte 3 Dialoge 3 Szenarien 2. Dialog 5. Schritt: Auswahl der Adresse - Benutzereingaben Auswahl aus Vorschlagliste 3. Dialog 10. Schritt: Serveraufruf (A- Funktion) 3. Szenario Die Adresse existiert nicht Neue Adresse anlegen Adressvergleich zur Dublettenprüfung Vorschlagliste 6. Schritt: Serveraufruf (A-Funktion) 7. Schritt: Ergebnisse Serveraufruf anzeigen Die Adresse existiert Adresse bearbeiten 8. Schritt: Auswahl der Adresse - Benutzereingaben 9. Schritt: alternativen Anwendungsfall aufrufen MAX (# Schritte # Dialoge # Szenarien) >= 8 Komplexität Einfach Mittel Hoch Punkte hohe Komplexität = 15 Use Case Points 55

52 Best Practice: Der richtige Schnitt von Use Cases Wichtig für eine verlässliche Schätzung ist eine einheitliche und angemessene Granularität. Folgende Hinweise deuten auf einen zu groben Schnitt hin: Die textuelle Beschreibung eines Szenarios umfasst mehr als eine DIN-A4-Seite oder Ein Szenario enthält mehr als 12 Schritte oder Ein Use Case beinhaltet mehr als sieben Szenarien (einzelnen Szenarien sind hier als eigene Use Cases zu betrachten). Folgende Hinweise deuten auf einen zu feinen Schnitt hin: Der Use Case enthält keinen Dialog und Der Use Case hat nur ein Szenario und Der Use Case hat nur einen oder zwei Schritte Falls mehr als etwa 20% der Use Cases zu grob oder zu fein sind, ist Vorsicht geboten: Hier kann die nicht angemessene Granularität das Schätzergebnis verfälschen. Die entsprechenden Use Cases sollten dann zunächst fachlich geteilt bzw. zusammengezogen werden. Insgesamt ist eine ausgewogene Verteilung von kleinen, mittleren oder großen Use Cases ein Zeichen für einen "guten" Schnitt. Generell gilt, dass Schritte innerhalb eines Use Cases, innerhalb einer Schätzung und (idealerweise) über alle UCP Schätzungen hinweg etwa gleich groß sein sollten. 56

53 T-Faktor und M-Faktor normieren auf einfache Weise die technische und organisatorische Komplexität des Projekts T-Faktor Kostenfaktor IFPUG FPA 4.1 COCOMO II UCP (Karner) Credit Suisse UCP MT230 sd&m UCP 1.0 sd&m Umfrage Komplexe Berechnungen Benutzeroberfläche Schnittstellen Verteiltes System Verfügbarkeitsanford Wiederverwendbark. geford ? Performance ? Flexibilität des Systems ? Installation Sicherheitsanforderungen 1 1 Anwender-Schulung 1 1 Anforderung an Portabilität 1 1 Auslastung Zielumgebung 1 2 Anzahl Clients 1 Betreibbarkeit 1 Flexibilität Architektur 1 Ähnliche Produkte 1 Ausfallsicherheit (Reliability) 1? Datenbankgröße 1 Tausch Hard-/Software 1 Flexibilität d. Entwicklung 1 Summe M-Faktor Kostenfaktor IFPUG FPA 4.1 COCOMO II UCP (Karner) Credit Suisse UCP MT 230 sd&m UCP 1.0 Stabile Anforderungen Reife der Prozesse Lstg./Fähigheit Chefdesigner Verfügbare Zeit 1 1 Teamplayer 1 1 Kontinuität Mitarbeiter 1 1 Review und Architektur 1 1 Anzahl Entscheidungsträger 1 1 Integrationsabhängigkeit 1 1 Erfahrung Fachlichkeit ? Motivation 1 1 Verfügbarkeit Team 1 1 Effizienz Programm.sprache 1 1 Erfahrung mit RUP 1 Erfahrung Objektorientierung 1 Erfahrung Werkzeuge 1? Erfahrung Plattform/Middlew. 1 Verteiltes Arbeiten 1? Dokumentation 1 Unterstütz. durch Werkzeuge 1 Lstg./Fähigk. Programmierer 1? Summe sd&m Umfrage Legende: (Bewertung der Kostenfaktoren aus Sicht der sd&m Umfrage) relevant? evtl. relevant aber Streuung zu hoch fehlt überflüssig nicht relevant 57

54 Zur Bestimmung des M-Faktors wird das Projekt bezüglich eine Reihe von Einflussgrößen bewertet Kostenfaktoren im M-Faktor (Ausschnitt) Nr. Einflussgröße Beispielwerte für die Bewertung Bewertung M1 M4 Leistung/ Fähigkeit Chefdesigner Qualität von Grobspezifika-tion und T-Architektur Wie erfahren sind der technische und fachliche Chefdesigner (TCD und FCD) hinsichtlich Aufgabe und Fachlichkeit bzw. Technik)? 0: wenig erfahren (0 vergleichbare Projekte als FCD oder TCD durchgeführt) 3: erfahren (1 vergleichbares Projekt als FCD oder TCD durchgeführt) 5: sehr erfahren (2 vergleichbare Projekte als FCD oder TCD durchgeführt) Wie nachvollziehbar und detailliert ist die Grobspezifikation und wie gut sind Risiken bekannt? Müssen z.b. umfangreiche Arbeiten zur Erstellung der T-Architektur durchgeführt (typisch für ein erstes Release) werden oder sind wichtige Pflöcke schon gesetzt (typisch für eine hohe Releasenummer) 0: die Grobspezifikation enthält zahlreiche Widersprüche und offene Fragen, für die Klärung sind mehrere Workshops notwendig; eine Risikoanalyse muss durchgeführt werden; es sind umfangreiche Arbeiten notwendig, um eine T-Architektur zu erstellen 3: die Grobspezifikation enthält offene Fragen, welche mit dem Kunden zu klären sind; eine Risikoanalyse wurde durchgeführt und es existieren Risiken; die T-Architektur entspricht weitestgehend einer Standardarchitektur oder wurde in einem vorherigen Release bereits so aufgesetzt 5: die Grobspezifikation ist ausreichend detailliert und lässt keine oder nur sehr wenige Fragen offen; eine Risikoanalyse wurde durchgeführt und ergab keine nennenswerte Risiken; die T-Architektur existiert Wie formal sind das Vorgehen und der Entwicklungsprozess im Projekt (bezieht sich auf Aufbau- und Ablauforganisation)? 3 3 M-Faktor > 1.0 M-Faktor = 1.0 M5 Prozess- Overhead 0: komplexer Entwicklungsprozess, d.h. sehr formales Vorgehen und Prozesse, hohe Abstimmungs- und Querschnittsaufwände, alle Querschnittsrollen besetzt (typisch für Großprojekt mit mehr als 40 Mitarb.) 3: normaler Entwicklungsprozess mit durchschnittlichen Querschnittsaufwänden (typisch für mittelgroßes Projekt, aber auch für kleine Projekte mit entsprechend formalen Anforderungen des Kunden) 3 M-Faktor < 1.0 5: schlanker Entwicklungsprozess, d.h. pragmatisches Vorgehen, wenig Dokumentation, keine formalen Reviews oder Abnahmen, niedrige Querschnittsaufwände (typisch für kleines Projekt mit max. 5 Mitarb.) 58

55 Die UCP-Methode setzt eine fachliche Größenbestimmung voraus Geeignet Nicht geeignet Individualentwicklung Produktanpassungen Neuentwicklung Wartung, d.h. geringfügige Anpassung bestehender Systeme Neuentwicklung fachlicher Geschäftsprozesse in betrieblichen Anwendungen Technikstufen, Steuerungssysteme Stammdaten-Pflegesysteme Fazit Methode ist ungeeignet, wenn Umfang von System-Anpassungen nur schlecht durch Use Cases erfasst wird, z.b. bei technischen Stufen, in denen sich die Fachlichkeit (A-Faktor) nur wenig ändert 59

56 Ein paar Disclaimer... Use Case Points sind wie alle Softwaremetriken keine fürchterlich exakte Wissenschaft o Wer mit Use Case Points arbeitest, muss sich auf eine gewisse Unschärfe einlassen und manchmal von Details abstrahieren Use Case Points sind keine Wunderwaffe o Garbage in garbage out : Wenn die Schätzbasis so vage oder unvollständig ist, dass ich Use Cases nicht sinnvoll benennen und annähernd vollständig aufzählen kann, hilft auch UCP nicht weiter o Wenn sie zum Projekt nicht passen, lass die Finger davon. Use Case Points lassen sich nicht für alle Projekte sinnvoll einsetzen 60

57 AGENDA 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur 61

58 Literatur UCP 3.0 Balzert, H.: Lehrbuch der Software-Technik, Band 1, Software-Entwicklung. Spektrum Akademischer Verlag, 2. Auflage, Siedersleben, J.: Softwaretechnik Praxiswissen für Software- Ingenieure 2. überarbeitete und aktualisierte Auflage, Hanser Verlag, Frohnhoff, S.; Jung, V.; Engels, G.: Use Case Points in der industriellen Praxis In Applied Software Measurement - Proceedings of the International Workshop on Software Metrics and DASMA Software Metrik Kongress, Abran, A. et al. Eds. Shaker Verlag, 2006, pp Cockburn, A.: Writing Effective Use Cases, Addison-Wesley, Smith, J.: The Estimation of Effort Based on Use Cases, Rational Software, Cupertino, CA.TP-171, October