Dr. Ina SchaeferSoftware Systems Engineering
Technische Universität Braunschweig
(mit Folien von Dr. Gerhard Pews)
Aufwandsabschätzung und ProjektplanungSoftware Engineering 1
WS 2010/2011
Dr. Ina Schaefer Software Engineering 1 Seite 6
Übersicht
• Sätzung• Allgemeine Grundlagen• Function Point Verfahren• Expertenschätzung (Delphi-Verfahren)• CoCoMo Verfahren
• Projektplanung• Inhalte der Planung• Planungstechniken
Dr. Ina Schaefer Software Engineering 1 Seite 7
Schätzungen
Dr. Ina Schaefer Software Engineering 1 Seite 8
Gewünschter Zeitpunkt der Schätzung
Test &Integration
FachlicheKonzeption
TechnischeKonzeption Realisierung
Umfang der Funktionalität bekanntFachliche Funktionen, MaskenUmsetzung bekannt
Dr. Ina Schaefer Software Engineering 1 Seite 9
Tatsächlicher Zeitpunkt der Schätzung
Test &Integration
FachlicheKonzeption
TechnischeKonzeption Realisierung
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
Dr. Ina Schaefer Software Engineering 1 Seite 10
Top-Down vs. Bottom-Up Schätzung
Top-down• Fragestellung: Wenn ich einen
festen Kostenrahmen habe, wie viel dürfen die einzelnen Arbeitspakete dann kosten?
• Vom fixierten Aufwand zu den Arbeitspaketen• Projekt so aussteuern,
dass es im Kostenrahmen bleibt
• Aufgaben werden nur so „gut“ erledigt, wie Geld da ist
• Beispiel: Validierung eines Kostenrahmens
Bottom-up• Fragestellung: Wenn ich das
alles machen will, wie viel kostet es dann?
• Von den Arbeitspaketen zur Aufwandszahl• Schätzung der einzelnen
Arbeitspakete• Summe ergibt
Gesamtaufwand• Beispiel: Abschätzung der
Gesamtkosten als Arbeitsgrundlage für weitere Planung
Dr. Ina Schaefer Software Engineering 1 Seite 11
Folgen von Fehlschätzungen
• 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.
Schätzung Beschreibung
zu hoch
zu niedrig• Geld reicht nicht, Projekt kann im Budget
nicht durchgeführt werden
• Konsequenz: Schätzungen sind gern zu hoch• Gefahr: Business Case rechnet sich nicht, bzw. Projekt wird an Mitbewerber
verloren.
Dr. Ina Schaefer Software Engineering 1 Seite 12
Schätzung als Planungsgrundlage
Wenn Schätzungen so fehlerbehaftet und schwierig ist, warum schätzt man dann überhaupt?
Top-down• Auch eine „falsche“ Schätzung ist
besser als ein kompletter Blindflug.• Eine Schätzung ist die Grundlage
der Planung.• 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.
Dr. Ina Schaefer Software Engineering 1 Seite 13
Einflussfaktoren für Schätzungen
Wichtigste Einflussfaktoren auf den AufwandUmzusetzende Fachlichkeit (funktional)
• Masken• Druckstücke• Batches• Berechnungen• zu berücksichtigende Fehlersituationen• Migrationen aus Altsystemen• Abhängigkeit von andern Systemen
Technologische Umsetzungnicht-funktionale Anforderungen
• Performance, Antwortzeitverhalten• Mengengerüste• Architektur• Systemplattform, Basis-Technologien
PM-Faktoren
• Team– Mitarbeiterqualifikation– Erfahrung– Eingespieltes Team
• Projektorganisation• Projetvorgehen, Methodik• Unterstützung durch Tools
Sonstige Faktoren
• Auftraggeber• Aufwände steigen mit
Größe der Aufgabe
Dr. Ina Schaefer Software Engineering 1 Seite 14
Vorgehen bei einer Schätzung
VorbereitenMessen,VergleichenLernen
Schätzen 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
Dr. Ina Schaefer Software Engineering 1 Seite 16
Function Point Verfahren
Vorgehen im Überblick
Bewertung der Kom-plexitä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
Dr. Ina Schaefer Software Engineering 1 Seite 17
Bewertung der Fachlichkeit Details zum ersten Schritt
Bewertung der Kom-plexitä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
Dr. Ina Schaefer Software Engineering 1 Seite 18
Bewertung durch Function Points
Beispiel für eine Function Point Bewertung
Schätzposten Komplexität FP… … …EingabedatenKunde gering 3Bankverbindung mittel 4… … …AnfragenKundensuche mittel 10… … …Summe 458
BewertungenEingabedatengering 3mittel 4hoch 6Eigene Datenbeständegering 7mittel 10hoch 15……
Schätztabelle FP-Werte für jeweilige
Komplexitäten
Dr. Ina Schaefer Software Engineering 1 Seite 19
Bewertung der Einflussfaktoren Details zum zweiten Schritt
Bewertung der Kom-plexitä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• Migrationen• Benutzerfreundlichkeit
Auch daraus wird wieder ein numerischer Faktor abgeleitet.
Dr. Ina Schaefer Software Engineering 1 Seite 20
Berechung des Gesamtaufwands Details zum dritten Schritt
Bewertung der Kom-plexitä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.
Personenmonate
TFP/LOC
Dr. Ina Schaefer Software Engineering 1 Seite 21
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.
Dr. Ina Schaefer Software Engineering 1 Seite 22
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.
Dr. Ina Schaefer Software Engineering 1 Seite 23
Expertenschätzung nach Delphi-Verfahren
Liste mit jedem Experten durchsprechen, erläutern
Erstellen Schätzpostenliste
Experte schätzt jeden Schätzposten, Rückfrage
möglich
Prüfung Ergebnisse Neue Liste mit unklaren Posten, neu kommentiert
z. B. falls unplausibel, Abweichungen
zwischen ExpertenErgebnis = Durchschnittwerte der Einzel-Schätzungen
Falls Breitband-Verfahren:Experten-Diskussion
Dr. Ina Schaefer Software Engineering 1 Seite 24
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
Dr. Ina Schaefer Software Engineering 1 Seite 25
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,…
Dr. Ina Schaefer Software Engineering 1 Seite 26
Vorgehen bei einer vereinfachten Schätzung
• Schätzung der reinen Realisierungs-Aufwände
Schritt Beschreibung
Schätzung der Realisierung
Hochrechnung auf alle Phasen
• Hochrechnung von • Fachlicher Konzeption• Technischer Konzeption• Test & Integration
aus den Rea-Werten
Zuschläge • Addieren von Zuschlägen, z. B. für
Projektkoordination, Gewährleistung, Qualitätssicherung, etc.
Dr. Ina Schaefer Software Engineering 1 Seite 27
Schätzung der Realisierung
Vorgehen bei der Schätzung der Realisierung• 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.
Schätzung
Dr. Ina Schaefer Software Engineering 1 Seite 28
Hochrechnung von Realisierungsaufwänden
Beispiel: Erfahrungswerte der Firma sd&m
fachl. Konzept
30%
tech.Konzept
15%
Reali-sierung
40%
Test und Integr.15%
Nutzung der Werte• 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.
Dr. Ina Schaefer Software Engineering 1 Seite 29
Aufschläge bei der Realisierungsschätzung
Erfahrungswerte für Zuschläge bei sd&mZuschlag ErfahrungswerteTechnik - Software-Entwicklungsumgebung Aufbau geplant, Pflege MA über Zeit - Technische Infrastruktur 5-10%, oder MA über Zeit - Konfigurationsmanagement Aufbau geplant, Pflege MA über ZeitDatenadministration (optional) 5-10%Abnahmesupport MA über ZeitChefdesign (CD) 5-10%, oder MA über ZeitQualitätssicherung (QS) Aktivitäten oder 10-20%Einarbeitung 2-4 Wochen bei ProjekteinstiegTeam-Meetings MA über ZeitPM/PL 10-25%, 1 PL pro ca. 7 MA über ZeitPuffer bzw. Risikozuschlag 10-40%Gewährleistung 3-12%Sonstiges ProjektspezifischReisezeit MA über ZeitReisespesen ableitbar aus ReisezeitZugekaufte Leistungen tatsächliche Kosten
Bei Großprojekten kann die Realisierung nach Berechnung aller Zuschläge nur noch 16% des Gesamtaufwands betragen!
Dr. Ina Schaefer Software Engineering 1 Seite 30
Repräsentanten und Stützpunkte schätzen
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ß
Problem
• Klassen: Einfache Dialoge, Mittelschwere Dialoge, Schwierige Dialoge
• Extrem schwierige Dialoge trotzdem individuell schätzen• Schätzen von einem Repräsentanten jeder Klasse
Lösung 1: Beispiel mit Bildung von Klassen.
• 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.
Lösung 2: Beispiel mit Schätzung von Stützpunkten
Dr. Ina Schaefer Software Engineering 1 Seite 31
Schätzunsicherheit
Vorgehen bei einer Min-Max-Schätzung• Schätzungen sind immer mit einer Schätzungenauigkeit und einem
Risiko behaftet.
Problem
• 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
Min-Max-Schätzung
Dr. Ina Schaefer Software Engineering 1 Seite 32
CoCoMo Verfahren
• 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)
Idee
MMDEV = a * KDSIb * m(X)Formel
Entwickelt von Barry Boehm
Dr. Ina Schaefer Software Engineering 1 Seite 33
Projektklasse Einfluss der Projektklasse auf die Aufwandsschätzung
• einfache SW-Projekte• eingespieltes Team,
bekannte Umgebung, wenig Neuland
• Größe <50 KDSI• Faktor b = 1,05
Organic Mode• mittelschwere
Projekte• Größe <300 KDSI• Faktor b = 1,12
Semi-detached Mode• schwierige Projekte• starker Kosten-
Termindruck, viel Neuland
• Größe: beliebig• Faktor b: 1,20
Embedded Mode
MMDEV = a * KDSIb * m(X)
Dr. Ina Schaefer Software Engineering 1 Seite 34
Modellvarianten Einfluss der Modellvarianten auf die Schätzung
MMDEV = a * KDSIb * m(X)
• früh, zu Beginn eines Softwareprojekts
• ganzheitliche Betrachtung
• Ausgangspunkt für weitere Schätzungen
Basismodell• Berücksichtigung von
15 Einflussparametern• keine Differenzierung
zwischen Phasen
Zwischenmodell• Berücksichtigung von
15 Parametern• Abweichungen der
Aufwände aus den einzelnen Phasen berücksichtigt
Detailmodell
Dr. Ina Schaefer Software Engineering 1 Seite 35
Weitere 15 Einflussfaktoren
RELY: geforderte Zuverlässigkeit der SoftwareDATA: Größe der DatenbasisCPLX: Komplexität des Produktes
Produkt
TIME: benötigte RechenzeitSTOR: Nutzung des verfügbaren
SpeicherplatzesVIRT: Änderungshäufigkeit der
SystembasisTURN: Bearbeitungszyklus
Computer
MODP: Verwendung moderner Entwicklungsmethoden
TOOL: Verwendung von ToolsSCED: Anforderungen an die
Entwicklungszeit
Projekt
ACAP: Analysefähigkeit der MitarbeiterAEXP: Erfahrung der Mitarbeiter im
ArbeitsgebietPCAP: Programmierfähigkeit der MitarbeiterVEXP: Erfahrung der Mitarbeiter in der
SystemumgebungLEXP: Erfahrung der Mitarbeiter in der
Programmiersprache
Personal
m(x) = m(x1) * m(x2) * … * m(x15)MMDEV = a * KDSIb * m(X)
Dr. Ina Schaefer Software Engineering 1 Seite 36
Berechnung des Gesamtaufwands in CoCoMo
Dr. Ina Schaefer Software Engineering 1 Seite 37
Bewertung von CoCoMo
• 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
Bewertung
Dr. Ina Schaefer Software Engineering 1 Seite 38
Tipps zur Schätzung
• 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.
Tipps
Dr. Ina Schaefer Software Engineering 1 Seite 39
Projektplanung
• 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.
Planung
Dr. Ina Schaefer Software Engineering 1 Seite 40
Planung als Prozess
„Damals haben wir mit viel Aufwand den Plan gemacht und nach zwei Wochen hat er schon nicht mehr gestimmt.“
Fallbeispiel: Zitat Projektleiter
• 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.
Grundideen einer Planung
Dr. Ina Schaefer Software Engineering 1 Seite 41
Projektverlauf, Ausführen des Plans
Planung Controlling(Überwachen) Steuern
SOLL
Handlungs-bedarf Maß-
nahmen
Anpassen
IST Meilensteine,Restaufwands-schätzungen
SOLL
Projektplanung im Projektmanagement
Dr. Ina Schaefer Software Engineering 1 Seite 42
• WER (Personen) macht• WANN (Termine)• WAS (Aufgaben)• ggf. WOMIT (Arbeitsmittel)?
FragestellungIm Projektplan finden sich die
Elemente:• Aufgabe,
Aktivität/Arbeitspaket (oft synonym verwendet)
• Ressourcen, insbesondere Personen
• Aufwände und Puffer• Termine
Inhalte
Inhalte der Planung
Dr. Ina Schaefer Software Engineering 1 Seite 43
Planungstechniken
• Stellt besonders gut den zeitlichen Verlauf dar
• In der Praxis größte Verbreitung• Unterstützung durch Tools, oft
Default-Ansicht
Gantt-Diagramm
• Z. B.: MPM-Methode• Stellt besonders gut die
Abhängigkeiten zwischen Arbeitspaketen dar
Netzplan
Dr. Ina Schaefer Software Engineering 1 Seite 44
Definition eines Netzplans
In Netzplänen werden dargestellt: Vorgänge, Ereignisse und deren Abhängigkeiten.
Netzplan
• 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).
Definitionen
Dr. Ina Schaefer Software Engineering 1 Seite 45
Grundtypen von Netzplänen
Knoten: EreignissePfeile: VorgängeBeispiel: Critical Path Method (CPM)
Vorgangspfeil-Netzplan
Knoten: EreignissePfeile: AbhängigkeitenBeispiel: Program Evaluation and Review
Technique (PERT)
Ereignisknoten-Netzplan
Knoten VorgängePfeile: AbhängigkeitenBeispiel: Metra Potential Method (MPM)
Vorgangsknoten-Netzplan
Ereignis EreignisVorgang
Ereignis Ereignis
Vorgang Vorgang
Dr. Ina Schaefer Software Engineering 1 Seite 46
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)
Früher Start
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. (SET-Dauer)
Später Start
0706050403020152515049
Ende
FAT FET
Start
5251 04 055049 06 07030201
SAT
EndeStart
SET
Termine eines Vorgangs
Dr. Ina Schaefer Software Engineering 1 Seite 47
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.
Pufferzeiten
0652 0149 04 070302 055150
freie Pufferzeit
EndeStart
Zeitfenster
Pufferzeit
Dr. Ina Schaefer Software Engineering 1 Seite 48
Der kritische 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.
Kritischer Pfad
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.
06050403025049 07015251
krit. Vorgang
krit. Vorgang
krit. Vorgang
EndeStart
kritischer Pfad
Dr. Ina Schaefer Software Engineering 1 Seite 49
Metra Potenzial Methode (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
Grundideen MPM
Vorgangsname
Nr.
SAT Gesamt-puffer SET
FAT Dauer FET
Vorgangsname
Nr.
SAT Gesamt-puffer SET
FAT Dauer FETVorgangsname
Nr.
SAT Gesamt-puffer SET
FAT Dauer FET
Vorgangsname
Nr.
SAT Gesamt-puffer SET
FAT Dauer FETVorgangsname
Nr.
SAT Gesamt-puffer SET
FAT Dauer FET
Vorgangsname
Nr.
SAT Gesamt-puffer SET
FAT Dauer FET
Dr. Ina Schaefer Software Engineering 1 Seite 50
Gantt Diagramme
• 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
Grundideen Gantt
Dr. Ina Schaefer Software Engineering 1 Seite 51
Zusammenfassung
• Was ist ein Projekt?
• Aufgaben im Projektmanagement
• Aufwandsabschätzung• Function Point Verfahren• Expertenschätzung (Delphi-Verfahren)• CoCoMo Verfahren
• Planungstechniken• Netzplantechnik• Gantt Charts