Projektmanagement aus der Praxis der … · Für Kennzahlen und Auswertungen Ebene1 Ebene 2 Jedes...
Transcript of Projektmanagement aus der Praxis der … · Für Kennzahlen und Auswertungen Ebene1 Ebene 2 Jedes...
Projektmanagement aus der Praxis der SoftwareentwicklungVorlesung im Wintersemester 2014/15 an der Technischen Universität Dortmund2b. Vorlesung am 27.10.2014: AufwandsschätzungSimon Pfeiffer
© msg systems ag, 27.10.20141 Projektmanagement - Aufwandsschätzung
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung2
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung3
Aufwandsschätzungen beruhen immer auf praktischer Erfahrung und Intuition
Aufgaben durchführen
Aufwändemessen
Erfahrung kalibrierenAufwände (neu) schätzen
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung4
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung5
Schätzdatenbanken mit FSM (Functional 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/Klassifizierung nötig bzgl.:
• Größe (FSM)• Komplexität• Umfeld
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung6
Der Kontenrahmen strukturiert Aufgaben nach Aufgabenkategorien (Beispiel: sd&m AG)
Ebene 0, Für Kennzahlen und Auswertungen
Ebene 1
Ebene 2Jedes Projekt schätztund erfasst seine Aufwände auf einer dieser Ebenen. Ab einer Projektgrößevon 15 BM ist die Ebene 2 verbindlich.Darunter kannbeliebig detailliert werden.
Die Ebene 1 & 2 definiert dieAufgabenkategorie
PN Projektneben-aufwände
ProjektPI Projektinhalt
IB Inbetriebn.SP SpezifikationSP-ISTIST-Systemanalyse
In Releases
INT IntegrationREA RealisierungKON-TKonstruktion der T-Stufen
UM Umsetzung
PQ ProjektquerschnittPK Projektkoordination PT Projekttechnik
100% = Netto
PK-PLProjektleitung
PK-PMProjektmanagement
PK-CDChefdesign
PK-QKQualitätsmanagement
PT-KMKonfigurations-/ Releasemanagement
PT-SEUSoftware-Entwicklungsumgebung
PT-TITechnische Infrastruktur
PK-MTGMeetings
KON Konstruktion
KON-AKonstruktion der A-Stufen
KON-MIGKonzeption v. Migration etc.
KON-DBKonstruktion DB-Design & Datentypen
KON-QSQS in der Konstruktion
SP-ALLGAllg. Spezifizikations-aufwände
SP-THEMASpezifikation von Themen und Daten
SP-QSQS auf Spezifikation
REA-DBAufbau und Pflege DB
REA-MIGMigration & Erstbefüllungen
REA-TRealisierung T-Stufen
REA-QSQS in der REA
REA-ARealisierung A-Stufen
INT-VBDVerbundtest
INT-NFKTNicht-Funktionale Tests
INT-BUGFIXFehlerbehebung
INT-SYS(Sub-) Systemtest
INT-TVOalle Testvorbereitungen
INT-QSDurchführung QS
IB-ABNAbnahme
IB-EINEinführung & Betrieb
IB-DOKDokumentationen
IB-SCHULSchulungen
IB-QSDurchführung QS
KON-ALLGAllg. Konstruktionsaufwand
CRChange Requests
BERATBeratung
SP-NACHNacharbeiten (FK V1.1)
PN PN-EIN Einarbeitung, Teamaufbau PN-STORT Mehrere StandortePN-REISE Reisezeiten
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung7
PN Projektneben-aufwände
ProjektPI Projektinhalt
IB Inbetriebn.SP SpezifikationSP-ISTIST-Systemanalyse
In Releases
INT IntegrationREA RealisierungKON-TKonstruktion der T-Stufen
UM Umsetzung
PQ ProjektquerschnittPK Projektkoordination PT Projekttechnik
100% = Netto
PK-PLProjektleitung
PK-PMProjektmanagement
PK-CDChefdesign
PK-QKQualitätsmanagement
PT-KMKonfigurations-/ Releasemanagement
PT-SEUSoftware-Entwicklungsumgebung
PT-TITechnische Infrastruktur
PK-MTGMeetings
KON Konstruktion
KON-AKonstruktion der A-Stufen
KON-MIGKonzeption v. Migration etc.
KON-DBKonstruktion DB-Design & Datentypen
KON-QSQS in der Konstruktion
SP-ALLGAllg. Spezifizikations-aufwände
SP-THEMASpezifikation von Themen und Daten
SP-QSQS auf Spezifikation
REA-DBAufbau und Pflege DB
REA-MIGMigration & Erstbefüllungen
REA-TRealisierung T-Stufen
REA-QSQS in der REA
REA-ARealisierung A-Stufen
INT-VBDVerbundtest
INT-NFKTNicht-Funktionale Tests
INT-BUGFIXFehlerbehebung
INT-SYS(Sub-) Systemtest
INT-TVOalle Testvorbereitungen
INT-QSDurchführung QS
IB-ABNAbnahme
IB-EINEinführung & Betrieb
IB-DOKDokumentationen
IB-SCHULSchulungen
IB-QSDurchführung QS
KON-ALLGAllg. Konstruktionsaufwand
CRChange Requests
BERATBeratung
SP-NACHNacharbeiten (FK V1.1)
PN PN-EIN Einarbeitung, Teamaufbau PN-STORT Mehrere StandortePN-REISE Reisezeiten
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung8
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung9
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung10
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung11
Wichtige Anmerkungen zum Kontenrahmen
PN
ProjektPI
IBSP
SP-IST
In Releases
INTREA
KON-T
UM Umsetzung
PQPK PTPK-PL PK-PMPK-CD
PK-QK PT-KMPT-SEU
PT-TIPK-MTG
KON
KON-A
KON-MIGKON-DB
KON-QS
SP-ALLGSP-THEMA
SP-QS
REA-DBREA-MIG
REA-T
REA-QS
REA-AINT-VBD
INT-NFKTINT-BUGFIX
INT-SYSINT-TVO
INT-QS
IB-ABNIB-EINIB-DOKIB-SCHUL
IB-QS
KON-ALLG
CR BERAT
SP-NACH
PN PN-EIN PN-STORTPN-REISE
Qualitätssichernde Maßnahmen durch den Bearbeiter (Entwicklertest, Komponententest) zählen zum Erstellungsaufwand
Planen wie schätzen: deshalb läuft Bugfixing unter „Integration“ – und nicht unter „Rea“
Qualitätssichernde Maßnahmen durch Dritte (Reviews, Audits etc) werden explizit erfasst –und zwar in der gleichen Kategorie wie das Ergebnis
Für KBer/QBer-Aktivitäten (QMS-Audit, Prisma-Pflege, etc) gibt es das Konto QK
Meetings sind Statusmeetings, insb. auch Kickoff und Reflexionsmeetings. Inhaltliche Meetings gehen aufs Thema
Wir buchen Aufgaben, nicht Rollen, d.h. ein PL, der etwas programmiert, bucht auf REA, nicht auf PL
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung12
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung13
Spezi-fikation
Um-setzung
1
2
# Fenster
# Ziegel
€
Bottom-Up
? ?
f (x)
FSM
€
Top-Down
Wir unterscheiden Bottom-Up undTop-Down Schätzverfahren
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung14
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung15
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
COCOMOFunction PointsUse Case Points
AnalogiemethodeMultiplikator-
methodenProzentsatzmeth.
EinzelschätzungDelphi-MethodeSchätzklausur
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung16
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung17
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung18
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung19
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung20
Alles, was Aufwand macht, …
Aufwandsposten
(Schätzposten)
ArbeitsergebnisDeliverableErgebnis
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung21
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 BM1 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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung22
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 zuschlagen, die Festlegung hängt von der Einschätzung des Angebotsverantwortlichen ab.
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung23
Beispiel: Strukturierung einer Stückliste
Konto Thema/ Komponente
Schätzposten (Arbeitspaket/Aktivität) Schätzung
SPSP-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,0SP-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,0SP-THEMA Register Visa Dokumentenquerschnitt mit Einleitung, Referenzen, NFAs
usw.4,0
SP-THEMA Visa-Regelwerk Überarbeitung bestehende Regeln (24) 12,0SP-THEMA Visa-Regelwerk Identifikation und Ergänzung fehlende Regeln 5,0SP-THEMA Visa-Regelwerk Berechtigungen prüfen und ergänzen 5,0SP-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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung24
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 GesamtaufwandSP-ALLG Initialisierung: fachliche Workshops, Themenabgrenzung, Spez-Pattern, etc. 4 1 5SP-ALLG Einleitung, Glossar, Überblick, Redaktion etc. 3 1 4SP-THEMA Stammdatendialoge Spez Dialog: Pflege Skilehrer 1 0,5 1,5SP-THEMA Stammdatendialoge Spez Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 1 0,5 1,5SP-THEMA Stammdatendialoge Spez Dialog: Pflege Stammdaten Skischule 1 0,5 1,5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Verfügbarkeit Skilehrer 2 0,5 2,5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Skikurse anlegen/pflegen 2 0,5 2,5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Kursbuchung 4 1 5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Fakturierung 2 1 3SP-THEMA Druckausgaben Rechnung 1 0,5 1,5SP-THEMA Druckausgaben Übersicht über alle Kurse 1 0,5 1,5SP-THEMA Druckausgaben Übersicht zu einem Kurs 1 0,5 1,5SP-NACH Erstellen Version 1.1 2 1 3SP-QS Qualitätssicherung Spez 2 1 3KON-ALLG Vorbereitung IT-Konzept: Nutzungskonzept/EHB für Access, Pattern IT-Konzept, 5 2 7KON-A Stammdatendialoge Kon Dialog: Pflege Skilehrer 0,5 0,5 1KON-A Stammdatendialoge Kon Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 0,5 0,5 1KON-A Stammdatendialoge Kon Dialog: Pflege Stammdaten Skischule 0,5 0,5 1KON-A Kursplanung & -abwicklung Kon Dialog: Verfügbarkeit Skilehrer 0,5 0,5 1KON-A Kursplanung & -abwicklung Kon Dialog: Skikurse anlegen/pflegen 1 0,5 1,5KON-A Kursplanung & -abwicklung Kon Dialog: Kursbuchung 1 0,5 1,5KON-A Kursplanung & -abwicklung Kon Dialog: Fakturierung 1 0,5 1,5KON-A Druckausgaben Rechnung 0,5 0,5 1KON-A Druckausgaben Übersicht über alle Kurse 0,5 0,5 1KON-A Druckausgaben Übersicht zu einem Kurs 0,5 0,5 1KON-QS Qualitätssicherung IT-Konzept 1 0 1REA-A Stammdatendialoge Pflege Skilehrer 1 1 2REA-A Stammdatendialoge Pflege Kurstypen (Art, Übungen, Preise etc.) 3 1 4REA-A Stammdatendialoge Pflege Stammdaten Skischule 1 1 2REA-A Kursplanung & -abwicklung Verfügbarkeit Skilehrer (Planung) 2 0,5 2,5REA-A Kursplanung & -abwicklung Skikurse anlegen/pflegen (Planung) 3 0,5 3,5REA-A Kursplanung & -abwicklung Kursbuchung 7 2 9REA-A Kursplanung & -abwicklung Fakturierung 4 1 5REA-A Druckausgaben Rechnung in Word 4 1 5REA-A Druckausgaben Übersicht über alle Kurse (Access Bericht) 1,5 0,5 2REA-A Druckausgaben Übersicht zu einem Kurs (Access Bericht) 1,5 0,5 2REA-DB Aufbau DB 3 1 4REA-QS Codereviews 2 2INT-TVO Testfälle & Testkonzept erstellen 5 1 6
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung25
Zuschläge für Querschnittsaufgaben werden konkret geschätzt oder prozentual ermittelt
Querschnittsaufgabe Abschätzung
möglichst konkret schätzen
Mitarbeiter x Laufzeitab 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 LaufzeitReisezeiten bis zu 15 %
Anzahl Meetings x Teilnehmer x Dauer über die LaufzeitMeetings, Präsentationen etc. bis zu 15 %
möglichst Einzelmaßnahmen schätzenTeam-Training
Erfahrungswerte
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung26
Im Kalkulationsschema sind die verschiedenen Anteile des Gesamtaufwands sichtbar
Aufgabe Aufwand [BT]Funktion 1 100Funktion 2 300Funktion 3 200
Nettoaufwand 600
Projektleitung 15% 90Qualitätssicherung 15% 90Team-Training 5% 30Systembetreuung 15% 90Reisezeit 7% 42Einführungsunterstützung 8% 48Querschnittsaufgaben 65% 390
Bruttoaufwand 990
Festpreis-Risikoaufschlag 10% 99Gewährleistung 10% 99
Gesamtaufwand 1.188
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung27
Zur Ermittlung des Nettoaufwands werden die Schätzposten gezählt und bewertet
• leicht• mittel• schwer• Einzelfall 1• Einzelfall 2
• Klassen
Kategorie
2 BT5 BT
10 BT25 BT20 BT
EinzelAufwand Typ Zählbaustein
44 BT75 BT80 BT25 BT20 BT
GesamtAufwand
2215
811
Anzahl
x =• leicht• mittel• schwer• extrem
• Dialoge
3 BT5 BT8 BT
18 BT
39 BT125 BT48 BT36 BT
1325
62
• Batches• Schnittstellen• Tabellen• …
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung28
Als erster Anhaltspunkt für Teamgröße und Projektlaufzeit dient Brooks Faustformel
n = Anzahl der Mitarbeiter
OptimaleMitarbeiter-anzahl
Entwicklungsdauer
Kommunikativer Anteil
Produktiver Anteil (1)
Mehr Abstimmung notwendig
Weniger Arbeits-teilung möglich
Mini-maleDauer
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung29
Die Aufwandsschätzung wird durch ein Mitarbeitergebirge plausibilisiert
• Den Projektablauf mit geschätzter Dauer und Teamgröße skizzieren
• Fläche ausrechnenhier: 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? AnzahlMitarbeiter
0
1
2
3
4
5
6
Jun Jul Aug Sep Okt Nov Dez
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung30
Aus dem Mitarbeitergebirge und dem Gesamtaufwand kanndie 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,74,2 11 18 27 36 45 55 64 74 82 91 99 103 104
In diesem Beispiel wurde der Gesamtaufwand von 104 BMauf 14 Monate verteilt:
Maximum 11 Mitarbeiter, im Schnitt 8,9 Mitarbeiter bzw. 7,4 BM,Teamaufbau und maximale Teamgröße sind vernünftig.
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung31
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 Einkaufslistesonstige Kosten Nur „Durchreichen“ oder
mit Zuschlag
kalkulatorische Vorgabenalle Parameter Konkret oder % von Bruttoaufwand
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung32
Zusammenfassung der Grundsätze
• KonkretMöglichst viele Aufwandsposten werden konkret geschätzt; möglichst wenige durch prozentuale Aufschläge bestimmt.
• SchätzunsicherheitZu 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.
• AufwandsblattDas 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ämissenHä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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung33
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung34
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung35
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 2001IBM1975
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 Points Object
PointsISO "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
Symons1988
UKSMA 1998
Karner1993
ISO 20968:2002
ISO 24570:2005
NESMA
ISO 29881:2008
FiSMA
IFPUG 2004
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung36
Ü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:2003Aktuell: IFPUG 4.2
User oriented: #In, #Out
1999 COSMIC FFP(=COmmon Software Measurement Consortium – Full Function Point)
19761: 2003Aktuell: 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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung38
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
Use Case Points = Bereinigte Use Case Points
Produktivitäts-faktor
Aufwand über alle Phasen1
Σ Use-Case-Gewichte +
...105
15
Use-Case-Gewicht
...15105
Aktoren-Gewicht
1) gemäß Mapping auf Aufwandsmodell
xM-Faktor
Fragebogen mit Kostenfaktoren
xT-Faktor
Fragebogen mit Kostenfaktoren
Überblick UCP-Methode
......mittelProdukt verwalten
einfachKunde verwaltenhochAuftrag verwalten
Kom-plexitätUse Case
Nachbarsystem (Protokoll)Geschäftspartner
......Benutzer-InterfaceHändler
Nachbarsystem (API)Stammdaten
TypAktor
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung39
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung40
Die UCP-Methode wird bei der msg zur Plausibilisierung der Expertenschätzung und bei Nachkalkulationen eingesetzt
AbschlussProjektdurchführungInitialisierungAngebot
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)
21 Angebotsfreigabe
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung41
Die UCP-Methode setzt auf einer Grobspezifikation auf und schätzt die Phasen Feinspezifikation und Umsetzung ab
PN Projektnebenaufwände
ProjektPI Projektinhalt
IB InbetriebnahmeSP Spezifikation
SP-IST IST-Analyse• Analyse von Ist -Systemen• Analyse von Ist -Prozessen
ggf. in Releases
INT IntegrationREA 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-CDChefdesign
PK-QK Qualitäts - und Wissensmanagement• Rolle QB und KB, z. B. auch Pflege ISIS• Steuernde QMS -Aufgaben , QMS -Audits• QM -Pläne
PT-KMKonfigurations -/Releasemanagement• KM aufbauen und pflegen• Build -Management• Auslieferungskoordination, Releaseverantwortung• Installations -CD erstellen• Bestückung von Umgebungen, Transport von Software
PT-SEUSoftware -Entwicklungsumgebung• SEU aufbauen und pflegen• Service, Support, Hotlines
PT-TITechnische Infrastruktur• Einrichten und Installation Server• Netzwerkverbindung• Software -Installationen
PK-MTGorganisat . 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-DOKDokumentationen• Systemdokumentationen• Benutzerhandbücher• Betriebshandbücher•
PK-MTGorganisat . 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 IntegrationREA 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-CDChefdesign
PK-QK Qualitäts - und Wissensmanagement• Rolle QB und KB, z. B. auch Pflege ISIS• Steuernde QMS -Aufgaben , QMS -Audits• QM -Pläne
PT-KMKonfigurations - /Releasemanagement• KM aufbauen und pflegen• Build -Management• Auslieferungskoordination, Releaseverantwortung• Installations -CD erstellen• Bestückung von Umgebungen, Transport von Software
PT-SEUSoftware -Entwicklungsumgebung• SEU aufbauen und pflegen• Service, Support, Hotlines
PT-TITechnische Infrastruktur• Einrichten und Installation Server• Netzwerkverbindung• Software -Installationen
PT-SEUSoftware -Entwicklungsumgebung• SEU aufbauen und pflegen• Service, Support, Hotlines
PT-TITechnische 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-DOKDokumentationen• Systemdokumentationen• Benutzerhandbücher• Betriebshandbücher• Installationshandbuch• Schreiben der Online -Hilfetexte
IB-SCHULSchulungen• 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% UM50-70% UM20-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 ReviewAlle Nacharbeiten zwischen Abnahmeveranstaltung bis zur endgültigen AbnahmeTypisch: Erstellung Fachkonzept V1.1
•
IB QS Durchführung QSReviews von DokumentationenReviews 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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung42
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-Casesklassifizieren
Aktorenklassifizieren
T-Faktorermitteln
M-Faktorermitteln
Aufwandberechnen
1
2
3
4
5
Aufwand =
Systemanforderungen
A-Faktor
Projekteinfluss
x
nicht funktionale Anforderungen
T-Faktor M-Faktor x PFx
funktionale Anforderungen
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung43
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung45
Schätzbeispiel aus der Praxis: Adresse anlegen– Zählen der Schritte –
4. Schritt: Ergeb-nisse Serverauf-rufanzeigen
Adressdatenerfassen
Prüfung auf posta-lische Korrektheit
Adressvergleich zurDublettenprüfung
Vorschlagliste
Auswahl ausVorschlagliste
Neue Adresseanlegen Adresse 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: alternativenAnwendungsfall aufrufen10. Schritt: Serveraufruf (A-
Funktion)
1. Schritt: Dialog „Adressdaten“ anzeigen
8. Schritt: Auswahl der Adresse -Benutzereingaben
5. Schritt: Auswahl der Adresse -Benutzereingaben
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung46
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 signifikantenfachlichen 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.
Adressdatenerfassen
Prüfung auf posta-lische Korrektheit
Adressvergleich zurDublettenprüfung
Vorschlagliste
Auswahl ausVorschlagliste
Neue Adresseanlegen Adresse bearbeiten
Adresse ist nicht korrekt
Adresse ist korrekt
Die Adresse existiertDie Adresse existiert nicht
1. Dialog
3. Dialog2. Dialog
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung47
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.
Adressdatenerfassen
Prüfung auf posta-lische Korrektheit
Adressvergleich zurDublettenprüfung
Vorschlagliste
Auswahl ausVorschlagliste
Neue Adresseanlegen Adresse bearbeiten
Adresse ist nicht korrekt
Adresse ist korrekt
Die Adresse existiertDie Adresse existiert nicht
1. Szenario
3. Szenario
2. Szenario
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung48
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 Adresseanlegen Adresse 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: alternativenAnwendungsfall 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. Dialog2. Dialog
1. Szenario
3. Szenario3. Szenario
2. Szenario2. Szenario
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung49
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 Casesein 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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung50
T-Faktor und M-Faktor normieren auf einfache Weise die technische und organisatorische Komplexität des Projekts
T-Faktor
IFPUG
FPA
4.1
CO
CO
MO
II
UC
P (Karner)
Credit Suisse
UC
P MT230
sd&m
UC
P 1.0
sd&m
Um
frage
Komplexe Berechnungen 1 1 1 1 1Benutzeroberfläche 2 2 1 2 1Schnittstellen 1 1 1 1 1Verteiltes System 1 1 1 1 1Verfügbarkeitsanford. 1 1 1 1Wiederverwendbark. geford. 1 1 1 1 1 ?Performance 2 1 1 1 ?Flexibilität des Systems 1 1 1 1 ?Installation 1 1 1Sicherheitsanforderungen 1 1Anwender-Schulung 1 1Anforderung an Portabilität 1 1Auslastung Zielumgebung 1 2Anzahl Clients 1Betreibbarkeit 1Flexibilität Architektur 1Ähnliche Produkte 1Ausfallsicherheit (Reliability) 1 ?Datenbankgröße 1Tausch Hard-/Software 1Flexibilität d. Entwicklung 1Summe 14 9 13 7 13 5
M-Faktor
IFPUG
FPA 4.1
CO
CO
MO
II
UC
P (Karner)
Credit Suisse
UC
P MT 230
sd&m
UC
P 1.0
sd&m
Um
frage
Stabile Anforderungen 1 1 1
Reife der Prozesse 1 1 1Lstg./Fähigheit Chefdesigner 1 1 1 1Verfügbare Zeit 1 1Teamplayer 1 1Kontinuität Mitarbeiter 1 1Review und Architektur 1 1Anzahl Entscheidungsträger 1 1Integrationsabhängigkeit 1 1Erfahrung Fachlichkeit 1 1 1 1 ?Motivation 1 1Verfügbarkeit Team 1 1Effizienz Programm.sprache 1 1Erfahrung mit RUP 1Erfahrung Objektorientierung 1Erfahrung Werkzeuge 1 ?Erfahrung Plattform/Middlew. 1Verteiltes Arbeiten 1 ?Dokumentation 1Unterstütz. durch Werkzeuge 1Lstg./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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung51
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
M1Leistung/Fähigkeit Chefdesigner
Wie erfahren sind der technische und fachliche Chefdesigner (TCD und FCD) hinsichtlich Aufgabe und Fachlichkeit bzw. Technik)?5: wenig erfahren (0 vergleichbare Projekte als FCD oder TCD durchgeführt)3: erfahren (1 vergleichbares Projekt als FCD oder TCD durchgeführt)1: sehr erfahren (2 vergleichbare Projekte als FCD oder TCD durchgeführt)
3
M4Qualitä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)5: 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 erstellen3: 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 1: 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)?
5: 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)
1: 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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung52
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung53
Ein paar Disclaimer ...
• Use Case Points sind – wie alle Softwaremetriken – keine fürchterlich exakte Wissenschafto Wer mit Use Case Points arbeitest, muss sich auf eine gewisse
Unschärfe einlassen und manchmal von Details abstrahieren
• Use Case Points sind keine Wunderwaffeo „Garbage in – garbage out“ :
Wenn die Schätzbasis so vage oder unvollständig ist, dass ich UseCases 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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung54
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung55
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 systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung56
Vielen Dank für Ihre Aufmerksamkeit
© msg systems ag, 27.10.2014Projektmanagement - Aufwandsschätzung57
Simon Pfeiffer
Lead Business ConsultantGeschäftsbereich Travel & Logistics
Max-Planck-Straße 40, 50354 KölnTel.: +49 2233 9721-0Mobil: +49 151 6242 6844E-Mail: [email protected]
www.msg-systems.com