Date post: | 05-Jun-2018 |
Category: |
Documents |
Upload: | nguyenmien |
View: | 213 times |
Download: | 0 times |
© 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