Thomas Engeroff
Aufwandsschätzung und Projektkalkulation
von Großprojekten
Thomas Engeroff
• Studium der Informatik an der TU Darmstadt
Abschluss mit Schwerpunkt Software Engineering und Nebenfach BWL
• 2001 – 2008: freiberufliche Software Entwicklung & IT Beratung
• 2008 – 2011: bei sd&m als Software-Ingenieur Projektleiter
Abteilung Research: Aufwandsschätzung, insb. Use Case Points (12 Monate)
danach Schwerpunkt Telekomunikation
• seit 2011 bei der der msg systems ag
Project Manager / Berater / Scrum Master
Bereich „Telecommunications & Media“
• Aktuell als Consultant bei der Telekom zur Unterstützung der Projektleitung eines Großprojektes
im Bereich Planungs-/Release-management tätig
Privates
Keine Kinder,
aber… ;) Hobbys: „Kernsanierung“ & Motorrad letzter Urlaub…
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
msg, November 2014 Thomas Engeroff 3
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
msg, November 2014 Thomas Engeroff 4
Aufwandsschätzungen beruhen immer auf
praktischer Erfahrung und Intuition
„Prognosen
sind besonders dann schwierig, wenn
sie sich auf die Zukunft beziehen.“
Aufgaben durchführen
Aufwände messen
Erfahrung kalibrieren Aufwände (neu) schätzen
msg, November 2014 Thomas Engeroff 5
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
Experte nach 3,75 Jahren
Monate
• 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, November 2014 Thomas Engeroff 6
Schätzdatenbanken mit FSM (Funktional Size Measurement)
überwinden die Grenzen der Intuition bei Großprojekten
Projekt 1
Projekt 2
…
t
Schätz-DB
Projekt 100
Projekt 3 Projekt n + 1
Normierung nötig
bzgl.:
• Größe (FSM)
• Komplexität
• Umfeld
msg, November 2014 Thomas Engeroff 7
Der Kontenrahmen strukturiert Aufgaben nach Aufgabenkategorien
(Beispiel: sd&m AG)
Ebene 0, Für Kennzahlen und
Auswertungen
Ebene 1
Ebene 2 Jedes Projekt schätzt
und erfasst seine
Aufwände auf einer
dieser Ebenen. Ab
einer Projektgröße
von 15 BM ist die
Ebene 2 verbindlich.
Darunter kann
beliebig detailliert
werden.
Die Ebene 1 & 2
definiert die
Aufgabenkategorie
PN Projektneben-
aufwände
Projekt
PI Projektinhalt
IB Inbetriebn. SP Spezifikation
SP-IST
IST-Systemanalyse
In Releases
INT Integration REA Realisierung
KON-T Konstruktion der T-Stufen
UM Umsetzung
PQ Projektquerschnitt
PK Projektkoordination PT Projekttechnik
100% = Netto
PK-PL Projektleitung
PK-PM Projektmanagement
PK-CD Chefdesign
PK-QK Qualitätsmanagement
PT-KM Konfigurations-/
Releasemanagement
PT-SEU Software-
Entwicklungsumgebung
PT-TI Technische Infrastruktur
PK-MTG Meetings
KON Konstruktion
KON-A Konstruktion der A-Stufen
KON-MIG
Konzeption v. Migration etc.
KON-DB Konstruktion DB-Design &
Datentypen
KON-QS QS in der Konstruktion
SP-ALLG Allg. Spezifizikations-
aufwände
SP-THEMA Spezifikation von Themen
und Daten
SP-QS QS auf Spezifikation
REA-DB
Aufbau und Pflege DB
REA-MIG Migration &
Erstbefüllungen
REA-T Realisierung T-Stufen
REA-QS QS in der REA
REA-A Realisierung A-Stufen
INT-VBD Verbundtest
INT-NFKT Nicht-Funktionale Tests
INT-BUGFIX Fehlerbehebung
INT-SYS (Sub-) Systemtest
INT-TVO alle Testvorbereitungen
INT-QS Durchführung QS
IB-ABN Abnahme
IB-EIN Einführung & Betrieb
IB-DOK Dokumentationen
IB-SCHUL Schulungen
IB-QS Durchführung QS
KON-ALLG Allg. Konstruktionsaufwand
CR
Change Requests
BERAT
Beratung
SP-NACH Nacharbeiten (FK V1.1)
PN PN-EIN Einarbeitung, Teamaufbau PN-STORT Mehrere Standorte PN-REISE Reisezeiten
msg, November 2014 Thomas Engeroff 8
PN Projektneben -
aufw ä nde
Projekt
PI Projektinhalt
IB Inbetriebn . SP Spezifikation
In Releases
INT Integration REA Realisierung
UM Umsetzung
PQ Projektquerschnitt
PK Projektkoordination PT Projekttechnik
100% = Netto
PK - PL Projektleitung
PK - PM Projektmanagement
PK - CD Chefdesign
PK - QK Qualit ä tsmanagement
PT - KM Konfigurations - / Releasemanagement
PT - SEU Software - Entwicklungsumgebung
PT - TI Technische Infrastruktur
PK - MTG Meetings
KON Konstruktion
CR BERAT
SP - IST IST - Systemanalyse
KON - T Konstruktion der T - Stufen
KON - A Konstruktion der A - Stufen
KON - MIG Konzeption v. Migration etc.
KON - DB Konstruktion DB - Design & Datentypen
KON - QS QS in der Konstruktion
SP - ALLG Allg. Spezifizikations - aufw ä nde
SP - THEMA Spezifikation von Themen und Daten
SP - QS QS auf Spezifikation
REA - DB Aufbau und Pflege DB
REA - MIG Migration & Erstbef ü llungen
REA - T Realisierung T - Stufen
REA - QS QS in der REA
REA - A Realisierung A - Stufen
INT - VBD Verbundtest
INT - NFKT Nicht - Funktionale Tests
INT - BUGFIX Fehlerbehebung
INT - SYS (Sub - ) Systemtest
INT - TVO alle Testvorbereitungen
INT - QS Durchf ü hrung QS
IB - ABN Abnahme
IB - EIN Einf ü hrung & Betrieb
IB - DOK Dokumentationen
IB - SCHUL Schulungen
IB - QS Durchf ü hrung QS
KON - ALLG Allg. Konstruktionsaufwand
SP - NACH Nacharbeiten (FK V1.1)
PN PN - EIN Einarbeitung, Teamaufbau PN - STORT Mehrere Standorte PN - REISE Reisezeiten
msg, November 2014 Thomas Engeroff 9
Exkurs: Wo erfassen wir folgende Aufwände / Tätigkeiten?
Im aktuellen Projekt bzw. grundsätzlich?
• Phase IT-Konzept: Teammeeting (Statusrunde) 2 Std.
• Phase Fachkonzept: Teammeeting: Abstimmung Dialoglayout 30 min.
• Rea-Phase: Mitarbeiter findet Fehler in Modul x nicht. PL und MA suchen gemeinsam den Fehler. 4 Std. Wohin bucht der MA? Wohin der PL?
msg, November 2014 Thomas Engeroff 10
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 Aufwandskategorien und 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, November 2014 Thomas Engeroff 11
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, November 2014 Thomas Engeroff 12
Weitere gängige Begriffe …
Bruttoaufwand
(= Gesamtaufwand)
Gesamter regulärer Aufwand zur Abwicklung eines Projekts
• 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
Nettoaufwand
• Aufwand zur unmittelbaren Erstellung der Projektergebnisse, also des
Projektinhalts (PI)
• ohne Projektquerschnitt (PQ) oder Projektnebenaufwände (PN)
Festpreisrisiko-
Zuschlag
ggf. Zuschlag für Festpreisgarantie als unternehmerische Risiko
(falsche Annahmen, Pönalen, Vertragsforderungen die in Schätzung
vergessen wurden, …)
Gewährleistungs-
Aufschlag
ggf. Rückstellung für Gewährleistungsforderungen nach der
Abnahme
msg, November 2014 Thomas Engeroff 14
Spezi-
fikation
Um-
setzung
1
2
# Fenster
# Ziegel
€
Bottom-Up
? ?
f (x)
FSM
€
Top-Down
Wir unterscheiden Bottom-Up undTop-Down Schätzverfahren
msg, November 2014 Thomas Engeroff 15
Bottom up ist die bevorzugte Schätzstrategie
Schätzstrategien
Top-Down
Bottom-Up
Gesamthafte Schätzung des Projektaufwandes mit Hilfe von mathematischen
Algorithmen auf Basis der funktionalen Anforderungen. Verwendet msg in der
Regel nur zur Plausibilisierung.
Aufwände jedes Aufwandspostens werden getrennt ermittelt und zum
Gesamtprojektaufwand summiert.
Im typischen msg Projekt gehen wir Bottom-Up vor.
msg, November 2014 Thomas Engeroff 16
Schätzverfahren im Überblick
• Aufwandsermittlung
per Formel, in der
Regel empirisch
nachgewiesen
• Basis sind messbare
Produktgrößen, z. B.
LoC, Anforderungen
oder Spezifikation
• Teilw. aufwändig, aber
gute Resultate
• Stellt Bezug zu
durchgeführten
Entwicklungs-
projekten her
• Keine messbaren
Produktgrößen wie
LoC nötig
• Nachkalkulationen
alter Projekte nötig
• Ähnlich
Analogiemethode,
allerdings braucht
man Messdaten
abgeschlossener
Projekte
• Greifen wenn möglich
auf Analogiemethode
zurück
• Erstmalige Schätzung
neuer Anforderungen
durch Expertenwissen
Algorithmische Methoden
Vergleichs- methoden
Kennzahlen- methoden
Experten- Schätzungen
Top-Down Bottom-Up
COCOMO
Function Points
Use Case Points
Analogiemethode
Multiplikator-
methoden
Prozentsatzmeth.
Einzelschätzung
Delphi-Methode
Schätzklausur
msg, November 2014 Thomas Engeroff 17
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
msg, November 2014 Thomas Engeroff 18
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
„Prognosen
sind besonders dann schwierig, wenn
sie sich auf die Zukunft beziehen.“
msg, November 2014 Thomas Engeroff 19
Experten-Schätzung –
Vertiefende Informationen: Gegenüberstellung der Varianten
• Ein einziger Experte legt die
Schätzwerte für einen
bestimmten Aufwandsposten
fest.
• Genauigkeit hängt wesentlich
von der Erfahrung dieses
Experten ab.
• Hohe Verantwortung für eine
Person
• Einseitige Beurteilung von
Aufwänden und
Unsicherheiten
Einzelschätzung
Pragmatisch aber
leicht ungenau
• Mehrere Experten führen ihre
Schätzung anonym und ohne
Abstimmung untereinander
durch.
• Zusammenführung der
Schätzung durch den PL
ggf. in Iterationen bei
(großen) Abweichungen.
• Korrektur-Möglichkeiten der
Schätzzahl ohne
Gesichtsverlust
• Keine Gruppenzwänge
Delphi-Methode
Verlässlich aber sehr
zeitaufwändig
• Mehrere Experten schätzen
„online“ im Rahmen eines
gemeinsamen Workshops.
• Sofortige Zusammenführung
von Aufwänden und
Plausibilisierung
• Inhaltliche Diskussionen bei
großen Abweichungen
• Gruppe einigt sich auf
Aufwand pro Schätzposten
• Risiken werden bewusst
• Gleichmäßiger
Informationsstand im Team
Schätzklausur
Besser als Mittelwerte aber
ebenfalls zeitaufwändig
msg, November 2014 Thomas Engeroff 20
Die Aufwandsschätzung besteht aus mehreren Schritten
Tätigkeit Ergebnis
Nettoaufwand
Bruttoaufwand
Gesamtbudget
Plausibilisiertes Budget
Budgethochrechnung
• Zerlegung in Aufgaben (Stückliste) • Aufgaben einzeln schätzen
• mehrere unabhängige Schätzungen
+ Querschnittsaufwände als %-Erfahrungswerte
Bewertung mit kalkulierten Stundensätzen, + FP-Risiko + Gewährleistung
• Plausibilisieren durch • Projektplan und Mitarbeitergebirge
• Verhältnis der Projektphasen • Vergleichsprojekte
Soll - / Ist-Vergleich
msg, November 2014 Thomas Engeroff 21
Alles, was Aufwand macht, …
Aufwandsposten
(Schätzposten)
Arbeitsergebnis Deliverable Ergebnis
sonstige Tätigkeiten
z. B. Review durchführen, Projektleitung, Meeting, Kickoff-Veranstaltung
• Alle aufwandstragenden Tätigkeiten im Projekt
• Die Liste aller Aufwandsposten gibt die Stückliste
• Nicht jeder Aufwandsposten muss 1:1 ein Arbeitsergebnis sein
• Aufwandsposten müssen nicht mit den späteren Planungseinheiten übereinstimmen
z. B. Fachkonzept, Dialog, Systemdokumentation
msg, November 2014 Thomas Engeroff 22
Wir schätzen Aufwände in Bearbeitertagen (BT) zu 8 h
Planungs- und Schätzungssicht
1 BT 8 Bh
1 BW 1 BW = 5 BT
1 BM 1 BM = 20 BT
1 BJ = 10 BM 1 BJ
• Ein Aufwand von 1 Bearbeitertag (BT)
muss in 8 Stunden (!) erbracht werden
können – nicht in einem 10-Stunden-
Tag
(oder 24h-Tag ).
• Wir schätzen Rüstzeiten nicht extra,
d.h. in jeder Aufwandszahl sind also
auch Zeiten für Kaffeetrinken, kleinere
Pausen, Mails lesen, Schreibtisch
aufräumen etc. enthalten
40 Bh
160 Bh
1600 Bh
msg, November 2014 Thomas Engeroff 23
Für jeden Schätzposten wird Aufwand und Schätzunsicherheit
ermittelt
Schätzung
[Bh, BT]
Gesamtaufwand := Schätzung + Aufwandsrisiko
Vorgehen zur Ermittlung des Aufwands und des Schätzrisikos unter
Zuhilfenahme eines Schätzverfahrens.
Grundlage sind in jedem Fall feststehende Anforderungen oder
mindestens als Prämissen 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: €).
Aufwandsrisiko
[Bh, BT]
X% der Schätzunsicherheit.
Die Schätzunsicherheiten wird nicht bei jedem Aufwandsposten
zugeschlagen, die Festlegung hängt von der Einschätzung des
Angebotsverantwortlichen ab.
msg, November 2014 Thomas Engeroff 24
Beispiel: Strukturierung einer Stückliste
Konto Thema/
Komponente
Schätzposten (Arbeitspaket/Aktivität) Schätzung
SP
SP-THEMA Register Visa Spezifikation der Komponente Visa-Auskunft
(Grundlage sind die bestehenden 4 AWF der Masterspez.)
12,0
SP-THEMA Register Visa Spezifikation der Komponente Visa-Meldung
(Wahrscheinlich 5 AWF in der neuen Spez.)
30,0
SP-THEMA Register Visa Spezifikation der Protokollierung durch das Register
(Wahrscheinlich ein AWF zum Protokollieren und einen
zum Abfragen, Exportschnittstelle)
8,0
SP-THEMA Register Visa Spezifikation der Komponenten Administration und
Datenpflege
5,0
SP-THEMA Register Visa Spezifikation der Komponente Fristenkontrolle 10,0
SP-THEMA Register Visa Spezifikation der Komponente Bereitstellung Analyse
(Schnittstellenbeschreibung oder Druckausgabe für
Rohdatenexport, AWF zum Exportieren, ggf. AWF/Enitäten
zum Zählen von Kennzahlen)
9,0
SP-THEMA Register Visa Spezifikation Datenmodells für das Register Visa 10,0
SP-THEMA Register Visa Dokumentenquerschnitt mit Einleitung, Referenzen, NFAs
usw.
4,0
SP-THEMA Visa-Regelwerk Überarbeitung bestehende Regeln (24) 12,0
SP-THEMA Visa-Regelwerk Identifikation und Ergänzung fehlende Regeln 5,0
SP-THEMA Visa-Regelwerk Berechtigungen prüfen und ergänzen 5,0
SP-THEMA Visa-Regelwerk Schnittstelle Regelkomponente definieren 3,0
Strukturierung nach den
Aufgabenkategorien des
Aufwandsmodells
Projektspezifische Detaillierung
in einzelne Aufwandsposten
(Schätzposten)
Abstrakte, projektspezifische
Strukturierung des Projektinhalts
nach Komponenten & Themen
Aufwandsschätzung in
Bearbeitertagen (BT)
msg, November 2014 Thomas Engeroff 25
In der Stückliste werden alle Schätzposten in BT erfasst und
bereits einer Aufgabenkategorie gemäß Kontenrahmen zugeordnet
Aufgabenkategorie Thema/Komponente Aufwandsposten Schätzung Aufwandsrisiko Gesamtaufwand
SP-ALLG Initialisierung: fachliche Workshops, Themenabgrenzung, Spez-Pattern, etc. 4 1 5
SP-ALLG Einleitung, Glossar, Überblick, Redaktion etc. 3 1 4
SP-THEMA Stammdatendialoge Spez Dialog: Pflege Skilehrer 1 0,5 1,5
SP-THEMA Stammdatendialoge Spez Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 1 0,5 1,5
SP-THEMA Stammdatendialoge Spez Dialog: Pflege Stammdaten Skischule 1 0,5 1,5
SP-THEMA Kursplanung & -abwicklung Spez Dialog: Verfügbarkeit Skilehrer 2 0,5 2,5
SP-THEMA Kursplanung & -abwicklung Spez Dialog: Skikurse anlegen/pflegen 2 0,5 2,5
SP-THEMA Kursplanung & -abwicklung Spez Dialog: Kursbuchung 4 1 5
SP-THEMA Kursplanung & -abwicklung Spez Dialog: Fakturierung 2 1 3
SP-THEMA Druckausgaben Rechnung 1 0,5 1,5
SP-THEMA Druckausgaben Übersicht über alle Kurse 1 0,5 1,5
SP-THEMA Druckausgaben Übersicht zu einem Kurs 1 0,5 1,5
SP-NACH Erstellen Version 1.1 2 1 3
SP-QS Qualitätssicherung Spez 2 1 3
KON-ALLG Vorbereitung IT-Konzept: Nutzungskonzept/EHB für Access, Pattern IT-Konzept, 5 2 7
KON-A Stammdatendialoge Kon Dialog: Pflege Skilehrer 0,5 0,5 1
KON-A Stammdatendialoge Kon Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 0,5 0,5 1
KON-A Stammdatendialoge Kon Dialog: Pflege Stammdaten Skischule 0,5 0,5 1
KON-A Kursplanung & -abwicklung Kon Dialog: Verfügbarkeit Skilehrer 0,5 0,5 1
KON-A Kursplanung & -abwicklung Kon Dialog: Skikurse anlegen/pflegen 1 0,5 1,5
KON-A Kursplanung & -abwicklung Kon Dialog: Kursbuchung 1 0,5 1,5
KON-A Kursplanung & -abwicklung Kon Dialog: Fakturierung 1 0,5 1,5
KON-A Druckausgaben Rechnung 0,5 0,5 1
KON-A Druckausgaben Übersicht über alle Kurse 0,5 0,5 1
KON-A Druckausgaben Übersicht zu einem Kurs 0,5 0,5 1
KON-QS Qualitätssicherung IT-Konzept 1 0 1
REA-A Stammdatendialoge Pflege Skilehrer 1 1 2
REA-A Stammdatendialoge Pflege Kurstypen (Art, Übungen, Preise etc.) 3 1 4
REA-A Stammdatendialoge Pflege Stammdaten Skischule 1 1 2
REA-A Kursplanung & -abwicklung Verfügbarkeit Skilehrer (Planung) 2 0,5 2,5
REA-A Kursplanung & -abwicklung Skikurse anlegen/pflegen (Planung) 3 0,5 3,5
REA-A Kursplanung & -abwicklung Kursbuchung 7 2 9
REA-A Kursplanung & -abwicklung Fakturierung 4 1 5
REA-A Druckausgaben Rechnung in Word 4 1 5
REA-A Druckausgaben Übersicht über alle Kurse (Access Bericht) 1,5 0,5 2
REA-A Druckausgaben Übersicht zu einem Kurs (Access Bericht) 1,5 0,5 2
REA-DB Aufbau DB 3 1 4
REA-QS Codereviews 2 2
INT-TVO Testfälle & Testkonzept erstellen 5 1 6
msg, November 2014 Thomas Engeroff 26
Zuschläge für Querschnittsaufgaben werden konkret geschätzt
oder prozentual ermittelt
Querschnittsaufgabe Abschätzung
möglichst konkret schätzen
Mitarbeiter x Laufzeit ab 7 Mitarbeiter ein Vollzeit-PL
Mitarbeiter x Laufzeit
möglichst Einzelmaßnahmen schätzen
sehr projektspezifisch: Aufbau und lfd. Support getrennt betrachten
Alle Querschnittsaufgaben
Projektleitung
Chef Design
Qualitätssicherung
Software-Entwicklungs-Umgebung, Technik
in % vom Nettoaufwand
10 - 20 %
10 - 25 %
5 - 25 %
Anzahl Reisen x durchschn. Reisezeit über die Laufzeit
Reisezeiten bis zu 15 %
Anzahl Meetings x Teilnehmer x Dauer über die Laufzeit
Meetings, Präsentationen etc. bis zu 15 %
möglichst Einzelmaßnahmen schätzen Team-Training
Erfahrungswerte
msg, November 2014 Thomas Engeroff 27
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, November 2014 Thomas Engeroff 28
Zur Ermittlung des Nettoaufwands werden
die Schätzposten gezählt und bewertet
• leicht
• mittel
• schwer
• Einzelfall 1
• Einzelfall 2
• Klassen
Kategorie
2 BT
5 BT
10 BT
25 BT
20 BT
Einzel Aufwand Typ Zählbaustein
44 BT
75 BT
80 BT
25 BT
20 BT
Gesamt Aufwand
22
15
8
1
1
Anzahl
x = • leicht
• mittel
• schwer
• extrem
• Dialoge
3 BT
5 BT
8 BT
18 BT
39 BT
125 BT
48 BT
36 BT
13
25
6
2
• Batches
• Schnittstellen
• Tabellen
• …
msg, November 2014 Thomas Engeroff 29
Verwendete Grundbegriffe der Statistik
• Jede Verteilung von unabhängigen Zufallsvariablen entwickelt sich bei genügend
großer Stichprobenanzahl in Richtung einer Normalverteilung (Gauß-Glocke).
Sie ist typisch für Messungen, die sich aus sehr vielen verschiedenen Einflüssen
zusammensetzen, die man nicht mehr trennen kann. Wir gehen bei der Analyse
der Kennzahlen des Aufwandsmodells vereinfacht von einer Normalverteilung der
Erfahrungswerte aus.
• Der Erwartungs- oder Mittelwert μ einer Normalverteilung ist der Wert mit der
höchsten relativen Wahrscheinlichkeit f. Je weiter man sich vom Mittelwert μ
entfernt, desto unwahrscheinlicher wird dieser Wert in der Praxis zu beobachten
sein.
• Die Standardabweichung σ ist ein Maß für die Streuung um den Mittelwert, sie
beschreibt die Breite der Normalverteilung. 68 % aller Messwerte haben eine
Abweichung von höchstens σ vom Mittelwert, liegen also im 1σ-Bereich um den
Mittelwert.
• Median bezeichnet eine Grenze zwischen zwei Hälften. In der Statistik halbiert
der Median eine Stichprobe. Gegenüber dem Mittelwert hat der Median den
Vorteil, robuster gegenüber Ausreißern zu sein, das gilt insbesondere bei einer
geringen Stichprobenanzahl. In einer echten Normalverteilung sind beide Werte
identisch.
• Die Konfidenz κ ist in ein Maß für die Güte/Präzision des Mittelwerts. Die
Konfidenz wird anhand einer vorgegebenen Wahrscheinlichkeit (1-α) berechnet.
Das Konfidenzintervall um den Mittelwert μ± κ gibt dann den Bereich an, in dem
sich der Mittelwert mit dieser Wahrscheinlichkeit befindet. Ein breites
Konfidenzintervall weißt auf eine zu geringe Stichprobenanzahl hin.
• In der Auswertung des Aufwandsmodells verlangen wir eine Konfidenz von mindestens 5% für das 90%-Konfidenzintervall (Vertrauensintervall mit α = 0,1). Damit legen wir ein Mindestmaß für die Schärfe und Belastbarkeit des Mittelwerts und damit auch des Medians fest.
msg, November 2014 Thomas Engeroff 31
Die Kennzahlen des Aufwandsmodells
dienen der Plausibilisierung einer Schätzung
• 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.
• Im Angebotsprofil wird in der Kennzahlenplausi die Schätzung automatisch neben die Erfahrungswerte aus dem Aufwandsmodell der passenden Projektklasse gehalten. Die Kennzahlenplausi unterstützt so die kritische Reflexion der Schätzung.
Projektklasse:
von bis Median
SP / PI 23% 8% 28% 18%
KON / UM 29% 9% 25% 17%
REA / UM 46% 35% 65% 53%
INT / UM 25% 18% 40% 32%
INT-BUGFIX / UM 10% 5% 19% 13%
PK / PI 31% 15% 40% 28%
PL / PI 13% 6% 18% 12%
PM / PI 5% 2% 7% 4%
CD / PI 10% 4% 11% 7%
PT / PI 11% 3% 10% 6%
EIN / PI 3% 2% 7% 4%
QS / PI 3% 2% 7% 5%
<Bitte AKQA-Bezeichnung in 0-Übersicht eintragen>
Kommentar
<bitte Statusdatum in 0-Übersicht pflegen>
alle (Durchschnitt über alle sd&m-Projekte)
(~1σ-Bereich)Kennzahlen Schätzung
Kennzahlenplausibilisierung
Erfahrungswerte aus
Aufw.-Modell
msg, November 2014 Thomas Engeroff 32
Als erster Anhaltspunkt für Teamgröße
und Projektlaufzeit dient Brooks Faustformel
n = Anzahl der
Mitarbeiter
Optimale
Mitarbeiter-
anzahl
Entwicklungsdauer
Kommunikativer
Anteil
Produktiver Anteil (1)
Mehr Abstimmung
notwendig
Weniger Arbeits-
teilung möglich
Mini-
male
Dauer
Optimale Teamgröße ~ Aufwand in BM
Zeit t
„Der Mann-Monat als Maßstab für den Umfang
des Arbeitsaufwandes ist ein gefährlicher und
irreführender Mythos. Der Begriff will uns
glauben machen, Bearbeiter und Monate seien
austauschbare Faktoren“
Fred Brooks in „Vom Mythos des Mann-Monats“
msg, November 2014 Thomas Engeroff 34
Die Aufwandsschätzung wird durch ein Mitarbeitergebirge
plausibilisiert
• Den Projektablauf mit geschätzter
Dauer und Teamgröße skizzieren
• Fläche ausrechnen
hier: 30 Zeitmonate (ZtM)
• 1 ZtM = 0,8 BM wegen Feiertagen,
Fortbildung, Krankheit, Meetings, etc.
• Hier ergibt die Umrechnung von ZtM auf BM:
30 * 0,8 = 24 BM
• Passt das zur Aufwandsschätzung? Anzahl
Mitarbeiter
0
1
2
3
4
5
6
Jun Jul Aug Sep Okt Nov Dez
msg, November 2014 Thomas Engeroff 35
Aus dem Mitarbeitergebirge und dem Gesamtaufwand kann
die Projektdauer ermittelt werden
Anzahl MA
0
2
4
6
8
10
12
Anzahl MA 5 8 9 10 11 11 11 11 11 10 10 10 5 2
M J J A S O N D J F M A M J
Aufwand [BM] (10/12)
kumulierter Aufwand
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
4,2 11 18 27 36 45 55 64 74 82 91 99 103 104
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.
msg, November 2014 Thomas Engeroff 36
In die Budgetierung des Projekts fließen – neben dem Aufwand –
weitere Parameter ein
Parameter Methode
Festlegung durch Management; nach Qualifikation oder
Mischstundensatz
durchschn. Stunden / Tag festlegen Überstunden kalkulieren
Anzahl Reisen * durchschn. Kosten
Stundensatz
Bruttoaufwand * Stundensatz
Reisekosten
Festpreis Risikozuschlag
Gewährleistung
Erfahrungswert
8 - 9 h / Tag
bis zu 14 %
10 - 25 %
3 - 10 %
Anschaffungskosten für Hardware, Software per Einkaufsliste
sonstige Kosten Nur „Durchreichen“ oder
mit Zuschlag
kalkulatorische Vorgaben alle Parameter Konkret oder % von
Bruttoaufwand
msg, November 2014 Thomas Engeroff 37
Zusammenfassung der Grundsätze
• Konkret
Möglichst viele Aufwandsposten werden konkret geschätzt; möglichst wenige durch
prozentuale Aufschläge bestimmt.
• Schätzunsicherheit
Zu jedem geschätzten Aufwandsposten wird die Schätzunsicherheit festgehalten. Für
jeden Schätzposten wird 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, November 2014 Thomas Engeroff 38
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
msg, November 2014 Thomas Engeroff 39
Die Top-Down Schätzung basiert auf der Messung von funktionaler
Größe (FSM) der fachlichen Anforderungen
• Gesamthafte Schätzung des Projektaufwandes mit Hilfe von mathematischen Algorithmen auf Basis der
funktionalen Anforderungen
• Annahme: Vergleichbarkeit des Projektaufwands bei gleichem funktionalem Umfang
• Funktionale Größe der Anforderungen werden in „Punkten“ (Points) ausgedrückt
1 2
Spezifikation Umsetzung BzA
• funktionale Anforderungen
• nicht funktionale Anforderungen
Top-Down Schätzung
msg, November 2014 Thomas Engeroff 40
Entwicklung der funktionalen Größenmessung
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
DeMarco1982 Sneed1989 Sneed1994 ISO 1994
Jones 1986
IFPUG 1999 IFPUG 2001IBM
1975
Albrecht
1979
IFPUG 1994IFPUG 1990
Boeing 1991
Rational 1999
1995 20001975 1980 1985 1990
Capgemini sd&m
Function Point Analysis
Function Point Analysis
Function Point Analysis 3.4
Function Point Analysis 4.0
Function Point Analysis 4.1
Function Point Analysis 4.1.1
Mark II FPA1.0
Mark II FPA1.3.1
De Marco'sBang Metric
Data PointsObjectPoints
ISO "FSM"Standard
FeaturePoints
3D FunctionPoints
Metrics forObjectory
Use Case Points
Full FunctionPoints 1.0
COSMICFPP 2.0
COSMICFPP 2.1
COSMICVersion 3.0
ISO 19761:2003
ISO 20926:2003
2005 2008
COSMIC 2007
Albrecht
1984
UCP 1.0 UCP 2.0
Function Point Analysis 4.2
Symons
1988
UKSMA
1998
Karner1993
ISO 20968:2002
ISO 24570:2005
NESMA
ISO 29881:2008
FiSMA
IFPUG 2004
msg, November 2014 Thomas Engeroff 41
Übersicht der wichtigsten FSM-Methoden
(= Functional Size Measurement)
Entstehungsjahr Methode ISO/IEC Charakterisierung
1979 Albrecht FPA
(=Function Point
Analysis)
# externer Eingaben
# externer Ausgaben
# externer Anfragen
# externer Dateien
# internen Dateien
1988 IFPUG FPA
(=International Function
Point User Group)
20926:2003
Aktuell: IFPUG 4.2
User oriented: #In, #Out
1999 COSMIC FFP
(=COmmon Software
Measurement
Consortium – Full
Function Point)
19761: 2003
Aktuell: COSMIC-
FFP 2.2
Transaction oriented: #Entry,
#Exit, #Read, #Write,
1993 =>1999 UCP
(=Use Case Points)
#Use Cases
www.IFPUG.org
www.lrgl.uqam.ca
Use Case Points (UCP) sind ein vergleichsweise junger
Ansatz aus dem Rational-Umfeld mit Einsatz in der Praxis
Gustav Karner
• Entwickelte UCP unter Betreuung von Ivar Jacobsen bei Objectory AB (später von Rational akquiriert)
• “Metrics for Objectory”. Diploma thesis, University of Linköping, Sweden. No. LiTHIDA-Ex-9344:21. December 1993
John Smith
• “The Estimation of Effort Based on Use Cases”. Rational Software. Cupertino, CA.TP-171. October 1999
• Bestandteil des „Rational Unified Process“ (RUP)
Dokumentierte Praxiserfahrungen
• von Rational, Sun, IBM, Capgemini, msg, ...
Neueste Werkzeuge zur UML-Modellierung integrieren UCP-Tools
• Bsp.: Sparx Enterprise Architect (Mid-Price-Tool)
• Ein Excel-Sheet reicht aber völlig aus ...
msg, November 2014 Thomas Engeroff 43
Die Use Case Points (UCP) Methode setzt direkt auf einer Use Case
basierten Spezifikation auf und ist sehr einfach anzuwenden
ABC Individuelle Analyse Berechnung nach Standard-Metrik (einfach, mittel, komplex)
Berechnung nach firmeneigener Metrik
Σ Aktoren-Gewichte
= Bereinigte Use Case Points
Aufwand über alle Phasen1
Σ Use-Case-Gewichte +
...
10
5
15
Use-Case-
Gewicht
...
15
5
10
Aktoren-
Gewicht
1) gemäß Mapping auf Aufwandsmodell
x M-Faktor
Fragebogen mit Kostenfaktoren
x T-Faktor
Fragebogen mit Kostenfaktoren
... ...
mittel Produkt verwalten
einfach Kunde verwalten
hoch Auftrag verwalten
Kom-
plexität Use Case
Nachbarsystem (Protokoll) Geschäftspartner
... ...
Benutzer-Interface Händler
Nachbarsystem (API) Stammdaten
Typ Aktor
Produktivitäts-
faktor
A-Faktor
Use Case Points
msg, November 2014 Thomas Engeroff 45
Die erweiterte UCP-Methode (UCP 2.0)
reduziert die Schätzvarianz auf unter 20%
UCP-Methode
(nach Karner)
Verbesserte Methode
UCP 2.0
Projekt
Ist-
Aufwand
[h] UUCP
Aufwand
geschätzt
[h]
Abwei-
chung A-Faktor T-Faktor M-Faktor
Aufwand
geschätzt
[h]
Abwei-
chung
Auto 1 4.824 227 6.569 36% 259 0,97 1,14 4.978 3%
Auto 2 7.894 327 9.869 25% 367 1,01 1,36 8.746 11%
Auto 3 7.069 177 5.366 -24% 253 1,02 1,49 6.643 -6%
Bekleidung 728 50 854 17% 70 0,87 0,77 811 11%
Finanz 1 7.825 141 5.208 -33% 205 1,06 2,13 8.012 2%
Finanz 2 3.680 124 3.730 1% 160 1,03 1,14 3.269 -11%
Finanz 3 2.992 71 1.728 -42% 115 0,89 1,49 2.628 -12%
Industrie 1 55.592 1.717 53.702 -3% 1.917 1,05 1,94 67.739 22%
Industrie 2 7.368 221 6.221 -16% 261 1,05 1,14 5.440 -26%
Logistik 1 2.567 61 1.874 -27% 125 1,14 1,04 2.566 0%
Logistik 2 7.250 268 8.234 14% 300 1,14 1,04 6.157 -15%
Logistik 3 944 73 747 -21% 105 0,68 0,81 1.001 6%
Logistik 4 5.362 231 6.617 23% 295 0,96 0,93 4.575 -15%
Logistik 5 2.936 201 5.796 97% 241 0,97 0,74 2.981 2%
Public 1 4.804 182 5.624 17% 198 1,04 1,53 5.463 14%
TelCo 1 65.000 1.395 45.905 -29% 1.503 1,17 2,00 60.638 -7%
TelCo 2 2.456 170 2.088 -15% 210 0,94 0,81 2.748 12%
TelCo 3 2.432 131 1.939 -20% 195 1,04 0,76 2.660 9%
Standardabweichung ± 34% ± 13%
Quelle: sd&m AG, 2007
msg, November 2014 Thomas Engeroff 46
Die UCP-Methode wird bei der msg zur Plausibilisierung
der Expertenschätzung und bei Nachkalkulationen eingesetzt
Abschluss Projektdurchführung Initialisierung Angebot
Budgetierung/
Ausschreibung
1 2
Auftraggeber
Auftragnehmer
Projektabschluss
• Zur Angebotsfreigabe wird die Expertenschätzung
mit der UCP-Schätzung verglichen
• Basis der Schätzung ist eine Grobspezifikation bzw.
Pflichtenheft, das Format ist variabel, aber Use-
Case-basiert
• Zum Projektende wird eine Nachkalkulation
durchgeführt. Der Ist-Aufwand wird mit der
UCP-Schätzung verglichen
• Basis der Nachkalkulation ist die Spezifikation
(Stückliste der Realisierung)
2 1 Angebotsfreigabe
msg, November 2014 Thomas Engeroff 47
Die UCP-Methode setzt auf einer Grobspezifikation auf und
schätzt die Phasen Feinspezifikation und Umsetzung ab
PN Projektnebenaufwände
Projekt
PI Projektinhalt
IB Inbetriebnahme SP Spezifikation
SP - IST IST - Analyse • Analyse von Ist - Systemen
• Analyse von Ist - Prozessen
ggf. in Releases
INT Integration REA Realisierung
KON - T Konstruktion der T - Stufen
• Konstruktion der T - Stufen z. B. Tracing, Logging , Drucken,
technische Frameworks…
• Schreiben zentrales IT - Konzept
• Einarbeiten von Review - Anmerkungen
UM Umsetzung
PQ Projektquerschnitt 25 - 60% PI
PK Projektkoordination 20 - 50% PI PT Projekttechnik 5 - 15% PI
100% = Netto
0 - 10% PI
PK - PL Projektleitung & Teilprojektleitung
• Jede Teamführung (auch von Test - Teams)
• Planung und Controlling
• Risikomanagement
• Abstimmung Parallelprojekte
PK - PM Projektmanagement
• Kunden - und Risikomanagement
• Gremienarbeit, Erwartungsmanagement
• Controlling auf PM - Ebene
• Trouble - Shooting
PK - CD Chefdesign
PK - QK Qualitäts - und Wissensmanagement
• Rolle QB und KB, z. B. auch Pflege ISIS
• Steuernde QMS - Aufgaben , QMS - Audits
• QM - Pläne
PT - KM Konfigurations - /Releasemanagement
• KM aufbauen und pflegen
• Build - Management
• Auslieferungskoordination, Releaseverantwortung
• Installations - CD erstellen
• Bestückung von Umgebungen, Transport von Software
PT - SEU Software - Entwicklungsumgebung
• SEU aufbauen und pflegen
• Service, Support, Hotlines
PT - TI Technische Infrastruktur
• Einrichten und Installation Server
• Netzwerkverbindung
• Software - Installationen
PK - MTG organisat . Meetings und Workshops
• Statusmeetings, Kickoff, Touchdown , Schätzworkshops
• Keine fachlichen Meetings ( PI )
0 - 30% PI
ohne FP - Risiko ! Systemerstellung = Brutto
KON Konstruktion
KON - A Konstruktion der A - Stufen
• Konstruktion der A - Stufen z.B. Modulkonstruktion, Dialoge,
Batches, Schnittstellen…
• Einarbeiten von Review - Anmerkungen
• Feinabstimmungen nach FK - Abnahme
KON - MIG Konstruktion Migr . & Einführungsstrategie
• Konzeption von Migration, Einführungsstrategie &
Erstbefüllungen
KON - DB Konstruktion DB - Design & Datentypen
• Physisches DB - Design
• Konzeption Indexe
• Konzeption übergreifende Datentypen
KON - QS Durchführung QS in der Konstruktion
• Durchführung & Besprechen von Reviews ,
• Review - oder Abnahmeveranstaltungen mit Kunden
• Schreibtischtests
SP - ALLG Allg. Spezifikationsaufwände
• Dokumentenstruktur
• Redaktion und Auslieferung
• Allgemeine Kapitel gem. Spezifikations -
Bausteinen z. B. Projektgrundlagen, Ziele &
Rahmenbedingungen, Stufung & Einführung etc.
• Themenübergreifende Workshops
SP - THEMA Spez. von Themen u. Daten
• Spezifikation der fachlichen Themen bis
Abnahme
• Spezifikation des logischen Datenmodells
• Testfallerstellung
• Alle notwendigen Abstimmungen dazu
• Einarbeiten von internen Review - Anmerkungen
(Abgrenzung: SP - NACH )
SP - QS QS auf Spezifikation
• Abnahmeveranstaltungen mit Kunden
• Durchführen & Besprechen von Reviews
• Schreibtischtests
REA - DB Aufbau und Pflege DB
• Realisierung DDLs etc.
• DB - Admin - Aufgaben
• Übergreifende Datentypen realisieren
REA - MIG Durchführung Migration &
Erstbefüllungen
• Realisierung & Test von Migrationstools
• Erstellen von Skripten zur Erstbefüllung
• Durchführung Migration
REA - T Realisierung T - Stufen
• Codieren incl. Persistenz & Datentypen
• Modul - und Komponententests incl. Bugfix
• Einarbeiten von Code - Reviews
REA - QS Durchführung QS in der REA
• Code Reviews incl. Durchsprechen
• Code Walk - Throughs & sonst. QS - Maßnahmen
• Hierzu gehört nicht der Entwicklertest!
( REA - T , REA - A )
REA - A Realisierung A - Stufen
• Codieren incl. Persistenz & Datentypen
• Modul - und Komponententests incl. Bugfix
• Einarbeiten von Code - Reviews
INT - VBD Durchführung Verbundtest
• Integrativer Test mit allen Nachbarsystemen auf einer
produktionsnahen Umgebung
• Fokus auf Systemschnittstellen
• kein vollständiger fachlicher Test
• Manchmal sind System - und Verbundtest nur
gemeinsam sinnvoll durchzuführen. In diesem Fall wird
der Aufwand mit INT - SYS erfasst.
INT - BUGFIX Fehlersuche & Fehlerbehebung
• Bugfixing aus System - , Verbund - und Abnahmetest
• Performancetuning
INT - NFKT nichtfunktionale Tests
• Z. B. Last - , Performance - , Ausfalltests
INT - SYS Durchführung ( Sub - )Systemtest
• Systematischer, fachlicher & technischer Test der
integrierten Inkremente/Stufen eines Projekt -
Releases , ohne Teilsysteme von anderen Projekten
bzw. Drittsysteme.
• Oft durch ein unabhängiges Team
• Auch Paralleltests
INT - TVO alle Testvorbereitungen
• Alle Testkonzepte und Testdaten
• Testfallerstellung
• Konzept/Tools Fehlerverfolgung
• Testtools (Evaluierung, Realisierung…)
INT - QS Durchführung QS
• Reviews auf Testkonzepte u. ä.
• Reviews auf Testfälle
IB - ABN Abnahme
• Nach Vereinbarung:
Unterstützung Abnahmetest
IB - EIN Einführung & Betrieb
• Produktionseinführung
• Installation & Betrieb
• Unterstützung Rollout
IB - DOK Dokumentationen
• Systemdokumentationen
• Benutzerhandbücher
• Betriebshandbücher
•
PK - MTG organisat . Meetings und Workshops
• Statusmeetings, Kickoff, Touchdown , Schätzworkshops
• Keine fachlichen Meetings ( PI )
0 - 30% PI
ohne FP - Risiko ! Systemerstellung = Brutto
KON Konstruktion
KON - A Konstruktion der A - Stufen
• Konstruktion der A - Stufen z.B. Modulkonstruktion, Dialoge,
Batches, Schnittstellen…
• Einarbeiten von Review - Anmerkungen
• Feinabstimmungen nach FK - Abnahme
KON - MIG Konstruktion Migr . & Einführungsstrategie
• Konzeption von Migration, Einführungsstrategie &
Erstbefüllungen
KON - DB Konstruktion DB - Design & Datentypen
• Physisches DB - Design
• Konzeption Indexe
• Konzeption übergreifende Datentypen
KON - QS Durchführung QS in der Konstruktion
• Durchführung & Besprechen von Reviews ,
• Review - oder Abnahmeveranstaltungen mit Kunden
• Schreibtischtests
SP - ALLG Allg. Spezifikationsaufwände
• Dokumentenstruktur
• Redaktion und Auslieferung
• Allgemeine Kapitel gem. Spezifikations -
Bausteinen z. B. Projektgrundlagen, Ziele &
Rahmenbedingungen, Stufung & Einführung etc.
• Themenübergreifende Workshops
SP - THEMA Spez. von Themen u. Daten
• Spezifikation der fachlichen Themen bis
Abnahme
• Spezifikation des logischen Datenmodells
• Testfallerstellung
• Alle notwendigen Abstimmungen dazu
• Einarbeiten von internen Review - Anmerkungen
(Abgrenzung: SP - NACH )
SP - QS QS auf Spezifikation
• Abnahmeveranstaltungen mit Kunden
• Durchführen & Besprechen von Reviews
• Schreibtischtests
REA - DB Aufbau und Pflege DB
• Realisierung DDLs etc.
• DB - Admin - Aufgaben
• Übergreifende Datentypen realisieren
REA - MIG Durchführung Migration &
Erstbefüllungen
• Realisierung & Test von Migrationstools
• Erstellen von Skripten zur Erstbefüllung
• Durchführung Migration
REA - T Realisierung T - Stufen
• Codieren incl. Persistenz & Datentypen
• Modul - und Komponententests incl. Bugfix
• Einarbeiten von Code - Reviews
INT Integration REA Realisierung
KON - T Konstruktion der T - Stufen
• Konstruktion der T - Stufen z. B. Tracing, Logging , Drucken,
technische Frameworks…
• Schreiben zentrales IT - Konzept
• Einarbeiten von Review - Anmerkungen
UM Umsetzung
PQ Projektquerschnitt 25 - 60% PI
PK Projektkoordination 20 - 50% PI PT Projekttechnik 5 - 15% PI
100% = Netto
0 - 10% PI
PK - PL Projektleitung & Teilprojektleitung
• Jede Teamführung (auch von Test - Teams)
• Planung und Controlling
• Risikomanagement
• Abstimmung Parallelprojekte
PK - PM Projektmanagement
• Kunden - und Risikomanagement
• Gremienarbeit, Erwartungsmanagement
• Controlling auf PM - Ebene
• Trouble - Shooting
PK - CD Chefdesign
PK - QK Qualitäts - und Wissensmanagement
• Rolle QB und KB, z. B. auch Pflege ISIS
• Steuernde QMS - Aufgaben , QMS - Audits
• QM - Pläne
PT - KM Konfigurations - /Releasemanagement
• KM aufbauen und pflegen
• Build - Management
• Auslieferungskoordination, Releaseverantwortung
• Installations - CD erstellen
• Bestückung von Umgebungen, Transport von Software
PT - SEU Software - Entwicklungsumgebung
• SEU aufbauen und pflegen
• Service, Support, Hotlines
PT - TI Technische Infrastruktur
• Einrichten und Installation Server
• Netzwerkverbindung
• Software - Installationen
PT - SEU Software - Entwicklungsumgebung
• SEU aufbauen und pflegen
• Service, Support, Hotlines
PT - TI Technische Infrastruktur
• Einrichten und Installation Server
• Netzwerkverbindung
• Software - Installationen
REA - QS Durchführung QS in der REA
• Code Reviews incl. Durchsprechen
• Code Walk - Throughs & sonst. QS - Maßnahmen
• Hierzu gehört nicht der Entwicklertest!
( REA - T , REA - A )
REA - A Realisierung A - Stufen
• Codieren incl. Persistenz & Datentypen
• Modul - und Komponententests incl. Bugfix
• Einarbeiten von Code - Reviews
INT - VBD Durchführung Verbundtest
• Integrativer Test mit allen Nachbarsystemen auf einer
produktionsnahen Umgebung
• Fokus auf Systemschnittstellen
• kein vollständiger fachlicher Test
• Manchmal sind System - und Verbundtest nur
gemeinsam sinnvoll durchzuführen. In diesem Fall wird
der Aufwand mit INT - SYS erfasst.
INT - BUGFIX Fehlersuche & Fehlerbehebung
• Bugfixing aus System - , Verbund - und Abnahmetest
• Performancetuning
INT - NFKT nichtfunktionale Tests
• Z. B. Last - , Performance - , Ausfalltests
INT - SYS Durchführung ( Sub - )Systemtest
• Systematischer, fachlicher & technischer Test der
integrierten Inkremente/Stufen eines Projekt -
Releases , ohne Teilsysteme von anderen Projekten
bzw. Drittsysteme.
• Oft durch ein unabhängiges Team
• Auch Paralleltests
INT - TVO alle Testvorbereitungen
• Alle Testkonzepte und Testdaten
• Testfallerstellung
• Konzept/Tools Fehlerverfolgung
• Testtools (Evaluierung, Realisierung…)
INT - QS Durchführung QS
• Reviews auf Testkonzepte u. ä.
• Reviews auf Testfälle
IB - ABN Abnahme
• Nach Vereinbarung:
Unterstützung Abnahmetest
IB - EIN Einführung & Betrieb
• Produktionseinführung
• Installation & Betrieb
• Unterstützung Rollout
IB - DOK Dokumentationen
• Systemdokumentationen
• Benutzerhandbücher
• Betriebshandbücher
• Installationshandbuch
• Schreiben der Online - Hilfetexte
IB - SCHUL Schulungen
• Vorbereitung und Durchführung von
Schulungen
• Schulungsunterlagen
• Train the Trainer
60 - 90% PI
KON - ALLG Allgemeine Konstruktionsaufwände
• Initialisierung & Gesamtarchitektur
• Technischer Durchstich & Proof of Concept
• Interne Handbücher (Entwicklerhandbuch,
Nutzungskonzepte, Styleguides etc.)
• Redaktion & Auslieferung IT - Konzept
• Allg. Teile im ITK (Einleitung, Glossar, Überblick…)
• Einarbeiten von Review - Anmerkungen
10 - 25% UM 50 - 70% UM 20 - 30% UM
PN
10 - 30% PI
• Fachliches und Technisches Chefdesign
• Auch Teamdesign
• Inhaltliche Arbeit ist in der
bzw. SP zu berücksichtigen
PN - EIN Einarbeitung (fachlich/technisch)
• Auch Teamaufbau, Teamfindung, insb. bei steilem Teamaufbau in Gr oßprojekten
• Der „gefühlte“ Einarbeitungsaufwand, keine Pauschalen
- •
-
•
SP NACH Nacharbeiten nach Review
Alle Nacharbeiten zwischen Abnahme
veranstaltung bis zur endgültigen Abnahme
Typisch: Erstellung Fachkonzept V1.1
•
IB QS Durchführung QS
Reviews von Dokumentationen
Reviews von Schulungsunterlagen
1) SP ohne Aufwände für Grobspezifikation
Vorbedingung
• Grobspezifikation liegt vor (RUP: Inception)
• Spezifikations-Format ist variabel
Schätzumfang
• Feinspezifikation bis Bereitstellung zur Abnahme
(RUP: Elaboration + Construction)
• inklusive QS-Maßnahmen
• d.h. folgende umrandete Aufwände
aus dem Kontenrahmen1) :
msg, November 2014 Thomas Engeroff 48
Die UCP-Schätzung erfolgt in 5 Schritten und differenziert nach
Systemanforderungen und Projekteinfluss
• Use Cases beschreiben das Verhalten und die Interaktion eines Systems als Reaktion auf die zielgerichtete Anfrage oder Aktion eines Aktors (menschlicher oder technischer Nutzer des Systems)
Use Cases und Aktoren definieren den funktionalen bzw. abwendungs-fachlichen Umfang des Projekts (= A-Faktor). Dieser wird als Use Case Points erfasst
• Der T-Faktor berücksichtigt die nichtfunktionalen Anforderungen und technologischen Randbedingungen des Projekts. Er wird anhand eines Fragenkatalogs ermittelt
• Der M-Faktor berücksichtig die organisatorische Komplexität und das Umfeld des Projekts. Er wird anhand eines Fragenkatalogs ermittelt
• Über den Produktivitätsfaktor (PF) wird der Aufwand berechnet. Dieser Faktor wurde auf Basis der Nachkalkulationen ermittelt und ist vorgegeben. Der Aufwand umfasst sowohl fachliche als auch technische Komponenten und ist proportional zu den ermittelten Use Case Points
Use-Cases
klassifizieren
Aktoren
klassifizieren
T-Faktor
ermitteln
M-Faktor
ermitteln
Aufwand
berechnen
1
2
3
4
5
Aufwand =
Systemanforderungen
A-Faktor
Projekteinfluss
x
nicht funktionale Anforderungen
T-Faktor M-Faktor x PF x
funktionale Anforderungen
msg, November 2014 Thomas Engeroff 49
Die Größe / Komplexität eines Use Cases wird durch dessen
Anzahl Schritte, Dialoge und Szenarien normiert
MAX
(# Schritte
# Dialoge
# Szenarien)
Komplexität Punkte
0 – 3
4 – 7
>= 8
Einfach
Mittel
Hoch
5
10
15
Definition von „Schritten“ in der
UCP-Methode als entscheidende Kenngröße
• Ein Schritt im Ablauf eines Use-Cases ist ein in sich geschlossener fachlicher Teil
des Use-Cases, der
• vom folgenden und davorliegenden Schritt eindeutig getrennt ist, z.B. durch
• den Wechsel des Akteurs, oder der verarbeitenden "Schicht"
(z.B. Eingabe im Dialog durch den Nutzer-> Verarbeitung der Eingabe am
Server-> Anzeige des Ergebnisses an der Oberfläche)
• Erzeugen eines definierten (Zwischen-)Ergebnisses
(z.B. Erzeugen von Druckdokumenten)
• Aufspalten eines neuen Szenarios
• Es werden die Schritte in allen Szenarien gezählt. Ist ein Schritt in mehreren
Szenarien enthalten, wird er nur einmal gezählt.
• Typische Beispiele für Schritte sind:
• Eingabe eines oder mehrerer Werte in einen Dialog
(ohne dass dazwischen ein Server-Roundttrip erfolgt)
• Aufrufe von Anwendungsfunktionen
• Server-Transaktionen
msg, November 2014 Thomas Engeroff 51
Schätzbeispiel aus der Praxis: Adresse anlegen
– Zählen der Schritte –
4. Schritt: Ergeb-
nisse Serverauf-
rufanzeigen
Adressdaten erfassen
Prüfung auf posta- lische Korrektheit
Adressvergleich zur Dublettenprüfung
Vorschlagliste
Auswahl aus Vorschlagliste
Neue Adresse anlegen
Adresse bearbeiten
Adresse ist nicht korrekt
Adresse ist korrekt
Die Adresse existiert Die Adresse existiert nicht
2. Schritt: Benutzereingaben
3. Schritt: Serveraufruf
(A-Funktion)
6. Schritt: Serveraufruf
(A-Funktion)
7. Schritt: Ergebnisse Serveraufruf
anzeigen
9. Schritt: alternativen
Anwendungsfall aufrufen 10. Schritt: Serveraufruf (A-
Funktion)
1. Schritt: Dialog „Adressdaten“
anzeigen
8. Schritt: Auswahl der Adresse -
Benutzereingaben
5. Schritt: Auswahl der Adresse -
Benutzereingaben
msg, November 2014 Thomas Engeroff 52
Schätzbeispiel aus der Praxis: Adresse anlegen
– Zählen der Dialoge –
Zählregeln: Anzahl Dialoge
• Hier wird die Anzahl der unterschiedlichen Dialoge des Use Case gezählt.
• Dialoge werden wie folgt gezählt:
• Jeder Reiter eines Dialogs (mit siginifikanten fachlichen Unterschieden) wird als eigener Dialog gezählt,
• triviale Pop-Up-Meldungen, Bestätigungen und Menüs werden nicht gezählt,
• Anzeigeseiten werden nur gezählt, wenn Daten eingegeben werden können.
• Druckstücke werden auch als Dialoge gezählt
• Hinweis: Derzeit deckt die Methode Kompexitätsunterschiede bei unterschiedlichen Dialogarten noch nicht gut ab.
Adressdaten erfassen
Prüfung auf posta- lische Korrektheit
Adressvergleich zur Dublettenprüfung
Vorschlagliste
Auswahl aus Vorschlagliste
Neue Adresse anlegen
Adresse bearbeiten
Adresse ist nicht korrekt
Adresse ist korrekt
Die Adresse existiert Die Adresse existiert nicht
1. Dialog
3. Dialog 2. Dialog
msg, November 2014 Thomas Engeroff 53
Schätzbeispiel aus der Praxis: Adresse anlegen
– Zählen der Szenarien –
Zählregeln: Anzahl Szenarien
• Hier wird die Anzahl der unterschiedlichen Erfolgs-Szenarien und nichttrivialen Fehlerszenarien im Use Case gezählt.
• Ein Erfolgs-Szenario ist ein möglicher fachlicher Ablauf des Use Case, der zum Erfolg (Erreichen des Business Goal) führt, z.B.:
• das Haupt-Szenario („Main Flow“) des Use Case
• fachliche Alternativszenarien des Use Case (triviale Abweichungen, z.B. „Anzeige einer Meldung, dann Abbruch“ werden nicht mitgezählt)
• Fehlerszenarien sind solche, die nicht zum Erfolg (Erreichen des Business Goal) führen
• fachliche Fehlerszenarien werden gezählt (wenn fachliche Schritte zur Fehlerbehandlung durchlaufen werden)
• triviale Fehlerszenarien, z.B. „Anzeige einer Meldung, dann Abbruch“ werden nicht gezählt.
Adressdaten erfassen
Prüfung auf posta- lische Korrektheit
Adressvergleich zur Dublettenprüfung
Vorschlagliste
Auswahl aus Vorschlagliste
Neue Adresse anlegen
Adresse bearbeiten
Adresse ist nicht korrekt
Adresse ist korrekt
Die Adresse existiert Die Adresse existiert nicht
1. Szenario
3. Szenario
2. Szenario
msg, November 2014 Thomas Engeroff 54
Die Größe / Komplexität eines Use Cases wird durch
dessen Anzahl Schritte, Dialoge und Szenarien normiert
Ergebnis für Use Case Adresse anlegen:
• 10 Schritte
• 3 Dialoge
• 3 Szenarien
MAX
(# Schritte
# Dialoge
# Szenarien)
Komplexität Punkte
0 – 3
4 – 7
>= 8
Einfach
Mittel
Hoch
5
10
15
hohe Komplexität = 15 Use Case Points
4. Schritt: Ergeb-
nisse Serverauf-
rufanzeigen
Adressdatenerfassen
Prüfung auf posta-lische Korrektheit
Adressvergleich zurDublettenprüfung
Vorschlagliste
Auswahl ausVorschlagliste
Neue Adresseanlegen
Adresse bearbeitenNeue Adresse
anlegenAdresse bearbeiten
Adresse ist nicht korrekt
Adresse ist korrekt
Die Adresse existiertDie Adresse existiert nicht
2. Schritt: Benutzereingaben
3. Schritt: Serveraufruf
(A-Funktion)
6. Schritt: Serveraufruf
(A-Funktion)
7. Schritt: Ergebnisse
Serveraufruf anzeigen
9. Schritt: alternativen
Anwendungsfall aufrufen10. Schritt: Serveraufruf (A-
Funktion)
1. Schritt: Dialog „Adressdaten“
anzeigen
8. Schritt: Auswahl der Adresse -
Benutzereingaben
5. Schritt: Auswahl der Adresse -
Benutzereingaben
1. Dialog
3. Dialog
2. Dialog
1. Szenario
3. Szenario3. Szenario
2. Szenario2. Szenario
msg, November 2014 Thomas Engeroff 55
Best Practice: Der richtige Schnitt von Use Cases
• Wichtig für eine verlässliche Schätzung ist eine einheitliche und angemessene Granularität.
• Folgende Hinweise deuten auf einen zu groben Schnitt hin:
• Die textuelle Beschreibung eines Szenarios umfasst mehr als eine DIN-A4-Seite oder
• Ein Szenario enthält mehr als 12 Schritte oder
• Ein Use Case beinhaltet mehr als sieben Szenarien (einzelnen Szenarien sind hier als
eigene Use Cases zu betrachten).
• Folgende Hinweise deuten auf einen zu feinen Schnitt hin:
• Der Use Case enthält keinen Dialog und
• Der Use Case hat nur ein Szenario und
• Der Use Case hat nur einen oder zwei Schritte
• Falls mehr als etwa 20% der Use Cases zu grob oder zu fein sind, ist Vorsicht geboten: Hier
kann die nicht angemessene Granularität das Schätzergebnis verfälschen. Die
entsprechenden Use Cases sollten dann zunächst fachlich geteilt bzw. zusammengezogen
werden.
• Insgesamt ist eine ausgewogene Verteilung von kleinen, mittleren oder großen Use Cases
ein Zeichen für einen "guten" Schnitt.
• Generell gilt, dass Schritte innerhalb eines Use Cases, innerhalb einer Schätzung und
(idealerweise) über alle UCP Schätzungen hinweg etwa gleich groß sein sollten.
msg, November 2014 Thomas Engeroff 56
T-Faktor und M-Faktor normieren auf einfache Weise die technische
und organisatorische Komplexität des Projekts
T-Faktor
IFP
UG
FP
A
4.1
CO
CO
MO
II
UC
P (K
arn
er)
Cre
dit S
uis
se
UC
P M
T230
sd
&m
UC
P 1
.0
sd
&m
Um
frag
e
Komplexe Berechnungen 1 1 1 1 1
Benutzeroberfläche 2 2 1 2 1
Schnittstellen 1 1 1 1 1
Verteiltes System 1 1 1 1 1
Verfügbarkeitsanford. 1 1 1 1
Wiederverwendbark. geford. 1 1 1 1 1 ?
Performance 2 1 1 1 ?
Flexibilität des Systems 1 1 1 1 ?
Installation 1 1 1
Sicherheitsanforderungen 1 1
Anwender-Schulung 1 1
Anforderung an Portabilität 1 1
Auslastung Zielumgebung 1 2
Anzahl Clients 1
Betreibbarkeit 1
Flexibilität Architektur 1
Ähnliche Produkte 1
Ausfallsicherheit (Reliability) 1 ?
Datenbankgröße 1
Tausch Hard-/Software 1
Flexibilität d. Entwicklung 1
Summe 14 9 13 7 13 5
M-Faktor
IFP
UG
FP
A 4
.1
CO
CO
MO
II
UC
P (K
arn
er)
Cre
dit S
uis
se
UC
P M
T 2
30
sd
&m
UC
P 1
.0
sd
&m
Um
frag
e
Stabile Anforderungen 1 1 1
Reife der Prozesse 1 1 1
Lstg./Fähigheit Chefdesigner 1 1 1 1
Verfügbare Zeit 1 1
Teamplayer 1 1
Kontinuität Mitarbeiter 1 1
Review und Architektur 1 1
Anzahl Entscheidungsträger 1 1
Integrationsabhängigkeit 1 1
Erfahrung Fachlichkeit 1 1 1 1 ?
Motivation 1 1
Verfügbarkeit Team 1 1
Effizienz Programm.sprache 1 1
Erfahrung mit RUP 1
Erfahrung Objektorientierung 1
Erfahrung Werkzeuge 1 ?
Erfahrung Plattform/Middlew. 1
Verteiltes Arbeiten 1 ?
Dokumentation 1
Unterstütz. durch Werkzeuge 1
Lstg./Fähigk. Programmierer 1 ?
Summe 0 13 8 3 7 9
Kostenfaktor Kostenfaktor
relevant fehlt evtl. relevant aber Streuung zu hoch ?
Legende: (Bewertung der Kostenfaktoren aus Sicht der sd&m Umfrage)
überflüssig nicht relevant
msg, November 2014 Thomas Engeroff 57
Zur Bestimmung des M-Faktors wird das Projekt bezüglich
eine Reihe von Einflussgrößen bewertet
Nr. Einflussgröße Beispielwerte für die Bewertung Bewertung
M1
Leistung/
Fähigkeit
Chefdesigner
Wie erfahren sind der technische und fachliche Chefdesigner (TCD und FCD) hinsichtlich Aufgabe und
Fachlichkeit bzw. Technik)?
0: wenig erfahren (0 vergleichbare Projekte als FCD oder TCD durchgeführt)
3: erfahren (1 vergleichbares Projekt als FCD oder TCD durchgeführt)
5: sehr erfahren (2 vergleichbare Projekte als FCD oder TCD durchgeführt)
3
M4
Qualität von
Grobspezifika-tion
und T-Architektur
Wie nachvollziehbar und detailliert ist die Grobspezifikation und wie gut sind Risiken bekannt? Müssen z.B.
umfangreiche Arbeiten zur Erstellung der T-Architektur durchgeführt (typisch für ein erstes Release) werden oder
sind wichtige „Pflöcke“ schon gesetzt (typisch für eine hohe Releasenummer)
0: die Grobspezifikation enthält zahlreiche Widersprüche und offene Fragen, für die Klärung sind mehrere
Workshops notwendig; eine Risikoanalyse muss durchgeführt werden; es sind umfangreiche Arbeiten notwendig,
um eine T-Architektur zu erstellen
3: die Grobspezifikation enthält offene Fragen, welche mit dem Kunden zu klären sind; eine Risikoanalyse wurde
durchgeführt und es existieren Risiken; die T-Architektur entspricht weitestgehend einer Standardarchitektur oder
wurde in einem vorherigen Release bereits so aufgesetzt
5: die Grobspezifikation ist ausreichend detailliert und lässt keine oder nur sehr wenige Fragen offen; eine
Risikoanalyse wurde durchgeführt und ergab keine nennenswerte Risiken; die T-Architektur existiert
3
M5 Prozess-
Overhead
Wie formal sind das Vorgehen und der Entwicklungsprozess im Projekt (bezieht sich auf Aufbau- und
Ablauforganisation)?
0: komplexer Entwicklungsprozess, d.h. sehr formales Vorgehen und Prozesse, hohe Abstimmungs- und
Querschnittsaufwände, alle Querschnittsrollen besetzt (typisch für Großprojekt mit mehr als 40 Mitarb.)
3: normaler Entwicklungsprozess mit durchschnittlichen Querschnittsaufwänden (typisch für mittelgroßes Projekt,
aber auch für kleine Projekte mit entsprechend formalen Anforderungen des Kunden)
5: schlanker Entwicklungsprozess, d.h. pragmatisches Vorgehen, wenig Dokumentation, keine formalen Reviews
oder Abnahmen, niedrige Querschnittsaufwände (typisch für kleines Projekt mit max. 5 Mitarb.)
3
M-Faktor > 1.0
M-Faktor = 1.0
M-Faktor < 1.0
Kostenfaktoren im M-Faktor (Ausschnitt)
msg, November 2014 Thomas Engeroff 58
Die UCP-Methode setzt eine fachliche Größenbestimmung
voraus
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
Fazit
Geeignet
Nicht geeignet
• Individualentwicklung • Produktanpassungen
• Neuentwicklung • Wartung, d.h. geringfügige Anpassung
bestehender Systeme
• Neuentwicklung fachlicher Geschäfts-
prozesse in betrieblichen Anwendungen • Technikstufen, Steuerungssysteme
• Stammdaten-Pflegesysteme
msg, November 2014 Thomas Engeroff 59
Ein paar Disclaimer ...
• Use Case Points sind – wie alle Softwaremetriken – keine fürchterlich
exakte Wissenschaft
o Wer mit Use Case Points arbeitest, muss sich auf eine gewisse
Unschärfe einlassen und manchmal von Details abstrahieren
• Use Case Points sind keine Wunderwaffe
o „Garbage in – garbage out“ :
Wenn die Schätzbasis so vage oder unvollständig ist, dass ich Use
Cases nicht sinnvoll benennen und annähernd vollständig
aufzählen kann, hilft auch UCP nicht weiter
o „Wenn sie zum Projekt nicht passen, lass die Finger davon.“
Use Case Points lassen sich nicht für alle Projekte sinnvoll
einsetzen
msg, November 2014 Thomas Engeroff 60
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
msg, November 2014 Thomas Engeroff 61
Literatur
• http://www.msg-systems.com/unt_technologiekomp.0.html UCP 3.0
• 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, November 2014 Thomas Engeroff 62
Vielen Dank für Ihre Aufmerksamkeit
Thomas Engeroff Senior Project Manager
Telefon: +49 151 155 255 51
www.msg-systems.com
msg, November 2014 Thomas Engeroff 63