IT-Projektmanagement Teil 5: Schätzung. Wintersemester 2012/2013 Dr. Gerhard Pews

Transkript

1 IT-Projektmanagement Teil 5: Schätzung Wintersemester 2012/2013 Dr. Gerhard Pews

2 Ziel dieser Einheit ist, den Studierenden Hintergrundwissen und Handwerkszeug zur Schätzung zu vermitteln. Ziele der Vorlesungseinheit Inhalte Hintergrundwissen zu Schätzungen vermitteln Gängige oder besonders bekannte Schätzmethoden vorstellen Expertenschätzung nach Delphi-Verfahren praktisch erlernen. 2

3 Der Fahrplan durch die Vorlesung Inhalte Einführung Das Was : Der Gegenstand von Softwareprojekten Das Wie : Die Tätigkeiten in einem Projekt und wie man sie ausführt Vorbereitung eines Projekts Projektplanung Durchführen eines Projekts Unterstützende Tätigkeiten Soft Factors Wirtschaftliche Aspekte 3

4 AGENDA Allgemeine Grundlagen zur Schätzung Function Point Verfahren Expertenschätzung, Delphi-Verfahren CoCoMo Verfahren 4

5 Schätzungen sind immer ein Blick in die Glaskugel und keine verlässlichen Berechnungen Zitat zu Schätzungen 5

6 Der Wunsch-Zeitpunkt für eine Schätzung ist der, zu dem die wesentliche Informationsgrundlage komplett ist. Zeitpunkt, zu dem man schätzen möchte Fachliche Konzeption Technische Konzeption Realisierung Test & Integration Umfang der Funktionalität bekannt Fachliche Funktionen, Masken Umsetzung bekannt 6

7 Eine Schätzung findet oft schon dann statt, wenn noch viele Einflussgrößen unbekannt sind. Zeitpunkt, zu dem geschätzt werden muss 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 7

8 Grundsätzlich kann top-down oder bottom-up schätzen Herangehensweisen 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 8

9 Da zu hohe Schätzung ist im nachhinein nur schwer zu überprüfen sind, besteht die Gefahr zu hoch zu schätzen und ein Projekt zu verlieren. Folgen aus 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. 9

10 Auch wenn Schätzungen immer ungenau sind, sind sie für die Planung eines Projekts unverzichtbar 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. 10

11 Der geschätzte Aufwand hängt nicht nur von der umzusetzenden Fachlichkeit, sondern auch noch von anderen Faktoren ab. Wichtigste Einflussfaktoren auf den Aufwand Umzusetzende Fachlichkeit (funktional) Masken Druckstücke Batches Berechnungen zu berücksichtigende Fehlersituationen Migrationen aus Altsystemen Abhängigkeit von andern Systemen Technologische Umsetzung, nichtfunktionale Anforderungen Performance, Antwortzeitverhalten Mengengerüste Architektur Systemplattform, Basis-Technologien PM-Faktoren Team Mitarbeiterqualifikation Erfahrung Eingespieltes Team Projektorganisation Projetvorgehen, Methodik Unterstützung durch Tools Sonstige Faktoren Auftraggeber Aufwände steigen mit Größe der Aufgabe 11

12 Während der Projektabwicklung wird ständig geschätzt und nachgeschätzt. 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 12

13 AGENDA Allgemeine Grundlagen zur Schätzung Function Point Verfahren Expertenschätzung, Delphi-Verfahren CoCoMo Verfahren 13

14 Das Vorgehen bei der Function-Point-Schätzung ist dreischrittig 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 14

15 Im ersten Schritt wird die Fachlichkeit strukturiert erhoben, in ihrer Komplexität abgeschätzt und mit Function Points bewertet 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 15

16 Im Beispiel wird jeder Fachlichkeit eine Komplexität und damit auch ein FP-Wert zugeordnet 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 16

17 Im zweiten Schritt werden sonstige Einflussfaktoren in einem numerischen Faktor zusammengefasst. 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. 17

18 Im dritten Schritt wird die Gesamtkomplexität des Projekts bestimmt und daraus ein Aufwand abgeleitet. 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 18

19 Die FP-Schätzung liefert insbesondere im ersten Schritt reproduzierbare Ergebnisse, der zweiten Schritt ist unternehmensspezifisch. Bewertung der FP-Methodik 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. 19

20 AGENDA Allgemeine Grundlagen zur Schätzung Function Point Verfahren Expertenschätzung, Delphi-Verfahren CoCoMo Verfahren 20

21 Die Expertenschätzung schätzt die Aufwände direkt und nutzt dazu das Delphi-Verfahren Allgemeine Hinweise zur 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. 21

22 Bei einer Expertenschätzung nach Delphi-Verfahren wird so lange geschätzt, bis die Experten ein weitgehend stimmiges Ergebnis erzielen. Vorgehen bei einer 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 22

23 Der erste Schritt bei einer Expertenschätzung ist das Aufstellen der Schätzpostenliste. Beispiele und Hinweise zur Erstellung einer 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 23

24 Der Wert, der in einer Expertenschätzung typischerweise geschätzt wird, ist der Bearbeitungstag: BT. 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, 24

25 Zur Vereinfachung einer Schätzung kann nur die Realisierung geschätzt werden und dann auf den Gesamtaufwand hochgerechnet werden. 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. 25

26 Die Schätzung der Realisierung setzt als Annahme voraus, dass alle Vorarbeiten erfolgt sind. 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. 26

27 Die Hochrechnung von Realisierungsaufwänden auf den Gesamtprojektaufwand erfolgt über Erfahrungswerte. 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. 27

28 Die Aufschläge für verschiedene Faktoren basieren auf Erfahrungswerten. 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! 28

29 Bei sehr großen Schätzpostenlisten kann man über Stützpunkte oder Repräsentanten von Klassen schätzen Tipps zur Schätzung großer Schätzpostenlisten Problem 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. 29

30 Will man die Schätzunsicherheit explizit machen, kann man in Form einer Min-Max-Schätzung schätzen Vorgehen bei einer Min-Max-Schätzung Problem 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 30

31 Fallbeispiel Fallbeispiel: Expertenschätzung eines Web-basierten Reporting-Systems 31

32 AGENDA Allgemeine Grundlagen zur Schätzung Function Point Verfahren Expertenschätzung, Delphi-Verfahren CoCoMo Verfahren 32

33 Das CoCoMo-Verfahren wurde durch Barry Boehm entwickelt. Überblick über CoCoMo, CoCoMo II 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) 33

34 CoCoMo differenziert Projekte nach Projektklassen 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 34

35 CoCoMo unterscheidet weiter nach Modellvarianten, nach denen die Einflussparameter unterschiedlich verrechnet werden. 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 35

36 CoCoMo sieht 15 Einflussfaktoren vor, die in die Aufwandsschätzung einfließen. Einfluss der Faktoren auf die Schätzung 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 36

37 Berechnung des Gesamtaufwands und der Projektlaufzeit basiert auf den vorgestellten Faktoren. Berechnung des Gesamtaufwands in CoCoMo 37

38 Obwohl CoCoMo wenig verbreitet ist, kann man aus CoCoMo gut lernen, welche Faktoren eine Schätzung beeinflussen. 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 38

39 Schätzungen ergeben oft hohe Werte. Stehen Sie dazu. Tipps zur Schätzung Tipps Keine Angst vor großen Zahlen. Software ist teuer. Eine ehrliche Schätzung ist die Grundlage für den Projekterfolg. 39

40 Vielen Dank für Ihre Aufmerksamkeit!