View
217
Download
0
Category
Preview:
Citation preview
Prof. Dr. Ina Schaefer Software Systems Engineering
Technische Universität Braunschweig
(mit Folien von Dr. Gerhard Pews)
Aufwandsabschätzung und Projektplanung
Software Engineering 1 WS 2012/2013
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 2
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 3
Teufelsquadrat nach Sneed Wiederholung: Teufelsquadrat nach Sneed
© 2011 Capgemini – All rights reservedVortrag Projekt Management TU Braunschweig.pptx
62
Qualität Leistungsumfang
Zeit Kosten
++
- -
--
+ +
• Die Fläche (Produktivität) eines Projekts ist invariant
• Wenn ein Projekt z. B. in weniger Zeit und zu geringeren Kosten abgeschlossen werden soll, verringert sich auch der Leistungsumfang und die Qualität
• Steuerung:– Fall 1: Planung war nicht
umsetzbar: Ecken neu justieren– Fall 2: Produktivität im Team
stimmt nicht (Fläche)
Beachte: Die Fläche (Produktivität) eines Projekts ist invariant: Wenn ein Projekt z. B. in weniger Zeit und zu geringeren Kosten abgeschlossen werden soll, verringert sich auch der Leistungsumfang und die Qualität.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 4
Wichtige Aspekte des Projektmanagements
• Definition des Projektumfangs
• Komplexität
• Vorgehensmodell
• Planung
• Steuerung und Controlling
• Änderungsmanagement
• Risikomanagement
• Reporting
• Teammanagement
• Offene Kommunikation & Feedback
• Projekterfolg
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 5
Projektstrukturplan
Der PSP ist die vollständige, hierarchische Zerlegung des Projekts in Aufgaben und Arbeitspakete (AP). Synonym: Work breakdown structure (WBS)
© 2011 Capgemini – All rights reservedVortrag Projekt Management TU Braunschweig.pptx
29
Im ersten Planungsschritt wird der Projektstrukturplan (PSP) erstellt - dies bildet die Basis für den Projektplan
Der PSP ist die vollständige, hierarchische Zerlegung des Projekts in Aufgaben und Arbeitspakete (AP) Synonym: work breakdown structure (WBS)
Definition
AP
AP1.1.2
Dialog x
AP1.2.1
AP1.2.2
AP1.2.3
Batch x
KON-A
GUI
AWK
Test
Dialog y
AP2.2.1
AP2.2.2
AP2.2.3
Batch y …
REA-A
Projekt
…
1.1.1
Aufgabenkategorien
Aufgaben
Arbeitspakete
Projektstrukturplan
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 6
Ü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 7
Schätzungen
Voraussagen sind schwierig,
vor allem, wenn sie die Zukunft
betreffen. Mark Twain
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 8
Gewünschter Zeitpunkt der Schätzung
Test & Integration
Fachliche Konzeption
Technische Konzeption Realisierung
Umfang der Funktionalität bekannt Fachliche Funktionen, Masken Umsetzung bekannt
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 9
Tatsächlicher Zeitpunkt der Schätzung
Test & Integration
Fachliche Konzeption
Technische Konzeption 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
Prof. 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
Prof. 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.
Prof. 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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 13
Einflussfaktoren für Schätzungen
§ Wichtigste Einflussfaktoren auf den Aufwand Umzusetzende Fachlichkeit (funktional) • 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
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 14
Vorgehen bei einer Schätzung
Vorbereiten Messen, Vergleichen Lernen
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 15
Schätzverfahren Schätzverfahren unterscheiden sich in Zielsetzung, Aufwand und Genauigkeit
© 2011 Capgemini – All rights reservedVortrag Projekt Management TU Braunschweig.pptx
31
Aufwandsermittlung per empirisch gewonnenen Formeln
Basis sind „messbare“ Systemfunktionen, z. B. Use-Case-Points
Teilw. aufwändig, aber gute Resultate
ohne Justierung wenig präzise
Algorithmische Methoden
COCOMOFunction-PointsUse-Case-Points
Use-Case-Points verwenden wir zur Plausibilisierung
Stellt Bezug zu durchgeführten Entwicklungsprojekten her
Erfahrungswerte aus alten Projekten nötig
Gibt eine Größenordnung zur Verifikation
Vergleichs-methoden
Analogieschätzung
Selten in Reinform, aber implizit in Expertenschätzung
Berechnung von Schätzposten aus explizit geschätzten
Ähnlich Analogie-methode
Erfahrungswerte für Kennzahlen aus abgeschlossenen Projekte nötig
Kennzahlen-methode
Kennzahlen-methode
Kennzahlen aus dem Aufwandsmodell zur Plausibilisierung
Schätzung von Stücklisten
Zählen und bewerten
Erstmalige Schätzung neuer Anforderungen durch Expertenerfahrung
Experten-Schätzungen
EinzelschätzungDelphi-MethodeSchätzklausur
bei Capgeminihauptsächlich eingesetzte Methode
Prof. 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
Prof. 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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 18
Bewertung durch Function Points
§ Beispiel für eine Function Point Bewertung
Schätzposten Komplexität FP … … … Eingabedaten Kunde gering 3 Bankverbindung mittel 4 … … … Anfragen Kundensuche mittel 10 … … … Summe 458
Bewertungen Eingabedaten gering 3 mittel 4 hoch 6 Eigene Datenbestände gering 7 mittel 10 hoch 15 … …
Schätztabelle FP-Werte für jeweilige
Komplexitäten
Prof. 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.
Prof. 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
Prof. 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.
Prof. 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.
Prof. 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 Experten Ergebnis = Durchschnittwerte der Einzel-Schätzungen
Falls Breitband-Verfahren: Experten-Diskussion
Prof. 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
Prof. 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,…
Prof. 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 Realisierungs-Werten
Zuschläge • Addieren von Zuschlägen, z. B. für
Projektkoordination, Gewährleistung, Qualitätssicherung, etc.
Prof. 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
Prof. 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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 29
Aufschläge bei der Realisierungsschätzung
§ Erfahrungswerte für Zuschläge bei sd&m Zuschlag 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!
Prof. 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
Prof. 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
Prof. 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 (*1935)
Prof. 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)
Prof. 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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 35
Weitere 15 Einflussfaktoren
RELY: geforderte Zuverlässigkeit der Software DATA: Größe der Datenbasis CPLX: Komplexität des Produktes
Produkt
TIME: benötigte Rechenzeit STOR: Nutzung des verfügbaren
Speicherplatzes VIRT: Änderungshäufigkeit der
Systembasis TURN: Bearbeitungszyklus
Computer
MODP: Verwendung moderner Entwicklungsmethoden
TOOL: Verwendung von Tools SCED: Anforderungen an die
Entwicklungszeit
Projekt
ACAP: Analysefähigkeit der Mitarbeiter AEXP: Erfahrung der Mitarbeiter im
Arbeitsgebiet PCAP: Programmierfähigkeit der Mitarbeiter VEXP: Erfahrung der Mitarbeiter in der
Systemumgebung LEXP: Erfahrung der Mitarbeiter in der
Programmiersprache
Personal
m(x) = m(x1) * m(x2) * … * m(x15) MMDEV = a * KDSIb * m(X)
Prof. 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
Prof. 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
Prof. 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
Prof. 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
Prof. 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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 42
• WER (Personen) macht • WANN (Termine) • WAS (Aufgaben) • ggf. WOMIT (Arbeitsmittel)?
Fragestellung Im Projektplan finden sich die
Elemente: • Aufgabe, Aktivität/
Arbeitspaket (oft synonym verwendet)
• Ressourcen, insbesondere Personen
• Aufwände und Puffer • Termine
Inhalte
Inhalte der Planung
Prof. 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
Prof. 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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 45
Grundtypen von Netzplänen
Knoten: Ereignisse Pfeile: Vorgänge Beispiel: Critical Path Method (CPM)
Vorgangspfeil-Netzplan
Knoten: Ereignisse Pfeile: Abhängigkeiten Beispiel: Program Evaluation and Review
Technique (PERT)
Ereignisknoten-Netzplan
Knoten Vorgänge Pfeile: Abhängigkeiten Beispiel: Metra Potential Method (MPM)
Vorgangsknoten-Netzplan
Ereignis Ereignis Vorgang
Ereignis Ereignis
Vorgang Vorgang
Prof. 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
07 06 05 04 03 02 01 52 51 50 49
Ende
FAT FET
Start
52 51 04 05 50 49 06 07 03 02 01
SAT
Ende Start
SET
Termine eines Vorgangs
Prof. 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
06 52 01 49 04 07 03 02 05 51 50
freie Pufferzeit
Ende Start
Zeitfenster
Pufferzeit
Prof. 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.
06 05 04 03 02 50 49 07 01 52 51
krit. Vorgang
krit. Vorgang
krit. Vorgang
Ende Start
kritischer Pfad
Prof. 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 FET Vorgangsname
Nr.
SAT Gesamt- puffer SET
FAT Dauer FET
Vorgangsname
Nr.
SAT Gesamt- puffer SET
FAT Dauer FET Vorgangsname
Nr.
SAT Gesamt- puffer SET
FAT Dauer FET
Vorgangsname
Nr.
SAT Gesamt- puffer SET
FAT Dauer FET
Prof. 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
Recommended