Aufwandsschätzung und Projektkalkulation von … · Nacharbeiten (FK V1.1) PN PN -EIN Einarbeitung, Teamaufbau PN -REISE Reisezeiten PN -STORT Mehrere Standorte 9 Thomas Engeroff

Thomas Engeroff

Aufwandsschätzung und Projektkalkulation

von Großprojekten

Thomas Engeroff

• Studium der Informatik an der TU Darmstadt

Abschluss mit Schwerpunkt Software Engineering und Nebenfach BWL

• 2001 – 2008: freiberufliche Software Entwicklung & IT Beratung

• 2008 – 2011: bei sd&m als Software-Ingenieur Projektleiter

Abteilung Research: Aufwandsschätzung, insb. Use Case Points (12 Monate)

danach Schwerpunkt Telekomunikation

• seit 2011 bei der der msg systems ag

Project Manager / Berater / Scrum Master

Bereich „Telecommunications & Media“

• Aktuell als Consultant bei der Telekom zur Unterstützung der Projektleitung eines Großprojektes

im Bereich Planungs-/Release-management tätig

Privates

Keine Kinder,

aber… ;) Hobbys: „Kernsanierung“ & Motorrad letzter Urlaub…

AGENDA

1. Grundlagen und Begriffsdefinitionen

2. Bottom-Up Schätzung (Expertenschätzung)

3. Top-Down Schätzung (Use Case Points)

4. Literatur

msg, November 2014 Thomas Engeroff 3

AGENDA




4. Literatur


Aufwandsschätzungen beruhen immer auf

praktischer Erfahrung und Intuition

„Prognosen

sind besonders dann schwierig, wenn

sie sich auf die Zukunft beziehen.“

Aufgaben durchführen

Aufwände messen

Erfahrung kalibrieren Aufwände (neu) schätzen


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


Schätzdatenbanken mit FSM (Funktional Size Measurement)

überwinden die Grenzen der Intuition bei Großprojekten

Projekt 1

Projekt 2

…

t

Schätz-DB

Projekt 100

Projekt 3 Projekt n + 1

Normierung nötig

bzgl.:

• Größe (FSM)

• Komplexität

• Umfeld


Der Kontenrahmen strukturiert Aufgaben nach Aufgabenkategorien

(Beispiel: sd&m AG)

Ebene 0, Für Kennzahlen und

Auswertungen

Ebene 1

Ebene 2 Jedes Projekt schätzt

und erfasst seine

Aufwände auf einer

dieser Ebenen. Ab

einer Projektgröße

von 15 BM ist die

Ebene 2 verbindlich.

Darunter kann

beliebig detailliert

werden.

Die Ebene 1 & 2

definiert die

Aufgabenkategorie

PN Projektneben-

aufwände

Projekt

PI Projektinhalt

IB Inbetriebn. SP Spezifikation

SP-IST

IST-Systemanalyse

In Releases

INT Integration REA Realisierung

KON-T Konstruktion der T-Stufen

UM Umsetzung

PQ Projektquerschnitt

PK Projektkoordination PT Projekttechnik

100% = Netto

PK-PL Projektleitung

PK-PM Projektmanagement

PK-CD Chefdesign

PK-QK Qualitätsmanagement

PT-KM Konfigurations-/

Releasemanagement

PT-SEU Software-

Entwicklungsumgebung

PT-TI Technische Infrastruktur

PK-MTG Meetings

KON Konstruktion

KON-A Konstruktion der A-Stufen

KON-MIG

Konzeption v. Migration etc.

KON-DB Konstruktion DB-Design &

Datentypen

KON-QS QS in der Konstruktion

SP-ALLG Allg. Spezifizikations-

aufwände

SP-THEMA Spezifikation von Themen

und Daten

SP-QS QS auf Spezifikation

REA-DB

Aufbau und Pflege DB

REA-MIG Migration &

Erstbefüllungen

REA-T Realisierung T-Stufen

REA-QS QS in der REA

REA-A Realisierung A-Stufen

INT-VBD Verbundtest

INT-NFKT Nicht-Funktionale Tests

INT-BUGFIX Fehlerbehebung

INT-SYS (Sub-) Systemtest

INT-TVO alle Testvorbereitungen

INT-QS Durchführung QS

IB-ABN Abnahme

IB-EIN Einführung & Betrieb

IB-DOK Dokumentationen

IB-SCHUL Schulungen

IB-QS Durchführung QS

KON-ALLG Allg. Konstruktionsaufwand

CR

Change Requests

BERAT

Beratung

SP-NACH Nacharbeiten (FK V1.1)

PN PN-EIN Einarbeitung, Teamaufbau PN-STORT Mehrere Standorte PN-REISE Reisezeiten


PN Projektneben -

aufw ä nde

Projekt

PI Projektinhalt

IB Inbetriebn . SP Spezifikation

In Releases


UM Umsetzung

PQ Projektquerschnitt

PK Projektkoordination PT Projekttechnik

100% = Netto

PK - PL Projektleitung

PK - PM Projektmanagement

PK - CD Chefdesign

PK - QK Qualit ä tsmanagement

PT - KM Konfigurations - / Releasemanagement

PT - SEU Software - Entwicklungsumgebung

PT - TI Technische Infrastruktur

PK - MTG Meetings

KON Konstruktion

CR BERAT

SP - IST IST - Systemanalyse

KON - T Konstruktion der T - Stufen

KON - A Konstruktion der A - Stufen

KON - MIG Konzeption v. Migration etc.

KON - DB Konstruktion DB - Design & Datentypen

KON - QS QS in der Konstruktion

SP - ALLG Allg. Spezifizikations - aufw ä nde

SP - THEMA Spezifikation von Themen und Daten

SP - QS QS auf Spezifikation

REA - DB Aufbau und Pflege DB

REA - MIG Migration & Erstbef ü llungen

REA - T Realisierung T - Stufen

REA - QS QS in der REA

REA - A Realisierung A - Stufen

INT - VBD Verbundtest

INT - NFKT Nicht - Funktionale Tests

INT - BUGFIX Fehlerbehebung

INT - SYS (Sub - ) Systemtest

INT - TVO alle Testvorbereitungen

INT - QS Durchf ü hrung QS

IB - ABN Abnahme

IB - EIN Einf ü hrung & Betrieb

IB - DOK Dokumentationen

IB - SCHUL Schulungen

IB - QS Durchf ü hrung QS

KON - ALLG Allg. Konstruktionsaufwand

SP - NACH Nacharbeiten (FK V1.1)

PN PN - EIN Einarbeitung, Teamaufbau PN - STORT Mehrere Standorte PN - REISE Reisezeiten


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?


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.


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


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


Spezi-

fikation

Um-

setzung

1

2

# Fenster

# Ziegel

€

Bottom-Up

? ?

f (x)

FSM

€

Top-Down

Wir unterscheiden Bottom-Up undTop-Down Schätzverfahren


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.


Schätzverfahren im Überblick

• Aufwandsermittlung

per Formel, in der

Regel empirisch

nachgewiesen

• Basis sind messbare

Produktgrößen, z. B.

LoC, Anforderungen

oder Spezifikation

• Teilw. aufwändig, aber

gute Resultate

• Stellt Bezug zu

durchgeführten

Entwicklungs-

projekten her

• Keine messbaren

Produktgrößen wie

LoC nötig

• Nachkalkulationen

alter Projekte nötig

• Ähnlich

Analogiemethode,

allerdings braucht

man Messdaten

abgeschlossener

Projekte

• Greifen wenn möglich

auf Analogiemethode

zurück

• Erstmalige Schätzung

neuer Anforderungen

durch Expertenwissen

Algorithmische Methoden

Vergleichs- methoden

Kennzahlen- methoden

Experten- Schätzungen

Top-Down Bottom-Up

COCOMO

Function Points

Use Case Points

Analogiemethode

Multiplikator-

methoden

Prozentsatzmeth.

Einzelschätzung

Delphi-Methode

Schätzklausur


AGENDA




4. Literatur


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.“


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


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


Alles, was Aufwand macht, …

Aufwandsposten

(Schätzposten)

Arbeitsergebnis Deliverable Ergebnis

sonstige Tätigkeiten

z. B. Review durchführen, Projektleitung, Meeting, Kickoff-Veranstaltung

• Alle aufwandstragenden Tätigkeiten im Projekt

• Die Liste aller Aufwandsposten gibt die Stückliste

• Nicht jeder Aufwandsposten muss 1:1 ein Arbeitsergebnis sein

• Aufwandsposten müssen nicht mit den späteren Planungseinheiten übereinstimmen

z. B. Fachkonzept, Dialog, Systemdokumentation


Wir schätzen Aufwände in Bearbeitertagen (BT) zu 8 h

Planungs- und Schätzungssicht

1 BT 8 Bh

1 BW 1 BW = 5 BT

1 BM 1 BM = 20 BT

1 BJ = 10 BM 1 BJ

• Ein Aufwand von 1 Bearbeitertag (BT)

muss in 8 Stunden (!) erbracht werden

können – nicht in einem 10-Stunden-

Tag

(oder 24h-Tag ).

• Wir schätzen Rüstzeiten nicht extra,

d.h. in jeder Aufwandszahl sind also

auch Zeiten für Kaffeetrinken, kleinere

Pausen, Mails lesen, Schreibtisch

aufräumen etc. enthalten

40 Bh

160 Bh

1600 Bh


Für jeden Schätzposten wird Aufwand und Schätzunsicherheit

ermittelt

Schätzung

[Bh, BT]

Gesamtaufwand := Schätzung + Aufwandsrisiko

Vorgehen zur Ermittlung des Aufwands und des Schätzrisikos unter

Zuhilfenahme eines Schätzverfahrens.

Grundlage sind in jedem Fall feststehende Anforderungen oder

mindestens als Prämissen dokumentierte Annahmen über

Projektinhalt und Rahmenbedingungen.

Das Ergebnis der Schätzung ist der vollständige Aufwand des Projekts in

Bh oder BT (im Gegensatz zur Kalkulation: €).

Aufwandsrisiko

[Bh, BT]

X% der Schätzunsicherheit.

Die Schätzunsicherheiten wird nicht bei jedem Aufwandsposten

zugeschlagen, die Festlegung hängt von der Einschätzung des

Angebotsverantwortlichen ab.


Beispiel: Strukturierung einer Stückliste

Konto Thema/

Komponente

Schätzposten (Arbeitspaket/Aktivität) Schätzung

SP

SP-THEMA Register Visa Spezifikation der Komponente Visa-Auskunft

(Grundlage sind die bestehenden 4 AWF der Masterspez.)

12,0

SP-THEMA Register Visa Spezifikation der Komponente Visa-Meldung

(Wahrscheinlich 5 AWF in der neuen Spez.)

30,0

SP-THEMA Register Visa Spezifikation der Protokollierung durch das Register

(Wahrscheinlich ein AWF zum Protokollieren und einen

zum Abfragen, Exportschnittstelle)

8,0

SP-THEMA Register Visa Spezifikation der Komponenten Administration und

Datenpflege

5,0

SP-THEMA Register Visa Spezifikation der Komponente Fristenkontrolle 10,0

SP-THEMA Register Visa Spezifikation der Komponente Bereitstellung Analyse

(Schnittstellenbeschreibung oder Druckausgabe für

Rohdatenexport, AWF zum Exportieren, ggf. AWF/Enitäten

zum Zählen von Kennzahlen)

9,0

SP-THEMA Register Visa Spezifikation Datenmodells für das Register Visa 10,0

SP-THEMA Register Visa Dokumentenquerschnitt mit Einleitung, Referenzen, NFAs

usw.

4,0

SP-THEMA Visa-Regelwerk Überarbeitung bestehende Regeln (24) 12,0

SP-THEMA Visa-Regelwerk Identifikation und Ergänzung fehlende Regeln 5,0

SP-THEMA Visa-Regelwerk Berechtigungen prüfen und ergänzen 5,0

SP-THEMA Visa-Regelwerk Schnittstelle Regelkomponente definieren 3,0

Strukturierung nach den

Aufgabenkategorien des

Aufwandsmodells

Projektspezifische Detaillierung

in einzelne Aufwandsposten

(Schätzposten)

Abstrakte, projektspezifische

Strukturierung des Projektinhalts

nach Komponenten & Themen

Aufwandsschätzung in

Bearbeitertagen (BT)


In der Stückliste werden alle Schätzposten in BT erfasst und

bereits einer Aufgabenkategorie gemäß Kontenrahmen zugeordnet

Aufgabenkategorie Thema/Komponente Aufwandsposten Schätzung Aufwandsrisiko Gesamtaufwand

SP-ALLG Initialisierung: fachliche Workshops, Themenabgrenzung, Spez-Pattern, etc. 4 1 5

SP-ALLG Einleitung, Glossar, Überblick, Redaktion etc. 3 1 4

SP-THEMA Stammdatendialoge Spez Dialog: Pflege Skilehrer 1 0,5 1,5

SP-THEMA Stammdatendialoge Spez Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 1 0,5 1,5

SP-THEMA Stammdatendialoge Spez Dialog: Pflege Stammdaten Skischule 1 0,5 1,5

SP-THEMA Kursplanung & -abwicklung Spez Dialog: Verfügbarkeit Skilehrer 2 0,5 2,5

SP-THEMA Kursplanung & -abwicklung Spez Dialog: Skikurse anlegen/pflegen 2 0,5 2,5

SP-THEMA Kursplanung & -abwicklung Spez Dialog: Kursbuchung 4 1 5

SP-THEMA Kursplanung & -abwicklung Spez Dialog: Fakturierung 2 1 3

SP-THEMA Druckausgaben Rechnung 1 0,5 1,5

SP-THEMA Druckausgaben Übersicht über alle Kurse 1 0,5 1,5

SP-THEMA Druckausgaben Übersicht zu einem Kurs 1 0,5 1,5

SP-NACH Erstellen Version 1.1 2 1 3

SP-QS Qualitätssicherung Spez 2 1 3

KON-ALLG Vorbereitung IT-Konzept: Nutzungskonzept/EHB für Access, Pattern IT-Konzept, 5 2 7

KON-A Stammdatendialoge Kon Dialog: Pflege Skilehrer 0,5 0,5 1

KON-A Stammdatendialoge Kon Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 0,5 0,5 1

KON-A Stammdatendialoge Kon Dialog: Pflege Stammdaten Skischule 0,5 0,5 1

KON-A Kursplanung & -abwicklung Kon Dialog: Verfügbarkeit Skilehrer 0,5 0,5 1

KON-A Kursplanung & -abwicklung Kon Dialog: Skikurse anlegen/pflegen 1 0,5 1,5

KON-A Kursplanung & -abwicklung Kon Dialog: Kursbuchung 1 0,5 1,5

KON-A Kursplanung & -abwicklung Kon Dialog: Fakturierung 1 0,5 1,5

KON-A Druckausgaben Rechnung 0,5 0,5 1

KON-A Druckausgaben Übersicht über alle Kurse 0,5 0,5 1

KON-A Druckausgaben Übersicht zu einem Kurs 0,5 0,5 1

KON-QS Qualitätssicherung IT-Konzept 1 0 1

REA-A Stammdatendialoge Pflege Skilehrer 1 1 2

REA-A Stammdatendialoge Pflege Kurstypen (Art, Übungen, Preise etc.) 3 1 4

REA-A Stammdatendialoge Pflege Stammdaten Skischule 1 1 2

REA-A Kursplanung & -abwicklung Verfügbarkeit Skilehrer (Planung) 2 0,5 2,5

REA-A Kursplanung & -abwicklung Skikurse anlegen/pflegen (Planung) 3 0,5 3,5

REA-A Kursplanung & -abwicklung Kursbuchung 7 2 9

REA-A Kursplanung & -abwicklung Fakturierung 4 1 5

REA-A Druckausgaben Rechnung in Word 4 1 5

REA-A Druckausgaben Übersicht über alle Kurse (Access Bericht) 1,5 0,5 2

REA-A Druckausgaben Übersicht zu einem Kurs (Access Bericht) 1,5 0,5 2

REA-DB Aufbau DB 3 1 4

REA-QS Codereviews 2 2

INT-TVO Testfälle & Testkonzept erstellen 5 1 6


Zuschläge für Querschnittsaufgaben werden konkret geschätzt

oder prozentual ermittelt

Querschnittsaufgabe Abschätzung

möglichst konkret schätzen

Mitarbeiter x Laufzeit ab 7 Mitarbeiter ein Vollzeit-PL

Mitarbeiter x Laufzeit

möglichst Einzelmaßnahmen schätzen

sehr projektspezifisch: Aufbau und lfd. Support getrennt betrachten

Alle Querschnittsaufgaben

Projektleitung

Chef Design

Qualitätssicherung

Software-Entwicklungs-Umgebung, Technik

in % vom Nettoaufwand

10 - 20 %

10 - 25 %

5 - 25 %

Anzahl Reisen x durchschn. Reisezeit über die Laufzeit

Reisezeiten bis zu 15 %

Anzahl Meetings x Teilnehmer x Dauer über die Laufzeit

Meetings, Präsentationen etc. bis zu 15 %

möglichst Einzelmaßnahmen schätzen Team-Training

Erfahrungswerte


Im Kalkulationsschema sind die verschiedenen Anteile

des Gesamtaufwands sichtbar

Aufgabe Aufwand [BT]

Funktion 1 100

Funktion 2 300

Funktion 3 200

Nettoaufwand 600

Projektleitung 15% 90

Qualitätssicherung 15% 90

Team-Training 5% 30

Systembetreuung 15% 90

Reisezeit 7% 42

Einführungsunterstützung 8% 48

Querschnittsaufgaben 65% 390

Bruttoaufwand 990

Festpreis-Risikoaufschlag 10% 99

Gewährleistung 10% 99

Gesamtaufwand 1.188


Zur Ermittlung des Nettoaufwands werden

die Schätzposten gezählt und bewertet

• leicht

• mittel

• schwer

• Einzelfall 1

• Einzelfall 2

• Klassen

Kategorie

2 BT

5 BT

10 BT

25 BT

20 BT

Einzel Aufwand Typ Zählbaustein

44 BT

75 BT

80 BT

25 BT

20 BT

Gesamt Aufwand

22

15

8

1

1

Anzahl

x = • leicht

• mittel

• schwer

• extrem

• Dialoge

3 BT

5 BT

8 BT

18 BT

39 BT

125 BT

48 BT

36 BT

13

25

6

2

• Batches

• Schnittstellen

• Tabellen

• …


Verwendete Grundbegriffe der Statistik

• Jede Verteilung von unabhängigen Zufallsvariablen entwickelt sich bei genügend

großer Stichprobenanzahl in Richtung einer Normalverteilung (Gauß-Glocke).

Sie ist typisch für Messungen, die sich aus sehr vielen verschiedenen Einflüssen

zusammensetzen, die man nicht mehr trennen kann. Wir gehen bei der Analyse

der Kennzahlen des Aufwandsmodells vereinfacht von einer Normalverteilung der

Erfahrungswerte aus.

• Der Erwartungs- oder Mittelwert μ einer Normalverteilung ist der Wert mit der

höchsten relativen Wahrscheinlichkeit f. Je weiter man sich vom Mittelwert μ

entfernt, desto unwahrscheinlicher wird dieser Wert in der Praxis zu beobachten

sein.

• Die Standardabweichung σ ist ein Maß für die Streuung um den Mittelwert, sie

beschreibt die Breite der Normalverteilung. 68 % aller Messwerte haben eine

Abweichung von höchstens σ vom Mittelwert, liegen also im 1σ-Bereich um den

Mittelwert.

• Median bezeichnet eine Grenze zwischen zwei Hälften. In der Statistik halbiert

der Median eine Stichprobe. Gegenüber dem Mittelwert hat der Median den

Vorteil, robuster gegenüber Ausreißern zu sein, das gilt insbesondere bei einer

geringen Stichprobenanzahl. In einer echten Normalverteilung sind beide Werte

identisch.

• Die Konfidenz κ ist in ein Maß für die Güte/Präzision des Mittelwerts. Die

Konfidenz wird anhand einer vorgegebenen Wahrscheinlichkeit (1-α) berechnet.

Das Konfidenzintervall um den Mittelwert μ± κ gibt dann den Bereich an, in dem

sich der Mittelwert mit dieser Wahrscheinlichkeit befindet. Ein breites

Konfidenzintervall weißt auf eine zu geringe Stichprobenanzahl hin.

• In der Auswertung des Aufwandsmodells verlangen wir eine Konfidenz von mindestens 5% für das 90%-Konfidenzintervall (Vertrauensintervall mit α = 0,1). Damit legen wir ein Mindestmaß für die Schärfe und Belastbarkeit des Mittelwerts und damit auch des Medians fest.


Die Kennzahlen des Aufwandsmodells

dienen der Plausibilisierung einer Schätzung

• Unter einer Kennzahl verstehen wir jeden Quotienten aus zwei Aufgabenkategorien des Aufwandsmodells. Damit steht hinter jeder Kennzahl eine klare inhaltliche Bedeutung, was die Voraussetzung für einen unternehmensweiten Gebrauch von Kennzahlen darstellt.

• Im Angebotsprofil wird in der Kennzahlenplausi die Schätzung automatisch neben die Erfahrungswerte aus dem Aufwandsmodell der passenden Projektklasse gehalten. Die Kennzahlenplausi unterstützt so die kritische Reflexion der Schätzung.

Projektklasse:

von bis Median

SP / PI 23% 8% 28% 18%

KON / UM 29% 9% 25% 17%

REA / UM 46% 35% 65% 53%

INT / UM 25% 18% 40% 32%

INT-BUGFIX / UM 10% 5% 19% 13%

PK / PI 31% 15% 40% 28%

PL / PI 13% 6% 18% 12%

PM / PI 5% 2% 7% 4%

CD / PI 10% 4% 11% 7%

PT / PI 11% 3% 10% 6%

EIN / PI 3% 2% 7% 4%

QS / PI 3% 2% 7% 5%

<Bitte AKQA-Bezeichnung in 0-Übersicht eintragen>

Kommentar

<bitte Statusdatum in 0-Übersicht pflegen>

alle (Durchschnitt über alle sd&m-Projekte)

(~1σ-Bereich)Kennzahlen Schätzung

Kennzahlenplausibilisierung

Erfahrungswerte aus

Aufw.-Modell


Als erster Anhaltspunkt für Teamgröße

und Projektlaufzeit dient Brooks Faustformel

n = Anzahl der

Mitarbeiter

Optimale

Mitarbeiter-

anzahl

Entwicklungsdauer

Kommunikativer

Anteil

Produktiver Anteil (1)

Mehr Abstimmung

notwendig

Weniger Arbeits-

teilung möglich

Mini-

male

Dauer

Optimale Teamgröße ~ Aufwand in BM

Zeit t

„Der Mann-Monat als Maßstab für den Umfang

des Arbeitsaufwandes ist ein gefährlicher und

irreführender Mythos. Der Begriff will uns

glauben machen, Bearbeiter und Monate seien

austauschbare Faktoren“

Fred Brooks in „Vom Mythos des Mann-Monats“


Die Aufwandsschätzung wird durch ein Mitarbeitergebirge

plausibilisiert

• Den Projektablauf mit geschätzter

Dauer und Teamgröße skizzieren

• Fläche ausrechnen

hier: 30 Zeitmonate (ZtM)

• 1 ZtM = 0,8 BM wegen Feiertagen,

Fortbildung, Krankheit, Meetings, etc.

• Hier ergibt die Umrechnung von ZtM auf BM:

30 * 0,8 = 24 BM

• Passt das zur Aufwandsschätzung? Anzahl

Mitarbeiter

0

1

2

3

4

5

6

Jun Jul Aug Sep Okt Nov Dez


Aus dem Mitarbeitergebirge und dem Gesamtaufwand kann

die Projektdauer ermittelt werden

Anzahl MA

0

2

4

6

8

10

12

Anzahl MA 5 8 9 10 11 11 11 11 11 10 10 10 5 2

M J J A S O N D J F M A M J

Aufwand [BM] (10/12)

kumulierter Aufwand

4,2 6,5 7,3 8,6 9,4 9,4 9,4 9,4 9,4 8,5 8,5 8,1 3,9 1,7

4,2 11 18 27 36 45 55 64 74 82 91 99 103 104

In diesem Beispiel wurde der Gesamtaufwand von 104 BM auf 14 Monate verteilt:

Maximum 11 Mitarbeiter, im Schnitt 8,9 Mitarbeiter bzw. 7,4 BM, Teamaufbau und maximale Teamgröße sind vernünftig.


In die Budgetierung des Projekts fließen – neben dem Aufwand –

weitere Parameter ein

Parameter Methode

Festlegung durch Management; nach Qualifikation oder

Mischstundensatz

durchschn. Stunden / Tag festlegen Überstunden kalkulieren

Anzahl Reisen * durchschn. Kosten

Stundensatz

Bruttoaufwand * Stundensatz

Reisekosten

Festpreis Risikozuschlag

Gewährleistung

Erfahrungswert

8 - 9 h / Tag

bis zu 14 %

10 - 25 %

3 - 10 %

Anschaffungskosten für Hardware, Software per Einkaufsliste

sonstige Kosten Nur „Durchreichen“ oder

mit Zuschlag

kalkulatorische Vorgaben alle Parameter Konkret oder % von

Bruttoaufwand


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.


AGENDA




4. Literatur


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


Entwicklung der funktionalen Größenmessung

Quelle: Lother, M.; Dumke, R.: Points Metrics - Comparison and Analysis. in: Dumke et al (Eds.): Current Trends in Software Measurement –

Proceedings of the 11th IWSM, Montréal, Shaker Verlag. Aachen. pg: 228-267. 2001; ergänzt durch S. Frohnhoff, sd&m AG

DeMarco1982 Sneed1989 Sneed1994 ISO 1994

Jones 1986

IFPUG 1999 IFPUG 2001IBM

1975

Albrecht

1979

IFPUG 1994IFPUG 1990

Boeing 1991

Rational 1999

1995 20001975 1980 1985 1990

Capgemini sd&m

Function Point Analysis

Function Point Analysis

Function Point Analysis 3.4



Function Point Analysis 4.1.1

Mark II FPA1.0

Mark II FPA1.3.1

De Marco'sBang Metric

Data PointsObjectPoints

ISO "FSM"Standard

FeaturePoints

3D FunctionPoints

Metrics forObjectory

Use Case Points

Full FunctionPoints 1.0

COSMICFPP 2.0

COSMICFPP 2.1

COSMICVersion 3.0

ISO 19761:2003

ISO 20926:2003

2005 2008

COSMIC 2007

Albrecht

1984

UCP 1.0 UCP 2.0


Symons

1988

UKSMA

1998

Karner1993

ISO 20968:2002

ISO 24570:2005

NESMA

ISO 29881:2008

FiSMA

IFPUG 2004


Übersicht der wichtigsten FSM-Methoden

(= Functional Size Measurement)

Entstehungsjahr Methode ISO/IEC Charakterisierung

1979 Albrecht FPA

(=Function Point

Analysis)

# externer Eingaben

# externer Ausgaben

# externer Anfragen

# externer Dateien

# internen Dateien

1988 IFPUG FPA

(=International Function

Point User Group)

20926:2003

Aktuell: IFPUG 4.2

User oriented: #In, #Out

1999 COSMIC FFP

(=COmmon Software

Measurement

Consortium – Full

Function Point)

19761: 2003

Aktuell: COSMIC-

FFP 2.2

Transaction oriented: #Entry,

#Exit, #Read, #Write,

1993 =>1999 UCP

(=Use Case Points)

#Use Cases

www.IFPUG.org

www.lrgl.uqam.ca

http://www.ifpug.org/

http://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 ...


Die Use Case Points (UCP) Methode setzt direkt auf einer Use Case

basierten Spezifikation auf und ist sehr einfach anzuwenden

ABC Individuelle Analyse Berechnung nach Standard-Metrik (einfach, mittel, komplex)

Berechnung nach firmeneigener Metrik

Σ Aktoren-Gewichte

= Bereinigte Use Case Points

Aufwand über alle Phasen1

Σ Use-Case-Gewichte +

...

10

5

15

Use-Case-

Gewicht

...

15

5

10

Aktoren-

Gewicht

1) gemäß Mapping auf Aufwandsmodell

x M-Faktor

Fragebogen mit Kostenfaktoren

x T-Faktor

Fragebogen mit Kostenfaktoren

... ...

mittel Produkt verwalten

einfach Kunde verwalten

hoch Auftrag verwalten

Kom-

plexität Use Case

Nachbarsystem (Protokoll) Geschäftspartner

... ...

Benutzer-Interface Händler

Nachbarsystem (API) Stammdaten

Typ Aktor

Produktivitäts-

faktor

A-Faktor

Use Case Points


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


Die UCP-Methode wird bei der msg zur Plausibilisierung

der Expertenschätzung und bei Nachkalkulationen eingesetzt

Abschluss Projektdurchführung Initialisierung Angebot

Budgetierung/

Ausschreibung

1 2

Auftraggeber

Auftragnehmer

Projektabschluss

• Zur Angebotsfreigabe wird die Expertenschätzung

mit der UCP-Schätzung verglichen

• Basis der Schätzung ist eine Grobspezifikation bzw.

Pflichtenheft, das Format ist variabel, aber Use-

Case-basiert

• Zum Projektende wird eine Nachkalkulation

durchgeführt. Der Ist-Aufwand wird mit der

UCP-Schätzung verglichen

• Basis der Nachkalkulation ist die Spezifikation

(Stückliste der Realisierung)

2 1 Angebotsfreigabe


Die UCP-Methode setzt auf einer Grobspezifikation auf und

schätzt die Phasen Feinspezifikation und Umsetzung ab

PN Projektnebenaufwände

Projekt

PI Projektinhalt

IB Inbetriebnahme SP Spezifikation

SP - IST IST - Analyse • Analyse von Ist - Systemen

• Analyse von Ist - Prozessen

ggf. in Releases



• 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


• Kunden - und Risikomanagement

• Gremienarbeit, Erwartungsmanagement

• Controlling auf PM - Ebene

• Trouble - Shooting

PK - CD Chefdesign

PK - QK Qualitäts - und Wissensmanagement

• Rolle QB und KB, z. B. auch Pflege ISIS

• Steuernde QMS - Aufgaben , QMS - Audits

• QM - Pläne

PT - KM Konfigurations - /Releasemanagement

• KM aufbauen und pflegen

• Build - Management

• Auslieferungskoordination, Releaseverantwortung

• Installations - CD erstellen

• Bestückung von Umgebungen, Transport von Software


• SEU aufbauen und pflegen

• Service, Support, Hotlines


• Einrichten und Installation Server

• Netzwerkverbindung

• Software - Installationen

PK - MTG organisat . Meetings und Workshops

• Statusmeetings, Kickoff, Touchdown , Schätzworkshops

• Keine fachlichen Meetings ( PI )

0 - 30% PI

ohne FP - Risiko ! Systemerstellung = Brutto

KON Konstruktion


• Konstruktion der A - Stufen z.B. Modulkonstruktion, Dialoge,

Batches, Schnittstellen…


• Feinabstimmungen nach FK - Abnahme

KON - MIG Konstruktion Migr . & Einführungsstrategie

• Konzeption von Migration, Einführungsstrategie &

Erstbefüllungen


• 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 )


• Abnahmeveranstaltungen mit Kunden

• Durchführen & Besprechen von Reviews



• 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


• 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 )





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


• Alle Testkonzepte und Testdaten


• 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


• Systemdokumentationen

• Benutzerhandbücher

• Betriebshandbücher

•

PK - MTG organisat . Meetings und Workshops

• Statusmeetings, Kickoff, Touchdown , Schätzworkshops

• Keine fachlichen Meetings ( PI )

0 - 30% PI

ohne FP - Risiko ! Systemerstellung = Brutto

KON Konstruktion


• Konstruktion der A - Stufen z.B. Modulkonstruktion, Dialoge,

Batches, Schnittstellen…


• Feinabstimmungen nach FK - Abnahme

KON - MIG Konstruktion Migr . & Einführungsstrategie

• Konzeption von Migration, Einführungsstrategie &

Erstbefüllungen


• 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


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


• Alle notwendigen Abstimmungen dazu

• Einarbeiten von internen Review - Anmerkungen

(Abgrenzung: SP - NACH )


• Abnahmeveranstaltungen mit Kunden

• Durchführen & Besprechen von Reviews



• 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







• Konstruktion der T - Stufen z. B. Tracing, Logging , Drucken,

technische Frameworks…

• Schreiben zentrales IT - Konzept


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


• Kunden - und Risikomanagement

• Gremienarbeit, Erwartungsmanagement

• Controlling auf PM - Ebene

• Trouble - Shooting

PK - CD Chefdesign

PK - QK Qualitäts - und Wissensmanagement

• Rolle QB und KB, z. B. auch Pflege ISIS

• Steuernde QMS - Aufgaben , QMS - Audits

• QM - Pläne

PT - KM Konfigurations - /Releasemanagement

• KM aufbauen und pflegen

• Build - Management

• Auslieferungskoordination, Releaseverantwortung

• Installations - CD erstellen

• Bestückung von Umgebungen, Transport von Software















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 )





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


• Alle Testkonzepte und Testdaten


• 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


• Systemdokumentationen

• Benutzerhandbücher

• Betriebshandbücher

• Installationshandbuch

• Schreiben der Online - Hilfetexte

IB - SCHUL Schulungen

• Vorbereitung und Durchführung von

Schulungen

• Schulungsunterlagen

• Train the Trainer

60 - 90% PI

KON - ALLG Allgemeine Konstruktionsaufwände

• Initialisierung & Gesamtarchitektur

• Technischer Durchstich & Proof of Concept

• Interne Handbücher (Entwicklerhandbuch,

Nutzungskonzepte, Styleguides etc.)

• Redaktion & Auslieferung IT - Konzept

• Allg. Teile im ITK (Einleitung, Glossar, Überblick…)


10 - 25% UM 50 - 70% UM 20 - 30% UM

PN

10 - 30% PI

• Fachliches und Technisches Chefdesign

• Auch Teamdesign

• Inhaltliche Arbeit ist in der

bzw. SP zu berücksichtigen

PN - EIN Einarbeitung (fachlich/technisch)

• Auch Teamaufbau, Teamfindung, insb. bei steilem Teamaufbau in Gr oßprojekten

• Der „gefühlte“ Einarbeitungsaufwand, keine Pauschalen

- •

-

•

SP NACH Nacharbeiten nach Review

Alle Nacharbeiten zwischen Abnahme

veranstaltung bis zur endgültigen Abnahme

Typisch: Erstellung Fachkonzept V1.1

•

IB QS Durchführung QS

Reviews von Dokumentationen

Reviews von Schulungsunterlagen

1) SP ohne Aufwände für Grobspezifikation

Vorbedingung

• Grobspezifikation liegt vor (RUP: Inception)

• Spezifikations-Format ist variabel

Schätzumfang

• Feinspezifikation bis Bereitstellung zur Abnahme

(RUP: Elaboration + Construction)

• inklusive QS-Maßnahmen

• d.h. folgende umrandete Aufwände

aus dem Kontenrahmen1) :


Die UCP-Schätzung erfolgt in 5 Schritten und differenziert nach

Systemanforderungen und Projekteinfluss

• Use Cases beschreiben das Verhalten und die Interaktion eines Systems als Reaktion auf die zielgerichtete Anfrage oder Aktion eines Aktors (menschlicher oder technischer Nutzer des Systems)

Use Cases und Aktoren definieren den funktionalen bzw. abwendungs-fachlichen Umfang des Projekts (= A-Faktor). Dieser wird als Use Case Points erfasst

• Der T-Faktor berücksichtigt die nichtfunktionalen Anforderungen und technologischen Randbedingungen des Projekts. Er wird anhand eines Fragenkatalogs ermittelt

• Der M-Faktor berücksichtig die organisatorische Komplexität und das Umfeld des Projekts. Er wird anhand eines Fragenkatalogs ermittelt

• Über den Produktivitätsfaktor (PF) wird der Aufwand berechnet. Dieser Faktor wurde auf Basis der Nachkalkulationen ermittelt und ist vorgegeben. Der Aufwand umfasst sowohl fachliche als auch technische Komponenten und ist proportional zu den ermittelten Use Case Points

Use-Cases

klassifizieren

Aktoren

klassifizieren

T-Faktor

ermitteln

M-Faktor

ermitteln

Aufwand

berechnen

1

2

3

4

5

Aufwand =

Systemanforderungen

A-Faktor

Projekteinfluss

x

nicht funktionale Anforderungen

T-Faktor M-Faktor x PF x

funktionale Anforderungen


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


Schätzbeispiel aus der Praxis: Adresse anlegen

– Zählen der Schritte –

4. Schritt: Ergeb-

nisse Serverauf-

rufanzeigen

Adressdaten erfassen

Prüfung auf posta- lische Korrektheit

Adressvergleich zur Dublettenprüfung

Vorschlagliste

Auswahl aus Vorschlagliste

Neue Adresse anlegen

Adresse bearbeiten

Adresse ist nicht korrekt

Adresse ist korrekt

Die Adresse existiert Die Adresse existiert nicht

2. Schritt: Benutzereingaben

3. Schritt: Serveraufruf

(A-Funktion)


(A-Funktion)

7. Schritt: Ergebnisse Serveraufruf

anzeigen

9. Schritt: alternativen

Anwendungsfall aufrufen 10. Schritt: Serveraufruf (A-

Funktion)

1. Schritt: Dialog „Adressdaten“

anzeigen

8. Schritt: Auswahl der Adresse -

Benutzereingaben


Benutzereingaben



– Zählen der Dialoge –

Zählregeln: Anzahl Dialoge

• Hier wird die Anzahl der unterschiedlichen Dialoge des Use Case gezählt.

• Dialoge werden wie folgt gezählt:

• Jeder Reiter eines Dialogs (mit siginifikanten fachlichen Unterschieden) wird als eigener Dialog gezählt,

• triviale Pop-Up-Meldungen, Bestätigungen und Menüs werden nicht gezählt,

• Anzeigeseiten werden nur gezählt, wenn Daten eingegeben werden können.

• Druckstücke werden auch als Dialoge gezählt

• Hinweis: Derzeit deckt die Methode Kompexitätsunterschiede bei unterschiedlichen Dialogarten noch nicht gut ab.




Vorschlagliste



Adresse bearbeiten


Adresse ist korrekt


1. Dialog

3. Dialog 2. Dialog



– 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.




Vorschlagliste



Adresse bearbeiten


Adresse ist korrekt


1. Szenario

3. Szenario

2. Szenario


Die Größe / Komplexität eines Use Cases wird durch

dessen Anzahl Schritte, Dialoge und Szenarien normiert

Ergebnis für Use Case Adresse anlegen:

• 10 Schritte

• 3 Dialoge

• 3 Szenarien

MAX

(# Schritte

# Dialoge

# Szenarien)

Komplexität Punkte

0 – 3

4 – 7

>= 8

Einfach

Mittel

Hoch

5

10

15

hohe Komplexität = 15 Use Case Points

4. Schritt: Ergeb-

nisse Serverauf-

rufanzeigen

Adressdatenerfassen

Prüfung auf posta-lische Korrektheit

Adressvergleich zurDublettenprüfung

Vorschlagliste

Auswahl ausVorschlagliste

Neue Adresseanlegen

Adresse bearbeitenNeue Adresse

anlegenAdresse bearbeiten


Adresse ist korrekt

Die Adresse existiertDie Adresse existiert nicht

2. Schritt: Benutzereingaben


(A-Funktion)


(A-Funktion)

7. Schritt: Ergebnisse

Serveraufruf anzeigen

9. Schritt: alternativen

Anwendungsfall aufrufen10. Schritt: Serveraufruf (A-

Funktion)

1. Schritt: Dialog „Adressdaten“

anzeigen


Benutzereingaben


Benutzereingaben

1. Dialog

3. Dialog

2. Dialog

1. Szenario

3. Szenario3. Szenario

2. Szenario2. Szenario


Best Practice: Der richtige Schnitt von Use Cases

• Wichtig für eine verlässliche Schätzung ist eine einheitliche und angemessene Granularität.

• Folgende Hinweise deuten auf einen zu groben Schnitt hin:

• Die textuelle Beschreibung eines Szenarios umfasst mehr als eine DIN-A4-Seite oder

• Ein Szenario enthält mehr als 12 Schritte oder

• Ein Use Case beinhaltet mehr als sieben Szenarien (einzelnen Szenarien sind hier als

eigene Use Cases zu betrachten).

• Folgende Hinweise deuten auf einen zu feinen Schnitt hin:

• Der Use Case enthält keinen Dialog und

• Der Use Case hat nur ein Szenario und

• Der Use Case hat nur einen oder zwei Schritte

• Falls mehr als etwa 20% der Use Cases zu grob oder zu fein sind, ist Vorsicht geboten: Hier

kann die nicht angemessene Granularität das Schätzergebnis verfälschen. Die

entsprechenden Use Cases sollten dann zunächst fachlich geteilt bzw. zusammengezogen

werden.

• Insgesamt ist eine ausgewogene Verteilung von kleinen, mittleren oder großen Use Cases

ein Zeichen für einen "guten" Schnitt.

• Generell gilt, dass Schritte innerhalb eines Use Cases, innerhalb einer Schätzung und

(idealerweise) über alle UCP Schätzungen hinweg etwa gleich groß sein sollten.


T-Faktor und M-Faktor normieren auf einfache Weise die technische

und organisatorische Komplexität des Projekts

T-Faktor

IFP

UG

FP

A

4.1

CO

CO

MO

II

UC

P (K

arn

er)

Cre

dit S

uis

se

UC

P M

T230

sd

&m

UC

P 1

.0

sd

&m

Um

frag

e

Komplexe Berechnungen 1 1 1 1 1

Benutzeroberfläche 2 2 1 2 1

Schnittstellen 1 1 1 1 1

Verteiltes System 1 1 1 1 1

Verfügbarkeitsanford. 1 1 1 1

Wiederverwendbark. geford. 1 1 1 1 1 ?

Performance 2 1 1 1 ?

Flexibilität des Systems 1 1 1 1 ?

Installation 1 1 1

Sicherheitsanforderungen 1 1

Anwender-Schulung 1 1

Anforderung an Portabilität 1 1

Auslastung Zielumgebung 1 2

Anzahl Clients 1

Betreibbarkeit 1

Flexibilität Architektur 1

Ähnliche Produkte 1

Ausfallsicherheit (Reliability) 1 ?

Datenbankgröße 1

Tausch Hard-/Software 1

Flexibilität d. Entwicklung 1

Summe 14 9 13 7 13 5

M-Faktor

IFP

UG

FP

A 4

.1

CO

CO

MO

II

UC

P (K

arn

er)

Cre

dit S

uis

se

UC

P M

T 2

30

sd

&m

UC

P 1

.0

sd

&m

Um

frag

e

Stabile Anforderungen 1 1 1

Reife der Prozesse 1 1 1

Lstg./Fähigheit Chefdesigner 1 1 1 1

Verfügbare Zeit 1 1

Teamplayer 1 1

Kontinuität Mitarbeiter 1 1

Review und Architektur 1 1

Anzahl Entscheidungsträger 1 1

Integrationsabhängigkeit 1 1

Erfahrung Fachlichkeit 1 1 1 1 ?

Motivation 1 1

Verfügbarkeit Team 1 1

Effizienz Programm.sprache 1 1

Erfahrung mit RUP 1

Erfahrung Objektorientierung 1

Erfahrung Werkzeuge 1 ?

Erfahrung Plattform/Middlew. 1

Verteiltes Arbeiten 1 ?

Dokumentation 1

Unterstütz. durch Werkzeuge 1

Lstg./Fähigk. Programmierer 1 ?

Summe 0 13 8 3 7 9

Kostenfaktor Kostenfaktor

relevant fehlt evtl. relevant aber Streuung zu hoch ?

Legende: (Bewertung der Kostenfaktoren aus Sicht der sd&m Umfrage)

überflüssig nicht relevant


Zur Bestimmung des M-Faktors wird das Projekt bezüglich

eine Reihe von Einflussgrößen bewertet

Nr. Einflussgröße Beispielwerte für die Bewertung Bewertung

M1

Leistung/

Fähigkeit

Chefdesigner

Wie erfahren sind der technische und fachliche Chefdesigner (TCD und FCD) hinsichtlich Aufgabe und

Fachlichkeit bzw. Technik)?

0: wenig erfahren (0 vergleichbare Projekte als FCD oder TCD durchgeführt)

3: erfahren (1 vergleichbares Projekt als FCD oder TCD durchgeführt)

5: sehr erfahren (2 vergleichbare Projekte als FCD oder TCD durchgeführt)

3

M4

Qualität von

Grobspezifika-tion

und T-Architektur

Wie nachvollziehbar und detailliert ist die Grobspezifikation und wie gut sind Risiken bekannt? Müssen z.B.

umfangreiche Arbeiten zur Erstellung der T-Architektur durchgeführt (typisch für ein erstes Release) werden oder

sind wichtige „Pflöcke“ schon gesetzt (typisch für eine hohe Releasenummer)

0: die Grobspezifikation enthält zahlreiche Widersprüche und offene Fragen, für die Klärung sind mehrere

Workshops notwendig; eine Risikoanalyse muss durchgeführt werden; es sind umfangreiche Arbeiten notwendig,

um eine T-Architektur zu erstellen

3: die Grobspezifikation enthält offene Fragen, welche mit dem Kunden zu klären sind; eine Risikoanalyse wurde

durchgeführt und es existieren Risiken; die T-Architektur entspricht weitestgehend einer Standardarchitektur oder

wurde in einem vorherigen Release bereits so aufgesetzt

5: die Grobspezifikation ist ausreichend detailliert und lässt keine oder nur sehr wenige Fragen offen; eine

Risikoanalyse wurde durchgeführt und ergab keine nennenswerte Risiken; die T-Architektur existiert

3

M5 Prozess-

Overhead

Wie formal sind das Vorgehen und der Entwicklungsprozess im Projekt (bezieht sich auf Aufbau- und

Ablauforganisation)?

0: komplexer Entwicklungsprozess, d.h. sehr formales Vorgehen und Prozesse, hohe Abstimmungs- und

Querschnittsaufwände, alle Querschnittsrollen besetzt (typisch für Großprojekt mit mehr als 40 Mitarb.)

3: normaler Entwicklungsprozess mit durchschnittlichen Querschnittsaufwänden (typisch für mittelgroßes Projekt,

aber auch für kleine Projekte mit entsprechend formalen Anforderungen des Kunden)

5: schlanker Entwicklungsprozess, d.h. pragmatisches Vorgehen, wenig Dokumentation, keine formalen Reviews

oder Abnahmen, niedrige Querschnittsaufwände (typisch für kleines Projekt mit max. 5 Mitarb.)

3

M-Faktor > 1.0

M-Faktor = 1.0

M-Faktor < 1.0

Kostenfaktoren im M-Faktor (Ausschnitt)


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


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


AGENDA




4. Literatur


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


http://www.msg-systems.com/unt_technologiekomp.0.html





Vielen Dank für Ihre Aufmerksamkeit

Thomas Engeroff Senior Project Manager

Telefon: +49 151 155 255 51

[email protected]

www.msg-systems.com


Documents

Aufwandsschätzung und Projektkalkulation von … · Nacharbeiten (FK V1.1) PN PN -EIN Einarbeitung, Teamaufbau PN -REISE Reisezeiten PN -STORT Mehrere Standorte 9 Thomas Engeroff