Vorlesung im Wintersemester 2015/16 an der … · Nacharbeiten (FK V1.1) PN. PN-EIN. Einarbeitung, Teamaufbau. PN-REISE. Reisezeiten. PN-STORT . ... Rückstellung für Gewährleistungsforderungen

Projektmanagement aus der Praxis der SoftwareentwicklungVorlesung im Wintersemester 2015/16 an der Technischen Universität Dortmund2b. Vorlesung am 02.11.2015: AufwandsschätzungSimon Pfeiffer

© msg systems ag, 02.11.20151 Projektmanagement - Aufwandsschätzung

AGENDA

1. Grundlagen und Begriffsdefinitionen

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

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

4. Literatur

© msg systems ag, 02.11.2015Projektmanagement - Aufwandsschätzung2

AGENDA




4. Literatur


Aufwandsschätzungen beruhen immer auf praktischer Erfahrung und Intuition

Aufgaben durchführen

Aufwändemessen

Erfahrung kalibrierenAufwä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 (Functional Size Measurement) überwinden die Grenzen der Intuition bei Großprojekten

Projekt 1

Projekt 2

…

t

Schätz-DB

Projekt 100

Projekt 3 Projekt n + 1

Normierung/Klassifizierung nötig bzgl.:

• Größe (FSM)• Komplexität• Umfeld


Der Kontenrahmen strukturiert Aufgaben nach Aufgabenkategorien (Beispiel: sd&m AG)

Ebene 0, Für Kennzahlen und Auswertungen

Ebene 1

Ebene 2Jedes Projekt schätztund erfasst seine Aufwände auf einer dieser Ebenen. Ab einer Projektgrößevon 15 BM ist die Ebene 2 verbindlich.Darunter kannbeliebig detailliert werden.

Die Ebene 1 & 2 definiert dieAufgabenkategorie

PN Projektneben-aufwände

ProjektPI Projektinhalt

IB Inbetriebn.SP SpezifikationSP-ISTIST-Systemanalyse

In Releases

INT IntegrationREA RealisierungKON-TKonstruktion der T-Stufen

UM Umsetzung

PQ ProjektquerschnittPK Projektkoordination PT Projekttechnik

100% = Netto

PK-PLProjektleitung

PK-PMProjektmanagement

PK-CDChefdesign

PK-QKQualitätsmanagement

PT-KMKonfigurations-/ Releasemanagement

PT-SEUSoftware-Entwicklungsumgebung

PT-TITechnische Infrastruktur

PK-MTGMeetings

KON Konstruktion

KON-AKonstruktion der A-Stufen

KON-MIGKonzeption v. Migration etc.

KON-DBKonstruktion DB-Design & Datentypen

KON-QSQS in der Konstruktion

SP-ALLGAllg. Spezifizikations-aufwände

SP-THEMASpezifikation von Themen und Daten

SP-QSQS auf Spezifikation

REA-DBAufbau und Pflege DB

REA-MIGMigration & Erstbefüllungen

REA-TRealisierung T-Stufen

REA-QSQS in der REA

REA-ARealisierung A-Stufen

INT-VBDVerbundtest

INT-NFKTNicht-Funktionale Tests

INT-BUGFIXFehlerbehebung

INT-SYS(Sub-) Systemtest

INT-TVOalle Testvorbereitungen

INT-QSDurchführung QS

IB-ABNAbnahme

IB-EINEinführung & Betrieb

IB-DOKDokumentationen

IB-SCHULSchulungen

IB-QSDurchführung QS

KON-ALLGAllg. Konstruktionsaufwand

CRChange Requests

BERATBeratung

SP-NACHNacharbeiten (FK V1.1)

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


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

COCOMOFunction PointsUse Case Points

AnalogiemethodeMultiplikator-

methodenProzentsatzmeth.

EinzelschätzungDelphi-MethodeSchä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)

ArbeitsergebnisDeliverableErgebnis

sonstige Tätigkeiten

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

• Alle aufwandstragenden Tätigkeiten im Projekt• Die Liste aller Aufwandsposten gibt die Stückliste• Nicht jeder Aufwandsposten muss 1:1 ein Arbeitsergebnis sein• Aufwandsposten müssen nicht mit den späteren Planungseinheiten

übereinstimmen

z. B. Fachkonzept, Dialog, Systemdokumentation


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

Planungs- und Schätzungssicht

1 BT 8 Bh

1 BW 1 BW = 5 BT

1 BM 1 BM = 20 BT

1 BJ = 10 BM1 BJ

• Ein Aufwand von 1 Bearbeitertag (BT) muss in 8 Stunden (!) erbracht werden können – nicht in einem 10-Stunden-Tag (oder 24h-Tag ).

• Wir schätzen Rüstzeiten nicht extra, d.h. in jeder Aufwandszahl sind also auch Zeiten für Kaffeetrinken, kleinere Pausen, Mails lesen, Schreibtisch aufräumen etc. enthalten

40 Bh

160 Bh

1600 Bh


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

Schätzung[Bh, BT]

Gesamtaufwand := Schätzung + Aufwandsrisiko

Vorgehen zur Ermittlung des Aufwands und des Schätzrisikos unter Zuhilfenahme eines Schätzverfahrens.

Grundlage sind in jedem Fall feststehende Anforderungen oder mindestens als Prämissen dokumentierte Annahmen über Projektinhalt und Rahmenbedingungen.

Das Ergebnis der Schätzung ist der vollständige Aufwand des Projekts in Bh oder BT (im Gegensatz zur Kalkulation: €).

Aufwandsrisiko[Bh, BT]

X% der Schätzunsicherheit. Die Schätzunsicherheiten wird nicht bei jedem Aufwandsposten zuschlagen, die Festlegung hängt von der Einschätzung des Angebotsverantwortlichen ab.


Beispiel: Strukturierung einer Stückliste

Konto Thema/ Komponente

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

SPSP-THEMA Register Visa Spezifikation der Komponente Visa-Auskunft

(Grundlage sind die bestehenden 4 AWF der Masterspez.)12,0

SP-THEMA Register Visa Spezifikation der Komponente Visa-Meldung(Wahrscheinlich 5 AWF in der neuen Spez.)

30,0

SP-THEMA Register Visa Spezifikation der Protokollierung durch das Register (Wahrscheinlich ein AWF zum Protokollieren und einen zum Abfragen, Exportschnittstelle)

8,0

SP-THEMA Register Visa Spezifikation der Komponenten Administration und Datenpflege

5,0

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

(Schnittstellenbeschreibung oder Druckausgabe für Rohdatenexport, AWF zum Exportieren, ggf. AWF/Enitäten zum Zählen von Kennzahlen)

9,0

SP-THEMA Register Visa Spezifikation Datenmodells für das Register Visa 10,0SP-THEMA Register Visa Dokumentenquerschnitt mit Einleitung, Referenzen, NFAs

usw.4,0

SP-THEMA Visa-Regelwerk Überarbeitung bestehende Regeln (24) 12,0SP-THEMA Visa-Regelwerk Identifikation und Ergänzung fehlende Regeln 5,0SP-THEMA Visa-Regelwerk Berechtigungen prüfen und ergänzen 5,0SP-THEMA Visa-Regelwerk Schnittstelle Regelkomponente definieren 3,0

Strukturierung nach den Aufgabenkategorien des Aufwandsmodells

Projektspezifische Detaillierung in einzelne Aufwandsposten (Schätzposten)

Abstrakte, projektspezifische Strukturierung des Projektinhalts nach Komponenten & Themen

Aufwandsschätzung in Bearbeitertagen (BT)


In der Stückliste werden alle Schätzposten in BT erfasst und bereits einer Aufgabenkategorie gemäß Kontenrahmen zugeordnet

Aufgabenkategorie Thema/Komponente Aufwandsposten Schätzung Aufwandsrisiko GesamtaufwandSP-ALLG Initialisierung: fachliche Workshops, Themenabgrenzung, Spez-Pattern, etc. 4 1 5SP-ALLG Einleitung, Glossar, Überblick, Redaktion etc. 3 1 4SP-THEMA Stammdatendialoge Spez Dialog: Pflege Skilehrer 1 0,5 1,5SP-THEMA Stammdatendialoge Spez Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 1 0,5 1,5SP-THEMA Stammdatendialoge Spez Dialog: Pflege Stammdaten Skischule 1 0,5 1,5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Verfügbarkeit Skilehrer 2 0,5 2,5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Skikurse anlegen/pflegen 2 0,5 2,5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Kursbuchung 4 1 5SP-THEMA Kursplanung & -abwicklung Spez Dialog: Fakturierung 2 1 3SP-THEMA Druckausgaben Rechnung 1 0,5 1,5SP-THEMA Druckausgaben Übersicht über alle Kurse 1 0,5 1,5SP-THEMA Druckausgaben Übersicht zu einem Kurs 1 0,5 1,5SP-NACH Erstellen Version 1.1 2 1 3SP-QS Qualitätssicherung Spez 2 1 3KON-ALLG Vorbereitung IT-Konzept: Nutzungskonzept/EHB für Access, Pattern IT-Konzept, 5 2 7KON-A Stammdatendialoge Kon Dialog: Pflege Skilehrer 0,5 0,5 1KON-A Stammdatendialoge Kon Dialog: Pflege Kurstypen (Art, Übungen, Preise etc.) 0,5 0,5 1KON-A Stammdatendialoge Kon Dialog: Pflege Stammdaten Skischule 0,5 0,5 1KON-A Kursplanung & -abwicklung Kon Dialog: Verfügbarkeit Skilehrer 0,5 0,5 1KON-A Kursplanung & -abwicklung Kon Dialog: Skikurse anlegen/pflegen 1 0,5 1,5KON-A Kursplanung & -abwicklung Kon Dialog: Kursbuchung 1 0,5 1,5KON-A Kursplanung & -abwicklung Kon Dialog: Fakturierung 1 0,5 1,5KON-A Druckausgaben Rechnung 0,5 0,5 1KON-A Druckausgaben Übersicht über alle Kurse 0,5 0,5 1KON-A Druckausgaben Übersicht zu einem Kurs 0,5 0,5 1KON-QS Qualitätssicherung IT-Konzept 1 0 1REA-A Stammdatendialoge Pflege Skilehrer 1 1 2REA-A Stammdatendialoge Pflege Kurstypen (Art, Übungen, Preise etc.) 3 1 4REA-A Stammdatendialoge Pflege Stammdaten Skischule 1 1 2REA-A Kursplanung & -abwicklung Verfügbarkeit Skilehrer (Planung) 2 0,5 2,5REA-A Kursplanung & -abwicklung Skikurse anlegen/pflegen (Planung) 3 0,5 3,5REA-A Kursplanung & -abwicklung Kursbuchung 7 2 9REA-A Kursplanung & -abwicklung Fakturierung 4 1 5REA-A Druckausgaben Rechnung in Word 4 1 5REA-A Druckausgaben Übersicht über alle Kurse (Access Bericht) 1,5 0,5 2REA-A Druckausgaben Übersicht zu einem Kurs (Access Bericht) 1,5 0,5 2REA-DB Aufbau DB 3 1 4REA-QS Codereviews 2 2INT-TVO Testfälle & Testkonzept erstellen 5 1 6


Zuschläge für Querschnittsaufgaben werden konkret geschätzt oder prozentual ermittelt

Querschnittsaufgabe Abschätzung

möglichst konkret schätzen

Mitarbeiter x Laufzeitab 7 Mitarbeiter ein Vollzeit-PL

Mitarbeiter x Laufzeit

möglichst Einzelmaßnahmen schätzen

sehr projektspezifisch: Aufbau und lfd. Support getrennt betrachten

Alle Querschnittsaufgaben

Projektleitung

Chef Design

Qualitätssicherung

Software-Entwicklungs-Umgebung, Technik

in % vom Nettoaufwand

10 - 20 %

10 - 25 %

5 - 25 %

Anzahl Reisen x durchschn. Reisezeit über die LaufzeitReisezeiten bis zu 15 %

Anzahl Meetings x Teilnehmer x Dauer über die LaufzeitMeetings, Präsentationen etc. bis zu 15 %

möglichst Einzelmaßnahmen schätzenTeam-Training

Erfahrungswerte


Im Kalkulationsschema sind die verschiedenen Anteile des Gesamtaufwands sichtbar

Aufgabe Aufwand [BT]Funktion 1 100Funktion 2 300Funktion 3 200

Nettoaufwand 600

Projektleitung 15% 90Qualitätssicherung 15% 90Team-Training 5% 30Systembetreuung 15% 90Reisezeit 7% 42Einführungsunterstützung 8% 48Querschnittsaufgaben 65% 390

Bruttoaufwand 990

Festpreis-Risikoaufschlag 10% 99Gewährleistung 10% 99

Gesamtaufwand 1.188


Zur Ermittlung des Nettoaufwands werden die Schätzposten gezählt und bewertet

• leicht• mittel• schwer• Einzelfall 1• Einzelfall 2

• Klassen

Kategorie

2 BT5 BT

10 BT25 BT20 BT

EinzelAufwand Typ Zählbaustein

44 BT75 BT80 BT25 BT20 BT

GesamtAufwand

2215

811

Anzahl

x =• leicht• mittel• schwer• extrem

• Dialoge

3 BT5 BT8 BT

18 BT

39 BT125 BT

48 BT36 BT

1325

62

• Batches• Schnittstellen• Tabellen• …


Als erster Anhaltspunkt für Teamgröße und Projektlaufzeit dient Brooks Faustformel

n = Anzahl der Mitarbeiter

OptimaleMitarbeiter-anzahl

Entwicklungsdauer

Kommunikativer Anteil

Produktiver Anteil (1)

Mehr Abstimmung notwendig

Weniger Arbeits-teilung möglich

Mini-maleDauer

Optimale Teamgröße ~ Aufwand in BM

Zeit t

„Der Mann-Monat als Maßstab für den Umfang des Arbeitsaufwandes ist ein gefährlicher und irreführender Mythos. Der Begriff will uns glauben machen, Bearbeiter und Monate seien austauschbare Faktoren“

Fred Brooks in „Vom Mythos des Mann-Monats“


Die Aufwandsschätzung wird durch ein Mitarbeitergebirge plausibilisiert

• Den Projektablauf mit geschätzter Dauer und Teamgröße skizzieren

• Fläche ausrechnenhier: 30 Zeitmonate (ZtM)

• 1 ZtM = 0,8 BM wegen Feiertagen, Fortbildung, Krankheit, Meetings, etc.

• Hier ergibt die Umrechnung von ZtM auf BM:30 * 0,8 = 24 BM

• Passt das zur Aufwandsschätzung? AnzahlMitarbeiter

0

1

2

3

4

5

6

Jun Jul Aug Sep Okt Nov Dez


Aus dem Mitarbeitergebirge und dem Gesamtaufwand kanndie Projektdauer ermittelt werden

Anzahl MA

0

2

4

6

8

10

12

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

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

Aufwand [BM] (10/12)kumulierter Aufwand

4,2 6,5 7,3 8,6 9,4 9,4 9,4 9,4 9,4 8,5 8,5 8,1 3,9 1,74,2 11 18 27 36 45 55 64 74 82 91 99 103 104

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

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


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

Parameter Methode

Festlegung durch Management;nach Qualifikation oder

Mischstundensatz

durchschn. Stunden / Tag festlegenÜberstunden kalkulieren

Anzahl Reisen * durchschn. Kosten

Stundensatz

Bruttoaufwand * Stundensatz

Reisekosten

Festpreis Risikozuschlag

Gewährleistung

Erfahrungswert

8 - 9 h / Tag

bis zu 14 %

10 - 25 %

3 - 10 %

Anschaffungskosten für Hardware, Software per Einkaufslistesonstige Kosten Nur „Durchreichen“ oder

mit Zuschlag

kalkulatorische Vorgabenalle Parameter Konkret oder % von Bruttoaufwand


Zusammenfassung der Grundsätze

• KonkretMöglichst viele Aufwandsposten werden konkret geschätzt; möglichst wenige durch prozentuale Aufschläge bestimmt.

• SchätzunsicherheitZu jedem geschätzten Aufwandsposten wird die Schätzunsicherheit festgehalten. Für jeden Schätzposten wird dann aber nur eine Aufwandszahl festgehalten, welche die Grundlage für die spätere Projektplanung und die Kalkulation bildet.

• AufwandsblattDas Ergebnis der Schätzung wird im so genannten Aufwandsblatt dokumentiert.

• VollständigkeitÜber das Aufwandsblatt wird die Vollständigkeit und Plausibilisierung der Zahlen zueinander sichergestellt.

• PrämissenHäufig stößt man an Grenzen (weil etwas nicht sauber spezifiziert ist, weil etwas unklar ist, weil etwas vergessen wurde). In diesem Fall formuliert man Prämissen für die Schätzung, die Grundlage des Angebots werden.


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


Übersicht der wichtigsten FSM-Methoden (= Functional Size Measurement)

Entstehungsjahr Methode ISO/IEC Charakterisierung

1979 Albrecht FPA(=Function Point Analysis)

# externer Eingaben# externer Ausgaben# externer Anfragen# externer Dateien# internen Dateien

1988 IFPUG FPA (=International Function Point User Group)

20926:2003Aktuell: IFPUG 4.2

User oriented: #In, #Out

1999 COSMIC FFP(=COmmon Software Measurement Consortium – Full Function Point)

19761: 2003Aktuell: COSMIC-FFP 2.2

Transaction oriented: #Entry, #Exit, #Read, #Write,

1993 =>1999 UCP(=Use Case Points)

#Use Cases

www.IFPUG.org

www.lrgl.uqam.ca

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

Use Case Points = Bereinigte Use Case Points

Produktivitäts-faktor

Aufwand über alle Phasen1

Σ Use-Case-Gewichte +

...105

15

Use-Case-Gewicht

...15105

Aktoren-Gewicht

1) gemäß Mapping auf Aufwandsmodell

xM-Faktor

Fragebogen mit Kostenfaktoren

xT-Faktor

Fragebogen mit Kostenfaktoren

Überblick UCP-Methode

......mittelProdukt verwalten

einfachKunde verwaltenhochAuftrag verwalten

Kom-plexitätUse Case

Nachbarsystem (Protokoll)Geschäftspartner

......Benutzer-InterfaceHändler

Nachbarsystem (API)Stammdaten

TypAktor


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

AbschlussProjektdurchführungInitialisierungAngebot

Budgetierung/Ausschreibung

1 2

Auftraggeber

Auftragnehmer

Projektabschluss

• Zur Angebotsfreigabe wird die Expertenschätzung mit der UCP-Schätzung verglichen

• Basis der Schätzung ist eine Grobspezifikation bzw. Pflichtenheft, das Format ist variabel, aber Use-Case-basiert

• Zum Projektende wird eine Nachkalkulation durchgeführt. Der Ist-Aufwand wird mit der UCP-Schätzung verglichen

• Basis der Nachkalkulation ist die Spezifikation (Stückliste der Realisierung)

21 Angebotsfreigabe


Die UCP-Methode setzt auf einer Grobspezifikation auf und schätzt die Phasen Feinspezifikation und Umsetzung ab

PN Projektnebenaufwände

ProjektPI Projektinhalt

IB InbetriebnahmeSP Spezifikation

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

ggf. in Releases

INT IntegrationREA Realisierung

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

technische Frameworks…• Schreiben zentrales IT -Konzept• Einarbeiten von Review -Anmerkungen

UM Umsetzung

PQ Projektquerschnitt 25-60% PI

PK Projektkoordination 20- 50% PI PT Projekttechnik 5-15% PI

100% = Netto

0-10% PI

PK-PL Projektleitung & Teilprojektleitung• Jede Teamführung (auch von Test -Teams)• Planung und Controlling• Risikomanagement• Abstimmung Parallelprojekte

PK-PM Projektmanagement• Kunden - und Risikomanagement• Gremienarbeit, Erwartungsmanagement• Controlling auf PM -Ebene • Trouble -Shooting

PK-CDChefdesign

PK-QK Qualitäts - und Wissensmanagement• Rolle QB und KB, z. B. auch Pflege ISIS• Steuernde QMS -Aufgaben , QMS -Audits• QM -Pläne

PT-KMKonfigurations -/Releasemanagement• KM aufbauen und pflegen• Build -Management• Auslieferungskoordination, Releaseverantwortung• Installations -CD erstellen• Bestückung von Umgebungen, Transport von Software

PT-SEUSoftware -Entwicklungsumgebung• SEU aufbauen und pflegen• Service, Support, Hotlines

PT-TITechnische Infrastruktur• Einrichten und Installation Server• Netzwerkverbindung• Software -Installationen

PK-MTGorganisat . Meetings und Workshops• Statusmeetings, Kickoff, Touchdown , Schätzworkshops• Keine fachlichen Meetings ( → PI )

0-30% PI

ohne FP-Risiko! Systemerstellung = Brutto

KON Konstruktion

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

Batches, Schnittstellen…• Einarbeiten von Review -Anmerkungen• Feinabstimmungen nach FK -Abnahme

KON-MIG Konstruktion Migr . & Einführungsstrategie • Konzeption von Migration, Einführungsstrategie &

Erstbefüllungen

KON-DB Konstruktion DB -Design & Datentypen• Physisches DB -Design• Konzeption Indexe• Konzeption übergreifende Datentypen

KON-QS Durchführung QS in der Konstruktion• Durchführung & Besprechen von Reviews , • Review - oder Abnahmeveranstaltungen mit Kunden• Schreibtischtests

SP-ALLG Allg. Spezifikationsaufwände• Dokumentenstruktur• Redaktion und Auslieferung• Allgemeine Kapitel gem. Spezifikations -

Bausteinen z. B. Projektgrundlagen, Ziele & Rahmenbedingungen, Stufung & Einführung etc.

• Themenübergreifende Workshops

SP-THEMA Spez. von Themen u. Daten• Spezifikation der fachlichen Themen bis

Abnahme• Spezifikation des logischen Datenmodells• Testfallerstellung• Alle notwendigen Abstimmungen dazu• Einarbeiten von internen Review -Anmerkungen

(Abgrenzung: SP -NACH )

SP-QS QS auf Spezifikation• Abnahmeveranstaltungen mit Kunden• Durchführen & Besprechen von Reviews• Schreibtischtests

REA-DB Aufbau und Pflege DB• Realisierung DDLs etc.• DB -Admin -Aufgaben• Übergreifende Datentypen realisieren

REA-MIG Durchführung Migration & Erstbefüllungen

• Realisierung & Test von Migrationstools• Erstellen von Skripten zur Erstbefüllung• Durchführung Migration

REA-T Realisierung T -Stufen• Codieren incl. Persistenz & Datentypen• Modul - und Komponententests incl. Bugfix• Einarbeiten von Code -Reviews

REA-QS Durchführung QS in der REA• Code Reviews incl. Durchsprechen• Code Walk -Throughs & sonst. QS -Maßnahmen• Hierzu gehört nicht der Entwicklertest!

(→ REA -T, REA -A)

REA-A Realisierung A -Stufen• Codieren incl. Persistenz & Datentypen• Modul - und Komponententests incl. Bugfix• Einarbeiten von Code -Reviews

INT-VBD Durchführung Verbundtest• Integrativer Test mit allen Nachbarsystemen auf einer

produktionsnahen Umgebung • Fokus auf Systemschnittstellen • kein vollständiger fachlicher Test• Manchmal sind System - und Verbundtest nur

gemeinsam sinnvoll durchzuführen. In diesem Fall wird der Aufwand mit INT -SYS erfasst.

INT-BUGFIX Fehlersuche & Fehlerbehebung• Bugfixing aus System - , Verbund - und Abnahmetest• Performancetuning

INT-NFKT nichtfunktionale Tests• Z. B. Last -, Performance -, Ausfalltests

INT-SYS Durchführung ( Sub -)Systemtest• Systematischer, fachlicher & technischer Test der

integrierten Inkremente/Stufen eines Projekt -Releases , ohne Teilsysteme von anderen Projekten bzw. Drittsysteme.

• Oft durch ein unabhängiges Team• Auch Paralleltests

INT-TVO alle Testvorbereitungen• Alle Testkonzepte und Testdaten• Testfallerstellung• Konzept/Tools Fehlerverfolgung• Testtools (Evaluierung, Realisierung…)

INT-QS Durchführung QS• Reviews auf Testkonzepte u. ä.• Reviews auf Testfälle

IB-ABN Abnahme• Nach Vereinbarung:

Unterstützung Abnahmetest

IB-EIN Einführung & Betrieb• Produktionseinführung• Installation & Betrieb• Unterstützung Rollout

IB-DOKDokumentationen• Systemdokumentationen• Benutzerhandbücher• Betriebshandbücher•

PK-MTGorganisat . Meetings und Workshops• Statusmeetings, Kickoff, Touchdown , Schätzworkshops• Keine fachlichen Meetings ( → PI )

0-30% PI

ohne FP-Risiko! Systemerstellung = Brutto

KON Konstruktion

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

Batches, Schnittstellen…• Einarbeiten von Review -Anmerkungen• Feinabstimmungen nach FK -Abnahme

KON-MIG Konstruktion Migr . & Einführungsstrategie • Konzeption von Migration, Einführungsstrategie &

Erstbefüllungen

KON-DB Konstruktion DB -Design & Datentypen• Physisches DB -Design• Konzeption Indexe• Konzeption übergreifende Datentypen

KON-QS Durchführung QS in der Konstruktion• Durchführung & Besprechen von Reviews , • Review - oder Abnahmeveranstaltungen mit Kunden• Schreibtischtests

SP-ALLG Allg. Spezifikationsaufwände• Dokumentenstruktur• Redaktion und Auslieferung• Allgemeine Kapitel gem. Spezifikations -

Bausteinen z. B. Projektgrundlagen, Ziele & Rahmenbedingungen, Stufung & Einführung etc.

• Themenübergreifende Workshops

SP-THEMA Spez. von Themen u. Daten• Spezifikation der fachlichen Themen bis

Abnahme• Spezifikation des logischen Datenmodells• Testfallerstellung• Alle notwendigen Abstimmungen dazu• Einarbeiten von internen Review -Anmerkungen

(Abgrenzung: SP -NACH )

SP-QS QS auf Spezifikation• Abnahmeveranstaltungen mit Kunden• Durchführen & Besprechen von Reviews• Schreibtischtests

REA-DB Aufbau und Pflege DB• Realisierung DDLs etc.• DB -Admin -Aufgaben• Übergreifende Datentypen realisieren

REA-MIG Durchführung Migration & Erstbefüllungen

• Realisierung & Test von Migrationstools• Erstellen von Skripten zur Erstbefüllung• Durchführung Migration

REA-T Realisierung T -Stufen• Codieren incl. Persistenz & Datentypen• Modul - und Komponententests incl. Bugfix• Einarbeiten von Code -Reviews

INT IntegrationREA Realisierung

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

technische Frameworks…• Schreiben zentrales IT -Konzept• Einarbeiten von Review -Anmerkungen

UM Umsetzung

PQ Projektquerschnitt 25-60% PI

PK Projektkoordination 20- 50% PI PT Projekttechnik 5-15% PI

100% = Netto

0-10% PI

PK-PL Projektleitung & Teilprojektleitung• Jede Teamführung (auch von Test -Teams)• Planung und Controlling• Risikomanagement• Abstimmung Parallelprojekte

PK-PM Projektmanagement• Kunden - und Risikomanagement• Gremienarbeit, Erwartungsmanagement• Controlling auf PM -Ebene • Trouble -Shooting

PK-CDChefdesign

PK-QK Qualitäts - und Wissensmanagement• Rolle QB und KB, z. B. auch Pflege ISIS• Steuernde QMS -Aufgaben , QMS -Audits• QM -Pläne

PT-KMKonfigurations -/Releasemanagement• KM aufbauen und pflegen• Build -Management• Auslieferungskoordination, Releaseverantwortung• Installations -CD erstellen• Bestückung von Umgebungen, Transport von Software





REA-QS Durchführung QS in der REA• Code Reviews incl. Durchsprechen• Code Walk -Throughs & sonst. QS -Maßnahmen• Hierzu gehört nicht der Entwicklertest!

(→ REA -T, REA -A)

REA-A Realisierung A -Stufen• Codieren incl. Persistenz & Datentypen• Modul - und Komponententests incl. Bugfix• Einarbeiten von Code -Reviews

INT-VBD Durchführung Verbundtest• Integrativer Test mit allen Nachbarsystemen auf einer

produktionsnahen Umgebung • Fokus auf Systemschnittstellen • kein vollständiger fachlicher Test• Manchmal sind System - und Verbundtest nur

gemeinsam sinnvoll durchzuführen. In diesem Fall wird der Aufwand mit INT -SYS erfasst.

INT-BUGFIX Fehlersuche & Fehlerbehebung• Bugfixing aus System - , Verbund - und Abnahmetest• Performancetuning

INT-NFKT nichtfunktionale Tests• Z. B. Last -, Performance -, Ausfalltests

INT-SYS Durchführung ( Sub -)Systemtest• Systematischer, fachlicher & technischer Test der

integrierten Inkremente/Stufen eines Projekt -Releases , ohne Teilsysteme von anderen Projekten bzw. Drittsysteme.

• Oft durch ein unabhängiges Team• Auch Paralleltests

INT-TVO alle Testvorbereitungen• Alle Testkonzepte und Testdaten• Testfallerstellung• Konzept/Tools Fehlerverfolgung• Testtools (Evaluierung, Realisierung…)

INT-QS Durchführung QS• Reviews auf Testkonzepte u. ä.• Reviews auf Testfälle

IB-ABN Abnahme• Nach Vereinbarung:

Unterstützung Abnahmetest

IB-EIN Einführung & Betrieb• Produktionseinführung• Installation & Betrieb• Unterstützung Rollout

IB-DOKDokumentationen• Systemdokumentationen• Benutzerhandbücher• Betriebshandbücher• Installationshandbuch• Schreiben der Online -Hilfetexte

IB-SCHULSchulungen• Vorbereitung und Durchführung von

Schulungen• Schulungsunterlagen• Train the Trainer

60-90% PI

KON-ALLG Allgemeine Konstruktionsaufwände• Initialisierung & Gesamtarchitektur• Technischer Durchstich & Proof of Concept• Interne Handbücher (Entwicklerhandbuch,

Nutzungskonzepte, Styleguides etc.)• Redaktion & Auslieferung IT -Konzept• Allg. Teile im ITK (Einleitung, Glossar, Überblick…)• Einarbeiten von Review -Anmerkungen

10-25% UM50-70% UM20-30% UM

PN

10-30% PI

• Fachliches und Technisches Chefdesign• Auch Teamdesign

• Inhaltliche Arbeit ist in der bzw. SP zu berücksichtigen

PN-EIN Einarbeitung (fachlich/technisch)• Auch Teamaufbau, Teamfindung, insb. bei steilem Teamaufbau in Gr oßprojekten• Der „gefühlte“ Einarbeitungsaufwand, keine Pauschalen

-•

-

•

SP NACH Nacharbeiten nach ReviewAlle Nacharbeiten zwischen Abnahmeveranstaltung bis zur endgültigen AbnahmeTypisch: Erstellung Fachkonzept V1.1

•

IB QS Durchführung QSReviews von DokumentationenReviews von Schulungsunterlagen

1) SP ohne Aufwände für Grobspezifikation

Vorbedingung • Grobspezifikation liegt vor (RUP: Inception)• Spezifikations-Format ist variabel

Schätzumfang

• Feinspezifikation bis Bereitstellung zur Abnahme (RUP: Elaboration + Construction)

• inklusive QS-Maßnahmen

• d.h. folgende umrandete Aufwände aus dem Kontenrahmen1) :


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

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

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

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

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

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

Use-Casesklassifizieren

Aktorenklassifizieren

T-Faktorermitteln

M-Faktorermitteln

Aufwandberechnen

1

2

3

4

5

Aufwand =

Systemanforderungen

A-Faktor

Projekteinfluss

x

nicht funktionale Anforderungen

T-Faktor M-Faktor x PFx

funktionale Anforderungen


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

Adressdatenerfassen

Prüfung auf posta-lische Korrektheit

Adressvergleich zurDublettenprüfung

Vorschlagliste

Auswahl ausVorschlagliste

Neue Adresseanlegen Adresse bearbeiten

Adresse ist nicht korrekt

Adresse ist korrekt

Die Adresse existiertDie Adresse existiert nicht

2. Schritt: Benutzereingaben

3. Schritt: Serveraufruf (A-Funktion)


7. Schritt: Ergebnisse Serveraufruf anzeigen

9. Schritt: alternativenAnwendungsfall aufrufen10. Schritt: Serveraufruf (A-

Funktion)

1. Schritt: Dialog „Adressdaten“ anzeigen

8. Schritt: Auswahl der Adresse -Benutzereingaben



Schätzbeispiel aus der Praxis: Adresse anlegen– Zählen der Dialoge –

Zählregeln: Anzahl Dialoge• Hier wird die Anzahl der unterschiedlichen

Dialoge des Use Case gezählt.• Dialoge werden wie folgt gezählt:

• Jeder Reiter eines Dialogs (mit signifikantenfachlichen Unterschieden) wird als eigener Dialog gezählt.

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

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

• Druckstücke werden auch als Dialoge gezählt• Hinweis: Derzeit deckt die Methode

Kompexitätsunterschiede bei unterschiedlichen Dialogarten noch nicht gut ab.

Adressdatenerfassen



Vorschlagliste




Adresse ist korrekt


1. Dialog

3. Dialog2. Dialog


Schätzbeispiel aus der Praxis: Adresse anlegen– Zählen der Szenarien –

Zählregeln: Anzahl Szenarien• Hier wird die Anzahl der unterschiedlichen

Erfolgs-Szenarien und nichttrivialen Fehlerszenarien im Use Case gezählt.

• Ein Erfolgs-Szenario ist ein möglicher fachlicher Ablauf des Use Case, der zum Erfolg (Erreichen des Business Goal) führt, z.B.:• das Haupt-Szenario („Main Flow“) des Use

Case• fachliche Alternativszenarien des Use

Case (triviale Abweichungen, z.B. „Anzeige einer Meldung, dann Abbruch“ werden nicht mitgezählt)

• Fehlerszenarien sind solche, die nicht zum Erfolg (Erreichen des Business Goal) führen• fachliche Fehlerszenarien werden gezählt

(wenn fachliche Schritte zur Fehlerbehandlung durchlaufen werden)

• triviale Fehlerszenarien, z.B. „Anzeige einer Meldung, dann Abbruch“ werden nicht gezählt.

Adressdatenerfassen



Vorschlagliste




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



Vorschlagliste


Neue Adresseanlegen Adresse bearbeitenNeue Adresseanlegen Adresse bearbeiten


Adresse ist korrekt


2. Schritt: Benutzereingaben



7. Schritt: Ergebnisse Serveraufruf anzeigen

9. Schritt: alternativenAnwendungsfall aufrufen10. Schritt: Serveraufruf (A-

Funktion)

1. Schritt: Dialog „Adressdaten“anzeigen



1. Dialog

3. Dialog2. 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 Casesein Zeichen für einen "guten" Schnitt.

• Generell gilt, dass Schritte innerhalb eines Use Cases, innerhalb einer Schätzung und (idealerweise) über alle UCP Schätzungen hinweg etwa gleich groß sein sollten.


T-Faktor und M-Faktor normieren auf einfache Weise die technische und organisatorische Komplexität des Projekts

T-Faktor

IFPUG

FPA 4.1

CO

CO

MO

II

UC

P (Karner)

Credit Suisse

UC

P MT230

sd&m

UC

P 1.0

sd&m

Um

frage

Komplexe Berechnungen 1 1 1 1 1Benutzeroberfläche 2 2 1 2 1Schnittstellen 1 1 1 1 1Verteiltes System 1 1 1 1 1Verfügbarkeitsanford. 1 1 1 1Wiederverwendbark. geford. 1 1 1 1 1 ?Performance 2 1 1 1 ?Flexibilität des Systems 1 1 1 1 ?Installation 1 1 1Sicherheitsanforderungen 1 1Anwender-Schulung 1 1Anforderung an Portabilität 1 1Auslastung Zielumgebung 1 2Anzahl Clients 1Betreibbarkeit 1Flexibilität Architektur 1Ähnliche Produkte 1Ausfallsicherheit (Reliability) 1 ?Datenbankgröße 1Tausch Hard-/Software 1Flexibilität d. Entwicklung 1Summe 14 9 13 7 13 5

M-Faktor

IFPUG

FPA 4.1

CO

CO

MO

II

UC

P (Karner)

Credit Suisse

UC

P MT 230

sd&m

UC

P 1.0

sd&m

Um

frage

Stabile Anforderungen 1 1 1

Reife der Prozesse 1 1 1Lstg./Fähigheit Chefdesigner 1 1 1 1Verfügbare Zeit 1 1Teamplayer 1 1Kontinuität Mitarbeiter 1 1Review und Architektur 1 1Anzahl Entscheidungsträger 1 1Integrationsabhängigkeit 1 1Erfahrung Fachlichkeit 1 1 1 1 ?Motivation 1 1Verfügbarkeit Team 1 1Effizienz Programm.sprache 1 1Erfahrung mit RUP 1Erfahrung Objektorientierung 1Erfahrung Werkzeuge 1 ?Erfahrung Plattform/Middlew. 1Verteiltes Arbeiten 1 ?Dokumentation 1Unterstütz. durch Werkzeuge 1Lstg./Fähigk. Programmierer 1 ?Summe 0 13 8 3 7 9

Kostenfaktor Kostenfaktor

relevant fehlt evtl. relevant aber Streuung zu hoch?

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

überflüssig nicht relevant


Zur Bestimmung des M-Faktors wird das Projekt bezüglich eine Reihe von Einflussgrößen bewertet

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

M1Leistung/Fähigkeit Chefdesigner

Wie erfahren sind der technische und fachliche Chefdesigner (TCD und FCD) hinsichtlich Aufgabe und Fachlichkeit bzw. Technik)?5: wenig erfahren (0 vergleichbare Projekte als FCD oder TCD durchgeführt)3: erfahren (1 vergleichbares Projekt als FCD oder TCD durchgeführt)1: sehr erfahren (2 vergleichbare Projekte als FCD oder TCD durchgeführt)

3

M4Qualität von Grobspezifika-tion und T-Architektur

Wie nachvollziehbar und detailliert ist die Grobspezifikation und wie gut sind Risiken bekannt? Müssen z.B. umfangreiche Arbeiten zur Erstellung der T-Architektur durchgeführt (typisch für ein erstes Release) werden oder sind wichtige „Pflöcke“ schon gesetzt (typisch für eine hohe Releasenummer)5: die Grobspezifikation enthält zahlreiche Widersprüche und offene Fragen, für die Klärung sind mehrere Workshops notwendig; eine Risikoanalyse muss durchgeführt werden; es sind umfangreiche Arbeiten notwendig, um eine T-Architektur zu erstellen3: die Grobspezifikation enthält offene Fragen, welche mit dem Kunden zu klären sind; eine Risikoanalyse wurde durchgeführt und es existieren Risiken; die T-Architektur entspricht weitestgehend einer Standardarchitektur oder wurde in einem vorherigen Release bereits so aufgesetzt 1: die Grobspezifikation ist ausreichend detailliert und lässt keine oder nur sehr wenige Fragen offen; eine Risikoanalyse wurde durchgeführt und ergab keine nennenswerte Risiken; die T-Architektur existiert

3

M5 Prozess-Overhead

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

5: komplexer Entwicklungsprozess, d.h. sehr formales Vorgehen und Prozesse, hohe Abstimmungs- und Querschnittsaufwände, alle Querschnittsrollen besetzt (typisch für Großprojekt mit mehr als 40 Mitarb.)

3: normaler Entwicklungsprozess mit durchschnittlichen Querschnittsaufwänden (typisch für mittelgroßes Projekt, aber auch für kleine Projekte mit entsprechend formalen Anforderungen des Kunden)

1: schlanker Entwicklungsprozess, d.h. pragmatisches Vorgehen, wenig Dokumentation, keine formalen Reviews oder Abnahmen, niedrige Querschnittsaufwände (typisch für kleines Projekt mit max. 5 Mitarb.)

3

M-Faktor > 1.0

M-Faktor = 1.0

M-Faktor < 1.0

Kostenfaktoren im M-Faktor (Ausschnitt)


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 Wissenschafto Wer mit Use Case Points arbeitest, muss sich auf eine gewisse

Unschärfe einlassen und manchmal von Details abstrahieren

• Use Case Points sind keine Wunderwaffeo „Garbage in – garbage out“ :

Wenn die Schätzbasis so vage oder unvollständig ist, dass ich UseCases nicht sinnvoll benennen und annähernd vollständig aufzählen kann, hilft auch UCP nicht weiter

o „Wenn sie zum Projekt nicht passen, lass die Finger davon.“Use Case Points lassen sich nicht für alle Projekte sinnvoll einsetzen


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

• Frohnhoff, S.: Use Case Points 3.0. Implementierung einer Use Case bezogenen Schätzmethode für das Software Engineering betrieblicher InformationssystemeDissertation an der Universität Paderborn, verfügbar unter http://d-nb.info/993834132/34

• 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


Simon Pfeiffer

Lead Business Consultant Travel & Logistics

Kruppstraße 82-100, 45145 EssenTel.: +49 151 6242 6844Fax: +49 2233 9721 6113E-Mail: [email protected]

www.msg-systems.com

Documents

Vorlesung im Wintersemester 2015/16 an der … · Nacharbeiten (FK V1.1) PN. PN-EIN. Einarbeitung, Teamaufbau. PN-REISE. Reisezeiten. PN-STORT . ... Rückstellung für Gewährleistungsforderungen