close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Aufwandsschätzung - AG SEAL

EinbettenHerunterladen
Projektmanagement aus der Praxis der Softwareentwicklung
Vorlesung im Wintersemester 2014/15 an der Technischen Universität Dortmund
2b. Vorlesung am 27.10.2014: Aufwandsschätzung
Simon Pfeiffer
1
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
2
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
3
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Aufwandsschätzungen beruhen immer auf
praktischer Erfahrung und Intuition
Aufgaben
durchführen
Aufwände
messen
Erfahrung kalibrieren
Aufwände (neu) schätzen
4
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
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
0
9
Projekt A´
18
Projekt C
27
Projekt A´´
36
45
Monate
15
Jahre
Experte nach 3,75 Jahren
• Annahme: ein Großprojekt bzw. Programm dauert 3 Jahre:
Projekt A
Projekt B
0
3
Projekt A´
6
Projekt C
9
Projekt A´´
12
Experte nach 15 Jahren 
5
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Schätzdatenbanken mit FSM (Functional Size Measurement)
überwinden die Grenzen der Intuition bei Großprojekten
Projekt 1
Projekt 2
Projekt 3
Schätz-DB
Projekt n + 1
…
Projekt 100
t
6
Normierung/Klassifizie
rung nötig bzgl.:
• Größe (FSM)
• Komplexität
• Umfeld
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Der Kontenrahmen strukturiert Aufgaben nach Aufgabenkategorien
(Beispiel: sd&m AG)
Projekt
PI Projektinhalt
SP Spezifikation
In Releases
UM Umsetzung
KON Konstruktion
100% = Netto
REA Realisierung INT Integration
IB Inbetriebn.
SP-IST
KON-T
REA-T
INT-TVO
IB-ABN
IST-Systemanalyse
Konstruktion der T-Stufen
Realisierung T-Stufen
alle Testvorbereitungen
Abnahme
SP-ALLG
KON-A
REA-A
Konstruktion der A-Stufen
Realisierung A-Stufen
INT-SYS
IB-EIN
KON-DB
REA-DB
Allg. Spezifizikationsaufwände
SP-THEMA
Konstruktion DB-Design &
Datentypen
Spezifikation von Themen
und Daten
KON-MIG
Allg. Konstruktionsaufwand
SP-QS
KON-QS
QS auf Spezifikation
Verbundtest
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.
Schulungen
INT-NFKT
Nicht-Funktionale Tests
QS in der Konstruktion
REA-QS
INT-QS
IB-QS
QS in der REA
Durchführung QS
Durchführung QS
PQ Projektquerschnitt
PK Projektkoordination
PT Projekttechnik
PK-PL
PK-PM
PK-QK
PT-TI
Projektleitung
Projektmanagement
Qualitätsmanagement
Technische Infrastruktur
PK-CD
Chefdesign
PK-MTG
PN Projektneben-PN PN-EIN Einarbeitung, Teamaufbau
aufwände
7
PT-KM
Konfigurations-/
Releasemanagement
PT-SEU
Meetings
SoftwareEntwicklungsumgebung
PN-REISE Reisezeiten
CR
BERAT
Change Requests
Beratung
Ebene 1
IB-DOK
IB-SCHUL
Fehlerbehebung
Migration &
Erstbefüllungen
Für Kennzahlen und
Auswertungen
Einführung & Betrieb
Dokumentationen
INT-BUGFIX
REA-MIG
KON-ALLG
Nacharbeiten (FK V1.1)
INT-VBD
Aufbau und Pflege DB
Konzeption v. Migration etc.
SP-NACH
(Sub-) Systemtest
Ebene 0,
 Die Ebene 1 & 2
definiert die
Aufgabenkategorie
PN-STORT Mehrere Standorte
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Projekt
PI Projektinhalt
SP Spezifikation
In Releases
100% = Netto
UM Umsetzung
KON Konstruktion
REA Realisierung INT Integration
IB Inbetriebn.
SP-IST
KON-T
REA-T
INT-TVO
IB-ABN
IST-Systemanalyse
Konstruktion der T-Stufen
Realisierung T-Stufen
alle Testvorbereitungen
Abnahme
SP-ALLG
KON-A
REA-A
Allg. Spezifizikationsaufwände
Realisierung A-Stufen
INT-SYS
IB-EIN
Konstruktion der A-Stufen
KON-DB
REA-DB
SP-THEMA
Spezifikation von
Themen und Daten
SP-NACH
Konstruktion DB-Design &
Datentypen
Konzeption v. Migration etc.
KON-ALLG
Nacharbeiten (FK V1.1)
Allg. Konstruktionsaufwand
SP-QS
KON-QS
QS auf Spezifikation
Aufbau und Pflege DB
QS in der Konstruktion
INT-VBD
IB-DOK
Verbundtest
Dokumentationen
INT-BUGFIX
REA-MIG
KON-MIG
Einführung &
Betrieb
(Sub-) Systemtest
IB-SCHUL
Fehlerbehebung
Migration &
Erstbefüllungen
Schulungen
INT-NFKT
Nicht-Funktionale Tests
REA-QS
INT-QS
IB-QS
QS in der REA
Durchführung QS
Durchführung QS
PQ Projektquerschnitt
PK Projektkoordination
PT Projekttechnik
PK-PL
PK-PM
PK-QK
PT-TI
Projektleitung
Projektmanagement
Qualitätsmanagement
Technische
Infrastruktur
PK-CD
Chefdesign
Konfigurations-/
Releasemanagement
PT-SEU
PK-MTG
SoftwareEntwicklungsumgebung
Meetings
PN Projektneben- PN PN-EIN Einarbeitung, Teamaufbau PN-REISE Reisezeiten
aufwände
8
PT-KM
CR
BERAT
Change Requests
Beratung
Projektmanagement - Aufwandsschätzung
PN-STORT Mehrere Standorte
© msg systems ag, 27.10.2014
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?
9
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
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,
•
10
-
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.
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Was sind die Instrumente des Aufwandsmodells?
•
Die Instrumente des Aufwandsmodells sind
•
•
•
•
11
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
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Wichtige Anmerkungen zum Kontenrahmen
Projekt
PI
SP
Qualitätssichernde Maßnahmen durch den
Bearbeiter (Entwicklertest, Komponententest)
zählen zum Erstellungsaufwand
In Releases
UM Umsetzung
KON
REA
INT
IB
SP-IST
KON-T
REA-T
INT-TVO
IB-ABN
SP-ALLG
SP-THEMA
KON-A
KON-DB
REA-A
REA-DB
INT-SYS
INT-VBD
IB-EIN
IB-DOK
SP-NACH
KON-MIG
KON-ALLG
REA-MIG
INT-BUGFIX
INT-NFKT
IB-SCHUL
KON-QS
REA-QS
INT-QS
IB-QS
SP-QS
PQ
PK
PK-PL
PK-CD
PN PN PN-EIN
CR
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
PT
PK-PM
PK-QK
PT-TI
PK-MTG
PT-KM
PT-SEU
PN-REISE
PN-STORT
BERAT
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
12
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Weitere gängige Begriffe …
FestpreisrisikoZuschlag
GewährleistungsAufschlag
Nettoaufwand
ggf. Zuschlag für Festpreisgarantie als unternehmerische Risiko
(falsche Annahmen, Pönalen, Vertragsforderungen die in Schätzung
vergessen wurden, …)
ggf. Rückstellung für Gewährleistungsforderungen nach der
Abnahme
• Aufwand zur unmittelbaren Erstellung der Projektergebnisse, also des
Projektinhalts (PI)
• ohne Projektquerschnitt (PQ) oder Projektnebenaufwände (PN)
Bruttoaufwand
(= Gesamtaufwand)
13
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
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Wir unterscheiden Bottom-Up undTop-Down Schätzverfahren
Bottom-Up
Top-Down
1
Spezifikation
?
?
FSM
2
€
f (x)

Umsetzung
# Fenster
# Ziegel
14
Projektmanagement - Aufwandsschätzung
€
© msg systems ag, 27.10.2014
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.
15
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Schätzverfahren im Überblick
Algorithmische
Methoden
COCOMO
Function Points
Use Case Points
• 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
Vergleichsmethoden
Kennzahlenmethoden
ExpertenSchätzungen
Analogiemethode
Multiplikatormethoden
Prozentsatzmeth.
Einzelschätzung
Delphi-Methode
Schätzklausur
• Stellt Bezug zu
durchgeführten
Entwicklungsprojekten her
• Keine messbaren
Produktgrößen wie
LoC nötig
• Nachkalkulationen
alter Projekte nötig
• Ähnlich
Analogiemethode,
allerdings braucht
man Messdaten
abgeschlossener
Projekte
Top-Down
16
Projektmanagement - Aufwandsschätzung
• Greifen wenn möglich
auf Analogiemethode
zurück
• Erstmalige Schätzung
neuer Anforderungen
durch Expertenwissen
Bottom-Up
© msg systems ag, 27.10.2014
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
17
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Experten-Schätzungen stellen ein weit verbreitetes Verfahren
für alle Arten von Entwicklungsprojekten dar
• Systematische Bottom-Up Schätzung von
„Prognosen
sind besonders dann schwierig, wenn
sie sich auf die Zukunft beziehen.“
18
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 ExpertenSchä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
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Experten-Schätzung –
Vertiefende Informationen: Gegenüberstellung der Varianten
Einzelschätzung
Delphi-Methode
• Ein einziger Experte legt die
Schätzwerte für einen
bestimmten Aufwandsposten
fest.
• Mehrere Experten führen ihre
Schätzung anonym und ohne
Abstimmung untereinander
durch.
• Genauigkeit hängt wesentlich
von der Erfahrung dieses
Experten ab.
• Hohe Verantwortung für eine
Person
• Einseitige Beurteilung von
Aufwänden und
Unsicherheiten
Pragmatisch aber
leicht ungenau
19
• 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
Verlässlich aber sehr
zeitaufwändig
Projektmanagement - Aufwandsschätzung
Schätzklausur
• 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
Besser als Mittelwerte aber
ebenfalls zeitaufwändig
© msg systems ag, 27.10.2014
Die Aufwandsschätzung besteht aus mehreren Schritten
20
Tätigkeit
Ergebnis
• Zerlegung in Aufgaben (Stückliste)
• Aufgaben einzeln schätzen
• mehrere unabhängige Schätzungen
Nettoaufwand
+ Querschnittsaufwände als
%-Erfahrungswerte
Bruttoaufwand
Bewertung mit kalkulierten Stundensätzen,
+ FP-Risiko + Gewährleistung
Gesamtbudget
Plausibilisieren durch
• Projektplan und Mitarbeitergebirge
• Verhältnis der Projektphasen
• Vergleichsprojekte
Plausibilisiertes Budget
Soll - / Ist-Vergleich
Budgethochrechnung
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Alles, was Aufwand macht, …
Aufwandsposten
(Schätzposten)
21
•
•
•
•
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
Arbeitsergebnis
Deliverable
Ergebnis
z. B. Fachkonzept, Dialog,
Systemdokumentation
sonstige
Tätigkeiten
z. B. Review durchführen,
Projektleitung, Meeting,
Kickoff-Veranstaltung
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Wir schätzen Aufwände in Bearbeitertagen (BT) zu 8 h
• Ein Aufwand von 1 Bearbeitertag (BT)
muss in 8 Stunden (!) erbracht werden
können – nicht in einem 10-StundenTag
(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
22
Planungs- und Schätzungssicht
1 BT
8 Bh
1 BW
40 Bh
1 BW = 5 BT
1 BM
160 Bh
1 BM = 20 BT
1 BJ
1600 Bh
1 BJ = 10 BM
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Für jeden Schätzposten wird Aufwand und Schätzunsicherheit
ermittelt
Gesamtaufwand := Schätzung + Aufwandsrisiko
Vorgehen zur Ermittlung des Aufwands und des Schätzrisikos unter
Zuhilfenahme eines Schätzverfahrens.
Schätzung
[Bh, BT]
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]
23
X% der Schätzunsicherheit.
Die Schätzunsicherheiten wird nicht bei jedem Aufwandsposten
zuschlagen, die Festlegung hängt von der Einschätzung des
Angebotsverantwortlichen ab.
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Beispiel: Strukturierung einer Stückliste
Thema/
Komponente
Schätzposten (Arbeitspaket/Aktivität)
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
SP-THEMA
Register Visa
SP-THEMA
SP-THEMA
Register Visa
Register Visa
SP-THEMA
SP-THEMA
Register Visa
Register Visa
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
Visa-Regelwerk
Visa-Regelwerk
Visa-Regelwerk
Visa-Regelwerk
Spezifikation der Protokollierung durch das Register
(Wahrscheinlich ein AWF zum Protokollieren und einen
zum Abfragen, Exportschnittstelle)
Spezifikation der Komponenten Administration und
Datenpflege
Spezifikation der Komponente Fristenkontrolle
Spezifikation der Komponente Bereitstellung Analyse
(Schnittstellenbeschreibung oder Druckausgabe für
Rohdatenexport, AWF zum Exportieren, ggf. AWF/Enitäten
zum Zählen von Kennzahlen)
Spezifikation Datenmodells für das Register Visa
Dokumentenquerschnitt mit Einleitung, Referenzen, NFAs
usw.
Überarbeitung bestehende Regeln (24)
Identifikation und Ergänzung fehlende Regeln
Berechtigungen prüfen und ergänzen
Schnittstelle Regelkomponente definieren
Konto
24
Schätzung
Projektmanagement - Aufwandsschätzung
8,0
5,0
10,0
9,0
10,0
4,0
12,0
5,0
5,0
3,0
Strukturierung nach den
Aufgabenkategorien des
Aufwandsmodells
Abstrakte, projektspezifische
Strukturierung des Projektinhalts
nach Komponenten & Themen
Projektspezifische Detaillierung
in einzelne Aufwandsposten
(Schätzposten)
Aufwandsschätzung in
Bearbeitertagen (BT)
© msg systems ag, 27.10.2014
In der Stückliste werden alle Schätzposten in BT erfasst und
bereits einer Aufgabenkategorie gemäß Kontenrahmen zugeordnet
Aufgabenkategorie
SP-ALLG
SP-ALLG
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-THEMA
SP-NACH
SP-QS
KON-ALLG
KON-A
KON-A
KON-A
KON-A
KON-A
KON-A
KON-A
KON-A
KON-A
KON-A
KON-QS
REA-A
REA-A
REA-A
REA-A
REA-A
REA-A
REA-A
REA-A
REA-A
REA-A
REA-DB
REA-QS
INT-TVO
25
Thema/Komponente
Stammdatendialoge
Stammdatendialoge
Stammdatendialoge
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Druckausgaben
Druckausgaben
Druckausgaben
Stammdatendialoge
Stammdatendialoge
Stammdatendialoge
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Druckausgaben
Druckausgaben
Druckausgaben
Stammdatendialoge
Stammdatendialoge
Stammdatendialoge
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Kursplanung & -abwicklung
Druckausgaben
Druckausgaben
Druckausgaben
Aufwandsposten
Initialisierung: fachliche Workshops, Themenabgrenzung, Spez-Pattern, etc.
Einleitung, Glossar, Überblick, Redaktion etc.
Spez Dialog: Pflege Skilehrer
Spez Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.)
Spez Dialog: Pflege Stammdaten Skischule
Spez Dialog: Verfügbarkeit Skilehrer
Spez Dialog: Skikurse anlegen/pflegen
Spez Dialog: Kursbuchung
Spez Dialog: Fakturierung
Rechnung
Übersicht über alle Kurse
Übersicht zu einem Kurs
Erstellen Version 1.1
Qualitätssicherung Spez
Vorbereitung IT-Konzept: Nutzungskonzept/EHB für Access, Pattern IT-Konzept,
Kon Dialog: Pflege Skilehrer
Kon Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.)
Kon Dialog: Pflege Stammdaten Skischule
Kon Dialog: Verfügbarkeit Skilehrer
Kon Dialog: Skikurse anlegen/pflegen
Kon Dialog: Kursbuchung
Kon Dialog: Fakturierung
Rechnung
Übersicht über alle Kurse
Übersicht zu einem Kurs
Qualitätssicherung IT-Konzept
Pflege Skilehrer
Pflege Kurstypen (Art, Übungen, Preise etc.)
Pflege Stammdaten Skischule
Verfügbarkeit Skilehrer (Planung)
Skikurse anlegen/pflegen (Planung)
Kursbuchung
Fakturierung
Rechnung in Word
Übersicht über alle Kurse (Access Bericht)
Übersicht zu einem Kurs (Access Bericht)
Aufbau DB
Codereviews
Testfälle & Testkonzept erstellen
Projektmanagement - Aufwandsschätzung
Schätzung
4
3
1
1
1
2
2
4
2
1
1
1
2
2
5
0,5
0,5
0,5
0,5
1
1
1
0,5
0,5
0,5
1
1
3
1
2
3
7
4
4
1,5
1,5
3
2
5
Aufwandsrisiko
Gesamtaufwand
1
1
0,5
0,5
0,5
0,5
0,5
1
1
0,5
0,5
0,5
1
1
2
0,5
0,5
0,5
0,5
0,5
0,5
0,5
0,5
0,5
0,5
0
1
1
1
0,5
0,5
2
1
1
0,5
0,5
1
1
5
4
1,5
1,5
1,5
2,5
2,5
5
3
1,5
1,5
1,5
3
3
7
1
1
1
1
1,5
1,5
1,5
1
1
1
1
2
4
2
2,5
3,5
9
5
5
2
2
4
2
6
© msg systems ag, 27.10.2014
Zuschläge für Querschnittsaufgaben werden konkret geschätzt
oder prozentual ermittelt
26
Querschnittsaufgabe
Abschätzung
Erfahrungswerte
Alle Querschnittsaufgaben
möglichst konkret schätzen
in % vom
Nettoaufwand
Projektleitung
Mitarbeiter x Laufzeit
ab 7 Mitarbeiter ein Vollzeit-PL
10 - 20 %
Chef Design
Mitarbeiter x Laufzeit
Qualitätssicherung
möglichst Einzelmaßnahmen schätzen
10 - 25 %
Software-EntwicklungsUmgebung, Technik
sehr projektspezifisch: Aufbau und lfd.
Support getrennt betrachten
5 - 25 %
Reisezeiten
Anzahl Reisen x durchschn. Reisezeit
über die Laufzeit
bis zu 15 %
Meetings, Präsentationen etc.
Anzahl Meetings x Teilnehmer x Dauer
über die Laufzeit
bis zu 15 %
Team-Training
möglichst Einzelmaßnahmen schätzen
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Im Kalkulationsschema sind die verschiedenen Anteile
des Gesamtaufwands sichtbar
Aufgabe
Aufwand [BT]
Funktion 1
Funktion 2
Funktion 3
Nettoaufwand
Projektleitung
Qualitätssicherung
Team-Training
Systembetreuung
Reisezeit
Einführungsunterstützung
Querschnittsaufgaben
100
300
200
600
15%
15%
5%
15%
7%
8%
65%
Bruttoaufwand
Festpreis-Risikoaufschlag
Gewährleistung
Gesamtaufwand
27
90
90
30
90
42
48
390
990
10%
10%
99
99
1.188
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Zur Ermittlung des Nettoaufwands werden
die Schätzposten gezählt und bewertet
Typ Zählbaustein
•
28
Klassen
•
Dialoge
•
•
•
•
Batches
Schnittstellen
Tabellen
…
Kategorie
•
•
•
•
•
•
•
•
•
leicht
mittel
schwer
Einzelfall 1
Einzelfall 2
leicht
mittel
schwer
extrem
Anzahl
Einzel
Aufwand
Gesamt
Aufwand
22
15
8
1
1
2 BT
5 BT
10 BT
25 BT
20 BT
44 BT
75 BT
80 BT
25 BT
20 BT
13
25
6
2
Projektmanagement - Aufwandsschätzung
x
3 BT
5 BT
8 BT
18 BT
=
39 BT
125 BT
48 BT
36 BT
© msg systems ag, 27.10.2014
Als erster Anhaltspunkt für Teamgröße
und Projektlaufzeit dient Brooks Faustformel
Entwicklungsdauer
Zeit t
Minimale
Dauer
Kommunikativer
Anteil
Weniger Arbeitsteilung möglich
Mehr Abstimmung
notwendig
Produktiver Anteil (1)
Optimale
Mitarbeiteranzahl
Optimale Teamgröße
n = Anzahl der
Mitarbeiter
~
Aufwand in BM
„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“
29
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
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
6
5
4
3
2
1
0
Jun
30
Jul
Projektmanagement - Aufwandsschätzung
Aug
Sep
Okt
Nov
Dez
© msg systems ag, 27.10.2014
Aus dem Mitarbeitergebirge und dem Gesamtaufwand kann
die Projektdauer ermittelt werden
In diesem Beispiel wurde der Gesamtaufwand von 104 BM
auf 14 Monate verteilt:
Maximum 11 Mitarbeiter, im Schnitt 8,9 Mitarbeiter bzw. 7,4 BM,
Teamaufbau und maximale Teamgröße sind vernünftig.
Anzahl MA
12
10
8
6
4
2
0
Anzahl MA
Aufwand [BM] (10/12)
kumulierter Aufwand
31
M
J
J
A
S
O
N
D
J
F
M
A
M
J
5
8
9
10
11
11
11
11
11
10
10
10
5
2
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
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
In die Budgetierung des Projekts fließen – neben dem Aufwand –
weitere Parameter ein
Parameter
Methode
Erfahrungswert
alle Parameter
kalkulatorische Vorgaben
Konkret oder % von
Bruttoaufwand
Stundensatz
Festlegung durch Management;
nach Qualifikation oder
Mischstundensatz
Bruttoaufwand * Stundensatz
durchschn. Stunden / Tag festlegen
Überstunden kalkulieren
8 - 9 h / Tag
Reisekosten
Anzahl Reisen * durchschn. Kosten
bis zu 14 %
Festpreis Risikozuschlag
10 - 25 %
Gewährleistung
3 - 10 %
sonstige Kosten
32
Anschaffungskosten für Hardware,
Software per Einkaufsliste
Projektmanagement - Aufwandsschätzung
Nur „Durchreichen“ oder
mit Zuschlag
© msg systems ag, 27.10.2014
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.
33
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
34
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die Top-Down Schätzung basiert auf der Messung von funktionaler
Größe (FSM) der fachlichen Anforderungen
Top-Down Schätzung
• 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
35
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Entwicklung der funktionalen Größenmessung
De Marco's
Bang Metric
Object
Points
Data Points
DeMarco1982
Sneed1989
Feature
Points
Sneed 1994
3D Function
Points
ISO 1994
Metrics for
Objectory
Boeing 1991 Karner 1993
Jones 1986
ISO "FSM"
Standard
Full Function
Points 1.0
Use Case Points
UCP 1.0 UCP 2.0
Rational 1999
Capgemini sd&m
COSMIC
FPP 2.0
COSMIC
FPP 2.1
ISO 19761:
2003
COSMIC
Version 3.0
COSMIC 2007
Function Point
Analysis
IBM
1975
Albrecht
1979
Function Point
Analysis
Function Point
Analysis 3.4
IFPUG 1990
Albrecht
1984
Function Point
Analysis 4.0
Function Point
Analysis 4.1
IFPUG 1994
IFPUG 1999
Function Point
Analysis 4.1.1
ISO 20926: Function Point
2003
Analysis 4.2
IFPUG 2001
IFPUG 2004
ISO 29881:
2008
Mark II FPA
1.0
Mark II FPA
1.3.1
Symons
1988
1975
1980
1985
ISO 20968:
2002
UKSMA
1998
1990
1995
FiSMA
ISO 24570:
2005
NESMA
2000
2005
2008
Quelle: Lother, M.; Dumke, R.: Points Metrics - Comparison and Analysis. in: Dumke et al (Eds.): Current Trends in Software Measurement –
Proceedings of the 11th IWSM, Montréal, Shaker Verlag. Aachen. pg: 228-267. 2001; ergänzt durch S. Frohnhoff, sd&m AG
36
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Übersicht der wichtigsten FSM-Methoden
(= Functional Size Measurement)
Entstehungsjahr
Methode
1979
Albrecht FPA
(=Function Point
Analysis)
1988
IFPUG FPA
(=International Function
Point User Group)
20926:2003
Aktuell: IFPUG 4.2
www.IFPUG.org
User oriented: #In, #Out
1999
COSMIC FFP
(=COmmon Software
Measurement
Consortium – Full
Function Point)
19761: 2003
Aktuell: COSMICFFP 2.2
Transaction oriented: #Entry,
#Exit, #Read, #Write,
1993 =>1999
UCP
(=Use Case Points)
ISO/IEC
Charakterisierung
# externer Eingaben
# externer Ausgaben
# externer Anfragen
# externer Dateien
# internen Dateien
www.lrgl.uqam.ca
#Use Cases
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 ...
38
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die Use Case Points (UCP) Methode setzt direkt auf einer Use Case
basierten Spezifikation auf und ist sehr einfach anzuwenden
Überblick UCP-Methode
Aufwand über alle Phasen1
Produktivitätsfaktor
M-Faktor
T-Faktor
x
Fragebogen mit
Kostenfaktoren
Fragebogen mit
Kostenfaktoren
x
Use Case Points = Bereinigte Use Case Points
+
Σ Use-Case-Gewichte
Stammdaten
Nachbarsystem (API)
AktorenGewicht
5
Auftrag verwalten
hoch
Use-CaseGewicht
15
Kunde verwalten
einfach
5
Geschäftspartner
Nachbarsystem (Protokoll)
10
Produkt verwalten
mittel
10
Händler
Benutzer-Interface
15
...
...
...
...
...
...
Use Case
ABC Individuelle Analyse
39
Komplexität
Σ Aktoren-Gewichte
Aktor
Berechnung nach Standard-Metrik
(einfach, mittel, komplex)
Typ
Berechnung nach firmeneigener Metrik
Projektmanagement - Aufwandsschätzung
1) gemäß Mapping auf
Aufwandsmodell
© msg systems ag, 27.10.2014
Die erweiterte UCP-Methode (UCP 2.0)
reduziert die Schätzvarianz auf unter 20%
Projekt
Auto 1
UCP-Methode
(nach Karner)
IstAufwand
Aufwand
geschätzt Abwei[h]
UUCP
[h]
chung A-Faktor
4.824
227
6.569
36%
259
Verbesserte Methode
UCP 2.0
Aufwand
geschätzt
T-Faktor M-Faktor
[h]
0,97
1,14
4.978
Abweichung
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
40
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die UCP-Methode wird bei der msg zur Plausibilisierung
der Expertenschätzung und bei Nachkalkulationen eingesetzt
Auftraggeber
Auftragnehmer
Budgetierung/
Ausschreibung
Angebot
Initialisierung
Projektdurchführung
Abschluss
1
1
2
Angebotsfreigabe
2
•
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 UseCase-basiert
41
Projektabschluss
•
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)
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die UCP-Methode setzt auf einer Grobspezifikation auf und
schätzt die Phasen Feinspezifikation und Umsetzung ab
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) :
Projekt
PI Projektinhalt
SP Spezifikation
10-30% PI
SP-IST IST-Analyse
KON-T Konstruktion der T
• Analyse von Ist - Systemen
• Analyse von Ist - Prozessen
SP-THEMASpez. von Themen u. Daten
-Stufen
• Konstruktion der T -Stufen z. B. Tracing,
technische Frameworks…
• Schreiben zentrales IT
-Konzept
• Einarbeiten von Review
- Anmerkungen
-Anmerkungen
Logging , Drucken,
-Stufen
KON-DB Konstruktion DB
-Design & Datentypen
SP-NACHNacharbeiten nach
• Physisches DB -Design
• Konzeption Indexe
• Konzeption übergreifende Datentypen
• Alle Nacharbeiten zwischen
Abnahme
veranstaltung bis zur endgültigen Abnahme
• Typisch: Erstellung Fachkonzept V1.1
Spezifikationsaufwände
• Dokumentenstruktur
• Redaktion und Auslieferung
• Allgemeine Kapitel gem. Spezifikations
Bausteinen z. B. Projektgrundlagen, Ziele &
Rahmenbedingungen, Stufung & Einführung etc.
• Themenübergreifende Workshops
SP-QS QS auf Spezifikation
• Abnahmeveranstaltungen mit Kunden
• Durchführen & Besprechen von
Reviews
• Schreibtischtests
• Konstruktion der A -Stufen z.B. Modulkonstruktion, Dialoge,
Batches, Schnittstellen…
• Einarbeiten von Review
-Anmerkungen
• Feinabstimmungen nach
FK -Abnahme
KON-MIGKonstruktion
Migr . & Einführungsstrategie
• Konzeption von Migration, Einführungsstrategie &
Erstbefüllungen
KON-ALLGAllgemeine
REA Realisierung
REA-T Realisierung T
-Stufen
10-25% UM
REA-DB Aufbau und Pflege DB
INT-SYS Durchführung (
• Produktionseinführung
• Installation & Betrieb
• Unterstützung Rollout
INT-VBD Durchführung
Erstbefüllungen
• Realisierung & Test von
Migrationstools
• Erstellen von Skripten zur Erstbefüllung
• Durchführung Migration
IB-EIN Einführung & Betrieb
Sub -)Systemtest
IB-DOKDokumentationen
•
•
•
•
•
Verbundtest
KON-QS Durchführung QS in der Konstruktion
• Durchführung & Besprechen von
Reviews ,
• Review - oder Abnahmeveranstaltungen mit Kunden
• Schreibtischtests
Systemdokumentationen
Benutzerhandbücher
Betriebshandbücher
Installationshandbuch
Schreiben der Online
-Hilfetexte
IB-SCHULSchulungen
• Vorbereitung und Durchführung von
Schulungen
• Schulungsunterlagen
• Train the Trainer
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
0-10% PI
IB-ABN Abnahme
• Nach Vereinbarung:
Unterstützung Abnahmetest
• 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.
REA-MIGDurchführung Migration &
IB Inbetriebnahme
• Alle Testkonzepte und Testdaten
• Testfallerstellung
• Konzept/Tools Fehlerverfolgung
• Testtools (Evaluierung, Realisierung…)
• 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
• Realisierung DDLs etc.
• DB -Admin -Aufgaben
• Übergreifende Datentypen realisieren
INT-BUGFIXFehlersuche & Fehlerbehebung
• Bugfixing aus System
• Performancetuning
- , Verbund - und Abnahmetest
INT-NFKTnichtfunktionale Tests
• Z. B. Last -, Performance
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)
-, Ausfalltests
INT-QS Durchführung QS
• Reviews auf Testkonzepte u. ä.
• Reviews auf Testfälle
IB QS Durchführung QS
Reviews von Dokumentationen
• Reviews von Schulungsunterlagen
25-60% PI
20- 50% PI
PK-PL Projektleitung & Teilprojektleitung
PK-CDChefdesign
INT Integration
INT-TVO alle Testvorbereitungen
-Stufen
• Codieren incl. Persistenz & Datentypen
• Modul - und Komponententests incl. Bugfix
• Einarbeiten von
Code - Reviews
PQ Projektquerschnitt
PK Projektkoordination
• Jede Teamführung (auch von Test
• Planung und Controlling
• Risikomanagement
• Abstimmung Parallelprojekte
50-70% UM
• Codieren incl. Persistenz & Datentypen
• Modul - und Komponententests incl. Bugfix
• Einarbeiten von
Code - Reviews
REA-A Realisierung A
KON-A Konstruktion der A
Review
100% =Netto
60-90% PI
20-30% UM
• Spezifikation der fachlichen Themen bis
Abnahme
• Spezifikation des logischen Datenmodells
• Testfallerstellung
• Alle notwendigen Abstimmungen dazu
• Einarbeiten von internen Review
-Anmerkungen
(Abgrenzung: SP -NACH )
SP-ALLGAllg.
ohneFP-Risiko! Systemerstellung Brutto
=
ggf. in Releases
UM Umsetzung
KON Konstruktion
-Teams)
- Teams)
PK-PM Projektmanagement
• Kunden - und Risikomanagement
• Gremienarbeit, Erwartungsmanagement
• Controlling auf PM -Ebene
• Trouble -Shooting
• Fachliches und Technisches Chefdesign
• Auch Teamdesign
PN Projektnebenaufwände
PN PN-EIN
• Inhaltliche Arbeit ist in der
bzw. SP zu berücksichtigen
PK-QK Qualitäts
- und Wissensmanagement
• Rolle QB und KB, z. B. auch Pflege ISIS
• Steuernde QMS -Aufgaben , QMS -Audits
• QM -Pläne
PK-MTGorganisat
. Meetings und Workshops
• Statusmeetings, Kickoff,
Touchdown , Schätzworkshops
 PI )
• Keine fachlichen Meetings (
PT
5-15% PI
Projekttechnik
PT-KMKonfigurations
--/Releasemanagement
/Releasemanagement
• KM aufbauen und pflegen
• Build - Management
• Auslieferungskoordination,
Releaseverantwortung
• Installations -CD erstellen
• Bestückung von Umgebungen, Transport von Software
PT-TI Technische Infrastruktur
• Einrichten und Installation Server
• Netzwerkverbindung
• Software -Installationen
PT-SEUSoftware
-Entwicklungsumgebung
• SEU aufbauen und pflegen
• Service, Support, Hotlines
0-30% PI
Einarbeitung (fachlich/technisch)
• Auch Teamaufbau, Teamfindung, insb. bei steilem Teamaufbau in Gr
• Der „gefühlte“ Einarbeitungsaufwand, keine Pauschalen
oßprojekten
1) SP ohne Aufwände für Grobspezifikation
42
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die UCP-Schätzung erfolgt in 5 Schritten und differenziert nach
Systemanforderungen und Projekteinfluss
1
2
Use-Cases
klassifizieren
Aktoren
klassifizieren
• 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. abwendungsfachlichen 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
3
T-Faktor
ermitteln
• 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
4
M-Faktor
ermitteln
5
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
Projekteinfluss
Systemanforderungen
Aufwand
berechnen
Aufwand =
A-Faktor
x
T-Faktor
x
M-Faktor x PF
nicht funktionale
funktionale
Anforderungen Anforderungen
43
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
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
Einfach
5
4–7
Mittel
10
>= 8
Hoch
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
45
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Schätzbeispiel aus der Praxis: Adresse anlegen
– Zählen der Schritte –
1. Schritt: Dialog „Adressdaten“
anzeigen
4. Schritt: Ergebnisse Serveraufrufanzeigen
2. Schritt: Benutzereingaben
Prüfung auf postalische Korrektheit
3. Schritt: Serveraufruf
(A-Funktion)
Adresse ist nicht korrekt
Adresse ist korrekt
Auswahl aus
Vorschlagliste
5. Schritt: Auswahl der Adresse Benutzereingaben
Adressdaten
erfassen
Adressvergleich zur
Dublettenprüfung
6. Schritt: Serveraufruf
(A-Funktion)
Vorschlagliste
7. Schritt: Ergebnisse Serveraufruf
anzeigen
Die Adresse existiert nicht
Die Adresse existiert
8. Schritt: Auswahl der Adresse Benutzereingaben
Neue Adresse
anlegen
Adresse bearbeiten
9. Schritt: alternativen
Anwendungsfall aufrufen
10. Schritt: Serveraufruf (AFunktion)
46
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Schätzbeispiel aus der Praxis: Adresse anlegen
– Zählen der Dialoge –
1. Dialog
Zählregeln: Anzahl Dialoge
• Hier wird die Anzahl der unterschiedlichen
Adressdaten
erfassen
Dialoge des Use Case gezählt.
Prüfung auf postalische Korrektheit
Adresse ist nicht korrekt
Adresse ist korrekt
Auswahl aus
Vorschlagliste
Adressvergleich zur
Dublettenprüfung
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.
2. Dialog
3. Dialog
Vorschlagliste
Die Adresse existiert nicht
Neue Adresse
anlegen
47
• Dialoge werden wie folgt gezählt:
• Jeder Reiter eines Dialogs (mit signifikanten
Die Adresse existiert
Adresse bearbeiten
• Druckstücke werden auch als Dialoge gezählt
• Hinweis: Derzeit deckt die Methode
Kompexitätsunterschiede bei
unterschiedlichen Dialogarten noch nicht gut
ab.
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Schätzbeispiel aus der Praxis: Adresse anlegen
– Zählen der Szenarien –
1. Szenario
Erfolgs-Szenarien und nichttrivialen
Fehlerszenarien im Use Case gezählt.
Adressdaten
erfassen
Prüfung auf postalische Korrektheit
2. Szenario
Adresse ist nicht korrekt
Adresse ist korrekt
Auswahl aus
Vorschlagliste
Adressvergleich zur
Dublettenprüfung
• 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)
Vorschlagliste
Die Adresse existiert nicht
Zählregeln: Anzahl Szenarien
• Hier wird die Anzahl der unterschiedlichen
Die Adresse existiert
• Fehlerszenarien sind solche, die nicht zum
Erfolg (Erreichen des Business Goal) führen
Neue Adresse
anlegen
Adresse bearbeiten
• fachliche Fehlerszenarien werden gezählt
(wenn fachliche Schritte zur
Fehlerbehandlung durchlaufen werden)
• triviale Fehlerszenarien, z.B. „Anzeige
3. Szenario
48
einer Meldung, dann Abbruch“ werden
nicht gezählt.
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die Größe / Komplexität eines Use Cases wird durch
dessen Anzahl Schritte, Dialoge und Szenarien normiert
1. Schritt: Dialog „Adressdaten“
Ergebnis für Use Case Adresse anlegen:
2. Schritt: Benutzereingaben
•
10 Schritte
•
3 Dialoge
•
3 Szenarien
1. Szenario
anzeigen
Adressdaten
erfassen
1. Dialog
Prüfung auf postalische Korrektheit
2. Szenario
4. Schritt: Ergebnisse Serveraufrufanzeigen
Adresse ist nicht korrekt
Adresse ist korrekt
Auswahl aus
Vorschlagliste
Adressvergleich zur
Dublettenprüfung
6. Schritt: Serveraufruf
(A-Funktion)
Vorschlagliste
7. Schritt: Ergebnisse
Serveraufruf anzeigen
2. Dialog
3. Dialog
5. Schritt: Auswahl der Adresse Benutzereingaben
3. Schritt: Serveraufruf
(A-Funktion)
Die Adresse existiert nicht
Die Adresse existiert
8. Schritt: Auswahl der Adresse Benutzereingaben
Neue Adresse
anlegen
10. Schritt: Serveraufruf (AFunktion)
MAX
(# Schritte
# Dialoge
# Szenarien)
Komplexität
Punkte
Adresse bearbeiten
9. Schritt: alternativen
Anwendungsfall aufrufen
3. Szenario
0–3
Einfach
5
4–7
Mittel
10
>= 8
Hoch
15
hohe Komplexität = 15 Use Case Points
49
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Best Practice: Der richtige Schnitt von Use Cases
• Wichtig für eine verlässliche Schätzung ist eine einheitliche und angemessene
•
•
•
•
•
50
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.
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
T-Faktor und M-Faktor normieren auf einfache Weise die technische
und organisatorische Komplexität des Projekts
?
13
7
13
5
1
1
1
1
1
1
1
0
1
1
1
1
1
1
13
sd&m
Umfrage
1
1
1
1
1
9
Reife der Prozesse
Lstg./Fähigheit Chefdesigner
Verfügbare Zeit
Teamplayer
Kontinuität Mitarbeiter
Review und Architektur
Anzahl Entscheidungsträger
Integrationsabhängigkeit
Erfahrung Fachlichkeit
Motivation
Verfügbarkeit Team
Effizienz Programm.sprache
Erfahrung mit RUP
Erfahrung Objektorientierung
Erfahrung Werkzeuge
Erfahrung Plattform/Middlew.
Verteiltes Arbeiten
Dokumentation
Unterstütz. durch Werkzeuge
Lstg./Fähigk. Programmierer
Summe
sd&m
UCP 1.0
2
Stabile Anforderungen
1
1
1
1
1
1
1
1
1
1
1
1
1
1
?
1
1
1
1
1
1
Credit Suisse
UCP MT 230
14
1
1
1
1
1
1
1
Kostenfaktor
UCP (Karner)
1
1
1
1
1
1
1
1
1
?
?
?
COCOMO II
1
1
2
1
1
1
1
1
1
1
1
1
1
M-Faktor
IFPUG FPA 4.1
1
2
1
1
1
2
1
1
1
1
1
1
1
1
1
1
sd&m
Umfrage
1
sd&m
UCP 1.0
1
2
1
1
Credit Suisse
UCP MT230
UCP (Karner)
Komplexe Berechnungen
Benutzeroberfläche
Schnittstellen
Verteiltes System
Verfügbarkeitsanford.
Wiederverwendbark. geford.
Performance
Flexibilität des Systems
Installation
Sicherheitsanforderungen
Anwender-Schulung
Anforderung an Portabilität
Auslastung Zielumgebung
Anzahl Clients
Betreibbarkeit
Flexibilität Architektur
Ähnliche Produkte
Ausfallsicherheit (Reliability)
Datenbankgröße
Tausch Hard-/Software
Flexibilität d. Entwicklung
Summe
COCOMO II
Kostenfaktor
IFPUG FPA
4.1
T-Faktor
1
1
1
1
1
1
1
?
?
8
3
7
?
9
Legende: (Bewertung der Kostenfaktoren aus Sicht der sd&m Umfrage)
relevant
51
?
evtl. relevant aber Streuung zu hoch
fehlt
überflüssig
Projektmanagement - Aufwandsschätzung
nicht relevant
© msg systems ag, 27.10.2014
Zur Bestimmung des M-Faktors wird das Projekt bezüglich
eine Reihe von Einflussgrößen bewertet
Kostenfaktoren im M-Faktor (Ausschnitt)
Nr.
Einflussgröße
Beispielwerte für die Bewertung
Bewertung
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)
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
Qualität von
Workshops notwendig; eine Risikoanalyse muss durchgeführt werden; es sind umfangreiche Arbeiten notwendig,
M4 Grobspezifika-tion um eine T-Architektur zu erstellen
und T-Architektur 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
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
Wie formal sind das Vorgehen und der Entwicklungsprozess im Projekt (bezieht sich auf Aufbau- und
Ablauforganisation)?
Leistung/
M1 Fähigkeit
Chefdesigner
ProzessM5
Overhead
3
3
M-Faktor > 1.0
M-Faktor = 1.0
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)
M-Faktor < 1.0
3
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.)
52
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Die UCP-Methode setzt eine fachliche Größenbestimmung
voraus
Geeignet
Nicht geeignet
•
Individualentwicklung
•
Produktanpassungen
•
Neuentwicklung
•
Wartung, d.h. geringfügige Anpassung
bestehender Systeme
•
Neuentwicklung fachlicher Geschäftsprozesse in betrieblichen Anwendungen
•
Technikstufen, Steuerungssysteme
•
Stammdaten-Pflegesysteme
Fazit
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
53
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
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
54
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
AGENDA
1. Grundlagen und Begriffsdefinitionen
2. Bottom-Up Schätzung (Expertenschätzung)
3. Top-Down Schätzung (Use Case Points)
4. Literatur
55
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Literatur
•
•
•
•
•
•
56
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
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Vielen Dank für Ihre Aufmerksamkeit
Simon Pfeiffer
Lead Business Consultant
Geschäftsbereich Travel & Logistics
Max-Planck-Straße 40, 50354 Köln
Tel.: +49 2233 9721-0
Mobil: +49 151 6242 6844
E-Mail: simon.pfeiffer@msg-systems.com
www.msg-systems.com
57
Projektmanagement - Aufwandsschätzung
© msg systems ag, 27.10.2014
Document
Kategorie
Kunst und Fotos
Seitenansichten
17
Dateigröße
1 031 KB
Tags
1/--Seiten
melden