Projektmanagement - informatik.uni-augsburg.de · 3 Ziele der Vorlesung Die Hauptziele der...

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

17

1.1 Motivation

18

1.1 Motivation

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


Komplexität des ProduktsFaktoren: Größe, Diversität, VernetzungFührt zu Komplexität des ProzessesSW oft komplexer als „klassische“ Ingenieurprodukte

26


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


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


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


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



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


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


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


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


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


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


Prozentualer PM-Kostenanteil

Grobe Regeln:kleine Projekte: 8%mittlere Projekte: 4%große Projekte: 2%

70


PM-Kosten und Projektkosten

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


4. Schätzverfahren und ProjektplanungSchätzverfahrenProjektplanung

5. Projektstrukturen und PersonalaktivitätenEinleitungProjektfunktionenAufgabenträgerOrganisationsformen, Unternehmensstrukturen und Projektstrukturen

74


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


1. Einleitung



78




79

Kapitel 2:Faktor Mensch

Teamworking und KommunikationInterviewtechnikenZeitmanagementKonflikte und ProblemlösungstechnikenModerations- und Kreativitätstechniken

80

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



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


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


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


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


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


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


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


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.

93

94

95


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


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


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


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


Entwicklungsphasen eines Teams

Neue Teammitglieder

Aufgabenänderung

Kein Konsens

100


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


Grundregeln der TeamarbeitAnerkennung geben, Beiträge forderngemeinsam handelneigene Meinung offen äußernZiele im Auge behaltenKonflikte ausdiskutierenaufmerksam zuhörenKritik akzeptieren

102


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


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


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


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


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



109

2. Faktor Mensch2.2 Interviewtechnik

Wann werden Interviewtechniken verwendet:BewerberverfahrenAuswahlentscheidungenKundenanforderungen….

Beispiel hier: Bewerberauswahl!

110


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


Fähigkeiten können seinLernfähigkeitKreativitätTeamfähigkeitErgebnisorientierungKundenorientiertungKommunikationsfähigkeitenDurchsetzungfähigkeitMotivationsfähigkeitStrategisches DenkenInitiativeVeränderungsfähigkeitNetworking SkillsEinfühlungsvermögenAnalysefähigkeitenPlanungs- und OrganisationsgeschickMobilitätInterkulturelles Verhalten…

112


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


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


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


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


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


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


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


Fragetechnik - Verhaltensdreieck

Situation

Vorgehen Ergebnis

120


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


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?

122


Übung!!!

123



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


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


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 …

127


To-Do-Liste

128


Persönlicher Tagesplaner

129


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


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



132


Konflikte können Todesurteil für Projekt seinKonflikte entstehen

Durch unterschiedliche Ziele und WertevorstellungenMissverständnisseAntipathieRivalitätMobbingZukunftsängsteErfolgslosigkeit

133


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.

134


Konfliktlösungsdreieck

135


Konfliktlösung - Verhaltensdreieck

Situation

Vorgehen Ergebnis

136


„Problemfall“ Mensch im Projekt:Menschen schätzen keine Veränderungen und versuchen sie zu ignorieren

137


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


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


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


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


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


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


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



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


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


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


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


Voraussetzungen Schulung der Teilnehmer

Flipboard und Konferenzraum

erfahrener Moderator

151


Durchführung Einberufung 1-3 Tage im vorausTeilnehmerkreis 5-8 Personenfachlich heterogen, hierarchisch homogen20-40 min DauerModerator überwacht Einhaltung der GrundregelnNachsitzung

152


Vorteile

rasch erlernbareinfach und schnellvielseitige Ideenanregend und motivierend

Nachteile

nur für relativ einfache Problemekeine VorgehenssystematikEinhaltung der Grundregeln schwierig

153


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


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


Mind-MapsTeilnehmerzahl

Einzeln oder in kleinen GruppenVoraussetzungen

Flip-chart und Moderator (bei Gruppen)PapierFarbstifte

157


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

158

2.4 Moderations- und Kreativitätstechniken Mind-Maps

Beispiel

159


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


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

162


Formblatt

163


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


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


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


Voraussetzungen Ein kreatives Team von Kunden/ Konsumenten oder MitarbeiternEin geschulter Moderator oder Diskussionsleiter mit Kenntnissen des lateralen Denkens und seiner Techniken

172


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


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


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


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.

176

zu guter Letzt

177


1. Einleitung



178




179




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

182


Projektstart

183


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

184


Zeitpunkte der Projektstartkommunikation

185


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


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


ProjektzieleProjektidee:

Auftragsprojekt: AnforderungskatalogInnovationsprojekt: Marktstudie/TechnologiestudiePflege/Änderungsprojekt: Verbesserungsvorgaben

Wichtig:Festlegung ProjekterfolgskriterienMessbare Kriterien

Präzisierung Projektziele:LastenheftPflichtenheftProjektauftrag

188


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


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


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


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)

192




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


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


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


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

198


Technologie-Portfolio

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


Lebenszyklus-AnalysenProduktlebenszyklenTechnologielebenszyklen

201


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


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


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


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


Richtige Aufgabenstellung?Produkt kann genial und hochwertig sein, wenn es aber keine Marktbedürfnisse decktFlop

DeswegenMarktanalysePortfoliodarstellung...

208


Richtige Entwicklungsdauer?McKinsey: „Das Einhalten und Verkürzen von Entwicklungszeiten ist wichtiger als das Einhalten und Reduzieren von Entwicklungskosten“3 Varianten der Wirtschaftlichkeitsbetrachtung

209


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


Richtige Personalstärke?von Brooke: Adding man power to a late project makes it late!Optimale Personalstärke

211


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


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


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

216




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



Anforderungskatalog

Pflichtenheft






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



Anforderungskatalog

Pflichtenheft






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


Aufbau - PflichtenheftGesamtsystem

SystemumgebungSystemdarstellungSystembeschreibung

TeilsystemTeilsystemdarstellungKurzbeschreibung der TeilsystemeKomponentenfestlegungBeschreibung der Ein-/AusgabedatenDarstellung der Bedienoberflächegeforderte Dialogauskünfte und Auswertungenverfahrensinterne Schnittstellen

DatendefinitionStammdatenBewegungsdatenVerwaltungsdaten

223


Aufbau – Pflichtenheft …Schnittstellen

zu vor-/nachgelagerten VerfahrenStandard-EingabeschnittstellenStandard-Ausgabeschnittstellen

Allgemeine SystemangabenQualitätsanforderungenAuflagen / RestriktionenMengengerüstArbeitsabläufe, vorhandene/geplante Ablauforganisationensonstige Anforderungen

224


225



Anforderungskatalog

Pflichtenheft






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


Im allg. umfasst die Leistungsbeschreibungdas fachliche Feinkonzeptdas technische Grobkonzeptund die allgemeinenRealisierungsanforderungen

228


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


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


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


Arten von Vorgehensweisen im Änderungsprozess:

kontinuierlicher Änderungsprozess

eingeschobener Änderungsprozess

begleitender Änderungsprozess

233


234


1. Einleitung



235




236




237

Kapitel 4:Schätzverfahren und Projektplanung

SchätzverfahrenProjektplanung

238



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.”

240

4 Schätzverfahren und Projektplanung4.1 Schätzverfahren

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


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


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


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


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.

246


247


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


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


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


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


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


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


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


Komplexität und Prozess

Verschiedene Maße in verschiedenen PhasenImplementierung: CodezeilenPost-Architektur (Feindesign): Abstrakter CodePrä-Architektur: Funktionspunkte

255


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

285


Standardtabelle Eingaben

286


Standardtabelle Ausgaben

287


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

288


Standardtabelle Datenbestände

289


Standardtabelle Referenzdaten

290


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

291


Standardtabelle Abfragen

292


Beispiel

293


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


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


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

296


Berechnung der Funktionszahl

297


Berechnung des Einflußgrades und bewerteten Function Points:

298


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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:

314


Graphen zu COCOMO Aufwandschätzungen fürverschiedene Projektgrößen:

315


Graph zur geschätzten Projektdauer in Abhängigkeit von der Projektgröße (Kurve für alle drei Projektklassenähnlich):

316


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


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=

318


Beispieltabelle zur Phasen-Bewertung des Faktors TOOL:

319


320


Beispiel: Aufwandsverteilung für die Klasse “einfache Projekte”:

321


322


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


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


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


Tabelle zur Illustration des gewichtigen Anteils der (subjektiven) Schätzungen der Einflußparameter am Gesamtergebnis:

326


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


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


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


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


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


CoCoMo II - Aufwand

Generell:Auswirkung des exponentiellen Faktors Prozess

- Faktor > 1- “Diseconomy of Scales”

333


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


Komplexität und Produktivität

Produktivität beeinflußt:Durch administrativen AufwandDurch personellen AufwandDurch Abstimmungsaufwand

335


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


Realisierungsaufwand und Laufzeit

Laufzeit beeinflusst Aufwand:Durchschnittliche Laufzeit minimiert AufwandZusätzlicher Aufwand erlaubt Kürzung (70%)Erhöhte Laufzeit verringert Aufwand nicht

337


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


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


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

342



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


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

345


Planungsintensität in den Projektphasen

346


Übersicht Planungsschritte

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


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

350


Regelkreis des Projektmanagements

351


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

352


Wirkung des Planungsaufwands

353


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

355


Projektstrukturplan

356


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


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“

359

4.2 ProjektplanungMeilensteine

Achtung: 90%-Syndrom!

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


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


Beispiel:Tätigkeiten mit Zeitangaben und Vorgängerrelationen

367


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


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)

369


Vorgangsknotennetzplan - Beispiel

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


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


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


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


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


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


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


VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen

379


380


VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen

382


383


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


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


CPM: Vorgangskantennetzplanoft werden Ereignisknoten auch folgendermaßen dargestellt

386


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


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


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


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


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


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


Beispiel: CPM NetzwerkTätigkeiten mit Zeitangaben und Vorgängerrelationen

393


Beispiel: CPM Netzwerk - Numerierung der Knoten

394


Beispiel: CPM Netzwerk - Bestimmung der frühesten Beginnzeiten

395


Beispiel: CPM Netzwerk - Bestimmung der spätesten Beginnzeiten

396


Beispiel: CPM Netzwerk - Bestimmung des kritischen Pfades

397


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.

398


Beispiel eines Netzplans mit einem kritischen Weg:

399


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

400


401


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


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


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)

404


Übersicht zu Pufferzeiten und Schlupf

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


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


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


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


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%

410


Beispiel zu einem PERT-Netzplan:

411


Erklärungen zum PERT-Netzplan Beispiel:

412


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


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


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

416


Balkendiagramm

417


Beispiel zu einem Balkendiagramm mit einem Ist-Soll-Vergleich

418


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

419


Vernetzte Balkenpläne

420


Vernetzte Balkenpläne

421


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


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


Einsatzmittel - Auslastungsdiagramm Beispiel eines Netzplans mit Einsatzmitteleinheiten(und mit unterschiedlichen Zeitwerten des Endereignisses)

425


Einsatzmittel - AuslastungsdiagrammBeispiel für ein Balkendiagramm der frühesten Lage

426


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


Einsatzmittel - AuslastungsdiagrammBeispiel für ein Balkendiagramm der spätesten Lage

(Jenny Abb. 4.21, S. 347)

428


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


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


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


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


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


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


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


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


Optimierung

Varianten der Zuordnung/Optimierung:Terminorientiert:

- Einhaltung vorgegebener Termine- Erhöhung der Personalzuordnung

Aufwandsorientiert:- Einhaltung vorgegebener (Maximal-)Aufwände- Verschiebung des Termins

441


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


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


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


RessourcenplanungVerfahren:

Im wesentlichen analog PersonalplanungÄhnliche Probleme

- Qualifikation: Vorbereitung- Multiprojekteinsatz: Umrüstung

UnterscheidungNichtverbrauchbare RessourcenVerbrauchbare Ressourcen (eingebettete SW)

445


1. Einleitung



446




447




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


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


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


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


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

455


Projektorganisation:

456

Projektspezifische Definition der Projektfunktionen

Übertragung der Projektfunktionen inkl. Kompetenz und Verantwortung auf die Aufgabenträger

Einbettung des Projekts in die vorhandene Organisation



Personen


Gremien





457






Personen


Gremien





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






Personen


Gremien




5 Projektstrukturen und Personalaktivitäten5.2 Aufgabenträger

467


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


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


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


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


Gremienzur Abstimmung, Information, Problemlösung und Entscheidungaber: so wenig Gremien wie möglichBeispiele:

ProjektbesprechungenChange Control BoardMeilenstein-EntscheidungenBeratungsausschussEntscheidungsausschuss

472


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


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


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


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






Personen


Gremien




5 Projektstrukturen und Personalaktivitäten5.3 Unternehmensstrukturen & Projektstrukturen

477


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


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


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


Bereichsstruktur

Schwerpunkte: Know-how-Transfer, Ressourcenflexibilität

481


Marktstruktur

Schwerpunkte: Effizienz, Produktidentifikation, minimierte Kommunikation

482


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


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


Bereichsleitung

E F VPL

PL

PL



Bereichsleitung

E F V

PLPL

Bereichsleitung

E F VPL


485


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


486


Projektorganisation

487


Extremfall: Projektstruktur als Unternehmensform

488


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


Bereichsleitung

E F V

PLPL

489


Stab-Linien-Organisation

490


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


491


Matrixorganisation

492


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


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


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


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

497


498


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


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


Personalaufwand in ProjektenBeobachtung:

Kommunikationsaufwand bestimmt durch ProjektstrukturProjektstruktur bestimmt durch Produktstruktur

Konsequenz:Erst: Festlegung der ProduktstrukturDann: Festlegung der ProjektstrukturEvtl. iterativ

Resultat: Ungleichmäßige PersonalausstattungBeispiel:

501


1. Einleitung



502




503




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

512

6 Projektkontrolle

513



514

6 Projektkontrolle6.1 Projektrisiken und Risikomanagement

Risikomanagement und Projektphasen

515


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


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

517


518


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)

519


Risikoidentifikation

520


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


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


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


„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


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


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


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


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


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


hoch

mittel

gering

gering mittel hoch

Schadenshöhe

Wahrscheinlichkeit

3

2 1

Beispiel eines Risikoportfolios

530


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


Risikomanagement: Weitere Schritte (Fortsetzung)Risikoüberwachung:

Aufgabe: Fortlaufende Erkennung von RisikenVerfahren:

- Durchführung Risikoplan: Fortschrittskontrolle, Trendanalyse- Evtl: Plananpassung- Zyklische Durchführung

532



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


Wartungsaufwand Einzelprojekt

Einzelprojekt:Individuelle AnfertigungSchwerpunkt: Pflege (Fehlerbehebung)

535


Wartungsaufwand langlebiges Projekt

Langlebiges Projekt:Wiederholte Installation bzw. (anpassbare) StandardanwendungSchwerpunkt: Änderung (Funktionserweiterung)

536


Aufschlüsselung Wartungsaufwände

537


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


Produkt und Aktivität

Aktivitäten:Benötigen, erzeugen, modifizieren Produkte

Produkte:Synchronisieren, beeinflussen Aktivitäten

539


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


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


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


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


Ä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


Änderungsmanagement

Änderungen:Änderungen verwalten

- Entgegennehmen/bewerten- Entscheiden/einleiten- Abschließen

Verantwortlichkeiten für Änderungsaufgaben zuweisenEntscheidungen herbeiführen und dokumentierenProjekthistorie mitführen

546


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


Schnittstelle BerichtswesenBerichtswesen

Festlegung VerantwortlichkeitenVerteilen InformationenDokumentation Entscheidungen

Wesentliche Schnittstellen:Änderungsmanagement: Erfassung Fehler, ÄnderungenProjekthistorie: Dokumentation Projektabwicklung

Berichtsarten (Beispiele):FehleridentifikationÄnderungsanträge und EntscheidungenÄnderungsmeldungenProjekthistorie

548


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


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



551

6 Projektkontrolle6.3 Qualitätsmanagement

552


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


Qualitätsmanagement

Qualitätsmanagement:Planung: Vorbereitende MaßnahmenLenkung: Konstruktive MaßnahmenSicherung: Analytische MaßnahmenVerbesserung: Prozessverbesserungsmaßnahmen

554


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


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


Planung:QS-Initialisierung: Konstruktiv

Prüfung (analytisch):VorbereitungProzessprüfung („Vorgaben eingehalten“)Produktprüfung

Leitung (administrativ):QS-Berichtswesen

557


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


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

559


Produktqualität - 3 Fragen

560


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Analytische Verfahren: Review/Walk-ThroughProzeß eines Projektreviews:

Planungssitzungabhalten

Reviewvorbereiten

Reviewsitzungabhalten

analysiereErgebnisse

setze erlasseneMaßnahmen um

591


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


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


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


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


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


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


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


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


Testen: PfadüberdeckungZiel: Umfassende TestfallgenerierungVerfahren:

Implementierung als KontrollflussgraphFür jeden Pfad im Graph einen TestfallPraxis: Maximale Pfadlänge

600


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


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


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


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

604


Beispiel: Coding Standards (NASA)

605


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


Fehlerarten im Prozess

Wann werden welche Fehler gemacht:Fatal: AnforderungsdefinitionSchwer: EntwurfMittel, leicht: Entwurf, Umsetzung

607


Aufwand

Aufwand:Ausführung: wenig UnterschiedeVorbereitung/Behebung: frühe Aktivitäten effizienter

608


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


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


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


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


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



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)

615


616


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


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


Meilensteintrendanalyse

Verfahren:Regelmäßige Erfassung StatusErfassung pro MeilensteinKeine rückwirkende Änderungen

619


Berichtszeitpunkte

Meilenstein-Termine

IVIIIIII

IVIIIIII

IVIIIIII

IVIIIIII

IVIIIIII

200x

200x

200x

200x

200x



620


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


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


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


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“

624


Beispiel: Zeitaufschreibung

625


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


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


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


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


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


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


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


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


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


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



636


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


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


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


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


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


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


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


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


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


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



647


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.

648


Beispiel zum Cost Performance Index

649


Beispiel zum Schedule Performance Index

650


CPI und SPI grafisch dargestellt am Beispiel eines gutgemanagten Projekts

651


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


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


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


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


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


Mittlere Management hat eine deutlich größere Anzahl von Projekten zu überschauen und erhält meistens stark zusammengefasste „Ampelberichte“

657


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


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


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


1. Einleitung



661




662




663

Kapitel 7:Projektabschluss und Prozessverbesserung

ProzessverbesserungProjektabschluss

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


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


Aufgaben:Formaler ProjektabschlussAuswertung ProjekthistorieErstellung Projektabschlussbericht

Ziel:Gesamtbeurteilung ProjektBewertung Projektergebnis (Ist/Soll-Vergleich)Dokumentation von ErfahrungenIdentifikation von Problemen und DefizitenVorbereitung Prozessverbesserung

667


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


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


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


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


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


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


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


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


„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


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

678


CMM: Stufe 1 und 2

679


CMM: Stufe 3

680


CMM: Stufe 4 und 5

681


CMM Verteilung

682


CMM-Verbreitung

683


CMM und Unternehmensgröße

684


CMM Verbesserungsaufwand

685


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


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


Fehlerbehebungsgüte

Effizienz der FehlerbehebungMaß: Anteil behobener/identifizierter FehlerAbhängig von Prozessgüte

688


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


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


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

691


SPICE: Reifegrade

692


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


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


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


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


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


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


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


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


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

701


ProzessverbesserungProjektabschluss

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


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


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


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


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


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


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


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

710

Das war‘s!

Ich danke Ihnen für Ihre Aufmerksamkeit und wünsche Ihnen

eine schöne vorlesungsfreie Zeit,viel Erfolg in der Klausurund auf Wiedersehen im neuen Semester!

Date post:	17-Sep-2018
Category:	Documents
Upload:	phamtruc
View:	228 times
Download:	0 times

Projektmanagement - informatik.uni-augsburg.de · 3 Ziele der Vorlesung Die Hauptziele der...

Documents