Projektmanagement - Institut für Informatik

Transcrição

Projektmanagement
Prof. Dr. Bernhard Bauer
Programmierung verteilter Systeme Lab
Institut für Informatik
Universität Augsburg
Universitätsstraße 14, 86159 Augsburg
Tel.: (+49) 821/598-2174, Fax: -2175
URL: http://www.informatik.uni-augsburg.de/vs
1
Organisatorisches
Bei weiteren Fragen:
Prof. Dr. Bernhard Bauer:
Sprechstunde: Montag 13:00 – 15:00 Uhr
Informatikgebäude, Zi. 2001
[email protected]
2
Ziele der Vorlesung
Die Hauptziele der Vorlesung
„Projektmanagement“
sind:
Einblick in die Begriffe, Methoden und theoretischen Grundlagen des
Projektmanagements
Kenntnis kritischer Erfolgsfaktoren für erfolgreiches SoftwareProjektmanagement
Projektcontrolling als wichtiger Aspekt für Einhaltung der Projektziele
Faktor Mensch in Projekten berücksichtigen
3
Literatur
Manfred Burghardt: Projektmanagement: Leitfaden für die Planung,
Überwachung und Steuerung von Entwicklungsprojekten, 5. Auflage, 2000,
Publicis MCD Verlag
Dirk Börnecke: Basiswissen für Führungskräfte: Die Elemente erfolgreicher
Organisation, Führung und Strategie, 2. Auflage 2001, Publicis MCD Verlag
H. Balzert: Lehrbuch der Software-Technik, Band 1, Spektrum Akademischer
Verlag, 2000
I. Sommerville: Software Engineering. Pearson, 2001.
T. DeMarco.: The Deadline: A Novel About Project Management. Dorset
House Publishing, 1997
U. Witschi, A. Erb, R. Biagini, Projekt-Management: Der BWILeitfaden
zu Teamführung und Methodik. Verlag Industrielle Organisation Zürich, 1996
T. DeMarco, T. Lister: Wien wartet auf Dich. Der Faktor Mensch im DVManagement.
K. Tumuscheit: Überleben im Projekt. 10 Projektfallen und wie man sie
umschifft. Orell Füssli, 1999.
4
Folien und Skripte
Bernhard Schätz: Vorlesung Projektorganisation und Management LeopoldFranzens Universität Innsbruck Sommersemester 2003
Ralf Reichwald, Frank Mang Management Innovativer Softwareprojekte
Wintersemester 2002/2003, TUM München
Siemens: Projektmanagement: ZuWAS Die Zukunft bestehen – Wirtschaft,
Arbeitswelt, Schule, 2002
5
Kapitel 1:
Einleitung
Motivation
Projekt
Schwierigkeiten bei SW-Projekten
Projektmanagement
PM – Crashkurs
Schlüsselfaktoren für den Projekterfolg
Summary
6
1.1 Motivation
Historische Projekte
Bau der Chinesischen Mauer
7.300 km Länge zur Abgrenzung
Mehrere 100 Jahre Bauzeit
Neuartige Konstruktion und Bauelemente
Bau der Pyramiden
147 m hoch, 2,3 Mio. Steinquader
20 Jahre Bauzeit
Ca 100.000 Teilzeitmitarbeiter
Turmbau zu Babel
Mächtige Stadt soll entstehen
Spitze bis in den Himmel
Misserfolg wegen Kommunikationsproblemen
7
1.1 Motivation
Private Projekte
Umzugsplanung
Wohnungssuche
Transportmittel
Helfer organisieren
Kartons,...
Studienplanung
welche Vorlesungen
welche Scheine
welche Seminare
Praktika
Hiwi-Jobs,...
8
1.1 Motivation
Technische Projekte
Flughafenneubau und -umzug München
Laufzeit ca. 10 Jahre (mit langer Planungsphase)
Umzug an einem Tag (Samstag 18:00 – Sonntag 9:00)
„Das 3 Liter Auto“
Politische Auftraggeber
Technische Implementierung durch unterschiedliche „Auftragnehmer“
Fraglicher Erfolg...
9
1.1 Motivation
Projekte scheitern – Klassiker:
1992: Integration des Reservierungssystems SABRE mit anderen
Reservierungssystemen abgebrochen: 165 Mio US $
1994: Softwareproblemen im Gepäcktransport-System verzögert Eröffnung des
Denver International Airport um 9 Monate
2000: US-Unternehmen verloren insgesamt 100 Milliarden US $ wegen
„defekter“ Software
10
1.1 Motivation
Projekte scheitern...
Presse:
CW 09/00: „RWE setzte Java-Projekt Cheops in den Sand: Nach vier Jahren
Planungs- und Implementierungszeit sowie Investitionen in Höhe von mindestens 100
Mio. DM wurde das geplante SAP-Nachfolgeprojekt de facto eingestellt....Warum gehen
Projekte dieser Größenordnung schief: zum einen wegen unzureichendem
Anforderungsmanagement, zum anderen wegen fehlender Kommunikation“
CW 03/02: „Microsoft verschiebt Windows .Net Server erneut: Bereits zum zweiten
Mal hat Microsoft den Erscheinungstermin für den Windows-2000-Server-Nachfolger
"Windows .Net Server„ verschoben. Nun soll sie erst in der zweiten Jahreshälfte (2002)
verfügbar sein. (..) Im April vergangenen Jahres hatte der Hersteller das Server-Pendant
zu Windows XP bereits von Ende 2001 auf Anfang 2002 vertagt. (...)
Sicherheitsbemühungen könnten .Net Server sogar noch weiter verzögern.“
11
1.1 Motivation
Projekte scheitern noch immer...
Presse:
(Heise 2003) Inpol-Neu kommt stark verspätet: Das neue Computersystem für das
Bundesinnenministerium, welches ursprünglich im April 2001 eingeführt werden sollte,
wurde im August 2003 doch erfolgreich gestartet. Das Polizei-Fahndungssystem wird als
60-Millionen-Euro-Projekt Polizisten 270.000 Abfragestellen für die Suche nach Tätern,
Beweisstücken und vor allem nach Beziehungsgeflechten zur Verfügung stellen.
(Heise 2005) Toll Collect: Testphasen und Starttermin immer wieder verschoben. On
Board Units (OBUs) anfangs fehlerhaft und mussten ausgetauscht werden. 2004
Kündigung des Vertrags zwischen dem Bund und TollCollect, dann aber
Zusammenarbeit doch verlängert. Mittlerweile spielt die LKW-Maut ca. 240 Millionen
Euro im Monat ein, Toll Collect auch in Ausschreibungen für Tschechien und Schweden
beteiligt. Sollte die PKW-Maut eingeführt werden, würde die Einnahmen von Toll Collect
stark steigen. Der Bund rechnet mit 3 Milliarden Euro für den Betrieb im ersten Jahr, 600
Millionen behält Toll Collect ein. Der Bund fordert wegen der zu späten Einführung aber
immer noch Zahlungen in Höhe von mehr als 5,1 Milliarden Euro.
12
1.1 Motivation
Projekte werden auch weiter scheitern?
Bunderwehr-IT-Projekt „Herkules“: Kosten von 6,65 Milliarden Euro für die nächsten
10 Jahre einkalkuliert. Bereits 2001 war die erste Ausschreibung. 2005 wird nach dem
Ausstieg von T-Systems aus dem letzten Bieterkonsortium das Projekt, welches nun von
IBM und SBS alleine durchgeführt werden soll, totgesagt. Endgültige Entscheidung der
Bundeswehr nicht vor Herbst 2005 erwartet.
Gesundheitskarte: Das „größte IT-Projekt der Welt“ (Auslieferung an 80 Millionen
Versicherte und 1,8 Millionen Firmen im medizinischen Dienstleistungssektor), welches
ursprünglich für Januar 2006 eingeführt werden sollte, scheint frühestens in 5 bis 10
Jahren voll funktionsfähig zu sein. Nach diversen Datenschutzkritiken werden nun
Funktionen wie Arzneimitteldokumentation erst in späteren Versionen eingebaut.
Biometrischer Reisepass?
13
1.1 Motivation
Misserfolgsfaktoren
The Standish Group (Chaos-Report USA, 2001)
23% der Projekte werden abgebrochen
49% der Projekte sind über dem Kosten- und/oder Zeitplan
28% der Projekte im Zeit- und Kostenplan
Zum Vergleich: Stand 1995
31% der Projekte werden abgebrochen
53% der Projekte kosten 189% der ursprünglichen Planung
nur 16% der Projekte im Zeit- und Kostenplan
14
1.1 Motivation
Misserfolgsfaktoren (Chaos-Report USA, 1995)
Unvollständige/ungenaue Anforderungen
13,1%
Mangelnde Einbeziehung der Beteiligten
12,4%
Ressourcenmangel
10,6%
Unrealistische Erwartungen
9,9%
Mangelnde Unterstützung vom Management
9,3%
Sich häufig ändernde Anforderungen/Spezifikationen
8,7%
Mangelnde Planung
8,1%
Wird nicht mehr benötigt
7,5%
Mangelndes IT-Management
6,2%
Mangelndes Technologiewissen
4,3%
etc.
15
1.1 Motivation
Erfolgsfaktoren für Projekte
Für Projektabwicklung geeignete Unternehmensorganisation
Hoher Stellenwert von Projektleitung im Unternehmen
Definierte Entwicklungsprozesse, die auch angewendet werden
Verfügbarkeit von Ressourcen
Qualifikation der Mitarbeiter
Funktionierendes Qualitätsmanagement
Kommunikationsprobleme meistern (Einbeziehung der Stakeholder)
Verteilte Entwicklung beherrschen: Unternehmensauftragnehmer,
standortübergreifende Entwicklung, Globalisierung, etc.)
etc.
16
1.1 Motivation
17
1.1 Motivation
18
1.2 Projekt
Was ist ein Projekt?
Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die
Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist,
z.B.
Zielvorgabe
zeitliche, finanzielle, personelle und andere Begrenzungen
Abgrenzung gegenüber anderen Vorhaben
projektspezifische Organisation.
( DIN 69 901)
19
1.2 Projekt
Merkmale eines Projekts
Vorgegebenes Ziel
Projekt
Begrenzte Ressourcen
Definierter Endtermin
Projekt
Einmalig
Produkt
Komplex
Risikoreich
Dynamisch
HW-Produkte
SW-Produkte
Interdisziplinär
20
1.2 Projekt
Komponenten eines Projekts

Aufbauorganisation
Projektfunktionen
Projektorganisation

Ablauforganisation / Meilenstein und
Phasen
Phasenorganisation
Meilenstein-Trendanalyse

Projektzielsetzung
Aufbauorganisation
Ablauforganisation
Projektziele
Requirements

Projektplanung

Strukturplanung
Aufwandsschätzung
Ablaufplanung
Terminplanung
Projektsteuerung und -überwachung
Berichtswesen
Steuerungsmaßnahmen
Projektziel
Projektplanung
Projektsteuerung
21
1.2 Projekt
Typische Situation bei FuE- Projekten
Typische Situation bei FuE- Projekten sind
Ziel bei Projektbeginn nicht genau bekannt
Lösungsweg muss erarbeitet werden
Hoher Innovationsgrad
Hohe Änderungsintensität
Termindruck
Vorgegebene Bearbeitungskapazität
Zusammenarbeit verschiedener Disziplinen
Notwendigkeit für kreativen Freiraum
FuE = Forschung und Entwicklung
22
1.2 Projekt
Anforderungen an Projekte
Anforderungen an das
Ergebnis steigen!

Komplexität
- Größe
- Integration
Anforderungen an das
Projekt steigen!

Termine

Ressourcen
Projekt

Neuartigkeit

Produktivität

Qualität

Zahl der Beteiligten
Ö Komplexität beherrschen!
23
1.3 Schwierigkeiten bei SW-Projekten
Das magische Viereck
Zeit: Projektlaufzeit
Kosten: Budget
Qualität: z.B. Funktionalität, Nutzbarkeit, Wartbarkeit
Quantität: Anzahl ausgelieferter Funktionen
24
Komplexität des Produkts
Faktoren: Größe, Diversität, Vernetzung
Führt zu Komplexität des Prozesses
SW oft komplexer als „klassische“ Ingenieurprodukte
25
Kennzahlen des Systems R/3
ERP (Enterprise Resource Planning)-Standardsoftware der SAP AG,
Walldorf
SAP ist der Weltmarktführer für diese Software
ca. 7.000.000 Zeilen Quellcode
ca. 100.000 Funktionsaufrufe
ca. 20.000 unterschiedliche Funktionen
ca. 21.000 Reports
ca. 17.000 Menüleisten
ca. 14.000 Funktionsbausteine
26
Effizienz vs. Flexibilität:
Effizienz: Einsatz bewährter Methoden zur Kostenreduktion:
Standardanwendungsdomäne
Standardentwicklungsplattform
Standardentwicklungsprozess
Standardentwicklungsumgebung
Flexibilität: Das Unvorhersehbare planen:
Änderung der Anforderungen durch den Kunden
Änderung der Entwicklungsplattform durch das Management
Mitarbeiterfluktuation
Änderung des Ausliefertermins durch das Management
Verzögerungen durch die Zulieferer
27
Weitere Schwierigkeiten von SW-Projekten
Immaterialität des Produkts: Software ist unsichtbar und damit
Für den Kunden schwer erlebbar (Kostenbewußtsein)
Bzgl. des Fertigungsgrades schwer messbar
Risiko: Umfang, Kosten und Laufzeit
Innovativität des Produkts: Software ist i.a. „Null“-Serie und damit
Mit dem Einsatz neuster Technologie verbunden
Mit der Realisierung umfassender neuer Funktionen verbunden
Risiko: Stabilität (Qualität) und Laufzeit
Mangelnde Prozessreife: SE ist eine junge Disziplin und damit
Fehlen standardisierte und etablierte Entwicklungsprozesse
Verständnis für die ingenieurmäßige SE (Kunst vs. Handwerk)
Risiko: Qualität und Laufzeit
28
Darüber hinaus können Ursachen für Schwierigkeiten sein:
Verantwortlichkeiten, Informations- und Entscheidungswege sind nicht
ausreichend geregelt
Projektauftrag und somit Projektziel ist unklar
Anforderungen werden am Projektbeginn nicht überprüft
Neue (An)forderungen gefährden/verändern die geplanten Projektziele
Termine werden vom Wunschdenken/Auftraggeberanforderungen diktiert
Kosten werden pauschal geplant
Zielabweichungen (Ergebnisse, Kosten, Termine) werden zu spät erkannt
Probleme werden gelöst, wenn sie aufgetreten sind (Reaktion vs. Proaktivität)
29
1.4. Projektmanagement
Ziele und Prinzipien
Ziele der Projektabwicklung
Projektziel erreichen
Risiken einengen
Geforderte Qualität erreichen
Durchlaufzeit verkürzen
Wirtschaftliche Abwicklung
Laufende Transparenz
Zuverlässige Aussagen
durch
Projektmanagement
30
Ziele und Prinzipien
Die Prinzipien des Projektmanagements sind dabei
klare Zielsetzung
Auftraggeber, Teilaufgaben, realistisch, akzeptiert
Strukturierung
Produkt, Prozess, Planung, Organisation, Top-Down, sinnvolle Detaillierung
Ergebnisorientierung
Meilensteine, Phasenorganisation, Projektfunktionen
klare Verantwortlichkeiten
Organisation, Ergebnisse, Personifiziert, Know-how-Träger
eindeutige Zustände
Organisation, Prozess, Planung, Entscheidung, Änderungen, Information
Einbeziehen der ProjektmitarbeiterInnen
Zielvereinbarungen, Motivation, Kommunikation, Kreativität
frühzeitiges Handeln
Zieldefinition, Organisation, Planung, Risikoeinengung, Entscheidungen
31
Projektmanagement
Projektleiter
Projektstrukturpläne
Matrixorganisation
Projektmanagement ?
Netzplantechnik
Ganzheitliche
Methodik zur
Arbeitspakete
Erreichung des
Projektziels
Phasenorganisation
Meilensteintrendanalyse
Task Force
32
Software-Entwicklungsprozess
Projektziele
Design
Implementierung
Anforderungen
der Stakeholder
Anforderungsanalyse
Test
Softwaresystem
Aktivität
Ressourcen
der
Infrastruktur
33
Standort des Projektmanagements
Projektstart
Projektideen
Projektvorfeld
Projektabschluss
Projektmanagement
Projektdurchführung
Systemnutzung
Lebenszeit des Projekts
Lebenszeit des Systems
34
Definitionen
Die Aufgabe des Projektmanagers besteht darin, sicherzustellen, dass das
Softwareprojekt (...)(Budget- und Zeitbeschränkungen) gerecht wird, und
Software abzuliefern, die zum Erreichen der wirtschaftlichen Ziele beiträgt.
Sommerville, I. Software Engineering. Pearson, 2001.
Management umfasst alle Aktivitäten und Aufgaben, um die Aktivitäten von
Mitarbeitern zu planen und zu kontrollieren damit ein Ziel oder der Abschluss
einer Aktivität erreicht wird, die durch die Mitarbeiter alleine nicht erreicht werden
können (...): Planung, Organisation, Personalauswahl, Leitung, Kontrolle
Balzert, H. Lehrbuch der Software-Technik. Spektrum, 1998.
35
Definitionen
Definition Projektmanagement (DIN 69 901)
Für die Abwicklung eines Projekts die Gesamtheit von
Führungsaufgaben

Führungsorganisation

Führungstechniken

Führungsmitteln

Zielsetzung
Zieleinhaltung
Entscheidung
Projektorganisation
Projektabwicklung
Motivationstechnik
Besprechungstechnik
Präsentationstechnik
Entscheidungsfindungstechnik
Produkt- und Projektstrukturplanungssysteme
Termin-, Kapazitäts-, Kosten-,
Planungs- und Steuerungssysteme
36
PM vs. ST
Abgrenzung zur Software-Technik:
Softwaretechnik: Ingenieurtechnik, Fachdisziplin
Projektmanagement: Nichtfachliche Abwicklung Entwicklungsprozess
Starke Schnittstellen:
Vorgehensmodelle (Prozessmodelle)
Qualitätsmanagement
Konfigurationsmanagement
37
Das "Magische Dreieck"
Das "Magische Dreieck"
Ziel
Rentabilität
Effektivität
Produktivität
Aufwand
Termin
38
Das "Magische Viereck"
Und hier noch mal das magische Viereck
Zeit: Projektlaufzeit
Kosten: Budget
Qualität: z.B. Funktionalität, Nutzbarkeit, Wartbarkeit
Quantität: Anzahl ausgelieferter Funktionen
39
Einteilung der Projektziele
Projektziele
Managementziele

Ziel erreichen
Erfolgreich sein
Immer transparent sein
Vorsprung ausbauen
Produktziele

Funktion
Leistung
Qualität
Prozessziele

Termine
Aufwand
Abwicklung
40
1.5. Projektmanagement – Crashkurs
Requirements
Requirements
... sind die einzelnen Anforderungen an Produkt, Projekt, Prozess aus der
Sicht des Anwenders.
... sind die Grundlage der Vereinbarungen mit dem Auftraggeber.
... werden vom Auftraggeber und der Entwicklung verantwortet.
... werden inhaltlich vom Auftraggeber und der Entwicklung akzeptiert.
... werden in den ersten Phasen des Projektes erarbeitet.
... sind die Ausgangsbasis für die Entwicklung.
41
Change Request (CR)

Änderungen an Entwicklungsergebnissen sind unvermeidlich
- Änderungen der Aufgabenstellung
- Neue Erkenntnisse bei der Produktentwicklung
- Fehler bei der Produktentwicklung

Ziel der formalisierten Behandlung von Änderungen (CR) ist es,
die Konsistenz der Entwicklungsergebnisse zu erhalten

Änderungen beziehen sich auf definierte Entwicklungsergebnisse
(Baselines) und haben Auswirkungen auf
- Teilprozesse (Meilensteine)
- Davorliegende Entwicklungsergebnisse (Backtracking)
- Nachgelagerte Entwicklungsergebnisse

Änderungen werden einzeln oder als "Versionsentwicklung" durchgeführt.
42
Change Request Prozedur
Antragsteller
Entwicklung
Change
Control Board
Angenommen
Change
Request
Technische
Untersuchung
Entwicklung
Änderung
betroffener
Dokumente
Information an
Antragsteller
Entscheidung
Abgelehnt
Projektnotiz
Verfolgung des Change Request
Systemplanung
43
Projektfunktionen
1. Projektspezifische
Definition der
Projektfunktionen
2. Übertragung der Projektfunktionen inkl. Kompetenz
und Verantwortung auf die
Aufgabenträger
Projektfunktionen
Aufgabenträger
Organisationsformen

LinienProjektorganisationen

MatrixProjektorganisationen

Reine
Projektorganisation

Projektleitung

Projektplanung und
-überwachung

Personen

Systemplanung
und -überwachung

Systementwicklung
Projektstellen
- Linienstellen
- Stabsstellen
- Temporäre Stellen

Systemintegration
und -test

Qualitätssicherung

3. Einbettung des Projekts in
die vorhandene Organisation
Gremien
44
Projektfunktionen – Checkliste
Projektleitung
Klärung der Zielvorgaben und Randbedingungen des Projektes;
Festlegung projektinterner Zielvorgaben
Steuerung der Zielerreichung
Festlegung der Aufbau- und Ablauforganisation
Delegation von Aufgaben; Vergabe von Teilaufträgen
Koordinierung aller am Projekt beteiligten Stellen
Ressourcen- und Personalbeschaffung
Personalführung
Entscheidung über Lösungsalternativen
Festlegung von Entwicklungsprioritäten
Entscheidung über Freigabe von Planungen und Entwicklungsergebnissen
Information des Managements
Kommunikation mit dem Auftraggeber
Außenvertretung des Projektes
45
Projektorganisation – Organisationsformen
Bereichsleitung
PL
E
Bereichsleitung
F
V
PL
PL
E
F
V
PL
Projekte in reiner Projektorganisation
Bereichsleitung
E
PL
F
Projekte in Matrixorganisation
V
PL
Projekte in reiner Linienorganisation
46
Projektplanung – Allgemein
Strukturplanung
Operative Planung
Produktstruktur
Objektstruktur
Projektstruktur
Aufwände
Dauer
Termine
Kapazitäten
Kosten
47
Schritte der Projektplanung
Produktstruktur
Aus welchen Komponenten besteht das Produkt?
Objektstruktur
Welche generellen Untersuchungen?
Welche Zwischenergebnisse (Prototypen)?
Welche Entwicklungsdokumente?
Welche Hilfsmittel, Tools, Vorrichtungen, Messgeräte?
Welche Steuerungsergebnisse (Planungen, Berichte)?
Projektstruktur
Welche Arbeitspakete zur Erstellung der Objekte?
48
Ablaufplan
Komponentencode

Der Ablaufplan stellt
die sachlogische
Verknüpfung (Input/
Output) der Arbeitspakete des Projektstrukturplans dar.

Der Ablaufplan bildet
die Grundlage für die
Erstellung des Netzplans.

Der Ablaufplan fasst
Arbeitspakete des
Projektstrukturplans
sinnvoll zusammen.

Der Ablaufplan wird
grafisch dargestellt.
Komponentenspezifikation
Komponentenbeschreibung
Designspezifikation
Komponententest
Testspezifikation
Testdaten
49
Netzplan (NP)

Der Netzplan zeigt die grafische Darstellung aller Arbeitspakete mit ihren
Abhängigkeiten untereinander.

Er stellt übersichtlich und kontrollierbar den geplanten Projektverlauf dar.

Er zeigt nach erfolgter Terminberechnung
- Anfangs- und Endtermine der Arbeitspakete und deren zeitliche Dauer
- den "kritischen Weg" und die Pufferzeiten.
Ö Der Netzplan ist ein Hilfsmittel zur Planung
und Überwachung der Projekttermine.
50
Definition des Meilensteins
Meilensteine bezeichnen
Definierte Sachergebnisse (Meilenstein-Inhalt)
Fertigstellungstermin (Meilenstein-Termin)
Meilenstein-Inhalte sind
wesentlich
überprüfbar
übergebbar
eindeutig festgelegt
voraus definiert (Phasenorganisation)
Meilenstein-Termine werden in der Projektplanung ermittelt
51
Berichtszeitpunkte
200x
200x
200x
200x
200x
I II III IV I II III IV I II III IV I II III IV I II III IV
2
0
0
x
MeilensteinTermine
IV
III
II
I
2
0
0
x
IV
III
II
I
IV
III
II
I
IV
III
II
I
2
0
0
x
IV
III
II
I
2
0
0
x
2
0
0
x
Projekt: xxx
Projektleiter: xxx
53
Berichtszeitpunkte
200x
200x
200x
200x
200x
2
0
0
x
MeilensteinTermine
IV
III
II
I
2
0
0
x
IV
III
II
I
IV
III
II
I
IV
III
II
I
2
0
0
x
IV
III
II
I
2
0
0
x
2
0
0
x
Projekt: xxx
Projektleiter: xxx
55
Abweichungen
Subjektive Einschätzung der
Fertigstellung
100
95
98
98
95
98
99
100
90
80
75
60
50
40
30
20
10
Der Fertigstellungsgrad eines Software-Projektes wird während der
Hälfte der Projektlaufzeit mit größer als 95% eingeschätzt !
56
Berichtswesen
Ziel: Stets aktueller Überblick
Was wird berichtet?

Termine
Kosten
Leistung, Qualität
Kapazität
Wie wird berichtet?

Meilensteintrendanalyse (MTA)
Projektberichterstattung
Meilensteine, Arbeitspakete, Laborberichte, QS- Berichte, KM- Control
Harte Daten

Probleme
Motivation
Risikoerwartung
Verhalten des Auftraggebers
Monatsbericht
TOP Bericht

Verbal
Weiche Daten
57
Abweichungen
Ziel: Abweichungen möglichst früh erkennen!
Welche Abweichungen gibt es?

Vollständigkeit der Ergebnisse
Qualität der Ergebnisse
Termine
Kosten
Produktivität
Kapazität
Managementziele
Woran erkennt man sie?

Offizielles Berichtswesen
- MTA
- Verbale Monatsberichte
- QS- Berichte
- Projektbibliotheks-Bericht

Beobachtung
- Stimmung im Projekt
- Gespräche
- Arbeitsverhalten
- Gerüchte

Reviews
58
Häufigste Ursachen für Abweichungen

Komplexität überfordert den Entwickler;
Kein Überblick über die Zusammenhänge

Unterschätzung des Aufwandes an Zeit und
Manpower für die Restarbeiten

Fehlen einer realistischen Planung
bzw. zu optimistische Planung
59
Ziel: Termin einhalten!
Leistung

Reduzieren
Versionsbildung
Produktkauf
Aufwand

Technische Alternativen
Entwicklungsprozess
Nutzen von Vorhandenem
Kapazität

Vergrößern
Umverteilen
Zukaufen
Produktivität

Ausbildung
Abschirmen
Information, Kommunikation
Motivation
60
1.6 Schlüsselfaktoren für den Projekterfolg
Projekterfolg eingebettet in Handlungsweisen des/der
Projektmanagers
seines Teams
Übergeordneten Organisation
Organisation des Auftraggebers
Handlungsweisen des PMs, die den Projekterfolg fördern
Projektkernteam selbst auswählen
Nur Mitarbeiter in Kernteam aufnehmen, die bewährt sind
Von Anfang an: Gefühl der Verpflichtung und Sinn für Mission
Ausreichende Kompetenzen beschaffen
Organisationsform: Projektorganisation
Gutes Verhältnis zu den Beteiligten
Öffentliches Ansehen des Projekts verbessern
Kernteam in Entscheidungsfindung und Problemlösung einbeziehen
…
61
Handlungsweisen die Projekterfolg fördern
…
Realistische Kosten-, Zeit- und Leistungsvorgaben entwickeln
Einen Ausweichplan für potenzielle Probleme bereithalten
Eine passende Teamstruktur wählen, die trotzdem flexibel und flach ist
Funktionsfähige Projektplanungs- und Steuerungswerkzeuge einsetzen
→ Sich nicht nur auf eine Art von Steuerungswerkzeug verlassen
Prioritäten vergeben, um das Endziel zu erreichen
Änderungen unter Kontrolle halten
Nach Möglichkeiten suchen, um leistungsfähigen Projektteammitgliedern einen
sicheren Arbeitsplatz zu bieten
62
Für die übergeordnete Organisation gibt es zahlreiche
Variablen, die für den Projekterfolg förderlich sind, wie z.B.
Die Bereitschaft, strukturelle Flexibilität zuzulassen
Die Bereitschaft, sich an Änderungen anzupassen
Eine effektive strategische Planung
Die angemessene Betonung von Erfahrungen aus der Vergangenheit
Der Einbau von Pufferzeiten
Eine unmittelbare und korrekte Kommunikation
Eine „enthusiastische“ Unterstützung
Allen betroffenen Parteien deutlich machen, dass das Projekt einen Beitrag zum
Unternehmenserfolg leistet
63
Folgende Schritte müssen unternommen werden:
Frühzeitige Wahl eines Projektmanagers mit nachgewiesener technischer
Fachkenntnis, sozialer Kompetenz und Führungsqualitäten (in der genannten
Reihenfolge)
Entwicklung von klaren und realisierbaren Richtlinien für den Projektmanager
Delegation ausreichender Befugnisse an den Projektmanager. Dem
Projektmanager gestatten, wichtige Entscheidungen gemeinsam mit den
Kernteammitgliedern zu treffen.
Begeisterung für das Projekt und sein Team zeigen
Aufbau von kurzen, informellen Kommunikationswegen
Den Projektmanager in Bezug auf Vertragsabschlüsse nicht extrem unter Druck
setzen
Die Kostenschätzung des Projektteams nicht willkürlich zusammenstreichen oder
aufblasen
Ein enges Arbeitsverhältnis zwischen Auftraggeber und Projektmanager
herstellen
64
Vorbedingungen für Management-Techniken
Klare Spezifikationen und Designs
Realistische Zeitpläne
Realistische Kostenpläne
Vermeidung von übermäßigem Optimismus
Auftraggeberseite
Die Pflege einer engen Beziehung
Die Aufstellung von vernünftigen Zielen und Kriterien
Gut etablierte Prozeduren für Veränderungen
Umgehende und exakte Kommunikation
Minimierung des Papierkriegs
Der Kontaktperson ausreichende Befugnisse geben (insbesondere bei der
Entscheidungsfindung)
65
1.7 Kosten des Projektmanagements
Kosten des Projektmanagements
oft Widerstand gegen moderne PM-Methoden wegen angeblich zu hohen Kosten
Die Frage sollte aber nicht
”Kann ich mir ein Projektmanagement leisten?“
sondern
”Kann ich mir es leisten, kein Projektmanagement
zu haben?“
lauten.
66
1,7 Kosten des Projektmanagements
Art und Umfang der durchzuführenden PM-Aufgaben hängen u.a. ab von
Art der Entwicklungsaufgabe
Größe des Entwicklungsvorhabens
Form der Projektorganisation
Anzahl der Entwicklungspartner
Entwicklungsdauer
Verhältnis Personal-/Materialkosten
Durchdringung mit PM-Methoden und Verfahren
67
Kostenbestandteile des PM
Planungskosten
Projektgründung, Wirtschaftlichkeitsprüfung,
Strukturplanung, Aufwandsabschätzung, Terminplanung,
Kostenplanung etc.
Überwachungskosten
Stundenkontierung, Netzplanaktualisierung,
Kostenerfassung, Fortschrittskontrolle, Qualitätssicherung etc.
Verfahrenskosten
Verfahrensabwicklung, Anwenderunterstützung, Projektführungssysteme, PC-Einsatz
etc.
Beachte: Normalerweise PM-Kosten getrennt von
Konfigurationsmanagement, Dokumentationsmanagement und
Qualitätssicherung
68
Prozentualer PM-Kostenanteil
Grobe Regeln:
kleine Projekte: 8%
mittlere Projekte: 4%
große Projekte: 2%
69
PM-Kosten und Projektkosten
70
1.8 Summary
Management
• Wissen
• Wollen
• Entscheiden
• Durchsetzen
Erfolgreiche Anwendung
des Projektmanagements
Mitarbeiter
• Zielvorgaben
• Problembewusstsein
• Know-How
• Unterstützung
71
Projektmanagment
Erster Überblick über die Vorlesung
1.
Einleitung
2.
Faktor Mensch
3.
Teamworking und Kommunikation
Interviewtechniken
Zeitmanagement
Konflikte und Problemlösungstechniken
Moderations- und Kreativitätstechniken
Projektinitiierung
Gründung eines Projekts
Wirtschaftlichkeitsbetrachtung
Produkt-/Systemdefinition
72
Projektmanagment
4. Schätzverfahren und Projektplanung
Schätzverfahren
Projektplanung
5. Projektstrukturen und Personalaktivitäten
Einleitung
Projektfunktionen
Aufgabenträger
Organisationsformen, Unternehmensstrukturen und Projektstrukturen
73
Projektmanagment
6.
Projektkontrolle
7.
Projektrisiken und Risikomanagement
Konfigurations- und Versionsmanagement
Fortschrittskontrolle
Change-Management
Kostenkontrolle
Projektabschluss und Prozessverbesserung
Prozessverbesserung
Projektabschluss
74
So nicht …
Aus dem Projektalltag . . .
Wir haben keine Zeit, über die Arbeit nachzudenken, nur genug, um sie zu
machen. (DeMarco/Lister)
WIR sind schon jahrelang im Geschäft. Bevor Sie Ihre ganze Planerei
abgeschlossen haben, ist bei uns schon die Hälfte des Codes fertig.
Jemand dachte, daß ein anderer irgend etwas tun würde (...)
Projektmanagement können wir: Wir waren schon immer in der Lage, zum
Telefon zu greifen und uns kurzfristig abzustimmen.
75
So nicht …
Zitate
Bei uns gibt es keine Projekte …
Das machen wir schon, aber anders …
Zu aufwendig, zu bürokratisch
Dafür haben wir jetzt keine Zeit
Das ist nur in großen Projekten anwendbar
Wir brauchen einen VW, keinen Mercedes
Das geht nur in militärischen Projekten und Organisationen, unsere Mitarbeiter
brauchen Freiräume …
Bisher waren wir auch ohne Projektmanagement erfolgreich…
Wir haben nur technische Probleme …
Wir warten, bis es bessere Verfahren / Werkzeuge gibt …
76
Projektmanagment
1.
Einleitung
2.
Faktor Mensch
3.
Interviewtechniken
Zeitmanagement
Projektinitiierung
77
Projektmanagment
6.
Projektkontrolle
7.
Change-Management
Kostenkontrolle
Prozessverbesserung
Projektabschluss
78
Kapitel 2:
Faktor Mensch
Interviewtechniken
Zeitmanagement
79
80
2. Faktor Mensch
Ausgangssituation
„The major problems of our work are not so much technological
as sociological in nature“ (DeMarco/Lister: Peopleware, 1999)
Kernprobleme bei Projekten sind praktisch immer „Politik“:
Probleme zwischen Mitarbeitern und Projektleiter (u.U.)
Probleme zwischen Projekt und Auftraggeber/Benutzer
Teamdynamik stimmt nicht
Hohe Fluktuation
Mangelnde Fähigkeiten der Beteiligten
81
2. Faktor Mensch
Produktivitätsvarianzen:
Beste Mitarbeiter um Faktor 10 besser als schlechteste
Beste Mitarbeiter um Faktor 2,5 besser als Durchschnitt
Überdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittliche
Unabhängig von Leistungsmetrik:
Anzahl der Fehler
Kalenderzeit bis Meilenstein
Funktionspunkte pro Zeiteinheit
82
2. Faktor Mensch
Fluktuation
Fluktuationskosten:
Durchschnittliche Fluktuation (de Marco/Lister):
-
Fluktuationsrate: 33 - 80% pro Jahr
Verweildauer: 15 Monate bis 36 Monate
Fluktuationsaufwand:
-
Einstellungskosten: ca. 2 Personenmonate
Unproduktive Phase: ca. 3 bis 5 Personenmonate
Relative Kosten (bei 2 Jahren): 20%
Gründe für Fluktuation:
Durchgangsstation: Firmenatmosphäre lädt nicht zu langfristigem Engagement ein
Ersetzbarkeitsgefühl: Management betrachtet Mitarbeiter als austauschbare Ressource
Bezugsmangel: Mitarbeiter haben keinen Bezug zum Unternehmen
83
Kapitel 2:
Faktor Mensch
Interviewtechniken
Zeitmanagement
84
2. Faktor Mensch
2.1 Teamworking und Kommunikation
Der Faktor Mensch ist in SW-Projekten sehr groß,
deswegen:
Wähle die richtigen Leute aus
Betraue die richtigen Mitarbeiter mit den richtigen Aufgaben
Motiviere die Mitarbeiter
Helfe den Teams durchzustarten und abzuheben
Alles andere sind „Administrivalitäten“
85
2. Faktor Mensch
Ursachen für Schwierigkeiten
Mangelnde Kommunikation mit Kunden
Mangelnde Kommunikation mit Kollegen
Mangelnde Kommunikation mit Vorgesetzten
Mangelnde Kommunikation mit Stakeholdern
Unklare Kommunikationswege
Der Kunde als Feinbild
Mit der Dauer des Projekts sinkt die Motivation
Endlose Meetings
Zu viel Kontrolle
Zu wenig Kontrolle
Unrealistische Ziele
¾ Worst-Case: „Team-Selbstmord“
86
2. Faktor Mensch
Gegenmaßnahmen
Defensives Management
Situation:
-
Das Management traut sich weder Entscheidungen selbst zu treffen noch die Verantwortung dafür
zu delegieren.
Gegenmaßnahme:
-
Den Mitarbeitern erlauben, ihre eigenen Entscheidungen zu fällen, auch wenn sie Fehler machen.
Jemand die Freiheit zu geben, Fehler zu machen, ist ein Zeichen von Vertrauen.
Bürokratie
Situation:
-
Das Management gibt genau vor, was und wie zu dokumentieren ist.
Gegenmaßnahme:
-
Dem Team zu erlauben, den Grad der Dokumentation selbst zu wählen. Dokumentation ist eine Art
der Kommunikation. Diese muss von den Beteiligten gestaltbar sein.
87
2. Faktor Mensch
Gegenmaßnahmen
Verteiltes Team
Situation:
-
Das Team ist auf mehrere Standorte bzw. Zimmer verteilt.
Gegenmaßnahme:
-
Schaffen Sie Kommunikations-Events wie zum Beispiel ein gemeinsames Projektfrühstück, einen
gemeinsamen Wochenstart, »Stehempfang« zu Anlässen wie Geburtstagen oder Meilensteinen.
Häufige Unterbrechungen
Situation:
-
Die Teammitglieder haben zu viele projektexterne Zuständigkeiten. Sie arbeiten noch in anderen
Projekten mit oder sind für viele Querschnittsaufgaben in der Firma verantwortlich. Die Telefone
läuten zu oft und die Mailboxen laufen voll wegen nicht projektrelevanter Angelegenheiten.
Gegenmaßnahme:
-
Umverteilen der nicht projektrelevanten Tätigkeiten. Umleiten von Anrufen und Weiterleitung von
Mails.
88
2. Faktor Mensch
Gegenmaßnahmen
Angeordnete Qualitätsreduktion
Situation:
-
Aufgrund von finanziellem oder zeitlichem Druck soll an der Qualität gespart werden. Die Selbstachtung eines
Entwicklers leidet, wenn er gezwungen wird, ein Produkt mit geringerer Qualität herzustellen, als er eigentlich
dazu in der Lage ist.
Gegenmaßnahme
-
Erlauben Sie nicht, dass Kostenreduktion zu Qualitätsreduktion führt, sondern streichen Sie besser einige
Funktionen. Appellieren Sie an den Stolz der Entwickler.
Unrealistische Termine
Situation:
-
Nicht haltbare Termine entstehen, wenn die Herleitung des Termins ausschließlich außerhalb des
Projektteams passiert und alleine von projektexternen Ereignissen abhängt, wie Messetermine,
Marketingpläne, Vorstellungen der Geschäftsleitung etc.
Gegenmaßnahme:
-
Enge Terminpläne sind oft notwendig und können auch eine Herausforderung sein. Jedoch ist es ein Leichtes
für ein Team, unrealistische fremdbestimmte Termine zu erkennen. Jeder Termin muss mit dem Team
besprochen und eingeordnet werden (unrealistisch, fremdbestimmt, realistisch, notwendig etc.).
89
2. Faktor Mensch
Gegenmaßnahmen
Unbekannte und ungenutzte Gruppendynamik
Situation:
-
Manager steuern Projekte häufig zu stark über bilaterale rollenbezogene Gespräche mit einzelnen
Mitarbeitern. Sie scheuen die Konfrontation mit dem ganzen Team. Dass im Team positive oder
negative Initiativen entstehen und sich etablieren, bekommen die Manager nicht mit.
Gegenmaßnahme:
-
Eine gut abgestimmte Mischung von bilateralen rollenbezogenen Gesprächen und Teammeetings,
Workshops und Events hilft die interessanten Initiativen im Team zu erkennen und zu unterstützen
bzw. diesen entgegenzuwirken.
90
2. Faktor Mensch

Teamaufbau
Charaktere, die eine genügende Portion an Erfahrung mitbringen, die nicht nur alles wissen,
sondern auch vieles können und zueinander passen.
Mitarbeiterprofile
Wissen: z.B. durch Vorlesung, Buch, Seminar
Können: Wissen anwenden können
Erfahrung: Einsatz des Wissens als Könner in früheren Projekten
Ideal:
Mitarbeiterprofil oder Skill-Datenbank mit
-
Zu jedem Projekt genaue Stellenbeschreibung
Qualifikationen (bzgl. Wissen, Können, Erfahrung)
Liste der Rechten und Pflichten, z.B. bestimmte Dokumente einsehen, bearbeiten, an Meetings teilnehmen,
informiert werden, koordinieren,…
91
2. Faktor Mensch
Software Engineering Body of Knowledge
Kriterien, die das Wissen, das Können und die Erfahrung von Mitarbeitern
festhalten hängt davon ab, welches die wichtigen Know-how-Felder in der Firma
sind.
Eine Anregung für eine Gliederung der möglichen Know-how-Felder kann der so
genannte »Software Engineering Body of Knowledge« (Software Engineering
Body of Knowledge), kurz »SWEBOK«, geben (www.SWEBOK.org).
Diese Gliederung der Themenwelt des Software Engineerings wurde von einem
internationalen Firmengremium (SAP, Boeing u.a.) unter der Leitung der IEEE
(www.computer.org) erarbeitet und dient als Grundlage vieler Ausbildungsgänge
und Studiengänge.
92
93
94
2. Faktor Mensch
Process Communication Model
Wird in größeren Unternehmen in mehr als 20 Ländern eingesetzt, z.B. NASA für
Astronautenteams
Wird verwendet um Team hinsichtlich Kommunikationsfähigkeit
zusammenzustellen.
6 Charaktere
Träumer
Workaholic
Widerständler
Revolutionär
Bewahrer
Befürworter
Jeder läßt sich anders (de-)motivieren,…
Ideal ist es wann keiner der Charaktere zu häufig vertreten ist
95
2. Faktor Mensch
PCM-Typ
Charakter
Motivation
Demotivation
Reaktion
Träumer
einfallsreich,
nachdenklich, ruhig,
introvertiert, leicht zu
führen
schätzt Einsamkeit
und braucht viel Zeit
zum Überlegen, um
kreativ zu sein, wird
durch Incentives und
Personen motiviert
unruhige Umgebung,
Führungslosigkeit
Aufgaben werden
nicht fertig; Rückzug
vom
Tagesgeschehen
Workaholic
logisch denkend,
verantwortungsvoll,
organisiert, Zeitgetrieben
Anerkennung von
Leistung,
Schulterklopfen,
Bonus, Incentives,
logische
Argumentation
wenn es zu
persönlich wird, wenn
Argumente fehlen,
Need-to-KnowPrinzip
Kritik, Frustration,
Beschwerden bzgl.
Geld, Fairness und
anderen Mitarbeitern
Widerständler
freundlich, sensibel,
mitfühlend,
Gefühlsgetrieben
eine angenehme
Umgebung, sowohl
bzgl. Räumlichkeiten
als auch Kollegen
auf Fehlern
herumreiten,
Selbstherrlichkeit
Sozialisierung mit
anderen,
Selbstzweifel, Kritik
96
2. Faktor Mensch
PCM-Typ
Charakter
Motivation
Demotivation
Reaktion
Revolutionär
spontan, kreativ,
verspielt, ausdrucksstark,
tatkräftig
ständiger Gedankenaustausch mit anderen,
persönlicher Kontakt,
Spaßfaktor
zeitliche
Einschränkungen,
Prediger
Opportunismus,
Beschwerden, Vorwürfe
Bewahrer
hingebungsvoll,
beobachtend,
gewissenhaft, hartnäckig,
bewerten durch
Meinungen anderer
Anerkennung von
Leistung, Kommittment
zu Zielen
Selbstherrlichkeit,
Machtspiele,
Neudefinitionen
Kreuzzüge,
Selbstgerechtigkeit,
verbale Attacken
Befürworter
anpassbar, überzeugend,
charmant, einfallsreich,
Aktions-orientiert
Risikobereitschaft, Geld
Unentschlossenheit,
Schwäche, Konfrontation
aufwendige
Argumentation, negative
Dramaturgie, Regelbruch
97
2. Faktor Mensch
Teamaufbau
Teambildung (nach DeMarco, Lister):
Auf gemeinsames Ziel ausrichten
Elitegefühl pflegen
Anerkennung verteilen
Qualität zum Kult erheben
Strategische anstatt taktischer Richtlinien
Erfolgreiche Teams erhalten
Teamverhindernde Faktoren:
Kontrolle statt Vertrauen
Räumliche Trennung
Aufsplitterung auf mehrere Projekte
Qualitätsreduktion
98
2. Faktor Mensch
Entwicklungsphasen eines Teams
Ke
in
N
Te eue
am
m
itg
lie
de
r
A
be
ga
f
u
Ko
ns
en
s
ng
ru
e
nd
nä
99
2. Faktor Mensch

Initialphase
Projektziel, die Aufgaben der einzelnen Projektmitglieder und die Zusammenarbeit werden
definiert.
Teammitglieder finden heraus, was sie tun werden.
Führungsstil wird klar
Arten der zwischenmenschlichen Kommunikation und Aufgabenteilung wird klar
¾ Diese Phase ist geprägt von Wohlwollen, Höflichkeit, Missverständnissen und Vorsicht.

Konfrontationsphase
Jetzt werden Diskussionen über verschiedene Ansätze geführt,
Meinungsstreite werden ausgetragen und die Rollen festgelegt.
Teammitglieder fangen an, sich gegen Gruppenzwänge zu wehren.
¾ Es herrscht Anspannung, man ist kritisch und Konfrontationen stehen auf der Tagesordnung.

Organisationsphase
Gruppenregeln werden ausgehandelt,
die Arbeitsweise festgelegt und das weitere Vorgehen bestimmt.
Die Widerstände sind überwunden.
Es etablieren sich Regeln und Teamstandards.
Teamzugehörigkeit entsteht.
¾ Der Alltag ist geprägt von Engagement und Kooperationsbereitschaft.

Arbeitsphase
Basis geschaffen für konstruktive Zusammenarbeit.
Das Team konzentriert sich auf die Erledigung der Aufgaben.
Die Diskussionen über zwischenmenschliche Beziehungen, Rollen und Aufgabenverteilung
sind Vergangenheit.
¾ Kreativität, technischen Herausforderungen und Gewissenhaftigkeit.
100
2. Faktor Mensch
Grundregeln der Teamarbeit
Anerkennung geben, Beiträge fordern
gemeinsam handeln
eigene Meinung offen äußern
Ziele im Auge behalten
Konflikte ausdiskutieren
aufmerksam zuhören
Kritik akzeptieren
101
2. Faktor Mensch
Wichtiger Aspekt für das Management eines Teams ist die
praktizierte Meeting-Kultur:
Nie ohne Agenda ein Meeting beginnen
Nie zu spät zu einem Meeting kommen
Nie ein Meeting ohne Rollendefinition durchführen (Moderator etc.)
Nie ein Meeting ohne Protokoll veranstalten (Wort- oder Ergebnisprotokoll)
Nie ein Meeting zeitlich überziehen
102
2. Faktor Mensch
Weitere Kommunikationsplattformen für ein Team:
Projekt-Mailingliste
Projekt-Website
Projektportal
Projektfrühstück
Projektstammtisch
Projekt-Kaffee-Ecke mit Espresso-Maschine
Projektparty
Kamingespräch mit Kunden
etc.
¾ Weiterentwicklung des Teams
¾ Schulung, Entwicklungsplan,… → Motivation
103
2. Faktor Mensch
Teamclosing - Feedback-Workshop:
Was war gut?
Was war weniger gut?
Wann ging was schief?
Warum ging was schief?
Welche Merksätze kann man daraus ableiten?
Gibt es offene Verbesserungsvorschläge?
Analyseschritte:
Analyse der projektrelevanten Mails
Was war wann Tagesgespräch im Projekt?
Analyse der Historie der Offenen-Punkte-Liste
¾ Prozessverbesserungen und Merksätze für die nächsten Projekte
(siehe auch Projektabschluss)
104
2. Faktor Mensch
Führungsqualitäten eines Projektleiters ist die emotionale Intelligenz.
Sie beruht auf fünf Elementen:
Selbstwahrnehmung,
Eigenmotivation,
Selbstregulierung,
Empathie und
soziales Engagement.
Mit anderen Worten: Ein guter Projektleiter verfügt über
Eigeninitiative,
Entscheidungsfreudigkeit,
Durchsetzungskraft,
Delegationsbereitschaft und
Einfühlungsvermögen.
Er/Sie ist konsequent und kann seine MitarbeiterInnen motivieren.
105
2. Faktor Mensch
Führungswerkzeuge
»Wenn du ein Schiff bauen willst, dann trommle nicht Männer zusammen,
um Holz zu beschaffen, sondern lehre sie die Sehnsucht nach dem weiten
endlosen Meer.«
Antome de Saint-Exupery
Visionen
Unser Verhalten wird von Visionen bestimmt. Die Sehnsucht nach dem weiten endlosen Meer kann oft
mehr bewirken als die beste Handlungsanweisung. Ebenso wird unser Projektalltag von Visionen geprägt.
Vorbilder
Vorbild sein in Tugenden wie Pünktlichkeit, Fairness, kommunikativ sein, Anteil nehmen etc., aber nicht in
Tätigkeiten: Führungskräfte müssen das aufgeben, was sie zur Führungskraft gemacht hat.
Delegation
Die Ziele bestimmt der Chef, die Wege bestimmen die Mitarbeiter. So kann der Manager den Überblick
behalten und muss sich nicht in Details verlieren. Richtiges Delegieren ist die beste Motivation.
Motivation
Wir können andere Menschen nicht motivieren, wir können ihnen nur helfen, sich selbst zu motivieren. Das
heißt, die Führungskraft muss die eigenen Ziele zu den Zielen der Mitarbeiter machen.
Lob
Leistung, die nicht anerkannt wird, wird nicht beibehalten. Leistung, die anerkannt wird, wird beibehalten.
Ein Lob muss zeitlich nah zum auslösenden Moment erfolgen, dann entfaltet es seine größte Wirkung.
Tadel
Durch Tadel darf kein Stress oder Druck entstehen. Menschen unter Druck denken nicht schneller.
Richtiger Tadel erfordert eine disziplinierte Gesprächsführung
106
2. Faktor Mensch
2.4 Konflikte und Problemlösungstechniken
Zusammenfassung
Der »Faktor Mensch« ist in Softwareprojekten der wichtigste Faktor. Demnach ist
die Auswahl der Teammitglieder eine der kritischen Tätigkeiten der Projektleitung.
Die Teamentwicklung sollte nicht dem Zufall überlassen werden, sondern über
bewusstes Team-Building, Team-Managing, Team-Developing und Team-Closing
gesteuert werden.
Die Anforderungen an einen Projektleiter sind sehr vielfältig. Um all diesen
gewachsen zu sein, sollte jeder Projektleiter eine Menge von
Führungsgrundsätzen, Führungswerkzeugen und Gesprächsstrategien
beherrschen.
107
Kapitel 2:
Faktor Mensch
Interviewtechniken
Zeitmanagement
108
2. Faktor Mensch
2.2 Interviewtechnik
Wann werden Interviewtechniken verwendet:
Bewerberverfahren
Auswahlentscheidungen
Kundenanforderungen
….
Beispiel hier: Bewerberauswahl!
109
2. Faktor Mensch
Stellenbezogenen Anforderungskriterien
Persönliche und fachliche Anforderungen Grundlage für Auswahlverfahren.
Tätigkeitsgebiet einer Stelle in mehrere Anforderungen
fachlicher und
persönlicher (überfachlicher) Art
unterteilen.
Auswahlinterview sollen
fachlichen („Erfahrungen" und „Kenntnisse) als auch die
persönlichen Anforderungen („Fähigkeiten" )
intensiv abgefragt werden.
"Muß-Anforderungen .
Suchen Sie Anforderungen, die in typischen Situationen in der betreffenden Stelle gestellt werden und
deren zugrundeliegende Fähigkeiten vorhanden sein müssen.
Definieren Sie die wichtigsten fachlichen und persönlichen Anforderungen für die Stelle.
Beschreiben Sie typische Tätigkeiten oder Verhaltensweisen, die jeder Anforderung zugrundeliegen.
Gewichten Sie die Anforderungen.
110
2. Faktor Mensch
Fähigkeiten können sein
Lernfähigkeit
Kreativität
Teamfähigkeit
Ergebnisorientierung
Kundenorientiertung
Kommunikationsfähigkeiten
Durchsetzungfähigkeit
Motivationsfähigkeit
Strategisches Denken
Initiative
Veränderungsfähigkeit
Networking Skills
Einfühlungsvermögen
Analysefähigkeiten
Planungs- und Organisationsgeschick
Mobilität
Interkulturelles Verhalten
…
111
2. Faktor Mensch
Typische Probleme von Auswahlentscheidungen
Wichtige Informationen werden übersehen
Die gleichen Themen werden mehrmals in den Interviews behandelt
Die Informationen des Bewerbers werden vom Interviewer falsch interpretiert
Vorurteile und Klischees beeinflussen die Beurteilung
Die Interviewer machen sich nicht genug Notizen
Die Interviewer treffen voreilige Entscheidungen
Die Beurteilungsdiskussion der Interviewer ist nicht systematisch
Die Interviewer lassen sich bei ihrer Einschätzung von einem einzigen Kriterium
leiten
Der Druck zur schnellen Besetzung der Stelle führt zu verfrühten Entscheidungen
Die Vorstellungen und Wünsche des Bewerbers werden nur unzureichend
beachtet
¾ Interviewtechniken notwendig
112
2. Faktor Mensch
Wahrnehmungsverzerrungen
Wertungsfreie, objektive Beobachtung gibt es nicht.
Mensch sieht die Welt durch verschiedene „Filter", die ihn davon abhalten, mit
neutralen Augen zu beobachten.
Stimmungen, Vorurteile, vorgefasste Meinungen
Die Persönlichkeit des Interviewers, sein Erfahrungshintergrund, seine momentane Stimmungslage sowie
bestehende Vorurteile beeinflussen die Wahrnehmung und Beurteilung der Kandidaten.
Beispiel Vorurteil: Menschen mit Brille gelten als intelligenter.
Beispiel Erfahrungshintergrund: Ein Kandidat kommt aus einer bestimmen
Hochschule - er ist grundsätzlich geeignet.
Erster Eindruck
Problem: ersten Eindruck oft entscheidend.
Urteil über eine Person häufig bereits in den ersten 4 Minuten gefällt wird.
Beispiel: Der Kandidat erscheint zu spät
Urteil: Diese Person ist unzuverlässig.
113
2. Faktor Mensch
Sympathie/Antipathie - Ähnlichkeit/Fremdheit
sympathisch erscheinende Menschen positiver,
Sympathie nichts anderes als eine wahrgenommene Ähnlichkeit (Auftreten,
Persönlichkeit, gleicher Studienort).
Beispiel: Ein Kandidat, der den Interviewer an eine unsympathische Person erinnert,
kann schlechter beurteilt werden.
Halo-Überstrahlungseffekt
Blendung durch auffälligen Merkmal, das alles andere überstrahlt und so frühzeitig zu
einer globalen Beurteilung verleitet. Aus dieser globalen Beurteilung werden eine ganze
Reihe von Eigenschaften und Merkmalen implizit abgeleitet.
Beispiel: Unattraktiven Kandidaten werden eher negative soziale Eigenschaften
zugeschrieben. Extrovertierte, rhetorisch gewandte Kandidaten gelten als intelligenter.
Ermüdungs-Effekt
Mit steigender Anzahl der Kandidaten werden die Aussagen immer weniger zuverlässig.
114
2. Faktor Mensch
Reihenfolgeeffekt/Kontrasteffekt
Die Beurteilung hängt vom Zeitpunkt und der Reihenfolge der Informationen ab, die er
über einen Kandidaten erhält.
Beispiel: zuerst etwas Negatives und dann erst etwas Positives erfahren→ negativeres
Bild .
Persönliche Eignungstheorie
Der Interviewer hat eine eigene Meinung oder Theorie über geeignete bzw. ungeeignete
Verhaltensweisen in bestimmten Situationen (z.B. welche Verhaltensweisen eine
Führungskraft zeigen/über welche Fähigkeiten sie verfügen sollte). Diese
Meinung/Theorie beeinflusst Wahrnehmung und Bewertung.
Beispiel: Der Kandidat trägt weiße Tennissocken. → Führungskraft nicht geeignet.
115
2. Faktor Mensch
Tipps zur Reduzierung der Fehlerquellen
Schaffen Sie eine offene und vertrauensvolle Atmosphäre ("small talk" zum
Einstieg, Positives zum Lebenslauf u.a.).
Betonen Sie das gemeinsame Interesse.
Mit einem Bewerbern sollten immer mehrere Interviewer sprechen (Mehr-AugenPrinzip).
Überdenken der eigenen Urteilsbildung (Selbstreflexion): Wie reagiere ich auf
bestimmtes Verhalten, welche Ansprüche habe ich, mit wem vergleiche ich...?
Diskussion der Interviewer in der Interviewkonferenz über Eindrücke und Urteile.
Wichtige Regel: Jeder Eindruck muss mit konkreten Aussagen und/oder
konkretem Verhalten des Bewerbers begründet werden!
Halten Sie sich an Ihren Interviewleitfaden, so dass Sie systematisch die
Anforderungen abklopfen und nicht zu früh Ihr Urteil bilden.
Wenden Sie die verhaltensbezogene Fragetechnik an:
¾ Situation/Aufgabe - eigenes Verhalten - Ergebnis
116
2. Faktor Mensch
Die „Ehre des Bewerbers “
Gut Zuhören können.
Unterbrechen des Bewerbers nur in Ausnahmesituationen,
Nicht in „Prüfungsstil" verfallen.
Das Provozieren des Bewerbers hilft nicht weiter.
Unterstellungen lassen den Bewerber defensiv werden.
Heikle Themen nur dann weiter erörtern, wenn es für die Stelle unbedingt
erforderlich ist.
Dem anderen vertrauen. Misstrauen zerstört das Gespräch.
Für die Antworten genug Zeit lassen.
Gesprächspausen zulassen.
Eine angemessene Körpersprache zeigen.
¾ Partnerschaftlicher Umgang!!
117
2. Faktor Mensch
Frageformen
Geeignete Fragen:
„W“-Fragen
Offene Fragen
Beispiele:
-
„Wie würden Sie eine Aufwandsabschätzung durchführen?"
„Warum sind Sie so vorgegangen?„
Weniger geeignete Fragen
Suggestivfragen
Ja-Nein-Fragen
Theoretische Fragen
Beispiele:
-
"Sie haben doch sicher schon einmal eine Budgetplanung gemacht?"
"Wenn Sie eine ISDN-Anlage installieren, würden Sie das wirklich ohne Anleitung versuchen?"
118
2. Faktor Mensch
Fragetechnik - Verhaltensdreieck
Situation
Vorgehen
Ergebnis
119
2. Faktor Mensch
Fragetechnik – Verhaltensdreieck
Den Interviews liegt das Prinzip des Verhaltensdreiecks zugrunde.
Der Bewerber soll eine Situation schildern, in der er eine bestimmte Tätigkeit das
letzte Mal verrichtet hat und dann sein Vorgehen und das daraus resultierende
Ergebnis. Der Interviewer fragt bei Ungenauigkeiten immer wieder tiefer nach.
Den Fragen liegen Situationsbeschreibungen, zugrunde, die für die betreffende
Stelle typisch und z.T. auch kritisch sind.
Die Fragen beziehen sich auf die Vergangenheit und lassen auf zukünftiges
Verhalten schließen. Sie messen Persönlichkeits-kompetenzen und
Aufgabenkompetenzen.
Im Idealfall hat man vor dem Bewerbungsgespräch bereits Antworten formuliert,
die sehr gutes und nicht erwünschtes Verhalten in der entsprechenden Situation
beschreiben. So fallen nach dem Gespräch Interpretation und Auswertung
leichter und werden objektiver.
120
2. Faktor Mensch
Beispiele
Teamfähigkeit
Beschreiben Sie eine Situation, in der Sie die Teamarbeit entscheidend weiterbringen
konnten. Was war die Ausgangslage?
Was habe Sie unternommen?
Was war das Ergebnis
Budgetplanung
Wann haben Sie die letzte Budgetplanung gemacht?
Wie sind Sie dabei vorgegangen?
Wie war das Ergebnis?
121
2. Faktor Mensch
Übung!!!
122
Kapitel 2:
Faktor Mensch
Interviewtechniken
Zeitmanagement
123
2. Faktor Mensch
2.3 Zeitmanagement
Problem:
Projekte im Rahmen der vorgegebenen
Zeit,
Kosten und
Leistung/Qualität durchzuführen.
Alltag besteht aus
zahlreichen Sitzungen,
Verfassen von Berichten,
Lösung von Konflikten,
Planung und Neuplanung,
Kommunikation mit dem Kunden und
aus Krisenmanagement…
¾ Zeitmanagement notwendig
124
2. Faktor Mensch
2.3 Zeitmanagement
Die folgenden Fragen sollten Managern dabei helfen,
Problembereiche zu erkennen:
Ist es ein Problem, die Arbeit bis zum geplanten Endtermin fertig zu stellen?
Mit wie vielen Unterbrechungen pro Tag ist zu rechnen?
Haben Sie schon ein Verfahren entwickelt, um mit den Unterbrechungen
umzugehen?
Wenn Sie einen größeren ununterbrochenen Zeitraum benötigen, steht dieser
überhaupt zur Verfügung? Mit oder ohne Überstunden?
Wie gehen Sie mit unangemeldeten Besuchern und Anrufen um?
Wie behandeln Sie eingehende Post?
Haben Sie bestimmte Vorgehensweisen zur Abwicklung von Routinetätigkeiten
entwickelt?
Wie schwierig ist es für Sie, nein zu sagen?
Wie gehen Sie mit Kleinarbeiten um?
125
2. Faktor Mensch
2.3 Zeitmanagement
Zeitdiebe
Unvollständige Arbeiten
Aufgaben, die doppelt ausgeführt
Eingehende Anrufe, Briefe und E-Mails
Zuständigkeiten sind unzureichend definiert und es fehlt
die angemessene Kompetenz
Änderungen ohne direkte Benachrichtigung/ Erklärung
Wartezeiten, z.B. durch verspätete Mitarbeiter
Unfähigkeit, zu delegieren, oder unkluge Delegation
Mangelhaftes System zur Informationsgewinnung
Mangel an Informationen, die direkt eingesetzt werden
können
Tägliche Verwaltungsarbeiten
Beschwerden der Gewerkschaft
Zu viele Review-Ebenen
Der Plausch im Büro
Fehlplatzierte Informationen
Prioritätenwechsel
Unentschlossenheit
Verzögerungen
Treffen von Verabredungen
Zu viele Sitzungen
Die Überwachung delegierter Tätigkeiten …
…
Unklare Rollen-/Stellenbeschreibungen
Einmischung durch die Unternehmensführung
Die Anforderung, am Budget festzuhalten
Schlecht ausgebildete Kunden
Nicht genügend erprobte Manager
Das Fehlen einer Stellenbeschreibung
Zu viele Personen sind an unwichtigen Entscheidungen
beteiligt
Mangelndes Fachwissen
Mangelnde Kompetenz, Entscheidungen zu treffen
Dürftige Statusberichterstattung Arbeitsüberlastung
Unvernünftige Zeitvorgaben
Zu viel Reisetätigkeit
Fehlen der passenden Projektmanagement-Tools
Jede Abteilung will den »schwarzen Peter« an andere
weitergeben
Unternehmensrichtlinien
Widersprüchliche Anweisungen
Bürokratische Hindernisse (»Ego«)
Linienmanager, die sich ihr eigenes Reich aufbauen
Mangelnde Kommunikation …
126
2. Faktor Mensch
2.3 Zeitmanagement
To-Do-Liste
127
2. Faktor Mensch
2.3 Zeitmanagement
Persönlicher Tagesplaner
128
2. Faktor Mensch
2.3 Zeitmanagement
Effektives Zeitmanagement (PM)
Delegieren
Den Ablauf- und Terminplan einhalten
Schnell entscheiden
Entscheiden, wer sich darum kümmern soll
Lernen, nein zu sagen
Sofort beginnen
Den schwierigsten Teil zuerst erledigen
Reiseunterbrechungen zum Arbeiten nutzen
Nutzlose Mitteilungen vermeiden
Unwichtige Arbeiten ablehnen
Vorausschauen
Fragen: Ist die Reise wirklich nötig?
Die eigene Energiekurve kennen
Telefon- und E-Mail-Zeiten steuern
Eine Tagesordnung für Sitzungen versenden
Verzögerungen überwinden
Den Führungsstil »Management by Exception« anwenden
129
2. Faktor Mensch
2.3 Zeitmanagement
Regeln für das Zeitmanagement
Durchführung einer Zeitanalyse (Zeitprotokoll)
Planung fester Zeiten für wichtige Dinge
Klassifikation der Aktivitäten
Prioritäten aufstellen
Opportunitätskosten für die verschiedenen Aktivitäten aufstellen
Das System trainieren (Chef, Mitarbeiter, Kollegen)
Delegieren
Dinge absichtlich ablehnen
Führung nach dem Ausnahmeprinzip praktizieren
Ausrichtung auf Möglichkeiten, nicht auf Probleme
Fragen
Welche meiner Tätigkeiten können eigentlich ganz wegfallen?
Welche meiner Tätigkeiten kann eine andere Person besser erledigen?
130
Kapitel 2:
Faktor Mensch
Interviewtechniken
Zeitmanagement
131
2. Faktor Mensch
Konflikte können Todesurteil für Projekt sein
Konflikte entstehen
Durch unterschiedliche Ziele und Wertevorstellungen
Missverständnisse
Antipathie
Rivalität
Mobbing
Zukunftsängste
Erfolgslosigkeit
132
2. Faktor Mensch
Phasen eines Konflikts
Diskussion
Am Anfang steht meistens eine Sachfrage, an der sich unterschiedliche Meinungen und
Interessen festmachen.
Überlagerung
Im Verlauf der Diskussion werden Argumente der anderen Seite nicht mehr akzeptiert.
Man unterstellt letztlich immer Unaufrichtigkeit. Die Sachebene wird zunehmend von der
Beziehungsebene überlagert.
Eskalation
Die andere Seite reagiert mit Empörung auf die unterstellte mangelnde Integrität und
geht zum Gegenangriff über. Der Konflikt eskaliert, Emotionen beherrschen die Szene.
Verhärtung
Wenn der Konflikt nicht entschieden werden kann, kühlen sich die Emotionen
zunehmend ab und man tritt in eine Phase des kalten Kriegs ein. Der Konflikt wird
chronisch.
133
2. Faktor Mensch
Konfliktlösungsdreieck
134
2. Faktor Mensch
Konfliktlösung - Verhaltensdreieck
Situation
Vorgehen
Ergebnis
135
2. Faktor Mensch
„Problemfall“ Mensch im Projekt:
Menschen schätzen keine Veränderungen und versuchen sie zu ignorieren
136
2. Faktor Mensch
Managementaufgaben
Menschen wollen produktiv sein:
Was habe ich davon? Was kostet es mich?
Was kann ich machen? Was muss ich machen?
Erfolgreiche Projektarbeit braucht Transparenz und Realismus:
Klare und realistische Ziele aller Beteiligten: Motivation
Klare und angemessene Verantwortlichkeiten aller Beteiligten: Delegation
Transparenz schaffen:
Verantwortungen delegieren:
-
Delegation: Verantwortungen (für Betroffene) bewusst machen
Motivation: Verantwortlichkeiten übertragen
Unklarheiten identifizieren
-
Delegation: Verantwortliche identifizieren
Motivation: Ziele (für Projektleitung) bewusst machen
Kooperation motivieren: für Betroffene Gewinnsituation bewusst machen
Konflikte adressieren:
-
Delegation: Verantwortliche informieren
Motivation: Ziele identifizieren
137
2. Faktor Mensch
Kooperation motivieren
Kooperation motivieren:
Engagement entsteht durch Wollen, nicht durch müssen
Mangelnde Motivation führt zu Blockierhaltung
Nach Außen: Ziele und Erwartungen aller Verantwortlichen identifizieren
Nach Innen: Ziele und Erwartungen identifizieren, Mitarbeiter gleichwertig integrieren
Nach Innen: Die Parkplatzfalle (Unproduktiver Mitarbeiter im Projekt):
Blockaden identifizieren (Was passt nicht?)
Integrieren statt regieren (Projektleiter steht nicht über dem Team)
Nach Aussen: Die Querulantenfalle (Bereichleiter sabotiert)
Ängste wahrnehmen
Gemeinsamen Profit identifizieren
In Planung und Umsetzung miteinbeziehen
138
2. Faktor Mensch
Verantwortung delegieren
Verantwortung delegieren:
Mangelnde Verantwortung führt zu mangelnder Motivation
Übertriebene Verantwortung führt zu übertriebenem Risiko
Verantwortung des Projektmanagers:
Nach Aussen: Übernahme von Verantwortung für die erfolgreiche Projektdurchführung
gegenüber Management
Nach Innen: Übergabe von Verantwortung für die erfolgreiche Aufgabendurchführung an
die Projektmitarbeiter
Delegation nach Außen:
Entscheidungsarthrose (Verzögerte Entscheidungen):
-
Dokumentieren: Wer muss bis wann welche Entscheidung treffen?
Dokumentieren: Was passiert, wenn die Entscheidung nicht getroffen wird?
Einfordern: Entscheidungsspielräume (Budget, Führungsverantwortung)
139
2. Faktor Mensch
Verantwortung delegieren
Delegation nach Außen:
Tyrannosauruseffekt (Neue Anforderungen durch Management):
-
Dokumentieren: Welche Konsequenzen haben Entscheidungen (Budget, Laufzeit, Qualität,
Quantität)?
Delegieren: Welche Entscheidung wurden getroffen?
Delegation nach Innen:
Fachexpertenfalle (Projektleiter trifft alle Entscheidungen)
-
Klare Festlegung (technische) Verantwortung (auch Projektleiter)
Gesundes Vertrauen gegenüber Projektmitarbeitern
Sinnlose Sitzungen (Unproduktive Sitzungen)
-
Klare Verantwortung auch für Führungspersonen
Möglichkeit der Beteiligung der Betroffenen
140
2. Faktor Mensch
Unklarheiten identifizieren:
Unklarheiten lösen sich nicht von selbst
Unklarheiten führen zu Konflikten oder Demotivation
Die Optimismusfalle (Innovative Projekte scheitern)
Unklarheiten verursachen übertriebenen Optimismus (Pessimismus)
Realistische Einschätzungen gewinnen:
Optimistische, realistische, pessimistische Schätzungen
Referenzdaten gewinnen
Klare Leistungen verbindlich regeln
Sinnlose Sitzungen (Unproduktive Sitzungen):
Was soll in der Sitzung erreicht werden, was nicht?
Welche Aufgaben ergeben sich aus der Sitzung?
141
2. Faktor Mensch
Konflikte adressieren:
Ungelöste Konflikte hinterlassen Unklarheiten
Ungelöste Konflikte verursachen Demotivation
Die Sozialkompetenzfalle (Projekte werden durch soziale Spannungen
aufgehalten):
Spielregeln vereinbaren:
Wie wird abgestimmt?
Wie wird informiert?
Wie wird diskutiert?
Krisensituationen moderieren
Konflikte erwarten (Anzeichen erkennen)
Lösungen anstatt Schuldzuweisungen
142
2. Faktor Mensch
Konflikte adressieren
Nach Aussen:
Die Querulantenfalle (Bereichleiter sabotiert):
-
Bereichsleiter ansprechen und Motivationen erkunden
Die Ressourcenfalle (Keine Ausreichenden Ressourcen):
Fehlende Ressourcen rechtzeitig addressieren (mit Konsequenzen)
Nach Innen: Das Parkplatzsyndrom (Unproduktiver Mitarbeiter):
Mitarbeiter ansprechen und Motivationen erkunden
143
Kapitel 2:
Faktor Mensch
Interviewtechniken
Zeitmanagement
144
2. Faktor Mensch
2.4 Moderations- und Kreativitätstechniken
Grundsätze für den Moderator
nicht gegen die Gruppe ankämpfen
Störungen haben Vorrang
unterscheiden: Wahrnehmung, Vermutung, Bewertung
„ich“ – statt „man“
nonverbale Signale beachten
nicht bewerten und beurteilen
sich nicht rechtfertigen
nicht über die Methode diskutieren
145
2. Faktor Mensch
Aufgabe des Protokollanten
erfasst die Substanz simultan mit dem Prozess
erfasst „öffentlich“
vermeidet Manipulation bzw. Färbungen
dokumentiert nicht länger als nötig, z.B. nur Ergebnisprotokoll
visualisiert
146
2. Faktor Mensch
Aufgaben des Moderators
formaler Steuerer
Ordnungsfunktion
regulieren
stimulieren
koordinieren
steuern
sachneutral
147
Brainstorming
Idee
Gruppendiskussion
Ausschalten denkpsychologischer Blockaden
freies Spinnen von Ideen
vier Grundregeln des Brainstormings
Zurückstellen
Zurückstellen
jeglicher
jeglicher Kritik
Kritik
Aufgreifen,
Aufgreifen,
Kombinieren
Kombinieren oder
oder
Weiterentwickeln
Weiterentwickeln
geäußerter
geäußerter
Ideen
Ideen
Ideen
Ideen freien
freien
Lauf
Lauf lassen
lassen
Quantität
Quantität geht
geht
vor
vor Qualität
Qualität
¾ „Prinzip der freien Abstraktion“
148
Brainstorming
Einsatzgebiet
Kreativphasen: Produktideenfindung, Produktkonzepterstellung
Generierung latenter Anforderungen in der Produktprofilplanung
für Suchprobleme bzw. einfachere (Teil-)probleme
integrierbar in andere Methoden, z.B. Szenariotechnik
Produktstrategie
planung
Produktideenfindung
/-bewertung
Produktprofilplanung
Produktkonzeptplanung
Produktkostenplanung
Produktkonzepterstellung
Verbreitung:
am häufigsten angewandte Kreativitätstechnik
Anwendungsgrad 50-80%
149
Brainstorming
Voraussetzungen
Schulung der Teilnehmer
Flipboard und Konferenzraum
erfahrener Moderator
150
Brainstorming
Durchführung
Einberufung 1-3 Tage im voraus
Teilnehmerkreis 5-8 Personen
fachlich heterogen, hierarchisch homogen
20-40 min Dauer
Moderator überwacht Einhaltung der Grundregeln
Nachsitzung
151
Brainstorming
Vorteile
rasch erlernbar
einfach und schnell
vielseitige Ideen
anregend und motivierend
Nachteile
nur für relativ einfache Probleme
keine Vorgehenssystematik
Einhaltung der Grundregeln schwierig
152
Brainstorming
Varianten
Diskussion 66
größerer Teilnehmerkreis
Little-Technik
Problem zunächst nicht bekannt
imaginäres Brainstorming
Verfremdung des Problems
SIL-Methode
Einzel- und Gruppenarbeit abwechselnd
Mindmaps
153
Brainstorming
Literatur
Schlicksupp, H.: Kreative Ideenfindung in der Unternehmung – Methoden und
Modelle, de Gruyter Verlag, Berlin, 1977
Schlicksupp, H.: Innovation, Kreativität und Ideenfindung
Vogel Verlag, Würzburg, 1989
Knieß, M.: Kreatives Arbeiten, dtv Beck Verlag, München, 1995
Baier, D.: Marketing und Innovation, Vorlesungsskript, Universität Karlsruhe,
1997
154
Mind-Maps
Idee
Methode zur Strukturierung von Daten eines Problems in bildlicher Form.
Verknüpfung von sprachlichem mit bildhaftem Denken (kann zu einer Steigerung
der Leistungsfähigkeit des menschlichen Denkens führen).
Basiert auf der modernen Gehirnforschung und auf der Aufgabenteilung zwischen
den beiden Hemisphären des Großhirns.
155
Mind-Maps
Mind-Maps
Teilnehmerzahl
Einzeln oder in kleinen Gruppen
Voraussetzungen
Flip-chart und Moderator (bei Gruppen)
Papier
Farbstifte
156
Mind-Maps
Durchführung
1. Man schreibt in die Mitte eines Papierbogens das Thema
2. Es wird mit einem Kreis umschlossen.
3. Ausgehend von diesem Kreis werden Verästelungen gebildet,
welche das Thema in einzelne Bereiche gliedern. Es entstehen
Assoziationen und von den Ästen können wiederum Zweige zur
Konkretisierung des Teilproblems gebildet werden. Dies geschieht solange, bis
den Beteiligten nichts mehr zur Thematik
einfällt.
4. Als Gedankenstütze kann man „Hinweisschilder“ benutzen.
Regeln:
Strukturieren vom Abstrakten zum Konkreten, vom Allgemeinen zum Speziellen
nur Substantive verwenden
in Blockschrift
157
Mind-Maps
Beispiel
158
Mind-Maps
Vorteile
Förderung der Kreativität
Steigerung der Effektivität
Guter Überblick über das Gesamtproblem
schnell und einfach erlernbar
flexibel anwendbar
Nachteile
Zeitbedarf
Als Anfänger kann man bei der Stichwortsuche Probleme haben
Oft fallen konkrete Stichworte schon vor der Astbildung.
159
Mind-Maps
Literatur
Kirckhoff, M.: Mind Mapping; Die Synthese von sprachlichem und bildhaften
Denken; Synchron-Verlag; Berlin; 1988
Hugl, U.: Qualitative Inhaltsanalyse und Mind-Mapping; Gabler-Verlag;
Wiesbaden; 1995
Vorlesung KLA des Instituts für Maschinenkonstruktionslehre und
Kraftfahrzeugbau (mkl) der Universität Karlsruhe (TH); Dozent Dipl.-Ing. N.
Burkardt
160
Methode 635
Idee
Weiterentwicklung des Brainstorming
Die Ideen eines Teilnehmers werden von dem Zweiten fortgesetzt und dann von
dem Dritten usw.
schriftlich (Formblatt)
6 Teilnehmer
3 verschiedene Lösungsvorschläge zum selben Thema
5 Minuten Zeit für drei Ideen
Einsatzgebiet
Vor dem Verwenden anderer und aufwendigerer Entwicklungsmethoden einsetzen
161
Methode 635
Formblatt
162
Methode 635
Durchführung
635-Ablauf in ca. 30 min = 6 * 5 Minuten.
Regeln:
kein Kontakt untereinander
Zeitvorgaben unbedingt einhalten
je Feld nur eine Idee, schlagwortartig formuliert
Hat der Vorgänger ein Feld freigelassen, immer zuerst die eigenen Felder ausfüllen
163
Methode 635
Vorteile
Entfall eines Moderators
Ermittlung des Urhebers einer Erfindung möglich
eine Idee wird systematisch weiterentwickelt
Nachteile
geringere Kreativität durch Isolierung und mangelnde Stimulierung
mögliche Denkblockaden durch Zeitbeschränkung
Missverständnisse durch stichwortartige Beschreibung
164
Methode 635
Literatur
Pahl,G./Beitz,W.; Konstruktionslehre; Springer-Verlag; Berlin; 1993
Das Arbeiten mit kreativen Methoden; Wirtschaftsförderungsinstitut der
Handelskammer (WIFI); Wien (Österreich); 1987
Schlicksupp,H.: Ideenfindung; Vogel-Verlag; Würzburg; 1992
165
Laterales Denken
Grundlage:
Theorie des kreativen Denkens und Handelns von Edward de Bono
Das laterale, kreative Denken wird dem vertikalen Denken (logisches
Schlußfolgern, Auswählen und Bewerten von Alternativen, Konzentration auf das
Relevante) gegenüberstellt.
Wahrnehmung und Informationsverarbeitung folgen in der Regel bestimmten
bevorzugten und “eingefahrenen” Datenverarbeitungswegen, die sich über die
Zeit bewährt haben (vertikales Denken).
Laterales Denken: Statt gewohnheitsmäßig auf der “Datenautobahn” zu fahren
mit einem lateralen Sprung auf ein Nebengleis wechseln
→ Verlassen der üblichen Wege der Datenverarbeitung
→ ungewöhnliche Lösungen
166
Laterales Denken - Hutwechsel-Methode

Prinzip: schneller Wechsel zwischen verschiedenen Denkmodi, die durch
verschiedenfarbige Hüte repräsentiert werden
→ Verlassen eingefahrener Denkschienen und Perspektivenwechsel
Sechs verschiedene Hüte werden nach Absprache zwischen den Teilnehmern
gewechselt, gegebenenfalls kann auch die ganze Gruppe den gleichen Hut
tragen:
Der weiße Hut: Daten und Informationen (Welche wichtigen Informationen fehlen uns? Wie
kommen wir an diese Informationen heran?)
Der rote Hut: Gefühle, Intuition, Instinkt (gibt die Möglichkeit, Gefühle und Intuitionen ohne
langwierige Entschuldigungen, Rechtfertigungen und rationale Tarnungen mitzuteilen)
Der schwarze Hut: kritisches Denken, Vorsicht, Fehlervorbeugung, Suche nach Nachteilen
(sehr wichtig, sollte aber nicht missbraucht werden und kreative Ideen schon im Keim
ersticken)
Der gelbe Hut: Optimismus, Suche nach Vorteilen, Suche nach Realisierungsmöglichkeiten
Der grüne Hut: kreatives Denken, Suche nach neuen Ideen und Alternativen
Der blaue Hut: “Vogelperspektive”, hat eine Art Moderatorfunktion, Kontrolle von Methoden und
Verfahren, objektive Prüfung der Denkmodi, Festlegung der Themen, Hinweise auf die
nächsten Schritte im Denkprozeß, kann andere Hüte aktivieren
167
Laterales Denken - Umkehrmethode

Die übliche “Marschroute”, die man bei der Bewältigung einer Aufgabe
normalerweise einschlägt, wird mental umgekehrt und genau die
entgegengesetzte Richtung eingeschlagen.
→ unerwartete und neuartige Ideen
Beispiel 1:
Das Telefon klingelt, wenn ein Anruf eingeht.
Provokation: Das Telefon klingelt die ganze Zeit über und ist nur still, wenn ein
Anruf eingeht. Dies erscheint zwar absurd, könnte aber z.B. zu der Idee führen,
daß man Telefon und Fernsehgerät koppelt und der Ton des Fernsehers
automatisch verstummt, sobald ein Anruf eingeht.
Beispiel 2:
Statt der Suche nach Lösungsmöglichkeiten für ein kundenfreundliches
Kaufhaus kann die Instruktion lauten, ein möglichst kundenunfreundliches
Kaufhaus zu entwerfen.
168
Laterales Denken - Random-Input-Technik
Um zu einer neuen Idee zu gelangen sucht man ein Wort, das in
keinerlei Zusammenhang mit dem Thema bzw. dem Problem steht und
stellt es dem Problem gegenüber.
→ Versuch, aus dieser Wortkombination neue Ideen zu entwickeln
Prinzip: Beginn der Suche an einem neuen Ausgangspunkt
→ erhöht die Wahrscheinlichkeit einer neuartigen Idee schlagartig
Begriff sollte Zufallsbegriff sein (beruht auf der Fähigkeit des Gehirns,
mentale Verbindungen auch zu fernen Assoziationen und Begriffen
herzustellen)
169
Laterales Denken
Einsatzgebiet
Die Techniken des lateralen Denkens sind vor allem zur Ideenfindung geeignet,
z.B. zum Auffinden neuer Produktideen oder Verbesserungsmöglichkeiten
Die Hutwechsel-Methode wird häufig als allgemeiner Diskussionsrahmen
verwendet
Die Random-Input–Technik und die Umkehrmethode sind besonders geeignet,
wenn der Ideenvorrat erschöpft ist, eine Blockade oder eine “Nullpunkt-Situation”
ohne Ausgangspunkt vorliegt.
170
Laterales Denken
Voraussetzungen
Ein kreatives Team von Kunden/ Konsumenten oder Mitarbeitern
Ein geschulter Moderator oder Diskussionsleiter mit Kenntnissen des lateralen
Denkens und seiner Techniken
171
Laterales Denken
Durchführung
Festsetzung des Themas/ Problemkreises
Zusammenstellen einer Gruppe für den Workshop
Auswahl eines geeigneten Moderators
Auswahl der Technik/ Kombination von Techniken
Durchführung des Workshops (unter Beachtung der Regeln, z.B. regelmäßiges
Wechseln der Hüte)
Ideensammlung
Ideenbearbeitung (Weiterentwicklung vielversprechender Ideen in
Lösungsvorschläge)
Bewertung der Lösungsvorschläge
Planung erster Implementationsschritte
172
Laterales Denken
Vorteile
Basis ist eine anerkannte Theorie der
Kreativität
Neuartige Denkimpulse bei Stagnation
der Ideenproduktion
Erhöhung der Motivation der
Teilnehmer durch spielerisches
Element der Techniken
Häufiger Perspektivenwechsel bewirkt
mehr und neuartigere Ideen
Nachteile
Unscharfe Definition der einzelnen
Techniken, “Verwaschung” durch
unqualifizierte Anwendung
Unübersichtliche Vielfalt an einzelnen
Techniken und Variationen der
Techniken
173
Laterales Denken
Große Vielfalt weiterer Techniken des lateralen Denkens:
“Schöpferische Pause” (kurzes Innehalten, um bewußt Abstand zu gewinnen)
“Mentale Provokation” (bewußtes Ausbrechen aus den Grenzen der Vernunft
durch eine “provokative Operation”, kurz “po”, bei der eine unlogische und
abwegige Äußerung den logischen Gedankengang unterbrechen soll und so zu
einem Perspektivenwechsel und zu neuen Ideen anregt)
“Trittstein-Provokationen”, zu denen auch die Umkehrmethode gehört. Weitere
Trittstein-Provokationen:
Übertreibung (Über- oder Untertreibung von Maßzahlen oder Dimensionen)
Zerrbilder (das Verhältnis zwischen den Elementen wird willkürlich verändert)
Wunschdenken (ein unrealisierbar erscheinender Wunsch wird ausgemalt, sollte
allerdings kein angestrebtes Ziel sein)
174
Laterales Denken
Literatur
DeBono, Edward (1986). Edward de Bono's Denkschule: zu mehr Innovation und
Kreativität. Landsberg am Lech: MVG
DeBono, Edward (1996). Serious Creativity: Die Entwicklung neuer Ideen durch
die Kraft des lateralen Denkens. Stuttgart: Schäffer-Poeschel.
Johansson, Björn (1997). Kreativität und Marketing: Die Anwendung von
Kreativitätstechniken im Marketingbereich. Bern: Lang.
175
zu guter Letzt
176
Projektmanagment
1.
Einleitung
2.
Faktor Mensch
3.
Interviewtechniken
Zeitmanagement
Projektinitiierung
177
Projektmanagment
Schätzverfahren
Projektplanung
Einleitung
Projektfunktionen
Aufgabenträger
178
Projektmanagment
6.
Projektkontrolle
7.
Change-Management
Kostenkontrolle
Prozessverbesserung
Projektabschluss
179
Kapitel 3:
Projektinitiierung

180
3 Projektinitiierung
Projektvorbereitung:
Projektinitiierung:
Inhaltliche Definition
Schätzung
Durchführungsentscheidung
Planung
Techniken:
Innovationsplanung und
Problemfeldanalyse
Schätzverfahren
Arbeitsplanung
Aufwands- und Terminplanung
Personalplanung
181
Projektstart
182
Vorauswahl von Projekten
Ausrichtung auf strategische
Ziele?
nein
nein
ja
Know-how zu akzeptablem
Preis erhältlich?
nein
ja
ja
Ausreichend Kapazität?
nein
ja
ja
Notwendiges Know-how?
Wirtschaftlichkeitssteigerung?
nein
Kapazitäten zu akzeptablem
Preis erhältlich
nein
ja
nein
Projektidee weiterverfolgen!
Projektidee eliminieren
183
Zeitpunkte der Projektstartkommunikation
184
Projektinitiierung
Starke Produktivitätsschwankungen zwischen Mitarbeitern
Schwache Produktivitätsschwankungen im Team
Teamkohäsion
Teamidentifikation mittels gemeinsamer Normen
„Never change a winning team“
Ausrichtung auf ein gemeinsames Ziel
Aufgabe:
Personalauswahl:
-
Anhand der richtigen technischen Metriken messen
Teamfähigkeit berücksichtigen
Teammitglieder in die Auswahl miteinbeziehen
Teamaufbau:
-
Zeit und Möglichkeit für Teamaufbau einbauen
Team als Einheit wahrnehmen
185
Funktion:
Grobdefinition der Ziele des Projekts
Grobabschätzung des Nutzens
Grobabschätzung der Kosten und benötigten Einsatzmittel
Erstvorschlag zur Projektorganisation
Aktivitäten:
Festlegung Projektziele
Erstellung Grobplan
Voruntersuchung und Durchführungsentscheidung
Organisationsplanung
Ergebnisse:
Projektauftrag
Projekthandbuch
Projektplan (Grobversion)
186
Projektziele
Projektidee:
Auftragsprojekt: Anforderungskatalog
Innovationsprojekt: Marktstudie/Technologiestudie
Pflege/Änderungsprojekt: Verbesserungsvorgaben
Wichtig:
Festlegung Projekterfolgskriterien
Messbare Kriterien
Präzisierung Projektziele:
Lastenheft
Pflichtenheft
Projektauftrag
187
Produktbeschreibung: Lastenheft, Pflichtenheft
Lastenheft:
Definiert durch Kunde oder Projektinitiator
Fachorientierte Anforderungssammlung
-
Produkteinsatz (Welche Nutzer)
Produktumgebung (Welche Schnittstellen)
Fachliches Datenmodell (Welche Information)
Funktionale Spezifikation (Welche Funktion)
Benutzungsschnittstelle (Welche Präsentation)
Pflichtenheft:
Definiert durch Kunde und Projektleiter
Fachliche Vertragsgrundlage
-
Zieleinsatz (Was vom Lastenheft wird geliefert)
Leistung und Qualitätsmerkmale (Was sind Leistungsgrenzen)
Testszenarien (Was wird getestet)
Entwicklungsumgebung (Was wird eingesetzt)
Ergänzungen (Was noch)
188
Grobplan
Ziel Projektplan (generell): Festlegung von Vorgängen und Meilensteinen und
deren Abhängigkeiten
Ziel Grobplan:
Grobschätzung Aufwände/Termine: Durchführungsentscheidung
Ausgangsversion Projektplan: Projektdurchführung
Inhalt Grobplan:
Festlegung Projektorganisation:
-
Festlegung Projektgrobstruktur
Zerlegung des Projekts in Aktivitäten und Produkte
Festlegung von Aufwänden und Terminen
Festlegung von benötigten Einsatzmitteln und Mitarbeitern
189
Durchführungsentscheidung
Ziel: Annahme/Ablehnung Projekt
Verfahren:
Ermittlung Kosten: Auf Basis Grobplan
-
Personalkosten (inkl. Personalvorbereitung)
Betriebsmittelkosten
Organisationskosten
Ermittlung Nutzen:
-
Monetärer Gewinn: Marktanalyse, Effizienzanalyse
Investitionsgewinn
Risikoanalyse:
-
Wirtschaftliche Risiken
Fachliche Risiken
Evtl: Alternativen erstellen und beurteilen
Ergebnis: Annahme / Ablehnung Projekt
190
Projektauftrag
Voraussetzung: Durchführungsentscheidung
Bestandteile:
Beschreibung des Grobkonzepts (Systemspezifikation)
Umfasst: Beschreibung des Leistungsumfang (Pflichtenheft)
Umfasst: Beschreibung des Anwendungsgebietes (Lastenheft)
Projektgrobplan: Termine und Aufwände
Projekthandbuch: Entwicklungsprozess
Projektstruktur: Externe Rollen (Auftraggeber, Projektmanager, Projektleiter)
191
Kapitel 3:
Projektinitiierung

192
3.1 Gründung eines Projekts
Basis Projektantrag
bildet vertragliche Grundlage zwischen Auftraggeber und Auftragnehmer
legt Leistungsvolumen, sowie
Kosten- und Terminrahmen des Projekts fest
Notwendig: klare Aufgabenstellung
Projektparameter müssen bestimmt
Projektrisiken festgestellt werden
-
Problemfeldanalyse, gesamtes Projektumfeld wird systematisch untersucht mit dem Ziel optimal
Planungsgrundlagen für die nachfolgenden Projektabschnitte zu schaffen
Innovationsplanung, stellt Weichen für Markterfolg
193
3.1 Gründung eines Projekts - Innovationsplanung
Innovationsplanung
Problem:
Zukunftssicherung von Unternehmen wird immer mehr von der Entwicklung völlig neuer
Produkte bestimmt und hängt immer weniger von der Weiterentwicklung vorhandener
Produkte ab.
Wandel vom Verkäufermarkt hin zum Käufermarkt
Marktgerechte Produkte fehlen, da
-
Entwicklung berücksichtigt zu wenig die Kundenanforderungen
Keine systematische Markterkundung
von der Technik getrieben, aber auch beharren auf alten Technologien
Konkurrenz und ihre Produkte wird nicht zur Kenntnis genommen
Kein Denken in Produktlebenszyklen
Notwendig – Strategische Planung
Marktanalysen
Geschäftsfeldplanung
Produktplanung
194
Definition
Innovationsplanung ist das gezielte Suchen und Finden von für das
Unternehmen lukrative Geschäftsfelder und damit neuer Produkte. Der
Ablauf umfasst:
Produktpositionierung
Produktbewertung
Produktauswahl
Analysemethoden:
Portfolio-Analysen
ABC-Analysen
Lebenszyklus-Analysen
195
Portfolio-Methode
zwei-dimensionale Matrix bestimmter Betrachtungsobjekte
Geschäftsfelder
Produktgebiete
Technologien
in Abhängigkeit von zwei Beurteilungskriterien mit Skalierung angeordnet
häufig werden eigene und konkurrierende Objekte miteinander verglichen
x-Koordinate, z.B.
relativer Marktanteil
Geschäftsfeldstärke
technisches Weiterentwicklungspotential
relative Technologieposition
y-Koordinate, z.B.
Marktwachstum
Branchenattraktivität
Produktattraktivität am Markt
wirtschaftliche Bedeutung
Beispiele:
Geschäftsfeldportfolio
Technologieportfolio
196
Geschäftsfeldmethode (BCG)
Feld I:
hoher relativer Marktanteil
niedriges Marktwachstum
¾ Cash Cow/Goldesel
Feld II:
hoher relativer Marktanteil
hohes Marktwachstum
¾ Stars
Feld III:
niedriger relativer Marktanteil
hohes Marktwachstum
¾ Question marks/Fragezeichen
Feld IV:
niedriger relativer Marktanteil
niedriges Marktwachstum
¾ Dogs/Sorgenkinder
197
Technologie-Portfolio
198
3.1 Gründung eines Projekts – Innovationsplanung
ABC-Analyse
wird verwendet um Vorauswahl an
Produkten zu treffen
Anwendung wenn Unwichtiges von
Wichtigem zu trennen ist
z.B. Auswahl von Produktalternativen
diejenigen mit meisten Umsatz
Klasse A
-
enthält Umsatzträchtigsten Produkte,
die zusammen bereits 75% des
Umsatzes ausmachen
Klasse B
-
enthält die Produkte, die zusammen mit
Produkten der Klasse A 90%
ausmachen
Klasse C
-
enthält die Umsatzschwächsten
Produkte, die nur 10% des Umsatzes
ausmachen
Analog: Technologieauswahl
x-Achse Technologien
y-Achse technisch-wirtschaftliche
Bedeutung
199
Lebenszyklus-Analysen
Produktlebenszyklen
Technologielebenszyklen
200
Produktlebenszyklen
Zyklen
Entstehungszyklus
-
Definition
Entwurf
Realisierung
Erprobung
Marktzyklus
-
Markteinführung
Wachstum
Reife
Sättigung
Degeneration
Standzeiten / Innovationszyklen
Mobiltelefone < 1Jahr
PC 2 bis 3 Jahre
Server 3 bis 5 Jahre
Anwender-SW etwa 6 Jahre
Kraftwerkstechnik 20 bis 30
201
Technologie-Lebenszyklus
S-Kurve
3 Phasen
Suchphase
-
Technologie noch nicht
leistungsfähig
Durchbruchphase
-
Technologie leistungsfähig
großer Nutzen für das Investment
Reifephase
-
Verbesserungsmöglichkeiten
ausgereizt
Umstieg auf neue Technologie muß
vorbereitet werden
202
3.1 Gründung eines Projekts - Grundparameter
Die 3 Grundparameter sind
Ergebnis / Leistung
Produktivität
Projekt
Kapazität
Aufwand /
Einsatzmittel
Termin
/ Zeit
203
Dreieck verdeutlicht Abfolge in
Projektgeschehen
Einsatz von Aufwänden (Geld,
Personal, Maschinen,...) und
Verbrauch an Zeit
soll bestimmtes Ergebnis
erzielt werden
PM hat zentrale Aufgabe
Erbringung geforderte Leistung
im optimalen Verhältnis zu Zeit und
Einsatzmitteln
Parameterausrichtung
kostenfixierte Parameterausrichtung
terminfixierte Parameterausrichtung
leistungsfixierte Parameterausrichtung
204

Produktivität
Kopfzahl (= Personalstärke)
Qualifikation

Qualität
DIN: Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte
Erfordernisse zu erfüllen
Beispiele:
Funktionserfüllung
Zuverlässigkeit
Benutzerfreundlichkeit
Wartungsfreundlichkeit
Instandhaltbarkeit
Umweltfreundlichkeit
Übertragbarkeit
Zeitverhalten
Verbrauchsverhalten
Fertigungsfreundlichkeit
205
3.1 Gründung eines Projekts - Problemfeldanalyse
Problemfeldanalyse
Richtige
FuE-Kosten
Richtige
Entwicklungsdauer
Richtige
Aufgabenstellung
Richtige
Personalstärke
Richtiges
Produkt
Richtige
Qualifikation
Richtiger
Funktionsumfang
Richtige
Methoden u.
Werkzeuge
206
Richtige Aufgabenstellung?
Produkt kann genial und hochwertig sein, wenn es aber keine Marktbedürfnisse
deckt
¾ Flop
Deswegen
Marktanalyse
Portfoliodarstellung
...
207
Richtige Entwicklungsdauer?
McKinsey: „Das Einhalten und Verkürzen von Entwicklungszeiten ist wichtiger als
das Einhalten und Reduzieren von Entwicklungskosten“
3 Varianten der Wirtschaftlichkeitsbetrachtung
208
Richtige FuE-Kosten?
Minimale Projektkosten
Es dürfen nicht so viele FuE-Kosten
verschlungen werden, wie nie wieder
an Erträgen hereinholbar sind.
-> Wirtschaftlichkeitsbetrachtungen
209
Richtige Personalstärke?
von Brooke: Adding man power to a late project makes it late!
Optimale Personalstärke
210
Richtige Qualifikation?
Produktivität kann erheblich variieren
Faktoren von mehr als das 10 (zehn-!)fache sind nicht selten
Personalplanung
mehr Klasse als Masse
Kopfzahlen
Make or buy - Entscheidung
211
Richtiger Funktionsumfang?
Der Kunde bekommt das was er nicht will, aber nicht das was er will
Requirements-Engineering sehr wichtiger Schritt!
Methoden:
Prioritätenliste
ABC-Analyse
¾ Versionsplanung
212
Richtige Methoden und Werkzeuge?
SW-Gebiet
Logische Entwurfssysteme
Graphische Designtools
Programmeditoren
IDE
Programmgeneratoren, z.B. aus UML-Diagrammen
Testsysteme
Profiler
Dokumentationssysteme
HW-Gebiet
Systeme zur Logik und Fehlersimulation
Layout-Systeme
Generierungsprogramme für Prüfdaten
213
3.1 Gründung eines Projekts – Projektantrag
Projektantrag
Ziel: Entwicklungsauftrag schriftlich fixieren
Inhalt
wichtigste Eckpunkt der geplanten Entwicklung
Zielvereinbarung
Aufbau, z.B.
-
Name des Projekts
Kurzbeschreibung des Vorhabens
Identifikationsbegriff
Projektleiter, Teilprojektleiter
Mit-/Unterauftragnehmer
Geplanter Personalaufwand
Einsatzmittelkosten
Meilensteine
Fertigstellungstermine
Risikobetrachtung
Unterschriften
214
3.1 Gründung eines Projekts - Projektantrag
Arten von Projektanträgen
Projektauftrag
interne Auftragsvergabe innerhalb eines Unternehmens
FuE-Auftrag
FuE-Planung innerhalb Entwicklungsbereiches
Produktvereinbarung
Zielvereinbarung zwischen Ertragszentren eines Unternehmens
215
Kapitel 3:
Projektinitiierung

216
3.2 Produkt-/Systemdefinition
Ziel
Aufgabendefinition eines Projekts
Wird in mehreren aufeinander folgenden Planungsschritten detailliert mit größerer
werdender inhaltlichen Genauigkeit
Anforderungskatalog
Pflichtenheft
Leistungsbeschreibung
vom Anwender zu definieren
mit Unterstützung des zukünftigen Anwenders,
fachliches Grobkonzept
im wesentlichen das fachliche Feinkonzept,
erstes Grobkonzept für die technische
Realisierung und die allgemeinen
Realisierungsanforderung;
legt Projektinhalt verbindlich fest
217
Ziel
Anforderungskatalog
Pflichtenheft
218
3.2 Produkt-/Systemdefinition - Anforderungskatalog
Anforderungskatalog
Ziel: Präzisierung des Projektziels
Mitwirkende: Auftraggeber
Aspekte für SW-Projekt
Anwendungs- bzw. Einsatzumgebung
geforderte Funktionen und Eigenschaften
Benutzeroberflächen
Benutzerschnittstellen
Datenbasis
Mengengerüst
Qualitätsanforderungen
Realisierungsvorgaben
Dokumentationsanforderungen
Zeit- und Kostenrahmen
Ausgehend vom Anforderungskatalog wird dann der Projektvorschlag definiert, i.a. bestehend aus
¾
Zusammenfassung
Projektdefinition
Ist-Zustand
Lösungsalternativen
Systemkonzept
Basis für die Entscheidung über das Projekt
219
Ziel
Anforderungskatalog
Pflichtenheft
220
3.2 Produkt-/Systemdefinition - Pflichtenheft
Pflichtenheft
Ziel: Definition fachliches Grobkonzept und weitere allgemeine Angaben zu
geplanten Produkt
Aspekte:
welche Funktionen das System erfüllen muss
welcher Daten und Informationen verarbeitet werden sollen
welche Ein- und Ausgaben vorgesehen sind
welche konstruktive Vorgaben (bei HW) zu beachten ist
welche Schnittstellen berücksichtigt werden müssen
welche sonstigen Produkt/Systemeigenschaften gefordert werden
Anforderungen:
vollständig
widerspruchsfrei
221
Aufbau - Pflichtenheft
Gesamtsystem
Systemumgebung
Systemdarstellung
Systembeschreibung
Teilsystem
Teilsystemdarstellung
Kurzbeschreibung der Teilsysteme
Komponentenfestlegung
Beschreibung der Ein-/Ausgabedaten
Darstellung der Bedienoberfläche
geforderte Dialogauskünfte und Auswertungen
verfahrensinterne Schnittstellen
Datendefinition
Stammdaten
Bewegungsdaten
Verwaltungsdaten
222
Aufbau – Pflichtenheft …
Schnittstellen
zu vor-/nachgelagerten Verfahren
Standard-Eingabeschnittstellen
Standard-Ausgabeschnittstellen
Allgemeine Systemangaben
Auflagen / Restriktionen
Mengengerüst
Arbeitsabläufe, vorhandene/geplante Ablauforganisationen
sonstige Anforderungen
223
224
Ziel
Anforderungskatalog
Pflichtenheft
225
3.2 Produkt-/Systemdefinition - Leistungsbeschreibung
Ziel: bildet Gesamtheit der Aufgabendefinition und legt damit die fachliche und technische
Basis des geplanten Produkts oder Systems fest
Aspekte:
welche Teilsystem und Komponenten das Produkt/System umfassen soll
welche Fachprozesse zu erfüllen sind
wie die Benutzungsoberfläche zu gestalten ist
welche Ausgaben in welcher Form zu realisieren sind
wie die Datenbasis aussieht
welche elektronischen und konstruktiven Eigenschaften (bei HW) bestehen werden
welche Schnittstellen vorhanden sein werden
welche Realisierungsanforderungen gelten und
welche allgemeine Systemeigenschaften gefordert werden
Vereinbarungsgrundlage zwischen Auftraggeber und Auftragnehmer
Leistungsbeschreibung ist Basis für
für das Management zur Realisierungsentscheidung
für die Qualitätssicherung zur Vollständigkeitskontrolle
für die Planung zur Durchführungsplanung und
für die Realisierung zum Erstellen des technischen Feinkonzepts
226
Im allg. umfasst die Leistungsbeschreibung
das fachliche Feinkonzept
das technische Grobkonzept
und die allgemeinen
Realisierungsanforderungen
227
Fachliches Feinkonzept
Fachliches Gesamtsystem
Systemumgebung
Systemdarstellung
Systembeschreibung
Teilsystem
Teilsystemdarstellung
Kurzbeschreibung der Teilsysteme
Verzeichnis der zugehörigen Datenbereiche
Verzeichnis der zugehörigen Komponenten
Verzeichnis der zugehörigen Schnittstellen
Beschreibung der Komponenten
Beschreibung
Datensätze
Masken und Listen
Beschreibung der Masken
Funktion und Aufgabe
Feldbeschreibungen
Ansprungsmöglichkeiten, Meldungen
Maskendarstellung
Beschreibung der Auswertungslisten
Aufgabenbeschreibung
Listendarstellung
Schnittstellen
228
Technisches Grobkonzept
Beschreibung IT-System
IT-Systemdarstellung
Beschreibung des IT-Systems
IT-Systemdatenfluss
Zuordnung Fachprozess zu IT-Teilsystemen bzw. –Komponenten
Beschriebung der IT-Teilsysteme
IT-Teilsystem-Beschreibung
Strukturbaum teilspez. IT-Komponenten
Strukturbaum zentraler IT-Komponenten
Abhängigkeiten zu anderen IT-Komponenten
Beschreibung der IT-Komponenten
Funktionsbeschreibung
Verarbeitungsschritte
Anzahl Satzarten
Fremdsoftware
Speicherkonzept
Datenbankschema
Verzeichnis der Daten
Datenbeschreibungen
Datenkatalog
Name der Datenelement
Synonyme
Suchbegriffe
Kurzbeschreibungen
Angaben zu Format, Länge Default
Wertebereiche
229
Allgemeine Realisierungsanforderungen
Regeln und Konventionen
Guidelines
Aufbau Masken, Listen, Meldungen
Toolkonzept
...
Testkonzept
Aufgabenstellung
Testfälle
Testberichte
Testdaten
Testplanung
Testdurchführung
Prüflisten
Auflagen/Restriktionen
Arbeitsabläufe
IT-spezifische Auflagen
Dokumentation
Benutzerdokumentation
Anwendungsdokumentation
Einführungs- und Versionsplanung
Installationskonzept
Wartungskonzept
Schulungsplan
Versionskonzept
230
3.2 Produkt-/Systemdefinition - Änderungswesen
Änderungswesen
Änderungsanforderungen stellen zwangsläufig bereits erarbeitete
Zwischenergebnisse in Frage.
Zwischenergebnisse bauen aufeinander auf
→ gesamte Ergebnisfolge gefährdet
Wirkung von Änderungsanforderungen
231
Arten von Vorgehensweisen im Änderungsprozess:
kontinuierlicher Änderungsprozess
eingeschobener Änderungsprozess
begleitender Änderungsprozess
232
233
Projektmanagment
1.
Einleitung
2.
Faktor Mensch
3.
Interviewtechniken
Zeitmanagement
Projektinitiierung
234
Projektmanagment
Schätzverfahren
Projektplanung
Einleitung
Projektfunktionen
Aufgabenträger
235
Projektmanagment
6.
Projektkontrolle
7.
Change-Management
Kostenkontrolle
Prozessverbesserung
Projektabschluss
236
Kapitel 4:
Schätzverfahren und Projektplanung
Schätzverfahren
Projektplanung
237
Kapitel 4:
Schätzverfahren
Projektplanung
238
4 Schätzverfahren und Projektplanung
4.1 Schätzverfahren
Wie man Kosten nicht schätzt - Beispiele:
“Für das Projekt stehen uns 12 Monate zur Verfügung, also wird es 12 Monate
dauern.”
“Der Mitbewerber hat ein Angebot über $1 M abgegeben, dann geben eben wir
eines über $0.9 M ab.”
“Das Produkt soll auf der nächsten Messe präsentiert werden, also muss die
Software in den nächsten 9 Monaten geschrieben und getestet werden.”
“Das Projekt wird wahrscheinlich 12 Monate brauchen, das Management wird
aber wohl nur 10 Monate akzeptieren. Dann geben wir eben 10 Monate als
Schätzung bekannt.”
239
240
Überblick
Notwendigkeit für Schätzungen
Bereits in frühen Phasen eines Projekts (noch vor der Genehmigung) muss eine
Aussage über die Machbarkeit und die Kosten (Geld und Zeit) getroffen werden.
Schätzungen sind Basis für Entscheidungen (Wirtschaftlichkeitsbetrachtung)
Genauigkeit der Schätzung muss über
die Projektlaufzeit zunehmen
Schätzungen sind Basis für die
gesamte Projektplanung
(Ressourcen, Mitarbeiter) und auch
für Folgeaktionen (Markteintritt,
Werbekampagnen etc.)
Basis für Projektcontrolling
241
Überblick
Notwendigkeit für Schätzungen
Messung der Produktivität
zum Erkennen von Verbesserungspotential
zur Beurteilung von Prozessverbesserungen
zum Benchmarking
Messung der Qualität
zum Erkennen von Schwachstellen
zur Prüfung der Wirksamkeit von QS-Maßnahmen
als Hilfe bei der Freigabe-Entscheidung
¾ Kernaufgabe für das Projektmanagement
242
Überblick
Probleme bei Schätzungen
Unvollständiges Wissen über
Tatsächlichen Projektumfang
Voraussichtliche Projektmitarbeiter
Technischen und organisatorisches Umfeld
Vergleichbarkeit der Projekte bei neuen Technologien, Mitarbeitern und ggf.
Vorgehensweisen
Zeitproblem
Aufwand hängt von sehr vielen Einflußgrößen ab, z.B.:
Art der Anwendung, befolgtes Lebenszyklusmodell,
nicht-funktionale Anforderungen, künftige Benutzer, organisatorische
Randbedingungen bei Auftraggeber sowie Auftragnehmer,
Software- und Hardwareumgebung, Stabilität der Umwelt, Qualifikation der
Mitarbeiter, Führungsstile, ..., ...
243
Überblick
Probleme bei Schätzungen
Schätzungen sind ungenau:
Mohanty (1981)
-
13 Verfahren getestet:
min. Aufwand: $362.500,
max. Aufwand: $2.766.667
je früher eine Schätzung gemacht
wird, umso ungenauer ist das
Ergebnis;
dennoch:
frühe Schätzung ist für das Projektmanagement erforderlich!
daher:
Wiederholung(en) der Schätzung im Projektverlauf notwendig für Präzisierung
und Kontrolle, ob der Budgetrahmen eingehalten wird.
244
Überblick
Grundprinzipien einer Schätzung
Dokumentation der Annahmen
Gewählte Schätzmethode
Annahmen über Umfang, Mitarbeiter etc.
Definition der Schätzgenauigkeit (passend zur Projektphase) – Angabe einer
Ergebniskorridors
Einbeziehung erfahrener Kollegen (Reviews)
Soll-Werte
ungenaue
Anforderungen
Mist
schätzen
Aufgabe
Aufgabe
strukturieren
strukturierte
Aufgabe
schätzen
noch fehleranfällig! Fehlerhafte Schätzungen der Vergangenheit
fließen ein, daher werden ggf. Fehler wiederholt.
245
Überblick
246
Überblick
Komponenten einer Projektschätzung
Kosten/Aufwand
Personal (in Personentagen bzw. in Kosten bewerten), abhängig von
-
Systemkomplexität
Produktivität
aber auch
-
Schulungskosten (Aus- und Weiterbildung)
Steuern und lokale Abgaben
Materialkosten (Rechner, Rechenzeit, Tools etc.)
Projektnebenkosten (Reisekosten, Mieten, etc.)
Software (Betriebssysteme, Entwicklungswerkzeuge)
Zeit
Gesamte Zeitdauer
Zeitliche Abhängigkeiten
Infrastrukturvoraussetzungen (Räume, techn. Infrastruktur, Mieten für Büro, Kopierer, Telefon
..., Hardware (ggf. Rechenzeiten), Netzwerk)
dies kann ein erheblicher Kostenfaktor sein!
hier: Focus Entwicklungsaufwand & Zeit
247
Überblick
Vorgehensweise bei Aufwandsschätzungen
Ermittlung der geschätzten Personentage
Verteilung auf Mitarbeitertypen
Einheitliche Verrechnungssätze (keine Differenzierung notwendig)
Unterschiedliche Verrechnungssätze je nach Mitarbeitertyp (Erfahrung, etc.)
Mitarbeiterkosten = Personentage x Kosten
Hier unterschieden sich die Anforderungen innerhalb der Firmen z.T. erheblich
(was wird berechnet und wie)
248
Überblick
Ermittlung der Personentage
Schwierigster Teil der gesamten Projektplanung
Vorgehensweise grundsätzlich:
Basierend auf Erfahrungen aus der Vergangenheit werden die bekannten
Informationen bewertet und in Aufwände umgerechnet
Wichtig ist
eine möglichst gute Basis (was soll gemacht werden),
eine wiederverwendbare Vorgehensweise (welche Schritte werden durchgeführt, welche
Ergebnisse müssen erstellt werden) und
viel Erfahrung
Problem ist die unterschiedliche Produktivität je Mitarbeitern: Annahme von
„Standardproduktivitäten“
249
Überblick
Messen Systemkomplexität
Komplexitätsfaktoren
Größe: Anzahl der Bausteine
Diversität: Unterschiedlichkeit der Bausteine
Vernetzung: Abhängigkeit der Bausteine
Grundlagen der Softwareschätzung
Messung/Schätzung von Systemkomplexität
Komplexität, Aufwand, Laufzeit
Modellparameter: Projekt vs. Prozess
250
Überblick
Wie misst man Software ?
Softwaremetrik Code
Lines of Code
-
Ansatz: Software = Programmcode
Einheit: Lines of Code
Meßverfahren: Softwareumfang = Anzahl Programmzeilen
Anzahl von Klassen
Anzahl von Modulen, Prozeduren
Komplexitätsmetriken
funktionale Maße
Anzahl der Masken
Anzahl der Verarbeitungsabläufe, Geschäftprozesse
Datenflüsse
251
Überblick
Code als Komplexitätsmaß
Verbesserung: Standardisierte Code-Zeilen
Größe: Zählregeln
Diversität: Sprachebene (Assembler, Prozedural, Objektorientiert)
Vernetzung: Nicht berücksichtigt
Problem:
Implementierungsmaßzahl
Konsequenz: Erst nach Codierung anwendbar
252
Überblick
Weitere Metriken
Komponentenmetriken:
I.A. Metriken „algorithmischer“ Komplexität
Halstead: Anzahl (verwendeter) Operatoren/Operanden
McCabe: Anzahl Knoten/Kanten Kontrollflussgraph
OO-Metriken: Anzahl Vererbungsstufen, Attribute, Methoden
Vorteile:
I.A. einfache bzw. automatisierbare Zählverfahren
Operieren auf Code/abstrahiertem Code
Einschränkung:
Erst auf Implementierungsebene einsetzbar
Fokus auf Implementierungsgüte
253
Überblick
Komplexität und Prozess
Verschiedene Maße in verschiedenen Phasen
Implementierung: Codezeilen
Post-Architektur (Feindesign): Abstrakter Code
Prä-Architektur: Funktionspunkte
254
Überblick
Klassen von Verfahren
Algorithmische Methoden:
Grundlage: Formeln, deren Strukturen und Konstanten empirisch sind und mit
Hilfe mathematischer Modelle bestimmt werden
Vergleichsmethoden:
Grundlage: Vergleich früherer Entwicklungen mit dem aktuellen Projekt;
Einsatz: speziell in sehr frühen Projektphasen
Kennzahlenmethoden:
Grundlage: Ableitung von Kennzahlen aus früheren Entwicklungen zwecks
Bewertung von Schätzgrößen für das geplante Projekt
255
Überblick
Weitere Strategien zur Aufwandschätzung
Parkinson’sches Gesetz:
besagt, daß sich die Arbeit soweit ausdehnt, daß die verfügbare Zeit verbraucht wird;
d.h.:
Projektkosten richten sich nach verfügbaren Resssourcen.
Beispiel: Wenn die SW in 12 Monaten geliefert werden muß und 5 Mitarbeiter verfügbar
sind, wird der Aufwand auf 60 Personenmonate geschätzt.
“Pricing to win”:
Die Kosten werden nach dem zur Verfügung stehenden Budget des Kunden
geschätzt und die Anforderungen werden dem Budget angepaßt.
256
Überblick
2 mögliche Ansätze für Aufwandsschätzungen:
Top Down Ansatz
Schätzung für Gesamtprojekt, Verteilung (z.B. über Prozentsätze) auf die einzelnen
Projektphasen und Ergebnisse
Bottom Up Ansatz
Schätzung für die Ergebnisse „auf unterer Ebene“ Aggregation nach oben (unter
Hinzufügung von Integrationsaufwand)
Zunächst wird der Aufwand für jede einzelne Komponente bestimmt. Der
Gesamtaufwand resultiert aus der Summe aller Teilaufwände.
I.d.R. wird ein gemischter Ansatz benutzt!
257
Überblick
Kommentare
Anmerkung:
große Projekte bedürfen mehrerer unabhängiger Schätzungen.
Sollten diese stark divergieren, mangelt es an notwendigen Informationen,
die zunächst eingeholt werden müssen (z.B. Anforderungen genauer
formulieren, Prototyping, ...).
zugrundeliegende Annahme aller Verfahren und Strategien:
die Schätzung beruht auf einer fixen Anforderungsdefinition;
Problem der Praxis: oft ist eine Schätzung vor der detaillierten Erhebung der
Anforderungen notwendig, da letztere bereits hohe Kosten verursacht.
Praxis: oft sind die Kosten statt der Anforderungen fix.
258
Überblick
Schätzmethoden
X Methode kann in dieser Phase eingesetzt werden
(X)* nur für ausgewählte Module
1)
Schätzungen während den Projektphasen
Grobe Schätzug
(vor & während Startphase)
Detaillierte Schätzung
(Planungsphase)
weitere Detaillierung
(Durchführungsphase)
Analogieschätzungen
Multiplikatormethode
X
(X)*
(X)*
Prozentsatzmethode
X
(X)*
(X)*
Delphi-Methode
(top-down)
X
(X)*
(X)*
Informelle Expertenschätzung
(top-down und bottom-up)
X
X
X
X
X
Cocomo
X
X
Function Point
X
X
2)
Expertenschätzungen
Drei-Punkt/Zeit-Schätzung
(bottom-up)
3)
Fortgeschrittene Methoden
259
Analogieverfahren
Analogieverfahren
Klasse: Vergleichsverfahren
Charakteristika:
basiert auf Aufzeichnungen von Ist-Werten vergleichbarer, abgewickelter Projekte
desselben Unternehmens;
sorgfältige Kostenanalysen abgeschlossener Projekte liefern benötigte Informationen
(“Erfahrungsmaterial”);
Ist-Werte werden mit entsprechenden Korrekturfaktoren multipliziert.
besonders geeignet
wenn neues System zum Großteil aus existierenden Komponenten besteht und/oder
Analogien zu ähnlichen Bauteilen hergestellt werden können;
im Anfangsstadium eines Projektes;
260
Analogieverfahren
Dazu: Strukturvorschlag für eine Projekt-Erfahrungsdatenbank
(Cost-Database):
Projektkurzbeschreibung:
Name, Beginn-, Ende-Datum, Fachgebiet
Aufgabenstellung (Neuentwicklung, Wartung)
Arbeitspakete (Leistungsbeschreibung)
Ergebnisse:
Anzahl der Anweisungen (Befehle, Konstante, LOC)
Anzahl A4-Seiten (je Projekt-, Produktdokumentation)
Anzahl der Module, durchschnittliche Modulgröße
Anzahl der Fehler (je Fehlerart)
261
Analogieverfahren
Analogieverfahren
Aufwand:
Anzahl Personenmonate, Anzahl Mitarbeiter (je Qualifikation)
Anzahl der Rechenstunden für die Entwicklung
Verteilung der Personenmonate/Rechenstunden im Verlauf
Aufwand pro Fehler (je Fehlerart und Bearbeitungsart)
Eingesetzte Hilfsmittel für
Entwerfen,
Implementieren,
Planen,
Dokumentation.
Umgebungsbedingungen, Randbedingungen, Erkenntnisse
Betriebssystem, Einflüsse durch Organisation, Rechenzentrum
Schätzabweichungsanalyse und Dokumentation
Klare Kennzahlen, z. B. Kosten pro Personenmonat,...
Besonderheiten des IS-technischen Lösungsweges
262
Analogieverfahren
Analogieverfahren
Einflußfaktoren:
Bewertung nach vorgegebener Skala!
Detaillierungsgrad der Anforderungen .. F(a)
Komplexität der Aufgabe .. F(b)
Erfahrungsstand der Projektmitarbeiter .. F(c)
geforderte Qualitätsmerkmale des Produktes .. F(d)
Hilfsmitteleinsatz .. F(e)
Weitere Bedingung für optimalen Einsatz des Analogieverfahrens:
- klare Gliederung der Arbeitspakete
263
Analogieverfahren

Ablauf des Analogieverfahrens (Multiplikatormethode):
1.
2.
3.
4.

Risikoanalyse aufgrund der Einflußfaktoren:
Risikoklasse in % = (vorhandener Skalawert / max. Skalawert) x 100
Schätzen der Aufwände für Arbeitspakete
Definition von Bezugsgrößen wie z. B.: Anzahl der Ziele, LOC, Komponenten, Testfälle,
Seiten an Dokumentation
Berechnung des Personen-Monat-Aufwandes PM(P0)
pro Paket mit Hilfe der Werte aus der Cost-Database, z. B. unter Einsatz der Delphi Methode.
Modifikation der in Punkt 3 ermittelten Aufwände anhand ihrer Einflußfaktoren F(a) bis F(e):
PM(P1) = PM(P0) * F(a) * F(b) * F(c) * F(d) * F(e)
Beachte:
Das Analogieverfahren macht intensiven Gebrauch der Erfahrungsdaten eines Unternehmens
(Cost-Database).
Die erfaßten Daten sind daher ausserhalb des betrachteten Entwicklungsumfeldes nur
beschränkt brauchbar.
264
Prozentsatzverfahren
Prozentsatzverfahren (Extrapolation) :
Klasse: Kennzahlenverfahren
Charakteristikum:
basiert auf einem genau definierten Entwicklungsverfahren,
für dessen einzelne Phasen genaue prozentuale Anteilswerte vorliegen.
Aus den Aufwendungen für die einzelnen Phasen aus früheren Projekten werden durch
Extrapolation die Aufwendungen für neue Projekte geschätzt.
Voraussetzungen zur Anwendung des Prozentsatzverfahrens:
möglichst umfassende Vergangenheitswerte (dokumentiert); das verwendete
Extrapolationsverfahren muß in der Lage sein, zufällige Schwankungen einer Zeitreihe zu
glätten;
weitgehende Stabilität der Umweltbedingungen
Vorgehensmodell: Wasserfallmodell
265
Prozentsatzverfahren (Extrapolation)
Schwächen:
Hochrechnung mit relativ kleinen Werten (5%);
Verschiebungen der prozentualen Anteile aufgrund von Faktoren wie Projektgröße,
Projekttyp, Komplexität, etc.
primärer Einsatz:
Schnellanalyse von Projektaufwendungen;
Aufwand-Frühwarnsysteme:
-
Prüfung, ob Aufwand den vorgegebenen Prozentwerten entspricht;
nach Abschluß der ersten Phase
266
Beispiel einer möglichen Aufteilung der Projektzeit auf einzelne
Phasen der Projektabwicklung:
(“Planung”)
(“Requ.Analyse”)
(“Entwurf”)
267
Prozentsatzmethode
Aufwandsverteilung in %
Aufwandsverteilung in
Personentagen
Studie
6
53
Systementwurf
15
133
Programmentwurf
23
204
Kodierung/Modultest
35
310
Systemintegration/-test
21
186
Summe
100
886
Phase
268
Delphi-Verfahren
Delphi-Verfahren
Klasse: Vergleichsverfahren
Charakteristikum: systematische Befragung von mindestens zwei Experten, die
aus Erfahrung Voraussagen über den Zeitbedarf einzelner Aktivitäten machen.
zwei Varianten:
- Standard Delphi-Verfahren: Befragung anonym
- Breitband Delphi-Verfahren: Schätzergebnisse werden
gegenseitig bekanntgegeben, damit Resultate diskutiert
und ggf. korrigiert werden können
269
Delphi-Verfahren
Ablauf des Standard-Delphi-Verfahrens:
1.
2.
3.
4.
5.
6.
Der Projektleiter schildert jedem Experten das Projektvorhaben und übergibt ihm
ein Formular, auf dem die einzelnen Aufgabenpakete angeführt sind
Jeder Experte füllt das Formular aus; dabei dürfen Fragen lediglich mit dem
Projektleiter besprochen werden
Projektleiter analysiert die Angaben. Falls Schätzwerte eines Paketes stark von
einander abweichen, werden diese mit Kommentar auf neuem Formular erfaßt
Das neue Formular wird erneut zur selbständigen Überarbeitung an die
Experten gereicht.
Die Schritte 2-4 werden so lange wiederholt, bis die gewünschte Annäherung
der Ergebnisse erreicht ist, oder der Projektleiter die Ergebnisse akzeptiert
Der Durchschnittswert der letzten Überarbeitung der Ergebnisse aller
Aufgabenpakete stellt das endgültige Schätzergebnis dar.
270
Delphi-Verfahren
Ablauf des Breitband-Delphi-Verfahrens
4.
5.
6.
7.
1-3) Schritte 1-3 wie Standardverfahren, mit dem Zusatz, daß vor dem Ausfüllen
der Formulare eine Sitzung einberufen wird, in der alle Experten unter der
Moderation des Projektleiters über die zu erstellende Schätzung diskutieren
Der Projektleiter beruft eine Sitzung ein, in der die Teilnehmer über die
zurückerhaltenen Formulare diskutieren
Die Experten überarbeiten ihre Ergebnisse selbständig und übergeben diese
dem Projektleiter
Die Schritte 2-5 werden solange wiederholt, bis die gewünschte Annäherung
erreicht ist, oder der Projektleiter die Ergebnisse akzeptiert
Der Durchschnittswert der letzten Überarbeitung der Ergebnisse aller
Aufgabenpakete stellt das endgültige Schätzergebnis dar.
Anmerkung: Kostenverantwortung liegt beim Projektleiter!
271
Drei-Zeiten-Verfahren
Drei-Zeiten Verfahren (“Beta-Methode”)
Charakteristikum: für jede Tätigkeit wird deren
optimistische-, häufigste und pessimistische Dauer geschätzt
272
Drei-Zeiten-Verfahren (“Beta-Methode”)
Hauptanwendung: bei stark innovativen Verfahren, bei welchen Aufwände nur
ungenau bestimmt werden können.
Berechnungsbeispiel:
A
B
C
D
E
F
G
Tätigkeit
Erstellen der Vorstudie
Erstellen des Konzeptes
Erstelen des Pflichtenheftes
Erstellen der Detailstudie
Realisieren
Testen
Einführen
OD
3
8
6
10
12
9
10
HD
8
13
10
17
22
18
10
PD
10
15
22
22
26
32
14
MD
7,5
12,5
11,3
16,7
21
18,8
12,7
100,5
273
Gewichteter
Schätzwert (PERT) =
Optimistisch + 4 (Realistisch) + Pessimistisch
6
Pessimistisch − Optimistisch
=
6
Standardabweichung *
* für jeden Schätzwert
Gesamtunsicherheit
=
∑(S tan dardabweichung)
2
274
Work Breakdown Structure
Work Breakdown Structure (WBS) / Projektstrukturplan
Hierarchische Darstellung aller (Teil-) Ergebnisse, die zur Erzielung des
Projektergebnisses notwendig ist
Strukturierte Beschreibung der
relevanten Arbeitsschritte
(basierend auf Ergebnismustern)
Aufgliederung der Aufgaben zur
Zuweisung von Verantwortlichkeiten
Basis für Schätzung, Budgetierung,
Mitarbeiterzuweisung und auch Kontrolle
Historisch stark am „Produkt“ (= Endsystem)
ausgerichtet, jetzt zunehmend mehr am Prozess der Erstellung
275
Die WBS ist
ein Mittel, ein Projekt graphisch in Teile zu zerlegen und darzustellen
kein Terminplan
keine Abbildung der Projektorganisation
Verschiedene Gliederungsprinzipien
funktionsorientiert: z.B.: Funktionsblöcke - Teilfunktionen -Einzelaufgaben
phasenorientiert: z.B.: Phasen - Fachgebiete - Verantwortlichkeiten
objektorientiert: z.B.: Objekte/Blöcke - Funktionen
Meist werden Mischformen verwendet:
(z.B.: erste Ebene phasenorientiert, ab zweiter Ebene funktionsorientiert)
276
Aufbau der WBS
top-down: Projekt in Teile zerlegen
bottom-up: einzelne Aufgaben zu Blöcken zusammenfassen
kombiniert: Grobstrukturierung definieren, Aufgaben zuordnen und Blöcke
definieren
Jede Vorgehensweise hat ihre Vor- und Nachteile
Welche Methode gewählt wird, hängt letztendlich von den
verantwortlichen Projektmitarbeitern ab
277
Function – Point – Verfahren
Function - Point – Verfahren
Alan Albrecht, IBM 1981
Ziel: Messung Datenflusskomplexität
Größe: Anzahl der Datenflussschnittstellen
Diversität: Datenflussarten
Vernetzung: Gemeinsame Datenquellen/-senken
Verfahren:
Analyse aus Sicht der Systemumgebung
Messung über funktionale Schnittstellen
-
Externe Eingabe
Externe Ausgabe
Externe Anfrage
Interne Logische Dateien
Externe Logische Dateien
Systemfunktionen werden gezählt und bewertet
Bewertung in sog. Funktionspunkten
werden in Personenmonate umgerechnet
Methode ist gut anwendbar, weil sie funktionsorientiert arbeitet
Funktionen des geplanten Systems müssen vollständig beschrieben sein (Pflichtenheft)
278
Function - Point – Verfahren
Basis der Aufwandsschätzung ist die funktionsbezogene Bewertung von fünf ausgewählten
Funktionsbereichen. Der zu schätzende Aufwand hängt vom funktionalen Umfang des
Projektes und von dessen Komplexität ab.
Vorgehensweise:
Bestimmen der Funktionen, d.h. Quantifizierung des Projektumfangs durch die Ermittlung von „Function“
Gewichten der Funktionen, d.h. Bewertung des Schwierigkeitsgrades der Funktionen durch „Points“
Berücksichtigung der Einflußfaktoren,
d.h. Analyse des Einflusses von 7
vorgegebenen Faktoren
Berechnen der Function Points,
d.h. Berechnung des bewerteten
Function Points
Ermitteln der Projekt- Aufwands,
d.h. mit Hilfe von historische Daten
279
Produkt-/Projektanforderungen
Funktionen
Einflußfaktoren
Klassifizierung
(einfach, mittel, komplex)
Bewertung der
Einflußfaktoren
Unbewertetete Function Points
Einflußfaktor
Function Points
des Projekts
als Basismaßzahl
für Funktionalität
Bewertete Function Points
Aufwand
MM
FP
Gesamtprojektaufwand (laut
Erfahrungskurve)
Abgeschlossene Projekte
(bewertet durch Function Point Analyse)
280

Bewertung des Produkt / Projekts nach Einflußfaktoren und Berechnung des
Value Adjustment Factors (Anpassung um ±30 %), z.B.:

Datenkommunikation, Verteilte Verarbeitung (inkl. Verteilter Daten)
Leistungsanforderungen (Antwortzeitverhalten)
Begrenzte Kapazität (stark belastetes System), Transaktionsrate
Benutzerfreundlichkeit
Berechnung der bewerteten Function Points
Ermittlung des mittleren Aufwands
Berechnung des spezifischen Aufwands
Prozentualer Abschlag für durchlaufene
Projektspezifische Korrektur-Faktoren, z.B.
Stabilität der Anforderungen, Erfahrung und Produktivität des Teams, Tools und Methoden,
Wiederverwendung
Spezielle Risiken (Verfügbarkeit der Teammitglieder, Zugang zu Informationen, Zulieferungen Dritter)

Aktualisierung der empirischen Daten
281
Zuordnung der Produktanforderungen zu Kategorien:
Die in dem SW-Produkt verwendeten Datenbestände:
Internal Logical File (eigener Datenbestand, der gelesen und geschrieben wird)
External Interface File (Datenbestand, der außerhalb des SW-Produkts gepflegt aber in
dem SW-Produkt verwendet wird)
Die Transaktionen auf diese Datenbestände:
External Inputs (Veränderung des internen Datenbestands)
External Outputs (Ausgaben, die eine Auswertung der Datenbestände erfordern)
External Inquiry (Abfragen, die ohne Auswertung gemacht werden können)
Klassifizierung der Funktionen (einfach, mittel, komplex)
Aufsummierung zu unbewerteten Function Points
282
Grundformel
Zahl der Eingabefunktionen/-daten (EF)
Zahl der Ausgabefunktionen/-daten (AF)
Zahl der Datenbestände (DB), d.h. intern gespeicherter Dateneinheiten/logische
Dateien
Zahl der Referenzdaten (RD), d.h. Schnittstellen zu externen Systemen
Zahl der Abfragefunktionen/-daten (AF)
¾ Jede Funktion wird mit Hilfe vorgegebener Tabellen nach den Kriterien „einfach“,
„mittel“ oder „komplex“ klassifiziert und mit dem entsprechenden Wert (i.e. Point)
aus der Tabelle versehen und anschließend werden die Points aller Funktionen
summiert:
¾ Unbewertete Function Points:
¾ UFP = a*EF + b*AF + c*DB + d*RD + e*AF
mit a,b,..., e Gewichtungsfaktoren
283
Ein-/Ausgabe
Eingabe bzw. Ausgabe von Umgebung an System
Logisch zusammenhängend
Benutzer- oder Kontrolleingabe bzw. -ausgabe
Eingabe: Verändert /erweitert internen Datenzustand
Ausgabe: Erhält Datenzustand, ist unabhängig von Benutzereingaben
284
Standardtabelle Eingaben
285
Standardtabelle Ausgaben
286
Datenbestände/Referenzdaten - logische Dateien
Benutzer- oder Kontrolldaten, die von Anwendung betreut oder gewartet wird
Gruppe von intern bzw. extern verarbeiteter Daten
Interne: Erzeugt, verwaltet oder bearbeitet
Externe: Von Außen zur Verfügung gestellt
287
Standardtabelle Datenbestände
288
Standardtabelle Referenzdaten
289
Externe Abfrage
Ein-/Ausgabekombination, jede Abfrage wird gezählt, die zu einem Suchen in
einem Datenbestand führt und das Ergebnis dem Benutzer sichtbar gemacht
wird.
Von Benutzer oder Systemumgebung
Eingabe löst sofortige Reaktion aus
Ändert Interne Logische Daten nicht
290
Standardtabelle Abfragen
291
Beispiel
292
Bisher wurde die Funktionszahl ausschließlich durch
Produkteigenschaften bestimmt
Der Projektaufwand unterliegt aber weiteren Einflußfaktoren im Projektumfeld,
d.h. Einflüsse, Randbedingungen und Qualitätsanforderungen, die den
Schwierigkeitsgrad des Vorhabens bestimmen
Diese werden durch einen „Einflußgrad“ bei der Aufwandsberechnung
berücksichtigt (Gewichtung)
0 kein Einfluß
1 gelegentlicher Einfluß
2 mäßiger Einfluß
3 mittlerer Einfluß
4 bedeutender Einfluß
5 sehr starker Einfluß
Der Einflußgrad bildet einen Korrekturfaktor zu der ermittelten Funktionszahl
293
Einflußfaktoren:
EF1: Verflechtung mit anderen Verfahren
EF2: Dezentrale Datenverwaltung und Datenhaltung
EF3: Transaktionsrate und Antwortzeitenverhalten
EF4: Transaktionslogik:
EF4.1: Schwierige Rechenoperationen
EF4.2: Umfangreiche Kontrollverfahren
EF4.3: Anzahl der Ausnahmeregelungen
EF4.4: Schwierige und komplexe Logik
EF5: Wiederverwendung in anderen Verfahren
(10%,20%,...,50%)
EF6: Datenbestandskonvertierungen
EF7: Benutzerbedienung, Usability
0–5
0–5
0–5
0 – 10
0–5
0 – 10
0–5
0–5
0–5
0–5
294
Vorgehen:
Einfluß der Systemkomplexität durch Berücksichtigung von 7
Komplexitätsgrößen/Einflußfaktoren (z.B. Transaktionsrate, Performanz, Online
Dateneingabe)
Gewichtung der Größen von 0 (keine Bedeutung) bis 5 bzw.10 (hohe Bedeutung)
Die Summe der bewerteten Function Points (BFP) ergibt sich als Produkt aus den
unbewerteten Function Points (UFP) und den Punkten der Einflußfaktoren (EF):
¾ ... Einflußfaktor (EF)
¾ EF = 0,70 + (0,01 * Summe der Gewichtungsfaktoren)
¾ ... daraus Berechnung der bewerteten Function Points
¾ BFP = UFP * EF
¾ ... somit können Einflußfaktoren +/-30% das Ergebnis beeinflußen
295
Berechnung der Funktionszahl
296
Berechnung des Einflußgrades und bewerteten Function Points:
297
Ermittlung des Aufwands
Die ermittelten Function-Points (Korrelationskurve) müssen nun in Aufwand
(Personentage) umgerechnet werden
Ablesen des voraussichtlichen Aufwandes direkt aus der Function -Point –
Kurve/Tabelle
Die Function - Point - Kurve ist eine durch Regressionsanalyse ermittelte
Kurve/Tabelle auf Basis von früheren Projekten, d.h. diese Kurve/Tabelle
repräsentiert in hohem Maße die gewonnenen Erfahrungen mit einer spezifischen
Entwicklungsumgebung.
Sie wird aus Function-Point Aufwandskombinationen berechnet
298
Ermittlung des Aufwandes
Der Aussagegehalt der Function - Point – Kurve / Tabelle steigt mit der Anzahl
der beobachteten realisierten Projekte, weil eine bessere Anpassung der Kurve
an die Beobachtungen vorgenommen werden kann.
299
Voraussetzungen für die Methodenanwendung
„brauchbare“ Aufwandskurve als Ausgangsbasis
Nachkalkulation bzw. Kalibrieriung, Entwicklung einer eigenen Aufwandskurve
(ca. 100 Projekte; Nachkalkulation ist sehr teuer)
iterative Projektplanung (FP-Methode erst in der Spezifikationsphase
aussagekräftig einsetzbar
Standardisierung des Schätzverfahrens.
Zählweise der Ein- / Ausgaben
Bewertung von Einflußfaktoren
¾ Methodenhandbuch schreiben
300
Vorteile der Function Point Analyse
Unabhängig von der Implementierungssprache
leicht erlernbar
mit wenig Aufwand anzuwenden
Einzelschätzungen sind gut nachvollziehbar
unternehmensspezifisch anwendbar
gute Anwenderkriterien
iterativ anwendbar, d.h. zunehmende Detaillierung
301
Nachteile der Function Point Analyse
Hohe Unsicherheit bei der Berechnung der Function Points
Komponenten einer Anwendung oft schwer zu bestimmen
Gewichtungsfunktionen allein aus Erfahrung abgeleitet
Bestimmung der Gewichtungsfaktoren schwierig
Einflußfaktoren beliebig wählbar
Wachsende Unsicherheit, je mehr der Schwerpunkt des Systems in einem
Bereich (z.B. bei Berechnungsfunktionen) liegt
Wiederverwendung (z.B. von Code) und Zulieferung werden nicht berücksichtigt
schwierige Abbildung der Schätzergebnisse auf einen Netzplan
summarischer Ansatz korrespondiert nicht direkt mit konkretem Problem
302
Umrechnungs-Kurve
(Erfahrung aus vorangegangenen Projekten)
MM
300,00
250,00
durchschnittlicher
Aufwand
200,00
Function Point Wert
150,00
100,00
50,00
00
00
20
00
18
00
16
00
14
00
10
12
0
0
80
0
60
0
40
20
0
0,00
FP
Kontrolle
durch andere Schätzmethode !
Schätzklausur
projektspezifische
Korrekturfaktoren
geschätzter
Projektaufwand
303
Nicht berücksichtigt:
Stabilität der Anforderungen
Erfahrung des Teams
fachlich bzgl. Aufgabengebiet (Domäne)
technisch bzgl. Entwicklungstechnologie
Produktivität des Teams
Teamgröße und -Struktur, mehrere Standorte, ...
Termindruck, Parallelisierung der Arbeiten
Tools und Methoden
Wiederverwendungs-Anteile
spezielle Risiken
Verfügbarkeit des Personals und von Ressourcen
Zugang zu Informationen
Zulieferungen Dritter
...
304
Fazit
Unterstützung der Methode bei Bestimmung der Funktionalität
Einbeziehung von und somit auch bessere Nachvollziehbarkeit durch Personen
ohne fundiertes technisches Wissen
Hohe Unsicherheit bei der Bestimmung
Weiterentwicklungen:
Feature Points (besser geeignet, wenn Schwerpunkt in einem Bereich liegt)
Object Points
…
305
CoCoMo
CoCoMo
Verfahren: Constructive Cost Modeling (CoCoMo)
Entwickler: Barry Boehm (1981)
Schätzung des Umfangs der Codezeilen (Korrelationskoeffizienz)
Charakteristikum: beruht auf einer Kombination von Gleichungen, statistischen
Modellen, und Schätzungen von Parameterwerten (z.B. mit der Delphi-Methode)
Anwendungsgebiete:
Informationssysteme (Honeywell, IBM,US Army)
Eingebettete System (AT&T, Boeing, Motorola)
Ansatz:
Eingabe:
-
Messung/Abschätzung der Systemkomplexität
Abschätzung von Prozessparametern
Ausgabe:
-
Abschätzung des Realisierungsaufwands
Abschätzung der minimalen Realisierungszeit
306
CoCoMo
Ausgangspunkt:
Das Modell basiert auf der Analyse von Daten aus vergangenen Projekten
Das Modell stellt eine Beziehung zwischen der Größe des zu erzeugenden
Software-Produktes und dem Aufwand in Personen-Monaten dar.
E = C1 * KLOCC2
mit
E geschätzter Aufwand
KLOC Kilo Lines of Code
C1, C2 Konstanten, die von der Art des betrachteten Projektes abhängen
genauer in KDSI :
KDSI .. Kilo Delivered Source Instructions (d.h. Kommentare werden nicht gezählt)
daraus werden berechnet:
E .. Entwicklungsaufwand (in Anz. der Personenmonate (PM)),
TDEV .. Entwicklungszeit (Time for Development, in Monaten)
307
CoCoMo
Bestimmungsgrößen
Anzahl der benötigten Codezeilen (Basisalgorithmus)
Komplexitätsgrade, die durch sog. Einflußfaktoren gesetzt werden
-
PREC: Güte der Organisation im Projekt
FLEX: Restriktivität gesetzter Anforderungen
RESL: Güte der Behandlung von Risikofaktoren
TEAM: Teamkompetenz und Motivation
PMAT: Qualität des Entwicklungsprozesses
20 Parameter zur Kalibrierung entsprechend Produkteigenschaften und
Entwicklungsvorgehen (Multiplikatoren)
308
CoCoMo
3 Modellvarianten:
Basismodell:
Einsatz in Frühstadium eines Projektes;
Projekt wird gesamtheitlich betrachtet;
Kosten- und Zeitaufwand werden nach einer Grundgleichung bestimmt;
dient als Ausgangspunkt weiterer Schätzungen.
Zwischenmodell:
berücksichtigt 15 Einflußparameter
Entwicklungsphasen werden nicht differenziert
Erweitertes Modell (“Detailmodell”):
berücksichtigt 15 Einflußfaktoren sowie
die Abweichungen der anteilsmäßigen Aufwände der einzelnen Entwicklungsphasen.
309
CoCoMo
Projektarten in CoCoMo:
einfache SW-Projekte (Organic mode):
kleines, gut harmonierendes Team arbeitet in bekannter Umgebung, Teammitglieder
haben Erfahrung in Umgang mit solchen Projekten, Innovationen in Architektur und
Funktionen des SW-Produktes sind minimal, Schnittstellen sind gering und stabil, auf den
Fertigstellungstermin wird wenig Druck ausgeübt,...
Produktgröße < 50 KDSI
mittelschwere SW-Projekte (Semi-detached mode):
Projekt stellt ein Mittelding zwischen Organic and Embedded dar
Produktgröße < 300 KDSI
komplexe SW-Projekte (Embedded mode):
starker Kosten- und Termindruck, große Innovation, hohe Anforderungen an das
Projektteam, eingebettet in äußerst komplexes Umfeld, hohe Anforderungen an die
Verfügbarkeit des SW-Produktes ... ;
Produktgröße: jede Größe
310
CoCoMo
Grundformel zur Ermittlung des Entwicklungsaufwandes:
E = C1 * KDSI C2 * ∏ Ei
wobei
C1 und C2 hängt von de Projektart und vom Projektmodell ab
Ei Einflußfaktoren mit i= 1 ..15 (“Kostentreiber”), wobei Ei = 1 im Grundmodell
Entwicklungszeit:
TDEV = C3 * EC4 mit
wobei
C1’ im Grundmodell
C1’’ sonst
311
CoCoMo
CoCoMo-Gleichungen
Aufwand:
OM: PM = 2,4 * (KLOC)^1,05
SDM: PM = 3,0 * (KLOC)^1,12
EM: PM = 3,6 * (KLOC) ^1,2
Entwicklungszeit:
OM: TDEV = 2,5 * (PM)^0,38
SDM: TDEV = 2,5 * (PM)^0,35
EM: TDEV = 2,5 * (PM)^0,32
Rechenbeispiel: 10.000 LOC
Semi Detached Model
-
PM = 3,0 * 10 ^ 1,12 = 39,54 PM
TDEV = 2,5 *39,54 ^ 0,35 = 9,05 CM
Embedded Model
-
PM = 3,5 * 10 ^ 1,2 = 55,44 PM
TDEV = 2,5 * 55,44 ^ 0,38 = 11,49 CM
312
CoCoMo
TDEV .. benötigte Entwicklungszeit in Monaten:
organic:
TDEV = 2.5 * E 0.38
semidetached: TDEV = 2.5 * E 0.35
embedded:
TDEV = 2.5 * E 0.32
Beispiele zu Produktgrößen, Personenzahl, Entwicklungszeit:
313
CoCoMo
Graphen zu COCOMO Aufwandschätzungen für
verschiedene Projektgrößen:
314
CoCoMo
Graph zur geschätzten Projektdauer in Abhängigkeit von
der Projektgröße (Kurve für alle drei Projektklassen
ähnlich):
315
CoCoMo
COCOMO Kostentreiber:
Kategorien: very low / low / nominal / high / very high / extra high
Attribute
Produkt-Attribute
-
RELY: Benötigte SW-Zuverlässigkeit
DATA: Umfang der Datenbasis
CPLX: Komplexität des Produkts
Computer-Attribute
-
TIME: Nutzung der verfügbaren Ausführungszeit
STOR: Nutzung des verfügbaren . Speicherplatzes
VIRT: Änderungshäufigkeit der Systembasis
TURN: Bearbeitungszyklus
Personal-Attribute
-
ACAP: Analysefähigkeit der Mitarbeiter
AEXP: Erfahrung der Mitarbeiter in dem Aufgabengebiet
PCAP: Programmierfähigkeit der Mitarbeiter
VEXP: Erfahrung d. Mitarbeiter in der Systemumgebung
LEXP: Erfahrung d. Mitarbeiter in d. Programmiersprache.
Projekt-Attribute
-
MODP: Verwendung mod. Entwicklungsmethode
TOOL: Verwendung von SW-Tools
SCED: Anforderungen an die Entwicklungszeit
316
CoCoMo
Kostenfaktor
Die Kostenfaktoren gehen multiplikativ in die Berechnung des Aufwandes ein:
E’ = E * ∏ cdriver
Für jeden Faktor existieren zwei Bewertungstabellen:
- eine kummulierte für das Zwischenmodell,
- eine nach Phasen aufgeschlüsselte für das Detailmodell:
Studie: PR (plans and requirements)
Systementwurf: PD (product design)
Programmentwurf: DD (detailed design)
Codierung und Einzeltest: CUT (code and unit test)
Integration und Systemtest: IT (integration and test=
317
CoCoMo
Beispieltabelle zur Phasen-Bewertung des Faktors TOOL:
318
CoCoMo
319
CoCoMo
Beispiel:
Aufwandsverteilung für die Klasse “einfache Projekte”:
320
CoCoMo
321
CoCoMo
Berechnungsbeispiel für das Zwischenmodell:
Ausgangspunkt:
komplexes Projekt
mit geschätzten 60 KDSI
Aufwandsschätzung:
E0 = 3.6 * 601.20 = 490 PM
TDEV = 2.5 * 490 0.32 = 18 Monate
N = 490/18 = 28 Mitarbeiter;
Korrektur der Basisaussage durch Einflußfaktoren:
RELY = 1.10, STOR = 1.30, MOD = 1.05, SCED = 1.15,
ACAP = 0.55; übrige Einflußfaktoren sind alle = 1;
E1 = 490 * 1.10 * 1.30 * 1.05 * 1.15 * 0.55 = 566 PM
322
CoCoMo
Kommentar zur benötigten Personenzahl:
Vorsicht: N = E/TDEV gibt nur einen groben Durchschnittswert, da die Anzahl im
Projektverlauf schwankt!
Vorschlag von Putnam (1978):
der optimale Mitarbeiterstand folgt einer Rayleigh-Kurve:
Beispiele zu Rayleigh-Kurven:
323
CoCoMo
Folgerungen:
Bei einer kleinen Produktgröße vermag eine Person mehr Codezeilen (LOC) pro
Zeiteinheit zu schreiben, als bei einem großen Produkt.
Die Entwicklungszeit nimmt anteilsmäßig ab, je größer ein Produkt ist.
Aufwandsverteilung:
Unterscheidung von 5 Entwicklungsphasen mit verschiedenen Anteilswerten,
abhängig von Projektklasse;
Da bei COCOMO die erste Phase bereits abgeschlossen sein muß, liegt sie
außerhalb des Modells; ihr Aufwand wird daher zu den restlichen vier Phasen
addiert.
324
CoCoMo
Tabelle zur Illustration des gewichtigen Anteils der (subjektiven)
Schätzungen der Einflußparameter am Gesamtergebnis:
325
CoCoMo
Anmerkungen zu COCOMO
für die Bewertung des Zwischenmodells sind viele Parameter unbekannt;
Ergebnisse können daher nicht mit anderen Verfahren verglichen werden.
primäre Kritik an COCOMO:
zu viele Parameter
starke Umgebungsabhängigkeit,
viele subjektive Elemente
326
CoCoMo
Kalibrierung des Modells:
Notwendig für einen erfolgreichen Einsatz in einer Organisation.
Vorgehen:
Vergleich tatsächlicher und geschätzter Kosten;
Anwendung der Methode der kleinsten Quadrate zur Approximation der geschätzten und
tatsächlichen Kosten;
Anpassung des konstanten Faktors in der Gleichung für den Aufwand (E);
Anpassung der Einflußfaktoren:
-
-
die von Boehm vorgeschlagene Liste sollte nach Bedarf angepaßt/ergänzt/verkürzt werden;
Vorgehen zum Auffinden der Wertetabelle für neue Faktoren:
» Schätzen des Aufwandes ohne Einsatz des entsprechenden Parameters,
» dann: Messung der aktuellen Kosten, dann: finden des besten Faktors so, daß geschätzter
und gemessener Aufwand übereinstimmen
Problematik: Faktoren sind oft nicht unabhängig voneinander ...
327
CoCoMo
Fazit
Einsatz für Grobschätzungen nach Abschluss der Analysephase
Verbesserung der Ergebnisse bei Aufteilung des Gesamtprojekts in kleinere
Einzelprojekte, die einzeln geschätzt werden
Erfahrungen zeigen Abweichungen der Schätzungen vom tatsächlichen Aufwand
um den Faktor 4
Weiterentwicklungen:
Ada COCOMO
COCOMO II
328
CoCoMo
CoCoMo II
Beobachtung:
Schätzung stark abhängig von
-
Eigenschaften zu erstellendes System
Eigenschaften erstellendes Unternehmen
Unterschiedliche Parameter:
-
-
Linear (Frühes Design): Projektorientiert
» Mensch: Qualifikation Personal
» Technik: Produktgüte, Legacy, Plattform, Entwicklungsumgebung, Zeitplan
Exponentiell: Prozessorientiert
» Technik: Randbedingungen, Risikomanagement, Prozessreife
» Mensch: Erfahrung, Kohäsion
329
CoCoMo
CoCoMo II Modellgleichungen
Parameter:
Aufwandsfaktor EM aus Einzelfaktoren EMi
Skalierfaktor B aus Einzelgewichten Wi
Grundfaktor A
Zeitplanfaktor SCED%
Gleichungen
Skalierfaktor: B = 0,91 + 0,01 * Summe(Wi)
Grundaufwand: PMGrund = A * Größe(FPA) ^ B
Aufwandsfaktor: EM = Produkt(EMi)
Gesamtaufwand: PMGesamt = EM * PMGrund
Laufzeit: TDEV = [3,67 * PMGesamt ^(0,28+0,2*(B-1,01))] * SCED%/100
331
CoCoMo
CoCoMo II - Aufwand
Generell:
Auswirkung des exponentiellen Faktors Prozess
-
Faktor > 1
“Diseconomy of Scales”
332
CoCoMo
Komplexität und Produktivität
Ziel Schätzung:
Bestimmung Realisierungsaufwand
Bestimmung Realisierungszeit
Produktivität:
Bestimmung Mitarbeiterzeit/Systemeinheit
Berechnung: „Aufwand = Produktivität * Größe“
Beobachtung:
-
Durchschnittl. Produktivität: 5 FP/PM
IS-Produktivität: 8 FP/PM
ES-Produktivität: 4 FP/PM
333
CoCoMo
Komplexität und Produktivität
Produktivität beeinflußt:
Durch administrativen Aufwand
Durch personellen Aufwand
Durch Abstimmungsaufwand
334
CoCoMo
Realisierungsaufwand und Laufzeit
Ziel Schätzung:
Bestimmung Realisierungsaufwand
Bestimmung Realisierungszeit
Intensität:
Bestimmung „Projektlaufzeit/Aufwand“
Berechnung: „Laufzeit = Intensität * Aufwand“
Beobachtung:
-
Laufzeit polynomial in Aufwand
Laufzeitvorgaben beeinflussen Aufwand
Maximale Laufzeitverkürzungen: 70-75%
335
CoCoMo
Realisierungsaufwand und Laufzeit
Laufzeit beeinflusst Aufwand:
Durchschnittliche Laufzeit minimiert Aufwand
Zusätzlicher Aufwand erlaubt Kürzung (70%)
Erhöhte Laufzeit verringert Aufwand nicht
336
CoCoMo
Aufwandsfaktoren
Projektparameter
Parameter wirken linear auf Aufwand
Arten von Parameter:
-
-
-
Produktfaktoren, z.B.:
» Zuverlässigkeit
» Anforderungen an Dokumentation
» Vorbereitung Wiederverwendung
Personalfaktoren, z.B.:
» Fluktuation
» Anwendungserfahrung
Projektfaktoren:
» Werkzeugeinsatz
» Zeitplan
Beeinflussung:
-
Technisch, projekttechnisch
Konsequenz: Beeinflussung durch Projektmanagement
337
CoCoMo
Skalierfaktoren
Prozessparameter
Faktoren wirken exponentiell auf Aufwand/Laufzeit
Arten von Faktoren:
-
Portfolio: Projektdomäne vs. Unternehmens-know-how
Prozess: Vorgaben, Reife, Risikomanagement
Personal: Teamkohäsion
Beeinflussung Prozessparameter:
-
Marktstrategisch: Projektauswahl
Unternehmensstrategisch: Entwicklungskultur
Personalstrategisch: Personalkultur
Konsequenz: Beeinflussung durch Unternehmensmanagement
338
CoCoMo

Vorteile von COCOMO
Geeignet für schnelle, grobe Schätzungen der anfallenden Kosten
Gute Ergebnisse bei kleineren Projekten, die in einer bekannten Entwicklungsumgebung
durchgeführt werden (Vergleichbarkeit mit bereits durchgeführten Projekten ist gegeben)
Abdeckung des Gesamtprojekts angefangen bei der Designphase bis hin zur Testphase (z.T.
durch Erfahrungswerte wie 10% Management, 10% Infrastrukturaufwand)

Nachteile von COCOMO
Wesentliche Einflussgrößen auf den Projektaufwand bleiben unberücksichtigt:
notwendige Entwicklungshardware
Einsatz moderner CASE-Tools
spezielle Fähigkeiten der Mitarbeiter
Qualität des Management
Qualität der Benutzerschnittstelle
Vergleichbarkeit mit bereits durchgeführten Projekten nicht immer gegeben
viele im voraus zu bestimmende Einflussfaktoren
339
Zusammenfassung
Zusammenfassung
Drei Merksätze zur Schätzung
Funktionelle Abhängigkeit kann Code als Komplexitätsmaß ersetzen.
Entwicklungsaufwand wird von Projektfaktoren linear, von Prozessfaktoren exponentiell
beeinflusst.
Laufzeit kann bei Mehraufwand maximal auf 70-75% gekürzt werden.
Zwei Warnungen zur Schätzung:
Detaillierung bestimmt Genauigkeit (20-50%)
Modelle benötigen Kalibrierung
340
Zusammenfassung
Bedeutung von Schätzungen für das Projektmanagement
Basis für alle wichtigen Projektentscheidungen
Alle „mathematischen“ Verfahren haben starken Einfluss von persönlicher
Erfahrung (meist Erfahrungen des Unternehmens, nicht nur des
Projektmanagers)
Verfahren haben sehr viele Stellschrauben, die vorsichtig eingesetzt werden
müssen
Ergebnisse einer Schätzung (Aufwand und Zeit) ist politisch meist zu hoch/zu
spät, Korrekturen müssen strukturiert und durchdacht angegangen werden
Review durch Kollegen/Experten ist unabdingbar
341
Kapitel 4:
Schätzverfahren
Projektplanung
342
4.2 Projektplanung
Variablen mit Einfluss auf den Entwicklungsprozess
Zielvariablen
Beschreiben die Zielsetzung während der System-Entwicklung (e.g. minimale
Entwicklungszeit, maximale Qualität, minimale Kosten)
Kontrollvariablen
Beschreiben die Einflussfaktoren, die vom Projekt-Management aktiv beeinflusst werden
können (z.B. verwendete Tools, Projekt-Organisationsform,
Unkontrollierbare Variablen
Beschreiben den Einfluss “von außen” auf das Projekt
Diese Variablen entziehen sich der Beeinflussung durch das Projekt-Management (z.B.
Erfahrung der Benutzer, Organisatorische Änderungen im Unternehmen)
343
4.2 Projektplanung
Typische Planungsfehler
Pläne verlangen zu viel in zu kurzer Zeit
Pläne basieren auf unrealistischen Wunschterminen
Das Senior Management hält an den Wunsch fest, obwohl eine realistische
Planung andere Termine ergeben würde
Pläne werden nicht mit Betroffenen abgestimmt
Niemand hat geprüft, ob die zugrunde liegenden Personaleinsatzanforderungen
erfüllt werden können
Schätzungen sind zu optimistisch und basieren nicht auf Erfahrungen
Verschiedene spätere Arbeiten lassen sich jetzt noch gar nicht abschätzen,
sondern erst z.B. nach dem Design (Management will aber jetzt eine Festlegung)
etc.
344
4.2 Projektplanung
Planungsintensität in den Projektphasen
345
4.2 Projektplanung
Übersicht Planungsschritte
346
4.2 Projektplanung
Übersicht Planungsdokumente
Planungsschritte
Dokumente
Projekt-umfang
und Meilen-steine
festlegen
Projektziele
E*
Projektdefinition
E*
Projektorganisation
E*
Projektspezifisches Vorgehensmodell
E*
Anforderungsspezifikation
E*
Projekt-strukturplan erstellen
Größen-, Aufwands-,
und Kostenschätzungen
durchführen
Aktivitäten-zeitplan
aufstellen
Ü
Ü
Ü
Projektstrukturplan
E
Ü
Ü
Arbeitspaketbeschreibung
E
Ü
Ü
Kosten-planung
aufstellen
347
4.2 Projektplanung
Übersicht Planungsdokumente
Planungsschritte
Dokumente
Projekt-umfang
und Meilen-steine
festlegen
Meilensteinplan
Projekt-strukturplan erstellen
Größen-, Aufwands-,
und Kostenschätzungen
durchführen
E
Aktivitäten-zeitplan
aufstellen
Ü
Schätzdokument
(Größen, Aufwand,Kosten)
E
E
Aktivitätenzeitplan
E
Kostenplan
Projektplan
Kosten-planung
aufstellen
E
A
A
A
A
Legende:
E: (Erstellen) Das Dokument wird in diesem Schritt erstellt.
E*: Dokument wird erstellt bzw. angepasst, abhängig davon, ob es schon in der Phase Projektstart erstellt
wurde.
Ü: (Überarbeiten) In diesem Schritt wird das Dokument überarbeitet.
348
A: (Anpassen) Das Dokument wird an die Projektbedürfnisse angepasst bzw. ergänzt.
4.2 Projektplanung
Vorbedingungen für effektive Projektkontrolle
Die Projektleitung muss sich über die Ziele des Systems im Klaren sein
Die Projektleitung muss genügend Spielraum für die Kontrolle haben (i.e. Anzahl
der Kontrollvariablen, Ausmaß in dem die Kontrollvariablen verändert werden
können)
Die Projektleitung muss die aktuellen Informationen über den Stand des Projekts
haben
Die Projektleitung muss über ein konzeptuelles Modell des zu kontrollierenden
Systems verfügen
Mit anderen Worten, die Projektleitung muss wissen, wovon die einzelnen
Kontrollvariablen abhängen und in welcher Weise sie einander gegenseitig
beeinflussen
349
4.2 Projektplanung
Regelkreis des Projektmanagements
350
4.2 Projektplanung
Planungstechniken
Ziele:
Überblick über den Projektablauf
Vorbereitung der Projektdurchführung
Zeitschätzung und Terminbestimmung
Planung der Vergabe von Ressourcen
Resultate dienen als:
Entscheidungs-, Steuerungs- und Kontrollunterlagen;
Inhalte:
Definition Aufgabe: Was ist zu tun?
Definition Vorgaben/Hilfsmittel: Wie ist es zu tun?
Definition Termine: (Bis) Wann ist es zu tun?
Definition Verantwortung: Wer hat es zu tun?
Durchführung der Planung: Wiederholt
Projektinitiierung
Projektdurchführung: Neuplanung bei
-
Detaillierung Produktstruktur
Änderung Terminlage
Änderung Personallage
Änderung Ressourcenlage
351
4.2 Projektplanung
Wirkung des Planungsaufwands
352
4.2 Projektplanung
Projektplan
Funktion: beschreibt aktuellen Planungsstand (Soll-Werte)
Vorbereitung Ressourcenbereitstellung
Vorbereitung Kontrolle/Steuerung
Bestandteile von Projektplänen
Zusammenfassung mehrerer Vorgänge zu einer Phase
Festlegung von Meilensteinen als Abschluss von Phasen oder Vorgangsgruppen:
-
Null-Dauer
Überprüfbarkeit: Teilprodukt ist fertiggestellt
Kurzfristigkeit: kurze Zeitdauer zwischen Meilensteinen
Gleichverteilung: kontinuierliche und gleiche Verteilung
Abhängigkeiten zwischen Meilensteinen und Vorgängen:
-
fachliche
terminliche Integration in Netzplänen
personelle
Elemente (Planung):
Projektstrukturplan
Terminplan
Personalplan
Ressourcenplan
Zusätzlich: Ist-Werte Projekt
353
4.2 Projektplanung
Projektstrukturplan
Projektstrukturplan oder Work Breakdown Structure
siehe auch Aufwandsabschätzung
Ziel:
Erfassen der Abhängigkeiten im Projektverlauf
Vorbereiten der Aufwands- und Zeitplan
Idee:
Zerlegung des Projekts solange in Teilaufgaben, bis diese umsetzbar sind
Die einzelnen umsetzbaren Teilaufgaben werden mit Meilensteinen für Beginn und Ende
versehen (und deren Erreichung überprüft)
Ist
ein Mittel, ein Projekt graphisch in Teile zu zerlegen und darzustellen
kein Terminplan
keine Abbildung der Projektorganisation
354
4.2 Projektplanung
Projektstrukturplan
Projektstrukturplan
355
4.2 Projektplanung
Projektstrukturplan
Typen von Projektstrukturplänen
Objektorientierter Projektstrukturplan
Definition der Aufgabenpakete nach der technischen Struktur des Projektes
z.B.: Objekte/Blöcke - Funktionen
Hausbau: Keller, Erdgeschoss, Dachgeschoss
Funktionsorientierter Projektstrukturplan
Definition nach Entwicklungsfunktionen (Bereichen)
z.B.: Funktionsblöcke - Teilfunktionen - Einzelaufgaben
Hausbau: Rohbau, Ausbau
Ablauforientierter Projektstrukturplan
Definition gemäß Entwicklungsprozeß
z.B.: Phasen - Fachgebiete - Verantwortlichkeiten
Hausbau: Planung, Umsetzung
¾ Meist werden Mischformen verwendet
(z.B.: erste Ebene phasenorientiert, ab zweiter Ebene funktionsorientiert)
356
4.2 Projektplanung
Projektstrukturplan
Projektstrukturplan
Projektprozessauswahl
Auswahl von Phasenkonzept oder Vorgehensmodell
z. B. IT-Projekt im öffentlichen Bereich nach V-Modell
Tailoring: projektspezifische Anpassung und Detaillierung
Erstellung: Instantiierung Prozessmodell
Produktstruktur: Erfassen/Festlegen der Teilprodukte und ihrer Abhängigkeiten
Ablaufstruktur: Festlegen der Vorgänge abhängig von der Produktstruktur
Elemente:
Phasen (entsprechen Prozessphasen)
hierarchische Strukturierung der Aufgaben
Vorgänge (konkretisieren Prozessaktivitäten)
Meilensteine (entsprechen Prozessereignissen)
357
4.2 Projektplanung
Meilensteine
Meilensteine:
Ziel: Ermöglichen die Projektkontrolle
Gezieltes Erkennen der Projektverzögerung
Rechtzeitiges Erkennen der Projektverzögerung
Entsprechen synchronisierenden Projektereignissen
Projektstart, Projektende,
Vorgangsende
Daher: Geknüpft an Erstellung eines (Teil)Produkts
Dichte: Relativ zur Gesamtlaufzeit: Abstände bis zu vier Wochen
Gleichverteilung: ungefähr gleiche Abstände
Eigenschaften:
Überprüfbarkeit: Objektive Kriterien
-
„Systemarchitektur liegt vor“
Testdrehbuch mit 10 Testfällen liegt
Nicht: „Implementierung zu 80% abgeschlossen“
358
4.2 Projektplanung
Meilensteine
Achtung: 90%-Syndrom!
359
4.2 Projektplanung
Projektablaufplan
Projektablaufplan
Abhängigkeiten
zwingende Folge
empfehlende Folge
freie Folge
Verschiedene Ablaufplänen mit unterschiedlichem Informationsgehalt
Linearpläne
Netzpläne
360
4.2 Projektplanung
Darstellungen
Projektablaufplan - Darstellungstechniken
Listungstechnik
nur bei kleinen (Linear-)Plänen sinnvoll einsetzbar
Terminlisten:
Workpackages (Vorgangslisten), von außen vorgegebene Termine
Netzplantechnik,
zusätzlich technologische Abhängigkeiten
z. B.
-
Vorgangspfeilnetzplan
Vorgangsknotennetzplan
Ereignisknotennetzplan
Balkendiagrammtechnik
zusätzlich je Teilaufgabe Start- und Endtermin bzw. Dauer
z. B.
-
Gantt-Diagramm
PLANNET-Diagramm
Vernetzte Balkenpläne
zusätzlich einfache Abhängigkeiten zwischen Vorgängen
361
4.2 Projektplanung
Terminlisten
Terminlisten
Enthält Liste der Aktivitäten bzw. Vorgänge
Zu jedem Vorgang wird die Liste der beteiligten oder verantwortlichen Personen
angegeben
Weiter wird (meist) eine Deadline für jeden Vorgang definiert
Zusätzlich kann eine Liste der Meilensteine existieren bzw. eine separate Liste
von außen vorgegebener wichtiger Termine (Deadlines)
362
4.2 Projektplanung
Netzplantechnik
Netzplantechniken
Ziel
Terminplanung für Vorgänge/Ereignisse
Berücksichtigung der Abhängigkeiten (evtl. Varianten)
Kennzeichen
umfassendes Planungsinstrument für komplexe Projekte
bietet übersichtlichen Überblick über den Projektablauf, inklusive der eindeutigen Darstellung der
Abhängigkeiten einzelner Vorgänge im Ablauf
ermöglicht genaue Zeitschätzung bzw. Terminfestlegung für
den Gesamtablauf sowie für einzelne Vorgänge
Erkennen der zeitintensivsten Ablauffolge: “kritischer Weg”
ermöglicht relativen Vergleich der Konsequenzen von Terminen, Kosten und Einsatzmitteln verschiedener
Planungsvarianten
fördert rechtzeitige Entscheidungen, da mögliche Konsequenzen im Netzplan ersichtlich sind.
Netzpläne bieten, dank komplexer Methoden um Abhängigkeiten zwischen Vorgängen darzustellen, die
umfangreichste Information über Projekte.
Diese Information muss allerdings auch zuverlässig und vollständig erhoben werden können.
363
4.2 Projektplanung
Netzplantechnik
Netzplantechniken
Netzplantechnik ist geeignet für:
- Strukturplanung
- Zeitplanung
- Einsatzmittelplanung
- Kostenplanung
bewährte Arten von Netzplänen:
- CPM: Critical Path Method
- PERT: Program Evaluation and Review Technic
- MPM: Metra-Potential-Method
zahlreiche Softwareprodukte unterstützen den Einsatz der Netzplantechnik; oft:
Zusammenfassung verschiedener Arten von Netzplänen; daher: Vorsicht auf
Konsistenz!
364
4.2 Projektplanung
Netzplantechnik – CPM
Erstellen der Tätigkeitsliste als Grundlage jedes Netzplans:
entsprechend der Projektstruktur werden alle Teilprojekte in Einzeltätigkeiten
zerlegt;
für jede Tätigkeit : Definition der
erforderlichen Vorbedingungen (Abschluß anderer Tätigkeiten)
voraussichtlichen Dauer
ggf. der direkten Nachfolgetätigkeiten
Erstellung der Tätigkeitsliste (auch “Vorgangsliste”)
Beispiel siehe nächste Folie
365
4.2 Projektplanung
Beispiel:
Tätigkeiten mit Zeitangaben und Vorgängerrelationen
366
4.2 Projektplanung
Netzplantechnik
Netzplantechniken
Netzplanvarianten:
Vorgangsknotennetzplan (z.B. MPM)
-
Knoten (meist Rechtecke) sind Vorgänge (Ereignisse)
Kanten sind benötigte Ressourcen/Produkte (Abhängigkeiten, Beziehungen)
Vorgangskantennetzplan (z.B. CPM), auch Vorgangspfeildarstellung
-
Knoten (meist Kreise) sind Ereignisse
Kanten/Pfeile sind Vorgänge
Schwerpunkt: Vorgang ( = Tätigkeit) mit Dauer
Ereignisknotennetzplan (z.B. PERT)
-
Knoten (meist Kreis) sind Ereignisse
Kanten/Pfeile sind Abhängigkeiten, Beziehungen
Schwerpunkt: Ereignis: beschreibt Projektzustand, Zustandsübergang kann mehrere Vorgänge
umfassen, die nicht näher beschrieben werden.
367
4.2 Projektplanung
Netzplantechnik
Vorgangsknoten Netzpläne - Activity on Node (AoN)
Knoten: enthalten Vorgänge, Vorgangsnummern und Dauern
Kanten: beschreiben die Anordnungsbeziehungen zwischen den Vorgängen
Vier Anordnungsbeziehungen zwischen Vorgängen
Normalfolge (Ende-Anfang Beziehung)
Anfangsfolge (Anfang-Anfang Beziehung)
Endfolge (Ende-Ende Beziehung)
Sprungfolge (Anfang-Ende Beziehung)
368
4.2 Projektplanung
Netzplantechnik
Vorgangsknotennetzplan - Beispiel
369
4.2 Projektplanung
Netzplantechnik - Vorgangsknotennetzplan
Vorgangsknotennetzplan KNP = (A,R,a,A,e,E)
A = {a1,...,am} Menge der Aktivitäten im Projekt mit
-
Dauer einer Aktivität d(a)
Frühest/spätest möglicher Beginn b(a)/B(a)
Frühest/spätest mögliches Ende e(a)/E(a)
p(a) Pufferzeit
R = { r1,...,rn } ⊆ A × A Menge der Abhängigkeiten
a/A frühester/spätester Starttermin Projekt
e/E frühester/spätester Endtermin Projekt
Begriffe:
Pfad (a1,...,am): Menge von Aktivitäten mit (ai, ai+1) ∈ R
Vorgänger V(a): { a‘ | (a‘, a) ∈ R }
Nachfolger N(a): { a‘ | (a, a‘) ∈ R }
370
4.2 Projektplanung
Ein Netzknoten ist i.a. wie folgt aufgebaut:
FA - frühester Anfang
FE - frühestes Ende
SA - spätester Anfang
SE - spätestes Ende
Subnetze: komplexe Netzknoten können aus Gründen der Übersichtlichkeit in
Subnetze zerlegt werden
371
4.2 Projektplanung
Normalfolge
Das Ende von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (EA: EndeAnfang)
Anfangsfolge
Der Beginn von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (AA: Anfang
- Anfang)
372
4.2 Projektplanung
Endfolge
Das Ende von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (EE: Ende Ende)
Sprungfolge
Der Beginn von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (AE: Anfang Ende)
373
4.2 Projektplanung
Terminberechnung
Berechnung frühester Projektende e:
Für Aktivitäten:
-
Für initiale Aktivitäten: Frühster Anfang ist Projektanfang
Für Zwischenaktivitäten: Frühester Anfang ist frühestes Ende aller Vorgänger
Frühestes Ende ist frühester Anfang zuzüglich Dauer
Frühestes Projektende e ist frühestes Ende aller Finalaktivitäten
374
4.2 Projektplanung
Terminberechnung
Berechnung spätester Projektanfang A:
Für Aktivitäten:
-
Für finale Aktivitäten: Spätestes Ende ist Projektende
Für Zwischenaktivitäten: Spätestes Ende ist spätester Anfang aller Nachfolger
Spätester Anfang ist spätestes Ende abzüglich Dauer
Spätester Projektanfang A ist spätester Anfang aller Initialaktivitäten
375
4.2 Projektplanung
Terminberechnung
Berechnung Pufferzeiten p(a):
Zeit zwischen frühestem und spätestem Anfang
Zeit zwischen frühestem und spätestem Ende
Kritischer Pfad:
Eine Aktivität mit Pufferzeit 0 ist eine zeitkritische Aktivität
All zeitkritischen Aktivitäten auf einem Pfad bilden einen kritischen Pfad
Verzögerung kritischer Aktivitäten führen zu Gesamtprojektverzögerungen
376
4.2 Projektplanung
Beispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen
377
4.2 Projektplanung
379
4.2 Projektplanung
Beispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen
380
4.2 Projektplanung
382
4.2 Projektplanung
Netzplantechnik
Netzplantechnik umfasst folgende Schritte:
Erstellen der Tätigkeitsliste aufgrund des Projektstrukturplans
Erstellen des Netzplans
Berechnen der Vorgangszeitpunkte
Ermitteln der Pufferzeiten
Errechnen des kritischen Weges
Verwendung des Netzplans als Basis von
Balkendiagrammen, z.B. Belegungsplan, Einsatzplan
Einsatzmittel-Auslastungsdiagrammen, z.B. zwecks Bedarfsglättung
383
4.2 Projektplanung
CPM: Vorgangskantennetzplan / Vorgangspfeilplan
Knoten:
symbolisiert ein Ereignis, welches einen Zustand beschreibt;
z.B.: Programm erstellt, Start für den Test;
Darstellung: als Kreis oder Rechteck
Ereignisknoten enthält folgende Bestimmungsstücke:
Ereignisnummer
2
Zeitwert der Vorwärtsrechnung
12
18
Zeitwert der Rückwärtsrechnung
384
4.2 Projektplanung
CPM: Vorgangskantennetzplan
oft werden Ereignisknoten auch folgendermaßen dargestellt
385
4.2 Projektplanung
CPM: Vorgangskantennetzplan
gerichtete Kante:
symbolisiert Vorgang oder Tätigkeit innerhalb eines Projektes;
kein Zusammenhang zwischen der Länge des Pfeils und der Dauer des Vorgangs
Vorgangsbeschreibung:
verbal oder Indexeintrag oberhalb des Pfeils;
Vorgangsdauer: num. Eintrag unter dem Pfeil
386
4.2 Projektplanung
Regel 1:
Ein Vorgang kann erst beginnen, wenn alle vorangehenden Vorgänge
abgeschlossen sind. Dabei fällt, mit Ausnahme des ersten Vorgangs, das
Anfangsereignis mit dem Endereignis des vorangehenden Vorgangs zusammen.
387
4.2 Projektplanung
Regel 2:
Müssen mehrere Vorgänge beendet sein, bevor ein weiterer Vorgang beginnen
kann, so enden sie im Anfangsereignis des nachfolgenden Vorgangs.
Regel 3:
Können mehrere Vorgänge beginnen, nachdem ein vorangehender Vorgang
beendet ist, so beginnen sie im Endereignis des vorangehenden Vorgangs.
388
4.2 Projektplanung
Regel 4:
Haben zwei oder mehr Vorgänge gemeinsame Anfangs- und Endereignisse, so
ist ihre eindeutige Kennzeichnung durch Einfügen von Scheinvorgängen zu
gewährleisten.
389
4.2 Projektplanung
Regel 5:
Beginnen und enden in einem Ereignis mehrere Vorgänge, die nicht alle
voneinander abhängig sind, so ist der richtige Ablauf durch Auflösung der
Unabhängigkeiten mittels Scheinvorgängen darzustellen.
Regel 6:
Innerhalb einer Folge von Vorgängen können beliebig viele Scheinvorgänge
eingefügt werden. Sie dienen neben der logischen Verknüpfung auch der
besseren Übersicht.
390
4.2 Projektplanung
Regel 7:
Kann ein Vorgang beginnen, bevor der vorangehende vollständig beendet ist, so
ist der vorangehende weiter zu unterteilen, damit ein "Zwischen-Ereignis"
definiert werden kann.
Regel 8:
Jeder Vorgang kann nur einmal ablaufen. Daher dürfen im CPM-Netzplan keine
Schleifen auftreten.
391
4.2 Projektplanung
Beispiel: CPM Netzwerk
Tätigkeiten mit Zeitangaben und Vorgängerrelationen
392
4.2 Projektplanung
Beispiel: CPM Netzwerk - Numerierung der Knoten
393
4.2 Projektplanung
Beispiel: CPM Netzwerk - Bestimmung der frühesten
Beginnzeiten
394
4.2 Projektplanung
Beispiel: CPM Netzwerk - Bestimmung der spätesten
Beginnzeiten
395
4.2 Projektplanung
Beispiel: CPM Netzwerk - Bestimmung des kritischen
Pfades
396
4.2 Projektplanung

Erstellen des Netzplans:
Eintragen der logischen Abhängigkeiten zwischen Tätigkeiten
Eintragen der geschätzten Dauer zu einzelnen Tätigkeiten

Errechnen der Zeitwerte und Bestimmung des kritischen Weges:

Zeitwert der Rückwärtsrechnung: vom Endereignis und dessen Zeitwert aus der
Vorwärtsrechnung ausgehend:

Zeitwert der Vorwärtsrechnung: Beginn bei 0;
dann: addieren der Zeiteinheiten nach der logischen Reihenfolge und
Eintrag in das linke untere Feld des Ereigniskreises;
Bedeutung: Bestimmung der frühesten Ereigniszeitpunkte;
Bestimmung der spätesten Ereigniszeitpunkte durch
Subtraktion der Zeitwerte;
Eintrag in den rechten unteren Teil des Ereignisknotens;
Der kritische Weg umfasst alle Ereignisse, deren früheste und späteste
Ereigniszeitpunkte gleich sind
Bedeutung: der kritische Weg enthält alle Tätigkeiten, die keine Pufferzeiten erlauben, d.h.
zwischen dem geplanten Ende einer Tätigkeit und dem Start der Folgetätigkeit gibt es keine
zeitliche Verschiebungsmöglichkeit, wenn das Ende des gesamten Vorhabens unbeeinflußt
bleiben soll.
397
4.2 Projektplanung
Beispiel eines Netzplans mit einem kritischen Weg:
398
4.2 Projektplanung
Berechnen der Vorgangszeitpunkte (“Tätigkeitszeitpunkte”):
frühester Anfangszeitpunkt des Ereignisses:
spätester Endzeitpunkt eines Vorganges:
frühester Endzeitpunkt eines Ereignisses:
spätester Anfangszeitpunkt eines Vorganges:
FA
SE
FE
SA
Zweck: Berechnung der Pufferzeiten und Erstellen des EinsatzAuslastungsdiagramms, z.B. zwecks Bedarfsglättung
399
4.2 Projektplanung
400
4.2 Projektplanung
Aufgrund der Vorwärts- und Rückwärtsrechnung sind bekannt: FA (FZ)
und SE (SZ)
FE(V1) = FA(V1) + D(V1)
SA(V1) = SE(V1) - D(V1)
Pufferzeiten:
Gesamte Pufferzeit (GP):GP = SE(j) - FA(i) - D
oder GP = SZ(j) - FZ(i) - D
Bedeutung:
GP gibt an, wie lange ein Vorgang höchstens verlängert/verzögert werden kann,
ohne daß der Endtermin beeinträchtigt wird.
401
4.2 Projektplanung
Freie Pufferzeit (FP):
FP = FE(j) - FA(i) - D
oder FP = FZ(j) - FZ(i) - D
Freie Pufferzeit entsteht, wenn mehrere Vorgänge, die nicht alle zeitbestimmend
sind, in einem Ereignis münden.
Die freie Pufferzeit gibt den Zeitunterschied zwischen der zeitbestimmenden und
der auf einem anderen Weg berechneten frühesten Lage eines Ereignisses an.
Bedeutung:
FP gibt an, wie lange ein Vorgang höchstens ausgedehnt/verzögert werden kann,
ohne den Anfangszeitpunkt der Folgevorgänge zu beeinflussen.
402
4.2 Projektplanung
Unabhängige Pufferzeit (UP):
UP = FE(j) - SA(i) - D
Bedeutung:
UP gibt die Dauer an, die der Vorgang mit den Folgevorgaben ausgedehnt oder
verschoben werden kann:
a) das Startereignis muß zum spätesterlaubten Zeitpunkt beginnen und
b) der Vorgang muß den frühestmöglichen Endzeitpunkt einhalten können.
weitere Kenngröße:
Schlupf im Zustand i: SL(i) = SZ(i) - FZ(i)
403
4.2 Projektplanung
Übersicht zu Pufferzeiten und Schlupf
404
4.2 Projektplanung
Netzplantechnik – PERT
Vorgangspfeilnetzplan
Program Evaluation and Review Technique (PERT)
Eigenschaften:
Ereignisorientierter Netzplan ähnlich CPM
Betont Projektzustände (Ereignisse);
Ziel war die Verbesserung der Zeitschätzungen
von den Zustandsübergängen (Pfeile, i.a. beliebige Folgen von Vorgängen) ist lediglich
die Dauer und Anordnungsbeziehung (AOB) von Interesse
wesentliches Charakteristikum:
Berücksichtigung der Unsicherheit bei der Zeitschätzung;
für jede Anordnungsbeziehung werden geschätzt:
- OD: optimistische Dauer
- HD: häufigste Dauer
- PD: pessimistische Dauer
405
4.2 Projektplanung
PERT
Annahmen:
OD, HD und PD stellen drei repräsentative Werte der Häufigkeitsverteilung dar, siehe
Aufwandsabschätzung;
bei mehrfacher Durchführung fallen alle Zeitwerte zwischen OD und PD;
kontinuierliche Verteilungskurve;
Folgerung: Beta-Verteilung
406
4.2 Projektplanung
PERT
Berechnung der mittleren Dauer (MD) als Erwartungswert aus den drei
Schätzungen OD, HD und PD
Näherungsgleichung:
MD = (OD + 4HD + PD)/6
Angabe der Varianz (δ)2 der Vorgangsdauer zur Bewertung der Unsicherheit bei
der Angabe der Vorgangsdauer:
Näherungsgleichung:
δ 2(D) = ((PD - OD)/6)2
Die Varianz der frühesten/spätesten Zeitpunkte (FZ/SZ) ergibt sich aus der
Summe der Varianzen, aus denen FZ und SZ berechnet wurden.
407
4.2 Projektplanung
PERT
Da Ereignisse im Vordergrund stehen, werden nicht Pufferzeiten sondern der
Schlupf je Ereignis berechnet:
SL(i) = SZ(i) - FZ(i)
Varianz des Schlupfs:
δ2[SL(i) ] = δ2[FZ(i)] + δ2[SZ(i)]
oft wir der Endtermin der Projektes vorgegeben; dieser vorgegebene Plantermin
(PT) kann zum frühesten Termin (FT) in Beziehung gebracht werden, indem die
Wahrscheinlichkeit, mit welcher der Plantermin erreicht werden kann, ermittelt
wird
408
4.2 Projektplanung
PERT
Anwendung der Normalverteilung zwecks Berechnung:
z = [PT(i) - FT(i)]/[δ2(FZ(i)]
Beispiel:
festgelegter Endtermin: 22.4.2003
Ermittlung aus dem Netzplan ergibt: FT = 29.4.2003
Standardabweichung = 10 Tage
z = [ (22.April) - (29.April)]/10 = -0.5
Nachsehen in Formelsammlung zur Normalverteilung bei (-0.5) ergibt: Wahrscheinlichkeit
von ca. 31%
409
4.2 Projektplanung
Beispiel zu einem PERT-Netzplan:
410
4.2 Projektplanung
Erklärungen zum PERT-Netzplan Beispiel:
411
4.2 Projektplanung
Netzplantechnik
Zusammenfassung
Netzplantechnik
Eingabe:
-
Projektstrukturplan
Terminvorgaben
Aufwandsschätzung (Zeitaufwände)
Ergebnis:
-
Meilensteinplan
Terminplan
Einschränkende Annahmen
Annahme: Vorgangsdauer genau abschätzbar
Annahme: Ressourcen frei planbar
Konsequenz: Termin- und Ressourcenplanung verschränkt durchführen
412
4.2 Projektplanung
Balkendiagramm
Balkendiagramm (GANTT-Diagramm)
Graphische Darstellung der Terminlisten unter Einbeziehung der Dauer der
einzelnen Vorgänge
Gute Visualisierung der einzelnen Phasen und des Projektfortschritts
Aktivitäten werden in Balkenform aufgetragen
Die Länge des Balkens entspricht der Länge der Aktivität
Graue Teile der Balken entsprechen der Pufferzeit (i.e. jene Zeit, um die sich eine
Aktivität verschieben darf, ohne Einfluss auf die Gesamtprojektdauer zu nehmen)
Aktivitäten ohne Pufferzeit stellen den “kritischen Pfad” dar
Aus Gantt-Diagrammen sind die Zusammenhänge der einzelnen Aktivitäten nicht
ersichtlich
413
4.2 Projektplanung
Balkendiagramm
Balkendiagramm (GANTT-Diagramm)
Balkendiagramme:
vielseitige Verwendung;
horizontale Achse: Zeit
vertikale Achse: z.B.
-
Sachmittel: “Belegungsplan”
Aufgaben: “Tätigkeitsplan”, “Projektfortschrittsplan”
Aufgabenträger: “Einsatzplan”
Erweiterungen:
Balken können mit Wert beschriftet werden
z.B. Mitarbeitername
je ein Balken für Soll- und Ist-Wert zwecks Vergleich
414
4.2 Projektplanung
Balkendiagramm
Balkendiagramm
Gesamtpersonalplan
Alle Projektpartner kumuliert
Personaleinsat
Zeitplan - Angaben als 'Personen pro Monat'
Arbeitsschritte
Meilensteine
AP 1 Entwicklung Vorgehensmodell „BP2WS-Prozess“
AP 1.1 Stand der Technik
AP 1.2 Vorgehensmodell „BP2WS“
MS 1.1 BP2WS V1
MS 1.2 BP2WS V2
AP 1.3 Dokumentation
AP 1.4 UML Profile
AP 2 Modelltransformation und Codegenerierung
AP 2.1 Stand der Technik
AP 2.2 Transformationssprache
MS 2.1 Transformationssprache V1
MS 2.2 Transformationssprache V2
AP 2.3 Regeln
MS 2.3 Regelbibliothek
AP 3 Prototyp
AP 3.1 Anforderungen
AP 3.2 Modellierung
MS 3.1 Modellierung in Innovator
AP 3.3 Tranformationen / Codegenerierung
MS 3.2 Transformations / Codegen. In Innovator
AP 4 Fallstudie
AP 4.1 Anforderungen Fallstudie
AP 4.2 Anforderungen an BP2WS
AP 4.3 Fallstudie 1 und Evaluation
MS 4.1 Fallstudie 1 und Eval
AP 4.4 Fallstudie 2 und Evaluation
MS 4.2 Fallstudie 2 und Eval
AP 5 Projektmanagement
Summen
Einteilung nach Vergütungsg
Balkendiagramm
Meilensteine
Jahr
Quartal
Quartale berücksich
0,2*3=0,6
2005
2
3
2006
4
bei Wirtschafts-Unternehme
o.ä.
2007
1
2
3
4
1
2
Insges.
3
0,7
1,4
1,1
0,7
0,5
1,3
0,6
0,5
1,3
0,9
0,3
0,7
0,9
0,6
1
1,3
MID
(Dipl.Ing
41,4
12,3
0
2,1
22,5
5
43,8
0,7
0,9
0,8
0,8
1
1,1
2,2
0,5
0,3
1,5
0,8
0,4
1,3
1,4
1,1
0,6
10,8
2,1
11,1
0
30,6
7
48,3
0,5
1,2
42,6
0,2
0,3
0,2
0,1
0,1
2,4
7,8
3,1
3,5
3,1
2
1
38,1
59,1
1,5
0,9
1,6
0,4
3,6
2,4
3,3
3,3
2,7
3
2
10,8
6
3
9,3
9,3
3,9
18
1
1
2
27,9
4
0,8
0,2
0,3
0,35
0,25
0,1
0,3
0,25
0,25
0,8
10,8
2,1
4,6
6
4,8
4,95
5,05
8,6
7,8
10,25
8,65
7,1
203,4
77,1
Durchschnittliche Zahl von Personen pro Monat über Projektlaufzeit:
1
5
6,78
415
4.2 Projektplanung
Balkendiagramm
Balkendiagramm
416
4.2 Projektplanung
Balkendiagramm
Beispiel zu einem Balkendiagramm mit einem
Ist-Soll-Vergleich
417
4.2 Projektplanung
Balkendiagramm
In das Balkendiagramm werden zusätzlich Informationen über einfache
Abhängigkeiten zwischen den einzelnen Vorgängen eingefügt
Darstellung: Pfeile vom Vorgänger-Balken zum jeweiligen Nachfolger
Dadurch gute Darstellung der direkten Abhängigkeiten, i.e. welche weiteren
Vorgänge werden aufgrund einer Verzögerung ebenfalls verspätet ausgeführt
und mit welchen Vorgängen kann im Zeitplan weiter wie geplant vorgegangen
werden.
Vernetzte Balkenpläne zählen zu den einfachsten und wichtigsten
Kommunikationsinstrumenten im Projektmanagement
418
4.2 Projektplanung
Balkendiagramm
419
4.2 Projektplanung
Balkendiagramm
420
4.2 Projektplanung
Balkendiagramm
ID
1
ID
Task Name
-2
1st Quarter
1
3
3rd Quarter
7
9
5
T1.1
Selection of tools
3
T1.2
Management of CVS-server, Web-site, …
4
T1.3
Project Co-ordination
5
T1.4
Co-ordination with standards
6
D11
Selection of Tools
31/03
7
D12
Inter-working with other projects
31/03
8
D13
Impact on Standards
9
D14
Impact on Standards
10
D15
Project summary and exploitation plan
11
D16
Annual Report Review 2000
D17
Annual Report Review 2001
13
1st Quarter
13
15
17
17
3rd Quarter
3rd Quarter
19
21
19
21
23
23
1st Quarter
1st Quarter
25
27
25
27
29
29
3rd Quart
3rd Quart
31
31
WP1 WP1 Project Management & Coordination
2
12
11
31/03
30/05
30/06
31/12
31/12
WP2 WP2 Field Trials
14
T2.1
Requirements of Field Trials
15
T2.2
Specifications of Field Trials
16
T2.3
Preparation of Field Trials
17
T2.4
Carry out Field Trials
18
T2.5
Evaluation of Field Trials
19
D21
Requirements of Field Trials
20
D22
Specifications of Field Trials
21
D23
Evaluation of Field Trials
22
WP3 WP3 Light. Ext. Agent Platform
23
T3.1
24
T3.2
System Design, Architecture, API
25
T3.3
Implementation
26
T3.4
Integration
27
T3.5
Maintenance
28
D31
Specification of the LEAP Architecture
29
D32
Specification of LEAP API + profile
30
D33
LEAP Version 1.0
31
D34
LEAP Version 2.0
30/04
30/08
30/06
Set-up of the environment
32
WP4 WP4 Agent Services & Applications
33
T4.1
Design
34
T4.2
Implementation
35
T4.2
Integration
36
T4.4
Maintenance
37
D41
Agent Services Design
38
D42
Lab Trial
39
D43
LEAP Application Implementations
31/05
31/07
31/12
30/08
30/08
31/12
28/09
40
Phase 1
Phase 2
421
4.2 Projektplanung
Einsatzmittel - Auslastungsdiagramm
Motivation: Berechnung und Visualisierung der Personal- und
Betriebsmitteleinheiten, die zu bestimmten Zeitpunkten während des
Projektablaufes benötigt werden.
Ziele der Einsatzmittelplanung:
Reduktion der Brachzeiten von Einsatzmitteln
Reduktion der Gesamtheit von Einsatzmitteln
Erhöhung der Anzahl der zu bearbeitenden Objekte
Optimierung des Einsatzes von Menschen und Maschninen
horizontale Achse des E-A-Diagramms: Zeit
vertikale Achse: Anzahl der Einheiten
422
4.2 Projektplanung
Schritte zur Erstellung des E-A-Diagramms:
Erstellen des Netzplans, erweitert um die Angabe der Einsatzmitteleinheiten (in Klammer,
rechts von der Dauer)
Erstellen des Balkendiagramms der frühesten Lage
Erstellen des E-A-Diagramms der frühesten Lage
Erstellen des Balkendiagramms der spätesten Lage
Erstellen des E-A-Diagramms der spätesten Lage
Durchführen der Bedarfsglättung gemäß der Bedarfsbegrenzung (“nicht-funktionale
Anforderungen”)
423
4.2 Projektplanung
Beispiel eines Netzplans mit Einsatzmitteleinheiten
(und mit unterschiedlichen Zeitwerten des Endereignisses)
424
4.2 Projektplanung
Beispiel für ein Balkendiagramm der frühesten Lage
425
4.2 Projektplanung
Beispiel des Ergebnisses der Übertragung des Balkendiagramms der frühesten
Lage auf das E-A-Diagramm der frühesten Lage. Kein Vorgang nutzt dabei
etwaige Pufferzeiten.
426
4.2 Projektplanung
Beispiel für ein Balkendiagramm der spätesten Lage
(Jenny Abb. 4.21, S. 347)
427
4.2 Projektplanung
Beispiel des Ergebnisses der Übertragung des Balkendiagramms der spätesten
Lage auf das E-A-Diagramm der spätesten Lage. Alle Pufferzeiten werden voll
dabei ausgeschöpft.
428
4.2 Projektplanung
Die E-A-Diagramme der frühesten und der spätesten Lage zeigen Extremwerte
des Bedarfs an.
Optimale Nutzung der Pufferzeiten ermöglicht Minimierung der Grenzwerte.
Neuordnung der Tätigkeiten innerhalb der erlaubten Spektren ermöglicht eine
Anpassung des Bedarfs gemäß der Bedarfsbegrenzung.
erreicht durch: Verschieben der Vorgänge, der Ereignisse, oder der Arbeitspakete
innerhalb der Pufferzeiten.
Frühzeitige Erkennung von Engpässen wird ermöglicht
429
4.2 Projektplanung
Beispiel einer Glättung unter dem Kriterium, daß die auf zehn Einheiten
festgelegte Bestandesgrenze eingehalten werden muß.
430
4.2 Projektplanung Arbeitspaketbeschreibung
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
1)
Beschreibung des
Arbeitspaketes
Vorbereitung, Durchführung und Nachbereitung von zwei je zweitägigen Trainings für Vertriebsmitarbeiter und
ausgewählte Mitarbeiter über die neue Technologie und Funktionalität des Mobile-Odors-Telefons. Ergänzende
Informationen:
Intensivtraining mit max. 4 Teilnehmern
Überwiegend folienbasiertes Training inkl. Übungen (ca. 80 Folien pro Tag)
Es gibt bereits Unterlagen einer älteren Schulung, die für das Training benutzt/angepasst werden dürfen.
Teilnehmerunterlagen werden durch Druckerei erstellt & geliefert. →Vorher Übergabe elektronisch in pdfFormat.
Nachbereitung: Teilnehmerzertifikate und im Kurs erarbeitete Unterlagen (elektronische Bilder via E-Mail)
2)
Durchführende Personen oder
Rollen
Chefdesigner
3)
Notwendige Fähigkeiten
des/der Durchführungen
Gute technische und funktionale Kenntnisse Mobile Odors, Trainerausbildung
431
4.2 Projektplanung Arbeitspaketbeschreibung
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
4)
Dauer und Aufwand
5)
Liefergegenstände
Schulungsdauer: 2 Tage (à 8 Stunden), Aufwand noch zu bestimmen
Trainerfolien, Trainingsorganisation, durchgeführte Trainings, Teilnehmerunterlagen
6)
Vorraussetzungen für die
Durch-führung
Ausreichend zeitlicher Vorlauf bei der Planung, damit alle Teilnehmer mit den 2 Trainings erreicht werden.
7)
8)
Vorraussetzungen für eine
erfolg-reiche Abnahme
Teilnehmer kennen die Technologie und fühlen sich in der Lage, auch mit technisch versierten Kunden ein
Vertriebsgespräch zu führen.
Kennzahlen zur Überprüfung
der korrekten Durchführung
keine
432
4.2 Projektplanung
Risikoanalyse
Risikoanalyse
Ziel: Abschätzung der möglichen Risiken mit deren Wahrscheinlichkeit des
Eintreffens und Auswirkungen
Zeitpunkt der Durchführung:
- zu Projektbeginn, bzw. bei der Bewertung der Projektanträge
- jeweils nach Abschluss einer Entwicklungsphase, z.B.
im Zuge der entsprechenden Reviews
Vorgehen:
1) Vorbereitung:
Entwurf eines Formulars zum Eintragen der Risiken
(falls nicht bereits vorgegeben)
433
4.2 Projektplanung
Risikoanalyse
Risikoanalyse
Beispiel eines Formulars für die Risikoanalyse:
2) Durchführung der Risikoanalyse
2.1 Ermitteln der Risiken: in Teamarbeit;
Beispiele für Fragen:
- Kommen Aktivitäten mit hohem Innovationsgrad vor?
- ist die Abhängigkeit von bestimmten Ressourcen hoch? ...
434
4.2 Projektplanung
Risikoanalyse
Risikoanalyse
2.2 Beschreiben der Ursachen jedes Risikos
Kennt man die Ursachen, ist es einfacher, adäquate Gegenmaßnahmen zu
planen.
2.3 Bewerten der Eintrittswahrscheinlichkeit je Risiko
2.4 Bewerten des Auswirkungsgrades/ der Tragweite
2.5 Bestimmen des Risikogrades: die größten Risiken haben eine hohe
Eintrittswahrscheinlichkeit und Tragweite
2.6 Beschreibung konkreter Gegenmaßnahmen und präventiver Aktionen
2.7 Frühwarnsystem einrichten: feststellen, aufgrund welcher Anzeichen,
Symptome, Ereignisse Gefahren und Risiken frühzeitig erkannt werden können.
2.8 Eventualmaßnahmen (alternative Strategien) planen
435
4.2 Projektplanung
Risikoanalyse
Risikoanalyse
3) Nachbearbeitung
Risikosituation eines Projektes ändert sich mit der Zeit
Folgerung: Überprüfung und Aktualisierung des Risikoprofils im Projektverlauf;
z.B. bei Reviews
Fragen:
- Kommen neue Risiken hinzu?
- Haben sich die Faktoren bekannter Risiken geändert?
- Sind die zur Risikoverminderung getroffenen
Maßnahmen noch wirkungsvoll?
436
4.2 Projektplanung
Personalplanung
Personalplanung
Aufgaben der projektbezogenen Personalplanung
Sicherstellung der Mitarbeiterverfügbarkeit
Optimaler Einsatz der Mitarbeiter
-
Vermeidung von Mitarbeiterüberlastung
Vermeidung von mangelnder Mitarbeiterauslastung
437
4.2 Projektplanung
Personalplanung
Ermittlung Personalaufwand
Prinzipieller Ansatz:
Eingaben: Aufwand Aktivität, Dauer Aktivität
Ausgabe: Anzahl benötigter Mitarbeiter
Verfahren:
Zusätzlich: Benötigte Qualifikation
Rechenbeispiel: 10 PM
Dauer 10 KM : 1 MA
Dauer 2 KM : 5 MA
Bemerkungen:
Annahme der normierten Leistung (1 MA leitet 1 PM pro Monat)
Annahme der unabhängigen Multiplizität von Mitarbeitern
Berücksichtigung Brutto/Netto-Leistung
438
4.2 Projektplanung
Personalplanung
Personalplanung
Prinzipieller Ansatz:
Ermittlung Personalaufwand (Projektstrukturplan, Aufwandsschätzung, Terminplan)
Ermittlung Personalressourcen
Personalzuordnung und Optimierung der Auslastung
Varianten der Zuordnung/Optimierung:
Terminorientiert: Aufwände in Abhängigkeit vorgegebener Termine
Aufwandsorientiert: Termin in Abhängigkeit vorgegebener (Maximal-)Aufwände
Realistisch: Mischverfahren
439
4.2 Projektplanung
Personalplanung
Optimierung
Varianten der Zuordnung/Optimierung:
Terminorientiert:
-
Einhaltung vorgegebener Termine
Erhöhung der Personalzuordnung
Aufwandsorientiert:
-
Einhaltung vorgegebener (Maximal-)Aufwände
Verschiebung des Termins
440
4.2 Projektplanung
Personalplanung
Organisatorische Randbedinungen
Qualifikation der Mitarbeiter:
Qualifizierte Mitarbeiter einsetzen
Mitarbeiter qualifizieren (Zeiten/Kosten einplanen)
Zeitliche/räumliche Verfügbarkeit:
Zeitlich: Persönliche Planung berücksichtigen (Urlaub/Ausfall)
Räumlich: Koordinationsverluste einplanen
Organisatorische Einbettung:
Projektstruktur: Mitarbeiter nach Auslastung einplanen
Matrixstruktur: Linenvorgesetzten in Planung einbeziehen
Generell: Mitarbeiter rechtzeitig in Planung einbeziehen
441
4.2 Projektplanung
Personalplanung
Humane Randbedingungen
Starke Produktivitätsschwankungen zwischen Mitarbeitern
Schwache Produktivitätsschwankungen im Team
Teamkohäsion
Teamidentifikation mittels gemeinsamer Normen
„Never change a winning team“
Ausrichtung auf ein gemeinsames Ziel
Projektidentifikation
Identifikation erhöht Produktivität
Multiprojekteinsatz reduziert Produktivität
Generell: Humane Faktoren sind primäre Produktivitätstreiber
442
4.2 Projektplanung
Personalplanung
Produktivität
Beste Mitarbeiter um Faktor 10 besser als schlechteste
Beste Mitarbeiter um Faktor 2,5 besser als Durchschnitt
Überdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittliche
Unabhängig von Leistungsmetrik:
-
Anzahl der Fehler
Kalenderzeit bis Meilenstein
Funktionspunkte pro Zeiteinheit
443
4.2 Projektplanung
Personalplanung
Ressourcenplanung
Verfahren:
Im wesentlichen analog Personalplanung
Ähnliche Probleme
-
Qualifikation: Vorbereitung
Multiprojekteinsatz: Umrüstung
Unterscheidung
Nichtverbrauchbare Ressourcen
Verbrauchbare Ressourcen (eingebettete SW)
444
Projektmanagment
1.
Einleitung
2.
Faktor Mensch
3.
Interviewtechniken
Zeitmanagement
Projektinitiierung
445
Projektmanagment
Schätzverfahren
Projektplanung
Einleitung
Projektfunktionen
Aufgabenträger
446
Projektmanagment
6.
Projektkontrolle
7.
Change-Management
Kostenkontrolle
Prozessverbesserung
Projektabschluss
447
Kapitel 5:
Projektstrukturen und Personalaktivitäten
Einleitung
Projektfunktionen
Aufgabenträger
448
Kapitel 5:
Projektstrukturen und Personalaktivitäten
Einleitung
Projektfunktionen
Aufgabenträger
449
5 Projektstrukturen und Personalaktivitäten
5.0 Einleitung
Aufbauorganisation
Projektfunktionen
Projektorganisation
Ablauforganisation / Meilenstein und
Phasen
Phasenorganisation
Projektzielsetzung
Projektziele
Requirements
Aufbauorganisation
Ablauforganisation
Projektplanung
Strukturplanung
Aufwandsschätzung
Ablaufplanung
Terminplanung
Projektziel
Projektsteuerung und -überwachung
Berichtswesen
Projektplanung
Projektsteuerung
450
5.0 Einleitung
Projekt: Ein Vorhaben, das im wesentlichen durch Einmaligkeit der
Bedingungen in seiner Gesamtheit gekennzeichnet ist, wie z.B.
Zielvorgabe,
zeitliche, finanzielle, personelle oder andere Begrenzungen,
Abgrenzung gegenüber anderen Vorhaben,
projektspezifische Organisation.
Projektorganisation:
Gesamtheit der Organisationseinheiten und der aufbau- und
ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes
[DIN 69 901] d.h.
temporäre Organisation
unternehmensinterne Projektorganisation
unternehmensübergreifende Projektorganisation
451
5.0 Einleitung
Rollen im Projekt
Projektbüro bzw. Projekt- Office
Informatik- Seite
Projektleiter/Projektverantwortlicher: Teamführung
Mitglieder des Projektteams: Arbeitsdurchführung
Fachbereichsseite
Anwender
-
Endanwender: später Nutzer
Fachberater: Repräsentant der späteren Nutzer im Projektteam
Auftraggeber
-
Auftraggeber: Geldgeber
Projektbeauftragter: Ansprechpartner des Projektleiters / Projektverantwortlichen
Servicemitarbeiter: Zuarbeiter des Projekts
452
5.0 Einleitung
Projektteam & Projektleiter
Gesamtverantwortung liegt beim Projektleiter
Qualität
Kosten
Zeit
Projektmitarbeiter sind fachlich unterstellt
verantwortlich für Durchführung zugewiesener Aufgaben
Berichtsweg an den Projektleiter / Projektverantwortlichen
Disziplinatorische Unterstellung
PL und Mitarbeiter bleiben in ihren Stellen
Matrixorganisation
fachliche Unterstellung (Berichtsweg) -> Informations - Verdichtung
Projektleitung mit Personalverantwortung
453
5.0 Einleitung
Einrichten einer projektspezifischen Organisation:
Aufbauorganisation
Innere Aufbau eines Unternehmens, d.h.
-
Einbinden des Projekts in die Unternehmensorganisation
Einrichten von Rollen und Verantwortlichkeiten
Ablauforganisation
Organisation der Arbeitsabläufe, d.h.
-
Abwickeln des Projekts entsprechend des Entwicklungsprozess
Festlegen von Aktivitäten und Abläufen
Prozeßorganisation
-
Zweck: Festlegen des Ablaufs
Prozeßorganisationsplan
Prozeßorganisationsplan
-
-
Phasenziele
» Fachliche Beschreibung der Teilaufgaben
Phasenergebnisse
» produktbezogen (Prototyp)
» projektbezogen (Projektplan, Projektbericht, usw.)
Phasenabschlüsse
» Abnahme eines Teilprojektes / Zwischenergebnisses
Kontrollinstanzen
454
5.0 Einleitung
Projektorganisation:
455
5.0 Einleitung
Projektspezifische
Definition der
Projektfunktionen
Übertragung der
Projektfunktionen inkl.
Kompetenz und
Verantwortung auf die
Aufgabenträger
Projektfunktionen
Aufgabenträger
Organisationsformen

Reine
Projektorganisation

Projektleitung

Projektplanung und
-überwachung

Personen

Systemplanung
und -überwachung

Systementwicklung
Projektstellen
- Linienstellen
- Stabsstellen

Systemintegration
und -test

Qualitätssicherung

Einbettung des Projekts
in die vorhandene
Organisation
Gremien
456
5.0 Einleitung
Projektspezifische
Definition der
Projektfunktionen
Übertragung der
Kompetenz und
Aufgabenträger
Projektfunktionen
Aufgabenträger
Organisationsformen

Reine
Projektorganisation

Projektleitung

Projektplanung und
-überwachung

Personen

Systemplanung
und -überwachung

Systementwicklung
Projektstellen
- Linienstellen
- Stabsstellen

Systemintegration
und -test

Qualitätssicherung

in die vorhandene
Organisation
Gremien
457
5.1 Projektfunktionen
Projektfunktionen
Projektleitung
Projektplanung und -überwachung
Systemplanung und -überwachung
Systementwicklung
Systemintegration und -test
Qualitätssicherung
458
5.1 Projektfunktionen - Projektleitung
Projektleitung
Zielvorgaben (z.B. Ressourcen, Termine, etc.) und Randbedingungen des
Projekts
Kontrolle und Steuerung der Zielerreichung
Festlegung der Aufbau- und Ablauforganisationen
Delegation von Aufgaben
Vergabe von Teilaufträgen
Koordination aller beteiligten Stellen/Unternehmen/Gruppen
Ressourcenbeschaffung, Personaleinsatzplanung
Personalführung abh. von Organisationsform
Entscheidung über Lösungsalternativen
Festlegung von Entwicklungsprioriäten
Entscheidung über Planungen und Entwicklungsergebnissen
Information von und Kommunikation mit Auftraggeber, Management
Außervertretung des Projekts
459
5.1 Projektfunktionen - Projektplanung und -überwachung
Projektplanung und –überwachung
Projektstrukturplanung (Zerlegung der Gesamtaufgabe in Teilaufgaben)
Arbeitspaketdefinition
Ablaufplanung (Festlegung der zeitlichen Ablauffolge der Arbeitspakete,
Netzplanerstellung, etc.)
Definition von Teilaufträgen
Planung und Kontrolle von
End- und Zwischenergebnissen in Abstimmung mit Systemplanung und –controlling,
sowie Qualitätssicherung
Ressourcen, wie z.B. Personal, HW, SW,...
Termine, Meilensteine
Kosten, wie z.B. Personal, Unteraufträge,...
Berichtswesen (Ergebnisse, Kosten, Termine, Meilensteine,...)
Vertragsadministration
460
5.1 Projektfunktionen - Systemplanung und -überwachung
Systemplanung und –überwachung
Requirements-Engineering (Analyse technische Anforderungen)
Definition und Analyse der technischen Probleme und Zerlegung in Teilaufgaben,
sowie Teilaufträge
Lösungsalternativen aufstellen und bewerten
Feasibility Study (können wir das überhaupt machen?)
Entwurf Gesamtsystem
Festlegung Schnittstellen nach innen und außen
Produktstrukturplanung
Konfigurationsplanung inkl. Produkteinheiten und Versionen (-> KM)
Entwicklungsweg aufstellen
Auswahl der Entwicklungsumgebungen, etc.
Rahmenbedingung für Qualitätssicherung und Teststrategie definieren
Festlegung und Controling von technischen Richtlinien für Entwurf,
Implementierung,... z.B. Code-Layout, Versionierung
461
5.1 Projektfunktionen - Systementwicklung
Systementwicklung
Definition und Analyse der Anforderungen an die Teilsysteme
Projektierung und Entwurf von Komponenten
Erstellung und Testen von Prototypen
Durchführung von Simulationen
Detailspezifikation
Realisierung der Komponenten, inkl. Test, Dokumentation und Versionisierung
Durchführung von Änderungen und Korrekturen
Benutzerdokumentation verfassen
462
5.1 Projektfunktionen - Systemintegration und -test
Systemintegration und –test
Testplanung inkl. Vorgehen, Umfang und Auswahl von Testfällen
Planung und Realisierung der Testsysteme für alle Phasen der Integration:
Integrations-, System- und Regressiontests
Systemintegration: Zusammenbau der Teilsysteme zum Gesamtsystem
Integrationstest: Läuft das integrierte System?
Systemtest: Erfüllt das System die Requirements?
Regressiontest: Läuft das System nach Fehlerbehebung, Änderungen oder
Erweiterungen?
463
5.1 Projektfunktionen - Konfigurationsmanagement
Verwaltung der Entwicklungsergebnisse ((Teil-)Systeme, Module, Versionen,
etc.) und Projektdaten
Melde- und Änderungswesen (Change Management): Verwaltung und Verfolgung
von Requirements, Änderungen (Change Requests) und Bug reporting
Konfigurationskontrolle
Bereitstellung von Komponenten für Systemintegration und Systemtest
Auslieferung vom System
Auswertungen
464
5.1 Projektfunktionen - Qualitätssicherung
Qualitätssicherung
Festlegung der Qualitätsanforderungen
Planung der Qualitätsprüfung
Objekte, wie z.B. Code, Werkzeuge, Dokumente
Verfahren, wie z.B. Code Review, Design Document Control (Umlauf eines Dokuments
mit Kommentierung), Structured Walk Through (zusammensetzen mit Diskussion)
Kriterien, wie z.B. Zuverlässigkeit, Usability, Performanz,
Zeitpunkte, wie z.B. Meilensteine, Beendigung von Phasen
Durchführung der Qualitätsprüfung
Berichterstatttung
465
5.2 Aufgabenträger
Projektspezifische
Definition der
Projektfunktionen
Übertragung der
Kompetenz und
Aufgabenträger
Projektfunktionen
Aufgabenträger
Organisationsformen

Reine
Projektorganisation

Projektleitung

Projektplanung und
-überwachung

Personen

Systemplanung
und -überwachung

Systementwicklung
Projektstellen
- Linienstellen
- Stabsstellen

Systemintegration
und -test

Qualitätssicherung

in die vorhandene
Organisation
Gremien
466
5.2 Aufgabenträger
Aufgabenträger - Rollen
Projektstruktur: Definiert durch
Rollen
Aktivitäten:
-
Pflichten/Aufgaben
Rechte/Kompetenzen
Rollenstruktur: Beeinflusst von:
Prozessstruktur (z.B. Analyse, Design, Implementierung, Integration)
Produktstruktur (z.B. Präsentation, Logik, Datenhaltung)
Projektrollen:
Projektausschuss
Auftraggeber
Anwender
Projektleiter
Projektmitarbeiter (z.T. leitender Mitarbeiter)
467
5.2 Aufgabenträger
Team-Rolle: Projektleiter
Rolle: Projektleiter
Aufgaben:
Erstellung Projekt-, Termin- und Kostenplan
Organisation und Koordination Projektteam
Durchführung Fortschrittskontrolle
Steuerung und Festlegung von Entscheidungen (fachlich)
Evtl.: Personelle Betreuung Projektmitarbeiter
Erfüllung und Einhaltung der Sach-, Termin- und Kostenziele
Kompetenzen:
Mitwirkung bei der Projektzieldefinition
Mitspracherecht bei der Bestimmung der Fachverantwortlichen
projektbezogenes Informations-, Weisungs- und Entscheidungsrecht
Delegationsrecht von Aufgaben
Verfügungsrecht über Projektbudget
Zugriffsrecht auf alle für die Projektdurchführung notwendigen Informationen
468
5.2 Aufgabenträger
Team-Rolle: Mitarbeiter
Rolle: Mitarbeiter
Aufgaben:
Mitwirkung an Projektplanung
Durchführung der zugewiesenen Arbeitspakete
Dokumentation der zugewiesenen Arbeitsergebnisse
Kompetenzen:
Vorbereitung/Herbeiführung von Entscheidungen
Umsetzung von Vorgaben
Einsatz von Ressourcen
Variante: Leitender Mitarbeiter
469
5.2 Aufgabenträger
Weitere Mitarbeiter-Rollen
• SE-spezifische Team-Rollen:
Systemanalytiker
Systementwickler
Tester
• SE-Spezifische Stabs-Rollen:
Qualitätsmanager, Qualitätsbeauftragter
Konfigurationsmanager
IT-Sicherheitsbeauftragter
Projekt-Controller
• Generelle Prinzipien:
Personifizierte Verantwortung
Klare Aufgaben und Kompetenzen
470
5.2 Aufgabenträger
Gremien
zur Abstimmung, Information, Problemlösung und Entscheidung
aber: so wenig Gremien wie möglich
Beispiele:
Projektbesprechungen
Change Control Board
Meilenstein-Entscheidungen
Beratungsausschuss
Entscheidungsausschuss
471
5.2 Aufgabenträger
Projektgremien
Entscheidungsausschuss
Lenkungsausschuss
Projektsteuerungsrunde
Projektmeetings
Geschäftsführung
Geschäftsführung
Gesamt-PL
Gesamt-PL
PL-Projektleiter
PL-Projektleiter
Teil-PL
Teil-PL
Team
472
5.2 Aufgabenträger
Unterste Ebene
meist wöchentlichen Projektmeetings, die der Projektleiter mit seinem Team
durchführt. Themen, z.B.:
Klärung fachlicher Probleme auf Detailebene
Arbeitspakete und Projektfortschritt
Risiken
Größere Projekte oft mehrere Teilteams,
die von Teilprojektleitern geführt werden.
Projektmeetings auf Teilprojektleiterebene
Teilprojektleiter treffen sich regelmäßig mit Projektleiter
Projektsteuerungs- oder Projektleitungsrunde, Themen, z.B.:
Klärung fachlicher und organisatorischer Probleme auf Projektebene
Koordinierung verschiedener, an der Projektdurchführung beteiligter Gruppen
Projektfortschritt und Risiken
473
5.2 Aufgabenträger
Im Lenkungsausschuss (engl.: steering committee) befinden sich
der Gesamtprojektleiter und Entwicklungsleiter von Auftragnehmerseite,
der Projektleiter und weitere wichtige Personen vom auftraggebenden Unternehmen sowie von
eventuell kooperierenden Unternehmen.
Üblicherweise wichtige Stakeholder, insbesondere auch
Kostenverantwortliche und Vertreter aus der Geschäftsleitung
Interne Projekte
-
fehlen Vertreter anderer Firmen,
stattdessen andere interne Abteilungen eingebunden (wie zum Beispiel Produktmanagement, Marketing,
Vertrieb, Produktion, Logistik, Einkauf).
Behandelte Themen:
Wichtige und strategische Entscheidungen
Finanzielle Fragen oder schwerwiegende organisatorische Probleme
Projektfortschritt und Risiken auf hohem Niveau
Meist ist der Lenkungsausschuss das oberste Gremium.
474
5.2 Aufgabenträger
Wenn jedoch die Geschäftsleitung nicht in den Lenkungsausschuss
eingebunden ist, gibt es gegebenenfalls als zusätzliche
Eskalationsstufe ein weiteres Gremium, Entscheidungsausschuss
genannt.
unternehmerische Verantwortung
letzte und höchste Eskalationsstufe.
Themen:
(projekt-)übergreifendeIT-Fragen auf hohem Niveau
z.B. mit grundlegenden Hardware- und Softwareentscheidungen in einem Unternehmen,
und
Entscheidungen bei der Projektpriorisierung im Rahmen der so genannten
Programmplanung zuständig.
475
5.3 Unternehmensstrukturen & Projektstrukturen
Projektspezifische
Definition der
Projektfunktionen
Übertragung der
Kompetenz und
Aufgabenträger
Projektfunktionen
Aufgabenträger
Organisationsformen

Reine
Projektorganisation

Projektleitung

Projektplanung und
-überwachung

Personen

Systemplanung
und -überwachung

Systementwicklung
Projektstellen
- Linienstellen
- Stabsstellen

Systemintegration
und -test

Qualitätssicherung

in die vorhandene
Organisation
Gremien
476

Ein Ziel der Projektorganisation ist die Regelung
der statischen Aspekte (Aufbauorganisation) und auch der
dynamischen Aspekte (Ablauforganisation) im Projekt.

Sowie die Regelung der Verantwortlichkeiten, beispielsweise
die Regelung der Aufgaben und Rechte der beteiligten Personen, d.h.

die Rollenverteilung im Projekt, und damit auch
die Festlegung der Kompetenzen,
die Definition der internen Schnittstellen (z.B. Schnittstellen zwischen Teilteams)
die Definition der externen Schnittstellen (z.B. Unterauftragnehmern und die Festlegung von
Eskalationswegen)
Statische Aspekt
welche Organisationseinheiten bzw. welche Personen aus welchen Organisationseinheiten im
Projekt zusammenarbeiten,
mit welchen Über- bzw. Unterordnungen und
mit welchen Befugnissen sie dies tun.
¾
Die Projektorganisation steht damit in enger Beziehung mit der
Unternehmensorganisation.
477
Grundstruktur:
Organisationsleitung:
Mittellinie:
Funktion: Operative Führung
Beispiel: Mittleres Management,
Gruppenleiter
Betrieblicher Kern:
Funktion: Strategische Führung
Beispiel: Geschäftsführung
Funktion: Operative Ausführung
Beispiel: Entwickler
Stab:
Funktion: Unterstützende Ausführung
Beispiel: Rechtsabteilung, Telefonzentrale,
Zentrale Forschungsabteilung,
Methodenberatung
478
Formen der Unternehmensorganisation:
Bereichsstruktur:
Untergliederung nach Geschäftsfunktion
Bereiche: z.B. Marketing, Entwicklung, Vertrieb, Buchhaltung, Forschung
Beispiel: BMW, Microsoft
Marktstruktur:
Untergliederung nach Produktgemeinsamkeiten
Märkte: z.B. BIS (ERP, CRM, etc.), Medizintechnik, Telekom
Beispiel: Siemens
Spezielle Varianten:
Nach Niederlassungen, z.B. Autohäuser
Nach Kunden, z.B. SBS – öffentliche Auftraggeber (BfA, BA)
479
Bereichsstruktur
¾ Schwerpunkte: Know-how-Transfer, Ressourcenflexibilität
480
Marktstruktur
¾ Schwerpunkte: Effizienz, Produktidentifikation, minimierte Kommunikation
481
Vor- und Nachteile von Organisationsformen
Bereichsstrukturierte Organisation:
Vorteile:
Standardisierung der Abläufe, erhöhte Wirtschaftlichkeit
Spezialisierung, Fachhierarchien, Wissenstransfer
Nachteile:
Aufwändige Koordination funktionsübergreifender Tätigkeiten
Mangelnde Flexibilität
Ausrichtung: Fertigung von Standardprodukten

Marktorientierte Gruppierung:
Vorteile:
Flexibilität (neue Marktsegmente)
I.A. geringerer bürokratischer Aufwand
Nachteile:
Schwacher Wissenstransfer durch fehlende Spezialisierung
Mangelnde Effizienz durch mangelnde Standardisierung
Ausrichtung: Fertigung von Individualprodukten
482
Projektformen
Wesentliches Element: Verantwortung
Fachliche Verantwortung („Was wird wann gemacht“)
Führungsverantwortung (Personalverantwortung)
(„Wer macht es wann mit welchem Aufwand“)
Problem:
Mitarbeiter sind in langfristige Organisationshierarchien eingebunden
Projekte konkurrieren kurzfristig mit diesen Hierarchien
Resultat: Konflikt zwischen Interessen der Linienhierarchie und der Projekthierarchie (i.E.
Linienverantwortung vs. Projektverantwortung)
Projektstrukturen:
Stab-Linien-Organisation
Projektorganisation
Matrixorganisation
483
Bereichsleitung
PL
E
Bereichsleitung
F
V
PL
PL
E
F
V
PL
Bereichsleitung
E
PL
F
V
PL
484
Projektorganisation
Prinzip:

Verantwortung Projektleiter:

Klare Kompetenzen und Verantwortlichkeiten
Hohe Projektidentifikation
geringer organisatorische Verknüpfungen
Kurze Kommunikationswege und geringster „Overhead“
Nachteile:

Fachliche Verantwortung
Führungsverantwortung
Bereichsleitung
PL
E
F
V
Vorteile:

Eigenständige Organisationseinheit
für Projekt, extra für Projekt eingerichtet
Projektmitarbeiter werden aus
Bereichen freigestellt
Umstellungsaufwände durch Aus-/Eingliederung
Gefahr des Etablierend der Projektgruppe nach Projektende
Schwächung der Bereiche
Problem der ungleichmäßigen Projektbelastung
Gefahr von Parallelentwicklungen in Projekt und benachbarter Linie
Einsatz:
kleine, mittlere oder große Projekte
häufig bei Projekten mit erheblichem Risiko
485
Projektorganisation
486
Extremfall: Projektstruktur als Unternehmensform
487
Prinzip:
Keine Leitungsinstanz/Organisationseinheit für Projekt
Projektmitarbeiter verbleiben vollständig
in Bereichen

PL
F
V
PL
Vorteile:
Schneller Know-How-Transfer
Flexible Kapazitätsauslastung
Keine Umstellungsaufwände

E
Keine fachliche Verantwortung
Keine Führungsverantwortung
Stabsfunktion (berichtend, koordinierend),
z.B. Laborleiter

Bereichsleitung
Nachteile:
Aufwändige Koordinations- und Abstimmungsprozesse
Keine Projektidentifikation
Keine Instanz mit Weisungsbefugnis

Einsatz:
Isolierte, kleine Projekte oder Teilprojekte
488
489
Bereichsleitung
Matrixorganisation
Prinzip:

E
F
V
PL
Fachliche Verantwortung
Keine Führungsverantwortung
Schneller Know-How-Transfer, Förderung
der Synergy Effekte
Optimale Kapazitätsauslastung
Geringe Umstellungsaufwände, schnelle Zusammenfassung von interdiszipliären Gruppen
Nachteile:

PL
Vorteile:

PL

Zeitlich befristetes Mehrliniensystem
Projektmitarbeiter verbleiben vollständig
in Bereichen
starke organisatorische Verknüpfung
Konfliktpotential durch Doppelunterstellung
Hohe Anforderungen an Selbstdisziplin und Eigenständigkeit
Hohe Anforderung an Teamfähigkeit und Sozialkompetenz von Mitarbeitern und Leitungskräften
Einsatz:
Flexible Projektabwicklung in dynamischem Umfeld (Markt und Technologiedynamik)
Mittlere und große Projekte
490
Matrixorganisation
491
Außerdem:
Profitcenter (strategisches Geschäftsfeld, -einheit)
Prinzip
-
Teilbereiche von Matrix- und Bereichsorganisationen
eigener Geschäftsabschluss dient als Beurteilung
agiert innerhalb eines Gesamtunternehmens als selbständiges Unternehmen
Vorteile:
-
hohe Flexibilität
hohe Motivation von Führungskräften und Mitarbeitern
rechtlich selbständig: Möglichkeit der Erhöhung der Kapitalbasis
Nachteile:
-
nur erfolgreich, wenn
» organisatorisch vom Gesamtunternehmen abgegrenzt
» Geschäftsstrategie selbst bestimmen kann
» klare Ergebnisverantwortung
Virtuelle Organisation
492
Außerdem - unternehmensübergreifende Projektorganisationen
klare Vertragsbeziehungen zwischen wirtschaftlich, rechtlich unabhängigen Projektpartnern
notwendig
Typische Formen:
Einzelauftragsorganisation
-
Auftraggeber behält Verantwortung für Gesamtvorhaben
vergibt für klar umgrenzte Teilvorhaben entsprechende Aufträge an Unternehmer (Unteraufträge)
Notwendig: Fachwissen über alle Bereiche und Integration der Komponenten
Konsortialorganisation
-
beteiligte Unternehmen bilden Konsortium (z.B. ARGE in der Bauwirtschaft)
Projektverantwortung, Arbeitsteilung und Haftung in Konsortialvertrag geregelt
i.A. ein Konsortialführer
für Auftraggeber fungiert das Konsortium als selbständiger Auftragnehmer mit dem Verträge geschlossen
werden
Generalunternehmerorganisation
-
Ein Unternehmen übernimmt die volle wirtschaftliche und technische Verantwortung
Andere Unternehmen über Unteraufträge für in sich abgeschlossen Aufgabenteile an dem Gesamtvorhaben
beteiligt.
493
5.4 Zusammenfassung

Projekt- und Produktstruktur

Arbeitsteilung:
Nach Prozesstätigkeiten (z.B. Analyse, Design, Implementierung)
Nach Produktstruktur (z.B. Präsentation, Logik, Datenhaltung)

Beobachtung:
Softwaresysteme: i.a. komplexe Produktstruktur
Softwaresysteme: Modularisierung zur Komplexitätsreduktion
Abstimmungsaufwand: Systemschnittstellen

Konsequenz: Abbildung der Produktstruktur auf Projektstruktur
494
5.4 Zusammenfassung

Gute Projektorganisation - wie gutes Softwaredesign:
schlanken Schnittstelle
D.h.
eindeutig Verantwortliche für bestimmte Aufgaben festlegen,
die Aufgaben so verteilen, dass
der Abstimmungsbedarf durch geschickte Zuordnung von Systemteilen zu Bearbeitern minimiert wird (d.h.
möglichst viele Schnittstellen in einer Hand),
möglichst selten zwischen mehreren verschiedenen Aufgaben und/oder Bearbeitern gewechselt werden
muss (Kontextswitch) und
Teams so groß wie nötig, aber so klein wie möglich eingeteilt werden (der Abstimmungsaufwand steigt
überproportional mit der Teamgröße).
¾
So werden Kommunikationspfade und damit Kommunikationsaufwand,
Missverständnisse, Doppelarbeiten etc. minimiert und Arbeiten effizienter
erledigt.
495
5.4 Zusammenfassung
Kommunikationsaufwand in Teams
Konsequenz:
Arbeitsteilung
Abstimmung- und Kommunikationsaufwand
Resultat: Zusätzlicher Aufwand
Rechenbeispiel: Aufwand bei 3-Stunden-Besprechungen
Zwei Parteien: 2*1*3 = 6 Ph/Woche
Vier Parteien: 4*3*3 = 24 Ph/Woche
Zehn Parteien: 10*9*3 = 270 Ph/Woche
Konsequenz: Minimierung der Schnittstellen
496
5.4 Zusammenfassung
497
5.4 Zusammenfassung
Phase
Organisationsformen
Definition
Entwurf
Realisierung
Erprobung
Einsatz
E-PO:
Es ist noch unsicher, ob es zu einer Beauftragung kommt
M-PO:
Interdisziplinäres Team für überschaubaren Zeitraum benötigt.
R-PO:
Das Projekt ist so bedeutend geworden, dass eine eigene
Organisationsform angebracht erscheint
S-PO:
Wartung und Support sollen von den einzelnen zuständigen
Stellen erbracht werden
498
5.4 Zusammenfassung
Festlegung der Projektstruktur:
Bereitstellung von Mitarbeitern: Einbettung in die Unternehmensorganisation
Einrichten einer internen Projektstruktur: Definition von Rollen und
Verantwortlichkeiten
Projektstruktur: ähnlich Unternehmensstruktur:
Leitung: Projektleiter
Kern: Projektmitarbeiter
Stab: Übergreifende Tätigkeiten (z.B. QM, KM)
Projekte konkurrieren mit Unternehmensstruktur:
Transparenz von Kompetenzen und Verantwortungen
Identifikation gemeinsamer Ziele Linie/Projekt
499
5.4 Zusammenfassung
Personalaufwand in Projekten
Beobachtung:
Kommunikationsaufwand bestimmt durch Projektstruktur
Projektstruktur bestimmt durch Produktstruktur
Konsequenz:
Erst: Festlegung der Produktstruktur
Dann: Festlegung der Projektstruktur
Evtl. iterativ
Resultat: Ungleichmäßige Personalausstattung
Beispiel:
500
Projektmanagment
1.
Einleitung
2.
Faktor Mensch
3.
Interviewtechniken
Zeitmanagement
Projektinitiierung
501
Projektmanagment
Schätzverfahren
Projektplanung
Einleitung
Projektfunktionen
Aufgabenträger
502
Projektmanagment
6.
Projektkontrolle
7.
Change-Management
Kostenkontrolle
Prozessverbesserung
Projektabschluss
503
Kapitel 6:
Projektkontrolle
504
6 Projektkontrolle
Projektkontrolle und Projektsteuerung
Projektkontrolle:
Feststellung des Projektstatus
Feststellung von Planabweichungen
Techniken:
Fortschrittsanalyse
Risikoanalyse
QS-Maßnahmen
Projektsteuerung
Durchführungsentscheidungen
Korrektivmaßnahmen
Techniken:
Risikomanagement
QM-Maßnahmen
505
6 Projektkontrolle
Ausgangssituation
Große Probleme in Projekten haben selten große Ursachen („Taktik der
Nadelstiche“)
Auf große Probleme kann mit einer kleinen Anzahl von Maßnahmen (manchmal
sogar eine!) erfolgreich reagiert werden
Wirklich problematisch sind kleine, aber öfter auftretende Probleme mit kleinen
Auswirkungen, die sich summieren („Kleinvieh macht auch Mist“)
506
6 Projektkontrolle
Ziele der Fortschrittskontrolle
Bestandsaufnahme:
Wo steht das Projekt aktuell (regelmäßig)?
Feststellung Projekt/Produktstatus und Abweichungen
Unterstützung Steuerung
Basis für weitere Planungen
Produktivitätsentwicklung (Soll/Ist)
Zeitplanung
Kapazitätsplanung
Identifikation von Problembereichen
Reaktion auf Probleme, Definition und Durchführung von Gegenmaßnahmen
507
6 Projektkontrolle
Fortschrittskontrolle ist nur ein Teil des gesamten
Projektcontrollings
Budget-/Zeitkontrolle
Risikomanagement
Mitarbeiterkontrolle
...
508
6 Projektkontrolle
Aufgaben der Kontrolle
Teilschritte:
Basis aller Vergleiche ist der detaillierte Projektplan (baseline)
-
Erstellt in der Projektplanungsphase
Ev. überarbeitet in der vorausgegangenen Periode
Erfassung des aktuellen Status (hier unterscheiden sich die Methoden)
Festlegung Vorgaben/Soll-Werte Projekt/Produkt
-
Projekt: Pläne (z.B. Terminpläne, Personalpläne, Kostenpläne)
Produkt: Standards (z.B. Dokumentvorlagen, Programmierrichtlinien) nach Qualitätsmanagement
Berichts- und Kontrollsystem einrichten
Feststellung/Messung Projekt/Produktstatus
-
Projekt: Fortschrittskontrolle
Produkt: Qualitätssicherung
Feststellung Abweichungen
Ableitung geeigneter Gegenmaßnahmen (falls notwendig)
Grundlage: Metriken
509
6 Projektkontrolle
Metrik
Abbildung einer Eigenschaft in einen Wertebereich
Wünschenswerte Kriterien (u.a.):
Objektiv: Unabhängig vom messenden
Zuverlässig: Wiederholungsneutral
Ökonomisch: Mit vertretbaren Kosten durchführbar
Nützlich: Für Kontrolle einsetzbar
Beispiele: Meilensteintermine, Fehleranzahl, Funktionspunkte
510
6 Projektkontrolle
Berichtswesen
Berichtswesen
Bereitstellung
Festlegung Verantwortlichkeiten: Messen, Aufbereiten, Weiterleiten
Grundregeln:
Regelmäßig: Dichte, gleichmäßige Messungen
Rechtzeitig: Maßnahmen zur Gegensteuerung
Richtig: Zuverlässige Daten (Metrik, Vertrauensschutz)
Berichtsarten (Beispiele):
Statusberichte: Messung aktueller Status
-
Planung: Budgetbericht, Terminbericht, Aufwandsbericht, Risikobericht
Qualitätssicherung: Fehlerbericht
Änderungsberichte: Vorhersage weitere Entwicklung
-
Planung: Meilenstein-,Termin-, Aufwandstrend
Qualitätssicherung: Fehlertrend, Change Requests
511
6 Projektkontrolle
512
Kapitel 6:
Projektkontrolle
513
6 Projektkontrolle
6.1 Projektrisiken und Risikomanagement
Risikomanagement und Projektphasen
514
6 Projektkontrolle
Risikomanagement:
Ziel: Bereitstellung von Verfahren zur Minimierung von Risiken
Verfahren: Identifizieren und Vermeiden von Risiken
Risiko: Möglichkeit des Eintretens eines Schadensfalls
Einzelschritte:
Risikobewertung
Identifikation
Analyse
Priorisierung
Risikobeherrschung
Planung
Überwindung
Überwachung
515
6 Projektkontrolle

Beobachtungen:
Pareto-Regel: 20% der Probleme verursachen 80% der Kosten
Behebungsverzögerung: je nach Phase bis zu 1000

Konsequenzen:
Fokussierung auf wichtige Risiken
Frühzeitige Erkennung und Vermeidung
516
6 Projektkontrolle
517
6 Projektkontrolle
Risikoidentifikation
Risikoidentifikation:
Aufgabe: Festlegung projektspezifischer Risiken
Verfahren: Erstellung Risikoliste
Einzelschritte:
Identifikation Risiken: Checklisten, Projektabschlüsse
Festlegung Risikotreiber: Faktoren, die Risiko beeinflussen
Festlegung Indikatoren: Metriken, die Risiko quantifizieren
Ermittlung Wahrscheinlichkeiten: Zuordnung Wahrscheinlichkeiten/Metriken
Beispiel:
Risiko: Unrealistische Kostenplanung
Risikotreiber: Übertriebene Anforderungen, unrealistische Wiederverwendung, kompliziertes Design
Indikatoren: Anzahl Anforderungen (in FP), Umfang Wiederverwendung (in % Code), Aufwand Design (in
Komponenten)
Wahrscheinlichkeiten: Übertriebene Anforderungen (gering: < 100 FP, mittel: < 1000, hoch >= 1000)
518
6 Projektkontrolle
Risikoidentifikation
519
6 Projektkontrolle
Weitere Risikoquellen
Anforderungen
Anforderungen insgesamt unausgereift oder in Teilen noch unklar
Voraussehbar zahlreiche Änderungen
Änderungsfreudigkeit des Kunden/Auftraggebers
Technik
Unrealistisches Design
Einzusetzende Technologie wird erst im Laufe des Projekts am Markt verfügbar
Unklar, ob geforderte Performanz erfüllt werden kann
Erstmaliger Einsatz neuer Tools, Soft- oder Hardwarekomponenten
Anwendung
Hohe Komplexität, viele ungelöste Probleme
Fehlende Erfahrung mit Teilaufgaben
Keine Erfahrung in neuer Anwendungsdomäne
Kunde
Konkurrierende Interessengruppen, Widerstände (z.B. von Anwendern)
Keine Erfahrung mit Auftragsvergabe nach außen
Mangelnde Kooperationsfähigkeit oder –bereitschaft
Integrierte Entwicklung Auftraggeber/Auftragnehmer
520
6 Projektkontrolle
Weitere Risikoquellen
Projektauftrag, -abwicklung
Unrealistische Termine
Unrealistische Budgets
Projektorganisation
Einsatz von Unterlieferanten (generell)
Bekannte Probleme von Unterlieferanten
Zulieferungen von anderen Projekten oder internen Stellen
Ressourcen
Drohender Ressourcenentzug wegen anderer, wichtigerer Projekte
Ressourcenengpässe oder unzuverlässige Ressourcenzusagen
Personelle Mängel
Nicht der richtige Projektleiter (unerfahren, ungeeignet, nicht anerkannt etc.)
Nicht die richtigen Mitarbeiter (mangelnde Qualifikation oder Erfahrung)
Drohender Ausfall von Mitarbeitern (Krankheit, Kündigung)
521
6 Projektkontrolle
Beispiele für Präventivmaßnahmen
Bei technischen Risiken:
Simulation oder Prototyping von Systemen
Beratung, Reviews durch Unabhängige
Anbieten alternativer Funktionen/Konzepte (bei denen das Risiko nicht auftritt)
Vorherige Erprobung von neuen Technologien
Bei Risiken bezüglich Anforderungen/Kunde:
Verstärktes Bemühen um den Kunden, Kontaktpflege
Kundenworkshops
(Frühzeitige) Abnahme von Zwischenergebnissen vereinbaren
Pflichten des Kunden vertraglich absichern
522
6 Projektkontrolle
Beispiele für Präventivmaßnahmen
Bei Ressourcenproblemen:
Schulung, Coaching von Mitarbeitern/Projektleiter
Einsetzen von Mitarbeitern in ähnliche Projekte im Vorfeld
Abwanderungsgefährdete Mitarbeiter zu halten versuchen
Prioritäten für die Ressourcenzusage mit Management diskutieren
Sonstiges
Preisaufschläge einkalkulieren
„Outsourcen“ von Risiken an Subunternehmer
523
6 Projektkontrolle
Risikoanalyse
Aufgabe:
Ermittlung Risikofaktor = Schadenwahrscheinlichkeit/Schadensausmaß
Skala Wahrscheinlichkeit/Schaden: normiert, z.B. 1 - 10
Partnerspezifische Risiken/Schäden:
Nutzer:
-
Erstellung Produkt mit mangelnder Qualität (funktional, Zuverlässigkeit, Benutzbarkeit, Effizienz)
Beachte: Risiko fällt i.a. auf Auftraggeber zurück.
Auftraggeber:
-
Projekt überschreitet Budget- oder Zeitplan
Beachte: Risiko fällt i.a. auf Entwickler zurück.
Entwickler:
-
Projekt überschreitet Budget- oder Zeitplan
Erstellung Produkt mit mangelnder Qualität (Änderbarkeit, Wartbarkeit, Übertragbarkeit)
524
6 Projektkontrolle
Bewertungsparameter
Eintretenswahrscheinlichkeit:
Wie wahrscheinlich ist es, dass der Risikofall eintritt?
Schadenshöhe:
Welchen Schaden wird das Risiko verursachen?
Risikoprioritätszahl (oder Risikokennzahl) =
Eintretenswahrscheinlichkeit * Schadenshöhe
525
6 Projektkontrolle
Charakterisierung der Eintretenswahrscheinlichkeit
Beispiel
Wahrscheinlichkeitsintervall
0 ≤ p ≤ 0,25
0,25 ≤ p ≤ 0,5
0,5 < p ≤ 0,75
0,75 < p ≤ 1
Interpretation
Es ist eher unwahrscheinlich, dass das Risiko eintritt, aber nicht
auszuschließen.
Das Risiko wird eher nicht eintreten, es ist aber dennoch möglich.
Das Risiko wird eher eintreten als nicht eintreten, es ist aber keineswegs
sicher.
Das Risiko wird mit ziemlicher Sicherheit eintreten.
526
6 Projektkontrolle
Charakterisierung der Schadenshöhe (Beispiel)
Einschränkungen der Funktionalität
für Endbenutzer kaum merklich
3-5
Einschränkungen der Funktionalität
für Endbenutzer merklich,
wesentliche Funktionen sind aber
unberührt, Produkt kann benutzt
werden
6-8
Wesentliche Funktionen sind
betroffen, Produkt kann nur mit
deutlichen Einschränkungen
benutzt werden
Einprodukte unbrauchbar
9 – 10
Schaden hinsichtlich
Projektkosten
Schaden hinsichtlich Überschreitung
der Projektdauer
Überschreitung Projektkosten
≤ 5%
Verzögerung kann wieder aufgeholt
werden, End-termin wird gehalten
> 5%,
aber ≤ 15%
Überschreitung Projektdauer bleibt
≤ 10%
> 15%,
aber ≤ 30%
Überschreitung Projektkosten >
30%
oder
1 -2
Schaden hinsichtlich
Endprodukten des Projekts
oder
Kennziffer für
Schadenshöhe
Überschreitung Projektdauer bleibt
≤ 20%
Überschreitung Projektdauer > 20%
527
6 Projektkontrolle
Beispiel einer Risikoliste im Projekt Mobile Odors
Nr.
Datum des
Eintrags
Beschreibung
Schadenshöhe
Wahrscheinlichkeit
Risiko-prio.zahl
Kategorie
1
05.01.
Zeit für Anforderungsanalyse reicht nicht
aus.
6
0,9
5,4
Anforderungs-risiko
2
05.01.
Ansprechpartner des Pilot-kunden stehen
wegen Urlaubssituation im Mai nicht
genügend zur Verfügung.
5
0,5
2,5
Anforderungs-risiko
3
05.01.
Übertragungsdauer der Ergebnisse von
Duftanalysen zu lange (Verdacht aus
Vorstudie).
9
0,5
4,5
Technisches Risiko
528
6 Projektkontrolle
Beispiel eines Risikoportfolios
Schadenshöhe
hoch
3
mittel
2
1
gering
gering
mittel
hoch
Wahrscheinlichkeit
529
6 Projektkontrolle
Risikomanagement: Weitere Schritte
Risikopriorisierung:
Aufgabe: Identifikation der höchsten Risiken
Verfahren: Identifiziere Risiken nach Analysefaktor gewichtet
Risikoplanung:
Aufgabe: Festlegung Kontroll- und Steuerungsaktivitäten
Verfahren: Bereitstellung Risikoplan
Risikoüberwindung:
Aufgabe: Abwendung auftretender Risiken
Verfahren:
-
Durchführung Risikoplan: Ausführung Steuerungsaktivitäten
Zyklische Durchführung
530
6 Projektkontrolle
Risikomanagement: Weitere Schritte (Fortsetzung)
Risikoüberwachung:
Aufgabe: Fortlaufende Erkennung von Risiken
Verfahren:
-
Durchführung Risikoplan: Fortschrittskontrolle, Trendanalyse
Evtl: Plananpassung
Zyklische Durchführung
531
Kapitel 6:
Projektkontrolle
532
6 Projektkontrolle
6.2 Konfigurations- und Versionsmanagement
Randbedingungen:
Produktkomplexität: Viele Module, viele Bearbeiter
Produktvielfalt: Viele unterschiedliche ausgelieferte Versionen
Probleme:
Rücknahme kontraproduktiver Änderungen: Welche Version muss wiederhergestellt
werden?
Identifikation von Fehlern: Welche (Modul-)Versionen sind davon betroffen?
Übernahme von Verbesserungen: Welche (Kunden-) Versionen sind davon betroffen?
Einführung neuer Versionen: Wo, warum, und von wem wurden Änderungen
vorgenommen?
Kontrolle: Welche Änderungen sind durchgeführt
533
6 Projektkontrolle
Wartungsaufwand Einzelprojekt
Einzelprojekt:
Individuelle Anfertigung
Schwerpunkt: Pflege (Fehlerbehebung)
534
6 Projektkontrolle
Wartungsaufwand langlebiges Projekt
Langlebiges Projekt:
Wiederholte Installation bzw. (anpassbare) Standardanwendung
Schwerpunkt: Änderung (Funktionserweiterung)
535
6 Projektkontrolle
Aufschlüsselung Wartungsaufwände
536
6 Projektkontrolle
Ziel:
Produkt ist hinsichtlich seiner funktionellen (Code) und äußeren
(zugehörige Information) Merkmale jederzeit identifizierbar
Funktion:
Sicherstellung der Identifizierbarkeit, Verfolgbarkeit, Kontrollierbarkeit, Status
Darstellung der Zusammenhänge und Unterschiede zwischen verschiedenen
Konfigurationen
Sicherstellung der Verfügbarkeit früherer Konfigurationen
Sicherstellen der Integrität (Gültigkeit, Reifegrad) von Produkten
Ansatz: Explizite Verwaltung von Produkten
537
6 Projektkontrolle
Produkt und Aktivität
Aktivitäten:
Benötigen, erzeugen, modifizieren Produkte
Produkte:
Synchronisieren, beeinflussen Aktivitäten
538
6 Projektkontrolle
KM: Produktzustände
Produktzustände:
Definiert auf allen Produkten des V-Modells
Verbinden KM mit allen weiteren Modulen
Ermöglichen Produktverwaltung
Zusammenhänge:
KM: Erfassung Produkt, Produktstatus, Produktänderung
QS. Überprüfung/Abnahme Produkt
PM: Planung Produkt
539
Projekthandbuch
Projektplan
KM 1
KM-Planung
KM 1.1
KM 1.2
Produkt
KM-Plan erstellen
KM einrichten
KM 2
Produkt- und
Konfigurationsverwaltung
KM
KM
KM
KM
KM
KM-Plan
2.1
2.2
2.3
2.4
2.5
Planung/Initiierung
Produkt/Konfig-Verwaltung:
Produkt initialisieren
Konfiguration initialisieren
Produkt verwalten
Konfiguration fortschreiben
Zugriffsrechte verwalten
Änderungsantrag/
Problemmeldung
KID
KM 3.1
KM 3.2
KM 3.3
Änderungsmanagement:
Änderungsauftrag
KM 3
Änderungsmanagement
(Konfigurationssteuerung)
Änderung bewerten
Änderungsvorgehen entscheiden und Änderung einleiten
Änderung abschließen
Initialisieren Produkte
Zustandsverfolgung von
Produkten
Konfig-Verwaltung
Änderungen gemäß
V-Modell-Regelungen
Produktbibliothek
Änderungenwünsche verwalten
Verantwortlichkeiten zu Rollen
Berichtsdokumente/
Projektabschlußbericht
Änderungsstatusliste
KM 4
KM-Dienste
Änderungsmitteilung
KM
KM
KM
KM
KM
KM
KM
Protokoll
Schnittstellenübersicht
Schnittstellenbeschreibung
Projektübergreifender
Datenkatalog
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Daten administrieren
SW-/HW-Produkte katalogisieren
Schnittstellen koordinieren
Ergebnisse sichern
KM-Dokumentation führen
Release-Management durchführen
Projekthistorie führen
Berichtsdokumente
Datenkatalog
Zentraler Produktkatalog
Projekthistorie
540
6 Projektkontrolle
Aufgaben Konfigurationsmanagement
Planung Konfigurationsmanagement
Bereitstellen Produkt-/Konfigurationsmanagement
Bereitstellung Änderungsmanagement
Bereitstellung von elementaren Diensten
Daten administrieren:
-
Zentrale, projektübergreifende Haltung aller Daten
Konsistente, vereinheitlichte Datendefinitionen
SW-/HW-Produkte katalogisieren: Vorbereitung Wiederverwendung
Schnittstellen koordinieren: Sicherung kompatibler Schnittstellen
Ergebnisse sichern: Wahrung des erreichten Projektstands
KM-Dokumentation führen zur Erstellung von Detailunterlagen und Übersichten
verschiedenster KM-Belange,
Release-Management: Kontrollierte Konfigurationsfreigabe- und verteilung
Projekthistorie führen: Nachvollziehbare Dokumentation über den Projektverlauf
541
6 Projektkontrolle
Konfiguration
Konfiguration:
Definition: Ansammlung von Produkten, die unabhängig von einander variiert werden
können, einschließlich ihrer Beziehungen
Beschreibung: Konfigurationsidentifikationsdokument
Funktion: Erfassung der Konfigurationselemente und ihrer Beziehungen
Umfasst:
-
Unterkonfiguration (z.B. HW-Konfiguration, SWKonfiguration)
Konfigurationselemente
Hilfselemente (Generierungswerkzeuge)
542
6 Projektkontrolle
Konfigurationselement
Konfigurationselement (engl. Configuration Item):
Definition: vom Konfigurationsmanagement erfasset und als Einheit behandelte
Ansammlung von Hard- und Software
Beispiele:
Quellcode-Dateien
Testtreiber, Testfälle, Testprotokolle
Entwicklungsdokumente (z.B. Pflichtenheft, Architekturentwurf)
Hardwarekonfigurationsbeschreibung
Im allgemeinen:
Nur ursprüngliche Dokumente
Keine generierten Dokumente (z.B. Binärcode)
543
6 Projektkontrolle
Ziel: Kontrolle der Änderungen
zur Sicherung der Produktqualität
-
Änderungsumfang
Verantwortlichkeiten
zur Kontrolle der Projektdurchführung
Statusverfolgung
Ressourcenplanung
Aufgaben:
Änderungen identifizieren
Änderungen bewerten
Änderungensvorgehen entscheiden und Änderungen einleiten
Änderungen abschließen
544
6 Projektkontrolle
Änderungen:
Änderungen verwalten
-
Entgegennehmen/bewerten
Entscheiden/einleiten
Abschließen
Verantwortlichkeiten für Änderungsaufgaben zuweisen
Entscheidungen herbeiführen und dokumentieren
Projekthistorie mitführen
545
6 Projektkontrolle
Begriffe: Version, Variante, Release
Begriffe:
Version: Ausprägung eines Konfigurationselements zu einem bestimmten Zeitpunkt
Variante: Zeitgleich nebeneinander liegende Ausprägung von Elementen
-
Parallele Entwicklungslinien
Unterschiedliche Implementierungen derselben Schnittstelle
Unterstützung unterschiedlicher HW/SW-Plattformen
Release: Element einer Referenzkonfiguration (baseline)
Baseline: Zu einem bestimmten Zeitpunkt ausgewähltes, gesichertes und freigebenes
(Zwischen-)Ergebnis
546
6 Projektkontrolle
Schnittstelle Berichtswesen
Berichtswesen
Festlegung Verantwortlichkeiten
Verteilen Informationen
Dokumentation Entscheidungen
Wesentliche Schnittstellen:
Änderungsmanagement: Erfassung Fehler, Änderungen
Projekthistorie: Dokumentation Projektabwicklung
Berichtsarten (Beispiele):
Fehleridentifikation
Änderungsanträge und Entscheidungen
Änderungsmeldungen
Projekthistorie
547
6 Projektkontrolle
Fehleridentifikation
Assoziierte Informationen:
Fehlernummer (laufende Nummer)
Datum des Erfassens
Art des Tests (Review/Walkthrough, Test)
Evtl. Testdaten
Beschreibung des Fehler/Verletzte Anforderung/Zugehöriger Testfall
Kritikalität des Fehlers
Lokalisierung/Modul/Dokument
Version des betroffenen Moduls/Dokuments
Aufwand des Findens
Maßnahme (Änderung Anforderungen/Änderung Dokument/Keine Änderung)
Fehlerstatus: Gefunden/Behoben/Getestet
Datum Behebung
Aufwand Fehlerbehebung
Von Behebung betroffene Module/Dokumente
548
6 Projektkontrolle
Projekthistorie
Entwicklungsverlauf
Entscheidungen
Schwierigkeiten, deren Ursachen und Behebung
Änderungs-/Versionshistorie
Nachvollziehbarkeit von Änderungen (Änderungen-Version-Bezug)
Dokumentation der Änderungshistorie (Anträge und Änderungen)
Dokumentation der Änderungsentscheidungen
Planungsstatistik
Planabweichungen und Planänderungen
Analyse der Ursachen
Möglichkeiten zur Verhinderung weiterer Planabweichungen
Änderungs- und Fehlerstatistik
Änderungsantrag/Problemmeldung
Betroffene Produkte
Klassifizierung, Beurteilung, Diagnose/Ursache
Maßnahmen zur zukünftigen Vermeidung
Analyse/Auswertung der Projekthistorie („lessons learned“)
549
Kapitel 6:
Projektkontrolle
550
6 Projektkontrolle
6.3 Qualitätsmanagement
551
6 Projektkontrolle
SW-Qualität: Produkt vs. Prozess
Unterscheidung:
Prozessqualität:
-
Faktoren: Planbarkeit, Effizienz (Kosten/Zeit), Produktqualität
Kontext: Prozesszertifizierung, Prozessverbesserung
Produktqualität:
-
Faktoren: ISO 9126
Kontext: Analytische/konstruktive QS-Maßnahmen
Verschiedene Qualitätsansätze zur Produktqualität
Extern getriebene Ansätze:
-
Nutzerbezogen: Benutzer legen Qualität fest
Kosten/Nutzen: Nutzen zu akzeptablem Preis
Qualitätsgetriebene Ansätze:
-
Prozessbezogen: Qualität durch den Erstellungsprozess
Produktbezogen: Qualität als meßbare Größe des Produkts
Hier: Produktbezogene Qualitätssicherung
Was ist Produktqualität?
Wie wird Produktqualität erreicht?
552
6 Projektkontrolle
Qualitätsmanagement:
Planung: Vorbereitende Maßnahmen
Lenkung: Konstruktive Maßnahmen
Sicherung: Analytische Maßnahmen
Verbesserung: Prozessverbesserungsmaßnahmen
553
6 Projektkontrolle
Qualität (ANSI/ASQC A3-1978), ISO 8402, DIN55350/1, IEEENorm)
“Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines
Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung
gegebener Erfordernisse bezieht”
Mit anderen Worten, Qualität ist an den Benutzeranforderungen zu messen (e.g.
Korrektheit, Verlässlichkeit, Verwendbarkeit, ...)
Software altert nicht, aber:
Es ist davon auszugehen, dass Software eine lange Lebensdauer hat und dabei immer
wieder adaptiert wird
Es gibt somit auch am System selbst orientiere Facetten der Qualität e.g. Wartbarkeit,
Portierbarkeit, Testbarkeit, ..
554
6 Projektkontrolle
V-Modell: QS- und SE-Aktivitäten
Analytische Maßnahme: von QS für SE
Konstruktive Maßnahmen: von QS auf SE-Produkten in QS
555
6 Projektkontrolle
Planung:
QS-Initialisierung: Konstruktiv
Prüfung (analytisch):
Vorbereitung
Prozessprüfung („Vorgaben
eingehalten“)
Produktprüfung
Leitung (administrativ):
QS-Berichtswesen
556
6 Projektkontrolle
Qualitätsplanung und Qualitätsverbesserung
Qualitätsplanung:
Ansatz: Vorbereitung qualitätssichernder Maßnahmen
Verfahren: QS-Plan (Prüfplan)
-
-
-
Definition Aufgabe: Was ist zu tun?
» QS-Merkmale identifizieren/Metriken auswählen
» Zu sichernde Produkte identifizieren
Definition Vorgaben/Hilfsmittel: Wie ist es zu tun?
» Konstruktive Vorgaben (z.B. Style Guides, Vorlagen)
» Analytische Vorgaben (Verfahren, Werkzeuge)
Definition Termine: (Bis) Wann ist es zu tun?
» Einordnung in den Projektplan
Definition Verantwortung: Wer hat es zu tun?
» Definition von Rollen (Q-Manager, Prüfer, Ersteller)
» Zuordnung von Verantwortlichen
Qualitätsverbesserung:
Ansatz: Auswertung QS-Ergebnisse und Prozessverbesserung
Verfahren: Siehe nächsten Abschnitt
557
6 Projektkontrolle
Qualitätslenkung und Qualitätssicherung
Qualitätslenkung:
Ansatz: Maßnahmen zur Umsetzung der Qualitätsziele
Verfahren:
-
Beurteilung Prüfergebnis
Berichtswesen und Analyse
Qualitätssicherung:
Ansatz: Maßnahmen zur Feststellung ob ausreichende Produktqualität vorliegt
Verfahren: (vorwiegend) analytisch/prüfend
Im folgenden:
Analytische und konstruktive Maßnahmen
Auswirkung auf die Prozessqualität
558
6 Projektkontrolle
Produktqualität - 3 Fragen
559
6 Projektkontrolle
SW-Qualität - was ist das?
SW-Qualität: Merkmale des SW-Produkts
Merkmalsbereiche (McCall):
-
Produkteinsatz
Produktbearbeitung
Produkterweiterung
Qualitätsmodell:
Merkmale: Relevante Produktkriterien
Metriken: Eigenschaften eines Produkts
Maße: Meßeinheit und Meßmethode zur Bestimmung
Modell: Standard (z.B ISO 9126) vs. Methode (z.B. GQM)
560
6 Projektkontrolle
McCall, Richards, Walters (1977)
McCall, Richards, Walters 77:
Factors in Software Quality, Rome Air Development Center, 1977
High-Level Attribute der Qualität
i.e. Qualitätsfaktoren
lassen sich nicht direkt messen
werden durch den Zusammenhang von Qualitätskriterien bestimmt
Low-Level Attribute der Qualität
i.e. Qualitätskriterien
lassen sich direkt messen (entweder objektiv oder subjektiv)
3 Product Activities mit insgesamt 11 Qualitätsfaktoren und 26 Qualitätskriterien
561
6 Projektkontrolle
McCall, Richards, Walters (1977) - Qualitätsfaktoren
Activity 1: Product Operation: Benutzer
Korrektheit (Correctness)
Das Ausmaß, zu dem das System die Anforderungsdefinition und die Ziele der Benutzer erfüllt
Verlässlichkeit (Reliability)
Das Ausmaß, zu dem das System seine beabsichtigte Funktion erfüllt unter Berücksichtigung der
notwendigen Präzision
Effizienz (Efficiency)
Der Umfang an Ressourcen und Code, den ein System zur Ausführung einer Funktion benötigt
Integrität (Integrity)
Das Ausmaß, zu dem der Zugriff von unberechtigten Personen auf Software und Daten kontrolliert werden
kann
Verwendbarkeit (Usability)
Der benötigte Einsatz, um den Umgang mit dem System zu erlernen, das System zu bedienen, Eingaben
vorzubereiten und die Ausgaben zu interpretieren
562
6 Projektkontrolle
Activity 2: Product Revision: Entwickler
Wartbarkeit (Maintainability)
Der benötigte Einsatz, um einen Fehler im System zu lokalisieren und zu korrigieren.
Testbarkeit (Testability)
Der benötigte Einsatz, um ein System zu testen und sicherzustellen, dass es die
beabsichtigte Funktion erfüllt
Flexibilität (Flexibility)
Der benötigte Einsatz, um am System Modifikationen vorzunehmen
563
6 Projektkontrolle
Activity 3: Product Transition (Benutzer und Entwickler)
Portierbarkeit (Portability)
Der benötigte Einsatz, um ein System für eine andere Hardware- und/oder
Software-Umgebung verwendbar zu machen
Wiederverwendbarkeit (Reusability)
Das Ausmaß, zu dem das System (oder Teile daraus) in anderen Applikationen
verwendet werden kann
Interoperabilität (Interoperability)
Der benötigte Einsatz, um ein System mit anderen zu verbinden
¾ Diese Liste ist natürlich noch erweiterbar!
564
6 Projektkontrolle
McCall, Richards, Walters (1977) - Qualitätskriterien
Zugangsprüfung (Access audit)
Die Einfachheit, mit der auf Software und Daten zugegriffen werden kann
Zugangskontrolle (Access control)
Die Vorkehrungen zur Kontrolle und zum Schutz von Software und Daten
Genauigkeit (Accuracy)
Präzision der Berechnungen und der Ausgabe
Allgemeinheit der Kommunikation (Communication commonality)
Das Ausmaß, zu dem Standard-Protokolle und –Schnittstellen Verwendung finden
Vollständigkeit (Completeness)
Volle Implementierung der benötigten Funktionalität
Kommunikativität (Communicativeness)
Die Einfachheit, mit der Eingabe und Ausgabe verbunden werden können
Kompaktheit (Conciseness)
Die Kürze des Source-Codes (Lines of Code)
565
6 Projektkontrolle
Konsistenz (Consistency)
Die Verwendung von einheitlichen Design- und Implementations- Techniken während des
Projektverlaufes (umfaßt auch einheitliche Notation)
Allgemeinheit der Daten (Data commonality)
Verwendung von Standard-Datenrepräsentationen
Fehlertoleranz (Error tolerance)
Kontinuität der Ausführung bei Vorliegen von unvorhergesehenen Ereignissen
Effizienz der Ausführung (Execution efficiency)
Laufzeitverhalten des Systems
Erweiterbarkeit (Expandability)
Das Ausmaß, zu dem gesteigerte Speicheranforderungen oder gesteigerte Anforderungen an
die Funktionalität berücksichtigt werden können
Allgemeinheit (Generality)
Die “Breite” der möglichen Einsatzbereiche von Software-Komponenten
Hardware-Unabhängigkeit (Hardware independence)
Das Ausmaß, zu dem die Software von der verwendeten Hardware abhängig ist
566
6 Projektkontrolle
Instrumentation (Instrumentation)
Das Ausmaß, zu dem die Software selbst Messungen über Daten (e.g. Speicherbedarf)
während der Ausführung bereitstellt bzw. die Identifikation von Fehlern ermöglicht
Modularität (Modularity)
Grad der Unabhängigkeit der einzelnen Module
Ausführbarkeit (Operability)
Die Einfachheit der Ausführung
Selbsterklärung (Self-documentation)
Der Umfang an in-line Kommentaren zur Beschreibung der Implementation
Einfachheit (Simplicity)
Der benötigte Einsatz für das Verständnis der Software (impliziert die Vermeidung von
Praktiken, die die Komplexität der Software erhöhen)
Software-Unabhängigkeit (Software system independence)
Das Ausmaß, zu dem das Produkt von seiner Software-Umgebung abhängig ist (e.g. NonStandard Sprachkonstrukte, Betriebssystem, Bibliotheken, ...)
Speichereffizienz (Storage efficiency)
Speicherbedarf zur Laufzeit des Systems
567
6 Projektkontrolle
Nachvollziehbarkeit (Traceability)
Die Möglichkeit, Software-Komponenten mit der Anforderungsdefinition in
Verbindung zu setzen
Training (Training)
Die Einfachheit, mit der neue Benutzer vom System Gebrauch machen können
¾ Diese Liste ist natürlich noch erweiterbar!
568
6 Projektkontrolle
SW-Qualität und ISO 9126
6 Qualitätsmerkmale
Funktionalität: Richtigkeit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit,
Sicherheit
Zuverlässigkeit: Reife, Fehlertoleranz, Wiederherstellbarkeit
Benutzbarkeit: Verständlichkeit, Erlernbarkeit, Bedienbarkeit
Effizienz: Zeitverhalten, Verbrauchsverhalten
Änderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit
Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit
569
6 Projektkontrolle
DIN ISO 9126
Funktionalität:
Vorhandensein von Funktionalität entsprechend den Anforderungen
Richtigkeit: Liefern der Richtigen Werte in bestimmter Genauigkeit
Angemessenheit: Eignung der Funktionen für best. Aufgabengebiete
Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuarbeiten
Ordnungsmäßigkeit: Erfüllung Anwendungsspezifischer Normen und Gesetze
Sicherheit: Fähigkeit, unberechtigten Zugriff zu Verhindern
570
6 Projektkontrolle
DIN ISO 9126
Zuverlässigkeit:
Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über
einen festgelegten Zeitraum zu erbringen
Reife:
geringe Versagenshäufigkeit durch Fehlzustände
Fehlertoleranz:
Fähigkeit, Leistungsniveau bei SW-Fehlern oder Schnittstellen-Fehlern einzuhalten
Wiederherstellbarkeit:
Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen (benötigte Zeit,
Aufwand)
571
6 Projektkontrolle
DIN ISO 9126
Effizienz:
Verhältnis zwischen Leistungsniveau der SW und Umfang der eingesetzten
Betriebsmittel
Zeitverhalten:
Antwortzeiten, Verarbeitungszeiten, Durchsatz
Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel
Benutzbarkeit:
Aufwand für Benutzung, Beurteilung von Benutzergruppen
Verständlichkeit:
Aufwand für Verständnis von Konzept und Anwendung
Erlernbarkeit:
Aufwand für Erlernen der Bedienung
Bedienbarkeit: Aufwand für Bedienung
572
6 Projektkontrolle
DIN ISO 9126
Änderbarkeit:
Aufwand für Korrekturen, Verbesserungen, Anpassungen
Analysierbarkeit:
Aufwand zur Diagnose von Mängeln und Ursachen für Versagen
Modifizierbarkeit:
Aufwand zur Ausführung von Verbesserungen, Fehlerbeseitigung oder Anpassung
Stabilität:
Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen
Prüfbarkeit:
Aufwand zur Prüfung geänderter Software
573
6 Projektkontrolle
DIN ISO 9126
Übertragbarkeit:
Eignung zur Übertragung in andere SW oder HW Umgebung
Anpassbarkeit:
Möglichkeit der Anpassung
Installierbarkeit:
Aufwand zur Installation
Konformität:
Grad des Einhaltens von Normen für Übertragbarkeit
Austauschbarkeit:
Möglichkeit, diese SW anstelle einer anderen zu verwenden
574
6 Projektkontrolle
Qualitätssicherung
IEEE-Norm
Qualitätssicherung ist die Gesamtheit der Maßnahmen und Hilfsmittel, die dazu
eingesetzt werden, um den Anforderungen an das Software-Produkt und an dessen
Entwicklungs- und Pflegeprozess zu entsprechen
ISO 8402
Qualitätssicherung ist Teil der Managementfunktionen, die die Qualitätspolitik bestimmen
und über ihre Einhaltung wachen.
575
6 Projektkontrolle
Aufgaben der Software Qualitätssicherung
Sicherstellen, dass Tätigkeiten genau in der Art durchgeführt werden, wie sie
geplant waren
Erhöhung der Softwarequalität durch ständige Beobachtung der Software und
ihres Entwicklungsprozesses
Sicherstellen der Übereinstimmung zwischen etablierten Standards bzw.
Vorgehensmodellen und dem Entwicklungsprozess
Sicherstellen, dass ein nicht entsprechendes Produkt, sein Entwicklungsprozess
bzw. der angewandte Standard dem Management bekannt wird damit
Gegenmaßnahmen getroffen werden können
576
6 Projektkontrolle
Wie erziele ich Produktqualität?
Zwei Ansätze:
Passiv (analytisch):
-
Feststellen der Produktqualität nach Erstellung
Korrektur bei mangelnder Qualität
Aktiv (konstruktiv)
-
Vorbeugende Maßnahmen bei Erstellung
Keine Korrektur erforderlich
Aber:
-
Konstruktiv als Voraussetzung für analytisch
Analytisch: „Kein Fehler˝ vs. Fehlerfreiheit
577
6 Projektkontrolle
Analytische Verfahren
Ansatz:
Keine Qualität per se:
-
Feststellen der Qualität nach der Realisierung
Korrektur zur Qualitätssteigerung
Meist: Funktionalität, Zuverlässigkeit, Änderbarkeit
Verfahren:
Analysierend = statische Überprüfung:
-
Statische Analyse
Review
Verifikation
Testend = Überprüfen in der Ausführung:
-
Funktionaler Test
Strukturtest
578
6 Projektkontrolle
Analytische Verfahren: Statische Analyse
Bewerten des Produkts mittels Metriken
Schwerpunkt: Zuverlässigkeit, Änderbarkeit
Verschiedene Metriken:
Komponenten:
-
Umfang: LOC
Innere Struktur: Kontrollflusskomplexität
Schnittstelle: Anzahl Methoden/Klasse, Schnittstellenbreite
Systeme:
Umfang: LOC
Kopplung: Anzahl Aufrufe in/aus Komponente
OO-Metriken
579
6 Projektkontrolle
Beispiele: Metriken
Komponentenmetriken: „algorithmische“ Komplexität
Halstead: Anzahl (verwendeter) Opertoren/Operanden
McCabe: Anzahl Knoten/Kanten Kontrollflussgraph
Strukturmetriken:
Komponenten/Subkomponenten
Schnittstellenkomplexität (Anzahl, Breite, Struktur)
Weitere:
OO-Metriken: Anzahl Vererbungsstufen, Attribute, Methoden
Fokus auf Implementierungsgüte
580
6 Projektkontrolle
Analytische Verfahren: Manuelle Prüfung
Arten:
Inspektion
Review
Walkthrough
Audit
Ziel: Identifikation von Produktdefekten
Technik:
Prinzip: Manuelles Prüfverfahren
Produkte: i.a. Dokumente (Spez.,Code)
Vorgaben: Richtlinien, Checklisten
Vorgang: Individuelle/moderierte Begutachtung
Ergebnis: Freigabe/Änderungsprotokoll
581
6 Projektkontrolle
Analytische Verfahren: Inspektion
Inspektion:
Definition:
Die Code-Inspektion hat zum Ziel, die Qualität der SW sowie die Leistung der Programmierer zu steigern,
indem die Schnittstellen, die Ablaufstruktur, der Codierstandard, etc. überprüft werden
Ansatz: Verbesserung schriftlicher Dokumente
-
manuelle, formalisierte Prüfmethode
Identifikation von schweren Defekten
anhand von Referenzunterlagen
Nebenwirkung: Verbesserung Entwicklungsregeln/Prozess
Rollen (nach Fagan, 1976, IBM):
-
Moderator (nicht Vorgesetzter): prüft Eingangskriterien; plant Durchführung; legt Referenzdokumente fest;
weist Rollen zu; zerlegt Prüfobjekt in geeignete Arbeitspakete; legt Termine fest; moderiert Sitzungen; stellt
Protokollqualität fest; prüft Überarbeitung; gibt Dokument frei.
Autor: reicht Prüfungsobjekt ein; überarbeitet Objekt nach Protokoll
Protokollführer: sammel potentielle Defizite aus Einzel- und Gemeinschaftsprüfung; erstellt Protokoll
Inspektoren: wird i.a. einer Rolle zugewiesen (z.B. Benutzer, System, Service); führen Individual- und
Gruppenprüfung durch.
582
6 Projektkontrolle
Analytische Verfahren: Inspektion
Schritte:
Beantragung (Autor), Festlegung eines Moderators (PM)
Kurzprüfung des Objekts auf Eingangsqualität (M)
Festlegung Inspektionsteams, Zuordnung von Aufgaben an die Inspektoren (M), Festlegung von
Referenzdokumenten
Individuelle Prüfung/Sammeln von potentiellen Defekten (I, ca. 1 Seite/h)
Moderierte Inspektionssitzung (Geschwindigkeit: ca. 20% zusätzliche Defekte gegenüber 80%
Individualdefekten; Protokollierung Fehler (Individualprüfung/Inspektion) (M/I) mit defektspez. Information
(Kurzbeschreibung, Ort, Bezug zu Referenzdokumente, leicht/schwer, Indiviual- oder Gesamtsitzung,
Verbesserungsvorschläge)
Überarbeitung Prüfobjekt (Änderung Objekt, Änderung Fehlergrad (schwer/leicht), Änderungsantrag für
Referenzobjekt) (A)
Überprüfung Überarbeitung hinsichtlich Sorgfalt/Vollständigkeit (nicht Korrektheit!) (M)
Überprüfung Freigabekriterien (z.B. alle notwendigen Änderungsanträge gestellt; nur 0,25 schwere
Restdefekte/Seite bei 60% Effektivität Entdeckung und 85% Effektivität Behebung; Autor und Moderator
stimmen Freigabe zu; optimale Prüfungsgeschwindigkeit eingehalten)
583
6 Projektkontrolle
Analytische Verfahren: Review/Walk-Through
Review:
Definition:
Ein Review ist ein mehr oder weniger formal geplanter, strukturierter Analyse- und Bewertungsprozeß, in
dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesem kommentiert oder
genehmigt werden. Was unter welchem Aspekt wann “reviewed” wird, ist im Prüfplan eines Projektes
festgelegt
Ziel: Identifikation Defekte/Standardabweichung, Freigabe
Dokumente: Prüfprodukt, Referenzdokumente
Rollen: Moderator, Autor, Protokollführer, Gutachter
Verfahren:
-
Eingangsprüfung, Individualprüfung
Reviewsitzung
Überarbeitung
Walk-Through:
Ziel: Identifikation von Defekten, Vermittlung von Inhalten
Dokumente: Prüfprodukt
Rollen: Autor, Gutachter
Verfahren: Gruppensitzung
584
6 Projektkontrolle
Qualitätssicherung - Technischer Review
Gegenstand des Reviews: “Prüfobjekt”:
-
Anforderungsspezifikation oder
Design (Entwurf) oder
Code oder div. technische/organisatorische Konzepte
Ziele:
-
frühzeitige Fehlererkennung; Minimieren von Fehlern;
Optimierung der Vollständigkeit;
Verbesserung der Verständlichkeit
Voraussetzungen:
-
Gutachter müssen die Methodik, nach der das Prüfobjekt
erstellt wurde, kennen;
verwendete Standards/Richtlinien sind zu referenzieren;
der Fragenkatalog/die Aspekte, nach welchen geprüft wird,
müssen schriftlich festgelegt sein; ...
585
6 Projektkontrolle
Prozeß eines technischen Reviews:
selektiere
Review-Team
bestimme Ort
und Zeit
verteile
Unterlagen
halte ReviewSitzung ab
notiere Aktionen und
führe Änderungen durch
586
6 Projektkontrolle
Kommentare zum Vorgehen bei technischen Reviews:
ad Reviewteam:
-
Projektleiter bestimmt Gutachter, falls diese nicht schon vergegeben sind;
das Reviewteam soll einige Projektmitarbeiter (3-4) mit großem, heterogenem Wissensspektrum
beinhalten;
ad Verteilung der Unterlagen:
-
muß rechtzeitig, allenfalls nach Fertigstellung der Dokumente geschehen, damit eine ausführliche
Vorbereitung möglich ist;
ad Reviewsitzung: (max. 2 Stunden)
-
-
ein Mitglied des Reviewteams wird zum/zur Vorsitzenden ge-wählt und ist für die Organisation des
Reviews verantwortlich; ein anderes Mitglied wird mit der Schriftführung betraut und ist für die
Aufzeichnung aller während der Sitzung gefällten Entscheidungen verantwortlich
der Autor des Prüfobjektes führt das Reviewteam durch das Dokument (Vorlesen, Präsentation, ...):
“Walk-Through”
das Team notiert Probleme, Inkonsistenzen und stellt Fragen;
vorerst werden keine Lösungsversuche unternommen!
587
6 Projektkontrolle
Kommentare zum Vorgehen bei technischen Reviews:
ad Abschluß - Nachbearbeitung:
-
-
Nach Abschluß des Walk-Through werden alle Kommentare durchgegangen;
einige können unzutreffend sein und werden verworfen.
Alle anderen werden einer der folgenden Kategorien zugeordnet, zum Beispiel:
(K1) Problem vernachläßigbar, keine Aktion;
(K2) gebe Autor (z.B. Designer) zur Korrektur;
(K3) überdenke Teilentwurf neu; Änderungen betreffen andere Teile des Entwurfs (der Analyse,...);
Treffen zwischen betroffenen Personen wird vereinbart.
Formulare betreffend Aktionen und Kommentare werden von Autor und Vorsitzendem unterfertigt
und als Teil der Projektdokumentation abgelegt.
Der/die Vorsitzende ist für die Durchführung der Änderungen verantwortlich;
falls nur kleine Probleme auftreten, kann von einem weiteren Review abgesehen werden;
bei größeren Problemen wird ein weiterer Review anberaumt, ggf. werden Betroffene verständigt.
588
6 Projektkontrolle
Projektreview (Management-Review):
Gegenstand des Reviews und Bedeutung:
-
“Standortbestimmung” aus bestimmtem Blickwinkel:
» Kontrolle des Sachfortschritts, der Termine, Kosten, etc.,
» unter Beibeziehung der technischen Reviewberichte,
Testberichte, Auditsberichte,...;
Zeitpunkt der Durchführung:
-
nach Phasenende oder in speziellen Situationen wie
Wechsel des Projektleiters, Auftraggeber-Probleme,...
Zusammensetzung des Reviewteams:
Gutachter, Moderator, Projektleiter, Vorsitzender des Projektleiters, Projektmitarbeiter
Voraussetzungen:
-
die Anforderungen an das Projektmanagement liegen in meßbarer Form vor (s. Pflichtenheft des PM);
Definition der Ziele des Reviews; was soll erreicht werden?
Vorliegen quantifizierter System- und Abwicklungsziele;
Bereitschaft zur Verwertung der Ergebnisse.
Ablauf:
-
etwas weniger formal als bei technischen Reviews, da größere Komplexität der Fragestellungen
589
6 Projektkontrolle
Prozeß eines Projektreviews:
Planungssitzung
abhalten
Review
vorbereiten
Reviewsitzung
abhalten
analysiere
Ergebnisse
setze erlassene
Maßnahmen um
590
6 Projektkontrolle
Kommentare zu den Schritten von Projektreviews:
ad Planungssitzung:
-
es wird festgelegt, wann wo, wer, wie, wen/was kontrolliert; auch Zielfestlegung;
ad Vorbereitung:
-
soll max. 2 Wochen dauern, während welcher noch offene Arbeiten abgeschlossen/überarbeitet
werden können;
Gutachter formulieren Fragen und erstellen Checklisten;
Projektteam: aktualisiert Ergebnisse, bereitet Dokumente vor; - Projektleiter stellt Präsentation
zusammen;
Moderator: informiert alle Verantwortlichen offiziell;
ad Durchführung:
-
Projektleiter/Mitarbeiter präsentieren Projektstatus;
Gutachter stellen Fragen bzgl. der Präsentation;
Gutachter stellen Zusatzfragen gemäß Checklisten;
Konklusionen ziehen in gemeinsamem Gespräch;
Risikobeurteilung;
Festlegen des weiteren Vorgehens durch Projektleiter-Vorgesetzten in Abstimmung mit dem
Projektleiter
591
6 Projektkontrolle
Kommentare zu den Schritten von Projektreviews:
ad Analyse der Ergebnisse:
-
-
Dauer: max. eine Woche;
Gutachter analysieren die Ergebnisse der Sitzung und entwerfen Maßnahmen zur Problemlösung
in zwei Berichten:
» Review-Bericht - Inhalt: technische Sachverhalte; Risikobeurteilung; Empfehlung
korrektiver Maßnahmen; zu treffende Entscheidungen;
» Aktionsplan - soll die Durchsetzung der getroffenen Phasenentscheidungen und/oder
Qualitätsmängelbehebungen gewährleisten;ggf. Änderung von Prioritäten, Terminen,
Budgets, Aufgabenumverteilung;
Dokumente werden der zuständigen Instanz (Kontrollausschuß, Auftraggeber,...) zwecks
Entscheidung über das weitere Vorgehen übermittelt.
ad Umsetzung: Projektleiter modifiziert den Projektplan und führt das Projekt gemäß der
neuen Planung weiter
592
6 Projektkontrolle
Analytische Verfahren: Projektaudit
Definition:
Ein Audit ist eine Aktivität, bei der sowohl die Angemessenheit und Einhaltung
vorgegebener Vorgehensweisen, Anweisungen und Standerds als auch deren
Wirksamkeit und Sinnhaftigkeit geprüft werden.
Ziel:
Beurteilung der Qualität des Projektabwicklungs-Verfahrens:
Konformität des SW-Prozesses mit Vorgaben;
Vollständigkeit, Effektivität des SW-Prozesses;
Praktiken, Leistungen des Managements;
593
6 Projektkontrolle
Ablauf:
Planungsphase:
-
Einführungsgespräch unter Leitung des Qualitätsauditors
Teamzusammensetzung ähnlich Projektreview
Festlegen von Termin, Ort, Ablauf, Aufgaben, Ziele,...
Zusammentragen von Vorbereitungsmaterial wie:vorhandene Projektkennwerte, Checklisten,
Projekthandbuch, QS-Richtlinien, etc.
Analysephase:
Beantwortung von Fragen wie z. B.:
-
Werden aktuelle QS-Richtlinien befolgt?
Wurde in der Projektabwicklung gemäß dem vorgegebenen Verfahren gearbeitet?
Entsprechen die Ergebnisse den geforderten Werten, z.B. bzgl. Vollständigkeit, Formalität
Entsprechen die Projektplandaten den Projektkennwerten?
Entspricht die Wirksamkeit der eingesetzten Methoden und Werkzeuge den definierten
Vorstellungen?
594
6 Projektkontrolle
Auditsitzung: (Leitung: Auditleiter)
Beurteilung aller aufgeführten Analysedaten;
Ordnung von Negativ- und Positivwerten und Herausfinden von deren systembedingten
Ursachen;
Erstellung eines Auditberichts mit Feststellungen und für notwendig erachteten,
besprochenen Maßnahmen;
Prozeßintegration:
Weiterleitung des Auditberichts zum Projektreviewteam;
Besprechung der empfohlenen Maßnahmen im Rahmen des nächsten Projektreviews;
Integration der notwendigen Maßnahmen in den weiteren SW-Prozeß.
595
6 Projektkontrolle
Analytische Verfahren: Verifikation
Ziel: Vollständige Überprüfung der Korrektheit
Technik:
Formalisierung (Teil-)Spezifikation
Formalisierung Implementierung
Mathematische Überprüfung
Verfahren:
Interaktiv (Theorembeweiser)
Automatisch (Model Checker)
Einschränkung:
U.U. aufwendig
Überprüfung der Formalisierungen
596
6 Projektkontrolle
Analytische Verfahren: Testen
Definition:
Testen ist der Prozeß, ein SW-Produkt durch manuelle oder automatisierte
Hilfsmittel zu bewerten, um damit die Erfüllung der speziellen Anforderungen
nachzuweisen
Testziele:
Funktionalität: Richtigkeit
Zuverlässigkeit: Fehlertoleranz, Reife
Testprinzip:
Überprüfung Implementierung vs. Spezifikation
Überprüfungsmittel: Testfälle
Testgüte: Überdeckung des Testraums
Spezialfall: Regressionstest (Änderungstest)
597
6 Projektkontrolle
Testen: Formen und Verfahren
Ansätze:
Strukturtest (Glass-Box-Test):
-
Kontrollflussorientiert
Datenflussorientiert
Funktionaler Test (Black-Box-Test)
-
Aquivalenzklassentest
Testen spezieller Werte
Zufallstest
Test von Automaten
598
6 Projektkontrolle
Testen: Pfadüberdeckung
Ziel: Umfassende Testfallgenerierung
Verfahren:
Implementierung als Kontrollflussgraph
Für jeden Pfad im Graph einen Testfall
Praxis: Maximale Pfadlänge
599
6 Projektkontrolle
Testen: Schritte im Prozess
Test: konstruktive und analytische Anteile
Testen im Prozess:
Konstruktive Maßnahmen:
-
Anforderungsanalyse: Spez. Abnahme-/ Belastungstest
Entwurf: Spez. Modultest/Integrationstest, Instrumentierung
Umsetzung: Instrumentierung
Test: Testbettvorbereitung
Analytische Maßnahmen
-
Modultest
Integrationstest
Abnahmetest, Belastungstest
600
6 Projektkontrolle
Konstruktive Verfahren
Ansatz:
A-priori-Absicherung der Produktqualität
Vorgabe von Konstruktionstechniken
Präventiv (keine Behebung erforderlich)
Techniken:
Methoden (Beispiel: SA)
Sprachen (Beispiel: Java statt C++)
Richtlinien (Beispiel: NASA Coding Standard)
Checklisten, Vorlagen
601
6 Projektkontrolle
Konstruktive Verfahren: Methoden
Ziel:Strukturierte Vorgehensweise
Technik: Vorgabe von Zwischenprodukten
Vorgaben von Modellen (z.B. Objektorientierte
Vorgabe von Einzelschritten (z.B. OOA mit fachl. Klassenmodell, Use CaseModellierung)
Vorgabe von Erstellungsmittel (z.B. Klassendiagramm, Objektdiagramm, Use Case
Diagramm)
Ansätze:
SA: Datenfluss, Struktur
SSADM:Funktion, Struktur,Prozess
OAAD:Daten, Struktur, Prozess
Zusätzlich:
Änderbarkeit
Werkzeugunterstützung
602
6 Projektkontrolle
Konstruktive Verfahren: Richtlinien
Ziel: Produkteigenschaften a-priori festlegen
Technik:
Vorgaben von Checklisten, Schablonen
Überprüfung der Richtlinien
Ansätze:
Analyse: Strukturierung (z.B. SCR-Tabellen)
Design:
-
Architektur (z.B. Pattern)
Beschreibungen (z.B. Automaten)
Umsetzung: Code (z.B. NASA Coding Standard)
Zusätzlich: Änderbarkeit, Übertragbarkeit
603
6 Projektkontrolle
Beispiel: Coding Standards (NASA)
604
6 Projektkontrolle
Was kostet Qualität?
Ziel: Vermeidung von Qualitätsmängeln
Bisher:
Was sind Mängel?
Wie vermeidet man Mängel?
Was kostet Qualität?
Wann entstehen Mängel?
Welcher Aufwand entsteht bei der Behebung?
Wie effektiv ist die Behebung?
Strategie
Qualität
Produktivität
605
6 Projektkontrolle
Fehlerarten im Prozess
Wann werden welche Fehler gemacht:
Fatal: Anforderungsdefinition
Schwer: Entwurf
Mittel, leicht: Entwurf, Umsetzung
606
6 Projektkontrolle
Aufwand
Aufwand:
Ausführung: wenig Unterschiede
Vorbereitung/Behebung: frühe Aktivitäten effizienter
607
6 Projektkontrolle
Effektivität
Effektivität:
Nur Testen: 1 von 4 Mängel unentdeckt
Frühe Mängel benötigen frühe Maßnahmen
Hohe Qualität: Kombinierte Ansätze
608
6 Projektkontrolle
Produktqualität im Entwicklungsprozess
Generell:
Schwerwiegende Mängel zu Prozessbeginn
Kosten Fehlerbehebung steigen (bis zu x10)
Analyse/Entwurfsmängel schwer testbar
Aber:
Qualitätssicherung oft erst nachgelagert
Für hohe Qualität:
Fehler frühzeitig finden
Fehler vermeiden anstatt finden
609
6 Projektkontrolle
Qualität und Produktivität
Konstruktive Maßnahmen
Strukturierte Methoden
Werkzeuggestützte Entwicklung
Hohe Programmiersprachen
Konstruktive Verfahren:
Verlagerung Aktivitäten in frühe Phasen
Wirken präventiv
Unterstützen Anpassbarkeit (Wiederverwendung)
Resultat:
Qualitätssteigerung
Effektivitäts/Produktivitätssteigerung
610
6 Projektkontrolle
Qualität und Werkzeuge
Unterstützend: Projekt, Konfiguration
Analytische Werkzeuge:
Metriken: Messwerkzeuge für Kennzahlen
Test: Testwerkzeuge
Konstruktive Werkzeuge:
Sprachen: Basiswerkzeuge
Richtlinien: Prüfwerkzeuge
Methoden: Analyse/Entwurfswerkzeuge
Nutzen:
Steigerung der Qualität (50%)
Steigerung der Produktivität (30%)
611
6 Projektkontrolle
Zusammenfassung
Produktqualität ist anforderungsabhängig
Maßnahmen zur Qualitätssicherung:
Test sichert Qualität nach/bei Realisierung
Frühzeitige Maßnahmen möglich:
Reviews
Konstruktive Maßnahmen (Verfahren, Werkzeuge)
Strategie: Frühzeitige Qualitätssicherung
Verbessert Qualität
Verbilligt Qualität
Erhöht Produktivität
Berücksichtigung Qualitätssicherung im Prozess
612
Kapitel 6:
Projektkontrolle
613
6 Projektkontrolle
6.4 Fortschrittskontrolle
Generell Vorgehensweise
Basis aller Vergleiche ist der detaillierte Projektplan (baseline)
Erstellt in der Projektplanungsphase
Evtl. überarbeitet in der vorausgegangenen Periode
Erfassung des aktuellen Status (hier unterscheiden sich die Methoden)
SOLL/IST Vergleich auf Basis vorab definierter Metriken (key performance
indicators)
Ableitung geeigneter Gegenmaßnahmen (falls notwendig)
614
6 Projektkontrolle
615
6 Projektkontrolle
Meilensteine
Meilensteine bezeichnen
Definierte Sachergebnisse (Meilenstein-Inhalt)
Fertigstellungstermin (Meilenstein-Termin)
Meilenstein-Inhalte sind
wesentlich
überprüfbar
übergebbar
eindeutig festgelegt
voraus definiert (Phasenorganisation)
¾ Meilenstein-Termine werden in der Projektplanung ermittelt
616
6 Projektkontrolle
Ziel:
Prognostizierung Termine
Erhöhung Planungssicherheit: Erkennen Schätzfehler
Verfahren:
Status: Regelmäßige Erfassung geplanter Termine
Prognostizierung: Interpolation Änderungen
Propagierung: Änderung abhängiger Termine
Verifizierung: Berücksichtigung Streuung
Erkennbare Planungsfehler: Indikatoren
Unrealistische Schätzung:
-
(Super)lineare Verschiebungen
Starke Schwankungen
Späte Neuschätzung: Terminasymptoten
617
6 Projektkontrolle
Verfahren:
Regelmäßige Erfassung Status
Erfassung pro Meilenstein
Keine rückwirkende Änderungen
618
6 Projektkontrolle
Berichtszeitpunkte
200x
200x
200x
200x
200x
2
0
0
x
MeilensteinTermine
IV
III
II
I
2
0
0
x
IV
III
II
I
IV
III
II
I
IV
III
II
I
2
0
0
x
IV
III
II
I
2
0
0
x
2
0
0
x
Projekt: xxx
Projektleiter: xxx
619
6 Projektkontrolle
1
Berichtszeitpunkte
Meilenstein-Termine
Meilenstein-Termine
Berichtszeitpunkte
3
2
2 Erste Projektbesprechung
mit Terminkontrolle nach
einem Monat
Berichtszeitpunkte
Meilenstein-Termine
Meilenstein-Termine
Berichtszeitpunkte
1 Ausgangssituation
nach Planung
3 Zweite Projektbesprechung
zwei Monaten
4
4 Dritte Projektbesprechung
drei Monaten
620
6 Projektkontrolle
Erkennbare Fehler:
Unterschätzung M1: Wiederholte Verschiebung (Messfehler)
Überschätzung M2: Überhöhte Verschiebung (Planungsfehler)
Fehlende Schätzung M3: Späte Verschiebung (Planungsfehler)
621
6 Projektkontrolle
Basisplanung
Die Basisplanung (baseline) muss bereits an die zur Statusüberwachung
ausgewählte Technik angepasst sein
Detailgrad/Granularität der Planung
Gliederung entsprechend der zu überwachenden Aufgaben (WBS!)
Annahmen bei Planung müssen schriftlich festgehalten sein (für
Änderungen/Anpassungen)
Enthält geplanten Verlauf des Budgetverbrauchs und des erwarteten
Fertigstellungsgrads
Zeitliche Effekte (Lernkurve, Urlaub, ...) sind eingerechnet
622
6 Projektkontrolle
Ansätze zur Ermittlung der aktuellen Zahlen bzw.
Zukunftsschätzungen
Ist-Zahlen kommen aus Zeitaufschreibung aller Projektbeteiligter
In der Methode zur Bestimmung noch anfallender Aufwände unterscheiden sich
die Methoden:
Zeitorientierte Ansätze
-
ETC (Estimate to Complete) – geschätzter Restaufwand Zahlen der Mitarbeiter (von
Team/Projektleiter verifiziert)
Basiert auf geschätztem Fertigstellungsgrad
Ergebnisorientierte Ansätze
-
Status wird an zu erstellenden Ergebnissen gemessen
Jedes Ergebnis hat genau einen Status (offen, in Arbeit, fertig)
Anteilige Zurechnung von „Support-Tasks“
623
6 Projektkontrolle
Beispiel: Zeitaufschreibung
624
6 Projektkontrolle
Zeitorientierte Fortschrittskontrolle
Baseline enthält Budgets für alle (Teil-)Aufgaben, die einzelnen Mitarbeitern (oder
Gruppen von Mitarbeitern) zugewiesen sind
Basierend auf aktuellen IST Zahlen und Schätzung der Mitarbeiter bezüglich der
offenen Restaufwände (ETC) bzw. Grad der Fertigstellung (in %)
Verglichen werden geplante Kosten pro Aufgabe mit aktuellen Hochrechnungen
625
6 Projektkontrolle
Probleme bei der zeitorientierten Fortschrittskontrolle
Schätzungen der einzelnen Mitarbeiter bezüglich des aktuellen Stands und der
Restaufwände sind spekulativ und von Erfahrung und Zielen der Mitarbeiter
abhängig
Bewertung Einarbeitungsaufwand
Informationsstand über offene Probleme
Ähnliche Problematik wie bei Schätzungen generell
Probleme werden üblicherweise erst spät deutlich (tatsächlicher Gesamtaufwand
wird erst spät – wenn es nicht mehr anders geht – angepasst)
626
6 Projektkontrolle
Ergebnisorientierte Ansätze
Status wird an Ergebnissen festgehalten
Status eines Ergebnisses kann sein: offen, in Arbeit, fertig
Zurechnung des Budgets nur bei Erreichen eines Status
Unterschiedliche Ansätze werden verwendet:
50% bei Start einer Aufgabe, 50% bei Abschluss
100% bei Abschluss
Nach vorher definieren Anteilen (Beispiel: bei 10 zu erstellenden Modulen 10% je fertiges
Modul)
Vorgehensweise muss bereits in der Planungsphase definiert und verwendet
werden
627
6 Projektkontrolle
Vorteile
Sicherer Status (eher etwas pessimistisch)
Weniger Know-how der Mitarbeiter notwendig bei Einschätzung von
Restaufwänden
Nachteile
Nur geeignet bei kurzen Tasks (1-2 Perioden)
Keine automatische Einschätzung des Work-in-Process
¾
Gängigste und brauchbarste Technik, die aber entsprechende Erfahrung
bei der Definition der Aufgaben und der Einstellung der Messgrößen
voraussetzt
628
6 Projektkontrolle
Ziele von Metriken
Es gibt eine Vielzahl von möglichen Metriken zur Feststellung des aktuellen
Stands eines Projekts.
Hier werden einige vorgestellt sowie die Arbeit mit den ausgewählten Metriken
erläutert.
Metriken dienen zur Feststellung des Projektstands basierend auf Statistiken über
das Projekt.
Sie helfen zur Identifikation von möglichen Problembereichen, identifizieren aber
keine Probleme (und lösen sie auch nicht)
Wichtiger als welche Metriken ist
Überhaupt welche zu verwenden
Eine überschaubare Anzahl zu haben
Sie einheitlich und durchgängig zu verwenden
629
6 Projektkontrolle
Earned Value Analyse (EVA)
Gemessen wird der aktuelle Projektfortschritt im Vergleich zu dem baseline
Budget.
Integriert Kosten, Zeitplan und geleistete Arbeit
Auch bekannt als Budgeted Cost of Work Performed
Kann für Kosten in unterschiedlichen Einheiten (Personentage, Geld) verwendet
werden
630
6 Projektkontrolle
Kernkomponenten (Key Performance Indicators KPI)
Folgende Basiskennzahlen werden aus den tatsächlichen Aufwänden
sowie den geschätzten Restaufwänden errechnet:
BCWP – Budgeted Cost of Work Performed - earned value Tatsächliche
Ergebnisse bewertet zu geplanten Kosten
ACWP – Actual Cost of Work Performed – burned
Tatsächliche Ergebnisse bewertet zu tatsächlichen Kosten
BCWS – Budgeted Cost of Work Scheduled – scheduled
Bis zum Stichtag geplante Arbeit bewertet zu geplanten Kosten
BCAC – Budgeted Cost at Completion – baseline
Geplantes Gesamtbudget bei Fertigstellung
631
6 Projektkontrolle
Beispiel
Team A (2 Mitarbeiter):
10 Module a 10 PT
in 10 Wochen erstellen
Lineare Verteilung der Arbeit (1Modul/Woche)
Aktuelle Zahlen nach Ende der Woche 2:
2 Module wurden komplett geliefert
Tatsächlicher Aufwand ist 22 PT
Kennzahlen:
BCWP = 20 Tatsächliche Ergebnisse bewertet zu geplanten Kosten
ACWP = 22 Tatsächliche Ergebnisse bewertet zu tatsächlichen Kosten
BCWS = 20 Bis zum Stichtag geplante Arbeit bewertet zu geplanten Kosten
BCAC = 200 Geplantes Gesamtbudget bei Fertigstellung
632
6 Projektkontrolle
Abgeleitete Kennzahlen
Aus diesen Basiszahlen können eine Vielzahl von Kennzahlen abgeleitet werden.
Betrachtet werden sollen im weiteren Kennzahlen zu
Kostenabweichungen: BCWP – ACWP
Abweichungen im Zeitplan: BCWP – BCWS
Kosten- und Zeitplanabweichungen müssen stets gemeinsam betrachtet werden,
sonst sind falsche Interpretationen vorprogrammiert
633
6 Projektkontrolle
Beispiele für abgeleitete Kennzahlen
CV – Cost Variance - Kostenabweichungen :
BCWP – ACWP
SV – Schedule Variance - Abweichungen im Zeitplan :
BCWP – BCWS
CPI – Cost Performance Index:
BCWP/ACWP = CEI – Cost Efficiency Index
SPI – Schedule Performance Index:
BCWP/BCWS = SEI – Schedule Efficiency Index
ETC – Estimate to Complete:
(BCAC – BCWP)/CPI
EAC – Estimate at Completion:
ETC + ACWP
TCPI - To-Complete Productivity Index:
(BCAC - BCWP) / (BCAC - ACWP)
634
6 Projektkontrolle
BCWP – ACWP
BCWP – BCWS
(BCAC – BCWP)/CPI
ETC + ACWP
635
6 Projektkontrolle
Interpretation von Kennzahlen
Im folgenden werden neun mögliche Fälle des Vergleichs von CV und SV (Cost
und Schedule Varianzen ) betrachtet
Die aufgeführten Gründe und möglichen Lösungsansätze sind nur exemplarisch
und auf keinen Fall als Kochbuch zu verstehen (aber als gute Anhaltspunkte!)
Ähnliche Überlegungen können ebenfalls für die anderen aufgelisteten
Kennzahlen erarbeitet werden
636
6 Projektkontrolle
Negative CV / Positive SV
Mögliche Gründe
Zu großzügige Termine
Zu viele Mitarbeiter
Hoher Terminfokus zu Lasten der Kosten
Unnötige Überstunden
Mögliche Lösungen
Begrenzung der Überstunden
Abziehen von Mitarbeiter von dem Bereich
Verständnis für Kosten wecken
637
6 Projektkontrolle
Keine CV, Positive SV
Mögliche Gründe
Sieht sehr gut aus!
ABER: Je nach Abhängigkeiten könnte Leerlauf (und damit Kosten) der Mitarbeiter
entstehen (nächste Arbeitsergebnisse können u.U. nicht vorgezogen werden)
Mögliche Lösungen
Abhängigkeiten im Projektplan betrachten
Sicherstellen, dass die Aufgaben auch komplett abgeschlossen werden (keine 80% fertig
Lösungen)
Begrenzung der Überstunden
Ggf. Mitarbeiter zu anderen Aufgaben einteilen
638
6 Projektkontrolle
Positive CV, Positive SV
Mögliche Gründe
Exzellentes Team mit sehr viel Erfahrung oder sehr konservativer Projektmanager in der
Planungsphase
ABER:
-
Versteht das Team die Aufgaben wirklich?
Werden „Abkürzungen“ benutzt und komplizierte Teile nach hinten verschoben (z.B. unzureichende
Tests)
Mögliche Lösungen
Qualitätsreviews überprüfen (sind die Ergebnisse wirklich fertig und auch in der
notwendigen Qualität)
Überprüfen, ob (eigenmächtige) „Optimierung“ des Arbeitsplans durchgeführt wurde
(einfache Tasks zu Beginn)
Überprüfung, ob der Umfang der einzelnen Aufgaben klar ist und auch richtig verstanden
wird
639
6 Projektkontrolle
Negative CV / Keine SV
Mögliche Gründe
Unerfahrenes Team, falsch einkalkulierte Lernkurve
Übermäßiges Qualitätsbewusstsein
Hoher zeitlicher Einsatz der Mitarbeiter (zu Gunsten des Termins)
Zu großzügige Terminplanung, Team macht zusätzliche Arbeit („goldene Wasserhähne“)
Mögliche Lösungen
Ausbildung des Teams verbessern (Coaching etc.)
Zeitplanung überprüfen und ggf. anpassen
Überstunden begrenzen (Achtung auf Zeitplan!)
Verständnis für Qualitätsanforderungen wecken
640
6 Projektkontrolle
Keine CV, keine SV
Mögliche Gründe
Eigentlich Idealzustand, macht aber jeden Projektmanager nervös!
Mögliche Lösungen
Qualitätskontrollen überprüfen (nicht auf Kosten der Qualität arbeiten)
Überprüfen der Schätzungen (Kosten und Zeit), sind hier zu große Puffer eingebaut?
Zusätzliche Anreize für Team zur weiteren Verbesserung überlegen (continuous
improvement)
641
6 Projektkontrolle
Positive CV, keine SV
Mögliche Gründe
Exzellentes Team mit sehr viel Erfahrung oder sehr konservativer Projektmanager in der
Planungsphase (was die Kosten angeht)
Versteht das Team die Aufgaben wirklich? Werden „Abkürzungen“ benutzt und
komplizierte Teile nach hinten verschoben (z.B. unzureichende Tests)?
Hohe Belastung der Mitarbeiter durch andere Tätigkeiten?
Mögliche Lösungen
Qualität überprüfen
Zeitbelastung der Mitarbeiter durch andere Aufgaben betrachten
Ausgleich der Ressourcen mit anderen Team
642
6 Projektkontrolle
Negative CV / Negative SV
Mögliche Gründe
„Alles Sch...“ (Normalsituation!)
Passt der Umfang noch (scope creep)?
Zusammensetzung des Teams, Lernkurve richtig eingeschätzt?
...
Mögliche Lösungen
Teamzusammensetzung übeprüfen, ggf. Ausbildung
Scope Management überprüfen
Planung anpassen (aber bitte nicht ständig...)
Das gesamte Repertoire des Projektmanagers kann eingesetzt werden...
643
6 Projektkontrolle
Kein CV, Negative SV
Mögliche Gründe
Arbeiten die Projektmitarbeiter wie geplant an den Aufgaben?
Überlastung der Mitarbeiter durch andere Aufgaben
Mögliche Lösungen
Urlaub, sonst Abwesenheit der Mitarbeiter entsprechen eingeplant?
Berichten die Mitarbeiter ihre Zeiten korrekt?
644
6 Projektkontrolle
Positive CV, Negative SV
Mögliche Gründe
Erfahrenes Team
Fehlende Mitarbeiter im Team
Planung ging von zu vielen verfügbaren Arbeitstagen aus
Arbeiten die Projektmitarbeiter wie geplant an den Aufgaben?
Mögliche Lösungen
Zu erfahrene Ressourcen anders einsetzen
Zusätzliche Ressourcen einsetzen (wenn dies Sinn macht!)
Verfügbarkeit der Mitarbeiter realistischer planen
645
6 Projektkontrolle
BCWP – ACWP
BCWP – BCWS
(BCAC – BCWP)/CPI
ETC + ACWP
646
6 Projektkontrolle
Beispiel
Wir betrachten eine Aktivität, die (der Einfachheit halber) 12 Monate vom 1.1. bis
zum 31.12. dauern und 120.000 € kosten soll, wobei nur Personalkosten
anfallen. Unser Berichtszeitpunkt ist der 30.6. Laut Kostenplan sollen sich die
Kosten linear über die Dauer verteilen. Der PV zum 30.6. beträgt also 60.000 €.
Für die Aktivität wurde aber mehr Personalaufwand investiert als geplant,
nämlich im Wert von 80.000 €.
(= AC). Der Arbeitsfortschritt ist jedoch nicht bei 50 % wie geplant, sondern erst
bei 33 % auf dem Stand von Ende April, da sich unerwartete Probleme ergeben
hatten. Der EV beträgt also 0,33 x 120.000 € = 40.000 €. CV ist dann 40.000 € 80.000 € = -40.000 €. Die geleistete Arbeit hat also 40.000 C mehr gekostet als
geplant. SV beträgt 40.000 € - 60.000 € = -20.000 €., d.h., wir liegen mit
unserem Arbeitsfortschritt mit Arbeit im Wert von 20.000 € zurück.
647
6 Projektkontrolle
Beispiel zum Cost Performance Index
648
6 Projektkontrolle
Beispiel zum Schedule Performance Index
649
6 Projektkontrolle
CPI und SPI grafisch dargestellt am Beispiel eines gut
gemanagten Projekts
650
6 Projektkontrolle
CPI und SPI lassen sich wie folgt interpretieren:
CPI > 1: Wir haben weniger Kosten gehabt, um die Leistung zu erbringen.
CPI = 1: Wir sind genau im Kostenplan.
CPI < 1: Wir haben mehr Kosten gehabt, um die Leistung zu erbringen.
SPI > 1: Wir sind dem Zeitplan voraus.
SPI = 1: Wir sind genau im Zeitplan.
SPI < 1: Wir liegen hinter dem Zeitplan.
651
6 Projektkontrolle
Mögliche Ursachen für ungünstige CPI- und SPI-Werte sind:
CPI > 1:
Der Personalaufwand war geringer als geplant, es wurde effizienter gearbeitet.
Eventuell wurden zu viele Puffer eingebaut.
CPI < 1:
Der Personalaufwand war höher als geplant, es wurde aber wenig effizient gearbeitet (eventuell waren die
Mitarbeiter unerfahren oder nicht dafür ausgebildet)
Es gab unerwartete technische Probleme (insbesondere wenn auch SPI < 1)
SPI > 1:
Die Aufgabe war einfacher als gedacht.
Eventuell durch überhöhten Personaleinsatz erkauft (wenn CPI < 1)
Eventuell wurden zu viele Puffer eingebaut.
SPI < 1:
Eventuell zu geringer Personaleinsatz (insbesondere wenn CPI > 1)
Es gab unerwartete technische Probleme (insbesondere wenn auch CPI < 1)
652
6 Projektkontrolle
Fallbeispiel: Gängige mögliche Kombinationen von CPI- und SPI-Werten und
ihre Interpretationen
PV
AC
EV
CPI
SPI
Interpretation
800
800
800
1,00
1,00
Optimaler Fall
800
600
400
0,67
0,50
Zu teuer und noch weiter hinter Zeitplan; einer der schlimmsten Fälle
800
400
600
1,50
0,75
Zwar kostengünstig, aber hinter Zeitplan; Warum wurden die Kosten so
überschätzt?
800
600
600
1,00
0,75
Kosten o.k., aber hinter Zeitplan
800
800
1000
1,25
1,25
Kostengünstiger und vor Zeitplan; Überoptimaler Fall
800
1000
1000
1,00
1,25
Genau im Kostenplan und vor Zeitplan; Überoptimaler Fall
800
600
800
1,33
1,00
Kostengünstiger und genau im Zeitplan; Überoptimaler Fall
800
1000
800
0,80
1,00
Zu teuer, aber im Zeitplan
800
600
1000
1,67
1,25
Erfreulich; Wurden zu viele Puffer eingebaut?
800
1200
1000
0,83
1,25
Zu teuer, aber vor Zeitplan
653
6 Projektkontrolle
Der Bestandsaufnahme und der Analyse der Zahlen folgen
weitere Schritte
Ergebnis der Bestandsaufnahme:
Problembereiche sind eingegrenzt, Hypothesen für die Problemlösung existieren
bereits.
Die genauen Probleme in den Problembereichen sowie die Ursachen dafür
müssen erkannt werden.
Die Einschätzung der Mitarbeiter zu dem aktuellen Stand und den Statuszahlen
ist sehr wichtig (teilen die Mitarbeiter die Bedenken, sehen sie die Situation
aufgrund zusätzlicher Information anders?).
Gegenmaßnahmen müssen definiert, ggf. mit dem Auftraggeber bzw. dem
Vorgesetzten (Programm–Projekt–Team) abgestimmt und umgesetzt werden
654
6 Projektkontrolle
Untere Management interessiert sich
meistens für:
Kostensituation
Entwicklungskosten, z.B. aus der EVA
(CPI, EAC, …)
Bei Großserien im Bereich Embedded
Systems: Prognose der Stückkosten
verglichen mit den geplanten Kosten
Terminsituation
Voraussichtlicher Endtermin, SPI (aus
der EVA)
Termintrends aus der MTA
Leistungsumfang
Wird die geforderte Funktionalität
geliefert oder gibt es Abweichungen?
Qualitätssituation
Wie ist die Produktqualität? (Z.B. wie viele
Fehler der verschiedenen Schweregrade gibt
es?)
Gibt es direkt kundenrelevante Probleme?
Personalstatus
Gibt es kritische personelle Engpässe in
Projekten?
Risiken
Zusammenfassung der Risiken, z.B. Top 5
oder Top 10
Risiken und Chancen, bei komplexen
Großserienprodukten im Bereich Embedded
Systems meistens monetär bezogen auf die
Stückkosten:
- Welche Risiken gibt es für
Kostensteigerungen, welche Chancen
für Kostenminderungen?
- Welche voraussichtlichen Stückkosten
ergeben sich unter der
Berücksichtigung von
Wahrscheinlichkeiten für Risiken und
Chancen?
Ausgewählte technische Probleme, soweit sie für die
Kosten, Termine und Funktionsumfang relevant sind
655
6 Projektkontrolle
Mittlere Management hat
eine deutlich größere Anzahl von Projekten zu überschauen und
erhält meistens stark zusammengefasste „Ampelberichte“
656
6 Projektkontrolle
Topmanagement
bei dem eine große Zahl von Projekten zusammenlaufen,
benötigt noch stärkere Zusammenfassungen:
Gibt es massive Probleme?
Verbessert oder verschlechtert sich die Situation?
Sind Maßnahmen eingeleitet?
Gibt es Handlungsbedarf für den Berichtsempfänger?
657
6 Projektkontrolle
Lessons Learned
Alle Abweichungen müssen betrachtet werden, nicht nur negative!
Positive Abweichungen vom Plan können nur temporär sein und im Projektverlauf
negative Auswirkungen haben.
Abweichungen sind normal, Bandbreiten müssen aber dem Stand im Projekt
entsprechen.
Positive Nachrichten zu Beginn eines Projekt sind verdächtig und verdecken oft
grundlegende Probleme
658
6 Projektkontrolle
Zusammenfassung
Überwachung von Zeit und Budget ist eine Aufgabe des Projektcontrollings.
Vorgehensweise und Methoden/Tools müssen bereits in der Projektplanung
definiert werden und bei der Projektplanung entsprechend berücksichtigt werden.
Metriken sind eine Methode, Bereiche für Schwachstellen in Projekten zu
erkennen, Detailanalyse muss folgen.
Es gibt eine Vielzahl von Metriken, Beschränkung auf eine wenige aber
aussagekräftige ist wichtig.
Projektfortschrittskontrolle geschieht nicht nur am Schreibtisch – mit den
Mitarbeitern reden!
659
Projektmanagment
1.
Einleitung
2.
Faktor Mensch
3.
Interviewtechniken
Zeitmanagement
Projektinitiierung
660
Projektmanagment
Schätzverfahren
Projektplanung
Einleitung
Projektfunktionen
Aufgabenträger
661
Projektmanagment
6.
Projektkontrolle
7.
Change-Management
Kostenkontrolle
Prozessverbesserung
Projektabschluss
662
Kapitel 7:
Prozessverbesserung
Projektabschluss
663
7 Projektabschluss und Prozessverbesserung
Warum Phase „Projektabschlusses“
Aus Definition von „Projekt“ ableitbar
Endliche Dauer (also muss ein Ende von vorne herein geplant sein)
Dedizierte Ressourcen (werden auch wieder für andere Aufgaben benötigt)
Neuartig – Tagesbetrieb wird außerhalb des Projekts abgewickelt
Ist dedizierter Projektschritt (passiert nicht einfach).
Definierte Aufgaben eines Projekt sind durchzuführen (entscheidet auch über
Erfolg/Misserfolg).
Muss daher frühzeitig geplant und explizit durchgeführt werden.
664
Bedeutung für Projektmanager
Letzte Möglichkeit, die Ergebnisse, die das Projekt erbringen soll, direkt zu
beeinflussen
Eindruck des Sponsors und der Anwender positiv beeinflussen
Offene Punkte/Probleme/Issues abschließen
Richtung für langfristigen Erfolg vorgeben
Leistung des Projekts kritisch bewerten
Methoden, Tools, Vorgehensweisen
Entscheidungen, eigenes Verhalten
Erfolgreiche Übergabe an die zuständige Organisation zur Betreuung
665
Aufgaben:
Formaler Projektabschluss
Auswertung Projekthistorie
Erstellung Projektabschlussbericht
Ziel:
Gesamtbeurteilung Projekt
Bewertung Projektergebnis (Ist/Soll-Vergleich)
Dokumentation von Erfahrungen
Identifikation von Problemen und Defiziten
Vorbereitung Prozessverbesserung
666
Kapitel 7:
Prozessverbesserung – Reifegradmodelle
Projektabschluss
667
7.1 Prozessverbesserung
Beobachtung: Qualitätsverbesserung führt zu
Reduktion der Entwicklungszeit
Reduktion der Entwicklungskosten
Steigerung der Wettbewerbsfähigkeit
Ansatz:
Verbesserung Entwicklungsqualität
Verbesserung Entwicklungsprozess
Definition (Software-)Entwicklungsprozess
(Software-)lebenszyklusabhängiger Anteil (Analyse, Entwurf, Realisierung)
Lebenszyklusunabhäniger Anteil (Planung, Kontrolle, Qualitätssicherung,
Konfigurationsmangement)
Organisationspezifische Anteil (Prozessdefinition,-bewertung, - verbesserung,
Ausbildung)
668
Strukturierte Verbesserungsansätze
Ziele:
¾
Bereitstellung systematisches Vorgehen
Richtlinen für Prozesserfassung
Metriken für Prozessbewertung
Maßnahmen zur Prozessverbesserung
Enthalten „Best Practices“
Beispiele:
EFQM (European Foundation of Quality Management): abstrakter, ganzheitlicher Ansatz,
fragebogenbasiert
CMM (Capability Maturity Model): Reifegradbasiert, assessmentorientiert – Entwicklung
eingestellt
BOOTSTRAP: ähnlich CMM, detaillierter, flexibler
SPICE (Software Process Improvement and Capability Determination): ähnlich CMM,
ISO-basiert, integriert ISO 9000, detallierter, umfassender
669

Reifegradmodelle (engl: maturity models)
enthalten »Best Practices«,
»Best Practices« über Jahrzehnte hinweg in vielen Projekten als erfolgreich erwiesen haben
und
deren Implementierung erfahrungsgemäß zu Verbesserungen hinsichtlich z.B.
Qualität,
Termin- und
Budgeteinhaltung führen.
Unternehmen adaptieren Praktiken, um somit besser und erfolgreicher Software zu entwickeln
und dabei schrittweise verschiedene Reifegradstufen zu erreichen.

Gruppieren Praktiken nach ihrer Zusammengehörigkeit. Je nach Modell werden
diese Gruppen als
«Prozesse«,
»Prozessbereiche«, oder auch
»Schlüsselprozessbereiche«
bezeichnet.
670
Die meisten Reifegradmodelle definieren Kategorien von Prozessen
organisatorische Prozesse,
unterstützende Prozesse,
Engineering-Prozesse etc.
Reifegradmodelle stellen
keine Prozessbeschreibungen dar
Aber: Grundlage zur Entwicklung von Prozessbeschreibungen
¾ Anpassung und Detaillierung an betriebliche Erfordernisse
Reifegradstufen (engl.: capability levels)
werden verwendet, um verschiedene evolutionäre Stadien in der allmählichen
Verbesserung der Prozesse zu beschreiben.
sind jeweils Gruppen von Praktiken zugeordnet, die aufeinander aufbauen.
¾ können als Orientierungshilfe für die Prioritäten bei der Prozessverbesserung
verwendet werden.
671
Assessments (ähnlich einem mehrtägigen Audit)
Bestimmung des Entwicklungsstandes in einem Projekt oder Unternehmen
Vergleich der betrieblichen Abläufe mit den Anforderungen des Reifegradmodells
Ergebnis ist u.a.
eine Reifegradaussage (je nach Reifegradmodell für die einzelnen Prozesse oder für die
untersuchte Organisation) sowie
Stärken und Schwächen in den einzelnen Prozessen.
¾ konkrete Verbesserungsmaßnahmen werden definiert.
¾ Reifegrade können also auch dem Nachweis der Güte der (Entwicklungs)Prozesse dienen und werden zunehmend von Unternehmen bei der
Lieferantenbeurteilung eingesetzt.
672
Capability Maturity Model (CMM)
Einführung:
Definition: SEI, 1991 (Version 1)
Zielgruppe: NASA
Überarbeitung: 1997 (Version 2)
Ziel:
Erhöhung der Qualität und Produktivität
Reduktion des Risikos
Verfahren: Stufenorientiert
5 Stufen zur Einordnung der aktuellen Prozessreife („maturity“)
Feststellung der Einordnung mittels fragebogenbasierten Assessments
Strukturierte Handlungsempfehlungen entsprechend Prozessreife
673
CMM
Schlüsselbereiche
(Key process areas):
Gebündelt zu Reifegraden
Definierten 18 Hauptkriterien für
Reifedefinition
Untergliedert in Unterverfahren (key
practices)
Definieren, was in einem
Schlüsselbereich zu tun ist
Definieren nicht, wie es zu tun ist
674
Schlüsselprozessbereiche (Key Process Areas, KPAs)
umfassen die einzelnen Praktiken und sind den Stufen fest zugeordnet.
Um z.B.
Stufe 2 zu erreichen, müssen deren Schlüsselprozessbereiche implementiert sein,
bei Stufe 3 diejenigen von Stufe 2 und 3 usw.
Über die Stufen wird ein Weg der Prozessverbesserung definiert, der auf
langjähriger Erfahrung in einer Vielzahl von Projekten basiert erwiesen oder
widerlegt.
675
Architektur von CMM
Stufe (Level)
Fokus
Schlüsselprozessbereich
Optimierend (5)
Kontinuierliche
Prozessverbesserungen
Fehlerverhütung
Technologie-Änderungsmanagement
Prozess-Änderungsmanagement
Geleitet (4)
Produkt- und Prozessqualität
Quantitatives Prozessmanagement
Software-Qualitätsmanagement
Definierter ingenieurmäßiger
Prozess
Organisationsweiter Prozessfokus
Organisationsweite Prozessdefinition
Trainingsprogramm
Integriertes Softwaremanagement
Software-Produktentwicklung
Koordination zwischen Gruppen
Partner-Reviews
Wiederholbar (2)
Projektmanagement und
Verpflichtungsprozess
Anforderungsmanagement
Software-Projektplanung
Software-Projektsteuerung und –verfolgung
Software-Unterauftragnehmermanagement
Software-Qualitätssicherung
Software-Konfigurationsmanagement
Initial (1)
„Helden“
Definiert (3)
676
Die Reifegradstufen bauen aufeinander auf und haben folgende
Bedeutung:
Stufe l: Prozesse sind nicht definiert oder werden nicht befolgt. Projekterfolge sind durchaus
möglich, basieren dann aber auf Individualleistungen der so genannten »Helden«.
Stufe 2: Die Schlüsselprozessbereiche dieser Stufe sind in allen Projekten implementiert,
wobei deren Implementierungen von Projekt zu Projekt unterschiedlich sein können. Die
Prozesse sind im jeweiligen Projekt definiert, werden gelebt und auch unter Stress beibehalten.
Stufe 3: Zusätzlich zu den neu hinzukommenden Prozessbereichen sind nun die Prozesse
organisationsweit standardisiert und werden für ein neues Projekt zurechtgeschnitten (mittels
»Tailoring Guide-lines«). Die Erfahrungen bei der Nutzung fließen zurück in die
Prozessdefinitionen.
Stufe 4: Die Prozesse werden nun mit statistischen Methoden überwacht und gesteuert.
Stufe 5: Die Prozesse werden ständig systematisch verbessert. Verbesserungsideen werden
systematisch erprobt und ihr Erfolg quantitativ
677
CMM: Stufe 1 und 2
678
CMM: Stufe 3
679
CMM: Stufe 4 und 5
680
CMM Verteilung
681
CMM-Verbreitung
682
CMM und Unternehmensgröße
683
CMM Verbesserungsaufwand
684
CMM: Assessmentfragebögen
Beispiel: Schlüsselbereich Qualitätssicherung
Sind QS-Maßnahmen geplant?
Stellt die QS objektiv sichern dass die Softwareprodukte und Aktivitäten den festgelegten
Standards, Verfahren und Anforderungen entsprechen
Werden die Ergebnisse der QS-Überprüfungen (reviews, audits) den betroffenen
Gruppen und Personen zur Verfügung gestellt (d.h., denjenigen, die die Arbeit ausführen
und denjenigen, die für die Arbeit verantwortlich sind)?
Werden Abweichungen, die nicht innerhalb des Projekts gelöst werden, an das höhere
Management berichtet (z.B. Abweichungen von festgelegten Standards)?
Folgt das Projekt einer schriftlichen QS-Politik?
685
Produktionsgüte
Zuverlässigkeit des ausgelieferten Systems
Abhängig von „built-in“ Qualität/prozessbegleitendes Qualitätsmanagement
Güte der Fehleridentifikation- und behebung in Integration und Test
686
Fehlerbehebungsgüte
Effizienz der Fehlerbehebung
Maß: Anteil behobener/identifizierter Fehler
Abhängig von Prozessgüte
687
SPICE
SPICE (Software Process Improvement and Capability Determination): ISO/IEC
15504 – Stand Oktober 2003
Ziele:
Assessmentmodelle und -verfahren in eine definierte Beziehung zu setzen
Integration existierender Ansätze, z.B.:
-
CMM
ISO 9000
Verfahren:
Bewertung Entwicklungsprozess mittels Assessments
Unterteilung in Prozess- und Reifegraddimension
Unabhängige Bewertung Prozessdimensionen
Identifikation von Verbesserungsmöglichkeiten
688
Dimensionen
Prozessdimension:
Umfang: 5 Kategorien, 29 Prozesse, 200 Aktivitäten
Kategorien:
-
Kunde-Zulieferer-Prozess
Entwicklungsprozess (Lebenszyklusaktivitäten)
Unterstützende Prozesse (u.a. KM,QS)
Managementprozess (u.a. PM, QM)
Organisationsprozess (u.a. Zieldefinition, Prozessverbesserung)
Reifegraddimension:
Umfang: 6 Stufen, 9 Attribute
Definiert für jede Prozess
Beispiel: Prozessdurchführung, Reifegradstufe 1:
Aktivität: Ausführung von Aktivitäten sicherstellen
Charakteristika: (z.B.)
-
Muster für Ein- und Ausgabeprodukte existieren
Es gibt Verteilungsmechanismus für Arbeitsprodukte
689
Reifegradstufen SPICE und CMM im Vergleich
CMM
SPICE
5
„Optimizing“
„Optimizing“
5
4
„Managed“
„Predictable“
4
3
„Defined“
„Established“
3
2
„Repeatable“
„Managed“
2
„Performed“
1
„Incomplete“
0
1
„Initial“
690
SPICE: Reifegrade
691
SPICE-Prozessmodell
PRIMARY LIFE CYCLE PROCESSES
CUS.1
Acqusition
CUS.1.1
Acqusition Preparation
CUS.1.2
Supplier selection
CUS.1.3
SUPPORTING LIFE CYCLE
PROCESSES
ENG.1
Development
SUP.1
Documentation
System requirements analysis and design
SUP.2
Configuration
Management
ENG.1.2
Software requirements analysis
SUP.3
Quality Assurance
Supplier monitoring
ENG.1.3
Software design
SUP.4
Verification
CUS.1.4
Customer acceptance
ENG.1.4
Software construction
SUP.5
Validation
CUS.2
Supply
ENG.1.5
Software integration
SUP.6
Joint Review
CUS.3
Requirements elecitation
ENG.1.6
Software testing
SUP.7
Audit
CUS.4
Operation
ENG.1.7
System integration and testing
SUP.8
Problem Resolution
CUS.4.1
Operational use
ENG.2
System and software maintenance
CUS.4.2
Customer support
ENG.1.1
692
Das SPICE-Prozessmodell
ORGANISATIONAL LIFE CYCLE PROCESSES
MAN.1
Management
ORG.1
Organisational alignment
ORG.3
Human Resource
Management
MAN.2
Project Management
ORG.2
Improvement process
ORG.4
Infrastructure
MAN.3
Qualitity Management
ORG.2.1
Process establishment
ORG.5
Measurement
MAN.4
Risk Management
ORG.2.2
Process assessment
ORG.6
Reuse
ORG.2.3
Process improvement
693
CMMI
Neben dem ursprünglichen Software CMM ist eine Reihe weiterer
Reifegradmodelle für andere Anwendungsgebiete entstanden
wie z.B. People CMM, Software Acquisition CMM etc.
CMMI auch die Integration (daher das »I« im Namen)
Kompatibilität zu ISO 15504
¾ allgemeinere Entwicklungsprozesse (insbesondere Systems Engineering)
Entwickelt von Team aus Industrie, US-Regierung und SEI entwickelt.
V0.2 im Jahr 1998
VI.l Ende 2001
erwartete Lebensdauer von vier bis fünf Jahren hat [CMMI 03].
694
CMMI
CMMI - »Product Suite«, bestehend aus
verschiedenen Modellen,
Assessmentmethoden und
Trainingsprodukten.
Die Modelle liegen als »Model Framework« mit zwei Dimensionen vor:
1. Dimension: Disziplin
-
Software Engineering
Systems Engineering
Integrated Product and Process Development (IPPD)
Supplier Sourcing (SS)
2. Dimension: Repräsentationsform
-
Staged Representation - wie das Software CMM aufgebaut
Continuous Representation - analog zur ISO 15504 strukturiert
Die in einem Assessment zu untersuchenden Prozesse können wie bei SPICE beliebig gewählt
werden (d.h. unabhängig von Reifegradstufen) und für jeden Prozess kann unabhängig von
anderen ein individueller Reifegrad ermittelt werden.
695
CMMI-Prozessmodell
STAGED REPRESANTATION
CONTINUOUS REPRESENTATION
LEVEL 2: MANAGED
PROJECT MANAGEMENT
Requirements management
Project planning
Project planning
Project monitoring and control
Project monitoring and control
Supplier aggreement management
Supplier aggreement management
Integrated project management
Measurement and anlalysis
Risk management
Process and product quality assurance
Qualitative project management
Configuration management
ENGINEERING
LEVEL 3: DEFINED
Requirement management
Requirement development
Requirement development
Technical solution
Technical solution
Product integration
Product integration
Verification
Verification
Validation
Validation
696
CMMI-Prozessmodell
STAGED REPRESANTATION
CONTINUOUS REPRESENTATION
Organisational process focus
SUPPORT
Organisational process definition
Configuration management
Organisational training
Process and product quality assurance
Integrated project management
Measurement and analysis
Rist management
Decision analysis and resolution
Decision analysis and resolution
Causal analysis and resolution
LEVEL 4: QUANTITATIVELY MANAGED
PROCESS MANAGEMENT
Organisational process performance
Organisational process focus
Quanititative project management
Organisational process definition
LEVEL 5: OPTIMIZING
Organisational training
Organisational innovation and deployment
Organisational process performance
Causal analysis and resolution
Organisational innovation and deployment
697
Reifegradmodelle sind Modelle zur
Messung,
Bewertung und
Verbesserung des SW-Entwicklungsprozesses.
Diese beinhalten
Best Practices, gegen die die realen Prozesse verglichen werden.
Anhand der Ergebnisse des Vergleichs werden neben Reifegradstufen auch Stärken und
Verbesserungspotenziale identifiziert und konkrete Empfehlungen gegeben.
Die am weitesten verbreiteten Modelle sind
das stufenorientierte Capability Maturity Model (CMM),
das kontinuierliche Modell ISO 15504 (genannt SPICE)
sowie das Capability Maturity Model Integration (CMMI), das beide Repräsentationen
ermöglicht.
Alle Modelle enthalten Projektmanagementprozesse sowie eine Verknüpfung von
Projektmanagementpraktiken mit den Reifegradstufen.
698
Prozessverbesserung: Nebenwirkungen
Strukturierte Prozessbesserungsansätze:
Ziele:
-
Messung/Steigerung Prozessproduktivität/Qualität
Messung/Reduktion Risiken
Ansatz: Standardisierung Entwicklungsprozess
Nebenwirkung:
Zusätzlicher Aufwand für Prozessverbesserung
Prozessoptimierung nur für traditionelle/Standardprobleme
Neue Domänen verursachen:
-
Neue Entwicklungsmethoden (Stufe 1)
Neue Qualitätssicherungsverfahren (Stufe 2)
Neue Prozessdefinitionen (Stufe 3)
Neue Prozesskennzahlen (Stufe 4)
Beispiel:
-
Wechsel von Controlling-Systeme zu Billing-Systeme
Wechsel von Automatisierungstechnik zu Automobiltechnik
699
Prozessverbesserung: Risiken
Risiko: Verselbstständigte Prozessverbesserung
Prozessbewertung wichtiger als Prozessverbesserung
-
„Ranking“ als Ziel der Prozessbesserung
Übertriebenes Sicherheitsdenken:
-
Fokussierung auf stabilen Entwicklungsprozess
Auswirkung:
Vermeidung risikoreicher Innovationen
Übernahme neuer Anwendungs-/Geschäftsfelder
700
Kapitel 7:
Prozessverbesserung
Projektabschluss
701
7.2 Projektabschluss
Projektabschluss
Formaler Projektabschluss: Definierte Beendigung eines Projekts
Erreichen des Projektziels
Abbruch eines Projekts
Prozessabschluss hat unterschiedliche Dimensionen:
Produktdimension:
-
Sicherung der Produkte und Ergebnisse
Vorbereitung Softwarepflege und Änderung
Vorbereitung der Wiederverwendung/Verbreitung der Ergebnisse
Projektdimension:
-
Freigeben von Ressourcen und Personal
Rechenschaftsberichte erstellen
Projekt auflösen
702
Formale Abnahme durch Auftraggeber
Abnahme ist Hauptpflicht des Auftraggebers
Abnahmekriterien und Vorgehensweise für die Abnahme sind bereits zu Beginn
des Projekts definiert worden (wenn nicht, wird‘s jetzt schwierig...)
Abnahme ist Basis für die Übergabe an die übernehmende
Organisation/Abteilung
Hat ggf. auch rechtliche Auswirkungen (bei Zusammenarbeit mit externen
Partnern)
Achtung: Abnahme erfolgt i.d.R. vor einer endgültigen Bestätigung des Business
Cases (mit allen Konsequenzen)
703
Inhalt und grobe Vorgehensweise
Begriff der Abnahme
Erklärung vs. Verfahren
zweigliedriger Abnahmebegriff: körperliche Entgegennahme und Billigung der Leistung
2 mögliche Vorgehensweisen
Projektbegleitende Abnahme (dringend empfohlen)
„Big bang“ (manchmal nicht anders machbar)
Verfahren und Detailvorgehensweise muss vor der Abnahme bekannt sein (auch
Testdaten etc.)
704
Abnahmekriterien
Für die Abnahme wird die Übereinstimmung mit den sog. Annahmekriterien
geprüft
Einhaltung von Planungs- und Managementprozessen
Definition der Verifikationsmethoden
Definition der Zeitdauer der Abnahme
Vereinbarung von Fehlerklassen
Zeitdauer für die Behebung von Problemen
¾
Wichtig:
Allen Beteiligten muss klar sein, was Abnahme heißt und was die Regeln
sind!
705
Abnahmephasen
Abnahmephasen:
Überprüfung und Vollständigkeitskontrolle des vom Auftragnehmer gelieferten
Programms einschl. Dokumentation
Installation und anschl. Test in Testumgebung
Performancetests auf Basis vereinbarter Mengenprofile
Test des störungsfreien Wiederanlaufs nach Abbruch oder Stromausfall
Auftraggeber trägt:
Verantwortung für Aufbau und Betrieb Testumgebung
Verantwortung für Testfälle und -daten
706
Rechtliche Auswirkungen
Vermutung der vollständigen Lieferung
Mangelausschluss (§ 640 II BGB)
Untersuchungs- und Rügepflichten (§ 377, 381 II HGB)
Mängelbeseitigungs- statt Erfüllungsanspruch
Beweislastumkehr
Gefahrenübergang
Nutzungsrechtseinräumung
Verschuldensunabhängiger Zinsanspruch (§ 641 II BGB)
Fälligkeit des Vergütungsanspruchs (§ 641 BGB)
Verjährungsbeginn (§ 638 BGB)
707
Somit
Hauptproblem bei der Abnahme ist i.d.R. kein rechtliches sondern ein
psychologisches beim Auftraggeber
Formaler Teil muss sein, aber dabei partnerschaftliches Verhältnis zwischen
Projekt und Auftraggeber beachten
Gutes Änderungsmanagement zahlt sich (spätestens) hier aus
Kriterien und Verfahren möglichst früh klären und festlegen (Abnahmephase ist
Stress...)
Bestmögliche Betreuung der zur Abnahme berechtigten Mitarbeiter des
Auftraggebers sicherstellen
Schnelle Reaktion auf auftretende Probleme
708
Projektabschlussdimensionen:
Personalorganisation:
Identifikation und Durchführung von Fortbildungsmaßnahmen
Teamgeist belohnen
Evtl. Fortführung der Teamstruktur
Organisationsdimension:
Identifikation von erfolgreichen Verfahren („Best Practices“)
Identifikation und Durchführung von
Verbesserungsmaßnahmen
-
Unternehmensstrukturen
Technologien
Prozessdefinitionen
709
Das war‘s!
Ich danke Ihnen für Ihre Aufmerksamkeit und wünsche Ihnen
eine schöne vorlesungsfreie Zeit,
viel Erfolg in der Klausur
und auf Wiedersehen im neuen Semester!
710

Projektmanagement - Institut für Informatik

Transcrição

Documentos relacionados

Senior Projektmanager - Promotion Software GmbH

Holger Gubbels SAP® ERP – Praxishandbuch Projektmanagement

Übung

Bewertung und Bilanzierung selbst erstellter Software

PmP, Projektmanagement Professional (PmI) PMP

Netzplantechnik Zeitplanung - fhdo

Contractor Safety Award 2016 Anmeldeformular