Kapitel 14 Projektmanagement - Software engineering · Software Project Management Plan (SPMP)...

Vorlesung SoftwaretechnologieDr. Günter KnieselJulia Kuck, Malte Appeltauer, Mark Schmatz

R O O T SSommersemester 2007

Kapitel 14Projektmanagement

Vorlesung Softwaretechnologie, Sommersemester 2007 14-2 R O O T S

Übersicht

Konzepte und TerminologieZielsetzung von ProjektmanagementplänenStruktur eines ProjektmanagementplansProjektverantwortlichkeitenTeamstrukturenProjektplanungKommunikationsmanagementAbhängigkeitenZeitplanProjektmanagementwerkzeuge


Projektmanagement: Erfahrungswerte / Faustregeln

Projekte kommen schnell voran bis sie zu 90% fertig sind. Danachbleiben sie für immer bei 90% stehen.Wenn alles gut läuft, wird etwas schiefgehen.Wenn es aussieht, als ob es langsam besser wird, wurde etwas übersehen.Wenn es nicht mehr schlimmer kommen kann, kommt es schlimmer.Wenn sich Projektinhalte frei ändern dürfen, wird die Änderungsrate die Fortschrittsrate übersteigen.Projektteams mögen keine Fortschrittsberichte, weil sich ihnen der Mangel an Fortschritt manifestiert.


Software Project Management Plan (SPMP)

SoftwareprojektAlle technischen und organisatorischen Aktivitäten, die notwendig sind, um die Endergebnisse an den Kunden auszuliefernEin Softwareprojekt hat eine spezifische Dauer, beansprucht Ressourcen und produziert Arbeitsergebnisse (engl. work products).Managementkategorien zur Fertigstellung eines Projekts:

Tasks, Aktivitäten, Funktionen

Software Project Management PlanDas Leitdokument eines SoftwareprojektsSpezifiziert die technischen und organisatorischen Ansätze für die Entwicklung des SoftwareproduktsBegleitdokument zum Anforderungsanalysedokument: Änderungen in einem der beiden erfordern evtl. Änderungen im jeweils andern.SPMP kann Teil der Projektvereinbarung sein.


Projektvereinbarung

Für den Kunden geschriebenes Dokument, das die folgenden Dinge festlegt:

Umfang, Dauer, Kosten und Endergebnisse des Projekts.Exakte Angaben über Artikel, Mengen, Auslieferungstermine und Auslieferungsort

Kann ein Vertrag, ein Statement of Work (SOW), ein Geschäftsplan oder eine Projektcharta sein.Kunde: Einzelne Person oder Organisation, der/die die Anforderungen spezifiziert und Endergebnisse erwartet.Endergebnisse (engl. Deliverables, Arbeitsergebnisse die an den Kunden ausgeliefert werden):

DokumenteDemonstration der FunktionalitätDemonstration der nicht-funktionalen AnforderungenDemonstrationen der Subsysteme


Projektvereinbarung vs. Problemstellung

Kunde (Sponsor) Manager Projektteam

Problemstellung

Software ProjectManagement PlanProjekt-

vereinbarung


Aktivitäten des Projektmanagements(fortgesetzt auf nächster Folie)

Initiierung

Start des Projekts

Teambildung Aufbau der Kommuni-kationsinfrastruktur

Definition der Problemstellung

Planung von Meilensteinen

Top-Level-Entwurf


Normalbetrieb

Terminierung

Installation Akzeptanztest durch Kunde Nachbereitung

ProjektvereinbarungProjektneuplanung

Zustandsüberwachung Risikomanagement

Start des Projekts

Vorlesung SoftwaretechnologieKapitel 14Projektmanagement


Projekt = Funktionen, Aktivitäten, Tasks, Action Items


Projekt: Funktionen, Aktivitäten und Tasks

p:Projectf1:Function

f2:Function

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task


FunktionenAktivitäten die die Dauer des gesamten Projekts umfassen.


f2:Function

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task


Funktionen

BeispieleProjektmanagementKonfigurationsmanagementDokumentationQualitätskontrolle (Verifikation und Validierung)Training

Abbildung von TerminologieProjektfunktionen (Project functions) im IEEE 1058 Standard… werden in IEEE 1074 als „Integrale Prozesse“ (integral processes) bezeichnet.


Aktivitäten

Größere Arbeits-einheiten mit präzisen Zeitangaben.Bestehen aus kleineren Aktivitäten oder TasksGipfeln in Projekt-Meilensteinen

a1:Activity


f2:Function

a2:Activity

a2.1:Activity a2.2:Activity

t1:Task t2:Task t3:Task


Beispiele für Aktivitäten

AktivitätenPlanungAnforderungserhebungAnforderungsanalyseSystementwurfObjektentwurfImplementierungTestenAuslieferung

Teil-Aktivitäten während der Anforderungsanalyse

Verfeinern von SzenariosUse-Case-Modell definieren Objektmodell definierenDynamisches Modell definierenBenutzerschnittstelle entwerfen


Tasks

Kleinste Einheit von Arbeit, die noch Gegenstand des Managements istKlein genug für adäquate Planung und VerfolgungGroß genug, um Mikromanagement zu vermeiden


f2:Function

a1:Activity a2:Activity

a2.1:Activity a2.2:Activity

t1:Task t2:Task t3:Task


Tasks

Kleinste Einheit für Verantwortlichkeit des ManagementsAtomare Einheit für Planung und VerfolgungEndliche Dauer, benötigt Ressourcen, produziert handfeste Ergebnisse (Dokumente, Code)

Spezifikation einer Task: AufgabeName, Beschreibung der zu leistenden Arbeit Vorbedingungen, Dauer, benötigte RessourcenErwartete ArbeitsergebnisseMit der Task verbundenes Risiko

ErfüllungskriterienBeinhaltet die Akzeptanzkriterien für die Arbeitsergebnisse


Größe von Tasks

Die angemessene Größe von Tasks zu finden, ist problematisch.

TODO-Listen früherer ProjekteWährend der anfänglichen Planung sind Tasksnotwendigerweise groß.Es ist evtl. anfänglich nicht bekannt, wie ein Problem in Tasks zu zerlegen ist.

Tasks müssen in Größen aufgebrochen werden, die ein Monitoring zulassen.

Arbeitspakete entsprechen i.d.R. wohl-definierten Arbeitsanweisungen für einen Arbeiter und eine Woche (einen Monat) Zeit.Abhängig von der Art der Arbeit und davon, wie gut die Aufgabe verstanden wird.

Jede Entwicklungsaktivität identifiziert neue und modifiziert existierende Tasks.


Beispiele für Tasks

Unit test für Klasse „Foo“Teste das Subsystem “Bla”Schreibe das BenutzerhandbuchSchreibe ein Protokoll zur letzten Sitzung und verteile es.Schreibe ein Memo über „Linux vs. Windows XP“Lege den Zeitplan für die Code Review fest.Entwickle den ProjektplanZusammenhängende Tasks werden zu hierarchischen Mengen von Funktionen gruppiert.Action Item


Action Item

Definition: Ein Task, der einer Person zugeordnet wird, und der innerhalb einer Woche oder weniger erledigt sein muß.Action Items

Tauchen auf der Agenda im „Status“-Abschnitt auf (siehe Vorlesung über Kommunikation)Klären: Was?, Wer?, Wann?

Beispiel für Action Items:Florian erledigt Unit Tests für Klasse “Foo” bis nächste Woche.Bob verschickt die nächste Agenda für das Simulationsteam bis 10. Sep. 12:00Das VIP Team entwickelt einen project Plan bis 18. Sep.



Software Project Management Plan


Struktur eines Software Project Management Plans

Einstieg1. Einführung2. Projektorganisation3. Organisatorischer Prozess4. Technischer Prozess5. Arbeitselemente, Zeitplan, BudgetOptionale Anlagen


SPMP Teil 0: Einstieg

TitelblattRevision sheet (update history)Vorwort: Umfang und ZielInhalts- sowie Tabellen- und Abbildungsverzeichnisse


SPMP Teil 1: Einführung

1.1 ProjektübersichtBeschreibung des Projekts, Projektzusammenfassung.

1.2 Endergebnisse des ProjektsAlle auszuliefernden Artikel, incl. Datum und Ort der Auslieferung

1.3 Evolution des SPMPsPläne bzgl. erwarteter und unerwarteter Änderungen

1.4 Referenziertes MaterialVollständige Liste aller Materialien, die vom SPMP referenziert werden

1.5 Definitionen und Akronyme


SPMP Teil 2: Projektorganisation

2.1 ProzessmodellBeziehungen zwischen Projektelementen

2.2 Organisatorische StrukturInterne Verwaltung, Organisationsdiagramm

2.3 Organisatorische SchnittstellenBeziehungen zu anderen Entitäten (außerhalb des Projekts)

2.4 VerantwortlichkeitenDie wichtigsten Funktionen und Aktivitäten

welcher Art sind sie?wer ist Verantwortlich?


2.1 Prozessmodell

Zeigt Beziehungen zwischenFunktionen, Aktivitäten, TasksMeilensteinenBaselinesReviewsProjektstrukturplanEndergebnisse

Visualisierung des ProzessmodellsWerkzeuge

MS Project (Microsoft)MAC Project (Claris)EasyTrak (Planning ControlInternational)

Vorlesung SoftwaretechnologieDr. Günter KnieselJulia Kuck, Malte Appeltauer, Mark Schmatz


Software Project Managemet Plan:

2.2 Organisatiorische Struktur


Beispiel eines Organisationsdiagramms

Client Management Consultants

Cross functional Teams

Logbook

Maintenance

Vehicle

Travel

Infrastructure Team

Architecture

HCI

Web Master

Documentation

Configuration Mgt

Development Teams


Assoziationen in Organisationsstrukturen

Berichterstattungsassoziationendienen der Übermitteln von Statusinformationen

Entscheidungsassoziationenwerden zum Propagieren von Entscheidungen verwendet

Kommunikationsassoziationendienen dem Austausch von Informationen, die zur Entscheidungsfällungnötig sind (z.B. Anforderungen, Entwurfsmodelle, Issues...)


Betrachtungen zu Verwaltungsstrukturen

Hierarchische Strukturen“erstattet Bericht”, “entscheidet” und “kommuniziert mit” werden alle auf die selbe Assoziation abgebildet.Funktionieren nicht gut zusammen mit iterativer und inkrementeller Softwareentwicklung.Der Manager hat nicht notwendigerweise immer Recht

Projektbasierte Strukturen“erstattet Bericht”, “entscheidet” und “kommuniziert mit” sind unterschiedliche Assoziationen.Abbau von Bürokratie reduziert Entwicklungszeit.Es wird erwartet, dass auf jeder der Ebenen Entscheidungen getroffen werden.Schwierig zu verwalten.


BA

Hierarchische Kommunikationsstruktur

Leitender Angestellter

First Level Manager(“Front-Line Manager”)

Projektteilnehmer

Organisationsgrundlage:Komplizierter Informations- und Kontrollfluss über

hierarchische Grenzen hinweg.

Organisationsgrundlage:Komplizierter Informations- und Kontrollfluss über

hierarchische Grenzen hinweg.

Komplizierter Informationsfluss: A möchte mit B reden.Komplizierter Kontrollfluss: A möchte, dass B etwas bestimmtes macht.

Informationsfluss

Kontrollfluss


Hierarchische Struktur

Projekte mit einem hohen Grad an Sicherheit, Stabilität, Einheitlichkeit und Wiederholung

Benötigt wenig KommunikationRollen sind klar definiert.

Wann?Je mehr Leute im Projekt mitarbeiten, desto größer ist die Notwendigkeit einer formalen Struktur.Evtl. besteht der Kund darauf, dass das Testteam unabhängig vom Entwurfsteam ist.Projektleiter besteht auf einer Struktur, die sich zuvor als erfolgreich erwiesen hat.


Projekt-basierte Kommunikationsstruktur

Organisationsgrundlage:Nicht-linearer Informationsfluss zwischen dynamisch formierten

Einheiten.

Organisationsgrundlage:Nicht-linearer Informationsfluss zwischen dynamisch formierten

Einheiten.

A will mit B reden: KommunikationsflussA möchte das B eine bestimmte Sache tut: Entscheidungsfluss

Projektleiter

Coaches

Projekt-teilnehmer

Subsystem Team Subsystem Team Subsystem Team

A B


Projekt-basierte Struktur

Projekt mit einem Grad an UnsicherheitOffene Kommunikation unter den Teilnehmern ist erforderlich.Rollen werden auf Projektbasis definiert.

Wann?Anforderungen ändern sich während der Entwicklung.Neue Technologie entwickelt sich während des Projekts.


Beispiel einer hierarchischen Organisation:„Chief Programmer“ (Mills)

Chief Programmer

Librarian Administrator Tester

Junior Programmer

AssistantChief Programmer

Senior Programmer …


Beispiel einer hierarchischen Organisation:„Chief Programmer“ (Mills)

Der Chief Programmer ist der Hauptverantwortliche für den Entwurf und die Implementierung. implementiert selbst kritische Funktionalität, weist den anderen Entwicklern Aufgaben zu und kontrolliert den Arbeitsfortschritt.

VorteileSchnelle Enticklung durch wenig Kommunikation, wenige Teammeetings, kurze Entscheidungswege

NachteileChief Programmer ist Engpass der Entwicklung, muss Manager und Hacker sein, demotiviert das Team

Erfnder: Harlan D. MillsErstmals in den 70er Jahren bei IBM eingesetzt.

Onlinematerial: http://everything2.com/index.pl?node_id=1292141


Eine andere Organisationsform: Egoless Programming Team (Weinberg)

Analytiker

Designer Bibliothekar

Tester Programmierer


Eine andere Organisationsform: „Egoless Programming Team” (Weinberg)

Programmierer identifizieren sich oft zu stark mit "ihrem" CodeAkzeptieren keine Änderungen, testen nicht gründlich genug,…

Egoless programming“Collective code ownership”Motiviere Teammitglieder Fehler in allen Modulen zu suchenFehler werden als normal betrachtetStarke GruppenidentitätKleine Gruppen ( <= 10 )

Vorteile von Egoless TeamsSehr produktivArbeiten am besten bei komplexen ProblemHaben sich im Forschungsumfeld als erfolgreich herausgestellt

Problemschwer planbar

Vergleiche: eXtreme Programming


Teambildung

Top-Level-Entwurf“Grobe” Subsystemzerlegung (vor der Anforderungsanalyse)Geschieht vor der eigentlichen Entwicklung

Teambildung findet nach dem Top-Level-Entwurf statt.Heuristiken:

Ein Team für jedes SubsystemEine Funktionsübergreifende Aufgabe pro Team5-7 Mitglieder pro Team

Teams müssen üblicherweise angepasst werden, sobald die tatsächliche Subsystemdekomposition fest steht (nach dem Systementwurf)


Zuweisung von Verantwortung

Team

Person A

Person B

Rolle 1

Item 1Item 2Item 9

Item 1Item 2Item 9

Rolle 3

Item 3Item 6Item 8

Item 3Item 6Item 8

Rolle 2

Item 4Item 5Item 7

Item 4Item 5Item 7

Rolle 3Rolle 3

Rolle 1

Rolle 2

Rolle 1

Rolle 2

„ToDo“-Liste für das Projekt

• Item 1• Item 2• Item 3• Item 4• Item 5• Item 6• Item 7• Item 8• Item 9

• Item 1• Item 2• Item 3• Item 4• Item 5• Item 6• Item 7• Item 8• Item 9


Mögliche Abbildungen von ToDos auf Personen

Viele-zu-WenigeJeder Projektteilnehmer nimmt mehrere Rollen an („Hüte“).Gefahr des „Über-Engagements“„load balancing“ ist notwendig.

Viele-zu-“Zu Viele“Einige Teilnehmer spielen keine signifikante Rolle„Zuschauer“Verlieren den Anschluss an das Projekt



SNMP 2.4: Verantwortlichkeiten / Rollen


Rollen in einem Projekt

PlanerAnalytikerDesignerProgrammiererTester WartungspersonalAusbilderDokument EditorWeb MasterKonfigurationsmanager

GruppenleiterLiaison (Verbindungsmann)Projektleiter


Rollen in einem Projekt

Rollen im ManagementOrganisation und Durchführung des Projekts unter Berücksichtigung von Rahmenbedingungen. Beispiele: Projektleiter, Teamleiter.

Rollen in der EntwicklungSpezifikation, Entwurf und Konstruktion der Subsysteme. Beispiele: Analytiker, Systemarchitekt, Programmierer.

Funktionsübergreifende RollenKoordination mehrerer Teams. Beispiele: API Ingenieur, Konfigurationsmanager, Tester

Beratende RollenUnterstützung in Gebieten, in denen es den Projektteilnehmern an Erfahrung mangelt. Beispiele: Anwender, Kunde, ein Spezialist auf dem Anwendungsgebiet (Problemdomäne), Technischer Berater (Lösungsdomäne)


Wissenspromoter

Auch als Technologe bezeichnetPropagiert Änderungen, die in der Anwendungs- oder Lösungsdomäne auftretenAufgaben: Schrittweise Informationen aneignen; Nutzen und grenzen neuer Technologie erkennen und mit den anderen Entwicklern über den Einsatz dieser Technologie diskutierenBeispiel auf Projektebene: Systemarchitekt

Berichtet dem ProjektleiterHat keine direkten Untergebenen, der ihm Bericht erstattetHat das letzte Wort in jeder technischen Entscheidung

Beispiel auf Unternehmensebene: Technischer Direktor


Prozesspromoter

Der Prozesspromoter ist mit den Prozessen und dem Prozedere des Projekts vertraut.Der Prozesspromoter ist verantwortlich einen Konsens über die langfristigen Ziele zu erreichen.Aufgaben

Verbindung zwischen Power- und Wissenspromoter, die oft nicht die selbe Sprache sprechen

Beispiel auf ProjektebeneEntwicklungsleitung. Verantwortlich für die administrativen Aspekte eines Projekts; beinhaltet Planung, Definition von Meilensteinen, Budgetplanung und Kommunikationsinfrastruktur

Beispiel auf UnternehmensebeneLeiter der Technologieabteilung


Rollen im Projekt: Coach

auf Probleme einzelner Teams eingehenDie wöchentliche Teamreports durchsehenDen wöchentlichen Projektmeetings beiwohnenTreffen mit dem Kunden arrangieren.Darauf bestehen, dass die Richtlinien befolgt werdenPräsentationen zuweisen Konflikte lösen, wenn sie nicht teamintern gelöst werden können


Rollen im Projekt: Gruppenleiter

Verantwortlich für die Kommunikation innerhalb des Teams (Meeting Management: Primärer Moderator)

Führt das wöchentliche ProjektmeetingSchickt die Agenda vor dem Treffen an alle BeteiligtenDefiniert und verfolgt Action Items (wer, was, wann)Misst Fortschritt (Setzt Meilensteine durch)Abgeschlossene Arbeitspakete an das Projektmanagement ausliefernTrägt Probleme und Status des Teams dem Projektleiter vor

Die Rolle des Gruppenleiters muss unter den Teammitgliedern durchrotiert werden.


Gruppenleiter: Erstellen einer Tagesordnung

Zweck des TreffensAngestrebtes ErgebnisInformationsaustauschInformationsverarbeitungMeetingkritik

Status-Bericht über Action Itemsdes vorigen

Treffens

Issues(Siehe voriges

Treffen & Boards)


Rollen im Projekt: Liaison

Verantwortlich für die Kommunikation zwischen den TeamsMacht öffentliche Schnittstellen von Subsystemen, die vom Team entwickelt werden für das Architekturteam verfügbarKoordiniert teamübergreifende Aufgaben mit anderen Teams

Verantwortlich für „Verhandlungen“ zwischen den TeamsBeispiele: API Ingenieur, Konfigurationsmanager


Rollen im Projekt: Planer

Plant und verfolgt Aktivitäten eines Teans und hat die folgenden Aufgaben:Definiert den Projektplan für das Team

PERT Diagramm, Ressourcetabelle und GANTT Diagramm, das die Arbeitspakete zeigt.Gibt den Projektplan in das jeweilige Projektmanagementwerkzeug ein.

Stellt den Projektplan dem Management zur VerfügungErstattet dem Projektleiter bericht über den Teamstatus


Rollen im Projekt: Document Editor

Sammeln, Korrekturlesen und verteilen von DokumentationLegt Dokumentation des Teams dem Architekturteam vorSammelt TagesordnungenFührt Protokoll bei Teammeetings


Pflegt die Homepage des Teams inklusive…… Liste stattgefundener Meetings… Rationale zum Entwurf

Veröffentlich Informationen über die Teammeetings auf der Homepage des Teams

Muss Tagesordnung, Protokoll, Action Items und Issues enthaltenMöglichkeiten:

Ein HTML Dokument per Meeting, mit Verlinkung. (Pflegen eine Rolle)Separate HTML Dokumente für Tagesordnung, Protokoll, etc. (Pflegen mehrere Rollen)

Web Master:

Agenda Minutes Action Items Issues9/9/96

Date Agenda Minutes Action Items Issues

Agenda Minutes Action Items Issues9/16/96



SPMP Teil 3: Organisatorischer Prozess


SPMP Teil 3: Organisatorischer Prozess

3.1 Verwaltungsziele und -prioritätenPhilosophie, Ziele, Prioritäten

3.2 Annahmen, Abhängigkeiten, RahmenbedingungenExterne Faktoren

3.3 RisikomanagementIdentifizierung, Abschätzung, Verfolgung von Risiken, Contingency

3.4 Überwachungs- und KontrollmechanismenBerichterstattungsmechanismen und -formate, Informationsflüsse, Reviews

3.5 PersonalplanungBenötigte Fähigkeiten (Was?, Wieviel?, Wann?)


Beispiele für Annahmen

There are enough cycles on the development machinesSicherheit ist kein Thema.Es gibt keine Bugs in Together-J, dem CASE Tool, das für das Projekt empfohlen wurde.Der Kunde führt eine Demonstration des Starnetwork-Systems vor.


Beispiel für Abhängigkeiten

Das Datenbankteam hängt von der von DaimlerChrysler zur Verfügung gestellten EPC Datenbank ab.Die automatische Codeerzeugung des CASE-Tools hängt vom jeweiligen JDK ab. Die momentane Version von Together-J unterstützt nur JDK 1.1.6


Beispiele für Rahmenbedingungen

Die Dauer des Projekts ist 3 Monate. Beschränkte Zeit zum Aufbau des Systems.Das Projekt besteht aus Anfängern. Es wird Zeit brauchen, den Umgang mit den Tools zu lernen.Nicht jeder Projektteilnehmer ist immer auf den neusten Stand, was den Status des Projekts betrifft.UML und ein CASE-Took müssen verwendet werden.Neuer Code soll ausschließlich in Java geschrieben werden.Das System muss JDK-1.1.6 verwenden.


Risikomanagement

Risiko: Teilnehmer in Schlüsselpositionen fallen aus.

Contingency: Rollen werden jemand anderem Zugewiesen. Funktionalität des Systems wird mit dem Kunden neu ausgehandelt.

Risiko: Das Projekt fällt hinter den Zeitplan zurück.

Contingency: Extra Projektmeetings werden anberaumt.

Risiko: Ein Subsystrem bietet nicht die Funktionalität, die von einem anderen benötigt wird.

Contingency: ?

Risk: Ibutton läuft nur mit JDK 1.2

Contingency: ?



SPMP Teil 4: Technischer Prozess

SPMP Teil 5: Arbeitselemente, Zeitplan, Budget


SPMP Teil 4: Technischer Prozess

4.1 Methoden, Werkzeuge und TechnikenComputersystem, Entwicklungsmethode, Teamstruktur, etc. Standards, Richtlinien, Standards, Verfahren

4.2 SoftwaredokumentationDokumentationsplan, einschließlich Meilensteine, Reviews und Baselines

4.3 Hilfsfunktionen für das Projekt (‚Project Support Functions‘)Pläne für Funktionen (Qualitätssicherung, Konfigurationsmanagement)


SPMP Teil 5: Arbeitselemente, Zeitplan, Budget

5.1 Aufschlüsselung der Arbeitspakete (‚Work breakdown structure‘)Zerlegung des Projekts in Tasks; Definition der Tasks

5.2 AbhängigkeitenPräzedenzrelationen zwischen Funktionen, Aktivitäten und Tasks

5.3 Erforderliche RessourcenAbschätzung für Ressourcen, wie z.B. Personal, Rechenzeit, spezielle Hardware, zusätzliche Software,...

5.4 Budget- und RessourcenazuweisungKosten mit Funktionen, Aktivitäten und Tasks in Verbindung setzen

5.5 ZeitplanDeadlines, Aufzeigen von Abhängigkeiten, notwendige Meilensteine


Erstellen von Arbeitspaketen

Aufschlüsselung der Arbeitspakete (AP)Aufbrechen des Projekts in Aktivitäten (Phasen, Schritte) und TasksAbhängigkeiten zwischen den Tasks zeigt die WBS nicht.

Das identifizieren der Arbeitspakete ist eine Instanz von Objektidentifikation und der Assoziation dieser Objekte.


Source: Software Engineering Economics, Barry W. Boehmp. 47, Prentice Hall, N.J., 1981

Aufschlüsselung der Arbeitspakete: Abwägungen

Aufschlüsselung der Arbeitspakete beeinflusst Kosten und ZeitplanSchwellwerte für die Erstellung der AP in % der gesamten Arbeit:

Kleiners Projekt (7 Personen-Monate): mindestens 7% bzw. 0.5 PMMittleres Projekt(300 Personen-Monate): mindestens 1% bzw. 3 PMsGroßes Projekt (7000 Personen-Monate): mindestens 0.2 % bzw. 15 PMs

Festlegung der AP ist inkrementell und iterativ.

AP Zeitplan

Kosten(Zeit, ¥€$)


Abhängigkeiten und Zeitplanung (SPMP Abschnitt 5.2 + 5.5)

Eine wichtige zeitliche Relation: „Muss vor ... passieren“Abhängigkeitsgraph zeigt Abhängigkeiten unter den Tasks(hierarchisch und zeitlich)

AktivitätengraphProjektmeilensteine sind KnotenTasks sind Kanten

Zeitplanungsdiagramm (MS-Project):Tasks und Meilensteine sind KnotenKanten repräsentieren zeitliche Abhängigkeiten

Abschätzung der Dauer jedes TasksAbhängigkeitsgraph wird mit den Schätzungen beschriftet.


Projektverwaltungswerkzeuge für Arbeitspakete

Visualisierungshilfen für die ProjektpräsentationGraphen (Zeitplan), Bäume (WBS)Tabellen (Ressourcen)

Task ZeitleisteGantt Diagramme: Zeigen Projektaktivitäten und -tasks parallel. Ermöglichen dem Projektleiter nachzuvollziehen, welche Tasks gleichzeitig bearbeitet werden können.

Zeitplan (PERT Diagramm)Grundstein vieler ProjektverwaltungswerkzeugeGrafische Repräsentation von Abhängigkeiten zwischen Tasks und Milestones.

PERT: Program Evaluation and Review Technique– Ein PERT diagramm geht von einer Normalverteilung der Taskdauer aus.– Nützlich für Analyse kritischer Pfade (‚Critical Path Analysis‘)

CPM: Critical Path Method– Kritischer Pfad ist Folge von Aktivitäten deren Verzögerung den gesamten

Ablauf verzögern würde


Beispiel für ein Gantt-Chart

( Gantt-Charts sind benannt nach dem amerikanischen Ingenieur H. L. Gantt (1861-1919)


Projekt: Ein Haus bauen

Aktivität 1: LandschaftsgärtnereiTask 1.1: Roden und GrabenTask 1.2: Rasen sähenTask 1.3: Büsche und Bäume pflanzen

Aktivität 2: Das Haus bauenAktivität 2.1: Baustelle vorbereitenAktivität 2.2: RohbauAktivität 2.3: Innenausbau


Projekt: ein Haus bauen (Fortsetzung)

Aktivität 2.1 : Baustelle vorbereitenTask 2.1.1: Gutachten einholen Task 2.1.2: BaugenehmigungTask 2.1.3: AusschachtenTask 2.1.4: Materialbeschaffung

Aktivität 2.2: RohbauTask 2.2.1: FundamentTask 2.2.2: AußenwändeTask 2.2.3: Ext. KlempnerarbeitenTask 2.2.4: Ext. ElektrikerarbeitenTask 2.2.5: VerputzenTask 2.2.6: AußenanstrichTask 2.2.7: Tür- und FensterrahmenTask 2.2.8: Dacharbeiten

Aktivität 2.3 : InnenausbauTask 2.3.1: Int. KlempnerarbeitenTask 2.3.2: Int. Elektrikerarbeiten Task 2.3.3: EsstrichTask 2.3.4: InnenanstrichTask 2.3.5: Teppich/FliesenTask 2.3.6: Türen und Fenster


Aktivitätsgraph für die Aktivität “Ein Haus Bauen”

1.11.2

1.4

1.3

2.1

2.2

3.1

3.2

3.3

3.4

2.3

2.4

2.5

2.6

2.82.7

3.5

3.6

2.6

Äußere Klempnerarbeiten Innere Klempnerarbeiten

Außenwände

Fundament

Material-beschaffung

Aussachtung

GutachtenAußenwände bauen

START

Äußere Elektrikerarbeiten

Verputzen

Außenanstrich

Türen Dach

Innere Elektrik

Esstrich

Teppiche/Fliesen Innenanstrich

Türen

FINISH


PERT Diagramm für „Ein Haus Bauen"

Duration00

Start Time

Slack Time

MS Project PERTcyChart with Duration of Activities (Pfleeger 2.3)

Building a House:

8/27/94

00

8/27/94

015

8/27/94

123

9/17/94

8/29/94

10/1/94 10/15/94

015

11/5/94

020

12/3/94

1210

InstallInterior

Plumbing

InstallInterior

Plumbing

12/3/94

012

12/17/94

1210

12/21/94

015

12/31/94

128

1/11/95

09

1/12/95

125

Roofing

1/19/95

129

1/22/95

018

1/22/95

011

2/8/95

07

1/19/95

156

2/16/95

00

LegendLegend

RequestPermits

RequestPermits

010

Excavation

Excavation

010

BuyMaterial

BuyMaterial

LayFounda

tion

LayFounda

tion

BuildOutside

Wall

BuildOutside

Wall

InstallFlooringInstall

Flooring

InstallInteriorDoors

InstallInteriorDoors

PaintInteriorPaint

Interior

InstallInterior

Electrical

InstallInterior

ElectricalInstall

WallboardInstall

Wallboard

FINISHFINISHSTARTSTART InstallRoofing

Surveying

InstallExterior

Electrical

InstallExteriorSiding

Paint Exterior

InstallExterior

Plumbing

InstallExteriorDoors


Slack Time und Critical Path

Zeitlicher Spielraum (‚slack time‘)späteste mögliche Startzeit – früheste mögliche Startzeit

Kritischer Pfad Der Pfad in einem Projektplan, für den der Spielruam an jedem Knoten (Task/Aktivität) null ist.

Auf dem kritischen Pfad gibt es keinen Spielraum für Tasks/Aktivitäten.Jede Verzögerung einer Aktivität / Task auf dem kritischen Pfad verzögert das gesamte Projekt!


Wie werde ich ein guter Projektplaner?

Stell einen Projektplan auf.Fange basierend auf deinen Erfahrungen mit vergangenen Projekten an.

Behalte Aktivitäten und ihre Dauer im Auge.Bestimme die Differenz zwischen geplantem und tatsächlichen DurchsatzDenk daran, eine Post-Mortem-Analyse zu machen

„Was haben wir aus dem Projekt gelernt?“Bitte Entwickler um FeedbackHalte schriftlich fest, was verbessert werden könnte.


Heuristiken zum Projektmanagement

Halte dir die Möglichkeit offen, einen Projektplan zu ändern oder auch komplett zu verwerfen.

Die Entwicklung komplexer Systeme ist eine nicht-lineare Angelegenheit.Wenn die Ziele unklar und komplex sind, benutzer teambasiertes Projektmanagement. In diesem Fall...

Vermeide GANTT und PERT Diagramme für Projekte mit sich ändernden Anforderungen.Blicke nicht zu weit in die Zukunft.

Vermeide Mikromanagement von Details.Sei nicht überrascht, wenn aktuelle Projektverwaltungstools nicht funktionieren:

Sie wurden für Projekte mit klaren Zielen und festen Organisationsstrukturen entworfen.


Projektmanagement: Zusammenfassung

Übereinkünfte zwischen Kunden, Managern und TeamsProblemstellungSoftware Project Management PlanProjektvereinbarungStell sicher, dass die Übereinkünfte Nachbesserungen ermöglichen.

OrganisationsstrukturenSPMPProjektplanung

Aufschlüsselung der Arbeitspakete (Work breakdown structure)Abhängigkeiten und Strukturen identifizieren: Tasks, Aktivitäten, Funktionen

Werkzeuge und TechnikenGANTT, Abhängigkeitsgraph, Zeitplan, Critical Path AnalyseVorsicht mit Werkzeugen in Projekten mit viel Änderung

Kapitel 14 Projektmanagement - Software engineering · Software Project Management Plan (SPMP)...

Documents

Transcript of Kapitel 14 Projektmanagement - Software engineering · Software Project Management Plan (SPMP)...