Einführung in die Wirtschaftsinformatik Schätzmethoden Prof. Dr. Volker Herwig

Transkript

1 Einführung in die Wirtschaftsinformatik Schätzmethoden Prof. Dr. Volker Herwig Prof. Dr. Volker Herwig

2 Inhalt Hintergrund Schätzmethoden Beispiel - COCOMO Beispiel - Function Point Toolsupport und Hinweise 2

3 Really? 3

4 4 Source: Rework (from the inventors of bacecamp)

5 Projects change during time. Staff not ready when planned Require ments removed Staff deverted to support trade show Unstable functional ity removed Estimation = 20 staff months THE PROJECT Require ments added Less experience d staff than expected Staff deverted to support all project More requirem ents added 5

6 Kosten eines Softwareprojektes Hardware- und Softwarekosten für Entwicklungs- und Produktionsumgebung (Server, Netzwerk, Betriebssysteme, Datenbanksoftware, Schnittstellenprogramme etc.) Anschaffung, Abschreibung, Betrieb bis regulärer Service beginnt Supportkosten Für die Entwicklungszeit und bis regulärer Service beginnt Schulungskosten Projektteam und künftige Anwender Entwicklungskosten ] Methoden der Kostenschätzung Sonstige Einführungskosten Helpdesk set up, Prozessänderungen etc. 6

7 Count this, that and drop 8 Minutes Stanford Report, June 14, 2005 'You've got to find what you love,' Jobs says I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out? It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college. And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting. It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5 deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example: Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating. None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later. Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life. 7

8 Results WS0809 This: 4 That: 16 Drop: 10 (incl. dropped etc.) WS0809 This: 4 That: 16 Drop: 10 (incl. dropped etc.) à 30 8

9 Painted probability distribution X y plot 9

10 Schätzungen sind i.d.r. zu optimistisch 10

11 Single Estimations are associated with a probability Probability of Success 90% 75% 50% 25% 0% Estimated Completion Time 24 weeks 22 weeks 20 weeks 18 weeks 16 weeks Are you giving a probability with your estimations? Maybe you should... 11

12 Kostenschätzung Die Kostenschätzung spielt in der eine Planung zentrale Rolle, da sie die für Budget und Termine notwendigen Angaben liefert. Drei Kernfragen werden beantwortet: 1) Wie gross ist der Arbeitsaufwand/Arbeit? (bspw. Manntage) Manntage 2) Wie viel Zeit wird benötigt? 250Tage (10 Entwickler) 3) Welches sind die totalen Kosten? 1,2 Mio (2.500MT*8h*60 /h) Entwickler 0,3 Mio Hardware + Software. Mehr Ressourcen heisst notw. nicht weniger Zeit 12

13 Wer ist verantwortlich für die Schätzung im Projekt? Projektleiter ist verantwortlich Führen Schätzung allein aus oder mit Beratung durch Experten (Entwicklern, Administratoren etc.) Experten einbeziehen: Studien zeige, dass die Schätzungen besser ausfallen, wenn Experten eingebunden sind Motivation der beteiligten Experten selbstgesteckte Ziele Einmalige Schätzung Schätzung ist fortlaufend notwendig, um Abweichungen zu korrigieren. 13

14 Overestimation/Underestimation Arguments against overestimation Parkinson s Law - people with additional time will find work to do Goldratt s (1997) Student Syndrome work will get pushed out until later in the project Arguments against underestimation Reduced effectiveness of project plans Statistical reduced time of on-time completion Poor technical foundation (worse effects) Destructive late project dynamics (more status meetings, frequent re-estimations, apologizing, interim releases, discussions about re-priorizations) 14

15 Standish Group Chaos Study 15

16 Benefits of accurate estimations Improved status visibility Comparison planned progress vs. actual progress Project tracking Higher quality Avoid stress-related quality issues 40% of all software errors caused by stress (Glass 1994) Better coordination with non-software functions Coordination with other business functions (staff training, campaigns, fares etc.) Better budgeting obvious J incl. forecasting Increased credibility of development team obvious Early risk information Reaction time increases, less impact 16

17 Top-down und Bottom-up Ansatz Top-down Aufwand für das gesamte Projekt schätzen und den so ermittelten Wert auf die einzelnen Aktivitäten verteilen Bottom-up Aufwand für jede Aktivität schätzen und den Aufwand für das gesamte Projekt durch Summieren errechnen! Gefahr, dass Schätzung nicht genügend auf Details eingeht! Gefahr, dass projektübergreifende Aktivitäten vergessen werden 17

18 Top Down Ansatz - Beispiel Annahme: Verteilung des Gesamtaufwandes eines Projektes auf die Phases ist relativ stabil. Phase Prozentsatz Aufwand (MT) Analyse 6% 10,8 Entwurf 49% 88,2 Implementierung 30 % 54 Test 10% 18 Inbetriebsetzung 5% 9 Summe 100% 180 Hinweise: Kleine Projekte: 1/3 Konzeption 1/3 Realisierung 1/3 Test/Finalisierung Große Projekte: Konzeption = Summe (Realisierung, Test/Finalisierung) Zuschläge: Unvollständige Anforderungen % Projektmanagement 15-20% 18

19 Buttom Up Ansatz - Basis Herunterbrechen in Arbeitspakete 1. Unterteilen der Aufgabe in Arbeitspakete. Zwei Ansätze, die kombinierbar sind: Inhaltliche Unterteilung der Aufgabe ( Ergebnis benennen! ) Requirements User Interface, Business Logic, Daten Speicherung Zeitliche Unterteilung der Aufgabe bspw. auf Basis eines Vorgehensmodells Analyse Entwurf Implementierung Analyse: Erstellung Requirements, Kick-Off meeting Entwurf: Fachkonzept, Design Modell, Datenmodell Test Inbetrieb setzung 19

20 Buttom Up Ansatz - Basis Schätzen des Aufwands/Arbeit und Errechnung der Kosten 2. Schätzung der notwendigen Arbeit (Aufwandsschätzung) Ermittlung der geschätzten Arbeit in Personentagen (PT) oder in Personenstunden (Ph) 3. Errechnung der Kosten Kosten = Arbeit (Ph) x Stundensatz (h) Hinweis: Dauer für die Erledigung eines APs stimmt i.a. nicht mit der Arbeit (geschätzte PTs) überein Arbeit = 3 PT, 1 Vollzeitperson ] Dauer = 3 Tage Arbeit = 3 PT, 3 Vollzeitpersonen ] Dauer = 1 Tag Arbeit = 3 PT, 1 Teilzeitperson (50%) ] Dauer = 6 Tage 20

21 Einflußfaktoren und Probleme Einflussfaktoren Komplexität der Arbeitspakete Verfügbare Hilfsmittel Anzahl der einzusetzenden Personen Verfügbarkeit der Mitarbeiter Abhängigkeiten von anderen Arbeitspaketen, z.b. benötigte Zwischenergebnisse Häufige Probleme Projektmitarbeiter stehen noch nicht fest Unterschiedliche Produktivität je Mitarbeiter Grad der Verfügbarkeit der einzelnen Mitarbeiter Unklarheiten im technischen und organisatorischen Umfeld 21

22 Einflußfaktoren und Probleme Einflussfaktoren Komplexität der Arbeitspakete Verfügbare Hilfsmittel Anzahl der einzusetzenden Personen Verfügbarkeit der Mitarbeiter Abhängigkeiten von anderen Arbeitspaketen, z.b. benötigte Zwischenergebnisse Häufige Probleme Projektmitarbeiter stehen noch nicht fest Unterschiedliche Produktivität je Mitarbeiter Grad der Verfügbarkeit der einzelnen Mitarbeiter Empfehlung Unklarheiten im technischen und organisatorischen Umfeld Puffer 10-20% bei konservativer Schätzung Einbindung von Experten, Projektmitarbeitern Review durch erfahrenen Kollegen wir geben Ihnen 20% weniger Ursachenforschung bei Abweichungen Lernen für die Zukunft 22

23 Mythos Wenn wir im Zeitplan zurückliegen, können wir einfach mehr Entwickler einstellen, um die Zeit wieder aufzuholen. Realität Fehlende Zeit ist nur sehr begrenzt durch eine höhere Mitarbeiterzahl kompensierbar. 23

24 Fehlerursachen Einarbeitung Installation von Softwareprodukten Projektplanung (insbesondere Updates der Schätzung und des Projektplans) Abstimmungen, Meetings Ausfälle (Mitarbeiter, Rechner, Software) Usability Maßnahmen und Tests bezüglich Ausfallsicherheit Zeit für Korrektur nach Tests Oberfläche zur Administration und Konfiguration Installationssoftware, Probeinstallation Konfigurationsmanagement und Probleme damit Probleme mit den eingesetzten Technologien, insbesondere weniger vertrauten Hilfefunktion Dokumentation der Software Wartung ProgrammiererInnen programmieren nicht 100% ihrer Zeit! Eine Studie der Bell Labs ergab, dass der im Hinblick auf Codeerzeugung produktive Anteil der Arbeit eines Programmierers nur 13% beträgt. 24

25 Categories of estimation errors 1. Inaccurate information about the project being estimated 2. Inaccurate information about the capabilities of the organization that will perform the project 3. Too much chaos in the project to support accurate estimation (that is trying to estimate a moving target) 4. Inaccuracies arising from the estimation itself Please give examples! 25

26 Verteilung der Arbeitszeit von Entwicklern ProgrammiererInnen programmieren nicht 100% ihrer Zeit! Eine Studie der Bell Labs ergab, dass der im Hinblick auf Codeerzeugung produktive Anteil der Arbeit eines Programmierers nur 13% beträgt. Programme schreiben Programme und Handbücher lesen Arbeitsbezogene Kommunikation Persönliches Ausbildung Post Diverses 13% 16% 32% 13% 6% 5% 15% Source: Glinz, M.: Software Engineering I: Skript zur Vorlesung an der Universität Zürich,

27 Prinzipien Schätzung Prinzipien Keine großen Risiken»Min-mid-max-Methode«à Einschränkungen & Voraussetzungen definieren oder Aufwandspunkt untergliedern»murphy s Law«es wird tendenziell unterschätzt Min-Max-Ansatz Min = so schnell geht es, wenn alles glatt geht Mid =so lange dauert es in einem durchschnittlichen Fall (gemäß früherer Projekterfahrung) Max =so viel Aufwand kostet es»maximal«, d. h. in 90% aller Fälle sollte es innerhalb dieser Anzahl von PT fertig werden min mid max Schätz Leistungen (in PT) Implementierung + Test der Schnittstelle zur Produktdatenbank 27

28 Activities commonly missing during estimation Functional and (non-functional) requirements missing like: Setup/installation program Data conversation utility Glue code (integration of third party software) Help system Deployment modes Interfaces with external systems Software Development activities commonly missed like: Ramp-up time for new team members Mentoring of new team members Management coordination Data conversation Installation Requirements clarification Creation of test data Participation in technical reviews Non-Software Development activities commonly missed like: Vacation/holidays/sick days/trainings Company meetings/department meetings Troubleshooting 28

29 Inhalt Hintergrund Schätzmethoden Beispiel - COCOMO Beispiel - Function Point Toolsupport und Hinweise 29

30 Schätzmethoden Schätzmehoden Experte Empirisch Empirisch Expert Empirisch Faktoren- Kenn- Parame- Experten- Vergleichs- u.gewichzahlen- trische beurteilung methoden tungsmethoden Methoden methoden Beispiele: Expertenbefragung Function Point Prozentsatzmethode; Produktivitätsmethoden COCOMO Formel mit Gewichtung wie #E/A Elemente, #Requiremnts 30

31 Empirische Schätzmethoden Mit Erfahrungen der Vergangenheit werden die bekannten Informationen bewertet und in Arbeit/Kosten umgerechnet. Vorraussetzung: Genaue und detaillierte Wissensbasis aus vergangenen Projekten Genauer und detailertes Wissen über die Arbeitspakete Empirsch-algorithmsche Schätzverfahren stat. Analyse historischer Daten Formeln verwenden Parameter, die das Produkt charakterisieren und Parameter, die die Bedingungen der Entwicklungsumgebung beschreiben Genauigkeit der Schätzung abhängig von der Genauigkeit der Eingangsgrössen (garbage-in-garbage-out)... der Qualität der Kalibrierung (Anpassung an die jeweilige Entwicklungsumgebung) 31

32 Expertenbeurteilung Verfahren: Aufwand wird auf Basis des Aufwandes eines ähnlichen früheren Projektes geschätzt Unterschiede werden so gut wie möglich berücksichtigt. D Einfach und billig D Kann sehr ungenau sein (Die Qualität der Schätzung ist von der Erfahrung der Schätzer und der Qualität der Erfahrungs-daten abhängig) 32

33 Expertenschätzung Delphi Methode Systematisches mehrstufiges Befragungssystem mit mehreren Experten und einem Moderator Verfahren: je Arbeitspaket gibt jeder Experte einen Schätzwert ab Mittelwert, falls alle Schätzwerte in einer bestimmten Bandbreite (Mittelwert + 20%) Sonst: Argumente austauschen und neue individuelle Schätzung Zuschläge zu den Einzelschätzungen: Plus % = Aufwand für Projektmanagement Variationen: 3-Experten-Konzept (oder Mini-Experten-Team) 3 optimistische, 3 realistische und 3 pessimistische Schätzungen Abklärungen durchführen, bis die Ergebnisse in jeder Kategorie übereinstimmen Daraus Schätzwert gemeinsam ableiten (z.b. s = (o+4r+p)/6) Source: Michael Häder (Hrsg.): Delphi-Befragungen. Ein Arbeitsbuch. Westdt. Verlag, Wiesbaden

34 Expertenschätzung Delphi Methode (Ausreisser werden eliminiert) C Liefert zuverlässigere Schätzungen als Expertenmethode D Höherer Schätzaufwand als Expertenmethode Systematisches mehrstufiges Befragungssystem mit mehreren Experten und einem Moderator Verfahren: je Arbeitspaket gibt jeder Experte einen Schätzwert ab Mittelwert, falls alle Schätzwerte in einer bestimmten Bandbreite (Mittelwert + 20%) Sonst: Argumente austauschen und neue individuelle Schätzung Zuschläge zu den Einzelschätzungen: Plus % = Aufwand für Projektmanagement Variationen: 3-Experten-Konzept (oder Mini-Experten-Team) 3 optimistische, 3 realistische und 3 pessimistische Schätzungen Abklärungen durchführen, bis die Ergebnisse in jeder Kategorie übereinstimmen Daraus Schätzwert gemeinsam ableiten (z.b. s = (o+4r+p)/6) Source: Michael Häder (Hrsg.): Delphi-Befragungen. Ein Arbeitsbuch. Westdt. Verlag, Wiesbaden

35 Inhalt Hintergrund Schätzmethoden Beispiel - COCOMO Beispiel - Function Point Toolsupport und Hinweise 35

36 COCOMO (Constructive Cost Model) Kostenschätzverfahren von Barry W. Boehm (1981) Algorithmisch-empirisches Schätzverfahren Kerngröße ist die erwartete Anzahl der Codezeilen (K)DSI : kilo delivered source instructions (K)LOC : kilo source lines of code Abschätzung dieser Größe wird von COCOMO nicht behandelt Abhängig von Programmiersprache Ansätze Erfahrungswerte aus früheren Projekten Ermittlung der Codezeilen aus Function Points, Object Points Grobeinteilung in drei Projekttypen organic (organisch) semidetached (teileingebettet) embedded (eingebettet) Einbeziehung weiterer Kostenfaktoren (Cost Driver) 36

37 Language Levels Durch Language Levels wird die Anzahl Programmzeilen über verschiedene Sprachen hinweg vergleichbar. Beispiel: Funktion lässt sich in Java durch 3 Zeilen beschreiben, in Visual C++ benötige sie 4,75 Zeilen. Assembler 1 C 2.5 PASCAL 3.5 Modula LISP 5 PROLOG 5 C++ 6 Java 6 Visual C SMALLTALK 15 ABAP/4 20 SQL 25 EXCEL

38 COCOMO Stufen der Abschätzung Basic Model: Aufwand in Personenmonaten und benötigte Kalenderzeit werden aus Basis der Größe des Produktes (# der Codezeilen) berechnet Intermediate Model: Neben dem Basis Model werden spezielle Anforderungen und Randbedingunge (Cost Driver Attributes) berücksichtigt. Detailed Model: Im Unterschied zum Intermediate Model werden hier die Cost Driver Attributes auf einzelne Phasen oder einzelne Subsysteme angewendet. 38

39 Basic COCOMO Entwicklungsaufwand [in MM] = a * Programmgrösse [in KDSC] b Entwicklungszeit [in M] = c * Aufwand d Einfache Applikationen ( Organic Mode Projects ) Programmsysteme (Semi-detached Mode Projects ) Eingebettete Systeme ( Embedded Mode Projects ) a b c d

40 COCOMO - Entwicklungsaufwand zeit abhängig von der Produktgrösse Geschätzter Aufwand [MM] embedded semi-detached organic Produktgrösse [KDSI] 40

41 Intermediate/Detailed COCOMO Berücksichtigung der Cost driver Attributes auf Basis der Tabelle von Boehm. 1.Den Entwicklungsmodus des Projekts identifizieren 2.Die Grösse des Projekts (in Anzahl Codezeilen) schätzen 3.Die 15 Cost Driver Attributes bestimmen 4.Den Projektaufwand in Personenmonaten und die Projektdauer in Monaten berechnen Aufwand [in Personenmonaten]= K1 *... * K15 * Aufwand aus Basic COCOMO Cost Driver Attributes à siehe Boehm s Cost-Driver-Attributes-Tabelle 41

42 Intermediate/Detailed COCOMO Berücksichtigung der Cost driver Attributes auf Basis der Tabelle von Boehm. 1.Den Entwicklungsmodus des Projekts identifizieren 2.Die Grösse des Projekts (in Anzahl Codezeilen) schätzen 3.Die 15 Cost Driver Attributes bestimmen 4.Den Projektaufwand in Personenmonaten und die Projektdauer in Monaten berechnen Aufwand [in Personenmonaten]= C Transparent ( man versteht das Modell ) D Modell ist anfällig auf falsches Zuweisen des Entwicklungsmodus D Cost Driver Attributes und insbesondere die Software-Grösse müssen gut geschätzt werden K1 *... * K15 * Aufwand aus Basic COCOMO Cost Driver Attributes à siehe Boehm s Cost-Driver-Attributes-Tabelle 42

43 Boehms Cost-Driver-Attributes-Tabelle 43

44 Aufgabe: Sortieren der Kostentreiber in Kategorien Vier Kategorien : Produktmerkmale (3) Computermerkmale (4) Personalmerkmale (5) Projektmerkmale (3) 44

45 Aufgabe: KLOC (Kilo Lines of Code) - ein adäquates Mass für die Softwaregrösse? Eine Kostenschätzung mit Boehm s COCOMO setzt eine Schätzung der Softwaregrösse in Anzahl Zeilen voraus. Auch in anderem Zusammenhang wird die Anzahl Zeilen als Mass für die Softwaregrösse verwendet. Beispielsweise wird die Produktivität häufig durch die Anzahl Zeile pro Tag ausgedrückt oder die Zuverlässigkeit einer Software durch die Anzahl Fehler pro Tausend Programmzeilen bezeichnet. Ist aber die Anzahl Zeilen ein adäquates Mass für die Softwaregrösse? Welche Probleme entstehen bei Verwendung von KLOC als Mass für die Softwaregrösse? Was könnte man dagegen tun? Gibt es Probleme bei der Verwendung von KLOC bei der Aufwandschätzung? Bitte diskutieren Sie diese Fragen in einer Gruppe und stellen sie die Ergebnisse vor. 45

46 Aufgabe Ideen zur Lösung Generelle Probleme Kann verschieden gemessen werden (mit oder ohne Kommentare, Leerzeilen,...) Belohnt geschwätzigen und bestraft konzisen Programmierstil Zieht Komplexität nicht in Betracht Ist abhängig von der verwendeten Programmiersprache... Problem bei Kostenschätzung Kann frühestens geschätzt werden, wenn Systementwurf vorhanden ist... 46

47 Inhalt Hintergrund Schätzmethoden Beispiel - COCOMO Beispiel - Function Point Toolsupport und Hinweise 47

48 Function Points Entwickelt in den 70er Jahren von A.J. Albrecht (IBM) Seitdem Weiterentwicklung von verschiedenen Autoren und Gremien (ISO anerkannt) Grundidee: Größe eines Informationssystems lässt sich durch den Umfang seiner Funktionalität messen Function Points Vorteil unabhängig von der Realisierung Ermittlung möglich, wenn Anforderungen vorliegen Nachteil Weniger Anschaulich als Lines of Code (LoC) Fokusiert auf Informationssysteme 48

49 Berechnung der Function Points A function point is a unit of measurement to express the amount of business functionality an information system provides to a user. 1. Schätzung der Function Points für das Produkt - Beispiel: Intranet hat 355 FP. Herunterbrechen der Funktionalität Schätzung der FP per Funktionalität Abhängig von Programmiersprache Beispiel: Dokumentationsumfang: Anzahl Seiten = FP 1.15 Anzahl benötigter Test Cases = FP 1.2 Anzahl benötigter Personen für die Wartung der Software = FP/ Schätzung des Aufwands pro Function Point Source: T. Capers Jones, Estimating Software Costs, McGraw-Hill,

50 Function Point Abhängigkeit von der Programmiersprache 1 Function Point = 320 Statements in Basic Assembler 1 Function Point = 213 Statements in Makro Assembler 1 Function Point = 128 Statements in C 1 Function Point = 107 Statements in COBOL 1 Function Point = 107 Statements in FORTRAN 1 Function Point = 80 Statements in PL/I 1 Function Point = 71 Statements in ADA83 1 Function Point = 53 Statements in C++ 1 Function Point = 15 Statements in Smalltalk Allgemein: für prozedurale Sprachen: 1 FP = 100 Statements für objekt-orientierte Sprachen:1 FP = 20 Statements 50

51 Berechnung der Function Points - Komplexität Die Funktionen (Dateneingaben, Datenausgaben, Anfragen, externe Schnittstellen und interne Datenbestände) des Informationssystems identifizieren und die Komplexität jeder identifizierten Funktion bestimmen. Gewichtungsfaktoren Komplexität niedrig Komplexität mitttel Komplexität hoch Dateneingaben Datenausgaben Anfragen Externe Schnittstellen Interne Datenbestände à Unadjusted Function Point Count 51

52 Function Point Abhängigkeit von der Komplexität Berechnung der Technischen Komplexität: Jeder der folgenden 14 Faktoren wird mit einem Wert zwischen 0 (nicht vorhanden, kein Einfluss) und 5 (starker Einfluss) bewertet. 1. Datenkommunikation 2. Verteilte Funktionen 3. Leistungsanforderungen 4. Belastung der Hardware 5. Verlangte Transaktionsrate 6. Online-Dateneingabe 7. Effiziente Benutzerschnittstelle 8. Online-Datenänderungen 9. Komplexe Verarbeitungen 10. Wiederverwendbarkeit 11. Einfache Installation 12. Einfache Benutzbarkeit 13. Installation an mehreren Orten 14. Änder- und Erweiterbarkeit Die Summe der Faktoren ergibt die Technische Komplexität. 52

53 Berechnung der Function Points - Korrekturfaktoren Den Unadjusted Function Point Count mit einem Korrekturfaktor multiplizieren, der die technische Komplexität des Systems reflektiert. Der Korrekturfaktor wird wie folgt berechnet: Korrekturfaktor = * Technische Komplexität Berechnung à siehe nächste Folie (Der Korrekturfaktor kann Werte zwischen 0.65 und 1.35 annehmen.) à Adjusted Function Point Count = Korrekturfaktor * Unadjusted Function Point Count 53

54 Function Points Aufwand 1. Schätzung der Function Points für das Produkt 2. Schätzung des Aufwands pro Function Point Faustregeln: Kalenderzeit [Monate] = FP 0.4 Anzahl Mitarbeiter = FP/150 Aufwand [Personenmonate] = Kalenderzeit * Anzahl Mitarbeiter Source: T. Capers Jones, Estimating Software Costs, McGraw-Hill,

55 Inhalt Hintergrund Schätzmethoden Beispiel - COCOMO Beispiel - Function Point Toolsupport und Hinweise 55

56 Parkinson s Law WORK EXPANDS SO AS TO FILL THE TIME AVAILABLE FOR ITS COMPLETION Das Projekt kostet so viel wie Arbeitskapazität vorhanden ist. Falls also 5 Personen für 12 Monate verfügbar sind, so beträgt der geschätzte Aufwand 60 Personenmonate. Source: C. Northcote Parkinson, Parkinson's Law: The Pursuit of Progress, London, John Murray (1958) 56

57 Toolunterstützung Features Schätzungen beruhen auf einer Wissensbasis, die Daten aus vielen Projekten beinhaltet Schätzen Grösse, Aufwand, Anzahl Personen je Aktivität, totale Kosten und Zeitplan mit Hilfe von Benutzerangaben zum geplanten System und mit Hilfe der Wissensbasis Bieten Schnittstellen zu Projekmanagement Tools (z.b. MS Project) und anderen Programmen an Produkte: REVIC, SLIM, spqr/20, Checkpoint, Knowledge Plan,... Trends: Integration von in Projektmanagement Tools 57

58 How does a project get to be late?... One day at a time. Source: Brooks, F. P.: The mythical man-month: Essays on Software Engineering, Addison Wesley,

59 Große Projekte Beobachtungen bei grossen Projekten: 1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity start, do not significally change as the start time draws near, no matter how wrong they ultimately turn out to be. 2. During the activity, overestimates of duration come steadily down as the activity proceeds. 3. Underestimates do not change significantly during the activity until about three weeks before the scheduled completion. 59

60 Der Aufwand für die Erstellung von Software steigt mit wachsender Produktgrösse überproportional an. 60

61 im Kern Be accurate. Be conservative. Base the estimate on solid historical data. Include quality, since software quality affects schedules and costs. Include paper documents, since they can cost more than source code. Include effects of creeping requirements. Do not exaggerate the effects of tools, languages, or methods. Get below phases to activity-level cost estimates. Be prepared to defend the assumptions of your estimate. Source: T. Capers Jones, Estimating Software Costs, McGraw-Hill,

62 Weiterführende Literatur COCOMO B.W. Boehm, Software Engineering Economics, Prentice-Hall, (Standardreferenz für COCOMO) E. Horowitz und andere, Software Cost Estimation with COCOMO II, Prentice-Hall, sunset.usc.edu/research/cocomoii/index.html Function Points (International Function Point User Group, im Function Point Counting Practices Manual der IFPUG sind detaillierte Zählregeln für Function Points beschriebenen) (Software Productivity Research Inc., Unternehmen von Capers Jones) 62

63 Kontakt Prof. Dr. Volker Herwig Professor Wirtschaftsinformatik Fachbereich Gebäudetechnik und Informatik Studiengang Angewandte Informatik Tel.: Fax: Raum: Web: 63