Kapitel 12 Projektmanagement - Software engineering€¦ · Software Project Management Plan (SPMP)...

Vorlesung „Softwaretechnologie“Wintersemester 2009 R O O T Ste se este 009

Kapitel 12Kapitel 12Projektmanagement

Stand: 26.01.2010

Übersicht

Konzepte und TerminologieZi l t P j kt t lä Zielsetzung von Projektmanagementplänen

Struktur eines Projektmanagementplans Projektverantwortlichkeiten Projektverantwortlichkeiten Teamstrukturen Projektplanungj p g Kommunikationsmanagement Abhängigkeiten Zeitplan Projektmanagementwerkzeuge

© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 12-2 R O O T S

Projektmanagement: Erfahrungswerte / Faustregeln Erfahrungswerte / Faustregeln

Projekte kommen schnell voran bis sie zu 90% fertig sind. Danach bleiben sie für immer bei 90% stehenbleiben 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 etwasWenn 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 Projektteams mögen keine Fortschrittsberichte, weil sich ihnen der Mangel an Fortschritt manifestiert.


Software Project Management Plan (SPMP)(SPMP)

Softwareprojekt All t h i h d i t i h Akti ität di t di i d Alle technischen und organisatorischen Aktivitäten, die notwendig sind,

um die Endergebnisse an den Kunden auszuliefern Ein 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 Plan Das Leitdokument eines Softwareprojekts Das Leitdokument eines Softwareprojekts Spezifiziert die technischen und organisatorischen Ansätze für die

Entwicklung des SoftwareproduktsB l i d k A f d l d k Ä d i Begleitdokument 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: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.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): Dokumente Dokumente Demonstration der Funktionalität Demonstration der nicht-funktionalen Anforderungen


Demonstrationen der Subsysteme

Projektvereinbarung vs. Problemstellung

Kunde (Sponsor) Manager Projektteam( p ) g j

Problemstellung

Software ProjectManagement PlanProjekt- Management PlanProjekt

vereinbarung


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

I itiiInitiierung

Definition der Problemstellungg

Planung von Top-Level-Entwurf

T bild Aufbau der Kommuni

Meilensteinen

Teambildung Aufbau der Kommuni-kationsinfrastruktur

Start des Projekts


Normalbetrieb

Start des Projekts

Zustandsüberwachung Risikomanagement

ProjektvereinbarungProjektneuplanung

Terminierung

Installation Akzeptanztest durch NachbereitungInstallation pKunde Nachbereitung


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

Projekt: Funktionen, Aktivitäten und TasksFunktionen, Aktivitäten und Tasks

p:Projectf1:Function

f2 F tif2: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

Aktivitäten die die Dauer des gesamten Projekts umfassen.


f2 F tif2:Function

a1:Activity a2:Activity a3:Activity

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




Funktionen

Beispiele P j kt t Projektmanagement Konfigurationsmanagement Dokumentation Qualitätskontrolle (Verifikation und Validierung) Training

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

bezeichnetbezeichnet.


Aktivitäten


f2 F ti

Größere Arbeits-

f2:Function

Größere Arbeitseinheiten mit präzisen Zeitangaben.

B t h kl i

a1:Activity a2:Activity

Bestehen aus kleineren Aktivitäten oder Tasks

Gipfeln in Projekt-a2.1:Activity a2.2:Activity

p jMeilensteinen

t1:Task t2:Task t3:Task



Beispiele für Aktivitäten

Aktivitäten Teil-Aktivitäten während der Aktivitäten Planung Anforderungserhebung

e ä e ä e d deAnforderungsanalyse Verfeinern von Szenarios U C M d ll d fi i Anforderungsanalyse

Systementwurf Objektentwurf

Use-Case-Modell definieren Objektmodell definieren Dynamisches Modell definieren Objektentwurf

Implementierung Testen

y Benutzerschnittstelle entwerfen

Auslieferung


Tasks


f2 F ti

Kleinste Einheit von

f2:Function

Kleinste Einheit von Arbeit, die noch Gegenstand des Managements ist

a1:Activity a2:Activity

Managements ist Klein genug für

adäquate Planung a2.1:Activity a2.2:Activity q gund Verfolgung

Groß genug, um Mikromanagementt1:Task t2:Task t3:Task Mikromanagement zu vermeiden


Tasks

Kleinste Einheit für Verantwortlichkeit des Managements At Ei h it fü Pl d V f l Atomare Einheit für Planung und Verfolgung Endliche Dauer, benötigt Ressourcen, produziert handfeste Ergebnisse

(Dokumente, Code) Spezifikation einer Task: Aufgabe

Name, Beschreibung der zu leistenden Arbeit Vorbedingungen Dauer benötigte Ressourcen Vorbedingungen, Dauer, benötigte Ressourcen Erwartete Arbeitsergebnisse Mit der Task verbundenes Risiko

Erfüllungskriterien Beinhaltet die Akzeptanzkriterien für die Arbeitsergebnisse


Größe von Tasks

Jede Entwicklungsaktivität identifiziert neue und modifiziert existierende Tasks

Tasks müssen in Größen f b h d di i

Die angemessene Größe von T k fi d i t

Tasks.

aufgebrochen werden, die ein Monitoring zulassen. Arbeitspakete entsprechen

Tasks zu finden, ist problematisch. TODO-Listen früherer Projekte p p

i.d.R. wohl-definierten Arbeitsanweisungen für einen Arbeiter und eine Woche (einen

jWährend der anfänglichen

Planung sind Tasks notwendigerweise groß.

Monat) Zeit. Abhängig von der Art der Arbeit

und davon, wie gut die Aufgabe

o e d ge e se g oß Es ist evtl. anfänglich nicht

bekannt, wie ein Problem in Tasks zu zerlegen ist g g

verstanden wird.Tasks zu zerlegen ist.


Beispiele für Tasks

Unit test für Klasse „Foo“T t d S b t “Bl ” Teste das Subsystem “Bla”

Schreibe das Benutzerhandbuch Schreibe ein Protokoll zur letzten Sitzung und verteile es Schreibe 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.g p Entwickle den Projektplan Zusammenhä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ßinnerhalb einer Woche oder weniger erledigt sein muß.

Action Items Tauchen auf der Agenda im „Status“-Abschnitt auf (siehe Vorlesung über g „ ( g

Kommunikation) Klären: Was?, Wer?, Wann?

Beispiel für Action Items: 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:00 Das VIP Team entwickelt einen project Plan bis 18. Sep.



Software Project Management Plan

Struktur eines Software Project Management PlansManagement Plans

Einstieg

1. Einführung

2. Projektorganisation2. Projektorganisation

3. Organisatorischer Prozess

4. Technischer Prozess

5. Arbeitselemente, Zeitplan, Budget

Optionale Anlagen


SPMP Teil 0: Einstieg

TitelblattR i i h t ( d t hi t ) Revision sheet (update history)

Vorwort: Umfang und Ziel Inhalts sowie Tabellen und Abbildungsverzeichnisse Inhalts- sowie Tabellen- und Abbildungsverzeichnisse


SPMP Teil 1: Einführung

1.1 Projektübersicht B h ib d P j kt P j kt f Beschreibung des Projekts, Projektzusammenfassung.

1.2 Endergebnisse des ProjektsAll li f d A ik l i l D d O d A li f Alle auszuliefernden Artikel, incl. Datum und Ort der Auslieferung

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

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

1.5 Definitionen und Akronyme


SPMP Teil 2: Projektorganisation

2.1 Prozessmodell B i h i h P j kt l t Beziehungen zwischen Projektelementen

2.2 Organisatorische StrukturI V l O i i di Interne Verwaltung, Organisationsdiagramm

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

2.4 Verantwortlichkeiten Die wichtigsten Funktionen und Aktivitäten

welcher Art sind sie? wer ist Verantwortlich?


2.1 Prozessmodell

Zeigt Beziehungen zwischen F kti Akti ität T k Funktionen, Aktivitäten, Tasks Meilensteinen Baselines Reviews Projektstrukturplan E d b i Endergebnisse

Visualisierung des Prozessmodells WerkzeugeWerkzeuge

MS Project (Microsoft) Google „project management tool“ „project management software“ Gemeinsame Schwäche: Nicht für „agile“ Softwareprozesse geeignet



Software Project Managemet Plan:

2.2 Organisatiorische Struktur

Beispiel eines Organisationsdiagramms

Client Management ConsultantsClient Management Consultants

Cross functional Teams Development Teams

LogbookArchitecture

HCIMaintenance

Vehicle

Web Master

Documentation

TravelConfiguration Mgt

Infrastructure Team

Assoziationen in Organisationsstrukturen

Berichterstattungsassoziationen di d Üb itt l St t i f ti dienen der Übermitteln von Statusinformationen

Entscheidungsassoziationen werden zum Propagieren von Entscheidungen verwendet werden zum Propagieren von Entscheidungen verwendet

Kommunikationsassoziationen dienen dem Austausch von Informationen, die zur Entscheidungsfällung

öti i d ( B A f d E t f d ll I )nötig sind (z.B. Anforderungen, Entwurfsmodelle, Issues...)


Betrachtungen zu Verwaltungsstrukturen

Hierarchische Strukturen “ t tt t B i ht” “ t h id t” d “k i i t it” d ll f di “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

t hi dli h A i tiunterschiedliche Assoziationen. Abbau von Bürokratie reduziert Entwicklungszeit. Es wird erwartet, dass auf jeder der Ebenen Entscheidungen getroffen

werden. Schwierig zu verwalten.


Hierarchische Kommunikationsstruktur

L it d A t lltKontrollfluss

Leitender Angestellter

Fi t L l M

Informationsfluss

First Level Manager(“Front-Line Manager”)

BAProjektteilnehmer

Komplizierter Informationsfluss: A möchte mit B reden.Komplizierter Entscheidungsfluss: A möchte, dass B etwas bestimmtes tut.

Organisationsgrundlage:Komplizierter Informations- und Kontrollfluss über


hierarchische Grenzen hinweg.

Hierarchische Struktur

Projekte mit einem hohen Grad an Sicherheit, Stabilität, Einheitlichkeit und Wiederholungund Wiederholung Benötigt wenig Kommunikation Rollen sind klar definiert.

Wann? J h L t i P j kt it b it d t öß i t di N t di k it Je mehr Leute im Projekt mitarbeiten, desto größer ist die Notwendigkeit

einer formalen Struktur. Evtl. besteht der Kunde darauf, dass das Testteam unabhängig vom

E f iEntwurfsteam ist. Projektleiter besteht auf einer Struktur, die sich zuvor als erfolgreich

erwiesen hat.


Projekt-basierte KommunikationsstrukturKommunikationsstruktur

Projektleiter

Coaches

Subsystem Team Subsystem Team Subsystem Team

ProjektteilnehmerA B

Direkter Informationsfluss: A will mit B reden.Direkter Entscheidungsfluss: A möchte, dass B etwas bestimmtes tut.

Organisationsgrundlage: Nicht-linearer Informationsfluss zwischen dynamisch formierten Einheiten

g ,


zwischen dynamisch formierten Einheiten.

Projekt-basierte Struktur

Projekt mit einem Grad an Unsicherheit Off K ik ti t d T il h i t f d li h Offene 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)Organisation: „Chief Programmer (Mills)

Chief Programmer

AssistantChief Programmer

Librarian Administrator TesterSenior Programmer …

Junior Programmerg


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

Der Chief Programmer i t d H t t tli h fü d E t f d di I l ti ist der Hauptverantwortliche für den Entwurf und die Implementierung. implementiert selbst kritische Funktionalität, weist den anderen Entwicklern Aufgaben zu und kontrolliert den g

Arbeitsfortschritt. Vorteile

Schnelle Enticklung durch wenig Kommunikation wenige Teammeetings Schnelle Enticklung durch wenig Kommunikation, wenige Teammeetings, kurze Entscheidungswege

Nachteile Chief Programmer ist Engpass der Entwicklung, muss Manager und

Hacker sein, demotiviert das Team Erfnder: Harlan D. Mills Erfnder: Harlan D. Mills

Erstmals in den 70er Jahren bei IBM eingesetzt. Onlinematerial: http://everything2.com/index.pl?node_id=1292141


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

A l tikAnalytiker

Tester Programmierer

Designer Bibliothekar


Eine andere Organisationsform: Egoless Programming Team” (Weinberg)„Egoless Programming Team (Weinberg) Programmierer identifizieren sich oft zu stark mit "ihrem" Code

Akzeptieren keine Änderungen testen nicht gründlich genug Akzeptieren keine Änderungen, testen nicht gründlich genug,… Egoless programming

“Collective code ownership” Motiviere Teammitglieder Fehler in allen Modulen zu suchen Fehler werden als normal betrachtet Starke Gruppenidentität Starke Gruppenidentität Kleine Gruppen ( <= 10 )

Vorteile von Egoless Teams Sehr produktiv Arbeiten am besten bei komplexen Problem Haben sich im Forschungsumfeld als erfolgreich herausgestellt Haben sich im Forschungsumfeld als erfolgreich herausgestellt

Problem schwer planbar


p Vergleiche: eXtreme Programming

Teambildung

Top-Level-Entwurf “G b ” S b t l ( d A f d l ) “Grobe” Subsystemzerlegung (vor der Anforderungsanalyse) Geschieht vor der eigentlichen Entwicklung

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

Ein Team für jedes Subsystem Eine Funktionsübergreifende Aufgabe pro Team 5-7 Mitglieder pro Team

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


Zuweisung von VerantwortungTeam

Rolle 1„ToDo“-Liste für das Projekt

Person ARolle 1Item 1Item 2Item 9

• Item 1Item 9

Rolle 2

Rolle 1

Rolle 2

• Item 2• Item 3

It 4

Person B

Item 4Item 5Item 7

• Item 4• Item 5• Item 6

Rolle 3Item 3 Rolle 3

Item 6• Item 7• Item 8 Item 3

Item 6Item 8

Rolle 3• Item 9


Mögliche Abbildungen von ToDos auf PersonenPersonen

Viele-zu-Wenige J d P j ktt il h i t h R ll ( Hüt “) Jeder Projektteilnehmer nimmt mehrere Rollen an („Hüte“). Gefahr des „Über-Engagements“ „load balancing“ ist notwendig.g g

Viele-zu-“Zu Viele“f Einige Teilnehmer spielen keine signifikante Rolle

„Zuschauer“ Verlieren den Anschluss an das Projektj



SNMP 2 4: Verantwortlichkeiten / SNMP 2.4: Verantwortlichkeiten / Rollen

Rollen in einem Projekt

PlanerA l ik

GruppenleiterLi i (V bi d ) Analytiker

Designer Programmierer

Liaison (Verbindungsmann) Projektleiter

Programmierer Tester Wartungspersonalg p Ausbilder Dokument Editor Web Master Konfigurationsmanager


Rollen in einem Projekt

Rollen im Management O i ti d D hfüh d P j kt t B ü k i hti Organisation und Durchführung des Projekts unter Berücksichtigung von

Rahmenbedingungen. Beispiele: Projektleiter, Teamleiter. Rollen in der Entwicklung

Spezifikation, Entwurf und Konstruktion der Subsysteme. Beispiele: Analytiker, Systemarchitekt, Programmierer.

Funktionsübergreifende Rollen Funktionsübergreifende Rollen Koordination mehrerer Teams. Beispiele: API Ingenieur,

Konfigurationsmanager, Tester Beratende Rollen

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


Wissenspromoter („Technologe“)

Propagiert Änderungen, die in der Anwendungs- oder Lösungsdomäne auftretenauftreten

AufgabenAufgaben Schrittweise Informationen aneignen Nutzen und grenzen neuer Technologie erkennen und mit den anderen

Entwicklern über den Einsatz dieser Technologie diskutierenEntwicklern über den Einsatz dieser Technologie diskutieren

Beispiel auf Projektebene: Systemarchitekte sp e au oje tebe e Syste a c te t Berichtet dem Projektleiter Hat keine direkten Untergebenen, der ihm Bericht erstattet Hat das letzte Wort in jeder technischen Entscheidung

Beispiel auf Unternehmensebene: Technischer Direktor


Beispiel auf Unternehmensebene: Technischer Direktor

Prozesspromoter

Der Prozesspromoter i t it d P d d P d d P j kt t t ist mit den Prozessen und dem Prozedere des Projekts vertraut. ist dafür verantwortlich einen Konsens über die langfristigen Ziele zu

erreichen.

Aufgaben V bi d i h P d Wi t di ft i ht di lb Verbindung zwischen Power- und Wissenspromoter, die oft nicht die selbe

Sprache sprechen Beispiel auf Projektebene

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

Beispiel auf Unternehmensebene Leiter der Technologieabteilung


Rollen im Projekt: Coach

auf Probleme einzelner Teams eingehenDi ö h tli h T t d h h Die wöchentliche Teamreports durchsehen

Den wöchentlichen Projektmeetings beiwohnen Treffen mit dem Kunden arrangieren Treffen mit dem Kunden arrangieren. Darauf bestehen, dass die Richtlinien befolgt werden Prä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)Management: Primärer Moderator) Führt das wöchentliche Projektmeeting Schickt die Agenda vor dem Treffen an alle Beteiligten Definiert und verfolgt Action Items (wer, was, wann) Misst Fortschritt (Setzt Meilensteine durch) Abgeschlossene Arbeitspakete an das Projektmanagement ausliefern Abgeschlossene Arbeitspakete an das Projektmanagement ausliefern Trägt Probleme und Status des Teams dem Projektleiter vor

Die Rolle des Gruppenleiters muss unter den Teammitgliedern durchrotiert werden.


Gruppenleiter: Erstellen einer TagesordnungTagesordnung

Zweck des TreffensA t bt E b i Angestrebtes Ergebnis

Informationsaustausch Informationsverarbeitung Informationsverarbeitung Meetingkritik

Status-Bericht über Action ItemsAction Itemsdes vorigen

Treffens

Issues(Siehe voriges

Treffen & Boards)


Treffen & Boards)

Rollen im Projekt: Liaison

Verantwortlich für die Kommunikation zwischen den Teams M ht öff tli h S h itt t ll S b t di T Macht öffentliche Schnittstellen von Subsystemen, die vom Team

entwickelt werden für das Architekturteam verfügbar Koordiniert teamübergreifende Aufgaben mit anderen Teams

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


Rollen im Projekt: Planer

Plant und verfolgt Aktivitäten eines Teans und hat die folgenden Aufgaben:Aufgaben:

Definiert den Projektplan für das Team PERT Diagramm, Ressourcetabelle und GANTT Diagramm, das die g , g ,

Arbeitspakete zeigt. Gibt den Projektplan in das jeweilige Projektmanagementwerkzeug ein.

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


Rollen im Projekt: Document Editor

Sammeln, Korrekturlesen und verteilen von DokumentationL t D k t ti d T d A hit kt t Legt Dokumentation des Teams dem Architekturteam vor

Sammelt Tagesordnungen Führt Protokoll bei Teammeetings Führt Protokoll bei Teammeetings


Web Master:

Pflegt die Homepage des Teams inklusive… Li t t tt f d M ti… Liste stattgefundener Meetings… Rationale zum Entwurf

Veröffentlich Informationen über die Teammeetings auf der Homepage g p gdes Teams Muss Tagesordnung, Protokoll, Action Items und Issues enthalten Mö li hk it Möglichkeiten:

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

h R ll )mehrere Rollen)

Date Agenda Minutes Action Items Issues

Agenda Minutes Action Items Issues9/9/96

Agenda Minutes Action Items Issues9/16/96


SPMP Teil 3: Organisatorischer SPMP Teil 3: Organisatorischer Prozess

SPMP Teil 3: Organisatorischer Prozess

3.1 Verwaltungsziele und -prioritäten Phil hi Zi l P i ität Philosophie, Ziele, Prioritäten

3.2 Annahmen, Abhängigkeiten, RahmenbedingungenE F k Externe Faktoren

3.3 Risikomanagement Identifizierung, Abschätzung, Verfolgung von Risiken, Contingency

3.4 Überwachungs- und Kontrollmechanismen Berichterstattungsmechanismen und -formate, Informationsflüsse, Reviews

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


Beispiele für Annahmen

Die Entwicklungsrechner sind schnell genug.

Sicherheit ist kein Thema.

Es gibt keine Bugs in 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 abgestellten EPC Datenbank ab.

Die automatische Codeerzeugung des CASE-Tools hängt vomDie automatische Codeerzeugung des CASE Tools hängt vom jeweiligen JDK ab. Die momentane Version unterstützt nur JDK 1.1.6


Beispiele für Rahmenbedingungen

Die Dauer des Projekts ist 3 Monate. Beschränkte Zeit zum Aufbau des SystemsSystems.

Das Projekt besteht aus Anfängern. Es wird Zeit brauchen, den j gUmgang mit den Tools zu lernen.

Nicht jeder Projektteilnehmer ist immer auf den neusten Stand was Nicht jeder Projektteilnehmer ist immer auf den neusten Stand, was den Status des Projekts betrifft.

UML und ein CASE-Took müssen verwendet werden.

N C d ll hli ßli h i J h i b d Neuer Code soll ausschließlich in Java geschrieben werden.

Das System muss JDK-1.1.6 verwenden.


Das System muss JDK 1.1.6 verwenden.

Risikomanagement

Risiko: Ein Subsystrem bietet nicht die Funktionalität die

Risiko: Teilnehmer in Schlüsselpositionen fallennicht die Funktionalität, die

von einem anderen benötigt wird.

Schlüsselpositionen fallen aus. Contingency: Rollen werden

Contingency: ?

Risiko: Ibutton läuft nur ab

jemand anderem Zugewiesen. Funktionalität des Systems wird mit dem Kunden neu

h d lt Risiko: Ibutton läuft nur ab JDK 1.2 Contingency: ?

ausgehandelt. Risiko: Das Projekt fällt hinter

den Zeitplan zurück.p Contingency: Extra

Projektmeetings werden anberaumt.anberaumt.



SPMP Teil 4: Technischer Prozess

SPMP Teil 5: Arbeitselemente, Zeitplan, BudgetBudget

SPMP Teil 4: Technischer Prozess

4.1 Methoden, Werkzeuge und Techniken C t t E t i kl th d T t kt t Computersystem, Entwicklungsmethode, Teamstruktur, etc. Standards, Richtlinien, Standards, Verfahren

4 2 S ft d k t ti4.2 Softwaredokumentation Dokumentationsplan, einschließlich Meilensteine, Reviews und Baselines

4 3 Hilf f kti fü d P j kt ( P j t S t F ti ‘)4.3 Hilfsfunktionen für das Projekt (‚Project Support Functions‘) Pläne für Funktionen (Qualitätssicherung, Konfigurationsmanagement)


SPMP Teil 5: Arbeitselemente, Zeitplan, BudgetBudget

5.1 Aufschlüsselung der Arbeitspakete (‚Work breakdown structure‘) Z l d P j kt i T k D fi iti d T k Zerlegung des Projekts in Tasks; Definition der Tasks

5.2 AbhängigkeitenP ä d l i i h F k i Ak i i ä d T k Präzedenzrelationen zwischen Funktionen, Aktivitäten und Tasks

5.3 Erforderliche Ressourcen Abschätzung für Ressourcen, wie z.B. Personal, Rechenzeit, spezielle

Hardware, zusätzliche Software,...

5 4 Budget und Ressourcenazuweisung5.4 Budget- und Ressourcenazuweisung Kosten mit Funktionen, Aktivitäten und Tasks in Verbindung setzen

5 5 Zeitplan5.5 Zeitplan Deadlines, Aufzeigen von Abhängigkeiten, notwendige Meilensteine


Erstellen von Arbeitspaketen

Aufschlüsselung der Arbeitspakete (AP) A fb h d P j kt i Akti ität (Ph S h itt ) d T k Aufbrechen des Projekts in Aktivitäten (Phasen, Schritte) und Tasks Abhängigkeiten zwischen den Tasks zeigt die WBS nicht.

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


Aufschlüsselung der Arbeitspakete: AbwägungenAbwägungen

Aufschlüsselung der Arbeitspakete beeinflusst Kosten und ZeitplanS h ll t fü di E t ll d AP i % d t A b it Schwellwerte für die Erstellung der AP in % der gesamten Arbeit: Kleiners Projekt (7 Personen-Monate): mindestens 7% bzw. 0.5 PM Mittleres Projekt(300 Personen-Monate): mindestens 1% bzw. 3 PMs Mittleres Projekt(300 Personen Monate): mindestens 1% bzw. 3 PMs Großes Projekt (7000 Personen-Monate): mindestens 0.2 % bzw. 15 PMs

Festlegung der AP ist inkrementell und iterativ.

Source: Software Engineering Economics, Barry W. Boehm

4 i 1981

AP Zeitplan

p. 47, Prentice Hall, N.J., 1981Kosten

(Zeit, ¥€$)


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

Eine wichtige zeitliche Relation: „Muss vor ... passieren“Abhä i k it h i t Abhä i k it t d T k Abhängigkeitsgraph zeigt Abhängigkeiten unter den Tasks (hierarchisch und zeitlich) Aktivitätengraphg p

Projektmeilensteine sind Knoten Tasks sind Kanten

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

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


Projektverwaltungswerkzeuge für ArbeitspaketeArbeitspakete Visualisierungshilfen für die Projektpräsentation

Graphen (Zeitplan) Bäume (WBS) Graphen (Zeitplan), Bäume (WBS) Tabellen (Ressourcen)

Task Zeitleiste Gantt Diagramme: Zeigen Projektaktivitäten und -tasks parallel.

Ermöglichen dem Projektleiter nachzuvollziehen, welche Tasks gleichzeitig bearbeitet werden können.

Z it l (PERT Di ) Zeitplan (PERT Diagramm) Grundstein vieler Projektverwaltungswerkzeuge Grafische Repräsentation von Abhängigkeiten zwischen Tasks und g g

Milestones. PERT: Program Evaluation and Review Technique

– Ein PERT diagramm geht von einer Normalverteilung der Taskdauer aus.Nüt li h fü A l k iti h Pf d ( C iti l P th A l i ‘)– 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


b au e öge ü de

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ärtnerei T k 1 1 R d d G b Task 1.1: Roden und Graben Task 1.2: Rasen sähen Task 1.3: Büsche und Bäume pflanzenp

Aktivität 2: Das Haus bauen Aktivität 2.1: Baustelle vorbereiten Aktivität 2.2: Rohbau Aktivität 2.3: Innenausbau


Projekt: ein Haus bauen (Fortsetzung)

Aktivität 2.1 : Baustelle vorbereiten Task 2 1 1: Vermessen

Aktivität 2.3 : Innenausbau Task 2 3 1: Int Klempnerarbeiten Task 2.1.1: Vermessen

Task 2.1.2: Baugenehmigung Task 2.1.3: Ausschachten

Task 2.3.1: Int. Klempnerarbeiten Task 2.3.2: Int. Elektroinstallation Task 2.3.3: Esstrich

Task 2.1.4: Materialbeschaffung

Aktivität 2.2: Rohbau

Task 2.3.4: Innenanstrich Task 2.3.5: Bodenbeläge Task 2.3.6: Innentüren

Task 2.2.1: Fundament Task 2.2.2: Außenwände Task 2 2 3: Ext Klempnerarbeiten Task 2.2.3: Ext. Klempnerarbeiten Task 2.2.4: Ext. Elektroinstallation Task 2.2.5: Verputzen Task 2 2 6: Außenanstrich Task 2.2.6: Außenanstrich Task 2.2.7: Aussentüren


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

1 21 1 Baugenehmigung beantragenVermessen

START

1.21.1

1.3 Ausschachtung

Baugenehmigung beantragenVermessen

1.4

2.1 Fundament

Materialbeschaffung

2.2

3.12.3Äußere Klempnerarbeiten Innere KlempnerarbeitenAußenwände

3.2

3.3

2.4

2.5

Äußere Elektroinstallation

Verputzen

Innere Elektroinstallation

Esstrich

3.42.6

2.7

3.5

3.6

Außenanstrich

Außentüren

Bodenbeläge Innenanstrich

Innentüren


Außentüren

ENDE

Zeitplanung: „Spielraum“ und „Kritischer Pfad“Pfad

Akti ität1 / A f b 1

Startdatum 1

Akti ität2 / A f b 2

Startdatum 2

istAktivität1 / Aufgabe1

Spielraum 1D 1

Aktivität2 / Aufgabe2

Spielraum 2D 2

ist Voraussetzung

für

Zeitlicher Spielraum (‚slack time‘)

Dauer 1 Dauer 2

p ( ) geplante Startzeit minus früheste mögliche Startzeit Spielraum 1 = Startdatum 2 – (Startdatum 1 + Dauer 1)

Kritischer Pfad (‚critical path‘) Der Pfad in einem Projektplan, für den der Spielraum 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


g g ggesamte Projekt!

PERT Diagramm für „Ein Haus Bauen„(Aktivitäten auf kritischen Pfaden sind rot markiert)(Aktivitäten auf kritischen Pfaden sind rot markiert)

Genehmigungen beantragen M t i l F d t

27.08.2007

27.08.2007 17.09.2007 01.10.2007 15.10.2007

STARTg

Ausschachtung Materialbeschaffen

Fundamente legen

Vermessen27.08.2007

00

015

010

010

015

22.01.2008

Vermessen

03.12.2007 21.12.2007 11.01.2008

123

Klempnerarbeiten(innen)

Elektroinstallation(innen) Esstrich Bodenbeläge

012

015

09

018

Aussenwände Innenanstrich

05.11.200722.01.2008

020

011

16.02.2008

Innentüren ENDEElektroinstallation(innen)

Klempnerarbeiten(aussen) Verputzen

08.02.200803.12.2007 17.12.2007 31.12.2007

11

07 0


1210

1210

128

7 00

Aussenanstrich

12.01.2008

125

Aussentüren

19.01.2008

156

Wie werde ich ein guter Projektplaner?

Stell einen Projektplan auf. F b i d f d i E f h it P j kt 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 Bestimme die Differenz zwischen geplantem und tatsächlichen

Durchsatz Denk daran, eine Post-Mortem-Analyse zu machen

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


Heuristiken zum Projektmanagement

Halte dir die Möglichkeit offen, einen Projektplan zu ändern oder auch komplett zu verwerfenkomplett 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 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 Sei nicht überrascht, wenn aktuelle Projektverwaltungstools nicht

funktionieren: Sie wurden für Projekte mit klaren Zielen und festen

O i ti t kt t f


Organisationsstrukturen entworfen.

Projektmanagement: Zusammenfassung

Übereinkünfte zwischen Kunden, Managern und Teams P bl t ll Problemstellung Software Project Management Plan Projektvereinbarungj g Stell sicher, dass die Übereinkünfte Nachbesserungen ermöglichen.

Organisationsstrukturen SPMP Projektplanung

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

Funktionen Werkzeuge und Techniken

GANTT, Abhängigkeitsgraph, Zeitplan, Critical Path Analyse Vorsicht mit Werkzeugen in Projekten mit viel Änderung


Vorsicht mit Werkzeugen in Projekten mit viel Änderung

Kapitel 12 Projektmanagement - Software engineering€¦ · Software Project Management Plan (SPMP)...

Documents

Transcript of Kapitel 12 Projektmanagement - Software engineering€¦ · Software Project Management Plan (SPMP)...