6. Aufwandsschätzung. Hintergrund von Schätzungen Daumen Drauf Function Point Source Lines of Code

Transkript

1 6. Aufwandsschätzung Hintergrund von Schätzungen Daumen Drauf Function Point Source Lines of Code 138

2 Ziele des Blocks Aufwandsschätzung Grundsätzliche Probleme von Schätzansätzen verstehen Sinn von formalisierten Schätzansätzen verstehen Notwendigkeit der firmeneigenen (SWproduktionstechnisch eigenen) Anpassung der Ansätze verstehen Unterschiedliche Schätzansätze kennen lernen, ihren Hintergrund verstehen, Vor- und Nachteile beurteilen können 139

3 Aufwand oder Kosten? Aufwand (costing): was getan werden muss, Personenmonate für technische Ausführung, Verwaltung, Management, Material Kosten (prizing): wie viel wird vom Kunden verlangt? Gewinnmaximierung vs. Ölfleck Kosten können sich aus politischen Gründen ändern, der Aufwand für die gleiche Aufgabe nicht 140

4 Warum schätzt man? Aufwandsbestimmung am Anfang des Projekts Schätzung des verbleibenden Aufwands im laufenden Projekt Gegenseitige Aufwandsschätzung bei Geschäftspartnern Offenlegung der Aufwandsansetzung gegenüber dem Kunden (Preisfindung) 141

5 Gründe für die Abweichung von Schätzergebnissen Schlechte Schätzmethodik Projektrisiken anfänglich nicht beachtet Projektrisiken während der Projektlaufzeit nicht gemanagt Preisreduktion ohne Aufwandsreduktion... Verknüpfung mit steuerndem Risikomanagement Deshalb Schätzungen während eines laufenden Projekts wiederholen Schätzung ist ein Maß zu Projektbeurteilung 142

6 Schätzgrundlage Zentraler Ausgangspunkt einer Schätzung, ist das was geschätzt werden soll Je detaillierter ein System beschrieben ist, desto genauer kann bei der Ausnutzung einiger Erfahrungen die Schätzung sein Problem: Am Anfang von Projekten ist das Zielsystem häufig nur grob umrissen, weicht die aktuelle Vorstellung vom Zielsystem vom wirklich gewünschten Zielsystem ab Schätzungen sind Prognosen, die im Laufe von Projekten überprüft und aktualisiert werden müssen 143

7 Struktur des Schätzobjekts Man beachte, dass es verschiedenste Ansätze zur Aufteilung der Projektarbeit gibt, woraus oft folgt, dass nur bestimmte Schätzansätze nutzbar sind (Umrechnungsmöglichkeiten werden später skizziert) Aufteilung 1: Aufgaben Projektmanagement (PM), Qualitätssicherung (QS), SW-Entwicklung Komponenten 1..n, Konfigurationsmanagement (KM),... (Orientierung an einer Work-Break-Down-Struktur) Aufteilung 2: Aufteilung in SW-Komponenten 1..n wobei PM, QS, KM anteilig eingerechnet sind Aufteilung 3: Aufteilung in SW-Entwicklungsphasen Analyse, Design, Implementierung, Test und Integration, wobei PM, QS, KM anteilig eingerechnet sind 144

8 Wann Daumen Drauf Es liegen keine Analogiedaten vor sehr kleines Projekt Schätzprozess wird von Projektverantwortlichen nicht angenommen es wird keine Aufteilung in Komponenten gemacht Beispiel: Schätze Produkt Projekthandbuch 145

9 Schätzprotokoll Aufgabe: Schätzverfahren: Grundlage: Kommentar: Schätzergebnis: Schätzer: Risiken: Nennung der Teilaufgabe oder des Aufgabenpakets z.b. Expertenwissen (= Daumen Drauf ) oder Analogie- Verfahren welche Quelle ist Grundlage der Schätzung? Randbedingungen oder Kommentar zur Aufgabe Aufwand in der vorher gewählten Einheit (z.b. Personentage), bei Kosten, z. B. Anschaffungen, in Euro. In Klammern wird zusätzlich der Risikoanteil angegeben, ein Eintrag 30 (10) PT, bedeutet, dass 10 der 30 PT ein Risikozuschlag sind. Name des/der Schätzer(s) Aufführung spezieller Risiken der Aufgabe, ggfls. mit Nennung der Gegenmaßnahmen, falls schon bekannt, Notation (-> Gegenmaßnahme ) 146

10 Schätzkonferenz (fiktives Beispiel) Paket Schätzer 1 Schätzer 2 Schätzer 3 Ergebnis (in PM) Kommentar Studierendeninformation Erfahrung mit vergleichbaren Projekten Veranstaltungsbeurteilung Nebenamtler, Wahlpflichtfächer Studiengebühren Mitarbeiterverwaltung

11 Function-Point-Methode (1/4) [Bal98] Jede Anforderung (bzw. ermittelte Funktionalität) in eine der fünf Kategorien einordnen Internal Logical Files (ILF, Datenbestand): Datenbestände, die innerhalb des zu entwickelnden Systems bearbeitet werden, z. B. die selbstentwickelten Klassen External Interface Files (EIF, Referenzdaten): Datenbestände die von außerhalb des zu entwickelnden Systems kommen und bearbeitet werden External Inputs (EI, Eingabe): Eingaben von außerhalb in das zu entwickelnde System mit denen der Datenbestand verändert wird, z. B. über Eingabemasken, Dateien in bestimmten Eingabeformaten, Eingaben von externen Systemen External Outputs (EO, Ausgabe): Ausgaben an außerhalb des zu entwickelnden System liegende Komponente, z. B. Ausgabemasken, Dateien in bestimmten Ausgabeformaten; Ausgaben weden aus vorhandenen Daten berechnet External Inqueries (EQ, Abfrage): Abfragen von Informationen des Datenbestands von außerhalb des Systems, z. B. Abfragemasken, reines Anzeigen der verwalteten Daten 148

12 Function-Point-Methode (2/4) Kategorie Anzahl Klassifizierung Eingabedaten 6 einfach 4 mittel komplex Abfragen 4 einfach mittel komplex Ausgaben 6 einfach 9 mittel komplex Datenbestände 7 einfach mittel komplex Referenzdaten einfach mittel komplex Summe ungewichteten Function-Points Gewichtung * 3 * 4 * 6 * 3 * 4 * 6 * 4 * 5 * 7 * 7 * 10 * 15 * 5 * 7 * 10 Zeilensumme

13 Function-Point-Methode (3/4) Summe unbewertete Function-Points Ausnahmeregelungen (0-10) Logik (0-5) Summe der Einflussfaktoren (EF) Verflechtung mit anderen Anwendungssystemen (0-5) Dezentrale Daten, dezentrale Verarbeitung (0-5) Transaktionsrate (0-5) Verarbeitungslogik Rechenoperationen (0-10) Kontrollverfahren (0-5) Wiederverwendbarkeit (0-5) Datenbestandskonvertierungen (0-5) Anpassbarkeit (0-5) Faktor Einflussbewertung (FE) = EF / ,7 Gewichtete Function-Points = ungewichtete Functionpoints *FE ,

14 Function-Point-Methode (4/4) 1000 Personenmonate 0 o o o 0 Function Points 5000 o Unternehmen 1 Unternehmen 2 151

15 Zusammenfassung der Function Point Analyse funktionale Anforderungen Schätzung ungewichtete Function-Points Einflussfaktoren Schätzung Projekteinflüsse Berechnung gewichtete Function-Points Ableitung Aufwand Personenmonate 152

16 Fazit zur Function-Point Analyse Wissenschaftlich fundiert Schätzdetails nur von speziellen Schätzexperten beurteilbar firmenspezifische und methodenspezifische Optimierung schwierig Wenn FPA eingesetzt werden soll, muss sie (evtl. rückwirkend) für verschiedene Projekte evaluiert werden sinnvoll, wenn eigene Schätzabteilung zur Betreuung aller Schätzungen aufgebaut wird wesentlich höherer Aufwand als später vorgestellte vereinfachte Analogieschätzung, Schätzer fühlen sich nicht für Schätzergebnis verantwortlich 153

17 Source Lines Of Code (vereinfacht) SLOC-Schätzung basiert auf Expertenerfahrung aus anderen Projekten Zerlegung in Komponenten, dann Schätzung ( Daumen Drauf ) SLOC Dann Extrapolation aus SLOC auf Aufwand für das Gesamtprojekt Berücksichtigung von Risiken (wie in anderen Ansätzen auch) bei der Umrechung SLOC nach Personentage möglich PT SLOC 154

18 Mitarbeiterverwaltung: Source lines of Code Teilpaket Mitarbeiterstamm ergänzen Mitarbeiterdaten aufdatieren Mitarbeiter löschen Reise einrichten Reisebeleg einrichten Reise prüfen Reisekosten berechnen Reisekosten anweisen Schätzer Schätzer Schätzer konsolidiert Kommentare nicht alle Daten klar komplex? sinnvoll: Schätzkonferenz durchführen geschätzt wird in Java-Zeilen (Annahme: wenig/kein generierter Code) Umrechnung in PT firmenabhängig, Beispielergebnis: 2550 Zeilen ~ 8 PM

19 Übung Führen sie für Ihr Projekt eine Aufwandsschätzung nach folgenden Verfahren durch: Daumen drauf, Function Point, SLOC (in Java). Versuchen Sie dabei nicht einfach Zahlen hinzuschreiben, sondern sich für einzelne Zahlen Argumente auszudenken und den Schätzprozess durchzuspielen, insbesondere ist die Beziehung gleichartiger Zahlen untereinander interessant. Dokumentieren Sie ihre Annahmen, die für alle Verfahren möglichst gleich sein sollen. 156

20 Schätzungen im Projektverlauf In laufenden Projekten sind Aufwandschätzungen bei Meilensteinen oder bei Verfeinerungen von zunächst nur grob beschriebenen Aufgaben zu wiederholen Bei Meilensteinen muss bekannt sein: Anteil der Funktionalität, der theoretisch nach letzter Schätzung realisiert sein sollte Anteil der Funktionalität, der aktuell realisiert wurde ein Aufdatieren von Schätzungen ist eine nichttriviale Aufgabe, wenn sich Rahmenbedingungen ändern, eine vereinfachte Aufwandsschätzung kann z.b. nur von Schätzbeteiligten aktualisiert werden 157

21 Thesen Jedes Schätzverfahren muss auf firmenindividuelle Gegebenheiten angepasst werden. Ein dokumentiertes und dokumentierendes Schätzverfahren ist immer besser als keines. Aufwandsschätzung soll von Personen durchgeführt werden, die später mit am Projekt verantwortlich arbeiten. Aufwandschätzung muss Risiken berücksichtigen. Aufwandsschätzung kann zur Findung von Risiken beitragen. Die Qualität des Schätzergebnisses hängt von der Akzeptanz des Schätzprozesses ab. Schätzungen müssen während des laufenden Projekts aufdatiert werden. 158

22 Aufwandsschätzung als Teil vom Ganzen Zwischenbericht des Gruppenleiters studieren Folgeschritte des Gruppenleiters diskutie re n Folgeschritte festhalten [kein weiterer Zwischenschritt definiert] Endbericht vom Gruppenleiter studieren [Ergebnis in Ordnung] Be richt an Leitung übergeordnete Notwendigkeit, Prozesse zu dokumentieren, um Folge aktivitäten aus T eilaufgabe ableiten [weiterer Zwischenbericht geplant] [Ergebnis unzufriedenstellend] [keine weiteren Maßnahm en notwendig/sinnvoll] Synergien zu ermöglichen hier findet die eigentliche Bearbeitung statt Projektdokumentation Projektleitung Angebotswesen [größere Überarbeitungen notwendig] Risiko- [kleine Korrekturen Management notwendig] Aufwandsschätzung Korre kturmaßnahmen mit Gruppe nleite r festhalten [kein Konsens über Maßnahm en] Ergebnis mit übergeordneter Leitung diskutieren Ste llungnahme der übergeordne ten Le itung formulieren 159

23 Übung Erstellen sie eine strukturierte Übersicht über die bisher vorgestellten Schätzmethoden, gehen sie dabei auf folgende Themen ein a) Wie wird geschätzt (grobe Beschreibung)? b) Aufwand der Schätzung (im Zusammenhang mit der Projektgröße) c) In welcher Phase kann das Verfahren frühestens im Projekt genutzt werden? d) Notwendige Erfahrung der Schätzer e) Aufdatierbarkeit der Schätzung im Projektverlauf f) Möglichkeit des Aufbaus/ der Nutzung einer firmeninternen Schätzdatenbank g) typische Anwendungsgebiete bzgl. Projektart und Projektgröße h) drei Vorteile des Ansatzes i) drei Nachteile des Ansatzes 160