Upload
phamtruc
View
228
Download
0
Embed Size (px)
Citation preview
1
Programmierung verteilter Systeme LabInstitut für InformatikUniversität AugsburgUniversitätsstraße 14, 86159 AugsburgTel.: (+49) 821/598-2174, Fax: -2175URL: http://www.informatik.uni-augsburg.de/vs
ProjektmanagementProf. Dr. Bernhard Bauer
2
Organisatorisches
Bei weiteren Fragen:
Prof. Dr. Bernhard Bauer:Sprechstunde: Montag 13:00 – 15:00 Uhr Informatikgebäude, Zi. [email protected]
3
Ziele der Vorlesung
Die Hauptziele der Vorlesung
„Projektmanagement“
sind:Einblick in die Begriffe, Methoden und theoretischen Grundlagen des ProjektmanagementsKenntnis kritischer Erfolgsfaktoren für erfolgreiches Software-ProjektmanagementProjektcontrolling als wichtiger Aspekt für Einhaltung der ProjektzieleFaktor Mensch in Projekten berücksichtigen
4
Literatur
Manfred Burghardt: Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten, 5. Auflage, 2000, Publicis MCD VerlagDirk Börnecke: Basiswissen für Führungskräfte: Die Elemente erfolgreicher Organisation, Führung und Strategie, 2. Auflage 2001, Publicis MCD VerlagH. Balzert: Lehrbuch der Software-Technik, Band 1, Spektrum Akademischer Verlag, 2000I. Sommerville: Software Engineering. Pearson, 2001.T. DeMarco.: The Deadline: A Novel About Project Management. Dorset House Publishing, 1997U. Witschi, A. Erb, R. Biagini, Projekt-Management: Der BWILeitfadenzu Teamführung und Methodik. Verlag Industrielle Organisation Zürich, 1996T. DeMarco, T. Lister: Wien wartet auf Dich. Der Faktor Mensch im DV-Management.K. Tumuscheit: Überleben im Projekt. 10 Projektfallen und wie man sie umschifft. Orell Füssli, 1999.
5
Folien und Skripte
Bernhard Schätz: Vorlesung Projektorganisation und Management Leopold-Franzens Universität Innsbruck Sommersemester 2003Ralf Reichwald, Frank Mang Management Innovativer SoftwareprojekteWintersemester 2002/2003, TUM MünchenSiemens: Projektmanagement: ZuWAS Die Zukunft bestehen – Wirtschaft, Arbeitswelt, Schule, 2002
6
Kapitel 1:Einleitung
MotivationProjektSchwierigkeiten bei SW-ProjektenProjektmanagementPM – CrashkursSchlüsselfaktoren für den ProjekterfolgSummary
7
1.1 Motivation
Historische ProjekteBau der Chinesischen Mauer
7.300 km Länge zur AbgrenzungMehrere 100 Jahre BauzeitNeuartige Konstruktion und Bauelemente
Bau der Pyramiden147 m hoch, 2,3 Mio. Steinquader20 Jahre BauzeitCa 100.000 Teilzeitmitarbeiter
Turmbau zu BabelMächtige Stadt soll entstehenSpitze bis in den HimmelMisserfolg wegen Kommunikationsproblemen
8
1.1 Motivation
Private ProjekteUmzugsplanung
WohnungssucheTransportmittelHelfer organisierenKartons,...
Studienplanungwelche Vorlesungenwelche Scheinewelche SeminarePraktikaHiwi-Jobs,...
9
1.1 Motivation
Technische ProjekteFlughafenneubau 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 AuftraggeberTechnische Implementierung durch unterschiedliche „Auftragnehmer“Fraglicher Erfolg...
10
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
11
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 unzureichendemAnforderungsmanagement, 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.“
12
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 Collectstark 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.
13
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?
14
1.1 Motivation
Misserfolgsfaktoren
nur 16% der Projekte im Zeit- und Kostenplan
53% der Projekte kosten 189% der ursprünglichen Planung
31% der Projekte werden abgebrochen
Zum Vergleich: Stand 1995
28% der Projekte im Zeit- und Kostenplan
49% der Projekte sind über dem Kosten- und/oder Zeitplan
23% der Projekte werden abgebrochen
The Standish Group (Chaos-Report USA, 2001)
15
1.1 Motivation
etc.
4,3%Mangelndes Technologiewissen
6,2%Mangelndes IT-Management
7,5%Wird nicht mehr benötigt
8,1%Mangelnde Planung
8,7%
9,3%
9,9%
10,6%
12,4%
13,1%
Sich häufig ändernde Anforderungen/Spezifikationen
Mangelnde Unterstützung vom Management
Unrealistische Erwartungen
Ressourcenmangel
Mangelnde Einbeziehung der Beteiligten
Unvollständige/ungenaue Anforderungen
Misserfolgsfaktoren (Chaos-Report USA, 1995)
16
1.1 Motivation
etc.
Verteilte Entwicklung beherrschen: Unternehmensauftragnehmer,standortübergreifende Entwicklung, Globalisierung, etc.)
Kommunikationsprobleme meistern (Einbeziehung der Stakeholder)
Funktionierendes Qualitätsmanagement
Qualifikation der Mitarbeiter
Verfügbarkeit von Ressourcen
Definierte Entwicklungsprozesse, die auch angewendet werden
Hoher Stellenwert von Projektleitung im Unternehmen
Für Projektabwicklung geeignete Unternehmensorganisation
Erfolgsfaktoren für Projekte
19
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.
Zielvorgabezeitliche, finanzielle, personelle und andere BegrenzungenAbgrenzung gegenüber anderen Vorhabenprojektspezifische Organisation.
( DIN 69 901)
20
1.2 ProjektMerkmale eines Projekts
Vorgegebenes Ziel
Begrenzte Ressourcen
Definierter Endtermin
Einmalig
Komplex
Risikoreich
Dynamisch
Interdisziplinär
Projekt
ProduktProjekt
HW-Produkte SW-Produkte
21
1.2 ProjektKomponenten eines Projekts
AufbauorganisationProjektfunktionenProjektorganisation
Ablauforganisation / Meilenstein und Phasen
PhasenorganisationMeilenstein-Trendanalyse
ProjektzielsetzungProjektzieleRequirements
ProjektplanungStrukturplanungAufwandsschätzungAblaufplanungTerminplanung
Projektsteuerung und -überwachungBerichtswesenSteuerungsmaßnahmen
Projekt-ziel
Ablauf-organisation
Projekt-steuerung
Projekt-planung
Aufbau-organisation
22
1.2 ProjektTypische Situation bei FuE- Projekten
Typische Situation bei FuE- Projekten sindZiel bei Projektbeginn nicht genau bekanntLösungsweg muss erarbeitet werdenHoher InnovationsgradHohe ÄnderungsintensitätTermindruckVorgegebene BearbeitungskapazitätZusammenarbeit verschiedener DisziplinenNotwendigkeit für kreativen Freiraum
FuE = Forschung und Entwicklung
23
1.2 ProjektAnforderungen an Projekte
Projekt
Komplexität beherrschen!
Anforderungen an das Ergebnis steigen!
Anforderungen an das Projekt steigen!
Komplexität- Größe- Integration
Neuartigkeit
Qualität
Termine
Ressourcen
Produktivität
Zahl der Beteiligten
24
1.3 Schwierigkeiten bei SW-Projekten
Das magische ViereckZeit: ProjektlaufzeitKosten: BudgetQualität: z.B. Funktionalität, Nutzbarkeit, WartbarkeitQuantität: Anzahl ausgelieferter Funktionen
25
1.3 Schwierigkeiten bei SW-Projekten
Komplexität des ProduktsFaktoren: Größe, Diversität, VernetzungFührt zu Komplexität des ProzessesSW oft komplexer als „klassische“ Ingenieurprodukte
26
1.3 Schwierigkeiten bei SW-Projekten
Kennzahlen des Systems R/3ERP (Enterprise Resource Planning)-Standardsoftware der SAP AG, WalldorfSAP ist der Weltmarktführer für diese Software
ca. 7.000.000 Zeilen Quellcodeca. 100.000 Funktionsaufrufeca. 20.000 unterschiedliche Funktionenca. 21.000 Reportsca. 17.000 Menüleistenca. 14.000 Funktionsbausteine
27
1.3 Schwierigkeiten bei SW-Projekten
Effizienz vs. Flexibilität:Effizienz: Einsatz bewährter Methoden zur Kostenreduktion:
StandardanwendungsdomäneStandardentwicklungsplattformStandardentwicklungsprozessStandardentwicklungsumgebung
Flexibilität: Das Unvorhersehbare planen:Änderung der Anforderungen durch den KundenÄnderung der Entwicklungsplattform durch das ManagementMitarbeiterfluktuationÄnderung des Ausliefertermins durch das ManagementVerzögerungen durch die Zulieferer
28
1.3 Schwierigkeiten bei SW-Projekten
Weitere Schwierigkeiten von SW-ProjektenImmaterialität des Produkts: Software ist unsichtbar und damit
Für den Kunden schwer erlebbar (Kostenbewußtsein)Bzgl. des Fertigungsgrades schwer messbarRisiko: Umfang, Kosten und Laufzeit
Innovativität des Produkts: Software ist i.a. „Null“-Serie und damitMit dem Einsatz neuster Technologie verbundenMit der Realisierung umfassender neuer Funktionen verbundenRisiko: Stabilität (Qualität) und Laufzeit
Mangelnde Prozessreife: SE ist eine junge Disziplin und damitFehlen standardisierte und etablierte EntwicklungsprozesseVerständnis für die ingenieurmäßige SE (Kunst vs. Handwerk)Risiko: Qualität und Laufzeit
29
1.3 Schwierigkeiten bei SW-Projekten
Darüber hinaus können Ursachen für Schwierigkeiten sein:
Verantwortlichkeiten, Informations- und Entscheidungswege sind nicht ausreichend geregeltProjektauftrag und somit Projektziel ist unklarAnforderungen werden am Projektbeginn nicht überprüftNeue (An)forderungen gefährden/verändern die geplanten ProjektzieleTermine werden vom Wunschdenken/Auftraggeberanforderungen diktiertKosten werden pauschal geplantZielabweichungen (Ergebnisse, Kosten, Termine) werden zu spät erkanntProbleme werden gelöst, wenn sie aufgetreten sind (Reaktion vs. Proaktivität)
30
1.4. ProjektmanagementZiele und Prinzipien
Ziele der ProjektabwicklungProjektziel erreichenRisiken einengenGeforderte Qualität erreichenDurchlaufzeit verkürzenWirtschaftliche AbwicklungLaufende TransparenzZuverlässige Aussagen
durch Projekt-management
31
1.4. ProjektmanagementZiele und Prinzipien
Die Prinzipien des Projektmanagements sind dabeiklare Zielsetzung
Auftraggeber, Teilaufgaben, realistisch, akzeptiertStrukturierung
Produkt, Prozess, Planung, Organisation, Top-Down, sinnvolle DetaillierungErgebnisorientierung
Meilensteine, Phasenorganisation, Projektfunktionenklare Verantwortlichkeiten
Organisation, Ergebnisse, Personifiziert, Know-how-Trägereindeutige Zustände
Organisation, Prozess, Planung, Entscheidung, Änderungen, InformationEinbeziehen der ProjektmitarbeiterInnen
Zielvereinbarungen, Motivation, Kommunikation, Kreativitätfrühzeitiges Handeln
Zieldefinition, Organisation, Planung, Risikoeinengung, Entscheidungen
32
1.4. ProjektmanagementProjektmanagement
Projektmanagement ?Projektmanagement ?
Projektleiter
Projektstrukturpläne
Matrixorganisation
PhasenorganisationMeilenstein-trendanalyse
Arbeitspakete
Netzplantechnik GanzheitlicheMethodik zur Erreichung des Projektziels
Task Force
33
1.4. ProjektmanagementSoftware-Entwicklungsprozess
Software-system
Anforderungen der Stakeholder
Ressourcen der
Infrastruktur
Projektziele
Implementierung
Test
Design
Anforderungs-analyse
Aktivität
34
1.4. ProjektmanagementStandort des Projektmanagements
Projektvorfeld Projektdurchführung
Projektideen
Systemnutzung
Projektstart Projektabschluss
Lebenszeit des Projekts
Lebenszeit des Systems
Projektmanagement
35
1.4. ProjektmanagementDefinitionen
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.
36
1.4. ProjektmanagementDefinitionen
Für die Abwicklung eines Projekts die Gesamtheit von
Führungsaufgaben ZielsetzungZieleinhaltungEntscheidung
ProjektorganisationProjektabwicklung
MotivationstechnikBesprechungstechnikPräsentationstechnikEntscheidungsfindungstechnikProdukt- und Projektstruktur-planungssystemeTermin-, Kapazitäts-, Kosten-, Planungs- und Steuerungssysteme
Führungsorganisation
Führungstechniken
Führungsmitteln
Definition Projektmanagement (DIN 69 901)
37
1.4. ProjektmanagementPM vs. ST
Abgrenzung zur Software-Technik:
Softwaretechnik: Ingenieurtechnik, FachdisziplinProjektmanagement: Nichtfachliche Abwicklung EntwicklungsprozessStarke Schnittstellen:
Vorgehensmodelle (Prozessmodelle)QualitätsmanagementKonfigurationsmanagement
38
1.4. ProjektmanagementDas "Magische Dreieck"
Das "Magische Dreieck"
Ziel
Aufwand TerminProduktivität
Rentabilität Effektivität
39
1.4. ProjektmanagementDas "Magische Viereck"
Und hier noch mal das magische ViereckZeit: ProjektlaufzeitKosten: BudgetQualität: z.B. Funktionalität, Nutzbarkeit, WartbarkeitQuantität: Anzahl ausgelieferter Funktionen
40
1.4. ProjektmanagementEinteilung der Projektziele
Managementziele Produktziele Prozessziele
Ziel erreichenErfolgreich seinImmer transparent seinVorsprung ausbauen
FunktionLeistungQualität
Termine AufwandAbwicklung
Projektziele
41
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.
42
Ä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.
1.5. Projektmanagement – Crashkurs Change Request (CR)
43
1.5. Projektmanagement – Crashkurs Change Request Prozedur
Antragsteller Entwicklung Change Control Board
Entwicklung
ChangeRequest
TechnischeUntersuchung Entscheidung
Information an Antragsteller
Änderung betroffener Dokumente
Projektnotiz
Verfolgung des Change RequestSystemplanung
Abgelehnt
Angenommen
44
1. Projektspezifische Definition der Projektfunktionen
2. Übertragung der Projekt-funktionen inkl. Kompetenz und Verantwortung auf die Aufgabenträger
3. Einbettung des Projekts in die vorhandene Organisation
Projektfunktionen Aufgabenträger Organisationsformen
ProjektleitungProjektplanung und -überwachungSystemplanung und -überwachungSystementwicklungSystemintegration und -testKonfigurations-managementQualitätssicherung
Personen
Projektstellen- Linienstellen- Stabsstellen- Temporäre Stellen
Gremien
Linien-Projektorganisationen
Matrix-Projektorganisationen
Reine Projektorganisation
1.5. Projektmanagement – Crashkurs Projektfunktionen
45
1.5. Projektmanagement – Crashkurs Projektfunktionen – Checkliste
ProjektleitungKlärung der Zielvorgaben und Randbedingungen des Projektes; Festlegung projektinterner ZielvorgabenSteuerung der ZielerreichungFestlegung der Aufbau- und AblauforganisationDelegation von Aufgaben; Vergabe von TeilaufträgenKoordinierung aller am Projekt beteiligten StellenRessourcen- und PersonalbeschaffungPersonalführungEntscheidung über LösungsalternativenFestlegung von EntwicklungsprioritätenEntscheidung über Freigabe von Planungen und EntwicklungsergebnissenInformation des ManagementsKommunikation mit dem AuftraggeberAußenvertretung des Projektes
46
1.5. Projektmanagement – Crashkurs Projektorganisation – Organisationsformen
Bereichsleitung Bereichsleitung
E F VPL E F VPL
PL
PL
Projekte in reiner Projektorganisation
Projekte in Matrixorganisation
Projekte in reiner Linienorganisation
Bereichsleitung
E F V
PLPL
47
1.5. Projektmanagement – Crashkurs Projektplanung – Allgemein
Strukturplanung ProduktstrukturObjektstrukturProjektstruktur
AufwändeDauerTermineKapazitätenKosten
Operative Planung
48
1.5. Projektmanagement – Crashkurs Schritte der Projektplanung
Produktstruktur
Objektstruktur
Projektstruktur
Aus welchen Komponenten besteht das Produkt?
Welche generellen Untersuchungen?Welche Zwischenergebnisse (Prototypen)?Welche Entwicklungsdokumente?Welche Hilfsmittel, Tools, Vorrichtungen, Messgeräte?Welche Steuerungsergebnisse (Planungen, Berichte)?
Welche Arbeitspakete zur Erstellung der Objekte?
49
1.5. Projektmanagement – Crashkurs Ablaufplan
Design-spezifikation
Komponenten-spezifikation
Test-spezifikation Testdaten
Komponenten-beschreibung
Komponenten-code
Der Ablaufplan stellt die sachlogische Verknüpfung (Input/ Output) der Arbeits-pakete des Projekt-strukturplans dar.
Der Ablaufplan bildet die Grundlage für die Erstellung des Netz-plans.
Der Ablaufplan fasst Arbeitspakete des Projektstrukturplans sinnvoll zusammen.
Der Ablaufplan wird grafisch dargestellt.
Komponenten-test
50
1.5. Projektmanagement – Crashkurs 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.
51
1.5. Projektmanagement – Crashkurs Definition des Meilensteins
Meilensteine bezeichnenDefinierte Sachergebnisse (Meilenstein-Inhalt)Fertigstellungstermin (Meilenstein-Termin)
Meilenstein-Inhalte sindwesentlichüberprüfbarübergebbareindeutig festgelegtvoraus definiert (Phasenorganisation)
Meilenstein-Termine werden in der Projektplanung ermittelt
53
1.5. Projektmanagement – Crashkurs Meilenstein-Trendanalyse
Berichtszeitpunkte
Meilenstein-Termine
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
200x
200x
200x
200x
200x
200x 200x 200x 200x 200xI II III IV I II III IV I II III IV I II III IV I II III IV
Projekt: xxxProjektleiter: xxx
55
1.5. Projektmanagement – Crashkurs Meilenstein-Trendanalyse
Berichtszeitpunkte
Meilenstein-Termine
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
200x
200x
200x
200x
200x
200x 200x 200x 200x 200xI II III IV I II III IV I II III IV I II III IV I II III IV
Projekt: xxxProjektleiter: xxx
56
1.5. Projektmanagement – Crashkurs Abweichungen
Der Fertigstellungsgrad eines Software-Projektes wird während der Hälfte der Projektlaufzeit mit größer als 95% eingeschätzt !
Subjektive Ein-schätzung der Fertigstellung
20
40
60
80
100 100
10
30
50
75
9095 95 9898 98 99
57
1.5. Projektmanagement – Crashkurs Berichtswesen
Ziel: Stets aktueller Überblick
Was wird berichtet? Wie wird berichtet?
Verbal
TermineKostenLeistung, QualitätKapazität
Harte Daten
ProblemeMotivationRisikoerwartungVerhalten des Auftraggebers
Weiche Daten
Meilensteintrendanalyse (MTA)ProjektberichterstattungMeilensteine, Arbeitspakete, Labor-berichte, QS- Berichte, KM- Control
MonatsberichtTOP Bericht
58
1.5. Projektmanagement – Crashkurs Abweichungen
Ziel: Abweichungen möglichst früh erkennen!
Welche Abweichungen gibt es? Woran erkennt man sie?
Vollständigkeit der ErgebnisseQualität der ErgebnisseTermineKostenProduktivitätKapazitätManagementziele
Offizielles Berichtswesen- MTA- Verbale Monatsberichte- QS- Berichte- Projektbibliotheks-Bericht
Beobachtung- Stimmung im Projekt- Gespräche- Arbeitsverhalten- Gerüchte
Reviews
59
1.5. Projektmanagement – Crashkurs 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
60
1.5. Projektmanagement – Crashkurs Steuerungsmaßnahmen
Ziel: Termin einhalten!
Produktivität
ReduzierenVersionsbildungProduktkauf
Technische AlternativenEntwicklungsprozessNutzen von Vorhandenem
VergrößernUmverteilenZukaufen
AusbildungAbschirmenInformation, KommunikationMotivation
Leistung
Aufwand
Kapazität
61
1.6 Schlüsselfaktoren für den Projekterfolg
Projekterfolg eingebettet in Handlungsweisen des/derProjektmanagersseines TeamsÜbergeordneten OrganisationOrganisation des Auftraggebers
Handlungsweisen des PMs, die den Projekterfolg fördernProjektkernteam selbst auswählenNur Mitarbeiter in Kernteam aufnehmen, die bewährt sindVon Anfang an: Gefühl der Verpflichtung und Sinn für MissionAusreichende Kompetenzen beschaffenOrganisationsform: ProjektorganisationGutes Verhältnis zu den BeteiligtenÖffentliches Ansehen des Projekts verbessernKernteam in Entscheidungsfindung und Problemlösung einbeziehen…
62
1.6 Schlüsselfaktoren für den Projekterfolg
Handlungsweisen die Projekterfolg fördern…Realistische Kosten-, Zeit- und Leistungsvorgaben entwickelnEinen Ausweichplan für potenzielle Probleme bereithaltenEine passende Teamstruktur wählen, die trotzdem flexibel und flach istFunktionsfähige Projektplanungs- und Steuerungswerkzeuge einsetzen→ Sich nicht nur auf eine Art von Steuerungswerkzeug verlassenPrioritäten vergeben, um das Endziel zu erreichenÄnderungen unter Kontrolle haltenNach Möglichkeiten suchen, um leistungsfähigen Projektteammitgliedern einen sicheren Arbeitsplatz zu bieten
63
1.6 Schlüsselfaktoren für den Projekterfolg
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 zuzulassenDie Bereitschaft, sich an Änderungen anzupassenEine effektive strategische PlanungDie angemessene Betonung von Erfahrungen aus der VergangenheitDer Einbau von PufferzeitenEine unmittelbare und korrekte KommunikationEine „enthusiastische“ UnterstützungAllen betroffenen Parteien deutlich machen, dass das Projekt einen Beitrag zum Unternehmenserfolg leistet
64
1.6 Schlüsselfaktoren für den Projekterfolg
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 ProjektmanagerDelegation ausreichender Befugnisse an den Projektmanager. Dem Projektmanager gestatten, wichtige Entscheidungen gemeinsam mit den Kernteammitgliedern zu treffen.Begeisterung für das Projekt und sein Team zeigenAufbau von kurzen, informellen KommunikationswegenDen Projektmanager in Bezug auf Vertragsabschlüsse nicht extrem unter Druck setzenDie Kostenschätzung des Projektteams nicht willkürlich zusammenstreichen oder aufblasenEin enges Arbeitsverhältnis zwischen Auftraggeber und Projektmanager herstellen
65
1.6 Schlüsselfaktoren für den Projekterfolg
Vorbedingungen für Management-TechnikenKlare Spezifikationen und Designs Realistische ZeitpläneRealistische KostenpläneVermeidung von übermäßigem Optimismus
AuftraggeberseiteDie Pflege einer engen BeziehungDie Aufstellung von vernünftigen Zielen und KriterienGut etablierte Prozeduren für VeränderungenUmgehende und exakte KommunikationMinimierung des PapierkriegsDer Kontaktperson ausreichende Befugnisse geben (insbesondere bei der Entscheidungsfindung)
66
1.7 Kosten des Projektmanagements
Kosten des Projektmanagementsoft Widerstand gegen moderne PM-Methoden wegen angeblich zu hohen KostenDie Frage sollte aber nicht
”Kann ich mir ein Projektmanagement leisten?“
sondern
”Kann ich mir es leisten, kein Projektmanagementzu haben?“
lauten.
67
1,7 Kosten des Projektmanagements
Art und Umfang der durchzuführenden PM-Aufgaben hängen u.a. ab von
Art der EntwicklungsaufgabeGröße des EntwicklungsvorhabensForm der ProjektorganisationAnzahl der EntwicklungspartnerEntwicklungsdauerVerhältnis Personal-/MaterialkostenDurchdringung mit PM-Methoden und Verfahren
68
1.7 Kosten des Projektmanagements
Kostenbestandteile des PMPlanungskosten
Projektgründung, Wirtschaftlichkeitsprüfung,Strukturplanung, Aufwandsabschätzung, Terminplanung,Kostenplanung etc.
ÜberwachungskostenStundenkontierung, Netzplanaktualisierung,Kostenerfassung, Fortschrittskontrolle, Qualitätssicherung etc.
VerfahrenskostenVerfahrensabwicklung, Anwenderunterstützung, Projektführungssysteme, PC-Einsatz etc.
Beachte: Normalerweise PM-Kosten getrennt von Konfigurationsmanagement, Dokumentationsmanagement und Qualitätssicherung
69
1.7 Kosten des Projektmanagements
Prozentualer PM-Kostenanteil
Grobe Regeln:kleine Projekte: 8%mittlere Projekte: 4%große Projekte: 2%
71
1.8 Summary
Management• Wissen• Wollen• Entscheiden• Durchsetzen
Mitarbeiter• Zielvorgaben• Problembewusstsein• Know-How• Unterstützung
Erfolgreiche Anwendung des Projektmanagements
72
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
73
ProjektmanagmentErster Überblick über die Vorlesung
4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung
5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
74
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
75
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.
76
So nicht …
ZitateBei uns gibt es keine Projekte …Das machen wir schon, aber anders …Zu aufwendig, zu bürokratischDafür haben wir jetzt keine ZeitDas ist nur in großen Projekten anwendbarWir brauchen einen VW, keinen MercedesDas 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 …
77
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
78
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
79
Kapitel 2:Faktor Mensch
Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
81
2. Faktor Mensch
Ausgangssituation„The major problems of our work are not so much technologicalas 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/BenutzerTeamdynamik stimmt nichtHohe FluktuationMangelnde Fähigkeiten der Beteiligten
82
2. Faktor Mensch
Produktivitätsvarianzen:Beste Mitarbeiter um Faktor 10 besser als schlechtesteBeste Mitarbeiter um Faktor 2,5 besser als DurchschnittÜberdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittlicheUnabhängig von Leistungsmetrik:
Anzahl der FehlerKalenderzeit bis MeilensteinFunktionspunkte pro Zeiteinheit
83
2. Faktor Mensch
FluktuationFluktuationskosten:
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 einErsetzbarkeitsgefühl: Management betrachtet Mitarbeiter als austauschbare RessourceBezugsmangel: Mitarbeiter haben keinen Bezug zum Unternehmen
84
Kapitel 2:Faktor Mensch
Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
85
2. Faktor Mensch2.1 Teamworking und Kommunikation
Der Faktor Mensch ist in SW-Projekten sehr groß, deswegen:
Wähle die richtigen Leute ausBetraue die richtigen Mitarbeiter mit den richtigen AufgabenMotiviere die MitarbeiterHelfe den Teams durchzustarten und abzuhebenAlles andere sind „Administrivalitäten“
86
2. Faktor Mensch2.1 Teamworking und Kommunikation
Ursachen für SchwierigkeitenMangelnde Kommunikation mit KundenMangelnde Kommunikation mit KollegenMangelnde Kommunikation mit VorgesetztenMangelnde Kommunikation mit StakeholdernUnklare KommunikationswegeDer Kunde als FeinbildMit der Dauer des Projekts sinkt die MotivationEndlose MeetingsZu viel KontrolleZu wenig KontrolleUnrealistische Ziele
Worst-Case: „Team-Selbstmord“
87
2. Faktor Mensch2.1 Teamworking und Kommunikation
GegenmaßnahmenDefensives 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ürokratieSituation:
- 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.
88
2. Faktor Mensch2.1 Teamworking und Kommunikation
GegenmaßnahmenVerteiltes 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 UnterbrechungenSituation:
- 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.
89
2. Faktor Mensch2.1 Teamworking und Kommunikation
GegenmaßnahmenAngeordnete 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 TermineSituation:
- 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.).
90
2. Faktor Mensch2.1 Teamworking und Kommunikation
GegenmaßnahmenUnbekannte 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.
91
2. Faktor Mensch2.1 Teamworking und Kommunikation
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, SeminarKönnen: Wissen anwenden könnenErfahrung: 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,…
92
2. Faktor Mensch2.1 Teamworking und Kommunikation
Software Engineering Body of KnowledgeKriterien, 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.
95
2. Faktor Mensch2.1 Teamworking und Kommunikation
Process Communication ModelWird in größeren Unternehmen in mehr als 20 Ländern eingesetzt, z.B. NASA für AstronautenteamsWird verwendet um Team hinsichtlich Kommunikationsfähigkeit zusammenzustellen. 6 Charaktere
TräumerWorkaholicWiderständlerRevolutionärBewahrerBefürworter
Jeder läßt sich anders (de-)motivieren,…Ideal ist es wann keiner der Charaktere zu häufig vertreten ist
96
2. Faktor Mensch2.1 Teamworking und Kommunikation
Sozialisierung mit anderen, Selbstzweifel, Kritik
auf Fehlern herumreiten, Selbstherrlichkeit
eine angenehme Umgebung, sowohl bzgl. Räumlichkeiten als auch Kollegen
freundlich, sensibel, mitfühlend, Gefühlsgetrieben
Widerständler
Kritik, Frustration, Beschwerden bzgl. Geld, Fairness und anderen Mitarbeitern
wenn es zu persönlich wird, wenn Argumente fehlen, Need-to-Know-Prinzip
Anerkennung von Leistung, Schulterklopfen, Bonus, Incentives, logische Argumentation
logisch denkend, verantwortungsvoll, organisiert, Zeit-getrieben
Workaholic
Aufgaben werden nicht fertig; Rückzug vom Tagesgeschehen
Reaktion
unruhige Umgebung, Führungslosigkeit
Demotivation
schätzt Einsamkeit und braucht viel Zeit zum Überlegen, um kreativ zu sein, wird durch Incentives und Personen motiviert
Motivation
einfallsreich, nachdenklich, ruhig, introvertiert, leicht zu führen
Charakter
Träumer
PCM-Typ
97
2. Faktor Mensch2.1 Teamworking und Kommunikation
aufwendige Argumentation, negative Dramaturgie, Regelbruch
Unentschlossenheit, Schwäche, Konfrontation
Risikobereitschaft, Geldanpassbar, überzeugend, charmant, einfallsreich, Aktions-orientiert
Befürworter
Kreuzzüge, Selbstgerechtigkeit, verbale Attacken
Selbstherrlichkeit, Machtspiele, Neudefinitionen
Anerkennung von Leistung, Kommittment zu Zielen
hingebungsvoll, beobachtend, gewissenhaft, hartnäckig, bewerten durch Meinungen anderer
Bewahrer
Opportunismus, Beschwerden, Vorwürfe
Reaktion
zeitliche Einschränkungen, Prediger
Demotivation
ständiger Gedanken-austausch mit anderen, persönlicher Kontakt, Spaßfaktor
Motivation
spontan, kreativ, verspielt, ausdrucksstark, tatkräftig
Charakter
Revolutionär
PCM-Typ
98
2. Faktor Mensch2.1 Teamworking und Kommunikation
TeamaufbauTeambildung (nach DeMarco, Lister):
Auf gemeinsames Ziel ausrichtenElitegefühl pflegenAnerkennung verteilenQualität zum Kult erhebenStrategische anstatt taktischer RichtlinienErfolgreiche Teams erhalten
Teamverhindernde Faktoren:Kontrolle statt VertrauenRäumliche TrennungAufsplitterung auf mehrere ProjekteQualitätsreduktion
99
2. Faktor Mensch2.1 Teamworking und Kommunikation
Entwicklungsphasen eines Teams
Neue Teammitglieder
Aufgabenänderung
Kein Konsens
100
2. Faktor Mensch2.1 Teamworking und Kommunikation
InitialphaseProjektziel, die Aufgaben der einzelnen Projektmitglieder und die Zusammenarbeit werden definiert.Teammitglieder finden heraus, was sie tun werden. Führungsstil wird klarArten der zwischenmenschlichen Kommunikation und Aufgabenteilung wird klarDiese Phase ist geprägt von Wohlwollen, Höflichkeit, Missverständnissen und Vorsicht.
KonfrontationsphaseJetzt 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.
OrganisationsphaseGruppenregeln 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.
ArbeitsphaseBasis 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.
101
2. Faktor Mensch2.1 Teamworking und Kommunikation
Grundregeln der TeamarbeitAnerkennung geben, Beiträge forderngemeinsam handelneigene Meinung offen äußernZiele im Auge behaltenKonflikte ausdiskutierenaufmerksam zuhörenKritik akzeptieren
102
2. Faktor Mensch2.1 Teamworking und Kommunikation
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
103
2. Faktor Mensch2.1 Teamworking und Kommunikation
Weitere Kommunikationsplattformen für ein Team:Projekt-MailinglisteProjekt-WebsiteProjektportalProjektfrühstückProjektstammtischProjekt-Kaffee-Ecke mit Espresso-MaschineProjektpartyKamingespräch mit Kundenetc.
Weiterentwicklung des TeamsSchulung, Entwicklungsplan,… → Motivation
104
2. Faktor Mensch2.1 Teamworking und Kommunikation
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 MailsWas 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)
105
2. Faktor Mensch2.1 Teamworking und Kommunikation
Führungsqualitäten eines Projektleiters ist die emotionale Intelligenz. Sie beruht auf fünf Elementen:
Selbstwahrnehmung,Eigenmotivation,Selbstregulierung,Empathie undsoziales 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.
106
2. Faktor Mensch2.1 Teamworking und Kommunikation
Führungswerkzeuge
VisionenUnser 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.
VorbilderVorbild 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.
DelegationDie 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.
MotivationWir 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.
LobLeistung, 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.
TadelDurch Tadel darf kein Stress oder Druck entstehen. Menschen unter Druck denken nicht schneller. Richtiger Tadel erfordert eine disziplinierte Gesprächsführung
»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
107
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
ZusammenfassungDer »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-Closinggesteuert 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.
108
Kapitel 2:Faktor Mensch
Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
109
2. Faktor Mensch2.2 Interviewtechnik
Wann werden Interviewtechniken verwendet:BewerberverfahrenAuswahlentscheidungenKundenanforderungen….
Beispiel hier: Bewerberauswahl!
110
2. Faktor Mensch2.2 Interviewtechnik
Stellenbezogenen AnforderungskriterienPersö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 diepersö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.
111
2. Faktor Mensch2.2 Interviewtechnik
Fähigkeiten können seinLernfähigkeitKreativitätTeamfähigkeitErgebnisorientierungKundenorientiertungKommunikationsfähigkeitenDurchsetzungfähigkeitMotivationsfähigkeitStrategisches DenkenInitiativeVeränderungsfähigkeitNetworking SkillsEinfühlungsvermögenAnalysefähigkeitenPlanungs- und OrganisationsgeschickMobilitätInterkulturelles Verhalten…
112
2. Faktor Mensch2.2 Interviewtechnik
Typische Probleme von AuswahlentscheidungenWichtige Informationen werden übersehenDie gleichen Themen werden mehrmals in den Interviews behandeltDie Informationen des Bewerbers werden vom Interviewer falsch interpretiertVorurteile und Klischees beeinflussen die BeurteilungDie Interviewer machen sich nicht genug NotizenDie Interviewer treffen voreilige EntscheidungenDie Beurteilungsdiskussion der Interviewer ist nicht systematischDie Interviewer lassen sich bei ihrer Einschätzung von einem einzigen Kriterium leitenDer Druck zur schnellen Besetzung der Stelle führt zu verfrühten EntscheidungenDie Vorstellungen und Wünsche des Bewerbers werden nur unzureichend beachtet
Interviewtechniken notwendig
113
2. Faktor Mensch2.2 Interviewtechnik
WahrnehmungsverzerrungenWertungsfreie, 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 EindruckProblem: 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ätUrteil: Diese Person ist unzuverlässig.
114
2. Faktor Mensch2.2 Interviewtechnik
Wahrnehmungsverzerrungen 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-ÜberstrahlungseffektBlendung 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-EffektMit steigender Anzahl der Kandidaten werden die Aussagen immer weniger zuverlässig.
115
2. Faktor Mensch2.2 Interviewtechnik
WahrnehmungsverzerrungenReihenfolgeeffekt/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 EignungstheorieDer 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.
116
2. Faktor Mensch2.2 Interviewtechnik
Tipps zur Reduzierung der FehlerquellenSchaffen 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-Augen-Prinzip).Ü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
117
2. Faktor Mensch2.2 Interviewtechnik
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!!
118
2. Faktor Mensch2.2 Interviewtechnik
FrageformenGeeignete Fragen:
„W“-FragenOffene FragenBeispiele:
- „Wie würden Sie eine Aufwandsabschätzung durchführen?"- „Warum sind Sie so vorgegangen?„
Weniger geeignete FragenSuggestivfragenJa-Nein-FragenTheoretische FragenBeispiele:
- "Sie haben doch sicher schon einmal eine Budgetplanung gemacht?"- "Wenn Sie eine ISDN-Anlage installieren, würden Sie das wirklich ohne Anleitung versuchen?"
119
2. Faktor Mensch2.2 Interviewtechnik
Fragetechnik - Verhaltensdreieck
Situation
Vorgehen Ergebnis
120
2. Faktor Mensch2.2 Interviewtechnik
Fragetechnik – VerhaltensdreieckDen 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.
121
2. Faktor Mensch2.2 Interviewtechnik
BeispieleTeamfä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
BudgetplanungWann haben Sie die letzte Budgetplanung gemacht?Wie sind Sie dabei vorgegangen?Wie war das Ergebnis?
123
Kapitel 2:Faktor Mensch
Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
124
2. Faktor Mensch2.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
125
2. Faktor Mensch2.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?
126
2. Faktor Mensch2.3 Zeitmanagement
ZeitdiebeUnvollständige ArbeitenAufgaben, die doppelt ausgeführtEingehende Anrufe, Briefe und E-MailsZuständigkeiten sind unzureichend definiert und es fehlt die angemessene KompetenzÄnderungen ohne direkte Benachrichtigung/ ErklärungWartezeiten, z.B. durch verspätete MitarbeiterUnfähigkeit, zu delegieren, oder unkluge DelegationMangelhaftes System zur InformationsgewinnungMangel an Informationen, die direkt eingesetzt werden könnenTägliche VerwaltungsarbeitenBeschwerden der GewerkschaftZu viele Review-EbenenDer Plausch im BüroFehlplatzierte InformationenPrioritätenwechselUnentschlossenheitVerzögerungenTreffen von VerabredungenZu viele SitzungenDie Überwachung delegierter Tätigkeiten …
…Unklare Rollen-/StellenbeschreibungenEinmischung durch die UnternehmensführungDie Anforderung, am Budget festzuhaltenSchlecht ausgebildete KundenNicht genügend erprobte ManagerDas Fehlen einer StellenbeschreibungZu viele Personen sind an unwichtigen Entscheidungen beteiligtMangelndes FachwissenMangelnde Kompetenz, Entscheidungen zu treffenDürftige Statusberichterstattung ArbeitsüberlastungUnvernünftige ZeitvorgabenZu viel ReisetätigkeitFehlen der passenden Projektmanagement-ToolsJede Abteilung will den »schwarzen Peter« an andere weitergebenUnternehmensrichtlinienWidersprüchliche AnweisungenBürokratische Hindernisse (»Ego«)Linienmanager, die sich ihr eigenes Reich aufbauenMangelnde Kommunikation …
129
2. Faktor Mensch2.3 Zeitmanagement
Effektives Zeitmanagement (PM)DelegierenDen Ablauf- und Terminplan einhaltenSchnell entscheidenEntscheiden, wer sich darum kümmern sollLernen, nein zu sagenSofort beginnenDen schwierigsten Teil zuerst erledigenReiseunterbrechungen zum Arbeiten nutzenNutzlose Mitteilungen vermeidenUnwichtige Arbeiten ablehnenVorausschauenFragen: Ist die Reise wirklich nötig?Die eigene Energiekurve kennenTelefon- und E-Mail-Zeiten steuernEine Tagesordnung für Sitzungen versendenVerzögerungen überwindenDen Führungsstil »Management by Exception« anwenden
130
2. Faktor Mensch2.3 Zeitmanagement
Regeln für das ZeitmanagementDurchführung einer Zeitanalyse (Zeitprotokoll) Planung fester Zeiten für wichtige DingeKlassifikation der AktivitätenPrioritäten aufstellenOpportunitätskosten für die verschiedenen Aktivitäten aufstellenDas System trainieren (Chef, Mitarbeiter, Kollegen)DelegierenDinge absichtlich ablehnenFührung nach dem Ausnahmeprinzip praktizierenAusrichtung auf Möglichkeiten, nicht auf Probleme
FragenWelche meiner Tätigkeiten können eigentlich ganz wegfallen?Welche meiner Tätigkeiten kann eine andere Person besser erledigen?
131
Kapitel 2:Faktor Mensch
Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
132
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Konflikte können Todesurteil für Projekt seinKonflikte entstehen
Durch unterschiedliche Ziele und WertevorstellungenMissverständnisseAntipathieRivalitätMobbingZukunftsängsteErfolgslosigkeit
133
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Phasen eines KonfliktsDiskussion
Am Anfang steht meistens eine Sachfrage, an der sich unterschiedliche Meinungen und Interessen festmachen.
ÜberlagerungIm Verlauf der Diskussion werden Argumente der anderen Seite nicht mehr akzeptiert. Man unterstellt letztlich immer Unaufrichtigkeit. Die Sachebene wird zunehmend von der Beziehungsebene überlagert.
EskalationDie 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ärtungWenn 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.
135
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Konfliktlösung - Verhaltensdreieck
Situation
Vorgehen Ergebnis
136
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
„Problemfall“ Mensch im Projekt:Menschen schätzen keine Veränderungen und versuchen sie zu ignorieren
137
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
ManagementaufgabenMenschen 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: MotivationKlare 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 machenKonflikte adressieren:
- Delegation: Verantwortliche informieren- Motivation: Ziele identifizieren
138
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Kooperation motivierenKooperation motivieren:
Engagement entsteht durch Wollen, nicht durch müssenMangelnde Motivation führt zu BlockierhaltungNach Außen: Ziele und Erwartungen aller Verantwortlichen identifizierenNach 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 wahrnehmenGemeinsamen Profit identifizierenIn Planung und Umsetzung miteinbeziehen
139
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Verantwortung delegierenVerantwortung 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 ManagementNach 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)
140
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Verantwortung delegierenDelegation 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
141
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Unklarheiten identifizieren:Unklarheiten lösen sich nicht von selbstUnklarheiten führen zu Konflikten oder Demotivation
Die Optimismusfalle (Innovative Projekte scheitern)Unklarheiten verursachen übertriebenen Optimismus (Pessimismus)Realistische Einschätzungen gewinnen:
Optimistische, realistische, pessimistische SchätzungenReferenzdaten gewinnen
Klare Leistungen verbindlich regelnSinnlose Sitzungen (Unproduktive Sitzungen):
Was soll in der Sitzung erreicht werden, was nicht?Welche Aufgaben ergeben sich aus der Sitzung?
142
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Konflikte adressieren:Ungelöste Konflikte hinterlassen UnklarheitenUngelöste Konflikte verursachen Demotivation
Die Sozialkompetenzfalle (Projekte werden durch soziale Spannungen aufgehalten):
Spielregeln vereinbaren:Wie wird abgestimmt?Wie wird informiert?Wie wird diskutiert?
Krisensituationen moderierenKonflikte erwarten (Anzeichen erkennen)Lösungen anstatt Schuldzuweisungen
143
2. Faktor Mensch2.4 Konflikte und Problemlösungstechniken
Konflikte adressierenNach 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
144
Kapitel 2:Faktor Mensch
Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
145
2. Faktor Mensch2.4 Moderations- und Kreativitätstechniken
Grundsätze für den Moderator nicht gegen die Gruppe ankämpfenStörungen haben Vorrangunterscheiden: Wahrnehmung, Vermutung, Bewertung„ich“ – statt „man“nonverbale Signale beachtennicht bewerten und beurteilensich nicht rechtfertigennicht über die Methode diskutieren
146
2. Faktor Mensch2.4 Moderations- und Kreativitätstechniken
Aufgabe des Protokollantenerfasst die Substanz simultan mit dem Prozesserfasst „öffentlich“vermeidet Manipulation bzw. Färbungendokumentiert nicht länger als nötig, z.B. nur Ergebnisprotokollvisualisiert
147
2. Faktor Mensch2.4 Moderations- und Kreativitätstechniken
Aufgaben des Moderatorsformaler SteuererOrdnungsfunktionregulierenstimulierenkoordinierensteuernsachneutral
148
2.4 Moderations- und KreativitätstechnikenBrainstorming
IdeeGruppendiskussionAusschalten denkpsychologischer Blockaden freies Spinnen von Ideenvier Grundregeln des Brainstormings
„Prinzip der freien Abstraktion“
Zurückstellen jeglicher KritikZurückstellen jeglicher Kritik
Aufgreifen, Kombinieren oderWeiterentwickeln
geäußerterIdeen
Aufgreifen, Kombinieren oderWeiterentwickeln
geäußerterIdeen
Ideen freien Lauf lassenIdeen freien Lauf lassen
Quantität geht vor Qualität
Quantität geht vor Qualität
149
2.4 Moderations- und KreativitätstechnikenBrainstorming
Einsatzgebiet Kreativphasen: Produktideenfindung, ProduktkonzepterstellungGenerierung latenter Anforderungen in der Produktprofilplanungfür Suchprobleme bzw. einfachere (Teil-)problemeintegrierbar in andere Methoden, z.B. Szenariotechnik
Verbreitung:am häufigsten angewandte KreativitätstechnikAnwendungsgrad 50-80%
Produkt-strategieplanung
Produkt-ideenfindung/-bewertung
Produkt-profil-
planung
Produkt-konzept-planung
Produkt-kosten-planung
Produkt-konzept-erstellung
150
2.4 Moderations- und KreativitätstechnikenBrainstorming
Voraussetzungen Schulung der Teilnehmer
Flipboard und Konferenzraum
erfahrener Moderator
151
2.4 Moderations- und KreativitätstechnikenBrainstorming
Durchführung Einberufung 1-3 Tage im vorausTeilnehmerkreis 5-8 Personenfachlich heterogen, hierarchisch homogen20-40 min DauerModerator überwacht Einhaltung der GrundregelnNachsitzung
152
2.4 Moderations- und KreativitätstechnikenBrainstorming
Vorteile
rasch erlernbareinfach und schnellvielseitige Ideenanregend und motivierend
Nachteile
nur für relativ einfache Problemekeine VorgehenssystematikEinhaltung der Grundregeln schwierig
153
2.4 Moderations- und KreativitätstechnikenBrainstorming
Varianten Diskussion 66
größerer Teilnehmerkreis Little-Technik
Problem zunächst nicht bekanntimaginäres Brainstorming
Verfremdung des Problems SIL-Methode
Einzel- und Gruppenarbeit abwechselnd Mindmaps
154
2.4 Moderations- und KreativitätstechnikenBrainstorming
Literatur Schlicksupp, H.: Kreative Ideenfindung in der Unternehmung – Methoden und Modelle, de Gruyter Verlag, Berlin, 1977
Schlicksupp, H.: Innovation, Kreativität und IdeenfindungVogel Verlag, Würzburg, 1989
Knieß, M.: Kreatives Arbeiten, dtv Beck Verlag, München, 1995
Baier, D.: Marketing und Innovation, Vorlesungsskript, Universität Karlsruhe, 1997
155
2.4 Moderations- und KreativitätstechnikenMind-Maps
IdeeMethode 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.
156
2.4 Moderations- und KreativitätstechnikenMind-Maps
Mind-MapsTeilnehmerzahl
Einzeln oder in kleinen GruppenVoraussetzungen
Flip-chart und Moderator (bei Gruppen)PapierFarbstifte
157
2.4 Moderations- und KreativitätstechnikenMind-Maps
Durchführung 1. Man schreibt in die Mitte eines Papierbogens das Thema2. Es wird mit einem Kreis umschlossen.3. Ausgehend von diesem Kreis werden Verästelungen gebildet,
welche das Thema in einzelne Bereiche gliedern. Es entstehenAssoziationen und von den Ästen können wiederum Zweige zurKonkretisierung 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 Speziellennur Substantive verwendenin Blockschrift
159
2.4 Moderations- und KreativitätstechnikenMind-Maps
VorteileFörderung der KreativitätSteigerung der EffektivitätGuter Überblick über das Gesamtproblemschnell und einfach erlernbarflexibel anwendbar
NachteileZeitbedarfAls Anfänger kann man bei der Stichwortsuche Probleme habenOft fallen konkrete Stichworte schon vor der Astbildung.
160
2.4 Moderations- und KreativitätstechnikenMind-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
161
2.4 Moderations- und KreativitätstechnikenMethode 635
IdeeWeiterentwicklung des Brainstorming
Die Ideen eines Teilnehmers werden von dem Zweiten fortgesetzt und dann von dem Dritten usw.
schriftlich (Formblatt)6 Teilnehmer3 verschiedene Lösungsvorschläge zum selben Thema5 Minuten Zeit für drei Ideen
Einsatzgebiet Vor dem Verwenden anderer und aufwendigerer Entwicklungsmethoden einsetzen
163
2.4 Moderations- und KreativitätstechnikenMethode 635
Durchführung 635-Ablauf in ca. 30 min = 6 * 5 Minuten.
Regeln: kein Kontakt untereinanderZeitvorgaben unbedingt einhaltenje Feld nur eine Idee, schlagwortartig formuliertHat der Vorgänger ein Feld freigelassen, immer zuerst die eigenen Felder ausfüllen
164
2.4 Moderations- und KreativitätstechnikenMethode 635
VorteileEntfall eines ModeratorsErmittlung des Urhebers einer Erfindung möglicheine Idee wird systematisch weiterentwickelt
Nachteilegeringere Kreativität durch Isolierung und mangelnde Stimulierungmögliche Denkblockaden durch ZeitbeschränkungMissverständnisse durch stichwortartige Beschreibung
165
2.4 Moderations- und Kreativitätstechniken 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
166
2.4 Moderations- und KreativitätstechnikenLaterales 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
167
2.4 Moderations- und KreativitätstechnikenLaterales 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öglichkeitenDer grüne Hut: kreatives Denken, Suche nach neuen Ideen und AlternativenDer 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
168
2.4 Moderations- und KreativitätstechnikenLaterales 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 IdeenBeispiel 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.
169
2.4 Moderations- und KreativitätstechnikenLaterales 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)
170
2.4 Moderations- und KreativitätstechnikenLaterales Denken
Einsatzgebiet Die Techniken des lateralen Denkens sind vor allem zur Ideenfindung geeignet, z.B. zum Auffinden neuer Produktideen oder VerbesserungsmöglichkeitenDie Hutwechsel-Methode wird häufig als allgemeiner Diskussionsrahmen verwendetDie Random-Input–Technik und die Umkehrmethode sind besonders geeignet, wenn der Ideenvorrat erschöpft ist, eine Blockade oder eine “Nullpunkt-Situation”ohne Ausgangspunkt vorliegt.
171
2.4 Moderations- und KreativitätstechnikenLaterales Denken
Voraussetzungen Ein kreatives Team von Kunden/ Konsumenten oder MitarbeiternEin geschulter Moderator oder Diskussionsleiter mit Kenntnissen des lateralen Denkens und seiner Techniken
172
2.4 Moderations- und KreativitätstechnikenLaterales Denken
Durchführung Festsetzung des Themas/ ProblemkreisesZusammenstellen einer Gruppe für den WorkshopAuswahl eines geeigneten ModeratorsAuswahl der Technik/ Kombination von TechnikenDurchführung des Workshops (unter Beachtung der Regeln, z.B. regelmäßiges Wechseln der Hüte)IdeensammlungIdeenbearbeitung (Weiterentwicklung vielversprechender Ideen in Lösungsvorschläge)Bewertung der LösungsvorschlägePlanung erster Implementationsschritte
173
2.4 Moderations- und KreativitätstechnikenLaterales Denken
Vorteile
Basis ist eine anerkannte Theorie der KreativitätNeuartige Denkimpulse bei Stagnation der IdeenproduktionErhöhung der Motivation der Teilnehmer durch spielerisches Element der TechnikenHäufiger Perspektivenwechsel bewirkt mehr und neuartigere Ideen
Nachteile
Unscharfe Definition der einzelnen Techniken, “Verwaschung” durch unqualifizierte AnwendungUnübersichtliche Vielfalt an einzelnen Techniken und Variationen der Techniken
174
2.4 Moderations- und KreativitätstechnikenLaterales 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)
175
2.4 Moderations- und KreativitätstechnikenLaterales Denken
Literatur DeBono, Edward (1986). Edward de Bono's Denkschule: zu mehr Innovation und Kreativität. Landsberg am Lech: MVGDeBono, 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.
177
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
178
ProjektmanagmentErster Überblick über die Vorlesung
4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung
5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
179
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
180
Kapitel 3:Projektinitiierung
Gründung eines Projekts
Wirtschaftlichkeitsbetrachtung
Produkt-/Systemdefinition
181
3 Projektinitiierung
Projektvorbereitung:Projektinitiierung:
Inhaltliche DefinitionSchätzungDurchführungsentscheidungPlanung
Techniken:Innovationsplanung und ProblemfeldanalyseSchätzverfahrenArbeitsplanungAufwands- und TerminplanungPersonalplanung
183
3 Projektinitiierung
Vorauswahl von Projekten
Ausrichtung auf strategische Ziele? Wirtschaftlichkeitssteigerung?
Notwendiges Know-how?
Ausreichend Kapazität?
Projektidee weiterverfolgen! Projektidee eliminieren
Know-how zu akzeptablem Preis erhältlich?
Kapazitäten zu akzeptablem Preis erhältlich
ja
neinnein
nein
nein
nein
ja
ja
ja
nein
nein
ja
ja
185
3 Projektinitiierung
ProjektinitiierungProduktivitätsvarianzen:
Starke Produktivitätsschwankungen zwischen MitarbeiternSchwache Produktivitätsschwankungen im Team
TeamkohäsionTeamidentifikation 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
186
3 Projektinitiierung
Funktion:Grobdefinition der Ziele des ProjektsGrobabschätzung des NutzensGrobabschätzung der Kosten und benötigten EinsatzmittelErstvorschlag zur Projektorganisation
Aktivitäten:Festlegung ProjektzieleErstellung GrobplanVoruntersuchung und DurchführungsentscheidungOrganisationsplanung
Ergebnisse:ProjektauftragProjekthandbuchProjektplan (Grobversion)
187
3 Projektinitiierung
ProjektzieleProjektidee:
Auftragsprojekt: AnforderungskatalogInnovationsprojekt: Marktstudie/TechnologiestudiePflege/Änderungsprojekt: Verbesserungsvorgaben
Wichtig:Festlegung ProjekterfolgskriterienMessbare Kriterien
Präzisierung Projektziele:LastenheftPflichtenheftProjektauftrag
188
3 Projektinitiierung
Produktbeschreibung: Lastenheft, PflichtenheftLastenheft:
Definiert durch Kunde oder ProjektinitiatorFachorientierte Anforderungssammlung
- Produkteinsatz (Welche Nutzer)- Produktumgebung (Welche Schnittstellen)- Fachliches Datenmodell (Welche Information)- Funktionale Spezifikation (Welche Funktion)- Benutzungsschnittstelle (Welche Präsentation)
Pflichtenheft:Definiert durch Kunde und ProjektleiterFachliche 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)
189
3 Projektinitiierung
GrobplanZiel Projektplan (generell): Festlegung von Vorgängen und Meilensteinen und deren Abhängigkeiten
Ziel Grobplan:Grobschätzung Aufwände/Termine: DurchführungsentscheidungAusgangsversion Projektplan: Projektdurchführung
Inhalt Grobplan:Festlegung Projektorganisation:
- Festlegung Projektgrobstruktur- Zerlegung des Projekts in Aktivitäten und Produkte
Festlegung von Aufwänden und TerminenFestlegung von benötigten Einsatzmitteln und Mitarbeitern
190
3 Projektinitiierung
DurchführungsentscheidungZiel: Annahme/Ablehnung ProjektVerfahren:
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
191
3 Projektinitiierung
ProjektauftragVoraussetzung: Durchführungsentscheidung
Bestandteile:Beschreibung des Grobkonzepts (Systemspezifikation)Umfasst: Beschreibung des Leistungsumfang (Pflichtenheft)Umfasst: Beschreibung des Anwendungsgebietes (Lastenheft)
Projektgrobplan: Termine und AufwändeProjekthandbuch: Entwicklungsprozess
Projektstruktur: Externe Rollen (Auftraggeber, Projektmanager, Projektleiter)
193
3 Projektinitiierung3.1 Gründung eines Projekts
Gründung eines ProjektsBasis Projektantrag
bildet vertragliche Grundlage zwischen Auftraggeber und Auftragnehmerlegt Leistungsvolumen, sowieKosten- und Terminrahmen des Projekts fest
Notwendig: klare AufgabenstellungProjektparameter müssen bestimmtProjektrisiken 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
194
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
InnovationsplanungProblem:
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äufermarktMarktgerechte 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 PlanungMarktanalysenGeschäftsfeldplanungProduktplanung
195
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
DefinitionInnovationsplanung ist das gezielte Suchen und Finden von für das Unternehmen lukrative Geschäftsfelder und damit neuer Produkte. Der Ablauf umfasst:
ProduktpositionierungProduktbewertungProduktauswahl
Analysemethoden:Portfolio-AnalysenABC-AnalysenLebenszyklus-Analysen
196
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
Portfolio-Methodezwei-dimensionale Matrix bestimmter Betrachtungsobjekte
GeschäftsfelderProduktgebieteTechnologien
in Abhängigkeit von zwei Beurteilungskriterien mit Skalierung angeordnethäufig werden eigene und konkurrierende Objekte miteinander verglichenx-Koordinate, z.B.
relativer MarktanteilGeschäftsfeldstärketechnisches Weiterentwicklungspotentialrelative Technologieposition
y-Koordinate, z.B.MarktwachstumBranchenattraktivitätProduktattraktivität am Marktwirtschaftliche Bedeutung
Beispiele:GeschäftsfeldportfolioTechnologieportfolio
197
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
Geschäftsfeldmethode (BCG) Feld I:hoher relativer Marktanteilniedriges MarktwachstumCash Cow/Goldesel
Feld II:hoher relativer Marktanteilhohes MarktwachstumStars
Feld III:niedriger relativer Marktanteilhohes MarktwachstumQuestion marks/Fragezeichen
Feld IV:niedriger relativer Marktanteilniedriges MarktwachstumDogs/Sorgenkinder
199
3 Projektinitiierung3.1 Gründung eines Projekts – Innovationsplanung
ABC-Analysewird verwendet um Vorauswahl an Produkten zu treffenAnwendung wenn Unwichtiges von Wichtigem zu trennen ist
z.B. Auswahl von Produktalternativen diejenigen mit meisten UmsatzKlasse 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: Technologieauswahlx-Achse Technologieny-Achse technisch-wirtschaftliche Bedeutung
200
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
Lebenszyklus-AnalysenProduktlebenszyklenTechnologielebenszyklen
201
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
ProduktlebenszyklenZyklen
Entstehungszyklus- Definition- Entwurf- Realisierung- Erprobung
Marktzyklus- Markteinführung- Wachstum- Reife- Sättigung- Degeneration
Standzeiten / InnovationszyklenMobiltelefone < 1JahrPC 2 bis 3 JahreServer 3 bis 5 JahreAnwender-SW etwa 6 JahreKraftwerkstechnik 20 bis 30
202
3 Projektinitiierung3.1 Gründung eines Projekts - Innovationsplanung
Technologie-LebenszyklusS-Kurve3 Phasen
Suchphase- Technologie noch nicht
leistungsfähigDurchbruchphase
- Technologie leistungsfähig- großer Nutzen für das Investment
Reifephase- Verbesserungsmöglichkeiten
ausgereizt- Umstieg auf neue Technologie muß
vorbereitet werden
203
3 Projektinitiierung3.1 Gründung eines Projekts - Grundparameter
Die 3 Grundparameter sind
Projekt
Ergebnis / Leistung
Aufwand /Einsatzmittel
Termin / Zeit
Kapazität
Produktivität
204
3 Projektinitiierung3.1 Gründung eines Projekts - Grundparameter
Dreieck verdeutlicht Abfolge in Projektgeschehen
Einsatz von Aufwänden (Geld, Personal, Maschinen,...) und Verbrauch an Zeitsoll bestimmtes Ergebniserzielt werden
PM hat zentrale AufgabeErbringung geforderte Leistungim optimalen Verhältnis zu Zeit und Einsatzmitteln
Parameterausrichtungkostenfixierte Parameterausrichtungterminfixierte Parameterausrichtungleistungsfixierte Parameterausrichtung
205
3 Projektinitiierung3.1 Gründung eines Projekts - Grundparameter
ProduktivitätKopfzahl (= Personalstärke)Qualifikation
QualitätDIN: Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllenBeispiele:
FunktionserfüllungZuverlässigkeitBenutzerfreundlichkeitWartungsfreundlichkeitInstandhaltbarkeitUmweltfreundlichkeitÜbertragbarkeitZeitverhaltenVerbrauchsverhaltenFertigungsfreundlichkeit
206
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Problemfeldanalyse
Richtiges Produkt
Richtige Methoden u.Werkzeuge
RichtigeAufgaben-
stellung
Richtige Entwicklungs-
dauer
Richtige FuE-Kosten
Richtige Personal-
stärkeRichtige
Qualifikation
Richtiger Funktions-
umfang
207
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtige Aufgabenstellung?Produkt kann genial und hochwertig sein, wenn es aber keine Marktbedürfnisse decktFlop
DeswegenMarktanalysePortfoliodarstellung...
208
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtige Entwicklungsdauer?McKinsey: „Das Einhalten und Verkürzen von Entwicklungszeiten ist wichtiger als das Einhalten und Reduzieren von Entwicklungskosten“3 Varianten der Wirtschaftlichkeitsbetrachtung
209
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtige FuE-Kosten?Es dürfen nicht so viele FuE-Kosten verschlungen werden, wie nie wieder an Erträgen hereinholbar sind. -> Wirtschaftlichkeits-betrachtungen
Minimale Projektkosten
210
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtige Personalstärke?von Brooke: Adding man power to a late project makes it late!Optimale Personalstärke
211
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtige Qualifikation?Produktivität kann erheblich variierenFaktoren von mehr als das 10 (zehn-!)fache sind nicht seltenPersonalplanung
mehr Klasse als MasseKopfzahlen
Make or buy - Entscheidung
212
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtiger Funktionsumfang?Der Kunde bekommt das was er nicht will, aber nicht das was er willRequirements-Engineering sehr wichtiger Schritt!Methoden:
PrioritätenlisteABC-Analyse
Versionsplanung
213
3 Projektinitiierung3.1 Gründung eines Projekts - Problemfeldanalyse
Richtige Methoden und Werkzeuge?SW-Gebiet
Logische EntwurfssystemeGraphische DesigntoolsProgrammeditorenIDEProgrammgeneratoren, z.B. aus UML-DiagrammenTestsystemeProfilerDokumentationssysteme
HW-GebietSysteme zur Logik und FehlersimulationLayout-SystemeGenerierungsprogramme für Prüfdaten
214
3 Projektinitiierung3.1 Gründung eines Projekts – Projektantrag
ProjektantragZiel: Entwicklungsauftrag schriftlich fixierenInhalt
wichtigste Eckpunkt der geplanten EntwicklungZielvereinbarungAufbau, z.B.
- Name des Projekts- Kurzbeschreibung des Vorhabens- Identifikationsbegriff- Projektleiter, Teilprojektleiter- Mit-/Unterauftragnehmer- Geplanter Personalaufwand- Einsatzmittelkosten- Meilensteine- Fertigstellungstermine- Risikobetrachtung- Unterschriften
215
3 Projektinitiierung3.1 Gründung eines Projekts - Projektantrag
Arten von ProjektanträgenProjektauftrag
interne Auftragsvergabe innerhalb eines UnternehmensFuE-Auftrag
FuE-Planung innerhalb EntwicklungsbereichesProduktvereinbarung
Zielvereinbarung zwischen Ertragszentren eines Unternehmens
217
3 Projektinitiierung3.2 Produkt-/Systemdefinition
ZielAufgabendefinition eines ProjektsWird 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
218
3 Projektinitiierung3.2 Produkt-/Systemdefinition
ZielAufgabendefinition eines ProjektsWird 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
219
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Anforderungskatalog
Anforderungskatalog
Ziel: Präzisierung des ProjektzielsMitwirkende: AuftraggeberAspekte für SW-Projekt
Anwendungs- bzw. Einsatzumgebunggeforderte Funktionen und EigenschaftenBenutzeroberflächenBenutzerschnittstellenDatenbasisMengengerüstQualitätsanforderungenRealisierungsvorgabenDokumentationsanforderungenZeit- und Kostenrahmen
Ausgehend vom Anforderungskatalog wird dann der Projektvorschlag definiert, i.a. bestehend ausZusammenfassungProjektdefinitionIst-ZustandLösungsalternativenSystemkonzeptBasis für die Entscheidung über das Projekt
220
3 Projektinitiierung3.2 Produkt-/Systemdefinition
ZielAufgabendefinition eines ProjektsWird 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
221
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Pflichtenheft
PflichtenheftZiel: Definition fachliches Grobkonzept und weitere allgemeine Angaben zu geplanten ProduktAspekte:
welche Funktionen das System erfüllen musswelcher Daten und Informationen verarbeitet werden sollenwelche Ein- und Ausgaben vorgesehen sindwelche konstruktive Vorgaben (bei HW) zu beachten istwelche Schnittstellen berücksichtigt werden müssenwelche sonstigen Produkt/Systemeigenschaften gefordert werden
Anforderungen:vollständigwiderspruchsfrei
222
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Pflichtenheft
Aufbau - PflichtenheftGesamtsystem
SystemumgebungSystemdarstellungSystembeschreibung
TeilsystemTeilsystemdarstellungKurzbeschreibung der TeilsystemeKomponentenfestlegungBeschreibung der Ein-/AusgabedatenDarstellung der Bedienoberflächegeforderte Dialogauskünfte und Auswertungenverfahrensinterne Schnittstellen
DatendefinitionStammdatenBewegungsdatenVerwaltungsdaten
223
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Pflichtenheft
Aufbau – Pflichtenheft …Schnittstellen
zu vor-/nachgelagerten VerfahrenStandard-EingabeschnittstellenStandard-Ausgabeschnittstellen
Allgemeine SystemangabenQualitätsanforderungenAuflagen / RestriktionenMengengerüstArbeitsabläufe, vorhandene/geplante Ablauforganisationensonstige Anforderungen
225
3 Projektinitiierung3.2 Produkt-/Systemdefinition
ZielAufgabendefinition eines ProjektsWird 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
226
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Leistungsbeschreibung
Leistungsbeschreibung Ziel: bildet Gesamtheit der Aufgabendefinition und legt damit die fachliche und technische Basis des geplanten Produkts oder Systems festAspekte:
welche Teilsystem und Komponenten das Produkt/System umfassen sollwelche Fachprozesse zu erfüllen sindwie die Benutzungsoberfläche zu gestalten istwelche Ausgaben in welcher Form zu realisieren sindwie die Datenbasis aussiehtwelche elektronischen und konstruktiven Eigenschaften (bei HW) bestehen werdenwelche Schnittstellen vorhanden sein werdenwelche Realisierungsanforderungen gelten und welche allgemeine Systemeigenschaften gefordert werden
Vereinbarungsgrundlage zwischen Auftraggeber und AuftragnehmerLeistungsbeschreibung ist Basis für
für das Management zur Realisierungsentscheidungfür die Qualitätssicherung zur Vollständigkeitskontrollefür die Planung zur Durchführungsplanung und für die Realisierung zum Erstellen des technischen Feinkonzepts
227
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Leistungsbeschreibung
Im allg. umfasst die Leistungsbeschreibungdas fachliche Feinkonzeptdas technische Grobkonzeptund die allgemeinenRealisierungsanforderungen
228
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Leistungsbeschreibung
Fachliches FeinkonzeptFachliches Gesamtsystem
SystemumgebungSystemdarstellungSystembeschreibung
TeilsystemTeilsystemdarstellungKurzbeschreibung der TeilsystemeVerzeichnis der zugehörigen DatenbereicheVerzeichnis der zugehörigen KomponentenVerzeichnis der zugehörigen Schnittstellen
Beschreibung der KomponentenBeschreibungDatensätzeMasken und Listen
Beschreibung der MaskenFunktion und AufgabeFeldbeschreibungenAnsprungsmöglichkeiten, MeldungenMaskendarstellung
Beschreibung der AuswertungslistenAufgabenbeschreibungListendarstellung
Schnittstellen
229
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Leistungsbeschreibung
Technisches GrobkonzeptBeschreibung IT-System
IT-SystemdarstellungBeschreibung des IT-SystemsIT-SystemdatenflussZuordnung Fachprozess zu IT-Teilsystemen bzw. –Komponenten
Beschriebung der IT-TeilsystemeIT-Teilsystem-BeschreibungStrukturbaum teilspez. IT-KomponentenStrukturbaum zentraler IT-KomponentenAbhängigkeiten zu anderen IT-Komponenten
Beschreibung der IT-KomponentenFunktionsbeschreibungVerarbeitungsschritteAnzahl Satzarten
FremdsoftwareSpeicherkonzept
DatenbankschemaVerzeichnis der DatenDatenbeschreibungen
DatenkatalogName der DatenelementSynonymeSuchbegriffeKurzbeschreibungenAngaben zu Format, Länge DefaultWertebereiche
230
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Leistungsbeschreibung
Allgemeine RealisierungsanforderungenRegeln und Konventionen
GuidelinesAufbau Masken, Listen, MeldungenToolkonzept
Qualitätsanforderungen...
TestkonzeptAufgabenstellungTestfälleTestberichteTestdatenTestplanungTestdurchführungPrüflisten
Auflagen/RestriktionenArbeitsabläufeIT-spezifische Auflagen
DokumentationBenutzerdokumentationAnwendungsdokumentation
Einführungs- und VersionsplanungInstallationskonzeptWartungskonzeptSchulungsplanVersionskonzept
231
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Änderungswesen
ÄnderungswesenÄnderungsanforderungen stellen zwangsläufig bereits erarbeitete Zwischenergebnisse in Frage. Zwischenergebnisse bauen aufeinander auf → gesamte Ergebnisfolge gefährdetWirkung von Änderungsanforderungen
232
3 Projektinitiierung3.2 Produkt-/Systemdefinition - Änderungswesen
Arten von Vorgehensweisen im Änderungsprozess:
kontinuierlicher Änderungsprozess
eingeschobener Änderungsprozess
begleitender Änderungsprozess
234
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
235
ProjektmanagmentErster Überblick über die Vorlesung
4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung
5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
236
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
239
4 Schätzverfahren und Projektplanung4.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.”
241
4.1 SchätzverfahrenÜberblick
Notwendigkeit für SchätzungenBereits 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 zunehmenSchätzungen sind Basis für die gesamte Projektplanung (Ressourcen, Mitarbeiter) und auchfür Folgeaktionen (Markteintritt, Werbekampagnen etc.)Basis für Projektcontrolling
242
4.1 SchätzverfahrenÜberblick
Notwendigkeit für SchätzungenMessung der Produktivität
zum Erkennen von Verbesserungspotentialzur Beurteilung von Prozessverbesserungenzum Benchmarking
Messung der Qualitätzum Erkennen von Schwachstellenzur Prüfung der Wirksamkeit von QS-Maßnahmenals Hilfe bei der Freigabe-Entscheidung
Kernaufgabe für das Projektmanagement
243
4.1 SchätzverfahrenÜberblick
Probleme bei SchätzungenUnvollständiges Wissen über
Tatsächlichen ProjektumfangVoraussichtliche ProjektmitarbeiterTechnischen und organisatorisches Umfeld
Vergleichbarkeit der Projekte bei neuen Technologien, Mitarbeitern und ggf. VorgehensweisenZeitproblemAufwand hängt von sehr vielen Einflußgrößen ab, z.B.:Art der Anwendung, befolgtes Lebenszyklusmodell,nicht-funktionale Anforderungen, künftige Benutzer, organisatorischeRandbedingungen bei Auftraggeber sowie Auftragnehmer, Software- und Hardwareumgebung, Stabilität der Umwelt, Qualifikation derMitarbeiter, Führungsstile, ..., ...
244
4.1 SchätzverfahrenÜberblick
Probleme bei SchätzungenSchätzungen sind ungenau:
Mohanty (1981) - 13 Verfahren getestet: - min. Aufwand: $362.500,
max. Aufwand: $2.766.667
je früher eine Schätzung gemachtwird, 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äzisierungund Kontrolle, ob der Budgetrahmen eingehalten wird.
245
4.1 SchätzverfahrenÜberblick
Grundprinzipien einer SchätzungDokumentation der Annahmen
Gewählte SchätzmethodeAnnahmen über Umfang, Mitarbeiter etc.
Definition der Schätzgenauigkeit (passend zur Projektphase) – Angabe einer ErgebniskorridorsEinbeziehung erfahrener Kollegen (Reviews)
schätzen
ungenaueAnforderungen Mist
Aufgabestrukturieren
Aufgabeschätzen
strukturierteAufgabe
Soll-Werte
noch fehleranfällig! Fehlerhafte Schätzungen der Vergangenheitfließen ein, daher werden ggf. Fehler wiederholt.
247
4.1 SchätzverfahrenÜberblick
Komponenten einer ProjektschätzungKosten/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)
ZeitGesamte ZeitdauerZeitliche 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
248
4.1 SchätzverfahrenÜberblick
Vorgehensweise bei AufwandsschätzungenErmittlung der geschätzten PersonentageVerteilung auf Mitarbeitertypen
Einheitliche Verrechnungssätze (keine Differenzierung notwendig)Unterschiedliche Verrechnungssätze je nach Mitarbeitertyp (Erfahrung, etc.)
Mitarbeiterkosten = Personentage x KostenHier unterschieden sich die Anforderungen innerhalb der Firmen z.T. erheblich (was wird berechnet und wie)
249
4.1 SchätzverfahrenÜberblick
Ermittlung der PersonentageSchwierigster Teil der gesamten ProjektplanungVorgehensweise grundsätzlich:Basierend auf Erfahrungen aus der Vergangenheit werden die bekannten Informationen bewertet und in Aufwände umgerechnetWichtig 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“
250
4.1 SchätzverfahrenÜberblick
Messen SystemkomplexitätKomplexitätsfaktoren
Größe: Anzahl der BausteineDiversität: Unterschiedlichkeit der BausteineVernetzung: Abhängigkeit der Bausteine
Grundlagen der SoftwareschätzungMessung/Schätzung von SystemkomplexitätKomplexität, Aufwand, LaufzeitModellparameter: Projekt vs. Prozess
251
4.1 SchätzverfahrenÜberblick
Wie misst man Software ?Softwaremetrik Code
Lines of Code- Ansatz: Software = Programmcode- Einheit: Lines of Code- Meßverfahren: Softwareumfang = Anzahl Programmzeilen
Anzahl von KlassenAnzahl von Modulen, ProzedurenKomplexitätsmetriken
funktionale MaßeAnzahl der MaskenAnzahl der Verarbeitungsabläufe, GeschäftprozesseDatenflüsse
252
4.1 SchätzverfahrenÜberblick
Code als Komplexitätsmaß
Verbesserung: Standardisierte Code-ZeilenGröße: ZählregelnDiversität: Sprachebene (Assembler, Prozedural, Objektorientiert)Vernetzung: Nicht berücksichtigt
Problem:ImplementierungsmaßzahlKonsequenz: Erst nach Codierung anwendbar
253
4.1 SchätzverfahrenÜberblick
Weitere MetrikenKomponentenmetriken:
I.A. Metriken „algorithmischer“ KomplexitätHalstead: Anzahl (verwendeter) Operatoren/OperandenMcCabe: Anzahl Knoten/Kanten KontrollflussgraphOO-Metriken: Anzahl Vererbungsstufen, Attribute, Methoden
Vorteile:I.A. einfache bzw. automatisierbare ZählverfahrenOperieren auf Code/abstrahiertem Code
Einschränkung:Erst auf Implementierungsebene einsetzbarFokus auf Implementierungsgüte
254
4.1 SchätzverfahrenÜberblick
Komplexität und Prozess
Verschiedene Maße in verschiedenen PhasenImplementierung: CodezeilenPost-Architektur (Feindesign): Abstrakter CodePrä-Architektur: Funktionspunkte
255
4.1 SchätzverfahrenÜberblick
Klassen von VerfahrenAlgorithmische Methoden: Grundlage: Formeln, deren Strukturen und Konstanten empirisch sind und mitHilfe mathematischer Modelle bestimmt werdenVergleichsmethoden: Grundlage: Vergleich früherer Entwicklungen mit dem aktuellen Projekt;Einsatz: speziell in sehr frühen ProjektphasenKennzahlenmethoden: Grundlage: Ableitung von Kennzahlen aus früheren Entwicklungen zwecksBewertung von Schätzgrößen für das geplante Projekt
256
4.1 SchätzverfahrenÜberblick
Weitere Strategien zur AufwandschätzungParkinson’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ügbarsind, wird der Aufwand auf 60 Personenmonate geschätzt.
“Pricing to win”: Die Kosten werden nach dem zur Verfügung stehenden Budget des Kundengeschätzt und die Anforderungen werden dem Budget angepaßt.
257
4.1 SchätzverfahrenÜ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 AnsatzSchä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. DerGesamtaufwand resultiert aus der Summe aller Teilaufwände.
I.d.R. wird ein gemischter Ansatz benutzt!
258
4.1 SchätzverfahrenÜberblick
KommentareAnmerkung:
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 genauerformulieren, 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 derAnforderungen notwendig, da letztere bereits hohe Kosten verursacht.
Praxis: oft sind die Kosten statt der Anforderungen fix.
259
4.1 SchätzverfahrenÜberblick
XXFunction Point
XXCocomo
3) Fortgeschrittene Methoden
XXDrei-Punkt/Zeit-Schätzung (bottom-up)
XXXInformelle Expertenschätzung (top-down und bottom-up)
(X)*
(X)*
(X)*
weitere Detaillierung (Durchführungsphase)
(X)*
(X)*
(X)*
Detaillierte Schätzung (Planungsphase)
XDelphi-Methode(top-down)
X
X
Grobe Schätzug(vor & während Startphase)
Schätzungen während den Projektphasen
2) Expertenschätzungen
Prozentsatzmethode
Multiplikatormethode
1) Analogieschätzungen
X Methode kann in dieser Phase eingesetzt werden(X)* nur für ausgewählte Module
Schätzmethoden
260
4.1 SchätzverfahrenAnalogieverfahren
AnalogieverfahrenKlasse: VergleichsverfahrenCharakteristika:
basiert auf Aufzeichnungen von Ist-Werten vergleichbarer, abgewickelter Projektedesselben Unternehmens;sorgfältige Kostenanalysen abgeschlossener Projekte liefern benötigte Informationen(“Erfahrungsmaterial”);Ist-Werte werden mit entsprechenden Korrekturfaktoren multipliziert.
besonders geeignetwenn neues System zum Großteil aus existierenden Komponenten besteht und/oderAnalogien zu ähnlichen Bauteilen hergestellt werden können;im Anfangsstadium eines Projektes;
261
4.1 SchätzverfahrenAnalogieverfahren
Dazu: Strukturvorschlag für eine Projekt-Erfahrungsdatenbank(Cost-Database):
Projektkurzbeschreibung:Name, Beginn-, Ende-Datum, FachgebietAufgabenstellung (Neuentwicklung, Wartung)Arbeitspakete (Leistungsbeschreibung)Ergebnisse:Anzahl der Anweisungen (Befehle, Konstante, LOC)Anzahl A4-Seiten (je Projekt-, Produktdokumentation)Anzahl der Module, durchschnittliche ModulgrößeAnzahl der Fehler (je Fehlerart)
262
4.1 SchätzverfahrenAnalogieverfahren
AnalogieverfahrenAufwand:Anzahl Personenmonate, Anzahl Mitarbeiter (je Qualifikation)Anzahl der Rechenstunden für die EntwicklungVerteilung der Personenmonate/Rechenstunden im VerlaufAufwand pro Fehler (je Fehlerart und Bearbeitungsart)Eingesetzte Hilfsmittel für
Entwerfen,Implementieren, Planen, Dokumentation.
Umgebungsbedingungen, Randbedingungen, ErkenntnisseBetriebssystem, Einflüsse durch Organisation, RechenzentrumSchätzabweichungsanalyse und DokumentationKlare Kennzahlen, z. B. Kosten pro Personenmonat,...Besonderheiten des IS-technischen Lösungsweges
263
4.1 SchätzverfahrenAnalogieverfahren
AnalogieverfahrenEinfluß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
264
4.1 SchätzverfahrenAnalogieverfahren
Ablauf des Analogieverfahrens (Multiplikatormethode):1. Risikoanalyse aufgrund der Einflußfaktoren:
Risikoklasse in % = (vorhandener Skalawert / max. Skalawert) x 1002. 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
3. Berechnung des Personen-Monat-Aufwandes PM(P0) pro Paket mit Hilfe der Werte aus der Cost-Database, z. B. unter Einsatz der Delphi Methode.
4. 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 nurbeschränkt brauchbar.
265
4.1 SchätzverfahrenProzentsatzverfahren
Prozentsatzverfahren (Extrapolation) :Klasse: KennzahlenverfahrenCharakteristikum:
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 durchExtrapolation die Aufwendungen für neue Projekte geschätzt.
Voraussetzungen zur Anwendung des Prozentsatzverfahrens:möglichst umfassende Vergangenheitswerte (dokumentiert); das verwendeteExtrapolationsverfahren muß in der Lage sein, zufällige Schwankungen einer Zeitreihe zuglätten;weitgehende Stabilität der UmweltbedingungenVorgehensmodell: Wasserfallmodell
266
4.1 SchätzverfahrenProzentsatzverfahren
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
267
4.1 SchätzverfahrenProzentsatzverfahren
Beispiel einer möglichen Aufteilung der Projektzeit auf einzelnePhasen der Projektabwicklung:
(“Planung”)
(“Requ.Analyse”)
(“Entwurf”)
268
4.1 SchätzverfahrenProzentsatzmethode
886100Summe
186
310
204
133
53
Aufwandsverteilung in Personentagen
21
35
23
15
6
Aufwandsverteilung in %
Systemintegration/-test
Kodierung/Modultest
Programmentwurf
Systementwurf
Studie
Phase
269
4.1 SchätzverfahrenDelphi-Verfahren
Delphi-VerfahrenKlasse: VergleichsverfahrenCharakteristikum: 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 werdengegenseitig bekanntgegeben, damit Resultate diskutiertund ggf. korrigiert werden können
270
4.1 SchätzverfahrenDelphi-Verfahren
Ablauf des Standard-Delphi-Verfahrens:1. Der Projektleiter schildert jedem Experten das Projektvorhaben und übergibt ihm
ein Formular, auf dem die einzelnen Aufgabenpakete angeführt sind2. Jeder Experte füllt das Formular aus; dabei dürfen Fragen lediglich mit dem
Projektleiter besprochen werden3. Projektleiter analysiert die Angaben. Falls Schätzwerte eines Paketes stark von
einander abweichen, werden diese mit Kommentar auf neuem Formular erfaßt4. Das neue Formular wird erneut zur selbständigen Überarbeitung an die
Experten gereicht.5. Die Schritte 2-4 werden so lange wiederholt, bis die gewünschte Annäherung
der Ergebnisse erreicht ist, oder der Projektleiter die Ergebnisse akzeptiert6. Der Durchschnittswert der letzten Überarbeitung der Ergebnisse aller
Aufgabenpakete stellt das endgültige Schätzergebnis dar.
271
4.1 SchätzverfahrenDelphi-Verfahren
Ablauf des Breitband-Delphi-Verfahrens1-3) Schritte 1-3 wie Standardverfahren, mit dem Zusatz, daß vor dem Ausfüllender Formulare eine Sitzung einberufen wird, in der alle Experten unter derModeration des Projektleiters über die zu erstellende Schätzung diskutieren
4. Der Projektleiter beruft eine Sitzung ein, in der die Teilnehmer über die zurückerhaltenen Formulare diskutieren
5. Die Experten überarbeiten ihre Ergebnisse selbständig und übergeben diesedem Projektleiter
6. Die Schritte 2-5 werden solange wiederholt, bis die gewünschte Annäherungerreicht ist, oder der Projektleiter die Ergebnisse akzeptiert
7. Der Durchschnittswert der letzten Überarbeitung der Ergebnisse allerAufgabenpakete stellt das endgültige Schätzergebnis dar.
Anmerkung: Kostenverantwortung liegt beim Projektleiter!
272
4.1 SchätzverfahrenDrei-Zeiten-Verfahren
Drei-Zeiten Verfahren (“Beta-Methode”)Charakteristikum: für jede Tätigkeit wird derenoptimistische-, häufigste und pessimistische Dauer geschätzt
273
4.1 SchätzverfahrenDrei-Zeiten-Verfahren
Drei-Zeiten-Verfahren (“Beta-Methode”)Hauptanwendung: bei stark innovativen Verfahren, bei welchen Aufwände nurungenau bestimmt werden können.Berechnungsbeispiel:
Tätigkeit OD HD PD MD A Erstellen der Vorstudie 3 8 10 7,5 B Erstellen des Konzeptes 8 13 15 12,5 C Erstelen des Pflichtenheftes 6 10 22 11,3 D Erstellen der Detailstudie 10 17 22 16,7 E Realisieren 12 22 26 21 F Testen 9 18 32 18,8 G Einführen 10 10 14 12,7 100,5
274
4.1 SchätzverfahrenDrei-Zeiten-Verfahren
6)(Re4 schPessimistialistischchOptimistis ++Gewichteter
Schätzwert (PERT) =
6chOptimistisschPessimisti −
=Standardabweichung ** für jeden Schätzwert
∑= )tan( 2hungdardabweicSGesamtunsicherheit
275
4.1 SchätzverfahrenWork Breakdown Structure
Work Breakdown Structure (WBS) / ProjektstrukturplanHierarchische Darstellung aller (Teil-) Ergebnisse, die zur Erzielung des Projektergebnisses notwendig istStrukturierte Beschreibung der relevanten Arbeitsschritte(basierend auf Ergebnismustern)Aufgliederung der Aufgaben zur Zuweisung von VerantwortlichkeitenBasis für Schätzung, Budgetierung, Mitarbeiterzuweisung und auch KontrolleHistorisch stark am „Produkt“ (= Endsystem) ausgerichtet, jetzt zunehmend mehr am Prozess der Erstellung
276
4.1 SchätzverfahrenWork Breakdown Structure
Die WBS istein Mittel, ein Projekt graphisch in Teile zu zerlegen und darzustellenkein Terminplankeine Abbildung der Projektorganisation
Verschiedene Gliederungsprinzipienfunktionsorientiert: z.B.: Funktionsblöcke - Teilfunktionen -Einzelaufgabenphasenorientiert: z.B.: Phasen - Fachgebiete - Verantwortlichkeitenobjektorientiert: z.B.: Objekte/Blöcke - Funktionen
Meist werden Mischformen verwendet:(z.B.: erste Ebene phasenorientiert, ab zweiter Ebene funktionsorientiert)
277
4.1 SchätzverfahrenWork Breakdown Structure
Aufbau der WBStop-down: Projekt in Teile zerlegenbottom-up: einzelne Aufgaben zu Blöcken zusammenfassenkombiniert: Grobstrukturierung definieren, Aufgaben zuordnen und Blöcke definieren
Jede Vorgehensweise hat ihre Vor- und NachteileWelche Methode gewählt wird, hängt letztendlich von den verantwortlichen Projektmitarbeitern ab
278
4.1 SchätzverfahrenFunction – Point – Verfahren
Function - Point – VerfahrenAlan Albrecht, IBM 1981Ziel: Messung Datenflusskomplexität
Größe: Anzahl der DatenflussschnittstellenDiversität: DatenflussartenVernetzung: Gemeinsame Datenquellen/-senken
Verfahren:Analyse aus Sicht der SystemumgebungMessung über funktionale Schnittstellen
- Externe Eingabe- Externe Ausgabe- Externe Anfrage- Interne Logische Dateien- Externe Logische Dateien
Systemfunktionen werden gezählt und bewertetBewertung in sog. Funktionspunktenwerden in Personenmonate umgerechnetMethode ist gut anwendbar, weil sie funktionsorientiert arbeitetFunktionen des geplanten Systems müssen vollständig beschrieben sein (Pflichtenheft)
279
4.1 SchätzverfahrenFunction – Point – Verfahren
Function - Point – VerfahrenBasis 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 FaktorenBerechnen der Function Points, d.h. Berechnung des bewertetenFunction PointsErmitteln der Projekt- Aufwands, d.h. mit Hilfe von historische Daten
280
4.1 SchätzverfahrenFunction – Point – Verfahren
Unbewertetete Function Points Einflußfaktor
Funktionen Einflußfaktoren
MM
FP
Function Pointsdes Projekts als Basismaßzahl für Funktionalität
Gesamtprojekt-aufwand (laut Erfahrungskurve)
Produkt-/Projektanforderungen
Klassifizierung(einfach, mittel, komplex)
Bewertung derEinflußfaktoren
Bewertete Function Points
Abgeschlossene Projekte (bewertet durch Function Point Analyse)
Aufw
and
281
4.1 SchätzverfahrenFunction – Point – Verfahren
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), TransaktionsrateBenutzerfreundlichkeit
Berechnung der bewerteten Function PointsErmittlung des mittleren AufwandsBerechnung des spezifischen Aufwands
Prozentualer Abschlag für durchlaufeneProjektspezifische Korrektur-Faktoren, z.B.
Stabilität der Anforderungen, Erfahrung und Produktivität des Teams, Tools und Methoden, WiederverwendungSpezielle Risiken (Verfügbarkeit der Teammitglieder, Zugang zu Informationen, Zulieferungen Dritter)
Aktualisierung der empirischen Daten
282
4.1 SchätzverfahrenFunction – Point – Verfahren
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
283
4.1 SchätzverfahrenFunction – Point – Verfahren
GrundformelZahl der Eingabefunktionen/-daten (EF)Zahl der Ausgabefunktionen/-daten (AF)Zahl der Datenbestände (DB), d.h. intern gespeicherter Dateneinheiten/logische DateienZahl der Referenzdaten (RD), d.h. Schnittstellen zu externen SystemenZahl 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*AFmit a,b,..., e Gewichtungsfaktoren
284
4.1 SchätzverfahrenFunction – Point – Verfahren
Ein-/Ausgabe
Eingabe bzw. Ausgabe von Umgebung an SystemLogisch zusammenhängendBenutzer- oder Kontrolleingabe bzw. -ausgabeEingabe: Verändert /erweitert internen DatenzustandAusgabe: Erhält Datenzustand, ist unabhängig von Benutzereingaben
287
4.1 SchätzverfahrenFunction – Point – Verfahren
Datenbestände/Referenzdaten - logische Dateien
Benutzer- oder Kontrolldaten, die von Anwendung betreut oder gewartet wirdGruppe von intern bzw. extern verarbeiteter DatenLogisch zusammenhängendInterne: Erzeugt, verwaltet oder bearbeitetExterne: Von Außen zur Verfügung gestellt
290
4.1 SchätzverfahrenFunction – Point – Verfahren
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.Logisch zusammenhängendVon Benutzer oder SystemumgebungEingabe löst sofortige Reaktion ausÄndert Interne Logische Daten nicht
293
4.1 SchätzverfahrenFunction – Point – Verfahren
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 bestimmenDiese 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
294
4.1 SchätzverfahrenFunction – Point – Verfahren
Einflußfaktoren:EF1: Verflechtung mit anderen Verfahren 0 – 5EF2: Dezentrale Datenverwaltung und Datenhaltung 0 – 5EF3: Transaktionsrate und Antwortzeitenverhalten 0 – 5EF4: Transaktionslogik:
EF4.1: Schwierige Rechenoperationen 0 – 10EF4.2: Umfangreiche Kontrollverfahren 0 – 5EF4.3: Anzahl der Ausnahmeregelungen 0 – 10EF4.4: Schwierige und komplexe Logik 0 – 5
EF5: Wiederverwendung in anderen Verfahren 0 – 5 (10%,20%,...,50%)EF6: Datenbestandskonvertierungen 0 – 5EF7: Benutzerbedienung, Usability 0 – 5
295
4.1 SchätzverfahrenFunction – Point – Verfahren
Vorgehen:Einfluß der Systemkomplexität durch Berücksichtigung von 7Komplexitä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 PointsBFP = UFP * EF
... somit können Einflußfaktoren +/-30% das Ergebnis beeinflußen
297
4.1 SchätzverfahrenFunction – Point – Verfahren
Berechnung des Einflußgrades und bewerteten Function Points:
298
4.1 SchätzverfahrenFunction – Point – Verfahren
Ermittlung des AufwandsDie ermittelten Function-Points (Korrelationskurve) müssen nun in Aufwand (Personentage) umgerechnet werdenAblesen des voraussichtlichen Aufwandes direkt aus der Function -Point –Kurve/TabelleDie 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
299
4.1 SchätzverfahrenFunction – Point – Verfahren
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.
300
4.1 SchätzverfahrenFunction – Point – Verfahren
Voraussetzungen für die Methodenanwendung„brauchbare“ Aufwandskurve als AusgangsbasisNachkalkulation bzw. Kalibrieriung, Entwicklung einer eigenen Aufwandskurve (ca. 100 Projekte; Nachkalkulation ist sehr teuer)iterative Projektplanung (FP-Methode erst in der Spezifikationsphase aussagekräftig einsetzbarStandardisierung des Schätzverfahrens.
Zählweise der Ein- / AusgabenBewertung von Einflußfaktoren
Methodenhandbuch schreiben
301
4.1 SchätzverfahrenFunction – Point – Verfahren
Vorteile der Function Point AnalyseUnabhängig von der Implementierungsspracheleicht erlernbarmit wenig Aufwand anzuwendenEinzelschätzungen sind gut nachvollziehbarunternehmensspezifisch anwendbargute Anwenderkriterieniterativ anwendbar, d.h. zunehmende Detaillierung
302
4.1 SchätzverfahrenFunction – Point – Verfahren
Nachteile der Function Point AnalyseHohe Unsicherheit bei der Berechnung der Function Points
Komponenten einer Anwendung oft schwer zu bestimmenGewichtungsfunktionen allein aus Erfahrung abgeleitetBestimmung der Gewichtungsfaktoren schwierigEinflußfaktoren beliebig wählbar
Wachsende Unsicherheit, je mehr der Schwerpunkt des Systems in einem Bereich (z.B. bei Berechnungsfunktionen) liegtWiederverwendung (z.B. von Code) und Zulieferung werden nicht berücksichtigtschwierige Abbildung der Schätzergebnisse auf einen Netzplansummarischer Ansatz korrespondiert nicht direkt mit konkretem Problem
303
4.1 SchätzverfahrenFunction – Point – Verfahren
0,0050,00
100,00150,00200,00250,00300,00
0200400600 800100
0120
0140
0160018002000
MM
FP
Umrechnungs-Kurve(Erfahrung aus vorangegangenen Projekten)
Function Point Wert
SchätzklausurprojektspezifischeKorrekturfaktoren
geschätzter Projekt-aufwand
durchschnittlicherAufwand
Kontrolle durch andere Schätzmethode !
304
4.1 SchätzverfahrenFunction – Point – Verfahren
Nicht berücksichtigt:Stabilität der AnforderungenErfahrung des Teams
fachlich bzgl. Aufgabengebiet (Domäne)technisch bzgl. Entwicklungstechnologie
Produktivität des TeamsTeamgröße und -Struktur, mehrere Standorte, ...Termindruck, Parallelisierung der Arbeiten
Tools und MethodenWiederverwendungs-Anteilespezielle Risiken
Verfügbarkeit des Personals und von RessourcenZugang zu InformationenZulieferungen Dritter...
305
4.1 SchätzverfahrenFunction – Point – Verfahren
FazitUnterstützung der Methode bei Bestimmung der FunktionalitätEinbeziehung von und somit auch bessere Nachvollziehbarkeit durch Personen ohne fundiertes technisches WissenHohe Unsicherheit bei der BestimmungWeiterentwicklungen:
Feature Points (besser geeignet, wenn Schwerpunkt in einem Bereich liegt)Object Points…
306
4.1 SchätzverfahrenCoCoMo
CoCoMoVerfahren: Constructive Cost Modeling (CoCoMo)Entwickler: Barry Boehm (1981)Schätzung des Umfangs der Codezeilen (Korrelationskoeffizienz)Charakteristikum: beruht auf einer Kombination von Gleichungen, statistischenModellen, 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
307
4.1 SchätzverfahrenCoCoMo
Ausgangspunkt: Das Modell basiert auf der Analyse von Daten aus vergangenen ProjektenDas 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 AufwandKLOC Kilo Lines of CodeC1, 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)
308
4.1 SchätzverfahrenCoCoMo
BestimmungsgrößenAnzahl 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)
309
4.1 SchätzverfahrenCoCoMo
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ßparameterEntwicklungsphasen werden nicht differenziert
Erweitertes Modell (“Detailmodell”): berücksichtigt 15 Einflußfaktoren sowiedie Abweichungen der anteilsmäßigen Aufwände der einzelnen Entwicklungsphasen.
310
4.1 SchätzverfahrenCoCoMo
Projektarten in CoCoMo:einfache SW-Projekte (Organic mode):
kleines, gut harmonierendes Team arbeitet in bekannter Umgebung, Teammitgliederhaben 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 darProduktgröß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
311
4.1 SchätzverfahrenCoCoMo
Grundformel zur Ermittlung des Entwicklungsaufwandes:E = C1 * KDSI C2 * ∏ Ei
wobeiC1 und C2 hängt von de Projektart und vom Projektmodell abEi Einflußfaktoren mit i= 1 ..15 (“Kostentreiber”), wobei Ei = 1 im Grundmodell
Entwicklungszeit:TDEV = C3 * EC4 mit
wobeiC1’ im GrundmodellC1’’ sonst
312
4.1 SchätzverfahrenCoCoMo
CoCoMo-GleichungenAufwand:
OM: PM = 2,4 * (KLOC)^1,05SDM: PM = 3,0 * (KLOC)^1,12EM: PM = 3,6 * (KLOC) ^1,2
Entwicklungszeit:OM: TDEV = 2,5 * (PM)^0,38SDM: TDEV = 2,5 * (PM)^0,35EM: TDEV = 2,5 * (PM)^0,32
Rechenbeispiel: 10.000 LOCSemi 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
313
4.1 SchätzverfahrenCoCoMo
TDEV .. benötigte Entwicklungszeit in Monaten:organic: TDEV = 2.5 * E 0.38semidetached: TDEV = 2.5 * E 0.35embedded: TDEV = 2.5 * E 0.32Beispiele zu Produktgrößen, Personenzahl, Entwicklungszeit:
315
4.1 SchätzverfahrenCoCoMo
Graph zur geschätzten Projektdauer in Abhängigkeit von der Projektgröße (Kurve für alle drei Projektklassenähnlich):
316
4.1 SchätzverfahrenCoCoMo
COCOMO Kostentreiber:Kategorien: very low / low / nominal / high / very high / extra highAttribute
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
317
4.1 SchätzverfahrenCoCoMo
KostenfaktorDie Kostenfaktoren gehen multiplikativ in die Berechnung des Aufwandes ein:
E’ = E * ∏ cdriverFü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=
322
4.1 SchätzverfahrenCoCoMo
Berechnungsbeispiel für das Zwischenmodell:Ausgangspunkt:
komplexes Projektmit geschätzten 60 KDSI
Aufwandsschätzung:E0 = 3.6 * 601.20 = 490 PMTDEV = 2.5 * 490 0.32 = 18 MonateN = 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
323
4.1 SchätzverfahrenCoCoMo
Kommentar zur benötigten Personenzahl:Vorsicht: N = E/TDEV gibt nur einen groben Durchschnittswert, da die Anzahl imProjektverlauf schwankt!Vorschlag von Putnam (1978): der optimale Mitarbeiterstand folgt einer Rayleigh-Kurve:Beispiele zu Rayleigh-Kurven:
324
4.1 SchätzverfahrenCoCoMo
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 sieaußerhalb des Modells; ihr Aufwand wird daher zu den restlichen vier Phasenaddiert.
325
4.1 SchätzverfahrenCoCoMo
Tabelle zur Illustration des gewichtigen Anteils der (subjektiven) Schätzungen der Einflußparameter am Gesamtergebnis:
326
4.1 SchätzverfahrenCoCoMo
Anmerkungen zu COCOMOfü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 Parameterstarke Umgebungsabhängigkeit, viele subjektive Elemente
327
4.1 SchätzverfahrenCoCoMo
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 ...
328
4.1 SchätzverfahrenCoCoMo
FazitEinsatz für Grobschätzungen nach Abschluss der AnalysephaseVerbesserung der Ergebnisse bei Aufteilung des Gesamtprojekts in kleinere Einzelprojekte, die einzeln geschätzt werdenErfahrungen zeigen Abweichungen der Schätzungen vom tatsächlichen Aufwand um den Faktor 4Weiterentwicklungen:
Ada COCOMOCOCOMO II
329
4.1 SchätzverfahrenCoCoMo
CoCoMo IIBeobachtung:
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
331
4.1 SchätzverfahrenCoCoMo
CoCoMo II ModellgleichungenParameter:
Aufwandsfaktor EM aus Einzelfaktoren EMi
Skalierfaktor B aus Einzelgewichten Wi
Grundfaktor AZeitplanfaktor SCED%
GleichungenSkalierfaktor: B = 0,91 + 0,01 * Summe(Wi)Grundaufwand: PMGrund = A * Größe(FPA) ^ BAufwandsfaktor: EM = Produkt(EMi)Gesamtaufwand: PMGesamt = EM * PMGrund
Laufzeit: TDEV = [3,67 * PMGesamt ^(0,28+0,2*(B-1,01))] * SCED%/100
332
4.1 SchätzverfahrenCoCoMo
CoCoMo II - Aufwand
Generell:Auswirkung des exponentiellen Faktors Prozess
- Faktor > 1- “Diseconomy of Scales”
333
4.1 SchätzverfahrenCoCoMo
Komplexität und ProduktivitätZiel Schätzung:
Bestimmung RealisierungsaufwandBestimmung Realisierungszeit
Produktivität:Bestimmung Mitarbeiterzeit/SystemeinheitBerechnung: „Aufwand = Produktivität * Größe“Beobachtung:
- Durchschnittl. Produktivität: 5 FP/PM- IS-Produktivität: 8 FP/PM- ES-Produktivität: 4 FP/PM
334
4.1 SchätzverfahrenCoCoMo
Komplexität und Produktivität
Produktivität beeinflußt:Durch administrativen AufwandDurch personellen AufwandDurch Abstimmungsaufwand
335
4.1 SchätzverfahrenCoCoMo
Realisierungsaufwand und LaufzeitZiel Schätzung:
Bestimmung RealisierungsaufwandBestimmung Realisierungszeit
Intensität:Bestimmung „Projektlaufzeit/Aufwand“Berechnung: „Laufzeit = Intensität * Aufwand“Beobachtung:
- Laufzeit polynomial in Aufwand- Laufzeitvorgaben beeinflussen Aufwand- Maximale Laufzeitverkürzungen: 70-75%
336
4.1 SchätzverfahrenCoCoMo
Realisierungsaufwand und Laufzeit
Laufzeit beeinflusst Aufwand:Durchschnittliche Laufzeit minimiert AufwandZusätzlicher Aufwand erlaubt Kürzung (70%)Erhöhte Laufzeit verringert Aufwand nicht
337
4.1 SchätzverfahrenCoCoMo
AufwandsfaktorenProjektparameter
Parameter wirken linear auf AufwandArten 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
338
4.1 SchätzverfahrenCoCoMo
SkalierfaktorenProzessparameter
Faktoren wirken exponentiell auf Aufwand/LaufzeitArten 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
339
4.1 SchätzverfahrenCoCoMo
Vorteile von COCOMOGeeignet für schnelle, grobe Schätzungen der anfallenden KostenGute 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 COCOMOWesentliche Einflussgrößen auf den Projektaufwand bleiben unberücksichtigt:
notwendige EntwicklungshardwareEinsatz moderner CASE-Toolsspezielle Fähigkeiten der MitarbeiterQualität des ManagementQualität der Benutzerschnittstelle
Vergleichbarkeit mit bereits durchgeführten Projekten nicht immer gegebenviele im voraus zu bestimmende Einflussfaktoren
340
4.1 SchätzverfahrenZusammenfassung
ZusammenfassungDrei 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
341
4.1 SchätzverfahrenZusammenfassung
Bedeutung von Schätzungen für das ProjektmanagementBasis für alle wichtigen ProjektentscheidungenAlle „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üssenErgebnisse einer Schätzung (Aufwand und Zeit) ist politisch meist zu hoch/zu spät, Korrekturen müssen strukturiert und durchdacht angegangen werdenReview durch Kollegen/Experten ist unabdingbar
343
4 Schätzverfahren und Projektplanung4.2 Projektplanung
Variablen mit Einfluss auf den EntwicklungsprozessZielvariablen
Beschreiben die Zielsetzung während der System-Entwicklung (e.g. minimale Entwicklungszeit, maximale Qualität, minimale Kosten)
KontrollvariablenBeschreiben die Einflussfaktoren, die vom Projekt-Management aktiv beeinflusst werden können (z.B. verwendete Tools, Projekt-Organisationsform,
Unkontrollierbare VariablenBeschreiben 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)
344
4 Schätzverfahren und Projektplanung4.2 Projektplanung
etc.
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)
Schätzungen sind zu optimistisch und basieren nicht auf Erfahrungen
Niemand hat geprüft, ob die zugrunde liegenden Personaleinsatzanforderungenerfüllt werden können
Pläne werden nicht mit Betroffenen abgestimmt
Das Senior Management hält an den Wunsch fest, obwohl eine realistischePlanung andere Termine ergeben würde
Pläne basieren auf unrealistischen Wunschterminen
Pläne verlangen zu viel in zu kurzer Zeit
Typische Planungsfehler
347
4.2 Projektplanung Übersicht Planungsdokumente
ÜÜEArbeitspaketbeschreibung
ÜÜEProjektstrukturplan
Kosten-planung aufstellen
Ü
Aktivitäten-zeitplan aufstellen
Ü
Größen-, Aufwands-, und Kosten-schätzungen durchführen
Ü
Projekt-struktur-plan erstellen
E*Anforderungsspezifikation
E*
E*
E*
E*
Projekt-umfang und Meilen-steine festlegen
Planungsschritte
Projektspezifisches Vorgehensmodell
Projektorganisation
Projektdefinition
Projektziele
Dokumente
348
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.A: (Anpassen) Das Dokument wird an die Projektbedürfnisse angepasst bzw. ergänzt.
4.2 Projektplanung Übersicht Planungsdokumente
A
E
Kosten-planung aufstellen
A
E
Ü
Aktivitäten-zeitplan aufstellen
A
E
Größen-, Aufwands-, und Kosten-schätzungen durchführen
A
Projekt-struktur-plan erstellen
EProjektplan
E
Projekt-umfang und Meilen-steine festlegen
Planungsschritte
Kostenplan
Aktivitätenzeitplan
Schätzdokument (Größen, Aufwand,Kosten)
Meilensteinplan
Dokumente
349
4 Schätzverfahren und Projektplanung4.2 Projektplanung
Vorbedingungen für effektive ProjektkontrolleDie Projektleitung muss sich über die Ziele des Systems im Klaren seinDie 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 habenDie Projektleitung muss über ein konzeptuelles Modell des zu kontrollierenden Systems verfügenMit anderen Worten, die Projektleitung muss wissen, wovon die einzelnen Kontrollvariablen abhängen und in welcher Weise sie einander gegenseitig beeinflussen
351
4 Schätzverfahren und Projektplanung4.2 Projektplanung
Planungstechniken Ziele:
Überblick über den ProjektablaufVorbereitung der ProjektdurchführungZeitschätzung und TerminbestimmungPlanung 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: WiederholtProjektinitiierungProjektdurchführung: Neuplanung bei
- Detaillierung Produktstruktur- Änderung Terminlage- Änderung Personallage- Änderung Ressourcenlage
353
4 Schätzverfahren und Projektplanung4.2 Projektplanung
ProjektplanFunktion: beschreibt aktuellen Planungsstand (Soll-Werte)
Vorbereitung RessourcenbereitstellungVorbereitung Kontrolle/Steuerung
Bestandteile von ProjektplänenZusammenfassung mehrerer Vorgänge zu einer PhaseFestlegung 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):ProjektstrukturplanTerminplanPersonalplanRessourcenplan
Zusätzlich: Ist-Werte Projekt
354
4.2 ProjektplanungProjektstrukturplan
Projektstrukturplan oder Work Breakdown Structuresiehe auch AufwandsabschätzungZiel:
Erfassen der Abhängigkeiten im ProjektverlaufVorbereiten der Aufwands- und Zeitplan
Idee:Zerlegung des Projekts solange in Teilaufgaben, bis diese umsetzbar sindDie einzelnen umsetzbaren Teilaufgaben werden mit Meilensteinen für Beginn und Ende versehen (und deren Erreichung überprüft)
Istein Mittel, ein Projekt graphisch in Teile zu zerlegen und darzustellenkein Terminplankeine Abbildung der Projektorganisation
356
4.2 ProjektplanungProjektstrukturplan
Typen von ProjektstrukturplänenObjektorientierter Projektstrukturplan
Definition der Aufgabenpakete nach der technischen Struktur des Projektesz.B.: Objekte/Blöcke - FunktionenHausbau: Keller, Erdgeschoss, Dachgeschoss
Funktionsorientierter ProjektstrukturplanDefinition nach Entwicklungsfunktionen (Bereichen)z.B.: Funktionsblöcke - Teilfunktionen - EinzelaufgabenHausbau: Rohbau, Ausbau
Ablauforientierter ProjektstrukturplanDefinition gemäß Entwicklungsprozeßz.B.: Phasen - Fachgebiete - VerantwortlichkeitenHausbau: Planung, Umsetzung
Meist werden Mischformen verwendet(z.B.: erste Ebene phasenorientiert, ab zweiter Ebene funktionsorientiert)
357
4.2 ProjektplanungProjektstrukturplan
Projektstrukturplan Projektprozessauswahl
Auswahl von Phasenkonzept oder Vorgehensmodellz. B. IT-Projekt im öffentlichen Bereich nach V-ModellTailoring: projektspezifische Anpassung und Detaillierung
Erstellung: Instantiierung ProzessmodellProduktstruktur: Erfassen/Festlegen der Teilprodukte und ihrer AbhängigkeitenAblaufstruktur: Festlegen der Vorgänge abhängig von der Produktstruktur
Elemente:Phasen (entsprechen Prozessphasen)hierarchische Strukturierung der AufgabenVorgänge (konkretisieren Prozessaktivitäten)Meilensteine (entsprechen Prozessereignissen)
358
4.2 ProjektplanungMeilensteine
Meilensteine:Ziel: Ermöglichen die Projektkontrolle
Gezieltes Erkennen der ProjektverzögerungRechtzeitiges Erkennen der Projektverzögerung
Entsprechen synchronisierenden ProjektereignissenProjektstart, Projektende,Vorgangsende
Daher: Geknüpft an Erstellung eines (Teil)ProduktsDichte: Relativ zur Gesamtlaufzeit: Abstände bis zu vier WochenGleichverteilung: ungefähr gleiche AbständeEigenschaften:
Überprüfbarkeit: Objektive Kriterien- „Systemarchitektur liegt vor“- Testdrehbuch mit 10 Testfällen liegt- Nicht: „Implementierung zu 80% abgeschlossen“
360
4.2 ProjektplanungProjektablaufplan
ProjektablaufplanAbhängigkeiten
zwingende Folgeempfehlende Folgefreie Folge
Verschiedene Ablaufplänen mit unterschiedlichem InformationsgehaltLinearpläne Netzpläne
361
4.2 ProjektplanungDarstellungen
Projektablaufplan - DarstellungstechnikenListungstechnik
nur bei kleinen (Linear-)Plänen sinnvoll einsetzbar
Terminlisten: Workpackages (Vorgangslisten), von außen vorgegebene Termine
Netzplantechnik, zusätzlich technologische Abhängigkeitenz. B.
- Vorgangspfeilnetzplan- Vorgangsknotennetzplan- Ereignisknotennetzplan
Balkendiagrammtechnikzusätzlich je Teilaufgabe Start- und Endtermin bzw. Dauerz. B.
- Gantt-Diagramm- PLANNET-Diagramm
Vernetzte Balkenplänezusätzlich einfache Abhängigkeiten zwischen Vorgängen
362
4.2 ProjektplanungTerminlisten
TerminlistenEnthält Liste der Aktivitäten bzw. Vorgänge
Zu jedem Vorgang wird die Liste der beteiligten oder verantwortlichen PersonenangegebenWeiter wird (meist) eine Deadline für jeden Vorgang definiertZusätzlich kann eine Liste der Meilensteine existieren bzw. eine separate Liste von außen vorgegebener wichtiger Termine (Deadlines)
363
4.2 Projektplanung Netzplantechnik
NetzplantechnikenZiel
Terminplanung für Vorgänge/EreignisseBerücksichtigung der Abhängigkeiten (evtl. Varianten)
Kennzeichenumfassendes Planungsinstrument für komplexe Projektebietet übersichtlichen Überblick über den Projektablauf, inklusive der eindeutigen Darstellung derAbhängigkeiten einzelner Vorgänge im Ablaufermöglicht genaue Zeitschätzung bzw. Terminfestlegung für den Gesamtablauf sowie für einzelne VorgängeErkennen der zeitintensivsten Ablauffolge: “kritischer Weg”ermöglicht relativen Vergleich der Konsequenzen von Terminen, Kosten und Einsatzmitteln verschiedener Planungsvariantenfö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.
364
4.2 Projektplanung Netzplantechnik
NetzplantechnikenNetzplantechnik ist geeignet für:- Strukturplanung- Zeitplanung- Einsatzmittelplanung- Kostenplanungbewährte Arten von Netzplänen:- CPM: Critical Path Method- PERT: Program Evaluation and Review Technic- MPM: Metra-Potential-Methodzahlreiche Softwareprodukte unterstützen den Einsatz der Netzplantechnik; oft: Zusammenfassung verschiedener Arten von Netzplänen; daher: Vorsicht auf Konsistenz!
365
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 Dauerggf. der direkten Nachfolgetätigkeiten
Erstellung der Tätigkeitsliste (auch “Vorgangsliste”)Beispiel siehe nächste Folie
366
4.2 Projektplanung Netzplantechnik – CPM
Beispiel:Tätigkeiten mit Zeitangaben und Vorgängerrelationen
367
4.2 Projektplanung Netzplantechnik
NetzplantechnikenNetzplanvarianten:
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.
368
4.2 Projektplanung Netzplantechnik
Vorgangsknoten Netzpläne - Activity on Node (AoN)Knoten: enthalten Vorgänge, Vorgangsnummern und DauernKanten: beschreiben die Anordnungsbeziehungen zwischen den Vorgängen
Vier Anordnungsbeziehungen zwischen VorgängenNormalfolge (Ende-Anfang Beziehung)Anfangsfolge (Anfang-Anfang Beziehung)Endfolge (Ende-Ende Beziehung)Sprungfolge (Anfang-Ende Beziehung)
370
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
VorgangsknotennetzplanVorgangsknotennetzplan 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ängigkeitena/A frühester/spätester Starttermin Projekte/E frühester/spätester Endtermin Projekt
Begriffe:Pfad (a1,...,am): Menge von Aktivitäten mit (ai, ai+1) ∈ RVorgänger V(a): { a‘ | (a‘, a) ∈ R }Nachfolger N(a): { a‘ | (a, a‘) ∈ R }
371
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
VorgangsknotennetzplanEin Netzknoten ist i.a. wie folgt aufgebaut:
FA - frühester Anfang FE - frühestes EndeSA - spätester Anfang SE - spätestes Ende
Subnetze: komplexe Netzknoten können aus Gründen der Übersichtlichkeit in Subnetze zerlegt werden
372
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
VorgangsknotennetzplanNormalfolge
Das Ende von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (EA: Ende-Anfang)
AnfangsfolgeDer Beginn von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (AA: Anfang - Anfang)
373
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
VorgangsknotennetzplanEndfolge
Das Ende von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (EE: Ende -Ende)
SprungfolgeDer Beginn von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (AE: Anfang -Ende)
374
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
TerminberechnungBerechnung 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
375
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
TerminberechnungBerechnung 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
376
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
TerminberechnungBerechnung Pufferzeiten p(a):
Zeit zwischen frühestem und spätestem AnfangZeit zwischen frühestem und spätestem Ende
Kritischer Pfad:Eine Aktivität mit Pufferzeit 0 ist eine zeitkritische AktivitätAll zeitkritischen Aktivitäten auf einem Pfad bilden einen kritischen PfadVerzögerung kritischer Aktivitäten führen zu Gesamtprojektverzögerungen
377
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen
380
4.2 Projektplanung Netzplantechnik - Vorgangsknotennetzplan
VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen
383
4.2 Projektplanung Netzplantechnik
Netzplantechnik umfasst folgende Schritte:Erstellen der Tätigkeitsliste aufgrund des ProjektstrukturplansErstellen des NetzplansBerechnen der VorgangszeitpunkteErmitteln der PufferzeitenErrechnen des kritischen WegesVerwendung des Netzplans als Basis von
Balkendiagrammen, z.B. Belegungsplan, EinsatzplanEinsatzmittel-Auslastungsdiagrammen, z.B. zwecks Bedarfsglättung
384
4.2 Projektplanung Netzplantechnik – CPM
CPM: Vorgangskantennetzplan / VorgangspfeilplanKnoten:
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
Zeitwert der Vorwärtsrechnung
Zeitwert der Rückwärtsrechnung
2
12 18
385
4.2 Projektplanung Netzplantechnik – CPM
CPM: Vorgangskantennetzplanoft werden Ereignisknoten auch folgendermaßen dargestellt
386
4.2 Projektplanung Netzplantechnik – CPM
CPM: Vorgangskantennetzplangerichtete 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
387
4.2 Projektplanung Netzplantechnik – CPM
Regel 1:Ein Vorgang kann erst beginnen, wenn alle vorangehenden Vorgängeabgeschlossen sind. Dabei fällt, mit Ausnahme des ersten Vorgangs, das Anfangsereignis mit dem Endereignis des vorangehenden Vorgangs zusammen.
388
4.2 Projektplanung Netzplantechnik – CPM
Regel 2:Müssen mehrere Vorgänge beendet sein, bevor ein weiterer Vorgang beginnenkann, so enden sie im Anfangsereignis des nachfolgenden Vorgangs.
Regel 3:Können mehrere Vorgänge beginnen, nachdem ein vorangehender Vorgangbeendet ist, so beginnen sie im Endereignis des vorangehenden Vorgangs.
389
4.2 Projektplanung Netzplantechnik – CPM
Regel 4: Haben zwei oder mehr Vorgänge gemeinsame Anfangs- und Endereignisse, so ist ihre eindeutige Kennzeichnung durch Einfügen von Scheinvorgängen zugewährleisten.
390
4.2 Projektplanung Netzplantechnik – CPM
Regel 5: Beginnen und enden in einem Ereignis mehrere Vorgänge, die nicht allevoneinander abhängig sind, so ist der richtige Ablauf durch Auflösung derUnabhängigkeiten mittels Scheinvorgängen darzustellen.
Regel 6:Innerhalb einer Folge von Vorgängen können beliebig viele Scheinvorgängeeingefügt werden. Sie dienen neben der logischen Verknüpfung auch derbesseren Übersicht.
391
4.2 Projektplanung Netzplantechnik – CPM
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 keineSchleifen auftreten.
392
4.2 Projektplanung Netzplantechnik – CPM
Beispiel: CPM NetzwerkTätigkeiten mit Zeitangaben und Vorgängerrelationen
394
4.2 Projektplanung Netzplantechnik – CPM
Beispiel: CPM Netzwerk - Bestimmung der frühesten Beginnzeiten
395
4.2 Projektplanung Netzplantechnik – CPM
Beispiel: CPM Netzwerk - Bestimmung der spätesten Beginnzeiten
396
4.2 Projektplanung Netzplantechnik – CPM
Beispiel: CPM Netzwerk - Bestimmung des kritischen Pfades
397
4.2 Projektplanung Netzplantechnik – CPM
Erstellen des Netzplans: Eintragen der logischen Abhängigkeiten zwischen TätigkeitenEintragen der geschätzten Dauer zu einzelnen Tätigkeiten
Errechnen der Zeitwerte und Bestimmung des kritischen Weges:Zeitwert der Vorwärtsrechnung: Beginn bei 0;dann: addieren der Zeiteinheiten nach der logischen Reihenfolge undEintrag in das linke untere Feld des Ereigniskreises;Bedeutung: Bestimmung der frühesten Ereigniszeitpunkte;
Zeitwert der Rückwärtsrechnung: vom Endereignis und dessen Zeitwert aus der Vorwärtsrechnung ausgehend:
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ßtbleiben soll.
399
4.2 Projektplanung Netzplantechnik – CPM
Berechnen der Vorgangszeitpunkte (“Tätigkeitszeitpunkte”):frühester Anfangszeitpunkt des Ereignisses: FAspätester Endzeitpunkt eines Vorganges: SEfrühester Endzeitpunkt eines Ereignisses: FEspätester Anfangszeitpunkt eines Vorganges: SA
Zweck: Berechnung der Pufferzeiten und Erstellen des Einsatz-Auslastungsdiagramms, z.B. zwecks Bedarfsglättung
401
4.2 Projektplanung Netzplantechnik – CPM
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) - Doder GP = SZ(j) - FZ(i) - DBedeutung: GP gibt an, wie lange ein Vorgang höchstens verlängert/verzögert werden kann, ohne daß der Endtermin beeinträchtigt wird.
402
4.2 Projektplanung Netzplantechnik – CPM
Freie Pufferzeit (FP):FP = FE(j) - FA(i) - Doder FP = FZ(j) - FZ(i) - DFreie Pufferzeit entsteht, wenn mehrere Vorgänge, die nicht alle zeitbestimmendsind, 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.
403
4.2 Projektplanung Netzplantechnik – CPM
Unabhängige Pufferzeit (UP):UP = FE(j) - SA(i) - DBedeutung: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 undb) der Vorgang muß den frühestmöglichen Endzeitpunkt einhalten können.weitere Kenngröße:Schlupf im Zustand i: SL(i) = SZ(i) - FZ(i)
405
4.2 Projektplanung Netzplantechnik – PERT
VorgangspfeilnetzplanProgram Evaluation and Review Technique (PERT)Eigenschaften:
Ereignisorientierter Netzplan ähnlich CPMBetont Projektzustände (Ereignisse); Ziel war die Verbesserung der Zeitschätzungenvon den Zustandsübergängen (Pfeile, i.a. beliebige Folgen von Vorgängen) ist lediglich die Dauer und Anordnungsbeziehung (AOB) von Interessewesentliches 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
406
4.2 Projektplanung Netzplantechnik – PERT
PERTAnnahmen:
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
407
4.2 Projektplanung Netzplantechnik – PERT
PERTBerechnung der mittleren Dauer (MD) als Erwartungswert aus den drei Schätzungen OD, HD und PD Näherungsgleichung:
MD = (OD + 4HD + PD)/6Angabe 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.
408
4.2 Projektplanung Netzplantechnik – PERT
PERTDa 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
409
4.2 Projektplanung Netzplantechnik – PERT
PERTAnwendung der Normalverteilung zwecks Berechnung:z = [PT(i) - FT(i)]/[δ2(FZ(i)]
Beispiel:festgelegter Endtermin: 22.4.2003Ermittlung aus dem Netzplan ergibt: FT = 29.4.2003Standardabweichung = 10 Tagez = [ (22.April) - (29.April)]/10 = -0.5Nachsehen in Formelsammlung zur Normalverteilung bei (-0.5) ergibt: Wahrscheinlichkeit von ca. 31%
412
4.2 Projektplanung Netzplantechnik
ZusammenfassungNetzplantechnik
Eingabe:- Projektstrukturplan- Terminvorgaben- Aufwandsschätzung (Zeitaufwände)
Ergebnis:- Meilensteinplan- Terminplan
Einschränkende AnnahmenAnnahme: Vorgangsdauer genau abschätzbarAnnahme: Ressourcen frei planbar
Konsequenz: Termin- und Ressourcenplanung verschränkt durchführen
413
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 ProjektfortschrittsAktivitäten werden in Balkenform aufgetragen
Die Länge des Balkens entspricht der Länge der AktivitätGraue 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” darAus Gantt-Diagrammen sind die Zusammenhänge der einzelnen Aktivitäten nicht ersichtlich
414
4.2 Projektplanung Balkendiagramm
Balkendiagramm (GANTT-Diagramm)Balkendiagramme:
vielseitige Verwendung;horizontale Achse: Zeitvertikale Achse: z.B.
- Sachmittel: “Belegungsplan”- Aufgaben: “Tätigkeitsplan”, “Projektfortschrittsplan”- Aufgabenträger: “Einsatzplan”
Erweiterungen:Balken können mit Wert beschriftet werden
z.B. Mitarbeiternameje ein Balken für Soll- und Ist-Wert zwecks Vergleich
415
4.2 Projektplanung Balkendiagramm
Balkendiagramm
Arbeitsschritte Meilensteine Jahr
Quartal 2 3 4 1 2 3 4 1 2 3 Insges. MID (Dipl.Ing
AP 1 Entwicklung Vorgehensmodell „BP2WS-Prozess“ 41,4 12,3 AP 1.1 Stand der Technik 0,7 2,1 0 AP 1.2 Vorgehensmodell „BP2WS“ 1,4 1,1 1,3 1,3 0,9 0,9 0,6 22,5 5 MS 1.1 BP2WS V1 MS 1.2 BP2WS V2 AP 1.3 Dokumentation 0,7 0,6 1 1,3 10,8 3 AP 1.4 UML Profile 0,5 0,5 0,3 0,7 6 2AP 2 Modelltransformation und Codegenerierung 43,8 10,8 AP 2.1 Stand der Technik 0,7 2,1 0 AP 2.2 Transformationssprache 0,9 0,8 0,8 0,8 0,4 11,1 MS 2.1 Transformationssprache V1 MS 2.2 Transformationssprache V2 AP 2.3 Regeln 1 1,1 2,2 1,5 1,3 1,4 1,1 0,6 30,6 7 MS 2.3 RegelbibliothekAP 3 Prototyp 48,3 42,6 AP 3.1 Anforderungen 0,5 0,3 2,4 1 AP 3.2 Modellierung 0,5 1,2 0,2 0,3 0,2 0,1 0,1 7,8 5 MS 3.1 Modellierung in Innovator AP 3.3 Tranformationen / Codegenerierung 3,1 3,5 3,1 2 1 38,1 3 MS 3.2 Transformations / Codegen. In InnovatorAP 4 Fallstudie 59,1 9,3 AP 4.1 Anforderungen Fallstudie 1,5 1,6 9,3 1 AP 4.2 Anforderungen an BP2WS 0,9 0,4 3,9 1 AP 4.3 Fallstudie 1 und Evaluation 3,6 2,4 18 2 MS 4.1 Fallstudie 1 und Eval AP 4.4 Fallstudie 2 und Evaluation 3,3 3,3 2,7 27,9 4 MS 4.2 Fallstudie 2 und EvalAP 5 Projektmanagement 0,8 0,2 0,3 0,35 0,25 0,1 0,3 0,25 0,25 0,8 10,8 2,1
Summen 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: 6,78
2006 2007
Einteilung nach Vergütungsg
bei Wirtschafts-Unternehmeo.ä.
Gesamtpersonalplan Alle Projektpartner kumuliert Zeitplan - Angaben als 'Personen pro Monat'
Balkendiagramm Meilensteine
PersonaleinsatQuartale berücksich0,2*3=0,6
2005
418
4.2 Projektplanung Balkendiagramm
Vernetzte BalkenpläneIn das Balkendiagramm werden zusätzlich Informationen über einfache Abhängigkeiten zwischen den einzelnen Vorgängen eingefügtDarstellung: Pfeile vom Vorgänger-Balken zum jeweiligen NachfolgerDadurch 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
421
4.2 Projektplanung Balkendiagramm
17 19 21 23 25 27 29 313rd Quarter 1st Quarter 3rd Quart
Phase 1 Phase 2
ID ID Task Name1 WP1 WP1 Project Management & Coordination
2 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
7 D12 Inter-working with other projects
8 D13 Impact on Standards
9 D14 Impact on Standards
10 D15 Project summary and exploitation plan
11 D16 Annual Report Review 2000
12 D17 Annual Report Review 2001
13 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 Set-up of the environment
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
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
40
31/03
31/03
31/03
30/05
30/06
31/12
31/12
30/04
30/08
30/06
31/05
31/07
31/12
30/08
30/08
31/12
28/09
-2 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 311st Quarter 3rd Quarter 1st Quarter 3rd Quarter 1st Quarter 3rd Quart
422
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammMotivation: 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 EinsatzmittelnReduktion der Gesamtheit von EinsatzmittelnErhöhung der Anzahl der zu bearbeitenden ObjekteOptimierung des Einsatzes von Menschen und Maschninen
horizontale Achse des E-A-Diagramms: Zeitvertikale Achse: Anzahl der Einheiten
423
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammSchritte 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 LageErstellen des E-A-Diagramms der frühesten LageErstellen des Balkendiagramms der spätesten LageErstellen des E-A-Diagramms der spätesten LageDurchführen der Bedarfsglättung gemäß der Bedarfsbegrenzung (“nicht-funktionale Anforderungen”)
424
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - Auslastungsdiagramm Beispiel eines Netzplans mit Einsatzmitteleinheiten(und mit unterschiedlichen Zeitwerten des Endereignisses)
425
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammBeispiel für ein Balkendiagramm der frühesten Lage
426
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammBeispiel 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.
427
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammBeispiel für ein Balkendiagramm der spätesten Lage
(Jenny Abb. 4.21, S. 347)
428
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammBeispiel 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.
429
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammDie 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
430
4.2 Projektplanung Einsatzmittel - Auslastungsdiagramm
Einsatzmittel - AuslastungsdiagrammBeispiel einer Glättung unter dem Kriterium, daß die auf zehn Einheiten festgelegte Bestandesgrenze eingehalten werden muß.
431
4.2 Projektplanung Arbeitspaketbeschreibung
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
Gute technische und funktionale Kenntnisse Mobile Odors, Trainerausbildung
Chefdesigner
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 pdf-
Format.Nachbereitung: Teilnehmerzertifikate und im Kurs erarbeitete Unterlagen (elektronische Bilder via E-Mail)
3) Notwendige Fähigkeiten des/der Durchführungen
2) Durchführende Personen oder Rollen
1) Beschreibung des Arbeitspaketes
432
4.2 Projektplanung Arbeitspaketbeschreibung
keine
8) Kennzahlen zur Überprüfung der korrekten Durchführung
Teilnehmer kennen die Technologie und fühlen sich in der Lage, auch mit technisch versierten Kunden ein Vertriebsgespräch zu führen.
7) Vorraussetzungen für eine erfolg-reiche Abnahme
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
Ausreichend zeitlicher Vorlauf bei der Planung, damit alle Teilnehmer mit den 2 Trainings erreicht werden.
Trainerfolien, Trainingsorganisation, durchgeführte Trainings, Teilnehmerunterlagen
Schulungsdauer: 2 Tage (à 8 Stunden), Aufwand noch zu bestimmen
6) Vorraussetzungen für die Durch-führung
5) Liefergegenstände
4) Dauer und Aufwand
433
4.2 Projektplanung Risikoanalyse
RisikoanalyseZiel: Abschätzung der möglichen Risiken mit deren Wahrscheinlichkeit des Eintreffens und AuswirkungenZeitpunkt der Durchführung:- zu Projektbeginn, bzw. bei der Bewertung der Projekt-anträ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)
434
4.2 Projektplanung Risikoanalyse
RisikoanalyseBeispiel eines Formulars für die Risikoanalyse:
2) Durchführung der Risikoanalyse2.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? ...
435
4.2 Projektplanung Risikoanalyse
Risikoanalyse2.2 Beschreiben der Ursachen jedes RisikosKennt man die Ursachen, ist es einfacher, adäquate Gegenmaßnahmen zu planen.2.3 Bewerten der Eintrittswahrscheinlichkeit je Risiko2.4 Bewerten des Auswirkungsgrades/ der Tragweite2.5 Bestimmen des Risikogrades: die größten Risiken haben eine hohe Eintrittswahrscheinlichkeit und Tragweite2.6 Beschreibung konkreter Gegenmaßnahmen und präventiver Aktionen2.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
436
4.2 Projektplanung Risikoanalyse
Risikoanalyse3) NachbearbeitungRisikosituation eines Projektes ändert sich mit der ZeitFolgerung: Überprüfung und Aktualisierung des Risikoprofils im Projektverlauf; z.B. bei ReviewsFragen:- Kommen neue Risiken hinzu?- Haben sich die Faktoren bekannter Risiken geändert?- Sind die zur Risikoverminderung getroffenen
Maßnahmen noch wirkungsvoll?
437
4.2 Projektplanung Personalplanung
PersonalplanungAufgaben der projektbezogenen Personalplanung
Sicherstellung der MitarbeiterverfügbarkeitOptimaler Einsatz der Mitarbeiter
- Vermeidung von Mitarbeiterüberlastung- Vermeidung von mangelnder Mitarbeiterauslastung
438
4.2 Projektplanung Personalplanung
Ermittlung PersonalaufwandPrinzipieller Ansatz:
Eingaben: Aufwand Aktivität, Dauer AktivitätAusgabe: Anzahl benötigter MitarbeiterVerfahren:Zusätzlich: Benötigte Qualifikation
Rechenbeispiel: 10 PMDauer 10 KM : 1 MADauer 2 KM : 5 MA
Bemerkungen:Annahme der normierten Leistung (1 MA leitet 1 PM pro Monat)Annahme der unabhängigen Multiplizität von MitarbeiternBerücksichtigung Brutto/Netto-Leistung
439
4.2 Projektplanung Personalplanung
PersonalplanungPrinzipieller Ansatz:
Ermittlung Personalaufwand (Projektstrukturplan, Aufwandsschätzung, Terminplan)Ermittlung PersonalressourcenPersonalzuordnung und Optimierung der Auslastung
Varianten der Zuordnung/Optimierung:Terminorientiert: Aufwände in Abhängigkeit vorgegebener TermineAufwandsorientiert: Termin in Abhängigkeit vorgegebener (Maximal-)AufwändeRealistisch: Mischverfahren
440
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
441
4.2 Projektplanung Personalplanung
Organisatorische RandbedinungenQualifikation der Mitarbeiter:
Qualifizierte Mitarbeiter einsetzenMitarbeiter 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 einplanenMatrixstruktur: Linenvorgesetzten in Planung einbeziehen
Generell: Mitarbeiter rechtzeitig in Planung einbeziehen
442
4.2 Projektplanung Personalplanung
Humane RandbedingungenProduktivitätsvarianzen:
Starke Produktivitätsschwankungen zwischen MitarbeiternSchwache Produktivitätsschwankungen im Team
TeamkohäsionTeamidentifikation mittels gemeinsamer Normen„Never change a winning team“Ausrichtung auf ein gemeinsames Ziel
ProjektidentifikationIdentifikation erhöht ProduktivitätMultiprojekteinsatz reduziert Produktivität
Generell: Humane Faktoren sind primäre Produktivitätstreiber
443
4.2 Projektplanung Personalplanung
Produktivität
Produktivitätsvarianzen:Beste Mitarbeiter um Faktor 10 besser als schlechtesteBeste Mitarbeiter um Faktor 2,5 besser als DurchschnittÜberdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittlicheUnabhängig von Leistungsmetrik:
- Anzahl der Fehler- Kalenderzeit bis Meilenstein- Funktionspunkte pro Zeiteinheit
444
4.2 Projektplanung Personalplanung
RessourcenplanungVerfahren:
Im wesentlichen analog PersonalplanungÄhnliche Probleme
- Qualifikation: Vorbereitung- Multiprojekteinsatz: Umrüstung
UnterscheidungNichtverbrauchbare RessourcenVerbrauchbare Ressourcen (eingebettete SW)
445
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
446
ProjektmanagmentErster Überblick über die Vorlesung
4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung
5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
447
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
448
Kapitel 5:Projektstrukturen und Personalaktivitäten
EinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
449
Kapitel 5:Projektstrukturen und Personalaktivitäten
EinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
450
5 Projektstrukturen und Personalaktivitäten5.0 Einleitung
AufbauorganisationProjektfunktionenProjektorganisation
Ablauforganisation / Meilenstein und Phasen
PhasenorganisationMeilenstein-Trendanalyse
ProjektzielsetzungProjektzieleRequirements
ProjektplanungStrukturplanungAufwandsschätzungAblaufplanungTerminplanung
Projektsteuerung und -überwachungBerichtswesenSteuerungsmaßnahmen
Projekt-ziel
Ablauf-organisation
Projekt-steuerung
Projekt-planung
Aufbau-organisation
451
5 Projektstrukturen und Personalaktivitäten5.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 Organisationunternehmensinterne Projektorganisationunternehmensübergreifende Projektorganisation
452
5 Projektstrukturen und Personalaktivitäten5.0 Einleitung
Rollen im ProjektProjektbüro bzw. Projekt- Office
Informatik- SeiteProjektleiter/Projektverantwortlicher: TeamführungMitglieder des Projektteams: Arbeitsdurchführung
FachbereichsseiteAnwender
- 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
453
5 Projektstrukturen und Personalaktivitäten5.0 Einleitung
Projektteam & ProjektleiterGesamtverantwortung liegt beim Projektleiter
QualitätKostenZeit
Projektmitarbeiter sind fachlich unterstelltverantwortlich für Durchführung zugewiesener AufgabenBerichtsweg an den Projektleiter / ProjektverantwortlichenDisziplinatorische Unterstellung
PL und Mitarbeiter bleiben in ihren StellenMatrixorganisationfachliche Unterstellung (Berichtsweg) -> Informations - VerdichtungProjektleitung mit Personalverantwortung
454
5 Projektstrukturen und Personalaktivitäten5.0 Einleitung
Einrichten einer projektspezifischen Organisation:Aufbauorganisation
Innere Aufbau eines Unternehmens, d.h.- Einbinden des Projekts in die Unternehmensorganisation- Einrichten von Rollen und Verantwortlichkeiten
AblauforganisationOrganisation 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
456
Projektspezifische Definition der Projektfunktionen
Übertragung der Projektfunktionen inkl. Kompetenz und Verantwortung auf die Aufgabenträger
Einbettung des Projekts in die vorhandene Organisation
Projektfunktionen Aufgabenträger Organisationsformen
ProjektleitungProjektplanung und -überwachungSystemplanung und -überwachungSystementwicklungSystemintegration und -testKonfigurations-managementQualitätssicherung
Personen
Projektstellen- Linienstellen- Stabsstellen- Temporäre Stellen
Gremien
Linien-Projektorganisationen
Matrix-Projektorganisationen
Reine Projektorganisation
5 Projektstrukturen und Personalaktivitäten5.0 Einleitung
457
Projektspezifische Definition der Projektfunktionen
Übertragung der Projektfunktionen inkl. Kompetenz und Verantwortung auf die Aufgabenträger
Einbettung des Projekts in die vorhandene Organisation
Projektfunktionen Aufgabenträger Organisationsformen
ProjektleitungProjektplanung und -überwachungSystemplanung und -überwachungSystementwicklungSystemintegration und -testKonfigurations-managementQualitätssicherung
Personen
Projektstellen- Linienstellen- Stabsstellen- Temporäre Stellen
Gremien
Linien-Projektorganisationen
Matrix-Projektorganisationen
Reine Projektorganisation
5 Projektstrukturen und Personalaktivitäten5.0 Einleitung
458
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen
ProjektfunktionenProjektleitungProjektplanung und -überwachungSystemplanung und -überwachungSystementwicklungSystemintegration und -testKonfigurationsmanagementQualitätssicherung
459
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Projektleitung
ProjektleitungZielvorgaben (z.B. Ressourcen, Termine, etc.) und Randbedingungen des ProjektsKontrolle und Steuerung der ZielerreichungFestlegung der Aufbau- und AblauforganisationenDelegation von AufgabenVergabe von TeilaufträgenKoordination aller beteiligten Stellen/Unternehmen/GruppenRessourcenbeschaffung, PersonaleinsatzplanungPersonalführung abh. von OrganisationsformEntscheidung über LösungsalternativenFestlegung von EntwicklungsprioriätenEntscheidung über Planungen und EntwicklungsergebnissenInformation von und Kommunikation mit Auftraggeber, ManagementAußervertretung des Projekts
460
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Projektplanung und -überwachung
Projektplanung und –überwachungProjektstrukturplanung (Zerlegung der Gesamtaufgabe in Teilaufgaben)ArbeitspaketdefinitionAblaufplanung (Festlegung der zeitlichen Ablauffolge der Arbeitspakete, Netzplanerstellung, etc.)Definition von TeilaufträgenPlanung und Kontrolle von
End- und Zwischenergebnissen in Abstimmung mit Systemplanung und –controlling, sowie QualitätssicherungRessourcen, wie z.B. Personal, HW, SW,...Termine, MeilensteineKosten, wie z.B. Personal, Unteraufträge,...
Berichtswesen (Ergebnisse, Kosten, Termine, Meilensteine,...)Vertragsadministration
461
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Systemplanung und -überwachung
Systemplanung und –überwachungRequirements-Engineering (Analyse technische Anforderungen)Definition und Analyse der technischen Probleme und Zerlegung in Teilaufgaben, sowie TeilaufträgeLösungsalternativen aufstellen und bewertenFeasibility Study (können wir das überhaupt machen?)Entwurf GesamtsystemFestlegung Schnittstellen nach innen und außenProduktstrukturplanungKonfigurationsplanung inkl. Produkteinheiten und Versionen (-> KM)Entwicklungsweg aufstellenAuswahl der Entwicklungsumgebungen, etc.Rahmenbedingung für Qualitätssicherung und Teststrategie definierenFestlegung und Controling von technischen Richtlinien für Entwurf, Implementierung,... z.B. Code-Layout, Versionierung
462
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Systementwicklung
SystementwicklungDefinition und Analyse der Anforderungen an die TeilsystemeProjektierung und Entwurf von KomponentenErstellung und Testen von PrototypenDurchführung von Simulationen DetailspezifikationRealisierung der Komponenten, inkl. Test, Dokumentation und VersionisierungDurchführung von Änderungen und KorrekturenBenutzerdokumentation verfassen
463
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Systemintegration und -test
Systemintegration und –testTestplanung inkl. Vorgehen, Umfang und Auswahl von TestfällenPlanung und Realisierung der Testsysteme für alle Phasen der Integration: Integrations-, System- und RegressiontestsSystemintegration: Zusammenbau der Teilsysteme zum GesamtsystemIntegrationstest: Läuft das integrierte System?Systemtest: Erfüllt das System die Requirements?Regressiontest: Läuft das System nach Fehlerbehebung, Änderungen oder Erweiterungen?
464
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Konfigurationsmanagement
KonfigurationsmanagementVerwaltung der Entwicklungsergebnisse ((Teil-)Systeme, Module, Versionen, etc.) und Projektdaten Melde- und Änderungswesen (Change Management): Verwaltung und Verfolgung von Requirements, Änderungen (Change Requests) und Bug reportingKonfigurationskontrolleBereitstellung von Komponenten für Systemintegration und SystemtestAuslieferung vom SystemAuswertungen
465
5 Projektstrukturen und Personalaktivitäten5.1 Projektfunktionen - Qualitätssicherung
QualitätssicherungFestlegung der QualitätsanforderungenPlanung der Qualitätsprüfung
Objekte, wie z.B. Code, Werkzeuge, DokumenteVerfahren, 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üfungBerichterstatttung
466
Projektspezifische Definition der Projektfunktionen
Übertragung der Projektfunktionen inkl. Kompetenz und Verantwortung auf die Aufgabenträger
Einbettung des Projekts in die vorhandene Organisation
Projektfunktionen Aufgabenträger Organisationsformen
ProjektleitungProjektplanung und -überwachungSystemplanung und -überwachungSystementwicklungSystemintegration und -testKonfigurations-managementQualitätssicherung
Personen
Projektstellen- Linienstellen- Stabsstellen- Temporäre Stellen
Gremien
Linien-Projektorganisationen
Matrix-Projektorganisationen
Reine Projektorganisation
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
467
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Aufgabenträger - RollenProjektstruktur: Definiert durch
RollenAktivitäten:
- Pflichten/Aufgaben- Rechte/Kompetenzen
Rollenstruktur: Beeinflusst von:Prozessstruktur (z.B. Analyse, Design, Implementierung, Integration)Produktstruktur (z.B. Präsentation, Logik, Datenhaltung)
Projektrollen:ProjektausschussAuftraggeberAnwenderProjektleiterProjektmitarbeiter (z.T. leitender Mitarbeiter)
468
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Team-Rolle: ProjektleiterRolle: ProjektleiterAufgaben:
Erstellung Projekt-, Termin- und KostenplanOrganisation und Koordination ProjektteamDurchführung FortschrittskontrolleSteuerung und Festlegung von Entscheidungen (fachlich)Evtl.: Personelle Betreuung ProjektmitarbeiterErfüllung und Einhaltung der Sach-, Termin- und Kostenziele
Kompetenzen:Mitwirkung bei der ProjektzieldefinitionMitspracherecht bei der Bestimmung der Fachverantwortlichenprojektbezogenes Informations-, Weisungs- und EntscheidungsrechtDelegationsrecht von AufgabenVerfügungsrecht über ProjektbudgetZugriffsrecht auf alle für die Projektdurchführung notwendigen Informationen
469
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Team-Rolle: MitarbeiterRolle: MitarbeiterAufgaben:
Mitwirkung an ProjektplanungDurchführung der zugewiesenen ArbeitspaketeDokumentation der zugewiesenen Arbeitsergebnisse
Kompetenzen:Vorbereitung/Herbeiführung von EntscheidungenUmsetzung von VorgabenEinsatz von Ressourcen
Variante: Leitender Mitarbeiter
470
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Weitere Mitarbeiter-Rollen• SE-spezifische Team-Rollen:
SystemanalytikerSystementwicklerTester
• SE-Spezifische Stabs-Rollen:Qualitätsmanager, QualitätsbeauftragterKonfigurationsmanagerIT-SicherheitsbeauftragterProjekt-Controller
• Generelle Prinzipien:Personifizierte VerantwortungKlare Aufgaben und Kompetenzen
471
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Gremienzur Abstimmung, Information, Problemlösung und Entscheidungaber: so wenig Gremien wie möglichBeispiele:
ProjektbesprechungenChange Control BoardMeilenstein-EntscheidungenBeratungsausschussEntscheidungsausschuss
472
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Projektgremien
Geschäftsführung Geschäftsführung
Gesamt-PL Gesamt-PL
PL-Projektleiter PL-Projektleiter
Teil-PL Teil-PL Team
Entscheidungs-ausschuss
Lenkungs-ausschuss
Projektsteuerungs-runde
Projektmeetings
473
5 Projektstrukturen und Personalaktivitäten5.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 DetailebeneArbeitspakete und ProjektfortschrittRisiken
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 ProjektebeneKoordinierung verschiedener, an der Projektdurchführung beteiligter Gruppen Projektfortschritt und Risiken
474
5 Projektstrukturen und Personalaktivitäten5.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äftsleitungInterne 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 ProblemeProjektfortschritt und Risiken auf hohem Niveau
Meist ist der Lenkungsausschuss das oberste Gremium.
475
5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger
Wenn jedoch die Geschäftsleitung nicht in den Lenkungsausschuss eingebunden ist, gibt es gegebenenfalls als zusätzliche Eskalationsstufe ein weiteres Gremium, Entscheidungsausschussgenannt.
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.
476
Projektspezifische Definition der Projektfunktionen
Übertragung der Projektfunktionen inkl. Kompetenz und Verantwortung auf die Aufgabenträger
Einbettung des Projekts in die vorhandene Organisation
Projektfunktionen Aufgabenträger Organisationsformen
ProjektleitungProjektplanung und -überwachungSystemplanung und -überwachungSystementwicklungSystemintegration und -testKonfigurations-managementQualitätssicherung
Personen
Projektstellen- Linienstellen- Stabsstellen- Temporäre Stellen
Gremien
Linien-Projektorganisationen
Matrix-Projektorganisationen
Reine Projektorganisation
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
477
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Ein Ziel der Projektorganisation ist die Regelung der statischen Aspekte (Aufbauorganisation) und auch der dynamischen Aspekte (Ablauforganisation) im Projekt.
Sowie die Regelung der Verantwortlichkeiten, beispielsweisedie 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.
478
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Grundstruktur:Organisationsleitung:
Funktion: Strategische FührungBeispiel: Geschäftsführung
Mittellinie:Funktion: Operative FührungBeispiel: Mittleres Management, Gruppenleiter
Betrieblicher Kern:Funktion: Operative AusführungBeispiel: Entwickler
Stab:Funktion: Unterstützende AusführungBeispiel: Rechtsabteilung, Telefonzentrale, Zentrale Forschungsabteilung, Methodenberatung
479
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Formen der Unternehmensorganisation:Bereichsstruktur:
Untergliederung nach GeschäftsfunktionBereiche: z.B. Marketing, Entwicklung, Vertrieb, Buchhaltung, ForschungBeispiel: BMW, Microsoft
Marktstruktur:Untergliederung nach ProduktgemeinsamkeitenMärkte: z.B. BIS (ERP, CRM, etc.), Medizintechnik, TelekomBeispiel: Siemens
Spezielle Varianten:Nach Niederlassungen, z.B. AutohäuserNach Kunden, z.B. SBS – öffentliche Auftraggeber (BfA, BA)
480
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Bereichsstruktur
Schwerpunkte: Know-how-Transfer, Ressourcenflexibilität
481
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Marktstruktur
Schwerpunkte: Effizienz, Produktidentifikation, minimierte Kommunikation
482
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Vor- und Nachteile von OrganisationsformenBereichsstrukturierte Organisation:
Vorteile:Standardisierung der Abläufe, erhöhte WirtschaftlichkeitSpezialisierung, Fachhierarchien, Wissenstransfer
Nachteile:Aufwändige Koordination funktionsübergreifender TätigkeitenMangelnde Flexibilität
Ausrichtung: Fertigung von Standardprodukten
Marktorientierte Gruppierung:Vorteile:
Flexibilität (neue Marktsegmente)I.A. geringerer bürokratischer Aufwand
Nachteile:Schwacher Wissenstransfer durch fehlende SpezialisierungMangelnde Effizienz durch mangelnde Standardisierung
Ausrichtung: Fertigung von Individualprodukten
483
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
ProjektformenWesentliches Element: Verantwortung
Fachliche Verantwortung („Was wird wann gemacht“)Führungsverantwortung (Personalverantwortung) („Wer macht es wann mit welchem Aufwand“)
Problem:Mitarbeiter sind in langfristige Organisationshierarchien eingebundenProjekte konkurrieren kurzfristig mit diesen HierarchienResultat: Konflikt zwischen Interessen der Linienhierarchie und der Projekthierarchie (i.E. Linienverantwortung vs. Projektverantwortung)
Projektstrukturen:Stab-Linien-OrganisationProjektorganisationMatrixorganisation
484
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Bereichsleitung
E F VPL
PL
PL
Projekte in Matrixorganisation
Projekte in reiner Linienorganisation
Bereichsleitung
E F V
PLPL
Bereichsleitung
E F VPL
Projekte in reiner Projektorganisation
485
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
ProjektorganisationPrinzip:
Eigenständige Organisationseinheit für Projekt, extra für Projekt eingerichtetProjektmitarbeiter werden aus Bereichen freigestellt
Verantwortung Projektleiter:Fachliche VerantwortungFührungsverantwortung
Vorteile:Klare Kompetenzen und VerantwortlichkeitenHohe Projektidentifikationgeringer organisatorische VerknüpfungenKurze Kommunikationswege und geringster „Overhead“
Nachteile:Umstellungsaufwände durch Aus-/EingliederungGefahr des Etablierend der Projektgruppe nach ProjektendeSchwächung der BereicheProblem der ungleichmäßigen ProjektbelastungGefahr von Parallelentwicklungen in Projekt und benachbarter Linie
Einsatz: kleine, mittlere oder große Projektehäufig bei Projekten mit erheblichem Risiko
Bereichsleitung
E F VPL
Projekte in reiner Projektorganisation
486
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Projektorganisation
487
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Extremfall: Projektstruktur als Unternehmensform
488
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Stab-Linien-OrganisationPrinzip:
Keine Leitungsinstanz/Organisations-einheit für ProjektProjektmitarbeiter verbleiben vollständigin Bereichen
Verantwortung Projektleiter:Keine fachliche VerantwortungKeine FührungsverantwortungStabsfunktion (berichtend, koordinierend), z.B. Laborleiter
Vorteile:Schneller Know-How-TransferFlexible KapazitätsauslastungKeine Umstellungsaufwände
Nachteile:Aufwändige Koordinations- und AbstimmungsprozesseKeine ProjektidentifikationKeine Instanz mit Weisungsbefugnis
Einsatz:Isolierte, kleine Projekte oder Teilprojekte
Projekte in reiner Linienorganisation
Bereichsleitung
E F V
PLPL
489
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Stab-Linien-Organisation
490
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
MatrixorganisationPrinzip:
Zeitlich befristetes MehrliniensystemProjektmitarbeiter verbleiben vollständigin Bereichenstarke organisatorische Verknüpfung
Verantwortung Projektleiter:Fachliche VerantwortungKeine Führungsverantwortung
Vorteile:Schneller Know-How-Transfer, Förderungder Synergy EffekteOptimale KapazitätsauslastungGeringe Umstellungsaufwände, schnelle Zusammenfassung von interdiszipliären Gruppen
Nachteile:Konfliktpotential durch DoppelunterstellungHohe Anforderungen an Selbstdisziplin und EigenständigkeitHohe 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
Bereichsleitung
E F VPL
PL
PL
Projekte in Matrixorganisation
491
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Matrixorganisation
492
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
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
493
5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen
Außerdem - unternehmensübergreifende Projektorganisationenklare Vertragsbeziehungen zwischen wirtschaftlich, rechtlich unabhängigen Projektpartnern notwendigTypische 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
werdenGeneralunternehmerorganisation
- Ein Unternehmen übernimmt die volle wirtschaftliche und technische Verantwortung- Andere Unternehmen über Unteraufträge für in sich abgeschlossen Aufgabenteile an dem Gesamtvorhaben
beteiligt.
494
5 Projektstrukturen und Personalaktivitäten5.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 ProduktstrukturSoftwaresysteme: Modularisierung zur KomplexitätsreduktionAbstimmungsaufwand: Systemschnittstellen
Konsequenz: Abbildung der Produktstruktur auf Projektstruktur
495
5 Projektstrukturen und Personalaktivitäten5.4 Zusammenfassung
Gute Projektorganisation - wie gutes Softwaredesign: schlanken SchnittstelleD.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.
496
5 Projektstrukturen und Personalaktivitäten5.4 Zusammenfassung
Kommunikationsaufwand in Teams
Konsequenz:ArbeitsteilungAbstimmung- und Kommunikationsaufwand
Resultat: Zusätzlicher AufwandRechenbeispiel: Aufwand bei 3-Stunden-Besprechungen
Zwei Parteien: 2*1*3 = 6 Ph/WocheVier Parteien: 4*3*3 = 24 Ph/WocheZehn Parteien: 10*9*3 = 270 Ph/Woche
Konsequenz: Minimierung der Schnittstellen
498
5 Projektstrukturen und Personalaktivitäten5.4 Zusammenfassung
S-PO:Wartung und Support sollen von den einzelnen zuständigen Stellen erbracht werden
Einsatz
R-PO:Das Projekt ist so bedeutend geworden, dass eine eigene Organisationsform angebracht erscheint
RealisierungErprobung
M-PO:Interdisziplinäres Team für überschaubaren Zeitraum benötigt.Entwurf
E-PO: Es ist noch unsicher, ob es zu einer Beauftragung kommt
Organisationsformen
Definition
Phase
499
5 Projektstrukturen und Personalaktivitäten5.4 Zusammenfassung
Festlegung der Projektstruktur:Bereitstellung von Mitarbeitern: Einbettung in die UnternehmensorganisationEinrichten einer internen Projektstruktur: Definition von Rollen und Verantwortlichkeiten
Projektstruktur: ähnlich Unternehmensstruktur:Leitung: ProjektleiterKern: ProjektmitarbeiterStab: Übergreifende Tätigkeiten (z.B. QM, KM)
Projekte konkurrieren mit Unternehmensstruktur:Transparenz von Kompetenzen und VerantwortungenIdentifikation gemeinsamer Ziele Linie/Projekt
500
5 Projektstrukturen und Personalaktivitäten5.4 Zusammenfassung
Personalaufwand in ProjektenBeobachtung:
Kommunikationsaufwand bestimmt durch ProjektstrukturProjektstruktur bestimmt durch Produktstruktur
Konsequenz:Erst: Festlegung der ProduktstrukturDann: Festlegung der ProjektstrukturEvtl. iterativ
Resultat: Ungleichmäßige PersonalausstattungBeispiel:
501
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
502
ProjektmanagmentErster Überblick über die Vorlesung
4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung
5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
503
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
504
Kapitel 6:Projektkontrolle
Projektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolle
505
6 Projektkontrolle
Projektkontrolle und ProjektsteuerungProjektkontrolle:
Feststellung des ProjektstatusFeststellung von PlanabweichungenTechniken:
FortschrittsanalyseRisikoanalyseQS-Maßnahmen
ProjektsteuerungDurchführungsentscheidungenKorrektivmaßnahmenTechniken:
RisikomanagementQM-MaßnahmenKonfigurationsmanagement
506
6 Projektkontrolle
AusgangssituationGroß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 werdenWirklich problematisch sind kleine, aber öfter auftretende Probleme mit kleinen Auswirkungen, die sich summieren („Kleinvieh macht auch Mist“)
507
6 Projektkontrolle
Ziele der FortschrittskontrolleBestandsaufnahme: Wo steht das Projekt aktuell (regelmäßig)?
Feststellung Projekt/Produktstatus und AbweichungenUnterstützung Steuerung
Basis für weitere PlanungenProduktivitätsentwicklung (Soll/Ist)ZeitplanungKapazitätsplanung
Identifikation von ProblembereichenReaktion auf Probleme, Definition und Durchführung von Gegenmaßnahmen
508
6 Projektkontrolle
Fortschrittskontrolle ist nur ein Teil des gesamten Projektcontrollings
Budget-/ZeitkontrolleRisikomanagementMitarbeiterkontrolleQualitätsmanagementKonfigurationsmanagement...
509
6 Projektkontrolle
Aufgaben der KontrolleTeilschritte:
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 einrichtenFeststellung/Messung Projekt/Produktstatus
- Projekt: Fortschrittskontrolle- Produkt: Qualitätssicherung
Feststellung AbweichungenAbleitung geeigneter Gegenmaßnahmen (falls notwendig)
Grundlage: Metriken
510
6 Projektkontrolle
Metrik
Abbildung einer Eigenschaft in einen WertebereichWünschenswerte Kriterien (u.a.):
Objektiv: Unabhängig vom messendenZuverlässig: WiederholungsneutralÖkonomisch: Mit vertretbaren Kosten durchführbarNützlich: Für Kontrolle einsetzbar
Beispiele: Meilensteintermine, Fehleranzahl, Funktionspunkte
511
6 Projektkontrolle
BerichtswesenBerichtswesen
BereitstellungFestlegung Verantwortlichkeiten: Messen, Aufbereiten, Weiterleiten
Grundregeln:Regelmäßig: Dichte, gleichmäßige MessungenRechtzeitig: Maßnahmen zur GegensteuerungRichtig: 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
513
Kapitel 6:Projektkontrolle
Projektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolle
515
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Risikomanagement:Ziel: Bereitstellung von Verfahren zur Minimierung von RisikenVerfahren: Identifizieren und Vermeiden von RisikenRisiko: Möglichkeit des Eintretens eines Schadensfalls
Einzelschritte:Risikobewertung
IdentifikationAnalysePriorisierung
RisikobeherrschungPlanungÜberwindungÜberwachung
516
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Beobachtungen:Pareto-Regel: 20% der Probleme verursachen 80% der KostenBehebungsverzögerung: je nach Phase bis zu 1000
Konsequenzen:Fokussierung auf wichtige RisikenFrühzeitige Erkennung und Vermeidung
518
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
RisikoidentifikationRisikoidentifikation:
Aufgabe: Festlegung projektspezifischer RisikenVerfahren: Erstellung Risikoliste
Einzelschritte:Identifikation Risiken: Checklisten, ProjektabschlüsseFestlegung Risikotreiber: Faktoren, die Risiko beeinflussenFestlegung Indikatoren: Metriken, die Risiko quantifizierenErmittlung Wahrscheinlichkeiten: Zuordnung Wahrscheinlichkeiten/Metriken
Beispiel:Risiko: Unrealistische KostenplanungRisikotreiber: Übertriebene Anforderungen, unrealistische Wiederverwendung, kompliziertes DesignIndikatoren: Anzahl Anforderungen (in FP), Umfang Wiederverwendung (in % Code), Aufwand Design (in Komponenten)Wahrscheinlichkeiten: Übertriebene Anforderungen (gering: < 100 FP, mittel: < 1000, hoch >= 1000)
520
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Weitere Risikoquellen
Integrierte Entwicklung Auftraggeber/Auftragnehmer
Mangelnde Kooperationsfähigkeit oder –bereitschaft
Keine Erfahrung mit Auftragsvergabe nach außen
Konkurrierende Interessengruppen, Widerstände (z.B. von Anwendern)
Kunde
Keine Erfahrung in neuer Anwendungsdomäne
Fehlende Erfahrung mit Teilaufgaben
Änderungsfreudigkeit des Kunden/Auftraggebers
Voraussehbar zahlreiche Änderungen
Hohe Komplexität, viele ungelöste Probleme
Anwendung
Erstmaliger Einsatz neuer Tools, Soft- oder Hardwarekomponenten
Unklar, ob geforderte Performanz erfüllt werden kann
Einzusetzende Technologie wird erst im Laufe des Projekts am Markt verfügbar
Unrealistisches Design
Technik
Anforderungen insgesamt unausgereift oder in Teilen noch unklar
Anforderungen
521
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Nicht die richtigen Mitarbeiter (mangelnde Qualifikation oder Erfahrung)
Drohender Ausfall von Mitarbeitern (Krankheit, Kündigung)
Nicht der richtige Projektleiter (unerfahren, ungeeignet, nicht anerkannt etc.)
Personelle Mängel
Ressourcenengpässe oder unzuverlässige Ressourcenzusagen
Unrealistische Budgets
Drohender Ressourcenentzug wegen anderer, wichtigerer Projekte
Ressourcen
Zulieferungen von anderen Projekten oder internen Stellen
Bekannte Probleme von Unterlieferanten
Einsatz von Unterlieferanten (generell)
Projektorganisation
Unrealistische Termine
Projektauftrag, -abwicklung
Weitere Risikoquellen
522
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Pflichten des Kunden vertraglich absichern
(Frühzeitige) Abnahme von Zwischenergebnissen vereinbaren
Kundenworkshops
Verstärktes Bemühen um den Kunden, Kontaktpflege
Bei Risiken bezüglich Anforderungen/Kunde:
Vorherige Erprobung von neuen Technologien
Anbieten alternativer Funktionen/Konzepte (bei denen das Risiko nicht auftritt)
Beratung, Reviews durch Unabhängige
Simulation oder Prototyping von Systemen
Bei technischen Risiken:
Beispiele für Präventivmaßnahmen
523
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
„Outsourcen“ von Risiken an Subunternehmer
Preisaufschläge einkalkulieren
Sonstiges
Prioritäten für die Ressourcenzusage mit Management diskutieren
Abwanderungsgefährdete Mitarbeiter zu halten versuchen
Einsetzen von Mitarbeitern in ähnliche Projekte im Vorfeld
Schulung, Coaching von Mitarbeitern/Projektleiter
Bei Ressourcenproblemen:
Beispiele für Präventivmaßnahmen
524
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
RisikoanalyseAufgabe:
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)
525
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
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
526
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Das Risiko wird mit ziemlicher Sicherheit eintreten.0,75 < p ≤ 1
Das Risiko wird eher eintreten als nicht eintreten, es ist aber keineswegs sicher.0,5 < p ≤ 0,75
Das Risiko wird eher nicht eintreten, es ist aber dennoch möglich.0,25 ≤ p ≤ 0,5
Es ist eher unwahrscheinlich, dass das Risiko eintritt, aber nicht auszuschließen.
Interpretation
0 ≤ p ≤ 0,25
Wahrscheinlichkeitsintervall
Charakterisierung der EintretenswahrscheinlichkeitBeispiel
527
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Einprodukte unbrauchbar9 – 10
Wesentliche Funktionen sind betroffen, Produkt kann nur mit deutlichen Einschränkungen benutzt werden 6 - 8
Einschränkungen der Funktionalität für Endbenutzer merklich, wesentliche Funktionen sind aber unberührt, Produkt kann benutzt werden3 - 5
Einschränkungen der Funktionalität für Endbenutzer kaum merklich
Schaden hinsichtlich Endprodukten des Projekts
1 -2
Kennziffer für Schadenshöhe
Überschreitung Projektkosten > 30%
Überschreitung Projektkosten > 15%,
aber ≤ 30%
Überschreitung Projektkosten> 5%,
aber ≤ 15%
Überschreitung Projektkosten ≤ 5%
Schaden hinsichtlich Projektkosten
Überschreitung Projektdauer > 20%
Überschreitung Projektdauer bleibt≤ 20%
Überschreitung Projektdauer bleibt≤ 10%
Verzögerung kann wieder aufgeholt werden, End-termin wird gehalten
Schaden hinsichtlich Überschreitung der Projektdauer
oder
oder
Charakterisierung der Schadenshöhe (Beispiel)
528
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Technisches Risiko4,50,59Übertragungsdauer der Ergebnisse von Duftanalysen zu lange (Verdacht aus Vorstudie).
05.01.3
Anforderungs-risiko2,50,55Ansprechpartner des Pilot-kunden stehen wegen Urlaubssituation im Mai nicht genügend zur Verfügung.
05.01.2
Anforderungs-risiko
Kategorie
5,4
Risiko-prio.-zahl
0,9
Wahr-schein-lichkeit
6
Schadenshöhe
Zeit für Anforderungsanalyse reicht nicht aus.
Beschreibung
05.01.
Datum des Eintrags
1
Nr.
Beispiel einer Risikoliste im Projekt Mobile Odors
529
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
hoch
mittel
gering
gering mittel hoch
Schadenshöhe
Wahrscheinlichkeit
3
2 1
Beispiel eines Risikoportfolios
530
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Risikomanagement: Weitere SchritteRisikopriorisierung:
Aufgabe: Identifikation der höchsten RisikenVerfahren: Identifiziere Risiken nach Analysefaktor gewichtet
Risikoplanung:Aufgabe: Festlegung Kontroll- und SteuerungsaktivitätenVerfahren: Bereitstellung Risikoplan
Risikoüberwindung:Aufgabe: Abwendung auftretender RisikenVerfahren:
- Durchführung Risikoplan: Ausführung Steuerungsaktivitäten- Zyklische Durchführung
531
6 Projektkontrolle6.1 Projektrisiken und Risikomanagement
Risikomanagement: Weitere Schritte (Fortsetzung)Risikoüberwachung:
Aufgabe: Fortlaufende Erkennung von RisikenVerfahren:
- Durchführung Risikoplan: Fortschrittskontrolle, Trendanalyse- Evtl: Plananpassung- Zyklische Durchführung
532
Kapitel 6:Projektkontrolle
Projektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolle
533
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
KonfigurationsmanagementRandbedingungen:
Produktkomplexität: Viele Module, viele BearbeiterProduktvielfalt: 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
534
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Wartungsaufwand Einzelprojekt
Einzelprojekt:Individuelle AnfertigungSchwerpunkt: Pflege (Fehlerbehebung)
535
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Wartungsaufwand langlebiges Projekt
Langlebiges Projekt:Wiederholte Installation bzw. (anpassbare) StandardanwendungSchwerpunkt: Änderung (Funktionserweiterung)
537
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
KonfigurationsmanagementZiel:
Produkt ist hinsichtlich seiner funktionellen (Code) und äußeren (zugehörige Information) Merkmale jederzeit identifizierbar
Funktion:Sicherstellung der Identifizierbarkeit, Verfolgbarkeit, Kontrollierbarkeit, StatusDarstellung der Zusammenhänge und Unterschiede zwischen verschiedenen KonfigurationenSicherstellung der Verfügbarkeit früherer KonfigurationenSicherstellen der Integrität (Gültigkeit, Reifegrad) von Produkten
Ansatz: Explizite Verwaltung von Produkten
538
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Produkt und Aktivität
Aktivitäten:Benötigen, erzeugen, modifizieren Produkte
Produkte:Synchronisieren, beeinflussen Aktivitäten
539
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
KM: Produktzustände
Produktzustände:Definiert auf allen Produkten des V-ModellsVerbinden KM mit allen weiteren ModulenErmöglichen Produktverwaltung
Zusammenhänge:KM: Erfassung Produkt, Produktstatus, ProduktänderungQS. Überprüfung/Abnahme ProduktPM: Planung Produkt
540
Planung/InitiierungProdukt/Konfig-Verwaltung:
Initialisieren ProdukteZustandsverfolgung von ProduktenKonfig-Verwaltung
Änderungsmanagement:Änderungenwünsche verwaltenVerantwortlichkeiten zu Rollen
Projekthandbuch
Projektplan
KM 1KM-Planung
KM 1.1 KM-Plan erstellenKM 1.2 KM einrichten
KM 2Produkt- und
Konfigurationsverwaltung
KM 2.1 Produkt initialisierenKM 2.2 Konfiguration initialisierenKM 2.3 Produkt verwaltenKM 2.4 Konfiguration fortschreibenKM 2.5 Zugriffsrechte verwalten
KM 3Änderungsmanagement
(Konfigurationssteuerung)
KM 3.1 Änderung bewertenKM 3.2 Änderungsvorgehen entschei-
den und Änderung einleitenKM 3.3 Änderung abschließen
KM 4KM-Dienste
KM 4.1 Daten administrierenKM 4.2 SW-/HW-Produkte katalogisierenKM 4.3 Schnittstellen koordinierenKM 4.4 Ergebnisse sichernKM 4.5 KM-Dokumentation führenKM 4.6 Release-Management durchführenKM 4.7 Projekthistorie führen
Änderungsantrag/Problemmeldung
KM-Plan
KID
Produkt
Änderungen gemäßV-Modell-Regelungen
Produkt-bibliothek
Änderungsauftrag
Berichtsdokumente/Projektabschlußbericht
Protokoll
Änderungsstatusliste
Änderungsmitteilung
Schnittstellenübersicht
Schnittstellenbeschreibung
Datenkatalog
Projekthistorie
Berichtsdokumente
ProjektübergreifenderDatenkatalog
Zentraler Produktkatalog
541
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Aufgaben KonfigurationsmanagementPlanung KonfigurationsmanagementBereitstellen Produkt-/KonfigurationsmanagementBereitstellung ÄnderungsmanagementBereitstellung von elementaren Diensten
Daten administrieren:- Zentrale, projektübergreifende Haltung aller Daten- Konsistente, vereinheitlichte Datendefinitionen
SW-/HW-Produkte katalogisieren: Vorbereitung WiederverwendungSchnittstellen koordinieren: Sicherung kompatibler SchnittstellenErgebnisse sichern: Wahrung des erreichten ProjektstandsKM-Dokumentation führen zur Erstellung von Detailunterlagen und Übersichten verschiedenster KM-Belange,Release-Management: Kontrollierte Konfigurationsfreigabe- und verteilungProjekthistorie führen: Nachvollziehbare Dokumentation über den Projektverlauf
542
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
KonfigurationKonfiguration:
Definition: Ansammlung von Produkten, die unabhängig von einander variiert werden können, einschließlich ihrer Beziehungen
Beschreibung: KonfigurationsidentifikationsdokumentFunktion: Erfassung der Konfigurationselemente und ihrer BeziehungenUmfasst:
- Unterkonfiguration (z.B. HW-Konfiguration, SWKonfiguration)- Konfigurationselemente- Hilfselemente (Generierungswerkzeuge)
543
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
KonfigurationselementKonfigurationselement (engl. Configuration Item):
Definition: vom Konfigurationsmanagement erfasset und als Einheit behandelte Ansammlung von Hard- und Software
Beispiele:Quellcode-DateienTesttreiber, Testfälle, TestprotokolleEntwicklungsdokumente (z.B. Pflichtenheft, Architekturentwurf)Hardwarekonfigurationsbeschreibung
Im allgemeinen:Nur ursprüngliche DokumenteKeine generierten Dokumente (z.B. Binärcode)
544
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
ÄnderungsmanagementZiel: Kontrolle der Änderungen
zur Sicherung der Produktqualität- Änderungsumfang- Verantwortlichkeiten
zur Kontrolle der ProjektdurchführungStatusverfolgungRessourcenplanung
Aufgaben:Änderungen identifizierenÄnderungen bewertenÄnderungensvorgehen entscheiden und Änderungen einleitenÄnderungen abschließen
545
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Änderungsmanagement
Änderungen:Änderungen verwalten
- Entgegennehmen/bewerten- Entscheiden/einleiten- Abschließen
Verantwortlichkeiten für Änderungsaufgaben zuweisenEntscheidungen herbeiführen und dokumentierenProjekthistorie mitführen
546
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Begriffe: Version, Variante, Release
Begriffe:Version: Ausprägung eines Konfigurationselements zu einem bestimmten ZeitpunktVariante: 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
547
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
Schnittstelle BerichtswesenBerichtswesen
Festlegung VerantwortlichkeitenVerteilen InformationenDokumentation Entscheidungen
Wesentliche Schnittstellen:Änderungsmanagement: Erfassung Fehler, ÄnderungenProjekthistorie: Dokumentation Projektabwicklung
Berichtsarten (Beispiele):FehleridentifikationÄnderungsanträge und EntscheidungenÄnderungsmeldungenProjekthistorie
548
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
FehleridentifikationAssoziierte Informationen:
Fehlernummer (laufende Nummer)Datum des ErfassensArt des Tests (Review/Walkthrough, Test)Evtl. TestdatenBeschreibung des Fehler/Verletzte Anforderung/Zugehöriger TestfallKritikalität des FehlersLokalisierung/Modul/DokumentVersion des betroffenen Moduls/DokumentsAufwand des FindensMaßnahme (Änderung Anforderungen/Änderung Dokument/Keine Änderung)Fehlerstatus: Gefunden/Behoben/GetestetDatum BehebungAufwand FehlerbehebungVon Behebung betroffene Module/Dokumente
549
6 Projektkontrolle6.2 Konfigurations- und Versionsmanagement
ProjekthistorieEntwicklungsverlauf
EntscheidungenSchwierigkeiten, deren Ursachen und Behebung
Änderungs-/VersionshistorieNachvollziehbarkeit von Änderungen (Änderungen-Version-Bezug)Dokumentation der Änderungshistorie (Anträge und Änderungen)Dokumentation der Änderungsentscheidungen
PlanungsstatistikPlanabweichungen und PlanänderungenAnalyse der UrsachenMöglichkeiten zur Verhinderung weiterer Planabweichungen
Änderungs- und FehlerstatistikÄnderungsantrag/ProblemmeldungBetroffene ProdukteKlassifizierung, Beurteilung, Diagnose/UrsacheMaßnahmen zur zukünftigen Vermeidung
Analyse/Auswertung der Projekthistorie („lessons learned“)
550
Kapitel 6:Projektkontrolle
Projektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolle
552
6 Projektkontrolle6.3 Qualitätsmanagement
SW-Qualität: Produkt vs. ProzessUnterscheidung:
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ätExtern 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ätssicherungWas ist Produktqualität?Wie wird Produktqualität erreicht?
553
6 Projektkontrolle6.3 Qualitätsmanagement
Qualitätsmanagement
Qualitätsmanagement:Planung: Vorbereitende MaßnahmenLenkung: Konstruktive MaßnahmenSicherung: Analytische MaßnahmenVerbesserung: Prozessverbesserungsmaßnahmen
554
6 Projektkontrolle6.3 Qualitätsmanagement
Qualität (ANSI/ASQC A3-1978), ISO 8402, DIN55350/1, IEEE-Norm)
“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 wirdEs gibt somit auch am System selbst orientiere Facetten der Qualität e.g. Wartbarkeit, Portierbarkeit, Testbarkeit, ..
555
6 Projektkontrolle6.3 Qualitätsmanagement
V-Modell: QS- und SE-Aktivitäten
Analytische Maßnahme: von QS für SEKonstruktive Maßnahmen: von QS auf SE-Produkten in QS
556
6 Projektkontrolle6.3 Qualitätsmanagement
Planung:QS-Initialisierung: Konstruktiv
Prüfung (analytisch):VorbereitungProzessprüfung („Vorgaben eingehalten“)Produktprüfung
Leitung (administrativ):QS-Berichtswesen
557
6 Projektkontrolle6.3 Qualitätsmanagement
Qualitätsplanung und QualitätsverbesserungQualitätsplanung:
Ansatz: Vorbereitung qualitätssichernder MaßnahmenVerfahren: 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 ProzessverbesserungVerfahren: Siehe nächsten Abschnitt
558
6 Projektkontrolle6.3 Qualitätsmanagement
Qualitätslenkung und QualitätssicherungQualitätslenkung:
Ansatz: Maßnahmen zur Umsetzung der QualitätszieleVerfahren:
- Beurteilung Prüfergebnis- Berichtswesen und Analyse
Qualitätssicherung:Ansatz: Maßnahmen zur Feststellung ob ausreichende Produktqualität vorliegtVerfahren: (vorwiegend) analytisch/prüfend
Im folgenden:Analytische und konstruktive MaßnahmenAuswirkung auf die Prozessqualität
560
6 Projektkontrolle6.3 Qualitätsmanagement
SW-Qualität - was ist das?SW-Qualität: Merkmale des SW-Produkts
Merkmalsbereiche (McCall):- Produkteinsatz- Produktbearbeitung- Produkterweiterung
Qualitätsmodell:Merkmale: Relevante ProduktkriterienMetriken: Eigenschaften eines ProduktsMaße: Meßeinheit und Meßmethode zur Bestimmung
Modell: Standard (z.B ISO 9126) vs. Methode (z.B. GQM)
561
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977)McCall, Richards, Walters 77: Factors in Software Quality, Rome Air Development Center, 1977High-Level Attribute der Qualität
i.e. Qualitätsfaktorenlassen sich nicht direkt messenwerden durch den Zusammenhang von Qualitätskriterien bestimmt
Low-Level Attribute der Qualitäti.e. Qualitätskriterienlassen sich direkt messen (entweder objektiv oder subjektiv)3 Product Activities mit insgesamt 11 Qualitätsfaktoren und 26 Qualitätskriterien
562
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - QualitätsfaktorenActivity 1: Product Operation: Benutzer
Korrektheit (Correctness)Das Ausmaß, zu dem das System die Anforderungsdefinition und die Ziele der Benutzer erfülltVerlässlichkeit (Reliability)Das Ausmaß, zu dem das System seine beabsichtigte Funktion erfüllt unter Berücksichtigung der notwendigen PräzisionEffizienz (Efficiency)Der Umfang an Ressourcen und Code, den ein System zur Ausführung einer Funktion benötigtIntegrität (Integrity)Das Ausmaß, zu dem der Zugriff von unberechtigten Personen auf Software und Daten kontrolliert werden kannVerwendbarkeit (Usability)Der benötigte Einsatz, um den Umgang mit dem System zu erlernen, das System zu bedienen, Eingaben vorzubereiten und die Ausgaben zu interpretieren
563
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - Qualitätsfaktoren 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ülltFlexibilität (Flexibility)Der benötigte Einsatz, um am System Modifikationen vorzunehmen
564
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - Qualitätsfaktoren 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 machenWiederverwendbarkeit (Reusability)Das Ausmaß, zu dem das System (oder Teile daraus) in anderen Applikationenverwendet werden kannInteroperabilität (Interoperability)Der benötigte Einsatz, um ein System mit anderen zu verbinden
Diese Liste ist natürlich noch erweiterbar!
565
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - Qualitätskriterien Zugangsprüfung (Access audit)Die Einfachheit, mit der auf Software und Daten zugegriffen werden kannZugangskontrolle (Access control)Die Vorkehrungen zur Kontrolle und zum Schutz von Software und DatenGenauigkeit (Accuracy) Präzision der Berechnungen und der AusgabeAllgemeinheit der Kommunikation (Communication commonality)Das Ausmaß, zu dem Standard-Protokolle und –Schnittstellen Verwendung findenVollständigkeit (Completeness)Volle Implementierung der benötigten FunktionalitätKommunikativität (Communicativeness)Die Einfachheit, mit der Eingabe und Ausgabe verbunden werden könnenKompaktheit (Conciseness)Die Kürze des Source-Codes (Lines of Code)
566
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - QualitätskriterienKonsistenz (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äsentationenFehlertoleranz (Error tolerance)Kontinuität der Ausführung bei Vorliegen von unvorhergesehenen EreignissenEffizienz der Ausführung (Execution efficiency)Laufzeitverhalten des SystemsErweiterbarkeit (Expandability)Das Ausmaß, zu dem gesteigerte Speicheranforderungen oder gesteigerte Anforderungen an die Funktionalität berücksichtigt werden könnenAllgemeinheit (Generality)Die “Breite” der möglichen Einsatzbereiche von Software-KomponentenHardware-Unabhängigkeit (Hardware independence)Das Ausmaß, zu dem die Software von der verwendeten Hardware abhängig ist
567
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - Qualitätskriterien 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öglichtModularität (Modularity) Grad der Unabhängigkeit der einzelnen ModuleAusführbarkeit (Operability)Die Einfachheit der AusführungSelbsterklärung (Self-documentation)Der Umfang an in-line Kommentaren zur Beschreibung der ImplementationEinfachheit (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. Non-Standard Sprachkonstrukte, Betriebssystem, Bibliotheken, ...)Speichereffizienz (Storage efficiency)Speicherbedarf zur Laufzeit des Systems
568
6 Projektkontrolle6.3 Qualitätsmanagement
McCall, Richards, Walters (1977) - QualitätskriterienNachvollziehbarkeit (Traceability)Die Möglichkeit, Software-Komponenten mit der Anforderungsdefinition in Verbindung zu setzenTraining (Training)Die Einfachheit, mit der neue Benutzer vom System Gebrauch machen können
Diese Liste ist natürlich noch erweiterbar!
569
6 Projektkontrolle6.3 Qualitätsmanagement
SW-Qualität und ISO 91266 Qualitätsmerkmale
Funktionalität: Richtigkeit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, SicherheitZuverlässigkeit: Reife, Fehlertoleranz, WiederherstellbarkeitBenutzbarkeit: Verständlichkeit, Erlernbarkeit, BedienbarkeitEffizienz: Zeitverhalten, VerbrauchsverhaltenÄnderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, PrüfbarkeitÜbertragbarkeit: Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit
570
6 Projektkontrolle6.3 Qualitätsmanagement
DIN ISO 9126Funktionalität: Vorhandensein von Funktionalität entsprechend den Anforderungen
Richtigkeit: Liefern der Richtigen Werte in bestimmter GenauigkeitAngemessenheit: Eignung der Funktionen für best. AufgabengebieteInteroperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuarbeitenOrdnungsmäßigkeit: Erfüllung Anwendungsspezifischer Normen und GesetzeSicherheit: Fähigkeit, unberechtigten Zugriff zu Verhindern
571
6 Projektkontrolle6.3 Qualitätsmanagement
DIN ISO 9126Zuverlässigkeit: Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu erbringen
Reife: geringe Versagenshäufigkeit durch FehlzuständeFehlertoleranz: Fähigkeit, Leistungsniveau bei SW-Fehlern oder Schnittstellen-Fehlern einzuhaltenWiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen (benötigte Zeit, Aufwand)
572
6 Projektkontrolle6.3 Qualitätsmanagement
DIN ISO 9126 Effizienz: Verhältnis zwischen Leistungsniveau der SW und Umfang der eingesetzten Betriebsmittel
Zeitverhalten: Antwortzeiten, Verarbeitungszeiten, DurchsatzVerbrauchsverhalten: Anzahl und Dauer der benötigten BetriebsmittelBenutzbarkeit: Aufwand für Benutzung, Beurteilung von BenutzergruppenVerständlichkeit: Aufwand für Verständnis von Konzept und AnwendungErlernbarkeit: Aufwand für Erlernen der BedienungBedienbarkeit: Aufwand für Bedienung
573
6 Projektkontrolle6.3 Qualitätsmanagement
DIN ISO 9126Änderbarkeit: Aufwand für Korrekturen, Verbesserungen, Anpassungen
Analysierbarkeit: Aufwand zur Diagnose von Mängeln und Ursachen für VersagenModifizierbarkeit: Aufwand zur Ausführung von Verbesserungen, Fehlerbeseitigung oder AnpassungStabilität: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von ÄnderungenPrüfbarkeit: Aufwand zur Prüfung geänderter Software
574
6 Projektkontrolle6.3 Qualitätsmanagement
DIN ISO 9126 Übertragbarkeit: Eignung zur Übertragung in andere SW oder HW Umgebung
Anpassbarkeit: Möglichkeit der AnpassungInstallierbarkeit: Aufwand zur InstallationKonformität: Grad des Einhaltens von Normen für ÜbertragbarkeitAustauschbarkeit: Möglichkeit, diese SW anstelle einer anderen zu verwenden
575
6 Projektkontrolle6.3 Qualitätsmanagement
QualitätssicherungIEEE-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 8402Qualitätssicherung ist Teil der Managementfunktionen, die die Qualitätspolitik bestimmen und über ihre Einhaltung wachen.
576
6 Projektkontrolle6.3 Qualitätsmanagement
Aufgaben der Software QualitätssicherungSicherstellen, dass Tätigkeiten genau in der Art durchgeführt werden, wie sie geplant warenErhöhung der Softwarequalität durch ständige Beobachtung der Software und ihres EntwicklungsprozessesSicherstellen der Übereinstimmung zwischen etablierten Standards bzw. Vorgehensmodellen und dem EntwicklungsprozessSicherstellen, dass ein nicht entsprechendes Produkt, sein Entwicklungsprozess bzw. der angewandte Standard dem Management bekannt wird damit Gegenmaßnahmen getroffen werden können
577
6 Projektkontrolle6.3 Qualitätsmanagement
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
578
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische VerfahrenAnsatz:
Keine Qualität per se:- Feststellen der Qualität nach der Realisierung- Korrektur zur Qualitätssteigerung
Meist: Funktionalität, Zuverlässigkeit, ÄnderbarkeitVerfahren:
Analysierend = statische Überprüfung:- Statische Analyse- Review- Verifikation
Testend = Überprüfen in der Ausführung:- Funktionaler Test- Strukturtest
579
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Statische AnalyseBewerten des Produkts mittels MetrikenSchwerpunkt: Zuverlässigkeit, ÄnderbarkeitVerschiedene Metriken:
Komponenten:- Umfang: LOC- Innere Struktur: Kontrollflusskomplexität- Schnittstelle: Anzahl Methoden/Klasse, Schnittstellenbreite
Systeme:Umfang: LOCKopplung: Anzahl Aufrufe in/aus KomponenteOO-Metriken
580
6 Projektkontrolle6.3 Qualitätsmanagement
Beispiele: MetrikenKomponentenmetriken: „algorithmische“ Komplexität
Halstead: Anzahl (verwendeter) Opertoren/OperandenMcCabe: Anzahl Knoten/Kanten Kontrollflussgraph
Strukturmetriken:Komponenten/SubkomponentenSchnittstellenkomplexität (Anzahl, Breite, Struktur)
Weitere:OO-Metriken: Anzahl Vererbungsstufen, Attribute, MethodenFokus auf Implementierungsgüte
581
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Manuelle PrüfungArten:
InspektionReviewWalkthroughAudit
Ziel: Identifikation von ProduktdefektenTechnik:
Prinzip: Manuelles PrüfverfahrenProdukte: i.a. Dokumente (Spez.,Code)Vorgaben: Richtlinien, ChecklistenVorgang: Individuelle/moderierte BegutachtungErgebnis: Freigabe/Änderungsprotokoll
582
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: InspektionInspektion:
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 werdenAnsatz: 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.
583
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: InspektionSchritte:
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 ReferenzdokumentenIndividuelle 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)
584
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughReview:
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 festgelegtZiel: Identifikation Defekte/Standardabweichung, FreigabeDokumente: Prüfprodukt, ReferenzdokumenteRollen: Moderator, Autor, Protokollführer, GutachterVerfahren:
- Eingangsprüfung, Individualprüfung- Reviewsitzung- Überarbeitung
Walk-Through:Ziel: Identifikation von Defekten, Vermittlung von InhaltenDokumente: PrüfproduktRollen: Autor, GutachterVerfahren: Gruppensitzung
585
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughQualitä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; ...
586
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughProzeß eines technischen Reviews:
selektiereReview-Team
bestimme Ortund Zeit
verteileUnterlagen
halte Review-Sitzung ab
notiere Aktionen undführe Änderungen durch
587
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughKommentare 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!
588
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughKommentare 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.
589
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughProjektreview (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 wieWechsel des Projektleiters, Auftraggeber-Probleme,...
Zusammensetzung des Reviewteams:Gutachter, Moderator, Projektleiter, Vorsitzender des Projektleiters, ProjektmitarbeiterVoraussetzungen:
- 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
590
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughProzeß eines Projektreviews:
Planungssitzungabhalten
Reviewvorbereiten
Reviewsitzungabhalten
analysiereErgebnisse
setze erlasseneMaßnahmen um
591
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughKommentare 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
592
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: Review/Walk-ThroughKommentare 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,...) zwecksEntscheidung über das weitere Vorgehen übermittelt.
ad Umsetzung: Projektleiter modifiziert den Projektplan und führt das Projekt gemäß derneuen Planung weiter
593
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: ProjektauditDefinition:Ein Audit ist eine Aktivität, bei der sowohl die Angemessenheit und Einhaltungvorgegebener Vorgehensweisen, Anweisungen und Standerds als auch derenWirksamkeit 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;
594
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: ProjektauditAblauf:
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?
595
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: ProjektauditAuditsitzung: (Leitung: Auditleiter)
Beurteilung aller aufgeführten Analysedaten;Ordnung von Negativ- und Positivwerten und Herausfinden von deren systembedingtenUrsachen;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ß.
596
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: VerifikationZiel: Vollständige Überprüfung der KorrektheitTechnik:
Formalisierung (Teil-)SpezifikationFormalisierung ImplementierungMathematische Überprüfung
Verfahren:Interaktiv (Theorembeweiser)Automatisch (Model Checker)
Einschränkung:U.U. aufwendigÜberprüfung der Formalisierungen
597
6 Projektkontrolle6.3 Qualitätsmanagement
Analytische Verfahren: TestenDefinition: Testen ist der Prozeß, ein SW-Produkt durch manuelle oder automatisierteHilfsmittel zu bewerten, um damit die Erfüllung der speziellen AnforderungennachzuweisenTestziele:
Funktionalität: RichtigkeitZuverlässigkeit: Fehlertoleranz, Reife
Testprinzip:Überprüfung Implementierung vs. SpezifikationÜberprüfungsmittel: TestfälleTestgüte: Überdeckung des TestraumsSpezialfall: Regressionstest (Änderungstest)
598
6 Projektkontrolle6.3 Qualitätsmanagement
Testen: Formen und VerfahrenAnsätze:
Strukturtest (Glass-Box-Test):- Kontrollflussorientiert- Datenflussorientiert
Funktionaler Test (Black-Box-Test)- Aquivalenzklassentest- Testen spezieller Werte- Zufallstest- Test von Automaten
599
6 Projektkontrolle6.3 Qualitätsmanagement
Testen: PfadüberdeckungZiel: Umfassende TestfallgenerierungVerfahren:
Implementierung als KontrollflussgraphFür jeden Pfad im Graph einen TestfallPraxis: Maximale Pfadlänge
600
6 Projektkontrolle6.3 Qualitätsmanagement
Testen: Schritte im ProzessTest: konstruktive und analytische AnteileTesten 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
601
6 Projektkontrolle6.3 Qualitätsmanagement
Konstruktive VerfahrenAnsatz:
A-priori-Absicherung der ProduktqualitätVorgabe von KonstruktionstechnikenPräventiv (keine Behebung erforderlich)
Techniken:Methoden (Beispiel: SA)Sprachen (Beispiel: Java statt C++)Richtlinien (Beispiel: NASA Coding Standard)Checklisten, Vorlagen
602
6 Projektkontrolle6.3 Qualitätsmanagement
Konstruktive Verfahren: MethodenZiel:Strukturierte VorgehensweiseTechnik: Vorgabe von Zwischenprodukten
Vorgaben von Modellen (z.B. ObjektorientierteVorgabe von Einzelschritten (z.B. OOA mit fachl. Klassenmodell, Use Case-Modellierung)Vorgabe von Erstellungsmittel (z.B. Klassendiagramm, Objektdiagramm, Use CaseDiagramm)
Ansätze:SA: Datenfluss, StrukturSSADM:Funktion, Struktur,ProzessOAAD:Daten, Struktur, Prozess
Zusätzlich:ÄnderbarkeitWerkzeugunterstützung
603
6 Projektkontrolle6.3 Qualitätsmanagement
Konstruktive Verfahren: RichtlinienZiel: Produkteigenschaften a-priori festlegenTechnik:
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
605
6 Projektkontrolle6.3 Qualitätsmanagement
Was kostet Qualität?Ziel: Vermeidung von QualitätsmängelnBisher:
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?
StrategieQualitätProduktivität
606
6 Projektkontrolle6.3 Qualitätsmanagement
Fehlerarten im Prozess
Wann werden welche Fehler gemacht:Fatal: AnforderungsdefinitionSchwer: EntwurfMittel, leicht: Entwurf, Umsetzung
607
6 Projektkontrolle6.3 Qualitätsmanagement
Aufwand
Aufwand:Ausführung: wenig UnterschiedeVorbereitung/Behebung: frühe Aktivitäten effizienter
608
6 Projektkontrolle6.3 Qualitätsmanagement
Effektivität
Effektivität:Nur Testen: 1 von 4 Mängel unentdecktFrühe Mängel benötigen frühe MaßnahmenHohe Qualität: Kombinierte Ansätze
609
6 Projektkontrolle6.3 Qualitätsmanagement
Produktqualität im EntwicklungsprozessGenerell:
Schwerwiegende Mängel zu ProzessbeginnKosten Fehlerbehebung steigen (bis zu x10)Analyse/Entwurfsmängel schwer testbar
Aber:Qualitätssicherung oft erst nachgelagert
Für hohe Qualität:Fehler frühzeitig findenFehler vermeiden anstatt finden
610
6 Projektkontrolle6.3 Qualitätsmanagement
Qualität und ProduktivitätKonstruktive Maßnahmen
Strukturierte MethodenWerkzeuggestützte EntwicklungHohe Programmiersprachen
Konstruktive Verfahren:Verlagerung Aktivitäten in frühe PhasenWirken präventivUnterstützen Anpassbarkeit (Wiederverwendung)
Resultat:QualitätssteigerungEffektivitäts/Produktivitätssteigerung
611
6 Projektkontrolle6.3 Qualitätsmanagement
Qualität und WerkzeugeUnterstützend: Projekt, KonfigurationAnalytische Werkzeuge:
Metriken: Messwerkzeuge für KennzahlenTest: Testwerkzeuge
Konstruktive Werkzeuge:Sprachen: BasiswerkzeugeRichtlinien: PrüfwerkzeugeMethoden: Analyse/Entwurfswerkzeuge
Nutzen:Steigerung der Qualität (50%)Steigerung der Produktivität (30%)
612
6 Projektkontrolle6.3 Qualitätsmanagement
Zusammenfassung Produktqualität ist anforderungsabhängigMaßnahmen zur Qualitätssicherung:
Test sichert Qualität nach/bei RealisierungFrühzeitige Maßnahmen möglich:
ReviewsKonstruktive Maßnahmen (Verfahren, Werkzeuge)Strategie: Frühzeitige Qualitätssicherung
Verbessert QualitätVerbilligt QualitätErhöht Produktivität
Berücksichtigung Qualitätssicherung im Prozess
613
Kapitel 6:Projektkontrolle
Projektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolle
614
6 Projektkontrolle6.4 Fortschrittskontrolle
Generell VorgehensweiseBasis aller Vergleiche ist der detaillierte Projektplan (baseline)
Erstellt in der ProjektplanungsphaseEvtl. überarbeitet in der vorausgegangenen Periode
Erfassung des aktuellen Status (hier unterscheiden sich die Methoden)SOLL/IST Vergleich auf Basis vorab definierter Metriken (key performanceindicators)Ableitung geeigneter Gegenmaßnahmen (falls notwendig)
616
6 Projektkontrolle6.4 Fortschrittskontrolle
MeilensteineMeilensteine bezeichnenDefinierte Sachergebnisse (Meilenstein-Inhalt)Fertigstellungstermin (Meilenstein-Termin)
Meilenstein-Inhalte sindwesentlichüberprüfbarübergebbareindeutig festgelegtvoraus definiert (Phasenorganisation)
Meilenstein-Termine werden in der Projektplanung ermittelt
617
6 Projektkontrolle6.4 Fortschrittskontrolle
MeilensteintrendanalyseZiel:
Prognostizierung TermineErhöhung Planungssicherheit: Erkennen Schätzfehler
Verfahren:Status: Regelmäßige Erfassung geplanter TerminePrognostizierung: Interpolation ÄnderungenPropagierung: Änderung abhängiger TermineVerifizierung: Berücksichtigung Streuung
Erkennbare Planungsfehler: IndikatorenUnrealistische Schätzung:
- (Super)lineare Verschiebungen- Starke Schwankungen
Späte Neuschätzung: Terminasymptoten
618
6 Projektkontrolle6.4 Fortschrittskontrolle
Meilensteintrendanalyse
Verfahren:Regelmäßige Erfassung StatusErfassung pro MeilensteinKeine rückwirkende Änderungen
619
6 Projektkontrolle6.4 Fortschrittskontrolle
Berichtszeitpunkte
Meilenstein-Termine
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
200x
200x
200x
200x
200x
200x 200x 200x 200x 200xI II III IV I II III IV I II III IV I II III IV I II III IV
Projekt: xxxProjektleiter: xxx
620
6 Projektkontrolle6.4 Fortschrittskontrolle
2
BerichtszeitpunkteBerichtszeitpunkte
Berichtszeitpunkte BerichtszeitpunkteM
eile
nste
in-T
erm
ine
1
3 4
Ausgangssituation nach Planung
Erste Projektbesprechung mit Terminkontrolle nach einem Monat
Zweite Projektbesprechung mit Terminkontrolle nach zwei Monaten
Dritte Projektbesprechung mit Terminkontrolle nach drei Monaten
1
2
3
4
Mei
lens
tein
-Ter
min
e
Mei
lens
tein
-Ter
min
eM
eile
nste
in-T
erm
ine
621
6 Projektkontrolle6.4 Fortschrittskontrolle
Meilensteintrendanalyse
Erkennbare Fehler:Unterschätzung M1: Wiederholte Verschiebung (Messfehler)Überschätzung M2: Überhöhte Verschiebung (Planungsfehler)Fehlende Schätzung M3: Späte Verschiebung (Planungsfehler)
622
6 Projektkontrolle6.4 Fortschrittskontrolle
BasisplanungDie Basisplanung (baseline) muss bereits an die zur Statusüberwachungausgewählte Technik angepasst sein
Detailgrad/Granularität der PlanungGliederung 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 FertigstellungsgradsZeitliche Effekte (Lernkurve, Urlaub, ...) sind eingerechnet
623
6 Projektkontrolle6.4 Fortschrittskontrolle
Ansätze zur Ermittlung der aktuellen Zahlen bzw. Zukunftsschätzungen
Ist-Zahlen kommen aus Zeitaufschreibung aller ProjektbeteiligterIn 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“
625
6 Projektkontrolle6.4 Fortschrittskontrolle
Zeitorientierte FortschrittskontrolleBaseline enthält Budgets für alle (Teil-)Aufgaben, die einzelnen Mitarbeitern (oder Gruppen von Mitarbeitern) zugewiesen sindBasierend 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
626
6 Projektkontrolle6.4 Fortschrittskontrolle
Probleme bei der zeitorientierten FortschrittskontrolleSchä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 EinarbeitungsaufwandInformationsstand ü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)
627
6 Projektkontrolle6.4 Fortschrittskontrolle
Ergebnisorientierte AnsätzeStatus wird an Ergebnissen festgehaltenStatus eines Ergebnisses kann sein: offen, in Arbeit, fertigZurechnung des Budgets nur bei Erreichen eines StatusUnterschiedliche Ansätze werden verwendet:
50% bei Start einer Aufgabe, 50% bei Abschluss100% bei AbschlussNach vorher definieren Anteilen (Beispiel: bei 10 zu erstellenden Modulen 10% je fertiges Modul)
Vorgehensweise muss bereits in der Planungsphase definiert und verwendet werden
628
6 Projektkontrolle6.4 Fortschrittskontrolle
VorteileSicherer Status (eher etwas pessimistisch)Weniger Know-how der Mitarbeiter notwendig bei Einschätzung von Restaufwänden
NachteileNur 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
629
6 Projektkontrolle6.4 Fortschrittskontrolle
Ziele von MetrikenEs 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 verwendenEine überschaubare Anzahl zu habenSie einheitlich und durchgängig zu verwenden
630
6 Projektkontrolle6.4 Fortschrittskontrolle
Earned Value Analyse (EVA)Gemessen wird der aktuelle Projektfortschritt im Vergleich zu dem baselineBudget.Integriert Kosten, Zeitplan und geleistete ArbeitAuch bekannt als Budgeted Cost of Work PerformedKann für Kosten in unterschiedlichen Einheiten (Personentage, Geld) verwendet werden
631
6 Projektkontrolle6.4 Fortschrittskontrolle
Kernkomponenten (Key Performance Indicators KPI)Folgende Basiskennzahlen werden aus den tatsächlichen Aufwändensowie den geschätzten Restaufwänden errechnet:
BCWP – Budgeted Cost of Work Performed - earned value TatsächlicheErgebnisse bewertet zu geplanten KostenACWP – Actual Cost of Work Performed – burnedTatsächliche Ergebnisse bewertet zu tatsächlichen KostenBCWS – Budgeted Cost of Work Scheduled – scheduledBis zum Stichtag geplante Arbeit bewertet zu geplanten KostenBCAC – Budgeted Cost at Completion – baselineGeplantes Gesamtbudget bei Fertigstellung
632
6 Projektkontrolle6.4 Fortschrittskontrolle
BeispielTeam A (2 Mitarbeiter):
10 Module a 10 PT in 10 Wochen erstellenLineare Verteilung der Arbeit (1Modul/Woche)
Aktuelle Zahlen nach Ende der Woche 2:2 Module wurden komplett geliefertTatsä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
633
6 Projektkontrolle6.4 Fortschrittskontrolle
Abgeleitete KennzahlenAus diesen Basiszahlen können eine Vielzahl von Kennzahlen abgeleitet werden.Betrachtet werden sollen im weiteren Kennzahlen zu
Kostenabweichungen: BCWP – ACWPAbweichungen im Zeitplan: BCWP – BCWS
Kosten- und Zeitplanabweichungen müssen stets gemeinsam betrachtet werden, sonst sind falsche Interpretationen vorprogrammiert
634
6 Projektkontrolle6.4 Fortschrittskontrolle
Beispiele für abgeleitete KennzahlenCV – Cost Variance - Kostenabweichungen : BCWP – ACWPSV – Schedule Variance - Abweichungen im Zeitplan : BCWP – BCWSCPI – Cost Performance Index: BCWP/ACWP = CEI – Cost Efficiency IndexSPI – Schedule Performance Index: BCWP/BCWS = SEI – Schedule Efficiency IndexETC – Estimate to Complete: (BCAC – BCWP)/CPIEAC – Estimate at Completion: ETC + ACWPTCPI - To-Complete Productivity Index:(BCAC - BCWP) / (BCAC - ACWP)
635
6 Projektkontrolle6.4 Fortschrittskontrolle
Beispiele für abgeleitete KennzahlenCV – Cost Variance - Kostenabweichungen : BCWP – ACWPSV – Schedule Variance - Abweichungen im Zeitplan : BCWP – BCWSCPI – Cost Performance Index: BCWP/ACWP = CEI – Cost Efficiency IndexSPI – Schedule Performance Index: BCWP/BCWS = SEI – Schedule Efficiency IndexETC – Estimate to Complete: (BCAC – BCWP)/CPIEAC – Estimate at Completion: ETC + ACWPTCPI - To-Complete Productivity Index:(BCAC - BCWP) / (BCAC - ACWP)
636
6 Projektkontrolle6.4 Fortschrittskontrolle
Interpretation von KennzahlenIm folgenden werden neun mögliche Fälle des Vergleichs von CV und SV (Costund Schedule Varianzen ) betrachtetDie aufgeführten Gründe und möglichen Lösungsansätze sind nur exemplarischund auf keinen Fall als Kochbuch zu verstehen (aber als gute Anhaltspunkte!)Ähnliche Überlegungen können ebenfalls für die anderen aufgelisteten Kennzahlen erarbeitet werden
637
6 Projektkontrolle6.4 Fortschrittskontrolle
Negative CV / Positive SVMögliche Gründe
Zu großzügige TermineZu viele MitarbeiterHoher Terminfokus zu Lasten der KostenUnnötige Überstunden
Mögliche LösungenBegrenzung der ÜberstundenAbziehen von Mitarbeiter von dem BereichVerständnis für Kosten wecken
638
6 Projektkontrolle6.4 Fortschrittskontrolle
Keine CV, Positive SVMö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ösungenAbhängigkeiten im Projektplan betrachtenSicherstellen, dass die Aufgaben auch komplett abgeschlossen werden (keine 80% fertig Lösungen)Begrenzung der ÜberstundenGgf. Mitarbeiter zu anderen Aufgaben einteilen
639
6 Projektkontrolle6.4 Fortschrittskontrolle
Positive CV, Positive SVMögliche Gründe
Exzellentes Team mit sehr viel Erfahrung oder sehr konservativer Projektmanager in der PlanungsphaseABER:
- Versteht das Team die Aufgaben wirklich?- Werden „Abkürzungen“ benutzt und komplizierte Teile nach hinten verschoben (z.B. unzureichende
Tests)
Mögliche LösungenQualitä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
640
6 Projektkontrolle6.4 Fortschrittskontrolle
Negative CV / Keine SVMögliche Gründe
Unerfahrenes Team, falsch einkalkulierte LernkurveÜbermäßiges QualitätsbewusstseinHoher zeitlicher Einsatz der Mitarbeiter (zu Gunsten des Termins)Zu großzügige Terminplanung, Team macht zusätzliche Arbeit („goldene Wasserhähne“)
Mögliche LösungenAusbildung des Teams verbessern (Coaching etc.)Zeitplanung überprüfen und ggf. anpassenÜberstunden begrenzen (Achtung auf Zeitplan!)Verständnis für Qualitätsanforderungen wecken
641
6 Projektkontrolle6.4 Fortschrittskontrolle
Keine CV, keine SVMö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 (continuousimprovement)
642
6 Projektkontrolle6.4 Fortschrittskontrolle
Positive CV, keine SVMö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ösungenQualität überprüfenZeitbelastung der Mitarbeiter durch andere Aufgaben betrachtenAusgleich der Ressourcen mit anderen Team
643
6 Projektkontrolle6.4 Fortschrittskontrolle
Negative CV / Negative SVMögliche Gründe
„Alles Sch...“ (Normalsituation!)Passt der Umfang noch (scope creep)?Zusammensetzung des Teams, Lernkurve richtig eingeschätzt?...
Mögliche LösungenTeamzusammensetzung übeprüfen, ggf. AusbildungScope Management überprüfenPlanung anpassen (aber bitte nicht ständig...)Das gesamte Repertoire des Projektmanagers kann eingesetzt werden...
644
6 Projektkontrolle6.4 Fortschrittskontrolle
Kein CV, Negative SVMögliche Gründe
Arbeiten die Projektmitarbeiter wie geplant an den Aufgaben?Überlastung der Mitarbeiter durch andere Aufgaben
Mögliche LösungenUrlaub, sonst Abwesenheit der Mitarbeiter entsprechen eingeplant?Berichten die Mitarbeiter ihre Zeiten korrekt?
645
6 Projektkontrolle6.4 Fortschrittskontrolle
Positive CV, Negative SVMögliche Gründe
Erfahrenes TeamFehlende Mitarbeiter im TeamPlanung ging von zu vielen verfügbaren Arbeitstagen ausArbeiten die Projektmitarbeiter wie geplant an den Aufgaben?
Mögliche LösungenZu erfahrene Ressourcen anders einsetzenZusätzliche Ressourcen einsetzen (wenn dies Sinn macht!)Verfügbarkeit der Mitarbeiter realistischer planen
646
6 Projektkontrolle6.4 Fortschrittskontrolle
Beispiele für abgeleitete KennzahlenCV – Cost Variance - Kostenabweichungen : BCWP – ACWPSV – Schedule Variance - Abweichungen im Zeitplan : BCWP – BCWSCPI – Cost Performance Index: BCWP/ACWP = CEI – Cost Efficiency IndexSPI – Schedule Performance Index: BCWP/BCWS = SEI – Schedule Efficiency IndexETC – Estimate to Complete: (BCAC – BCWP)/CPIEAC – Estimate at Completion: ETC + ACWPTCPI - To-Complete Productivity Index:(BCAC - BCWP) / (BCAC - ACWP)
647
6 Projektkontrolle6.4 Fortschrittskontrolle
BeispielWir 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.
650
6 Projektkontrolle6.4 Fortschrittskontrolle
CPI und SPI grafisch dargestellt am Beispiel eines gutgemanagten Projekts
651
6 Projektkontrolle6.4 Fortschrittskontrolle
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.
652
6 Projektkontrolle6.4 Fortschrittskontrolle
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)
653
6 Projektkontrolle6.4 Fortschrittskontrolle
Fallbeispiel: Gängige mögliche Kombinationen von CPI- und SPI-Werten und ihre Interpretationen
Zu teuer, aber vor Zeitplan1,250,8310001200800
Erfreulich; Wurden zu viele Puffer eingebaut?1,251,671000600800
Zu teuer, aber im Zeitplan1,000,808001000800
Kostengünstiger und genau im Zeitplan; Überoptimaler Fall1,001,33800600800
Genau im Kostenplan und vor Zeitplan; Überoptimaler Fall1,251,0010001000800
Kostengünstiger und vor Zeitplan; Überoptimaler Fall1,251,251000800800
Kosten o.k., aber hinter Zeitplan
Zwar kostengünstig, aber hinter Zeitplan; Warum wurden die Kosten so überschätzt?
Zu teuer und noch weiter hinter Zeitplan; einer der schlimmsten Fälle
Optimaler Fall
Interpretation
0,75
0,75
0,50
1,00
SPI
600
400
600
800
AC
1,00
1,50
0,67
1,00
CPI
600
600
400
800
EV
800
800
800
800
PV
654
6 Projektkontrolle6.4 Fortschrittskontrolle
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
655
6 Projektkontrolle6.4 Fortschrittskontrolle
Untere Management interessiert sich meistens für:
KostensituationEntwicklungskosten, z.B. aus der EVA (CPI, EAC, …)Bei Großserien im Bereich Embedded Systems: Prognose der Stückkosten verglichen mit den geplanten Kosten
TerminsituationVoraussichtlicher Endtermin, SPI (aus der EVA)Termintrends aus der MTA
LeistungsumfangWird die geforderte Funktionalität geliefert oder gibt es Abweichungen?
QualitätssituationWie ist die Produktqualität? (Z.B. wie viele Fehler der verschiedenen Schweregrade gibt es?)Gibt es direkt kundenrelevante Probleme?
PersonalstatusGibt es kritische personelle Engpässe in Projekten?
RisikenZusammenfassung der Risiken, z.B. Top 5 oder Top 10 Risiken und Chancen, bei komplexen Großserienprodukten im Bereich EmbeddedSystems 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
656
6 Projektkontrolle6.4 Fortschrittskontrolle
Mittlere Management hat eine deutlich größere Anzahl von Projekten zu überschauen und erhält meistens stark zusammengefasste „Ampelberichte“
657
6 Projektkontrolle6.4 Fortschrittskontrolle
Topmanagementbei 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?
658
6 Projektkontrolle6.4 Fortschrittskontrolle
Lessons LearnedAlle 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
659
6 Projektkontrolle6.4 Fortschrittskontrolle
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!
660
ProjektmanagmentErster Überblick über die Vorlesung
1. Einleitung
2. Faktor MenschTeamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken
3. ProjektinitiierungGründung eines ProjektsWirtschaftlichkeitsbetrachtungProdukt-/Systemdefinition
661
ProjektmanagmentErster Überblick über die Vorlesung
4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung
5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen
662
ProjektmanagmentErster Überblick über die Vorlesung
6. ProjektkontrolleProjektrisiken und RisikomanagementKonfigurations- und VersionsmanagementQualitätsmanagementFortschrittskontrolleChange-ManagementKostenkontrolle
7. Projektabschluss und ProzessverbesserungProzessverbesserungProjektabschluss
664
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.
665
7 Projektabschluss und Prozessverbesserung
Bedeutung für ProjektmanagerLetzte Möglichkeit, die Ergebnisse, die das Projekt erbringen soll, direkt zu beeinflussen
Eindruck des Sponsors und der Anwender positiv beeinflussenOffene Punkte/Probleme/Issues abschließenRichtung für langfristigen Erfolg vorgeben
Leistung des Projekts kritisch bewertenMethoden, Tools, VorgehensweisenEntscheidungen, eigenes Verhalten
Erfolgreiche Übergabe an die zuständige Organisation zur Betreuung
666
7 Projektabschluss und Prozessverbesserung
Aufgaben:Formaler ProjektabschlussAuswertung ProjekthistorieErstellung Projektabschlussbericht
Ziel:Gesamtbeurteilung ProjektBewertung Projektergebnis (Ist/Soll-Vergleich)Dokumentation von ErfahrungenIdentifikation von Problemen und DefizitenVorbereitung Prozessverbesserung
667
Kapitel 7:Projektabschluss und Prozessverbesserung
Prozessverbesserung – ReifegradmodelleProjektabschluss
668
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Beobachtung: Qualitätsverbesserung führt zuReduktion der EntwicklungszeitReduktion der EntwicklungskostenSteigerung der Wettbewerbsfähigkeit
Ansatz:Verbesserung EntwicklungsqualitätVerbesserung 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)
669
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Strukturierte VerbesserungsansätzeZiele:
Bereitstellung systematisches VorgehenRichtlinen für ProzesserfassungMetriken für ProzessbewertungMaßnahmen zur ProzessverbesserungEnthalten „Best Practices“
Beispiele:EFQM (European Foundation of Quality Management): abstrakter, ganzheitlicher Ansatz, fragebogenbasiertCMM (Capability Maturity Model): Reifegradbasiert, assessmentorientiert – Entwicklung eingestelltBOOTSTRAP: ähnlich CMM, detaillierter, flexiblerSPICE (Software Process Improvement and Capability Determination): ähnlich CMM, ISO-basiert, integriert ISO 9000, detallierter, umfassender
670
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
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.
671
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
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 ProzessbeschreibungenAnpassung 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.
672
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
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) sowieStä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.
673
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
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ätReduktion des Risikos
Verfahren: Stufenorientiert5 Stufen zur Einordnung der aktuellen Prozessreife („maturity“)Feststellung der Einordnung mittels fragebogenbasierten AssessmentsStrukturierte Handlungsempfehlungen entsprechend Prozessreife
674
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
CMM Schlüsselbereiche(Key process areas):
Gebündelt zu ReifegradenDefinierten 18 Hauptkriterien für ReifedefinitionUntergliedert in Unterverfahren (keypractices)Definieren, was in einem Schlüsselbereich zu tun istDefinieren nicht, wie es zu tun ist
675
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
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.
676
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
„Helden“Initial (1)
AnforderungsmanagementSoftware-ProjektplanungSoftware-Projektsteuerung und –verfolgungSoftware-UnterauftragnehmermanagementSoftware-QualitätssicherungSoftware-Konfigurationsmanagement
Projektmanagement und VerpflichtungsprozessWiederholbar (2)
Organisationsweiter ProzessfokusOrganisationsweite ProzessdefinitionTrainingsprogrammIntegriertes SoftwaremanagementSoftware-ProduktentwicklungKoordination zwischen GruppenPartner-Reviews
Definierter ingenieurmäßiger ProzessDefiniert (3)
Quantitatives ProzessmanagementSoftware-Qualitätsmanagement
Produkt- und ProzessqualitätGeleitet (4)
FehlerverhütungTechnologie-ÄnderungsmanagementProzess-Änderungsmanagement
Schlüsselprozessbereich
Kontinuierliche Prozessverbesserungen
Fokus
Optimierend (5)
Stufe (Level)
Architektur von CMM
677
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
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
685
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
CMM: AssessmentfragebögenBeispiel: 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 entsprechenWerden 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?
686
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Produktionsgüte
Zuverlässigkeit des ausgelieferten SystemsAbhängig von „built-in“ Qualität/prozessbegleitendes QualitätsmanagementGüte der Fehleridentifikation- und behebung in Integration und Test
687
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Fehlerbehebungsgüte
Effizienz der FehlerbehebungMaß: Anteil behobener/identifizierter FehlerAbhängig von Prozessgüte
688
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
SPICESPICE (Software Process Improvement and Capability Determination): ISO/IEC 15504 – Stand Oktober 2003Ziele:
Assessmentmodelle und -verfahren in eine definierte Beziehung zu setzenIntegration existierender Ansätze, z.B.:
- CMM- ISO 9000
Verfahren:Bewertung Entwicklungsprozess mittels AssessmentsUnterteilung in Prozess- und ReifegraddimensionUnabhängige Bewertung ProzessdimensionenIdentifikation von Verbesserungsmöglichkeiten
689
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
DimensionenProzessdimension:
Umfang: 5 Kategorien, 29 Prozesse, 200 AktivitätenKategorien:
- 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 AttributeDefiniert für jede Prozess
Beispiel: Prozessdurchführung, Reifegradstufe 1:Aktivität: Ausführung von Aktivitäten sicherstellenCharakteristika: (z.B.)
- Muster für Ein- und Ausgabeprodukte existieren- Es gibt Verteilungsmechanismus für Arbeitsprodukte
690
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
CMM SPICE
„Optimizing“ „Optimizing“
„Repeatable“
„Managed“
„Defined“
„Initial“
„Predictable“
„Established“
„Managed“
„Performed“
„Incomplete“
5
4
3
2
1
5
4
3
2
1
0
Reifegradstufen SPICE und CMM im Vergleich
692
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
SPICE-Prozessmodell
Customer supportCUS.4.2
System and software maintenanceENG.2Operational useCUS.4.1
Problem ResolutionSUP.8System integration and testingENG.1.7OperationCUS.4
AuditSUP.7Software testingENG.1.6Requirements elecitationCUS.3
Joint ReviewSUP.6Software integrationENG.1.5SupplyCUS.2
ValidationSUP.5Software constructionENG.1.4Customer acceptanceCUS.1.4
VerificationSUP.4Software designENG.1.3Supplier monitoringCUS.1.3
Software requirements analysis
System requirements analysis and design
Development
Quality AssuranceSUP.3ENG.1.2Supplier selectionCUS.1.2
ConfigurationManagement
SUP.2ENG.1.1
Acqusition PreparationCUS.1.1
DocumentationSUP.1
SUPPORTING LIFE CYCLE PROCESSES
ENG.1AcqusitionCUS.1
PRIMARY LIFE CYCLE PROCESSES
693
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Das SPICE-Prozessmodell
Process improvementORG.2.3
ReuseORG.6Process assessmentORG.2.2Risk ManagementMAN.4
Process establishment
Improvement process
Organisational alignment
MeasurementORG.5ORG.2.1Qualitity ManagementMAN.3
InfrastructureORG.4ORG.2Project ManagementMAN.2
Human Resource ManagementORG.3ORG.1ManagementMAN.1
ORGANISATIONAL LIFE CYCLE PROCESSES
694
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
CMMINeben 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 15504allgemeinere Entwicklungsprozesse (insbesondere Systems Engineering)
Entwickelt von Team aus Industrie, US-Regierung und SEI entwickelt. V0.2 im Jahr 1998VI.l Ende 2001erwartete Lebensdauer von vier bis fünf Jahren hat [CMMI 03].
695
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
CMMICMMI - »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.
696
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
CMMI-Prozessmodell
ValidationValidation
VerificationVerification
Product integrationProduct integration
Technical solutionTechnical solution
Requirement developmentRequirement development
Requirement managementLEVEL 3: DEFINED
ENGINEERINGConfiguration management
Qualitative project managementProcess and product quality assurance
Risk managementMeasurement and anlalysis
Integrated project managementSupplier aggreement management
Supplier aggreement managementProject monitoring and control
Project monitoring and controlProject planning
Project planningRequirements management
PROJECT MANAGEMENTLEVEL 2: MANAGED
CONTINUOUS REPRESENTATIONSTAGED REPRESANTATION
697
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Organisational innovation and deploymentCausal analysis and resolution
Organisational process performanceOrganisational innovation and deployment
Organisational trainingLEVEL 5: OPTIMIZING
Organisational process definitionQuanititative project management
Organisational process focusOrganisational process performance
PROCESS MANAGEMENTLEVEL 4: QUANTITATIVELY MANAGED
Causal analysis and resolutionDecision analysis and resolution
Decision analysis and resolutionRist management
Measurement and analysisIntegrated project management
Process and product quality assuranceOrganisational training
Configuration managementOrganisational process definition
SUPPORTOrganisational process focus
CONTINUOUS REPRESENTATIONSTAGED REPRESANTATION
CMMI-Prozessmodell
698
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Reifegradmodelle sind Modelle zurMessung, 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.
699
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Prozessverbesserung: NebenwirkungenStrukturierte Prozessbesserungsansätze:
Ziele:- Messung/Steigerung Prozessproduktivität/Qualität- Messung/Reduktion Risiken
Ansatz: Standardisierung EntwicklungsprozessNebenwirkung:
Zusätzlicher Aufwand für ProzessverbesserungProzessoptimierung nur für traditionelle/StandardproblemeNeue 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
700
7 Projektabschluss und Prozessverbesserung7.1 Prozessverbesserung
Prozessverbesserung: Risiken
Risiko: Verselbstständigte ProzessverbesserungProzessbewertung wichtiger als Prozessverbesserung
- „Ranking“ als Ziel der Prozessbesserung
Übertriebenes Sicherheitsdenken:- Fokussierung auf stabilen Entwicklungsprozess
Auswirkung:Vermeidung risikoreicher InnovationenÜbernahme neuer Anwendungs-/Geschäftsfelder
702
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
ProjektabschlussFormaler Projektabschluss: Definierte Beendigung eines Projekts
Erreichen des ProjektzielsAbbruch 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
703
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
Formale Abnahme durch AuftraggeberAbnahme ist Hauptpflicht des AuftraggebersAbnahmekriterien 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/AbteilungHat 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)
704
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
Inhalt und grobe VorgehensweiseBegriff der Abnahme
Erklärung vs. Verfahrenzweigliedriger Abnahmebegriff: körperliche Entgegennahme und Billigung der Leistung
2 mögliche VorgehensweisenProjektbegleitende Abnahme (dringend empfohlen)„Big bang“ (manchmal nicht anders machbar)
Verfahren und Detailvorgehensweise muss vor der Abnahme bekannt sein (auch Testdaten etc.)
705
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
AbnahmekriterienFür die Abnahme wird die Übereinstimmung mit den sog. Annahmekriterien geprüftEinhaltung von Planungs- und ManagementprozessenDefinition der VerifikationsmethodenDefinition der Zeitdauer der AbnahmeVereinbarung von FehlerklassenZeitdauer für die Behebung von Problemen
Wichtig:Allen Beteiligten muss klar sein, was Abnahme heißt und was die Regeln sind!
706
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
AbnahmephasenAbnahmephasen:
Überprüfung und Vollständigkeitskontrolle des vom Auftragnehmer gelieferten Programms einschl. DokumentationInstallation und anschl. Test in TestumgebungPerformancetests auf Basis vereinbarter MengenprofileTest des störungsfreien Wiederanlaufs nach Abbruch oder Stromausfall
Auftraggeber trägt:Verantwortung für Aufbau und Betrieb TestumgebungVerantwortung für Testfälle und -daten
707
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
Rechtliche AuswirkungenVermutung der vollständigen LieferungMangelausschluss (§ 640 II BGB)Untersuchungs- und Rügepflichten (§ 377, 381 II HGB)Mängelbeseitigungs- statt ErfüllungsanspruchBeweislastumkehrGefahrenübergangNutzungsrechtseinräumungVerschuldensunabhängiger Zinsanspruch (§ 641 II BGB)Fälligkeit des Vergütungsanspruchs (§ 641 BGB)Verjährungsbeginn (§ 638 BGB)
708
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
SomitHauptproblem bei der Abnahme ist i.d.R. kein rechtliches sondern ein psychologisches beim AuftraggeberFormaler Teil muss sein, aber dabei partnerschaftliches Verhältnis zwischen Projekt und Auftraggeber beachtenGutes Änderungsmanagement zahlt sich (spätestens) hier ausKriterien und Verfahren möglichst früh klären und festlegen (Abnahmephase ist Stress...)Bestmögliche Betreuung der zur Abnahme berechtigten Mitarbeiter des Auftraggebers sicherstellenSchnelle Reaktion auf auftretende Probleme
709
7 Projektabschluss und Prozessverbesserung7.2 Projektabschluss
Projektabschlussdimensionen:Personalorganisation:
Identifikation und Durchführung von FortbildungsmaßnahmenTeamgeist belohnenEvtl. Fortführung der Teamstruktur
Organisationsdimension:Identifikation von erfolgreichen Verfahren („Best Practices“)Identifikation und Durchführung vonVerbesserungsmaßnahmen
- Unternehmensstrukturen- Technologien- Prozessdefinitionen