+ All Categories
Home > Documents > Kapitel 2 - Universität Ulm · z2.7 Werkzeugunterstützung: Microsoft Project z2.8 Der...

Kapitel 2 - Universität Ulm · z2.7 Werkzeugunterstützung: Microsoft Project z2.8 Der...

Date post: 05-Jun-2018
Category:
Upload: nguyenmien
View: 213 times
Download: 0 times
Share this document with a friend
49
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 67 Kapitel 2 Projektplanung © 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 68 Aufbau der Vorlesung (Kapitel 2) Kapitel 2: Projektplanung z 2.1 Ziele und Inhalte der Planung ¾ Ablauf der Planung z 2.2 Das Projektziel ¾ Formulieren eines Projektziels ¾ Das Henne-Ei Problem der Entwicklung z 2.3 Organisatorische Aspekte von Projekten ¾ Organisationsformen für Projekt und Teams z 2.4 Projektstrukturplan z 2.5 Netzplantechnik z 2.6 Ressourcenplanung ¾ Kommunikation und Produktivität z 2.7 Werkzeugunterstützung: Microsoft Project z 2.8 Der Projektmanagement-Plan Kap. 2 (Projektplanung)
Transcript

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 67

Kapitel 2

Projektplanung

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 68

Aufbau der Vorlesung (Kapitel 2)

Kapitel 2: Projektplanung2.1 Ziele und Inhalte der Planung

Ablauf der Planung2.2 Das Projektziel

Formulieren eines ProjektzielsDas Henne-Ei Problem der Entwicklung

2.3 Organisatorische Aspekte von ProjektenOrganisationsformen für Projekt und Teams

2.4 Projektstrukturplan2.5 Netzplantechnik2.6 Ressourcenplanung

Kommunikation und Produktivität2.7 Werkzeugunterstützung: Microsoft Project2.8 Der Projektmanagement-Plan

Kap. 2 (Projektplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 69

Ziele der Planung (1)

Planung ist die geistige Vorwegnahme der kommenden RealitätDie Planung

befasst sich mit künftigen Ereignissen und Aufgabenbestimmt Vorgaben für die Durchführungempfängt Impulse aus der Kontrolle für Planungskorrektur

Basis einer verbindlichen Planung: klare Vorgabe allerProjektanforderungen

2.1 (Ziele und Inhalte der Planung)Kap. 2 (Projektplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 70

Ziele der Planung (2)

Beantwortung der W-Fragen

Kap. 2 (Projektplanung) 2.1 (Ziele und Inhalte der Planung)

Präferenzregelungen,Alternativplanungen,worst-case-Pläne liegenvor

Risiken abschätzen undKonzept zur Risikobehandlungentwerfen

Wo sind Projektrisiken?

Teilprojekt- undArbeitspaketverantwortliche sind festgelegt

Ressourcen zuteilenWer erledigt dieAufgabenstellungen?

Kostenplanung liegt vorKosten ermittelnWie hoch ist derRessourcenaufwand?

Terminplan liegt vorAblauf und Reihenfolgenfestlegen

Wann müssen die Aufgabenerledigt werden?

Vorgangsliste,Projektstrukturplan undProjektablauf liegen vor

Projekt in operationalisierte,übersichtliche, abschätzbare,kontrollierbare unddelegierbare Teile aufgliedern.

Was ist zur Zielerreichungzu tun?

TeilergebnisZielW.- Frage

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 71

Ablauf der Projektplanung (1)

Auftraggeber

Aufgabenstellung, Projektdefinition Lasten-heft

Pflichten-heft

ProjektstrukturplanZuständigkeitsmatrix Projektorganisation

Arbeitspaketbeschreibungen Vorgangslisten Mengengerüste

Ablauf-, Zeit- und Meilensteinpläne Kosten- und Finanzplan Kapazitätsplan

Planung

Test

Analyse

Design

Einführung

Evaluation

Installation

Projekt: FWTSBearbeiter: Ich

Aufgabe: Entwerfe Segel1) FhG Segel beauftrag2) Planung

Ergebnisse: BerichtKapazität: 2 Manntage

Vorgang

4711.3 EA+2 4711.25432.5 AA 2134.2654.2 EE-2 324.1

Vorgang4711.3 3 Analysten

4 Designer4711.3 2 Programmierer

5422.2 Rechenzentrum

4711.1 1 AnalystSimulationsrechner

Zuständigkeit

4711 Abt. FT7/SK5432 Abt. FT7/SL6540 Abt FT8/XY

Analyse

Kap. 2 (Projektplanung) 2.1 (Ziele und Inhalte der Planung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 72

Ablauf der Projektplanung (2)

Projektziel ist Ausgangspunkt aller weiteren AktivitätenProjektstrukturplan: Wurzelknoten beschreibt alle Aufgaben desProjekts, Blätter heißen Arbeitspakete, Knoten sind TeilaufgabenProjektteamorganisation existiert oft vor den AufgabenZuständigkeitsmatrix regelt das wer macht wasArbeitspaketbeschreibung hinreichend genau, um Arbeitspaketbearbeiten zu könnenVorgangslisten beschreibt wie stehen die Aufgaben zueinanderMengengerüste dokumentieren die benötigten Ressourcen jeAufgabeBalkenpläne und Netzpläne haben gleichen Informationsgehalt;beschreiben wer macht wann was womit

Kap. 2 (Projektplanung) 2.1 (Ziele und Inhalte der Planung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 73

Ablauf der Projektplanung (3)

Meilensteinpläne definieren ZwischenergebnisseKosten- und Finanzplan: Sollplanung der benötigten FinanzmittelKapazitätsplan aus Zeitscheiben im Balkenplan; Auslastung überder Zeit

Kap. 2 (Projektplanung) 2.1 (Ziele und Inhalte der Planung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 74

Ablauf der Projektplanung: Projektziel

Auftraggeber

Aufgabenstellung, Projektdefinition Lasten-heft

Pflichten-heft

ProjektstrukturplanZuständigkeitsmatrix Projektorganisation

Arbeitspaketbeschreibungen Vorgangslisten Mengengerüste

Ablauf-, Zeit- und Meilensteinpläne Kosten- und Finanzplan Kapazitätsplan

Planung

Test

Analyse

Design

Einführung

Evaluation

Installation

Projekt: FWTSBearbeiter: Ich

Aufgabe: Entwerfe Segel1) FhG Segel beauftrag2) Planung

Ergebnisse: BerichtKapazität: 2 Manntage

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

Zuständigkeit

4711 Abt. FT7/SK5432 Abt. FT7/SL6540 Abt FT8/XY

Vorgang

4711.3 EA+2 4711.25432.5 AA 2134.2654.2 EE-2 324.1

Vorgang4711.3 3 Analysten

4 Designer4711.3 2 Programmierer

5422.2 Rechenzentrum

4711.1 1 AnalystSimulationsrechner

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 75

Das Projektziel (1)

„Wichtiger als die Auswahl der richtigen Lösungen ist zunächst dieBestimmung der richtigen Ziele“(Hall, A Methodology for System Engineering)

Grundlage jedes Projekts: Zugrunde liegende Anforderungen

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

Gesamtzielsetzung

Ergebnisziele Vorgehensziele

Finanzziele Funktionsziele Terminziele

Kostenziele

Personelle Z.

Politische Z.

Leistungsziele

Qualitätsziele

Sicherheitsz.

Wirtschaftlichkeit

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 76

Das Projektziel (2)

Projektziele sollten folgende Eigenschaften aufweisen:lösungsneutral (siehe auch folgenden Exkurs)widerspruchsfrei(möglichst) vollständigstrukturiertaufgeteilt in Muss-Ziele, Kann-Ziele und Nicht-Zieleakzeptiert von Auftraggeberakzeptiert vom Projektleiteranspruchsvoll, aber erreichbar (realistisch)

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 77

Exkurs: Abstraktionsstufen von Anforderungen

Goal-Level RequirementsUnsere Kalkulationen sollen eine Genauigkeit von 5% aufweisen

Domain-Level RequirementsDas IT-System soll die Kalkulation durch Erfahrungswert (ausabgeschlossenen Projekten) unterstützen

Product-Level RequirementsDas IT-System soll Speicherungs- und Abrufefunktionen fürKalkulationsdaten abgeschlossener Projekte (Erfahrungswerte)beinhalten

Design-Level RequirementsDie Kalkulation soll in der Bildschirmmaske x.y erfolgen.

Quelle: Soeren Lauesen

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 78

Template ‚Projektziel‘

Projekt: Titel

Gesamtziel: Was liegt bei Projektabschluß vor?

Vorbemerkungen: Motivation, Kontext

Ergebnisziele1) Leistungsziele/Funktionsziele: Was kann das Produkt?2) Qualitätsziele: Z.B. Performance, Sicherheit, Stabilität3) Wirtschaftlichkeitsziele: I.d.R. nur bei HW relevant4) Ökologische Ziele: I.d.R. nur bei HW relevant

Vorgehensziele1) Terminziele: Bis wann?2) Kostenziele: Welcher Kostenrahmen?3) Politische Ziele: Z.B. Wiederverwendbarkeit

Projektauftrag: Schriftlich fixiertes GO (mit Unterschriften)

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 79

Projektziele - Lastenheftstruktur nach Balzert

1 ZielbestimmungHier wird beschrieben, welche Ziele durch den Einsatz desProduktes erreicht werden sollen.

2 ProdukteinsatzEs wird festgelegt, für welchen Anwendungsbereich und fürwelche Zielgruppe das Produkt vorgesehen ist.

3 ProduktfunktionenDie Hauptfunktionen des Produkt werden beschrieben.

4 ProduktdatenDie Hauptdaten des Produkts, die permanent gespeichertwerden müssen, werden festgelegt.

5 ProduktleistungenLeistungsanforderungen bzgl. Zeit, Datenumfang oderGenauigkeit werden hier aufgeführt.

6 QualitätsanforderungenDie wichtigsten Qualitätsanforderungen sollten hieraufgeführt sein, wie Zuverlässigkeit, Benutzbarkeit, usw.

7 ErgänzungenHier finden sich Ergänzungen oder spezielle Anforderungen.

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 80

Das Henne-Ei Problem der Entwicklung (1)

Dilemma:Eine genaue Anforderungsbeschreibung ist Voraussetzung für eine guteProjektplanungABER: Die Analyse ist typischerweise die erste Phase eines Projekts

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

Analyse /Planung

Durchführung

Zeit /Kostenbeeinflussbarkeit

Anforderungskenntnis

Projektfortschritt

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 81

Das Henne-Ei Problem der Entwicklung (2)

Saubere Lösung: Vorprojekt

Ziele:Bedarfsanalyse (Was braucht man wirklich?)

SpezifikationMachbarkeitsanalyse (Kann das Ziel überhaupt erreicht werden?)Aufzeigen von Umsetzungsalternativen (z.B. intern vs. extern)KostenabschätzungEmpfehlung2 Wochen – 2 Monate

Kap. 2 (Projektplanung) 2.2 (Das Projektziel)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 82

Ablauf der Projektplanung

Auftraggeber

Aufgabenstellung, Projektdefinition Lasten-heft

Pflichten-heft

ProjektstrukturplanZuständigkeitsmatrix Projektorganisation

Arbeitspaketbeschreibungen Vorgangslisten Mengengerüste

Ablauf-, Zeit- und Meilensteinpläne Kosten- und Finanzplan Kapazitätsplan

Planung

Test

Analyse

Design

Einführung

Evaluation

Installation

Projekt: FWTSBearbeiter: Ich

Aufgabe: Entwerfe Segel1) FhG Segel beauftrag2) Planung

Ergebnisse: BerichtKapazität: 2 Manntage

Kap. 2 (Projektplanung) 2.1 (Organisatorische Aspekte von Projekten)

Zuständigkeit

4711 Abt. FT7/SK5432 Abt. FT7/SL6540 Abt FT8/XY

Vorgang

4711.3 EA+2 4711.25432.5 AA 2134.2654.2 EE-2 324.1

Vorgang4711.3 3 Analysten

4 Designer4711.3 2 Programmierer

5422.2 Rechenzentrum

4711.1 1 AnalystSimulationsrechner

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 83

Organisation - Motivation und Einführung (1)

Unternehmen – oder allgemeiner Institutionen – ab einerbestimmten Größe müssen sich, um zielgerichtet arbeiten können,eine Struktur geben.In dieser nehmen einzelne Stellen wohldefinierte Aufgaben wahr.Diese Struktur wird als Organisation bezeichnet.

UnterscheidungAufbauorganisation: Hierarchische Untergliederung einesUnternehmensAblauforganisation: Regelung der Arbeitsabläufe

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 84

Organisation - Motivation und Einführung (2)

Beispiel: Aufbauorganisation

Hier: Hierarchische Untergliederung nach Funktionen imUnternehmen

Unternehmensleitung

Vertrieb Beschaffung FinanzierungProduktion

Prod. A Prod. B Prod. A Prod. B

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 85

Organisation - Motivation und Einführung (3)

Beispiel: AblauforganisationAblauf einer Stapel-Buchhaltung (nach Wedekind 1988)

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

Vorgang Buchhaltung Datenerfassung RechenzentrumBelege sortieren und prüfenAbstimmungssumme bildenBelege versendenDatenerfassungKontrolle der ErfassungKorrekturDatenträger ins RZRücktransport der BelegeBelegablageRZ-AuswertungenAuswertungen versendenAuswertungen prüfenUrbelege suchenKorrekturenAuswertungen ablegen

Elemente derAufbauorganisation

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 86

Organisation - Motivation und Einführung (4)

Regelung der Ablauforganisation bei SoftwareprojektenDurch Vorgehensmodelle (siehe Kapitel 1)

Offen: Definition der Aufbauorganisation von Softwareprojekten undderen Integration in die Gesamt-Aufbauorganisation

Facetten:Aufbauorganisatorische Grobstruktur des gesamten UnternehmensEinordnung des „IT-Bereichs“ in die GrobstrukturInterne Struktur des IT-BereichsIntegration von Softwareprojektenin die Gesamt-AufbauorganisationProjektinterne Aufbauorganisation

Fokus

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 87

Notation: Leitungsstelle, Stabsstelle, ausführende Stelle

LeitungsstelleStabsstelle

AusführendeStelle

Quelle: Henrich, Management von Softwareprojekte, 2001

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 88

Integration von Softwareprojekten in Aufbauorganisation

Drei Haupt-AusprägungenReine ProjektorganisationMatrixorganisationLinienorganisation (auch Einfluss-Projektorganisation genannt)

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 89

Reine Projektorganisation (1)

KennzeichenMitarbeiter (MA) ist fachlich und disziplinarisch dem Projektleiter (PL)unterstelltPL ist verantwortlich für Kosten, Termine, Qualität des ProduktesMA werden für die Dauer des Projektes organisatorisch aus ihrer altenPosition gelöst

Unternehmensleitung

Abteilung A Abteilung B Abteilung C

(1) (3)(2)1 2 3

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

Projektleiter

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 90

Reine Projektorganisation (2)

VorteileEinheit von Verantwortung und Kompetenz beim PLEindeutige Unterstellung der MA (Weisungsbefugnis)Volle Konzentration der MA auf das Projekt und ihre Aufgaben darinKlare Anlaufstelle für AuftraggeberRasche Entscheidungsfindung durch klare VerantwortlichkeitenMA identifizieren sich mit dem ProjektProjektspezifische Vorgehensweisen sind gut umsetzbar

NachteileRekrutieren von MA (Fachabteilungen wollen nicht ihre besten Leuteabgeben; Übernahme aus auslaufenden Projekten)Ungewisse Zukunft der MA(Werden sie wieder in Fachabteilung übernommen?)Rivalität mit LinienabteilungenErfahrungstransfer über Projekte hinweg schwierig

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 91

Reine Linienorganisation (1)

KennzeichenMitarbeiter (MA) ist fachlich und disziplinarisch dem AbteilungsleiterunterstelltPL hat keine Weisungsrechte (ist eher Projektkoordinator)MA sind i.d.R. an verschiedenen Projekten beteiligt

Unternehmensleitung

Abteilung A Abteilung B Abteilung C

PL

1 2 3

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 92

Reine Linienorganisation (2)

VorteileProjekte können einfach (schnell) gestartet und beendet werden, dakein/wenig organisatorischer OverheadKeine Unsicherheit für MitarbeiterProjektübergreifender Informationsaustausch wird gefördert(insbesondere innerhalb der Fachabteilungen)Linienabteilungen sind stärker eingebunden(haben Interesse an Projekterfolg, da dafür mit-verantwortlich)

NachteileUnklare Verantwortlichkeiten und Entscheidungen (PL ist „zahnlos“)Motivation/Identifikation der MA ist eher gering

Beteiligung eines MA an mehreren ProjektenAbteilungsinteressen gehen vor ProjektinteressenKein klarer/kompetenter Ansprechpartner für Auftraggeber

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 93

Matrixorganisation (1)

KennzeichenPL ist verantwortlich für Kosten, Termine, Qualität des ProduktesMitarbeiter (MA) verbleiben in Linienposition, sind aber ganz oderteilweise dem Projekt zugeordnetMA ist fachlich dem PL, disziplinarisch dem Linienvorgesetztenunterstellt

Unternehmensleitung

Abteilung A Abteilung B Abteilung C

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

Projektleiter

1 2 3

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 94

Matrixorganisation (2)

Zwischenlösung Projektorganisation - LinienorganisationAufgabenteilung Projektleitung/Linienabteilung

„Die Projektleitung ist für die Projektplanung, überwachung undsteuerung verantwortlich; für die projektbezogenen fachlichen

Aufgaben sind die Linieninstanzen verantwortlich. Die Projektmitarbeiterwerden temporär in die Projektgruppe delegiert; sie unterstehen fachlichder Projektleitung, disziplinär ihrem Linienvorgesetzten.“(Heinrich 1997)

Auftragserteilung über zwei KanäleKonfliktpotential

Notwendigkeit des Konsens zwischen PL und Linien-VorgesetztenAnnahme: Durch Konsens entstehen bessere Lösungen

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 95

Matrixorganisation (3)

Unternehmensleitung

Linienvorgesetzter

Projektleiter Mitarbeiter

Kunde

Projektstatus

Wann (Termine)Wieviel (Kosten)Was (Leistung, Ziel)

Wie (Methode)Wer (Mitarbeiter)

Kompetenzaufteilung ineiner Matrixorganisation

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 96

Matrixorganisation (4)

VorteileProjekte können einfach (schnell) gestartet und beendet werden, dawenig organisatorischer OverheadKeine Unsicherheit für MitarbeiterProjektübergreifender Informationsaustausch wird gefördertLinienabteilungen sind stärker eingebundenKlarer Ansprechpartner für AuftraggeberNotwendigkeit des Konsens führt zu ganzheitlicher Projektbetrachtung

NachteileHohes KonfliktpotentialZuordnung zu zwei Führungskräften kann Verunsicherung der MAbedeuten (oder MA spielt Vorgesetzte gegeneinander aus)Hoher Kommunikationsaufwand (durch Zwang zum Konsens)

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 97

Projektinterne Aufbauorganisation (1)

Fall 1: Hierarchisches Team (Regelfall)

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

Projektleiter

Verifikation,Test

Analyse undDesign

Programmierung,Integration

Planungund Kontrolle

Konfigu-rationsmanager

Qualitäts-manager

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 98

Projektinterne Aufbauorganisation (2)

Fall 2: Egoless Programmierer–Team (Demokratisches Team)Alle Entscheidungen werden in der Gruppe (ca. 10-12 Personen)getroffen. Gruppenleitung (eher: Sprecher) rotiert.

Fall 3: Chief Programmer Team (IBM)Jedes Projektteam hat 3-4 permanent zugeordnete Mitglieder (Chiefprogrammer, backup programmer, program librarian); weitere Mitgliedernur bei Bedarf; Chief programmer managed alle technischen AspekteDer program librarian pflegt alle Dokumente und übernimmtadministrative Aufgaben

Kap. 2 (Projektplanung) 2.3 (Organisatorische Aspekte von Projekten)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 99

Ablauf der Projektplanung: Projektstrukturplan

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

Auftraggeber

Aufgabenstellung, Projektdefinition Lasten-heft

Pflichten-heft

ProjektstrukturplanZuständigkeitsmatrix Projektorganisation

Arbeitspaketbeschreibungen Vorgangslisten Mengengerüste

Ablauf-, Zeit- und Meilensteinpläne Kosten- und Finanzplan Kapazitätsplan

Planung

Test

Analyse

Design

Einführung

Evaluation

Installation

Projekt: FWTSBearbeiter: Ich

Aufgabe: Entwerfe Segel1) FhG Segel beauftrag2) Planung

Ergebnisse: BerichtKapazität: 2 Manntage

Zuständigkeit

4711 Abt. FT7/SK5432 Abt. FT7/SL6540 Abt FT8/XY

Vorgang

4711.3 EA+2 4711.25432.5 AA 2134.2654.2 EE-2 324.1

Vorgang4711.3 3 Analysten

4 Designer4711.3 2 Programmierer

5422.2 Rechenzentrum

4711.1 1 AnalystSimulationsrechner

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 100

Projektstrukturplan

Engl: Work Breakdown Structure (WBS)

Projektstrukturplan beschreibt die Gesamtheit der wesentlichenBeziehungen zwischen den Elementen eines Projekts [DIN 69901]

Hierarchische Gliederung der Gesamtaufgabe nach formalenund/oder inhaltlichen Merkmalen in einzelne Teilaufgaben(nicht zeitlich gegliedert später)

Möglichkeit der Strukturierung:Objekt/Produktorientiert Gliederung nach „Bestandteilen“ desSystemsFunktionsorientiert (Phasenorientiert) Gliederung nachEntwicklungsfunktionen

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 101

Objektorientierter Projektstrukturplan

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

Projekt BSH 3000

Debitorensystem Kreditorensystem Anlagebuchhaltung Lohnbuchhaltung

Konvertierungs-stamm

Konvertierungs-stamm

Archivsystem Altes Daten-verwaltungsystem

KennzeichenZergliederung des Projekts in die inhaltlichen Bestandteile(Produktbestandteile)Aktivitäten erscheinen nicht

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 102

Funktionsorientierter Projektstrukturplan

Projekt BSH 3000

Planungsphase Analysephase Realisierungsphase Einführungsphase

Projektplanung

Durchführung vonErhebungen

Prototyping

Erstellen vonEreignislisten

Programmierung Schulungen

Benutzerbetreuung

KennzeichenZergliederung des Projekts in die durchzuführendenAktivitäten/AufgabenInhaltliche Bestandteile erscheinen nicht

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 103

Eigenschaften eines Projektstrukturplans (1)

Häufig: Mischform, in der auf oberen Ebenen objektorientiertstrukturiert, auf unteren Ebenen funktionsorientiert strukturiert.Wichtig: Auf einer Ebene nicht funktionsorientiert undobjektorientiert mischen!Nummerierung der einzelnen Elemente:

Alternativ: Dewey-Notation (1.1.2.4)

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

0000

1000 2000 3000 4000

1100

1200

2100

2200

3100

3200

4100

420012101220

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 104

Eigenschaften eines Projektstrukturplans (2)

Standardabschnitte jedes Projektstrukturplans:Projektmanagement (1000) mit Planung, ÜberwachungSteuerung (1100)Administration (1200)Dokumentation (1300)QualitätssicherungKonfigurationsmanagement

ArbeitspaketeBlätter des Projektstrukturplans beschreiben ArbeitspaketeErgebnis: Beschreibung von Vorgängen mit benötigten Ressourcen

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 105

Arbeitspaketbeschreibung - Template

Projekt:Projektnummer:Hauptaufgabe/Teilprojekt: Nr:Teilaufgabe: Nr:Arbeitspaket: Nr:

Aufgaben/LeistungsumfangVorgangsnummer Beschreibung (in Stichworten) Dauer (T) Aufwand (PT)1)2)3)4)5)

Grundlagen/Vorschriften:

Voraussetzungen/Randbedingungen:

Schnittstellen/Kommunikation:

Ergebnisse/Leistungsziele:

Durchführende Stelle, Verantwortlicher:

Stand:

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 106

Regeln für die Erstellung eines Projektstrukturplans

Mit Beteiligten abstimmenBei größeren Projekten: Übersichtsplan und detaillierte PhasenpläneKomplexe (und damit risikoreichere) Aufgaben müssen stärkeruntergliedert werdenKriterium für Blätter:

Arbeitspaket sollte im Verhältnis zur Projektlaufzeit so klein sein, daßeine wirkungsvolle Steuerung erfolgen kannArbeitspakete mit 1 Jahr ist Schwachsinn; Heuristik: 3-4 Wochen bis 3-4MonateTeilaufgaben und Arbeitspakete sollten so formuliert sein, dass beiAbschluss jeweils ein klar fassbares Arbeitsergebnis vorliegt(gilt nicht für Unterstützungsaufgaben wie Steuerung, Dokumentation, ...)

Aufbaustruktur (Produkterstellung) und Organisationsstruktur(späterer Betrieb des Produkts) strikt auseinander halten

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 107

Erfahrungswerte für die Projektstrukturierung (1)

In der Regel 3-5 Ebenen ausreichendFolgende Breiten je Ebene sind sinnvoll:

4 bis 7 Teilaufgaben auf der 1. Ebene10 bis 30 Teilaufgaben auf der 2. Ebene30 bis 120 Teilaufgaben auf der 3. Ebene100 bis 500 Teilaufgaben auf der 4. Ebene

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

10000

1000

100

10

1Empf

ohle

ne A

rbei

tspa

kete

39 78 156 313 625 1.250 2.500 5.000 10.000 20.000 40.000 80.000

Projektaufwand in T€

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 108

Erfahrungswerte für die Projektstrukturierung (2)

Klassische Fehler bei der Projektplanung„Hurra, wir haben einen Plan“Plan nur einmal erstellen, nie wieder ändernSuper-Detail-Pläne

Symptome für zu wenig PlanungImmer hektische Erteilung von Aufgaben, deren Ergebnisse späterniemand interessierenBei Entscheidungssituationen stellt sich heraus, dass wichtigeVorarbeiten nicht durchgeführt wurdenArbeitsbelastung im Team ist sehr ungleichmäßigMitarbeiter nehmen Vorgaben nicht ernst, weil niemand derenEinhaltung überprüftAufgaben erledigen sich „von selbst“ (Aussitzen)

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 109

Erfahrungswerte für die Projektstrukturierung (3)

Symptome für zu viel PlanungArbeitspakete werden auf Stundenbasis geplant (Ausnahme: Meetings,Abnahmesitzungen, o.ä.); in der Regel sollte nicht feiner als auf Tages-oder Wochenbasis geplant werdenPlan kann aufgrund seiner Detaillierung nicht mehr aktuell gehaltenwerdenÜberprüfungsaufwand für den Plan steht in keinem Verhältnis zumeigentlichen Entwicklungsaufwand

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 110

Ablauf der Projektplanung: Ablaufpläne/Netzplantechnik

Auftraggeber

Aufgabenstellung, Projektdefinition Lasten-heft

Pflichten-heft

ProjektstrukturplanZuständigkeitsmatrix Projektorganisation

Arbeitspaketbeschreibungen Vorgangslisten Mengengerüste

Ablauf-, Zeit- und Meilensteinpläne Kosten- und Finanzplan Kapazitätsplan

Planung

Test

Analyse

Design

Einführung

Evaluation

Installation

Projekt: FWTSBearbeiter: Ich

Aufgabe: Entwerfe Segel1) FhG Segel beauftrag2) Planung

Ergebnisse: BerichtKapazität: 2 Manntage

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

Zuständigkeit

4711 Abt. FT7/SK5432 Abt. FT7/SL6540 Abt FT8/XY

Vorgang

4711.3 EA+2 4711.25432.5 AA 2134.2654.2 EE-2 324.1

Vorgang4711.3 3 Analysten

4 Designer4711.3 2 Programmierer

5422.2 Rechenzentrum

4711.1 1 AnalystSimulationsrechner

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 111

Meilensteine

Meilensteine . . .... kennzeichnen Anfang und Ende eines Projekt, Abschluss einer

Phase und meist den Abschluss... einer Gruppe von Vorgängen (i.d.R. Arbeitspaket).... sind keine Vorgang und benötigen keine Zeit.... geben dem Projektleiter klare und eindeutige Anhaltspunkte

für die Bewertung des Projektfortschritts... sollten folgende Eigenschaften haben:

ÜberprüfbarkeitKurzfristigkeitGleichverteilung

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 112

Zusammenhang von Meilensteinen, Phasen imWasserfallmodell und Projekttätigkeiten:

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

Aufwand für dieeinzelnen Tätigkeiten

Zeit(Phase)

M1 M2 M3 M4 M5Anforderungsdokument V1 V2 V3Architekturbeschreibung V1 V2Entwurfsbeschreibung V1 V2Quellcode V1 V2Testvorschrift V1 V2 V3Benutzerhandbuch V1 V2

spezifizieren entwerfen codieren testen

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 113

Meilensteine

Interne und externe Meilensteine

Unterschiedliche „Adressaten“ von MeilensteinenAuftraggeber - für Entscheidungen des Auftraggebers

- für Lieferung in und aus ProjektProjekteigentümer - für Entscheidungen des ProjekteigentümersProjektleiter - für Ereignisse im Projekt

Mögliche Entscheidungen bei Meilensteinen:Freigabe der Mittel für die nächste Phase oder das nächsteArbeitspaketZurückweisung (mit der Konsequenz einer Planänderung)Abbruch des Projekts

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 114

Vorgangsbeziehungen (1)

Zwischen Vorgängen (Arbeitspaketen) gibt es in der RegelBeziehungen (z.B. A darf nicht vor dem Ende von B beginnen)

Mögliche zeitliche Vorgangsbeziehungen:Normalfolge Ende–Anfang (EA)Anfangsfolge Anfang–Anfang (AA)Endfolge Ende–Ende (EE)Sprungfolge Anfang–Ende (AE)

Normalfolge Ende-AnfangVorgang B darf erst beginnen, wenn Vorgang A abgeschlossen ist„Normalfall“tA(B) tE(A)

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 115

Vorgangsbeziehungen (2)

Anfangsfolge Anfang–AnfangVorgang B darf erst beginnen, nachdem Vorgang A begonnen wurde isttA(B) tA(A)

Endfolge Ende–EndeVorgang B darf erst enden, nachdem Vorgang A beendet wurdeBsp: Ergebnisse aus B müssen anhand der Ergebnisse aus A überprüftwerdentE(B) tE(A)

Sprungfolge Anfang–EndeVorgang B darf enden enden, nachdem Vorgang A begonnen wurdeBsp: „Übergabe“ von B an AtE(B) tA(A)

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 116

Vorgangsbeziehungen (3)

A

B

Zeit

EA-Beziehung

A

B

Zeit

AA-Beziehung

A

B

Zeit

EE-Beziehung

A

B

Zeit

AE-Beziehung

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 117

Vorgangsbeziehungen (4)

Zusätzlich können zusammengehörende Vorgänge überlappt oderverzögert werden, d.h. es kann ein positiver oder negativerZeitabstand angegeben werdenBeispiele:

A

B

Zeit

EA + 1T

plus 1 Tag A

B

Zeit

AA - 4T

minus 4 Tage

A

B

Zeit

AE + 2T

plus 2 Tage

Kap. 2 (Projektplanung) 2.4 (Projektstrukturplan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 118

Netzplantechnik

In Netzplänen werden die verschiedenen Aktivitäten sowie ihrejeweiligen Abhängigkeiten graphisch dargestellt.

Basierend auf Netzplänen können Analysen durchgeführt werdenTerminrechnung (z.B. frühestes Projektende)Ressourcenrechnungen (vgl. Kapitel 2.6)

Es gibt verschiedenen Methoden und Darstellungsformen, z.B.CPM (Critical Path Method)PERT (Program Evaluation and Review)VKM (Vorgangsknoten-Methode)

Vorgangsknoten-NetzplanGANTT-Diagramme

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 119

Terminrechnung (1)

Informationen zu einem Vorgangsknoten

Aus der ArbeitspaketbeschreibungNameDauerAbhängigkeiten zu anderen Arbeitpaketen (Vorgangsbeziehungen)

Name

FST (FrühesterStarttermin)

Dauer Puffer

FET (FrühesterEndtermin)

SST (SpätesterStarttermin)

SET (SpätesterEndtermin)

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 120

Terminrechnung (2)

Beispiel

Fragen:Wann ist das Projekt frühestens abgeschlossen?Wann kann das Projekt spätestens begonnen werden?

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

A 5

B 4

D 10

C 3

E 2

Alle Beziehungen: EA

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 121

Terminrechnung (3)

Wann ist das Projekt frühestens abgeschlossen?Vorwärtsrechnung

A 5

B 4

D 10

C 3

E 2

0 5

5 9 9 12

5 15

15 17

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 122

Terminrechnung (4)

Hinweis:Die Termine (z.B. bei Tagesplanung) können als Zeitpunkt am Morgenaufgefasst werden.

Z.B: Starttermin 6, Endtermin 9 bedeutet

Die Aktivität wird am Morgen des Tages 6 begonnen undist am Morgen des Tages 9 abgeschlossen.

Die Bearbeitung der Aufgabe fand also an den Tagen 6, 7 und 8 statt

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 123

Vorwärtsrechnung (1)

Der Früheste Starttermin eines Vorgangs Vj kann wie folgt bestimmtwerden:

Sei PEAj die Menge der Vorgänge, zu denen Vj eine Ende-AnfangBeziehung hatSei zEA i, j die zeitliche Verzögerung für die Ende-Anfang AbhängigkeitAnalog seien definiertPAAj, zAA i, j PEEj, zEE i, j PAEj, zAE i, j

Dann ergibt sich für den frühesten Starttermin des Vorgangs Vj

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

AAjijAAijEAjijEAijj PVzFSTPVzFETFST ,,max

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 124

Vorwärtsrechnung (2)

Der Früheste Endtermin ergibt sich wie folgt

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

EEjijEEij

AEjijAEij

jj

j

PVzFETPVzFST

DFSTFET

,

,max

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 125

Rückwärtsrechnung (1)

Wann kann das Projekt spätestens begonnen werden?Rückwärtsrechnung

A 5

B 4

D 10

C 3

E 2

17

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 126

Rückwärtsrechnung (1)

Wann kann das Projekt spätestens begonnen werden?Rückwärtsrechnung

A 5

B 4

D 10

C 3

E 2

0 5

5 9 9 12

5 15

15 17

15 17

12 15

5 15

8 12

0 5

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 127

Rückwärtsrechnung (2)

Der Späteste Endtermin eines Vorgangs Vj kann wie folgt bestimmtwerden

Der Späteste Starttermin eines Vorgangs Vj kann wie folgt bestimmtwerden

EEijiiEEji

EAijiiEAjij

PVVzSET

PVVzSSTSET

mit

mitmin

,

,

AAijiiAAjj

AEijiiAEjj

jj

j

PVVzSST

PVVzSET

DSET

SST

mit

mitmin

,

,

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 128

Pufferzeiten (1)

Zeit zwischen frühesten und spätesten Terminen bezeichnet manals Pufferzeiten

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

A 5

B 4

D 10

C 3

E 2

0 5

5 9 9 12

5 15

15 17

15 17

12 15

5 15

8 12

0 5

0

3 3

0

0

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 129

Pufferzeiten (2)

Puffer ermöglicht Freiräume bei der Planung. Es lassen sich zweiArten von Pufferzeiten unterscheiden:

Freie Pufferzeit: Zeitspanne, um die sich ein Vorgang verzögern kann,ohne einen anderen Vorgang zu verzögernGesamte Pufferzeit: Zeitspanne, um die sich ein Vorgang verzögernkann, ohne den Endtermin zu beeinflussen

Pufferzeiten entstehen durch Vorgangsbeziehungen und sonstigeBeschränkungen, zum Beispiel

Vorgang beginnt nicht vor X.X.XXVorgang fängt so spät wie möglich an.

Besitzt ein Vorgang keine Pufferzeit, so heißt er kritischer Vorgang.Die Vorgangsfolge, die genau so lange dauert wie dasGesamtprojekt heißt kritischer Pfad.

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 130

Pufferzeiten (3)

Eine Verzögerung in einem Vorgang auf dem Kritischen Pfad wirktsich immer unmittelbar auf die Gesamtprojektdauer aus.Verzögerungen außerhalb des kritischen Pfads wirken sich(zunächst) nur auf die Pufferzeiten aus

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

A

B

C

E

D

Lage und Dauer eines kritischen Vorgangs

Früheste Verarbeitung eines unkritischen Vorgangs

Pufferzeit eines unkritischen Vorgangs

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 131

Pufferzeiten (4)

Ein Netzplan (bzw. GANTT–Diagramm) heißt zeitkonsistent, wennkeine negativen Puffer (= verletzte „Sperrzeiten“) auftreten.Fehlen feste Termine, so ergibt sich immer ein zeitkonsistenter Plan.

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 132

Darstellung: GANTT-Diagramme (1)

Zeitstrahl mit Blöcken für jeden VorgangVorgänge sind Zeitproportional dargestelltStart-, Endtermin und Dauer ergeben sich aus der Lage zumZeitstrahlVorgangsname, Bearbeiter und Vorgangsbeziehung sind am linkenRand annotiertMeilensteine sind RautenAbhängigkeiten werden durch Pfeile dargestellt

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 133

Darstellung: GANTT-Diagramme (2)

Beispiel

Zeit

Nr. Vorgang Bearbeiter Vorgänger

1 Vorgang A Hr. Müller -

2 Meilenstein Alpha - 1 EA

3 Vorgang B Fr. Huber 2 EA + 3

4 Vorgang C Fr. Schmidt 2 EA

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 134

Darstellung: Vorgangsknoten–Netzplan

Gerichteter GraphKnoten sind VorgängeKanten sind AbhängigkeitenMeilensteine sind doppelt umrandete KnotenVorgangsname, Vorgangsbeziehungen, Starttermin, Endtermin,Dauer und Bearbeiter des Vorgangs sind im Knoten annotiertBeispiel:

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

Vorgang

Abhängigkeit

Meilenstein

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 135

Verfeinerung der Planung

Planung Stufe 1(Top-Management)

Planung Stufe 2(Projektmanager)

Planung Stufe 3(Unterauftragnehmer)

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 136

Beispiel: Terminplanung in der Fahrzeugentwicklung

Kap. 2 (Projektplanung) 2.5 (Netzplantechnik)

Fahrzeugentwicklung

Konzept & Partitionierung

Subsystementwicklung(Antriebsstrang, Fahrwerk,Karosserie, Multi-Media)

Integration (Fahrzeugprototypen)

Integration (Vorserien-und Serienfahrzeuge)

Entwicklung elektronischer Systeme

Analyse & Spezifikation dertechnischen Systemarchitektur

Software-, Hardware-, Sollwertgeber-,Sensor- & Aktuatorentwicklung

Integration, Test & Kalibrierung derelektronischen Systeme

Software-Entwicklung

Analyse & Spezifikation derSoftwarearchitektur

Spezifikation, Design & Implementierungder Software-Komponenten

Integration & Test der SoftwareQuelle: Schäuffele, Zurawka

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 137

Ablauf der Projektplanung: Ressourcenplanung

Auftraggeber

Aufgabenstellung, Projektdefinition Lasten-heft

Pflichten-heft

ProjektstrukturplanZuständigkeitsmatrix Projektorganisation

Arbeitspaketbeschreibungen Vorgangslisten Mengengerüste

Ablauf-, Zeit- und Meilensteinpläne Kosten- und Finanzplan Kapazitätsplan

Planung

Test

Analyse

Design

Einführung

Evaluation

Installation

Projekt: FWTSBearbeiter: Ich

Aufgabe: Entwerfe Segel1) FhG Segel beauftrag2) Planung

Ergebnisse: BerichtKapazität: 2 Manntage

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

Zuständigkeit

4711 Abt. FT7/SK5432 Abt. FT7/SL6540 Abt FT8/XY

Vorgang

4711.3 EA+2 4711.25432.5 AA 2134.2654.2 EE-2 324.1

Vorgang4711.3 3 Analysten

4 Designer4711.3 2 Programmierer

5422.2 Rechenzentrum

4711.1 1 AnalystSimulationsrechner

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 138

Ressourcenplanung (1)

Bisher: Nur Vorgänge mit Dauer und AbhängigkeitenNun: Auch Betrachtung von Ressourcen

Verschiedene Arten von RessourcenRepetierfaktoren: Produktionsfaktoren, die während des Prozessesverbraucht werden (z.B. Geld, Rohstoffe, Betriebsstoffe, Einzelteile)Potentialfaktoren: Faktoren, die im Fertigungsprozess nur genutzt,aber nicht verbraucht werden (zumindest kurzfristig; z.B. Arbeitskräfteund Maschinen)

Repetierfaktoren spielen bei Softwareprojekten i.A. eineuntergeordnete Rolle

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 139

Ressourcenplanung (2)

Bei der Personalplanung ist zu beachtenQualifikationVerfügbare PersonalkapazitätZeitliche VerfügbarkeitÖrtliche VerfügbarkeitOrganisatorische Verfügbarkeit(u.a. Teamzugehörigkeit, „never change a winning team“)

Ziel: optimaler Ressourceneinsatz über die gesamte ProjektlaufzeitVorgehen:

1. Ermitteln der verfügbaren Ressourcen2. Errechnen des Ressourcenbedarfs3. Vergleich Bedarf und Vorrat4. Optimieren der Auslastung

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 140

Schritt 1: Ermitteln der verfügbaren Ressourcen (1)

Brutto–Zeitvorrat: Nominell zur Verfügung stehende ArbeitszeitNetto–Zeitvorrat = Brutto–Zeitvorrat minus (Krankheit, Urlaub,Weiterbildung, etc. )

Gute Faustregel:1. Die Woche hat 4 Tage2. Der Tag hat 6 Stunden

Was macht ein MA am 5. Tag?Toner im Kopierer nachfüllenGeburtstag feiernSpesenabrechnung machenStrategiemeeting vorbereitenKonfliktdiskussion führen...

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 141

Schritt 1: Ermitteln der verfügbaren Ressourcen (2)

Ergebnis: Ist-Kapazitätsplan (mögliche Maximalauslastung)

Schulung

Urlaub

Verfügbare Personalressourcen [PM]

Zeit [Monate]

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 142

Schritt 2: Errechnen des Ressourcenbedarfs (1)

Kombiniere Zeitplanung und Aufwandsplanung ausArbeitspaketbeschreibung

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

Projekt:Projektnummer:Hauptaufgabe/Teilprojekt: Nr:Teilaufgabe: Nr:Arbeitspaket: Nr:

Aufgaben/LeistungsumfangVorgangsnummer Beschreibung (in Stichworten) Dauer (T) Aufwand (PT)1)2)3)4)5)

Grundlagen/Vorschriften:

Voraussetzungen/Randbedingungen:

Schnittstellen/Kommunikation:

Ergebnisse/Leistungsziele:

Durchführende Stelle, Verantwortlicher:

Stand:

Projekt:Projektnummer:Hauptaufgabe/Teilprojekt: Nr:Teilaufgabe: Nr:Arbeitspaket: Nr:

Aufgaben/LeistungsumfangVorgangsnummer Beschreibung (in Stichworten) Dauer (T) Aufwand (PT)1)2)3)4)5)

Grundlagen/Vorschriften:

Voraussetzungen/Randbedingungen:

Schnittstellen/Kommunikation:

Ergebnisse/Leistungsziele:

Durchführende Stelle, Verantwortlicher:

Stand:

ArbeitpaketbeschreibungenZeitplanung

V1

Zeit [PM]V4

0 1 2 3 4 5 6 7 8

V2

V3

Aktivität Bedarf [PM] Bedarf/ZeitV1 9PM 3PM/MonatV2 4PM 1PM/MonatV3 6PM 3PM/MonatV4 3PM 1,5PM/Monat

Bedarfsplanung

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 143

Schritt 2: Errechnen des Ressourcenbedarfs (2)

Aktivität Bedarf [PM] Bedarf/ZeitV1 9PM 3PM/MonatV2 4PM 1PM/MonatV3 6PM 3PM/MonatV4 3PM 1,5PM/Monat

Zeit [PM]

0 1 2 3 4 5 6 7 8

Bedarf je Aktivität über die Zeit

Anzahl MA

V1

V2

V3V4

Zeit [PM]

0 1 2 3 4 5 6 7 8

V1

V2

V2

V3

V3

V4

Aggregierte Bedarfe über die Zeit

Anzahl MA

Bedarfsplanung

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 144

Schritt 3: Vergleich Bedarf und Vorrat

Vergleich Ist- und Soll-Kapazitätsbedarf

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

Zeit [PM]

0 1 2 3 4 5 6 7 8

V1

V2

V2

V3

V3

V4

Anzahl MA

Ist-Kapazitäten

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 145

Schritt 4: Optimieren der Auslastung (1)

Ziel: Durch Ändern der Planung Schaffen von Übereinstimmung vonIst- und Soll-Kapazitätsbedarf

Fall 1: Interne Optimierung möglichBeispiel: Ausnutzen von Puffern im Zeitplan

V1

V4

0 1 2 3 4 5 6 7 8

V2

V3

Zeit [PM]

0 1 2 3 4 5 6 7 8

V1

V2

V2

V3

V4

Anzahl MA

Ist-Kapazitäten

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 146

Schritt 4: Optimieren der Auslastung (2)

Fall 2: Interne Optimierung nicht möglichZwei Vorgehensweisen:

Termintreue Einsatzplanung, d.h. Termine vom AG liegen fest und eswird ermittelt, welche Ressourcen in welcher zeitlichen Belegungbenötigt werden (ggf. Aufstocken der Ressourcen)Kapazitätstreue Einsatzplanung, d.h. Ressourcen stehen fest und esmuss der früheste Fertigstellungstermin ermittelt werden(ggf. Terminverschiebung)

Es lässt sich nicht immer Optimieren!Beispiel: Ich würde, um den Termin halten zu können, 5 Analytikerbrauchen, habe aber nur 4!

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 147

Exkurs: Kommunikation und Produktivität (1)

Rein rechnerisch kann Arbeitsvolumen auf mehrere MA aufgeteiltwerden.Beispiel: 15 PM

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

0 1 2 3 4 5 6 7 8 Dauer [Tage]

Bedarf Mitarbeiter [Anzahl]

1

2

3

4

5

6

nct 1

D.h. im allgemeinen Fall

mit Zeitbedarf t undn eingesetzten Mitarbeiter(ohne Kommunikation)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 148

Exkurs: Kommunikation und Produktivität (2)

Aber: Berücksichtigt man den Aufwand für die Kommunikation mitKommunikationsfaktor k, so ergibt sich

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

n = 5 10 Kommunikationspfade n = 10 45 Kommunikationspfade

knnn

nk

nt

2)1(1

21

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 149

Exkurs: Kommunikation und Produktivität (3)

Anzahl Mitarbeiter n

Zeit t

Zeitbedarf fürproduktive Arbeit

Zeitbedarf fürKommunikation

Gesamtaufwand

minimaleDauer

optimaleMitarbeiteranzahl

mehr Abstimmungsaufwandweniger Arbeitsteilung

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 150

Exkurs: Kommunikation und Produktivität (4)

Hier noch nicht berücksichtigt: EinarbeitungszeitBrooks’sches Gesetz:

„Adding manpower to a late software project makes it later“

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 151

Weiteres zur Ressourcenplanung (1)

QualifikationBisher: Eine Ressource = PersonalSpielt Qualifikation eine Rolle: Betrachte mehrere Ressourcen(Systemanalytiker, Programmierer, Handbuchautoren, etc. )

KalenderBisher: Reine Betrachtung von DauernNormalerweise: Abbildung auf Kalender(d.h. Wochenenden, Feiertage, Betriebsferien, etc.)Erhöhter Planungsaufwand

Projektübergreifende Planung und OptimierungOft mehr als ein Projekt gleichzeitigFolglich: Projektübergreifende Planung (Multiprojektmanagement)

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 152

Weiteres zur Ressourcenplanung (2)

Kosten durch NetzplantechnikNetzplansoftwareDatenbeschaffungPlanung und AktualisierungPlanungskosten liegen i.d.R. zwischen 0,1% und 2%, im Extrem bei 4%

Nutzen durch NetzplantechnikNur grobe Schätzungen

Zeitersparnis 25%Kostenersparnis 15%

Kap. 2 (Projektplanung) 2.6 (Ressourcenplanung)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 153

Projektmanagement-Werkzeug MS Project (1)

Neues Projekt anlegenFile - New: Eingabe von Start- oder EndterminFile - Properties: Eingabe von Titel, ProjektleiterTool - Change working Time: Definition eines projektspezifischenKalenders (Arbeitszeit, Feiertage)

Arbeitspakete, Vorgänge und MeilensteineGANTT-Ansicht: Vorgänge eingeben, mit Shift-Alt-Links und Shift-Alt-Rechts höher- oder niedrigerstufenMeilensteine sind Vorgänge mit 0 Tagen LaufzeitProject - Task Information: Festlegen von Vorgängern und Nachfolgern,Zugeordneten Ressourcen, Kommentaren

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 154

Projektmanagement-Werkzeug MS Project (2)

Ressourcen definierenRessource-Sheet: Eingabe von Ressourcen und KostenGANTT-Ansicht: Zuordnen von RessourcenVorsicht: Erstzuordnung bestimmt Aufwand (z.B. 2 Personen auf 5 TageVorgang bedeuten 10 PT Aufwand); Nachträgliche Änderung orientiertsich an diesem Aufwand

BerichteView - Reports: Ermöglicht Ausgabe nach verschiedensten Aspekten

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 155

MS Project - Beispielsitzung

VorgängeVorgang Dauer Vorgänger[1] Projektstart Meilenstein (18.5.) -[2] Spezifikation 10T 1[3] Entwurf 8T 2 EA-3T[4] Spezifikationsreview 5T 2 EA-0T[5] Entwurfsreview 5T 3 EA[6] Codierung 8T 3 EA-2T[7] Testfallerstellung 5T 4 EA[8] Test und Korrektur 8T 6 EA[9] Handbucherstellung 7T 2 EA[10] Abnahmetest 2T 7; 9[11] Projektende Meilenstein 1;2;3;4;5;6;7;8;9;10

Ressourcen Anna und Tom

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 156

Beispielprojekt „LH-Checker“Motivation:

Lastenhefte sind umfangreiche DokumenteBasieren auf einer ca. 150-Seitigen Vorlage

Löschen von Anforderungen, Hinzufügen von AnforderungenVorlage beinhaltet Muss- und Kann-Anforderungen

Manuelle Prüfung von Regeleinhaltungen ist aufwändig undfehleranfällig

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 157

Beispielprojekt „LH-Checker“

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

1 LH-Checker

1.1 Projektmanagement

1.1.1 Steuerung

1.1.2 Administration

1.1.3 Dokumentation

1.2 Plausibilisierung„weicher“ Metriken

1.2.1 Metrik-Auswahl

1.2.2 PrototypischeImplementierung

1.2.3 Anwendung undAuswertung

1.3 RealisierungLH-Checker

1.3.1 Erster Prototyp

1.3.1.1 Definitions-phase

1.3.2.1 Dokumentationvon Anforderungen

1.3.2 Produkt, Stufe 1

1.4 Konfigurations-management

1.2.4 Ergebnis-vorstellung

1.2.3.1 Auswahl vonBeispiel-LH

1.2.3.2 Anwendungauf Beispiel-LH

1.2.3.3 Auswertung

1.3.1.2 Realisierungs-phase

1.3.1.3 Evaluations-und Reifungsphase

1.3.2.2 Übergabean die IT

1.3.2.3 Abnahmetest

1.3.2.4 Support für IT

Projektstrukturplan(mit WBS-Numerierung nach MS Project)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 158

Beispielprojekt „LH-Checker“

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

Projekt: LH-CheckerProjektnummer: A123 567Hauptaufgabe/Teilprojekt: Realisierung Nr: 1.3Teilaufgabe: Erster Prototyp Nr: 1.3.1Arbeitspaket: Evaluations- und Reifungsphase Nr: 1.3.1.3

Aufgaben/LeistungsumfangVorgangsnummer Beschreibung (in Stichworten) Dauer (T) Aufwand (PT)1) Evaluation des Prototypen anhand zweier Lastenheft 10 T 5 PT2) Überarbeitung des Prototypen 5 T 5 PT3) Vorstellung des Prototypen bei LH-Check-Gruppe 1 T 1 PT4) Einsatz des Prototypen im Rahmen LH-Check 40 T 5 PT5) Lessons-Learned Sitzung 1 T 1 PT6) Dokumentation der Lessons Learned 10 T 4 PT

Grundlagen/Vorschriften: LH-Standardprozess bei TopCon Hard&Soft

Voraussetzungen/Randbedingungen: Realisierungsphase (1.3.1.2) abgeschlossen

Schnittstellen/Kommunikation: Wöchentl. Bericht wärend Prototypeinsatz

Ergebnisse/Leistungsziele: Erfolgter Einsatz des Prototypen; Gesicherte Ergebnisse

Durchführende Stelle, Verantwortlicher: Hr. Schulz (1-3, 5-6), Fr. Maile (4)

Stand: 26.10.2009

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 159

Beispielprojekt „LH-Checker“

Kap. 2 (Projektplanung) 2.7 (Werkzeugunterstützung MS Project)

MS Project Plan

MS Project File

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 160

Der Projektmanagement-Plan

Ergebnis der Planung wird im Projektmanagement-Plan festgehaltenZentrales Dokument der EntwicklungWichtig: Fortschreiben!

Zentrale ElementeProjektüberblick (Zielsetzung, Ergebnisse)Projektorganisation (Rollen, Einbettung in Kontext, Verantwortlichkeiten)Vorgehen bei Entwicklung („Wer macht wann was wie?“)

VorgehensmodellZeitplan, Ressourcen, Arbeitspakete, MeilensteineStandards, Werkzeuge, DokumentationSteuerung und Kontrolle (z.B. auch Risikomanagement)Schnittstellen nach Außen (z.B. Auftraggeber, Geschäftsleitung)

Kap. 2 (Projektplanung) 2.8 (Der Projektmanagement-Plan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 161

Projektmanagementplan Template (1)

TitelseiteÄnderungsstandVorwortInhaltsverzeichnisAbbildungsverzeichnisTabellenverzeichnis1. Einleitung

1.1 Projektüberblick1.2 Projektergebnisse (Deliverables)1.3 Entwicklung des Projektplans1.4 Referenzmaterialien1.5 Definitionen und Abkürzungen

2. Projektorganisation2.1 Prozessmodell2.2 Organisationsstruktur2.3 Org.-grenzen und Schnittstellen2.4 Verantwortlichkeiten

3. Steuerungsprozess3.1 Management Ziele, Prioritäten

3.2 Annahmen, Abhängigkeiten3.3 Risiko Management3.4 Beobachtungs- und

Steuerungsmechanisem3.5 Personalaustattungsplan

4. Technischer Prozess4.1 Methoden, Tools, Techniken4.2 Software Dokumentation4.3 Projektunterstützungsfunktionen

5. Arbeitspakete, Zeitplan, Budget5.1 Arbeitspakete5.2 Abhängigkeiten5.3 Budget- Ressourcenzuordnung5.4 Zeitplan

Weitere KomponentenIndexAnhänge

Nach P. Rook, 1991

Kap. 2 (Projektplanung) 2.8 (Der Projektmanagement-Plan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 162

Projektmanagementplan Template (2)

TitelseiteÄnderungsstandVorwortInhaltsverzeichnis1. Einleitung

1.1 Zweck des Projektplans1.2 Projektüberblick und Motivation1.3 Entwicklungsstrategie

2. Grundlagen2.1 Vertragliche Anforderungen2.2 Standards, Randbedingungen2.3 Annahmen

3. Beschreibung des Projekts3.1 Lieferumfang3.2 Resultate, die nicht zum

Lieferumgang gehören3.3 Meilensteine3.4 Abnahmeprozedur

4. Entwicklungsplan4.1 Projektstrukturplan4.2 Netzplan (Tätigkeiten/Termine)

4.3 Budget4.4 Kritische Punkte/Risiken

5. Anforderungen an die Umgebung5.1 Rechensystem, Software5.2 Leistungen des Auftraggebers5.3 Leistungen externer Lieferanten

6. Entwicklungsprozess6.1 Phasen der Entwicklung6.2 Dokumentation6.3 Prüfstrategie (Review, Test)

7. Projektorganisation7.1 Schnittstellen zum Auftraggeber7.2 Schnittstelle zur Firmenorganisation7.3 Schlüsselpersonen7.4 Organisation während Phasen

8. Standards für die Entwicklung8.1 Konfigurationsverwaltung8.2 Programmierrichtlinien8.3 Einsatz von Werkzeugen8.4 Projektspezifische Abweichungen

von FirmenstandardsNach Ludewig et. al 2000

Kap. 2 (Projektplanung) 2.8 (Der Projektmanagement-Plan)

© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 163

Der Projektstart

In der Regel Zeitspanne, kein fester Zeitpunkt

Projektstart ist entscheidender und stark prägender Aspekt derweiteren ProjektabwicklungWichtig: Gemeinsames Verständnis aller Projektbeteiligten

Kap. 2 (Projektplanung) 2.8 (Der Projektmanagement-Plan)

Projektinitialisierung

Projektziel

Definition (Planung) des Projekts

Projektauftrag

Entscheidung des Auftraggeberszur Durchführung einer Entwicklung

(Antragsfreigabe)

Inkraftsetzen desProjektplans

Projektabwicklung, d.h.Abarbeitung derArbeitspakete

Zeit


Recommended