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 7Grundlagen 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 8Grundlagen 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 9Grundlagen 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 10Grundlagen 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 12Grundlagen 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 13Grundlagen 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 141. 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 151. 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 161. 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 17Agenda 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 19Bottom-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 20Bottom-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 21Bottom-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 22Bottom-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 23Bottom-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 24Bottom-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 25Bottom-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 26Bottom-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 27Bottom-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 28Bottom-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 29Bottom-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 30Bottom-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 31Bottom-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 32Bottom-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 33Bottom-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 34Bottom-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 35Agenda 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 38Top-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 39Top-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 404. 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 42Vielen 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 43Sie können auch lesen
