Aufwandsabschätzung und Projektplanung

Aufwandsabschätzung und Projektplanung
Software Engineering 1
WS 2012/2013
Prof. Dr. Ina Schaefer
Software Systems Engineering
Technische Universität Braunschweig
(mit Folien von Dr. Gerhard Pews)
Charakteristika eines Projekts
Abgrenzung zu Routinetätigkeiten:
•  Ein Projekt hat ein Projektziel.
•  Ein Projekt ist zeitlich befristet.
•  Ein Projekt befasst sich in der Regel mit einem
„schwierigen“ Thema.
•  Ein Projekt besteht aus einer Vielzahl von
Einzelaufgaben und besitzt dadurch Komplexität.
•  Ein Projekt umfasst oft neuartige Aufgaben und
Inhalte.
•  Ein Projekt hat in der Regel ein höheres Risiko als
eine Routinetätigkeit.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 2
Wiederholung:Teufelsquadrat
Teufelsquadrat nachnach
SneedSneed
Leistungsumfang
Qualität
+
Zeit
Prof. Dr. Ina Schaefer
+
-
-
+
+
-
Die Fläche (Produktivität) eine
Projekts ist invariant
• Wenn ein Projekt z. B. in weni
Zeit
und zu(Produktivität)
geringeren Kosten
Beachte: Die
Fläche
abgeschlossen
eines Projekts
ist invariant:werden soll,
verringert sich auch der
Leistungsumfang
und die Qua
Wenn ein Projekt
z. B. in weniger
Zeit und zu
geringeren Kosten
• Steuerung:
abgeschlossen
werden
soll, war nicht
– Fall
1: Planung
verringert sich
auch der Ecken neu justie
umsetzbar:
Leistungsumfang und die Qualität.
– Fall 2: Produktivität im Team
stimmt nicht (Fläche)
•
Kosten
Software Engineering 1
© 2011 Capgemini – All rights reser
Vortrag Projekt Management TU Braunschweig.p
Seite 3
Wichtige Aspekte des Projektmanagements
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Prof. Dr. Ina Schaefer
Definition des Projektumfangs
Komplexität
Vorgehensmodell
Planung
Steuerung und Controlling
Änderungsmanagement
Risikomanagement
Reporting
Teammanagement
Offene Kommunikation & Feedback
Projekterfolg
Software Engineering 1
Seite 4
Projektstrukturplan
Der Planungsschritt
PSP ist die vollständige,
Zerlegung(PSP)
des Projekts
Im ersten
wird derhierarchische
Projektstrukturplan
erstellt in
Aufgaben und Arbeitspakete (AP).
- dies bildet
die Basis für den Projektplan
Synonym: Work breakdown structure (WBS)
Projektstrukturplan
Projekt
Aufgabenkategorien
Aufgaben
Arbeitspakete
KON-A
REA-A
Dialog x
Batch x
Dialog y
Batch y
AP
1.1.1
AP
1.2.1
GUI
AP
2.2.1
AP
1.1.2
AP
1.2.2
AWK
AP
2.2.2
AP
1.2.3
Test
AP
2.2.3
…
…
Definition
Der
ist die
Prof.
Dr.PSP
Ina Schaefer
vollständige, hierarchische Zerlegung
des Projekts
in Aufgaben und Arbeitspakete (AP)
Software Engineering
1
Seite 5
Übersicht
•  Schätzung
•  Allgemeine Grundlagen
•  Function Point Verfahren
•  Expertenschätzung (Delphi-Verfahren)
•  CoCoMo Verfahren
•  Projektplanung
•  Inhalte der Planung
•  Planungstechniken
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 6
Schätzungen
,
g
i
r
e
i
w
h
c
s
d
n
i
s
n
e
g
a
s
s
u
a
r
Vo
t
f
n
u
k
u
Z
e
i
d
e
i
s
n
n
e
w
,
m
e
l
l
vo r a
betreffen.
Mark Twain
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 7
Gewünschter Zeitpunkt der Schätzung
Fachliche
Konzeption
Technische
Konzeption
Realisierung
Test &
Integration
Umfang der Funktionalität bekannt
Fachliche Funktionen, Masken
Umsetzung bekannt
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 8
Tatsächlicher Zeitpunkt der Schätzung
Fachliche
Konzeption
Technische
Konzeption
Realisierung
Test &
Integration
Nur Anforderungen aus Auftrag sind bekannt
Schätzungen sind „unfair“
•  Finden zu einem sehr frühen Zeitpunkt statt.
•  Man weiß dann wenig über die Aufgabe.
Aber:
•  Auf die Zahlen wird man später festgenagelt
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 9
Top-Down vs. Bottom-Up Schätzung
Bottom-up
Top-down
•  Fragestellung: Wenn ich das
alles machen will, wie viel
kostet es dann?
•  Fragestellung: Wenn ich einen
festen Kostenrahmen habe, wie
viel dürfen die einzelnen
Arbeitspakete dann kosten?
•  Von den Arbeitspaketen zur
Aufwandszahl
•  Schätzung der einzelnen
Arbeitspakete
•  Vom fixierten Aufwand zu den
Arbeitspaketen
•  Projekt so aussteuern,
dass es im Kostenrahmen
bleibt
•  Summe ergibt
Gesamtaufwand
•  Beispiel: Abschätzung der
Gesamtkosten als
Arbeitsgrundlage für weitere
Planung
Prof. Dr. Ina Schaefer
•  Aufgaben werden nur so
„gut“ erledigt, wie Geld da
ist
•  Beispiel: Validierung eines
Kostenrahmens
Software Engineering 1
Seite 10
Folgen von Fehlschätzungen
Schätzung
zu niedrig
zu hoch
Beschreibung
•  Geld reicht nicht, Projekt kann im Budget
nicht durchgeführt werden
•  Schätzzahl liegt höher als die tatsächlich zu
leistenden Aufwände.
•  Im nachhinein kaum festzustellen. Jedes Projekt
schöpft den Kostenrahmen voll aus.
•  Konsequenz: Schätzungen sind gern zu hoch
•  Gefahr: Business Case rechnet sich nicht, bzw. Projekt wird an Mitbewerber
verloren.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 11
Schätzung als Planungsgrundlage
Top-down
•  Auch eine „falsche“ Schätzung ist
besser als ein kompletter Blindflug.
•  Eine Schätzung ist die Grundlage
der Planung.
Wenn Schätzungen
so fehlerbehaftet und
schwierig ist, warum
schätzt man dann
überhaupt?
•  Man merkt bei der Planausführung
frühzeitig, ob eine Schätzung falsch
ist und kann dann nachsteuern.
•  Auch Schätzen ist ein Prozess: sobald
erste Erfahrungen und ermittelte
Aufwände im Projekt vorliegen, wird
nachgeschätzt und die Schätzung
korrigiert
•  Die Schätzung wird im Laufe des
Projekts immer genauer.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 12
Einflussfaktoren für Schätzungen
§  Wichtigste Fachlichkeit
Einflussfaktoren
auf den Aufwand
Umzusetzende
(funktional)
PM-Faktoren
• 
• 
• 
• 
• 
• 
• 
Masken
Druckstücke
Batches
Berechnungen
zu berücksichtigende Fehlersituationen
Migrationen aus Altsystemen
Abhängigkeit von andern Systemen
Technologische Umsetzung
nicht-funktionale Anforderungen
• 
• 
• 
• 
Performance, Antwortzeitverhalten
Mengengerüste
Architektur
Systemplattform, Basis-Technologien
Prof. Dr. Ina Schaefer
• 
• 
• 
• 
Team
–  Mitarbeiterqualifikation
–  Erfahrung
–  Eingespieltes Team
Projektorganisation
Projetvorgehen, Methodik
Unterstützung durch Tools
Sonstige Faktoren
• 
• 
Software Engineering 1
Auftraggeber
Aufwände steigen mit
Größe der Aufgabe
Seite 13
Vorgehen bei einer Schätzung
Vorbereiten
Schätzen
Messen,
Vergleichen
Lernen
Nachschätzen
Hinweise
•  Eine gute Vorbereitung ist elementar für die Schätzung
•  Komplettieren und Strukturieren der Schätzgrundlage
(osintots – oh shit, I never thought of this)
•  Sammeln aller Faktoren
•  Nachschätzen und aus Projekterfahrungen lernen ist ein stetiger Kreislauf
während des Projekts
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 14
Schätzverfahren
Schätzverfahren unterscheiden
sich in Zielsetzung, Aufwand und
Genauigkeit
Vergleichsmethoden
Analogieschätzung
Kennzahlenmethode
Algorithmische
Methoden
COCOMO
Function-Points
Use-Case-Points
Kennzahlenmethode
ExpertenSchätzungen
Einzelschätzung
Delphi-Methode
Schätzklausur
 Stellt Bezug zu
durchgeführten
Entwicklungsprojekten
her
 Erfahrungswerte aus
alten Projekten nötig
 Berechnung von
Schätzposten aus
explizit geschätzten
 Ähnlich Analogiemethode
 Aufwandsermittlung per
empirisch gewonnenen
Formeln
 Basis sind „messbare“
Systemfunktionen,
z. B. Use-Case-Points
 Schätzung von
Stücklisten
 Zählen und bewerten
 Gibt eine
Größenordnung zur
Verifikation
 Erfahrungswerte für
Kennzahlen aus
abgeschlossenen
Projekte nötig
 Teilw. aufwändig, aber
gute Resultate
 ohne Justierung wenig
präzise
 Erstmalige Schätzung
neuer Anforderungen
durch
Expertenerfahrung
Selten in Reinform,
aber implizit in
Expertenschätzung
Kennzahlen aus dem
Aufwandsmodell zur
Plausibilisierung
Use-Case-Points
verwenden wir zur
Plausibilisierung
bei Capgemini
hauptsächlich
eingesetzte Methode
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 15
Function Point Verfahren
§  Vorgehen im Überblick
Bewertung der Komplexität der Fachlichkeit
(Datenfluss)
Bewertung
sonstiger
Einflussfaktoren
Ermittlung der
Gesamtkomplexität,
Berechnung des
Aufwands
Hinweise
•  Function Point Schätzungen werden in verschiedenen Firmen
unterschiedlich gelebt.
•  Alle arbeiten nach dem gleichen Prinzip, Unterschiede gibt es in:
•  Kriterien, nach denen die Komplexität der Fachlichkeit gemessen wird
•  Betrachtete sonstige Einflussfaktoren
•  Unternehmensspezifische Gewichtung
•  Im Folgenden: ursprüngliches Verfahren
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 16
Bewertung der Fachlichkeit
§  Details zum ersten Schritt
Bewertung der Komplexität der Fachlichkeit
(Datenfluss)
Bewertung
sonstiger
Einflussfaktoren
Ermittlung der
Gesamtkomplexität,
Berechnung des
Aufwands
Inhalte
•  Strukturierte Erfassung der Fachlichkeit:
•  Eingabedaten (Bildschirm, Batch, etc.)
•  Ausgabedaten (Bildschirm, Druck, Interface, etc.)
•  Anfragen (Suchanfragen)
•  Eigene Datenbestände (lesen & schreiben)
•  Extern referenzierte Datenbestände (nur lesen)
•  Zu jedem Punkt Bewertung: geringe/mittlere/hohe Komplexität
•  Ableiten der FP aus Tabelle mit FP-Werten für die jeweilige Komplexität
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 17
Bewertung durch Function Points
§  Beispiel für eine Function Point Bewertung
Bewertungen
Eingabedaten
Schätzposten
Komplexität
FP
gering
3
…
…
mittel
4
hoch
6
…
Eingabedaten
Kunde
gering
3
Bankverbindung
mittel
4
Eigene
Datenbestände
…
…
gering
7
mittel
10
15
…
Anfragen
Kundensuche
mittel
10
hoch
…
…
…
458
…
…
Summe
FP-Werte für
jeweilige
Komplexitäten
Schätztabelle
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 18
Bewertung der Einflussfaktoren
§  Details zum zweiten Schritt
Bewertung der Komplexität der Fachlichkeit
(Datenfluss)
Bewertung
sonstiger
Einflussfaktoren
Ermittlung der
Gesamtkomplexität,
Berechnung des
Aufwands
Inhalte
•  Bewertung sonstiger Einflussfaktoren:
•  Verflechtung mit anderen Systemen
•  Dezentrale Verarbeitung und Datenhaltung
•  Transaktionsrate und Antwortzeitverhalten
•  Verarbeitungskomplexität (Rechenoperationen,
Ausnahmebehandlungen, Logik, …=)
•  Wiederverwendbarkeit
Auch daraus wird
wieder ein
numerischer Faktor
abgeleitet.
•  Migrationen
•  Benutzerfreundlichkeit
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 19
Berechung des Gesamtaufwands
§  Details zum dritten Schritt
Bewertung der Komplexität der Fachlichkeit
(Datenfluss)
Bewertung
sonstiger
Einflussfaktoren
Ermittlung der
Gesamtkomplexität,
Berechnung des
Aufwands
Inhalte
•  Gesamtkomplexität in „Total Function Points“ (TFP) durch Verrechnung (i. d.
R. Multiplikation) der Faktoren
•  Errechnung des Aufwands z. T. mit Zwischenschritt über die zu erstellenden
Codezeilen (Lines of Code – LOC) für eine jeweilige Programmiersprache.
TFP/LOC
Personenmonate
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 20
Bewertung des FP-Verfahrens
Bewertung
•  Systematische Herangehensweise
•  In Function Points wird die fachliche Komplexität der Aufgabe
gemessen, nicht die Komplexität der technischen Lösung.
•  Lebt von den jeweiligen Erfahrungswerten des Unternehmens
und der Personen.
•  Insbesondere in den zweiten Schritt gehen
unternehmensspezifische Erfahrungen ein, die schwer zu
begründen und in anderen Kontexten zu reproduzieren sind.
•  Wird in unterschiedlichen Unternehmen auch unterschiedlich
gehandhabt.
•  Nach einiger Zeit der Anwendung erzielt man reproduzierbare
Ergebnisse in der Function Point Messung.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 21
Expertenschätzung
Hinweise zum Vorgehen
•  Aufwände und Umsetzung werden explizit geschätzt, nicht
über Lines of Code oder Faktoren.
•  Bei einer Expertenschätzung sind in der Regel mindestens
zwei Experten beteiligt, um Schätzergebnisse vergleichen zu
können.
•  Generelle Unterscheidung in der Vorgehensweise:
•  Standard-Delphi-Verfahren: Experten schätzen
komplett unabhängig
•  Breitband-Delphi-Verfahren: Experten diskutieren
Zwischenergebnisse.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 22
Expertenschätzung nach Delphi-Verfahren
Erstellen Schätzpostenliste
Liste mit jedem Experten
durchsprechen, erläutern
Experte schätzt jeden
Schätzposten, Rückfrage
möglich
Falls Breitband-Verfahren:
Experten-Diskussion
Prüfung Ergebnisse
Neue Liste mit unklaren
Posten, neu kommentiert
z. B. falls unplausibel,
Abweichungen
Ergebnis = Durchschnittwerte
zwischen Experten
der Einzel-Schätzungen
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 23
Schätzpostenliste
Schätzposten
•  Benötigt: vollständige funktionale Beschreibung des Systems
•  Beispiele für Schätzposten
•  Dialog
•  Druckstück
•  Funktionen, Services
•  Entitäten & Persistenz der Entitäten
•  Querschnittliche Funktionen (Drucken, Fehlerbehandlung, etc.)
•  Granularität eines Schätzpostens (Daumenregeln)
•  nicht kleiner als 1 Tag, sonst addieren sich Nichtigkeiten zu
großen Aufwänden
•  nicht größer als 20 Tage, sonst wird die Schätzung zu ungenau
•  guter Bereich: 5 – 10 Tage
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 24
Schätzgröße in der Expertenschätzung
§  Hinweise
zur Schätzgröße „BT“
Schätzgröße
•  BT = Bearbeitungstag, auch PT = Personentag oder MT = Manntag
•  Die Arbeit, die eine Person an einem Tag erledigen kann
•  Die Arbeit ist brutto gerechnet, d. h. die wirkliche Zeit, die man
benötigt, d. h. Entwicklung inklusive:
•  Entwicklertest
•  Code-Dokumentation
•  Nacharbeiten
•  Reisekostenabrechnung, Stundenkontierung in SAP, …
•  Kaffee trinken, Zigarrettenpause
•  Teilnahme an Meetings
•  Anderen Kollegen helfen
•  Rechner ist abgestürzt, Netzwerk ist weg,…
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 25
Vorgehen bei einer vereinfachten Schätzung
Schritt
Schätzung der
Realisierung
Hochrechnung auf
alle Phasen
Zuschläge
Prof. Dr. Ina Schaefer
Beschreibung
•  Schätzung der reinen RealisierungsAufwände
•  Hochrechnung von
•  Fachlicher Konzeption
•  Technischer Konzeption
•  Test & Integration
aus den Realisierungs-Werten
•  Addieren von Zuschlägen, z. B. für
Projektkoordination, Gewährleistung,
Qualitätssicherung, etc.
Software Engineering 1
Seite 26
Schätzung der Realisierung
§  Vorgehen
bei der Schätzung der Realisierung
Schätzung
•  Geschätzt wird die reine Brutto-Realisierung. Annahmen dabei:
•  Alle fachlichen Fragen sind geklärt
•  Algorithmen sind klar
•  Technologie ist klar
•  Mitarbeiter ist geschult
•  „Normale“ Projektmitarbeiter, keine Technologie-Experten (wie
diejenigen, die schätzen)
•  Eigentlich ist eine detaillierte Schätzung erst nach Abschluss der
fachlichen Konzeption möglich. Zu diesem Zeitpunkt kennt man die
Aufwände der fachlichen Konzeption schon bzw. kann sie
abschätzen. Diese Aufwände kann man zur Plausibilisierung mit
den geschätzten Realisierungsaufwänden vergleichen.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 27
Hochrechnung von Realisierungsaufwänden
§  Beispiel: Erfahrungswerte der Firma sd&m
Nutzung der Werte
Test und
Integr.
15%
Realisierung
40%
Prof. Dr. Ina Schaefer
fachl.
Konzept
30%
tech.
Konzept
15%
Software Engineering 1
•  Hochrechnung: Nach
diesen
Erfahrungswerten ist
der Gesamtaufwand
2,5x so hoch wie der
Realisierungsaufwand
•  Plausibilisierung:
Nach Abschluss des
fachlichen Konzepts
sollten 30% des
Projektbudgets
verbraucht sein.
Seite 28
Aufschläge bei der Realisierungsschätzung
§  Erfahrungswerte für Zuschläge bei sd&m
Zuschlag
Technik
- Software-Entwicklungsumgebung
- Technische Infrastruktur
- Konfigurationsmanagement
Datenadministration (optional)
Abnahmesupport
Chefdesign (CD)
Qualitätssicherung (QS)
Einarbeitung
Team-Meetings
PM/PL
Puffer bzw. Risikozuschlag
Gewährleistung
Sonstiges
Reisezeit
Reisespesen
Zugekaufte Leistungen
Erfahrungswerte
Aufbau geplant, Pflege MA über Zeit
5-10%, oder MA über Zeit
Aufbau geplant, Pflege MA über Zeit
5-10%
MA über Zeit
5-10%, oder MA über Zeit
Aktivitäten oder 10-20%
2-4 Wochen bei Projekteinstieg
MA über Zeit
10-25%, 1 PL pro ca. 7 MA über Zeit
10-40%
3-12%
Projektspezifisch
MA über Zeit
ableitbar aus Reisezeit
tatsächliche Kosten
Bei Großprojekten kann die Realisierung nach Berechnung aller Zuschläge nur
noch 16% des Gesamtaufwands betragen!
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 29
Repräsentanten und Stützpunkte schätzen
Problem
§  Tipps
zur Schätzung großer Schätzpostenlisten
•  Problem: Was tun, wenn die Schätzpostenliste sehr groß ist, z. B.
wenn das System mehrere hundert Dialoge umfasst? Der Aufwand
zur Schätzung wird dann sehr groß
Lösung 1: Beispiel mit Bildung von Klassen.
•  Klassen: Einfache Dialoge, Mittelschwere Dialoge, Schwierige
Dialoge
•  Extrem schwierige Dialoge trotzdem individuell schätzen
•  Schätzen von einem Repräsentanten jeder Klasse
Lösung 2: Beispiel mit Schätzung von Stützpunkten
•  Fünf Dialoge wählen, die das ganze Spektrum der Komplexität
abdecken.
•  Andere Dialoge werden nicht geschätzt, sondern mit den
Stützpunkten verglichen. Aufwandszahlen der Stützpunkte werden
übernommen und ggf. leicht angepasst.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 30
Schätzunsicherheit
Problem
§  Vorgehen
bei einer Min-Max-Schätzung
•  Schätzungen sind immer mit einer Schätzungenauigkeit und einem
Risiko behaftet.
Min-Max-Schätzung
•  Idee: Experte schätzt minimalen und maximalen Aufwand für die
Aufgabe.
•  Wichtig: kein zu großes Delta zwischen Min und Max, guter
Erfahrungswert ca.: 20%, in der Praxis aber leider oft höher.
•  Die Planung wird am Minimalwert ausgerichtet, aber so mit
Personen hinterlegt, dass die maximalen Aufwände in der
Projektlaufzeit möglich zu erbringen sind.
•  Weitere Möglichkeit zur Min-Max-Schätzung: Min, Max und
Normalwert schätzen, dann rechen mit:
(Min + Max + 4*Norm) / 6
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 31
CoCoMo Verfahren
Idee
•  Schätzung der Projektgröße in LOC (Lines of Code)
bzw. KDSI (Kilo Delivered Software Instructions),
d. h. ohne Kommentare.
•  Nach Verrechnung mit weiteren Kennzahlen wird der
Gesamtaufwand E berechnet
(MMDEV Entwicklungsaufwand in PM) und die
Projektlaufzeit (TDEV)
Formel
MMDEV = a * KDSIb * m(X)
Entwickelt von Barry Boehm (*1935)
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 32
Projektklasse
§  Einfluss der Projektklasse auf die Aufwandsschätzung
MMDEV = a * KDSIb * m(X)
Organic Mode
Semi-detached Mode
Embedded Mode
•  einfache SW-Projekte
•  mittelschwere
Projekte
•  schwierige Projekte
•  eingespieltes Team,
bekannte Umgebung,
wenig Neuland
•  Größe <50 KDSI
•  Größe <300 KDSI
•  Faktor b = 1,12
•  Faktor b = 1,05
Prof. Dr. Ina Schaefer
•  starker KostenTermindruck, viel
Neuland
•  Größe: beliebig
•  Faktor b: 1,20
Software Engineering 1
Seite 33
Modellvarianten
§  Einfluss der Modellvarianten auf die Schätzung
MMDEV = a * KDSIb * m(X)
Basismodell
Zwischenmodell
Detailmodell
•  früh, zu Beginn eines
Softwareprojekts
•  Berücksichtigung von
15 Einflussparametern
•  Berücksichtigung von
15 Parametern
•  ganzheitliche
Betrachtung
•  keine Differenzierung
zwischen Phasen
•  Abweichungen der
Aufwände aus den
einzelnen Phasen
berücksichtigt
•  Ausgangspunkt für
weitere Schätzungen
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 34
Weitere 15 Einflussfaktoren
MMDEV = a * KDSIb * m(X) m(x) = m(x1) * m(x2) * … * m(x15)
Produkt
Projekt
RELY: geforderte Zuverlässigkeit der Software
MODP: Verwendung moderner
Entwicklungsmethoden
DATA: Größe der Datenbasis
TOOL: Verwendung von Tools
CPLX: Komplexität des Produktes
Personal
SCED: Anforderungen an die
Entwicklungszeit
ACAP: Analysefähigkeit der Mitarbeiter
Computer
AEXP: Erfahrung der Mitarbeiter im
Arbeitsgebiet
TIME: benötigte Rechenzeit
PCAP: Programmierfähigkeit der Mitarbeiter
STOR: Nutzung des verfügbaren
Speicherplatzes
VEXP: Erfahrung der Mitarbeiter in der
Systemumgebung
VIRT: Änderungshäufigkeit der
Systembasis
LEXP: Erfahrung der Mitarbeiter in der
Programmiersprache
TURN: Bearbeitungszyklus
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 35
Berechnung des Gesamtaufwands in CoCoMo
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 36
Bewertung von CoCoMo
Bewertung
•  Die Schätzmethode CoCoMo bzw. CoCoMo II ist wenig
verbreitet.
•  Die Methode macht deutlich, welche Einflussfaktoren für die
Schätzung relevant sind:
•  Zeitpunkt der Schätzung
•  Typ des Projekts
•  15 detaillierte Einflussfaktoren
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 37
Tipps zur Schätzung
Tipps
•  Keine Angst vor großen Zahlen.
•  Schätzungen ergeben oft hohe Werte. Stehen Sie dazu.
•  Software ist teuer.
•  Eine ehrliche Schätzung ist die Grundlage für den
Projekterfolg.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 38
Projektplanung
Planung
•  Ein Plan zeigt die Machbarkeit eines Vorhabens. Wenn man
nicht einmal einen Plan erstellen kann, dann ist das Vorhaben
nicht machbar.
•  Ein Plan wird im Projekt ständig nachgeführt und aktualisiert.
Dadurch kann der Projektleiter sein Projekt ins Ziel führen.
•  Ein Plan ist die Grundlage, um ein Projekt zu steuern
•  Ohne Steuerung und Plan erkennt man erst zu
Projektende, ob sich der Projekterfolg einstellt
•  Mit Steuerung: Gefährdungen sind früh erkennbar, man
kann auf darauf reagieren
è Auch ein „falscher“ Plan ist besser als gar kein Plan. Die
Alternative wäre ein totaler Blindflug.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 39
Planung als Prozess
Fallbeispiel: Zitat Projektleiter
„Damals haben wir mit viel Aufwand den Plan gemacht und nach
zwei Wochen hat er schon nicht mehr gestimmt.“
Grundideen einer Planung
•  Eine Planung wird zu Projektbeginn erstellt und dann ständig
verfeinert und angepasst.
•  Eine Planung veraltet, sobald sie fertig ist. (Und manchmal auch
schon, während sie erstellt wird)
•  Eine Planung ist keine Vorhersage. Ein Projekt kann man nicht
ausrechnen.
•  Die Planung ist ein Werkzeug. Sie ist das wichtigste
Arbeitswerkzeug des Projektleiters.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 40
Projektplanung im Projektmanagement
Anpassen
Planung
SOLL
Controlling
(Überwachen)
Steuern
Handlungsbedarf
SOLL
IST Meilensteine,
Restaufwandsschätzungen
Maßnahmen
Projektverlauf, Ausführen des Plans
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 41
Inhalte der Planung
Fragestellung
Inhalte
•  WER (Personen) macht
Im Projektplan finden sich die
Elemente:
•  WANN (Termine)
•  WAS (Aufgaben)
•  ggf. WOMIT (Arbeitsmittel)?
•  Aufgabe, Aktivität/
Arbeitspaket (oft synonym
verwendet)
•  Ressourcen, insbesondere
Personen
•  Aufwände und Puffer
•  Termine
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 42
Planungstechniken
Gantt-Diagramm
•  Stellt besonders gut den zeitlichen
Verlauf dar
•  In der Praxis größte Verbreitung
•  Unterstützung durch Tools, oft
Default-Ansicht
Netzplan
•  Z. B.: MPM-Methode
•  Stellt besonders gut die
Abhängigkeiten zwischen
Arbeitspaketen dar
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 43
Definition eines Netzplans
Netzplan
In Netzplänen werden dargestellt: Vorgänge, Ereignisse und
deren Abhängigkeiten.
Definitionen
•  DIN 69900 Definition Netzplan:
Der Netzplan ist die graphische Darstellung von
Ablaufstrukturen, welche die logische und zeitliche
Aufeinanderfolge von Vorgängen veranschaulichen.
•  Definition Vorgang:
Ein Vorgang ist eine Zeit beanspruchende Tätigkeit, die
über einen definierten Anfang und ein definiertes Ende
verfügt.
•  Definition Ereignis:
Ein Ereignis signalisiert das Eintreten eines definierten und
beschreibbaren Zustands im Projektablauf (z. B.
Meilenstein).
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 44
Grundtypen von Netzplänen
Vorgangspfeil-Netzplan
Knoten: Ereignisse
Ereignis
Pfeile: Vorgänge
Vorgang
Ereignis
Beispiel: Critical Path Method (CPM)
Ereignisknoten-Netzplan
Knoten: Ereignisse
Pfeile: Abhängigkeiten
Ereignis
Ereignis
Vorgang
Vorgang
Beispiel: Program Evaluation and Review
Technique (PERT)
Vorgangsknoten-Netzplan
Knoten Vorgänge
Pfeile: Abhängigkeiten
Beispiel: Metra Potential Method (MPM)
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 45
Termine eines Vorgangs
Früher Start
49 50 51 52 01 02 03 04 05 06 07
FAT: Frühester Anfangstermin – Der Termin, zu
dem der Vorgang frühestens beginnen kann.
FET: Frühester Endtermin – Der Termin, zu dem
der Vorgang frühestens abgeschlossen werden
kann, wenn man zum FAT begonnen hat. (FAT
+ Dauer)
Start
FAT
Später Start
Ende
FET
49 50 51 52 01 02 03 04 05 06 07
SET: Spätester Endtermin – Der Termin, zu dem
der Vorgang abgeschlossen sein muss.
SAT: Spätester Anfangstermin – Der Termin, zu
dem man spätestens angefangen haben muss,
wenn man zum SET fertig sein will. (SETDauer)
Start
Ende
SAT
Prof. Dr. Ina Schaefer
Software Engineering 1
SET
Seite 46
Pufferzeiten
Pufferzeiten
Pufferzeit: Die Zeit, um die ein Vorgang verschoben werden kann.
Freie Pufferzeit: Die Zeit, um die man einen Vorgang verschieben kann, ohne
dass der nachfolgende Vorgang verschoben werden muss.
Gesamtpufferzeit: Die Zeit, um die man einen Vorgang verschieben kann,
ohne dass das Projektende verschoben werden muss.
Pufferzeit
49
50
51
52
01
02
03
04
05
Start
06
07
Ende
freie Pufferzeit
Zeitfenster
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 47
Der kritische Pfad
Kritischer Pfad
Kritischer Pfad: Der Pfad vom Projektstart bis zum Projektende, auf dem
ausschließlich Vorgänge ohne Pufferzeit liegen.
Kritischer Vorgang: Vorgang auf dem kritischen Pfad.
49
50
51
52
01
02
03
04
05
06
Start
krit. Vorgang
07
Ende
kritischer
Pfad
krit. Vorgang
krit. Vorgang
Kritische Vorgänge erfordern besondere Aufmerksamkeit im Projektmanagement.
Jeder Verzug auf dem kritischen Pfad führt dazu, dass der Zieltermin des Projekts
gefährdet ist.
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 48
Metra Potenzial Methode (MPM)
Grundideen MPM
•  Ausprägung der Netzplantechnik
•  Spezielle Notation der Vorgänge mit FAT, FET, SAT, SET und Puffer
•  Vorwärts- und Rückwärtsrechnung, um diese Daten für alle Vorgänge zu
bestimmen.
•  1958 durch die Unternehmensgruppe Metra entwickelt
Nr.
Nr.
Vorgangsname
Vorgangsname
FAT
Dauer
FET
SAT
Gesamtpuffer
SET
Prof. Dr. Ina Schaefer
Nr.
FAT
Dauer
FET
SAT
Gesamtpuffer
SET
Nr.
Vorgangsname
FAT
Dauer
SAT
Gesamtpuffer
Nr.
Vorgangsname
FET
SET
FAT
Dauer
FET
SAT
Gesamtpuffer
SET
Nr.
Vorgangsname
Vorgangsname
FAT
Dauer
FET
FAT
Dauer
FET
SAT
Gesamtpuffer
SET
SAT
Gesamtpuffer
SET
Software Engineering 1
Seite 49
Gantt Diagramme
Grundideen Gantt
•  Anderer Name: Balkendiagramm
•  Vorgänge werden durch Balken auf einem Kalender dargestellt.
•  Vorteil: intuitiv verständlich, man sieht sofort die Dauer der Vorgänge
•  Abhängigkeiten weniger übersichtlich dargestellt
•  Durch Henry L. Gantt (1861–1919) entwickelt
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 50
Zusammenfassung
•  Was ist ein Projekt?
•  Aufgaben im Projektmanagement
•  Aufwandsabschätzung
•  Function Point Verfahren
•  Expertenschätzung (Delphi-Verfahren)
•  CoCoMo Verfahren
•  Planungstechniken
•  Netzplantechnik
•  Gantt Charts
Prof. Dr. Ina Schaefer
Software Engineering 1
Seite 51