Aufwandsabschätzung und Projektplanung - TU … · • Man weiß dann wenig über die Aufgabe. Aber: ... Prof. Dr. Ina Schaefer Software Engineering 1 Seite 11 Folgen von Fehlschätzungen

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.


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.


Wichtige Aspekte des Projektmanagements

•  Definition des Projektumfangs

•  Komplexität

•  Vorgehensmodell

•  Planung

•  Steuerung und Controlling

•  Änderungsmanagement

•  Risikomanagement

•  Reporting

•  Teammanagement

•  Offene Kommunikation & Feedback

•  Projekterfolg


Projektstrukturplan

Der PSP ist die vollständige, hierarchische Zerlegung des Projekts in Aufgaben und Arbeitspakete (AP). Synonym: Work breakdown structure (WBS)


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


Übersicht

•  Schätzung •  Allgemeine Grundlagen •  Function Point Verfahren •  Expertenschätzung (Delphi-Verfahren) •  CoCoMo Verfahren

•  Projektplanung •  Inhalte der Planung •  Planungstechniken


Schätzungen

Voraussagen sind schwierig,

vor allem, wenn sie die Zukunft

betreffen. Mark Twain


Gewünschter Zeitpunkt der Schätzung

Test & Integration

Fachliche Konzeption

Technische Konzeption Realisierung

Umfang der Funktionalität bekannt Fachliche Funktionen, Masken Umsetzung bekannt


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


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


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.


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.


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


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


Schätzverfahren Schätzverfahren unterscheiden sich in Zielsetzung, Aufwand und Genauigkeit


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


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


Bewertung der Fachlichkeit §  Details zum ersten Schritt




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


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


Bewertung der Einflussfaktoren §  Details zum zweiten Schritt




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.


Berechung des Gesamtaufwands §  Details zum dritten Schritt




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


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.


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.


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


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


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,…


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.


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


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.


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!


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


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


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)


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



Modellvarianten §  Einfluss der Modellvarianten auf die Schätzung


•  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


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)


Berechnung des Gesamtaufwands in CoCoMo


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


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


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


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


Projektverlauf, Ausführen des Plans

Planung Controlling (Überwachen) Steuern

SOLL

Handlungs- bedarf Maß-

nahmen

Anpassen

IST Meilensteine, Restaufwands- schätzungen

SOLL

Projektplanung im Projektmanagement


•  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


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


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


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


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


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


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


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.


FAT Dauer FET Vorgangsname

Nr.


FAT Dauer FET

Vorgangsname

Nr.


FAT Dauer FET Vorgangsname

Nr.


FAT Dauer FET

Vorgangsname

Nr.


FAT Dauer FET


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


Zusammenfassung

•  Was ist ein Projekt?

•  Aufgaben im Projektmanagement

•  Aufwandsabschätzung •  Function Point Verfahren •  Expertenschätzung (Delphi-Verfahren) •  CoCoMo Verfahren

•  Planungstechniken •  Netzplantechnik •  Gantt Charts

Documents

Aufwandsabschätzung und Projektplanung - TU … · • Man weiß dann wenig über die Aufgabe. Aber: ... Prof. Dr. Ina Schaefer Software Engineering 1 Seite 11 Folgen von Fehlschätzungen