Software Engineering in der industriellen Praxis - Projektmanagement: Aufwandsschätzung Christian Schmitz - msg ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Software Engineering in der industriellen Praxis Projektmanagement: Aufwandsschätzung Christian Schmitz
Block A: Projektmanagement Geplanter Ablauf 10:00-10:30 Wirtschaftlichkeit von IT Projekten 10:30-11:30 Aufwandsschätzung und Projektkalkulation von Großprojekten 11:30-13:00 Motivation zu agilen Vorgehen / Scrum Basics 13:00-13:30 Mittagspause 13:30-17:00 „SCRUM NEXUS ZOO“ als praktisches Anwendungsbeispiel © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 3
Agenda Software Engineering in der industriellen Praxis Projektmanagement: Aufwandsschätzung 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 5
Agenda Software Engineering in der industriellen Praxis Projektmanagement: Aufwandsschätzung 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 6
Grundlagen der Begriffsdefinition Aufwandsschätzungen beruhen immer auf praktischer Erfahrung und Intuition Aufgaben Aufwände durchführen messen Erfahrung kalibrieren Aufwände (neu) schätzen © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 7
Grundlagen der Begriffsdefinition 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´´ 0 9 18 27 36 45 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´´ 0 3 6 9 12 15 Jahre Experte nach 15 Jahren ☺ © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 8
Grundlagen der Begriffsdefinition Schätzdatenbanken mit FSM (Funktional Size Measurement) überwinden die Grenzen der Intuition bei Großprojekten Projekt 1 Projekt 2 Projekt 3 Schätz-DB Projekt n + 1 … Normierung nötig bzgl. • Größe (FSM) Projekt 100 Komplexität • Umfeld t © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 9
Grundlagen und Begriffsdefinition Das Aufwandsmodell1 strukturiert Projekttätigkeiten nach Aufgabenkategorien → Alle Tätigkeiten in einem Projekt lassen sich eindeutig zuordnen! E0 Ebene 0 Dient der Erhebung von Kennzahlen und Auswertungen E1 Ebene 1 Strukturiert die Aufgabenkategorien aus Ebene 2 nach Themengebieten E2 Ebene 2 Definiert die Aufgabenkategorien eines Projektes. Alle Tätigkeiten eines Projektes fallen in eine dieser Aufgabenkategorien. UM Umsetzung Dient der Gruppierung der zur Umsetzung gehörenden Themengebiete 1. Quelle: Dissertation „Use Case Points 3.0“ von Dr. Stephan Frohnhoff, Universität Paderborn, 2009 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 10
Grundlagen der Begriffsdefinition 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 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. © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 12
Grundlagen der Begriffsdefinition 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 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 13
Grundlagen der Begriffsdefinition Weitere gängige Begriffe … Festpreisrisiko- • Ggf. Zuschlag für Festpreisgarantie als unternehmerische Risiko (falsche Annahmen, Pönalen, Zuschlag Vertragsforderungen die in Schätzung vergessen wurden, …) Gewährleistungs- • Ggf. Rückstellung für Gewährleistungsforderungen nach der Abnahme Aufschlag Nettoaufwand • Aufwand zur unmittelbaren Erstellung der Projektergebnisse, also des Projektinhalts (PI) • Ohne Projektquerschnitt (PQ) oder Projektnebenaufwände (PN) Bruttoaufwand Gesamter regulärer Aufwand zur Abwicklung eines Projekts (= Gesamtaufwand) • 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 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 14
1. Grundlagen der Begriffsdefinition Wir unterscheiden Bottom-Up und Top-Down Schätzverfahren Bottom-Up Top-Down Spezi- fikation 1 ? ? € Um- setzung f (x) # Fenster # Ziegel 2 € © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 15
1. Grundlagen der Begriffsdefinition Bottom up ist die bevorzugte Schätzstrategie Schätzstrategien • Gesamthafte Schätzung des Projektaufwandes mit Hilfe von mathematischen Algorithmen auf Basis der Top-Down funktionalen Anforderungen. Verwendet msg in der Regel nur zur Plausibilisierung. • Aufwände jedes Aufwandspostens werden getrennt ermittelt und zum Gesamtprojektaufwand summiert. Bottom-Up • Im typischen msg Projekt gehen wir Bottom-Up vor. © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 16
1. Grundlagen der Begriffsdefinition Schätzverfahren im Überblick Algorithmische Vergleichs- Kennzahlen- Experten- Methoden methoden methoden Schätzungen COCOMO Multiplikator- Einzelschätzung Function Points Analogiemethode methoden Delphi-Methode Use Case Points Prozentsatzmeth. Schätzklausur / PERT-Methode • Aufwandsermittlung per • Stellt Bezug zu • Ähnlich Analogiemethode, • Greifen wenn möglich auf Formel, in der Regel durchgeführten allerdings braucht man Analogiemethode zurück empirisch nachgewiesen Entwicklungs-projekten her Messdaten abgeschlossener • Erstmalige Schätzung neuer • Basis sind messbare • Keine messbaren Projekte Anforderungen durch Produktgrößen, z. B. LoC, Produktgrößen wie LoC nötig Expertenwissen Anforderungen oder • Nachkalkulationen alter Spezifikation Projekte nötig • Teilw. aufwändig, aber gute Resultate Top-Down Bottom-Up © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 17
Agenda Software Engineering in der industriellen Praxis Projektmanagement: Aufwandsschätzung 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 18
Bottom-Up Schätzung (Expertenschätzung) Experten-Schätzungen stellen ein weit verbreitetes Verfahren für alle Arten von Entwicklungsprojekten dar • 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 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 19
Bottom-Up Schätzung (Expertenschätzung) Experten-Schätzung – Vertiefende Informationen: Gegenüberstellung der Varianten Schätzklausur / Einzelschätzung Delphi-Methode Planning Poker • Ein einziger Experte legt die Schätzwerte • Mehrere Experten führen ihre Schätzung • Mehrere Experten schätzen „online“ im für einen bestimmten Aufwandsposten anonym und ohne Abstimmung Rahmen eines gemeinsamen Workshops. fest. untereinander durch. • Sofortige Zusammenführung von • Zusammenführung der Schätzung durch Aufwänden und Plausibilisierung • Genauigkeit hängt wesentlich von der den PL • Inhaltliche Diskussionen bei großen Erfahrung dieses Experten ab. ggf. in Iterationen bei (großen) Abweichungen Abweichungen. • Hohe Verantwortung für eine Person • Gruppe einigt sich auf Aufwand pro • Einseitige Beurteilung von Aufwänden Schätzposten und Unsicherheiten • Korrektur-Möglichkeiten der Schätzzahl • Risiken werden bewusst ohne Gesichtsverlust • Gleichmäßiger Informationsstand im • Keine Gruppenzwänge Team Pragmatisch aber Besser als Mittelwerte aber ebenfalls Verlässlich aber sehr zeitaufwändig leicht ungenau zeitaufwändig © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 20
Bottom-Up Schätzung (Expertenschätzung) Die Aufwandsschätzung besteht aus mehreren Schritten Tätigkeit Ergebnis • Zerlegung in Aufgaben (Stückliste) • Aufgaben einzeln schätzen Nettoaufwand • mehrere unabhängige Schätzungen + Querschnittsaufwände als %-Erfahrungswerte Bruttoaufwand Bewertung mit kalkulierten Stundensätzen, + FP-Risiko + Gewährleistung Gesamtbudget • Plausibilisieren durch • Projektplan und Mitarbeitergebirge • Verhältnis der Projektphasen Plausibilisiertes Budget • Vergleichsprojekte Soll - / Ist-Vergleich Budgethochrechnung © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 21
Bottom-Up Schätzung (Expertenschätzung) Alles, was Aufwand macht, … • Alle aufwandstragenden Tätigkeiten im Projekt Aufwandsposten • Die Liste aller Aufwandsposten gibt die Stückliste (Schätzposten) • Nicht jeder Aufwandsposten muss 1:1 ein Arbeitsergebnis sein • Aufwandsposten müssen nicht mit den späteren Planungseinheiten übereinstimmen Arbeitsergebnis Deliverable • z. B. Fachkonzept, Dialog, Systemdokumentation Ergebnis Sonstige • z. B. Review durchführen, Projektleitung, Meeting, Kickoff-Veranstaltung Tätigkeiten © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 22
Bottom-Up Schätzung (Expertenschätzung) Wir schätzen Aufwände in Bearbeitertagen (BT) zu 8 h • Ein Aufwand von 1 Bearbeitertag (BT) muss in 8 Planungs- und Schätzungssicht Stunden (!) erbracht werden können – nicht in einem 10-Stunden-Tag (oder 24h-Tag ☺). 1 BT 8 Bh • Wir schätzen Rüstzeiten nicht extra, d.h. in jeder Aufwandszahl sind also auch Zeiten für 1 BW 40 Bh 1 BW = 5 BT Kaffeetrinken, kleinere Pausen, Mails lesen, Schreibtisch aufräumen etc. enthalten 1 BM 160 Bh 1 BM = 20 BT 1 BJ 1600 Bh 1 BJ = 10 BM © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 23
Bottom-Up Schätzung (Expertenschätzung) 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 Grundlage sind in jedem Fall feststehende Anforderungen oder mindestens als Prämissen [Bh, BT] 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: €). X% der Schätzunsicherheit. Aufwandsrisiko Die Schätzunsicherheiten wird nicht bei jedem Aufwandsposten zuschlagen, die Festlegung hängt von [Bh, BT] der Einschätzung des Angebotsverantwortlichen ab. © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 24
Bottom-Up Schätzung (Expertenschätzung) Beispiel: Strukturierung einer Stückliste Strukturierung nach den Requirements des Kunden Abstrakte, projektspezifische Strukturierung des Projektinhalts nach Komponenten & Themen Projektspezifische Detaillierung in einzelne Aufwandsposten (Schätzposten) Aufwandsschätzung in Bearbeitertagen (BT) © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 25
Bottom-Up Schätzung (Expertenschätzung) Beispiel: Projektcontrolling der einzelnen Backlog-Positionen / Program Increments / Sprints • Im Rahmen der Umstellung auf ein agiles Vorgehen wurde die zentrale Steuerung maßgeblich gestärkt („ART-Team“). • Fortschritts- und Budgetcontrolling findet auf Sprint- und PI-Ebene sowie global statt. Eine Reihe von automatisierten Auswertungen liegen dazu schon vor oder sind in Entstehung. Gemessene KPIs umfassen u.a.: • Team-Performance • Einhaltung des Sprint-Scopes und des geplanten Aufwands • Budgetverbrauch, Burn-Down-Charts, regelmäßige Restaufwandschätzungen © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 26
Bottom-Up Schätzung (Expertenschätzung) Zuschläge für Querschnittsaufgaben werden konkret geschätzt oder prozentual ermittelt Querschnittsaufgabe Abschätzung Erfahrungswerte Alle Querschnittsaufgaben Möglichst konkret schätzen in % vom Nettoaufwand Projektleitung Mitarbeiter x Laufzeit 10 - 20 % ab 7 Mitarbeiter ein Vollzeit-PL Chef Design Mitarbeiter x Laufzeit Qualitätssicherung Möglichst Einzelmaßnahmen schätzen 10 - 25 % Software-Entwicklungs-Umgebung, Sehr projektspezifisch: Aufbau und lfd. Support 5 - 25 % Technik getrennt betrachten Anzahl Reisen x durchschn. Reisezeit über die Reisezeiten bis zu 15 % Laufzeit Anzahl Meetings x Teilnehmer x Dauer über die Meetings, Präsentationen etc. bis zu 15 % Laufzeit Team-Training Möglichst Einzelmaßnahmen schätzen © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 27
Bottom-Up Schätzung (Expertenschätzung) Im Kalkulationsschema sind die verschiedenen Anteile des Gesamtaufwands sichtbar Aufgabe Aufwand [BT] Funktion 1 100 Funktion 2 300 Funktion 3 200 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 1.188 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 28
Bottom-Up Schätzung (Expertenschätzung) Zur Ermittlung des Nettoaufwands werden die Schätzposten gezählt und bewertet Typ Einzel Gesamt Kategorie Anzahl Zählbaustein Aufwand Aufwand • leicht 22 2 BT 44 BT • mittel 15 5 BT 75 BT • Klassen • schwer 8 10 BT 80 BT • Einzelfall 1 1 25 BT 25 BT • Einzelfall 2 1 20 BT 20 BT x = • leicht 13 3 BT 39 BT • mittel 25 5 BT 125 BT • Dialoge • schwer 6 8 BT 48 BT • extrem 2 18 BT 36 BT • Batches • Schnittstellen • Tabellen • … © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 29
Bottom-Up Schätzung (Expertenschätzung) Die Kennzahlen des Aufwandsmodells dienen der Plausibilisierung einer Schätzung Kennzahlenplausibilisierung Erfahrungswerte aus Kennzahlen Schätzung Aufw.-Modell Kommentar (~1σ-Bereich) von bis Median SP / PI 0% 8% 28% 19% Detailspezifikation fertig bzw Rest nach Aufwand bis v1.0 KON / UM 13% 9% 25% 17% REA / UM 53% 35% 65% 52% INT / UM 34% 17% 40% 32% INT-BUGFIX / UM 8% 5% 19% 13% PK / PI 45% 15% 40% 28% PK-PL / PI 16% 6% 18% 12% PL & Entwicklungsleitung, daher mehr als normal PK-PM / PI 3% 2% 6% 4% PK-CD / PI 12% 4% 12% 8% PT / PI 17% 3% 10% 6% DevOps sind mit eingeplant (zusätzliche Resource) PN-EIN / PI 1% 2% 7% 4% QS / PI 0% 3% 8% 5% wurde nicht separat geschätzt, sollte aber abgedeckt sein • 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. • Mit der Kennzahlenplausi kann plausilisiert werden, • in der Schätzung alle Aufwandskategorien umfassend abgedeckt wurden. • die Verteilung des Aufwandes entsprechend der Erfahrung aus bisherigen Projekten sinnvoll erscheint. • Die Erfahrungswerte zur prozentualen Verteilung dienen dabei nur als Richtwerte, da jedes Projekt individuell ist. Größere Abweichungen sollten aber zumindest hinterfragt und begründet werden. © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 30
Bottom-Up Schätzung (Expertenschätzung) Als erster Anhaltspunkt für Teamgröße und Projektlaufzeit dient Brooks Faustformel Zeit t Entwicklungsdauer „Der Mann-Monat als Maßstab für den Umfang des Arbeitsaufwandes ist ein gefährlicher und Kommunikativer irreführender Mythos. Der Begriff will uns glauben Anteil machen, Bearbeiter und Monate seien austauschbare Faktoren“ Weniger Arbeits- Mehr Abstimmung Fred Brooks in „Vom Mythos des Mann-Monats“ teilung möglich notwendig Produktiver Anteil (1) Optimale n = Anzahl der Mitarbeiter- Mitarbeiter anzahl Optimale Teamgröße ~ Aufwand in BM © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 31
Bottom-Up Schätzung (Expertenschätzung) Die Aufwandsschätzung wird durch ein Mitarbeitergebirge plausibilisiert • Den Projektablauf mit geschätzter Dauer und Teamgröße skizzieren Anzahl • Fläche ausrechnen, hier: 30 Zeitmonate (ZtM) Mitarbeiter 6 • 1 ZtM = 0,8 BM wegen Feiertagen, Fortbildung, Krankheit, Meetings, etc. • Hier ergibt die Umrechnung von ZtM auf BM: 30 * 0,8 = 24 BM 5 • Passt das zur Aufwandsschätzung? 4 3 2 1 0 Jun Jul Aug Sep Okt Nov Dez © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 32
Bottom-Up Schätzung (Expertenschätzung) 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 Aufwand [BM] (10/12) 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 kumulierter Aufwand 4,2 11 18 27 36 45 55 64 74 82 91 99 103 104 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 33
Bottom-Up Schätzung (Expertenschätzung) In die Budgetierung des Projekts fließen – neben dem Aufwand – weitere Parameter ein Parameter Methode Erfahrungswert Kalkulatorische Konkret oder % von Alle Parameter Vorgaben Bruttoaufwand Stundensatz Festlegung durch Management; nach Qualifikation oder Mischstundensatz Durchschnittliche Stunden / Tag festlegen Bruttoaufwand * Stundensatz 8 - 9 h / Tag Überstunden kalkulieren Reisekosten Anzahl Reisen * durchschn. Kosten bis zu 14 % Festpreis Risikozuschlag 10 - 25 % Gewährleistung 3 - 10 % Anschaffungskosten für Hardware, Software per Nur „Durchreichen“ oder mit sonstige Kosten Einkaufsliste Zuschlag © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 34
Bottom-Up Schätzung (Expertenschätzung) Zusammenfassung der Grundsätze Konkret • Möglichst viele Aufwandsposten werden konkret geschätzt; möglichst wenige durch prozentuale Aufschläge bestimmt. • Zu jedem geschätzten Aufwandsposten wird die Schätzunsicherheit festgehalten. Für jeden Schätzposten wird Schätzunsicherheit 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. © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 35
Agenda Software Engineering in der industriellen Praxis Projektmanagement: Aufwandsschätzung 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 36
Top-Down Schätzung (Use Case Points) Motivation zum Einsatz von Use Case Points • Top-Down Schätzmethode zur schnellen Schätzung von Projekten • Gesamthafte Schätzung des Projektaufwandes mit Hilfe von mathematischen Algorithmen • Schätzung basiert auf funktionale Anforderungen (Use Cases) • Einsatz in der Regel nur zur Plausibilisierung der Expertenschätzung • Ermöglicht aber auch schnelle (grobe) Budgetabschätzungen • Je mehr Schätzungen in einem Umfeld gemacht werden, je genauer kann Methode werden © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 37
Top-Down Schätzung (Use Case Points) Entwicklung der funktionalen Größenmessung De Marco's Object ISO "FSM" Data Points Bang Metric Points Standard DeMarco1982 Sneed1989 Sneed 1994 ISO 1994 Feature 3D Function Metrics for Points Points Objectory Use Case Points UCP 1.0 UCP 2.0 Rational 1999 Capgemini sd&m Full Function COSMIC COSMIC ISO 19761: COSMIC Jones 1986 Boeing 1991 Karner 1993 Points 1.0 FPP 2.0 FPP 2.1 2003 Version 3.0 COSMIC 2007 Function Point Function Point Function Point Function Point Function Point Function Point ISO 20926: Function Point Analysis Analysis Analysis 3.4 Analysis 4.0 Analysis 4.1 Analysis 4.1.1 2003 Analysis 4.2 IBM Albrecht Albrecht IFPUG 1990 IFPUG 1994 IFPUG 1999 IFPUG 2001 IFPUG 2004 1975 1979 1984 ISO 29881: 2008 Mark II FPA Mark II FPA ISO 20968: 1.0 1.3.1 2002 FiSMA ISO 24570: Symons UKSMA 2005 1988 1998 NESMA 1975 1980 1985 1990 1995 2000 2005 2008 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: 228-267. 2001; ergänzt durch S. Frohnhoff, sd&m AG © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 38
Top-Down Schätzung (Use Case Points) Die Use Case Points (UCP) Methode setzt direkt auf einer Use Case basierten Spezifikation auf und ist sehr einfach anzuwenden Kom- Use-Case- Aktoren- Use Case Aktor Typ plexität Gewicht Gewicht Auftrag verwalten hoch 5 Stammdaten Nachbarsystem (API) 2 Kunde verwalten einfach 1 Geschäftspartner Nachbarsystem (Protokoll) 2 Produkt verwalten mittel 3 Händler Benutzer-Interface 3 ... ... ... ... ... ... Σ Use-Case-Gewichte + Σ Aktoren-Gewichte M-Faktor x T-Faktor x A-Faktor = Bereinigte Use Case Points Fragebogen mit Fragebogen mit Use Case Kostenfaktoren Kostenfaktoren Points Produktivitäts- faktor Aufwand über alle Phasen1 ABC Individuelle Analyse Berechnung nach Standard-Metrik Berechnung nach firmeneigener Metrik 1) gemäß Mapping auf Aufwandsmodell (einfach, mittel, komplex) © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 39
Top-Down Schätzung (Use Case Points) 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äfts-prozesse in betrieblichen • Technikstufen, Steuerungssysteme Anwendungen • Stammdaten-Pflegesysteme 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 © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 40
4. Literatur Software Engineering in der industriellen Praxis Projektmanagement: Aufwandsschätzung 1. Grundlagen und Begriffsdefinitionen 2. Bottom-Up Schätzung (Expertenschätzung) 3. Top-Down Schätzung (Use Case Points) 4. Literatur © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 41
Literatur • https://www.msg.group/images/msggroup/services/techrefresh/Disser tation_Use_Case_Points_3.0_Frohnhoff_msg.pdf Suche nach „UCP“ • Balzert, H.: Lehrbuch der Software-Technik, Band 1, Software- Entwicklung. Spektrum Akademischer Verlag, 2. Auflage, 2000. • Siedersleben, J.: “Softwaretechnik - Praxiswissen für Software-Ingenieure” 2. überarbeitete und aktualisierte Auflage, Hanser Verlag, 2003. • 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. 511-526 • Cockburn, A.: “Writing Effective Use Cases”, Addison-Wesley, 2001. • Smith, J.: „The Estimation of Effort Based on Use Cases“, Rational Software, Cupertino, CA.TP-171, October 1999. http://whitepapers.zdnet.co.uk/0,39025945,60071904p- 39000629q,00.htm © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 42
Vielen Dank Christian Schmitz msg systems ag +49 (170) 9241329 Robert-Bürkle-Straße 1 christian.schmitz@msg-gillardon.de 85737 Ismaning +49 89 96101-0 +49 89 96101-1113 info@msg.group value – inspired by people © msg | WS 2020/2021 | Software Engineering in der industriellen Praxis – Block A: Projektmanagement 43
Sie können auch lesen