Vorlesung VS SS 2007 · Projektmanagement ist ein wenig, wie sich das Rauchen abzugewöhnen: leicht...

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

Bernhard Bauer

Projektmanagement: Einführung

2

Ziele der Vorlesung

Lernziele: Die Studierendensind in der Lage, sich in einem Projekt zu orientierenkönnen konstruktiv in einem Projekt mitarbeitenhaben das theoretische Wissen, eine Projektleitung auszuüben

Ziel der Vorlesung ist die Einführung in die grundlegenden Aufgaben und Techniken

des IT-Projektmanagements. Der Fokus der Übungen liegt auf der praktischen Anwendung und Umsetzung von Projektmanagement-Inhalten.Projektmanagement ist zu großen Teilen eine praktische Fertigkeit.

Projektmanagement M1 -

Einführung

3

Übersicht

EinführungProjektvorbereitungProjektplanungProjektkontrolle und –steuerungQualitätsmanagement und ProzessverbesserungEthische Leitlinien im Software Engineering


Einführung

4

Literatur

H. Balzert: Lehrbuch der Software-Technik, Band 2, Spektrum Akademischer Verlag, 2002I. Sommerville: Software Engineering. Pearson, 2006.U. Witschi, A. Erb, R. Biagini, Projekt-Management: Der BWI-Leitfaden zu Teamführung und Methodik. Verlag Industrielle Organisation Zürich, 1996T. DeMarco, T. Lister: Wien wartet auf Dich. Der Faktor Mensch im DV-Management.Tom DeMarco. Peopleware: Productive Projects and Teams. B&T, 1999. Tom DeMarco. Der Termin. Hanser Wirtschaft, 2005.


Einführung

5

Folien und Skripte

Bernhard Schätz: Vorlesung Projektorganisation und Management, Leopold-Franzens Universität Innsbruck, Sommersemester 2003Bernhard Bauer: Vorlesungsfolien Projektmanagement. 2006Gerhard Pews: Vorlesung Projektmanagement, Universität Kaiserslautern, Wintersemester 2005/06 Martin Wirsing: Vorlesung Projektmanagement 2007


Einführung

6

Wo sind wir: Welt der Softwaretechnik

Technik-Katastrophen:September 1999: Verlust der Sonde "Mars Climate Orbiter" wegen

falscher Einheitenumrechnung1985-1987 Therac 25 (Strahlengerät zur Krebsbehandlung): Fehlerhafte Programmierung führt zu Verbrennungen und Todesfällen

Finanzielle Katastrophen:1990 AT&T Telefonverbindung zwischen Ost- und Westküste der USA

wg eines SW-Fehlers für mehr als 24 Std unterbrochen: ca. 1 Mia US-$1992: Integration des Reservierungssystems SABRE mit anderen Reservierungssystemen abgebrochen: 165 Mio. US-$1996 Dtsche Telecom: “1. Januar 1996 ist kein Feiertag”: >50 Mio DM

Terminkatastrophen:1994: Eröffnung des Denver International Airport um 9 Monate verzögert

wegen Softwareproblemen im Gepäcktransport-System2003: Einführung des LKW-Mautsystems in Deutschland verzögert sich um 18 Monate


Einführung

7

Erfolgreiche und gescheiterte IT-Projekte

Erfolgreiche Projekte

Projekte mit Abweichungen

Gescheiterte Projekte

1994 16 % 53 % 31 %

2000 28 % 49 % 23 %

2004 29 % 53 % 18 %


Einführung

Quelle: Standish Group: Chaos Report

8

Aktuelle Fehlschläge

CW 29.12.06 Probleme mit Hartz-IV-Software„Eine Bearbeitung von Erst- und Fortzahlungsanträgen für das Arbeitslosengeld 2 (ALG2) ist seit dem 27. 12. nicht mehr möglich. Deshalb Verzögerungen bei der Auszahlung des ALG2 kommen. Schuld an dem Dilemma seien Probleme mit der zentralen Computersoftware A2LL, die die Bundesagentur für Arbeit für die Leistungsgewährung verwendet.“

CW 30.03.2007 Bayern kippt Polizeisystem DiplazNach jahrelangen Querelen rund um das neue Dienstplanungs- und Zeitwirtschaftssystem (Diplaz) hat das bayerische Innenministerium das Projekt gestoppt.„2003 ausgeschrieben sollte die Software für Dienstplanung und Zeitwirtschaft ursprünglich schon seit Mitte 2005 laufen. Aufgrund von funktionalen Mängeln musste der Start allerdings immer wieder verschoben werden. Nachdem sich die Fehler und Probleme auch im Modell- und Flächenpiloten vergangenes Jahr nicht beheben ließen, setzte das Innenministerium das Projekt Anfang Dezember 2006auf Eis. … Da es dem Softwarehersteller (auch im März ) nicht gelungen war, fristgerecht ein fehlerfreies System abzuliefern, zogen die politisch Verantwortlichen nun die Konsequenzen.“

Süddeutsche Zeitung Januar 2007Während des Januar-Orkans fielen die elektronischen Anzeigen des MVV aus bzw. mussten wegen Fehlangaben abgeschaltet werden. Ursache waren Fehler in der zugrunde liegenden Software.


Einführung

9

Ziele dieser Vorlesungseinheit

Begriffe „Projekt“ und „Projektmanagement“ definierenSchwierigkeiten des Projektmanagement diskutierenAufgaben des Projektmanagement kennen lernenTätigkeiten während des Projektverlaufs kennen lernen und im V-Modell wiederfinden


Einführung

Was sind Projekte?

10

Begriff Projekt


Einführung

Routine- aufgaben

Veränderungs- aufgaben

Projekte

Linien-Organisation

alte Wege neue Wege

neue Ziele

alte Ziele

Sicherheit

FestigkeitStandardisierung

Genaues Regelsystem

ExperimentierfreudeInnovativ

KreativRisiko

Konflikte

11

Begriff 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)Ein Projekt ist eine zeitlich beschränkte Anstrengung zur Erzeugung eines einmaligen Produktes oder Dienstes

(Project Management Institute, PM Body of Knowledge)

Was heißt es, ein Projekt zu "machen"?Schaffen einer stabilen, akzeptierten und funktionierenden "temporären Organisation„Abgrenzungen gegenüber Umgebung nötig


Einführung

12

Abgrenzung eines Projekts

Zeitliche AbgrenzungZeitplan, Termine,Vor- und Nachprojekt-Phase

Sachliche AbgrenzungZiele, Hauptaufgaben, Nicht-Zielezu anderen Projekten, Tätigkeiten

Soziale AbgrenzungProjektleiter, Projektauftraggeber, ProjektteamUmwelt-/Umgebungsanalyse


Einführung

13

Begriff Projektmanagement

"Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes„

(DIN 69901)

"Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements." "Project management includes

identifying requirements, establishing clear objectives, balancing the competing demands for time, quality, and cost, adapting the specifications, plans, and approach to the different concerns and expectations of the various stakeholders.„

(Project Management Institute, pmi.org)


Einführung

14

Projektmanagement

Projektmanagement umfasst alle Aufgaben bei der Durchführung von Projekten hinsichtlich

Vorbereitung (Struktur und Personal)PlanungKontrolleSteuerung

Dazu gehören auch projektübergreifende Aufgaben:Projektabschluss und ErgebnisdokumentationProzessverbesserungPersonalführungInteraktion mit dem Kunden und Koordination von Zulieferern.


Einführung

15

Projektmanagement

Projektmanagement ist einfach zu begreifen, aber schwer zu tunProjektmanagement ist ein wenig, wie sich das Rauchen abzugewöhnen: leicht zu begreifen, schwer zu tun.Man ist schon dann ein guter Projektleiter, wenn man dafür sorgt, dass alle die Dinge auch tatsächlich passieren, die eigentlich selbstverständlich sind.

Warum ist Projektmanagement wichtig für Sie? Als Projektleiter: Selber machen Als Projektmitarbeiter: Zusammenhänge kennen


Einführung

Projektmanagement ist die Kunst mit 10 Fingern 11 Korken unter Wasser zu halten

Quelle: G..Pews sd&m

16

Projektmanagement (und Humor)

Projekte sind oftmals nicht erfolgreich,deshalb gibt es viele Aussprüche über das Projektmanagement.

Hier ein paar nicht ganz ernst zu nehmende Zitate:Persönlichkeit: "If you're 6 months late on a milestone due next week but reallybelieve you can make it, you're a project manager."Zeitschätzung: "The first 90% of a project takes 90% of the time; the last 10% takes the other 90%."Straffung von Zeitplänen: "Even the nine most competent women can not have a baby in only one month."Rolle von Planung: "The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."


Einführung

17

(Unerwünschter) Projektablauf

1.

Enthusiasmus

2.

Desillusionierung

3.

Panik

4.

Suche nach den Schuldigen

5.

Bestrafung der Unschuldigen

6.

Ruhm & Ehre für die Unbeteiligten


Einführung

18

Schwierigkeiten im IT-Projektmanagement

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


Einführung

19

Schwierigkeiten im IT-Projektmanagement

Immaterialität des Produkts: Software ist unsichtbar und damitFür den Kunden schwer erlebbar (Kostenbewusstsein)Bzgl. des Fertigungsgrades schwer messbarRisiko: Umfang, Kosten und Laufzeit

Innovativität des Produkts: Software ist i.a. „Null“-Serie und damitMit dem Einsatz neuester 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


Einführung

Magisches Projektmanagement-Dreieck (Triple Constraints)

©

Bernhard Bauer, all rights reserved 2007 20

Projektziel

ZeitraumAufwand

21

Projektmanagement Teufelsquadrat nach Harry Sneed


Einführung

Zielgrößen auf den Diagonalen:Zeit: ProjektlaufzeitKosten: BudgetQualität: z.B. Funktionalität, Nutzbarkeit, WartbarkeitLeistungsumfang: Anzahl ausgelieferter Funktionen

Je weiter außen, desto besser das Ergebnis:

„Mehr“ Qualität und Leistung führen zu besserem Ergebnis (daher „plus“ außen)Kürzere Entwicklungsdauer und geringere Kosten führen zu besserem Ergebnis (daher „minus“ außen)

Die von den Zielgrößen gebildete Fläche beschreibt die Produktivität des Projekts.

22

Projektmanagement Teufelsquadrat nach Sneed

Die Fläche (Produktivität) eines Projekts ist invariant

Wenn ein Projekt z. B. in weniger Zeit und zu geringeren Kosten abgeschlossen werden soll, verringern sich auch Leistungsumfang und Qualität.

„Chinesenprinzip“Idee: Ein Projekt wird beschleunigt, indem massiv Personen in das Projekt entsandt werden. Funktioniert nur bei stark parallelisierbaren, voneinander unabhängigen Tätigkeiten, die keine größere Einarbeitung erfordern.


Einführung

23

Projektmanagement Zielgrößen

Kosten Das Projekt wird mit einem festen Budget gestartet. Dieses Budget wird nachträglich nicht mehr gekürzt. Auch bei Anbietern von Festpreisprojekten wird in der Regel nicht während der Projektlaufzeit das für das Projekt verfügbare Budget gekürzt, um einen höheren Gewinn zu erzielen. Das Budget wird nicht ohne Grund erhöht.

Zeit Das Projekt wird mit einem festen Zeitrahmen gestartet. Oft gibt es einen fixen Zieltermin. Oft kommt es zu einer faktischen Kürzung der Projektlaufzeit, wenn sich der Projektstart verzögert, z. B. aus organisatorischen Gründen wie fehlenden Ressourcen oder nicht freigegebenen Budgets.


Einführung

24

Projektmanagement Zielgrößen

Qualität Ist der am schwierigsten zu messende Faktor und sind nicht so klar vorgegeben wie Budget und ZeitQualitätskriterien müssen im Projekt konkretisiert werden. Über einzelne, konkrete Punkte kann dann ggf. gesprochen werden, ob dieses Qualitätskriterium gehalten werden muss.

Leistung Der Leistungsumfang tendiert während eines Projekts dazu, immer größer zu werden. Ursache dafür sind zu Projektbeginn zwangsläufig unscharfe Anforderungen, bei deren Konkretisierung immer neue Implementierungsaspekte entstehen können. In konkreten Punkten lässt sich der Leistungsumfang auch im Projektverlauf kürzen. Dabei verschwimmt die Abgrenzung zu den Qualitätsmerkmalen.


Einführung

25

Aufgabenfelder Projektmanagement

Laut Project Management Institute besteht PM aus den folgenden 9Aufgabenfeldern:

Integrierende Aufgaben (integration management)Umfangsmanagement (scope management)Zeitmanagement (time management)Kostenmanagement (cost management)Qualitätsmanagement (quality management)Personalmanagement (human resource management)Kommunikationsmgmt. (communication management)Risikomanagement (risk management)Beschaffungsmanagement.(procurement management)

Es folgt eine Kurzübersicht über deren Themen


Einführung

26

Vorbemerkung: Wann wie viel?

Viele der nachfolgend beschriebenen Aufgaben sind nur für Großprojekte im vollen Umfang sinnvollBei mittelgroßen Projekten sollten viele davon vereinfacht werden

aber welche und wie stark hängt vom Einzelfall abBei kleinen Projekten sollten evtl. sogar manche ganz entfallen

aber ob und welche hängt vom Einzelfall ab

Übertriebenes Projektmanagement ist schädlich!Zu wenig Projektmanagement ist auch schädlich!

Augenmaß ist gefragt!Das ist allerdings ohne Erfahrung ziemlich viel verlangt…


Einführung

27

Integrierende Aufgaben (integration management)

Diese Tätigkeiten verbinden die Tätigkeiten der restlichen Felder miteinander:Entwickeln des umfassenden Projektplans

enthält Teilpläne aus den anderen AufgabenfeldernAnmerkung: Ein solcher Plan existiert immer (evtl. nicht detailliert, evtl. nicht einmal schriftlich)

Projektleitungkonkrete Anweisungen geben, Entscheidungen fällen etc.

Projektüberwachungkontinuierlich den Ablauf gegenüber den Plänen verfolgen,bei Abweichungen geeignete Maßnahmen ergreifen

Planänderungs-Überwachung und -SteuerungÄnderungen am Plan auf Wirkungen abklopfen und entweder zurückweisen oder komplett ins Projekt einfädeln


Einführung

28

Umfangsmanagement (scope mgmt)

UmfangsdefinitionWas ist Aufgabe des Projekts? Was nicht?Bei SW: Anforderungsbestimmung

Erarbeiten einer Produktzerlegung (WBS: Work Breakdown Structure)In welche handhabbaren Teile sollte man das Gesamtprodukt (genauer eigentlich: den konkreten Prozess) zerlegen?Wie fügen sich diese Teile zum Ganzen zusammen?Bei SW hauptsächlich: Entwurf + Prozessmodell

Umfangsverwaltung (bei SW: Anforderungsverwaltung)Änderungen am Umfang (durch externe Einflüsse, z.B. Kundenwunsch) werden nicht einfach zugelassen, sondern die Auswirkungen überprüft.Akzeptierte Änderungen werden sorgfältig in die Umfangsbeschreibung eingearbeitet

und Beteiligte geeignet benachrichtigt


Einführung

29

Zeitmanagement (time management)

Entwickeln einer AktivitätenlisteZu jedem Teilprodukt laut WBS gehören eine oder mehrere Aufgaben (Aktivitäten, also Prozesse)

(Zeit-) Aufwandsschätzung für die AktivitätenWie hoch ist der Aufwand (z.B. Personentage)?Wie lange dauert die Erledigung (Kalendertage)?

Aufstellung eines Zeit- und Arbeitsplans (schedule)Wie hängen die Aufgaben von einander ab?Wer erledigt von wann bis wann welche Aktivität?

Zeitplanüberwachung (schedule control)Wird der Plan eingehalten?Kontinuierliche Fortschreibung des Zeitplans


Einführung

30

Kostenmanagement (cost management)

KostenschätzungBudgetaufstellungKostenüberwachung

Bei SW-Projekten sind außer den Personalkosten meistens nur ganz wenige Posten relevant (meist SW-Lizenzen, Reisekosten, …)Dadurch hängen die Kosten so eng an den Zeitaufwänden, dass diese Aufgabe kaum separat gelöst werden muss


Einführung

31

Qualitätsmanagement (quality management)

Qualitätsplanung (quality planning)Aufstellen von Qualitätsanforderungen (bei SW: Anforderungsbestimmung)

Planen, wie man sie erfüllt (bei SW ungefähr: Qualitätsmanagement)

Qualitätssicherung (quality assurance)

Qualitätssteuerung (quality control)wenn die Qualität nicht stimmt, geeignete Maßnahmen ergreifenz.B. korrigieren, Teil wegwerfen und neu bauen, Aufgabe an andere Person übergeben, Entwicklungsprozess ändern, etc.


Einführung

32

Personalmanagement (human resource management)

PersonalplanungDefinition von Rollen, Verantwortlichkeiten, Weisungsbefugnisse(Prozessmodell & Organisationsplanung)

Aufstellung eines PersonalzeitplansWie viele Leute mit welcher Qualifikation brauchen wir von wann bis wann?

z.B. Analysten überwiegend am Anfang des Projekts, Programmierer jedoch nicht von Anfang an

Team einwerben, TeamformungTeilnahme an einem Projekt sollte freiwillig seinMitglieder müssen ein Gemeinschaftsgefühl entwickeln

TeamführungLeistung der Mitglieder verfolgen, Feedback geben, Konflikte auflösen, Arbeit bei Änderungen neu koordinieren


Einführung

33

Kommunikationsmanagement (communication management)

KommunikationsplanungWelche Beteiligten brauchen regelmäßig welche Information?

InformationsverteilungDen Betroffenen relevante Information stets zügig zukommen lassen

FortschrittsberichteStatusberichte und Planfortschreibung regelmäßig erarbeiten und allen Betroffenen zuleiten

Interaktion mit BeteiligtenBesprechungen und Schriftverkehr mit allen Beteiligten (z.B. Projektteam, Auftraggeber, Anwender, Interessierte), um deren Bedürfnisse zu erfüllen und Angelegenheiten aller Art zu klären


Einführung

34

Risikomanagement (risk management)

Risiken identifizierenWelche Ereignisse könnten die plangerechte Durchführung bedrohen?

RisikoeinschätzungRisikogrößen abschätzen, Risikobehandlung priorisieren

Vorbeugung planenWas wird getan, um welchem Risiko vorzubeugen?

Gegenmaßnahmen planenWas wird getan, wenn welches Risiko eintritt?

Risikomanagement-ÜberwachungKontinuierlich nach neuen oder veränderten Risiken Ausschau haltenFortführung und Wirkung eingeleiteter Vorbeugungen und Gegenmaßnahmen überwachen. Ggf. korrigierend eingreifen


Einführung

35

Beschaffungsmanagement (procurement management)

Planung und Durchführung der Beschaffung aller Dinge, die das Projekt braucht, aber nicht selbst herstellt

Betrifft bei SW-Projekten gelegentlich Möbel u.ä., manchmal Hardware und oft SW-LizenzenIst aber meist nicht sehr kompliziert


Einführung

36

Projektverlauf

•

Projektvorbereitung–

Festlegung der Projektziele–

Zusammenstellung der groben Projektplanung...in Koordination mit dem Auftraggeber!

–

Zusammenstellung und Nutzen von Know-How aus früheren Tätigkeiten und Projekten

–

Möglichst Durchführung eines Start-Workshops gemeinsam mit Auftraggeber und Projektteam

•

Projektabschluss–

Zusammenstellung und Präsentation der Projektergebnisse–

Gemeinsamer inhaltlicher und emotionaler(!) Abschluss des Projektes–

Sicherung des Know-Hows und der "learned lessons" für nachfolgende Projekte

–

Prozessverbesserung


Einführung

Projekt-vorbereitung

Projekt-durchführung

Projekt-abschluss

37

Projektverlauf


Einführung

•

Projektdurchführung–

Projektkontrolle

–

Feststellung des Projektstatus–

Feststellung von Planabweichungen–

Techniken:

–

Fortschrittsanalyse–

Risikoanalyse

–

Qualitätssicherungs -Maßnahmen

–

Projektsteuerung–

Durchführungsentscheidungen–

Korrektivmaßnahmen–

Techniken:

–

Risikomanagement–

Qualitätsmanageme

nt-Maßnahmen–

Konfigurationsmana

gement



Projekt-abschluss

38

Projektverlauf Prozesse im Submodell PM des VM‘97


Einführung

PM1: ProjektinitialisierungPM2: Vergabe/BeschaffungPM3: Auftragnehmer-ManagementPM4: FeinplanungPM5: Kosten-/NutzenanalysePM6: DurchführungsentscheidungPM7: Risikomanagement

PM8: Projektkontrolle und –steuerungPM9: Informationsdienst/BerichtswesenPM10: Schulung/EinarbeitungPM11: Bereitstellung der RessourcenPM12: Vergabe von ArbeitsaufträgenPM13: Einweisung der MitarbeiterPM14: Projektabschluss

Prozesse nach VM’97 (Submodell PM)

Projekt

Kunde

Zulieferer



Projekt-abschluss

39Projektmanagement M1 -

Einführung



Einführung


41

Zusammenfassung (1)

Ein Projekt ist eine zeitlich beschränkte Anstrengung zur Erzeugung eines einmaligen Produktes oder DienstesProjektmanagement bezeichnet Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines ProjektesDas Teufelsquadrat von Sneed beschreibt den Zusammenhang von Zeit, Kosten, Leistungsumfang und Qualität eines Projekts


Einführung

42

Zusammenfassung (2)

Laut Project Management Institute besteht PM aus den folgenden 9 Aufgabenfeldern:

Integrierende Aufgaben (integration management)Umfangsmanagement (scope management)Zeitmanagement (time management)Kostenmanagement (cost management)Qualitätsmanagement (quality management)Personalmanagement (human resource management)Kommunikationsmgmt. (communication management)Risikomanagement (risk management)Beschaffungsmanagement.(procurement management)

Ein Projektverlauf besteht ausProjektvorbereitungProjektdurchführung mit Projektkontrolle und -SteuerungProjektabschluss


Einführung

Projektmanagement: Prozessmodelle und Projektorganisation

44

Ziele

Wichtige Paradigmen und Vorgehensmodelle der SW-Entwicklung wiederholen und in Zusammenhang mit Projekten stellen:

Sequentiell („Wasserfall“, „V-Modell“),iterativ („spiralförmig“), leichtgewichtig („agil“).

ProjektorganisationUnternehmenss- und Projektstrukturen kennenlernenEinbinden des Projekts in die Unternehmensorganisation bewertenRollen und Verantwortlichkeiten in Projekten verstehen

Projektmanagement M2 –

Prozessmodelle und Projektorganisation

Prozessmodell

Funktion: Beschreibung und Strukturierung des Prozesses zur Abwicklung eines Projekts

Elemente:Phasen Aktivitäten der Phasen(Teil-)Produkte der PhasenProjektrollen (Kompetenzen, Verantwortlichkeiten, Qualifikationen)Richtlinen, Standards, Methoden, Werkzeuge

©


46

Paradigmen der SW-Entwicklung

Einordnung der anfallenden TätigkeitenAnforderungsanalyse & Fachliche KonzeptionTechnische Konzeption (Design, Entwurf)RealisierungIntegration & Test

in Vorgehensmodelle



47

Das sequentielle Paradigma

Das sequentielle Paradigma bezeichnet ein sequentielles Vorgehen mit klar definierten Phasen und Ergebnissen

Bekannteste Vorgehensmodelle:Wasserfall-ModellV-Modell



•

48

Sequentiell: Wasserfallmodell (schematisch)

• Eingeführt von Walker Royce 1970, Weiterentwicklung der „stufenweisen Entwicklung“

(„stagewise development“) von

Benington 1956.• Ansatz:

•

Top-down Stufenmodell mit eingeschränkter Rückkopplung•

Phasensynchronisation durch (Zwischen-) Produkte

•

Geringer Managementaufwand



Charakteristika:- Jede Aktivität muss beendet sein,

bevor die nächste beginnt. - Jede Aktivität ist in der richtigen

Reihenfolge und in voller Breite vollständig durchzuführen.

- Am Ende jeder Aktivität steht ein fertiggestelltes Dokument.

Fach.

Konzeption

Tech.

Konzeption

Realisierung

Test & Integration

Projektstart Ziel

Sequentiell: V-Modell

Entwicklungsstandard für IT-Systeme des BundesEingeführt 1991/1997, Bundesamt für Wehrtechnik und BeschaffungEinsatz

Bei allen Beschaffungen für IT-Systeme des BundesReferenzmodell in vielen Unternehmen der Privatwirtschaft (nominell)

Module:ProjektmanagementSystementwicklungQualitätssicherungKonfigurationsmanagement

©


50

Das sequentielle Paradigma: Vor-

und Nachteile

Vorteileeinfach durchzuführenschränkt Freiheitsgrade stark ein, daher auch für sehr große Projekte anwendbar Komplexitätsbeherrschungsehr effizient bei bekannten und konstanten Anforderungenist gut zu vermessen (notwendig z.B. für Prozessverbesserung) Erhöhte Transparenz

NachteileRisiken gesammelt am Schluss („Big Bang“)starr während des Ablaufs

Gut anwendbar bei klarer, relativ fixer Funktionalität:System- und Basissoftware wie OS, DB, Web-Server;Branchen-Software wie SAP R/3.

Notwendig bei hohen Qualitäts- und Zuverlässigkeitsanforderungen:eingebettete Systeme,rechtliche Anforderungen wie Revisionssicherheit oder Nachvollziehbarkeit.



51

Das iterative Paradigma

Iterativ

heißt, dass der Entwicklungsprozess mehrfach iteriert wird: statt den „Wasserfall“

einmal zu durchlaufen, werden kleine Wasserfälle

hintereinander gesetzt.



52

Das iterative Paradigma

Das iterative Paradigma ist eine Weiterentwicklung des sequentiellen Paradigmas aus der Erkenntnis, dass Software länger lebt als erwartet und auch vom Funktionsumfang her gepflegt werden muss.

Das iterative Paradigma unterstützt inkrementelle Entwicklung, d.h. dass das zu erstellende System nicht in einem Rutsch freigegeben wird, sondern in mehreren Stufen.

Bekannteste Modelle:Spiral-Modell (ein Meta-Vorgehensmodell)Unified Process (RUP)

Das agile Paradigma ist eine Form des iterativen Paradigmas in Verbindung mit frühem Prototyping, bei der nicht alle Tätigkeiten iteriert werden.



53

Rational Unified Process (RUP)



PropjektmanagementInfrastruktur

Geschäftsmodellierung

ImplementierungTest

Analyse & Entwurf

Preliminary Iteration(s)

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+

1

Iter.

#n+

2

Iter.

#m

Iter.

#m+

1

Auslieferung

Konfigurations-Mgmt

Anforderungen

Entwurf ÜbergangKonzeption KonstruktionZeitliche Phasen

IterationenArbeitsschritte

RUP ist eine Weiterentwicklung von Jacobsons Objectory

RUP hat UML als Sprache voreingestellt

RUP wird von Rational/IBM bezeichnet als• inkrementell & iterativ,• architektur-zentriert, und•

anwendungsfall-

getrieben.

54

Das iterative Paradigma: Vor-

und Nachteile

VorteileRisiken können früher erkannt werdenvolatile Anforderungen können besser berücksichtigt werdeninkrementelle Auslieferung wird erleichtert

NachteileMehrarbeitkomplexeres Projektmanagementschwerer messbar



55

Das adaptive Paradigma

Unter einem adaptiven SW-Prozess versteht man eine Weiterentwicklung des iterativen Paradigmas, bei der

die Planung der Iterationen dynamisch erfolgt undvon Anfang an Prototypen erstellt werden

Charakteristikum:kontinuierliche Anpassung an Änderungen

Prinzipien:Individuum und Interaktion (geht) vor Prozess und Werkzeugausführbare SW vor vollständiger DokumentationZusammenarbeit mit Kunden vor VertragsverhandlungBerücksichtigung von Änderungen vor Beharren auf Plan

Bekannte Vorgehensweisen:XPSCRUM, ...



56

XP (Extreme Programming)

MerkmaleXP arbeitet mit kleinen Releases, unterteilt in Iterationen und Arbeitspakete.Anforderungsanalyse

Aufgaben und Anforderungen in Form von StoriesBeschränkung auf wenige Anforderungen pro Iteration

Pair ProgrammingZwei Personen vor einem Rechner, einer programmiert, der andere ist Sparringspartner.

Enthält Elemente des Prototyping, allerdings ohne Wegwerfen.Auftraggeber wird besser eingebunden, kann konkrete Ergebnisse sehen.

Prozess: Test-first: Zuerst Tests (Spezifikation) schreiben, dann programmieren. Kontinuierliches Refactoring zur Verbesserung der Code-Qualität.



57

Das adaptive Paradigma: Vor-

und Nachteile

VorteileGut einsetzbar bei unklaren Zielen und sich ändernden Anforderungen/UmgebungVerspricht besseres Kosten/Nutzen-VerhältnisVermutlich durchschnittliche Code-Qualität besser

NachteileErgebnis ist nicht vorhersagbar

Qualitätseigenschaften können nicht garantiert werdenOft nicht nachvollziehbar, wie eine Funktion zustande kommt

80-90% aller Software läuft auf eingebetteten Systemen.Das bezieht sich z.B. auf Maschinen und Anlagen jeder Art und Größe, Verkehrsmittel, Militärische Anwendungen, Medizinische Geräte.Hier sind Fehler fatal - ein „agiler“ Prozess kommt nicht (oft) in Frage.

Refactoring geht nicht bei Nicht-oo-Sprachen.Aber ein Großteil (ca. 90%) der bestehenden Applikationen weltweit ist in Cobol, PL1, Assembler und C, und OO-Sprachen sind nicht immer optimal.



58

Wasserfallmodell versus Inkrementelle Software-Entwicklung

Was ist besser?



59

Wasserfallmodell versus Inkrementelle Software-Entwicklung

WasserfallHohe Sicherheit für Software-AnbieterGesamtblick (aber: zu viele Details)Unüberschaubare KonzeptpapiereGeringere Flexibilität, aber Change-Request-VerfahrenNutzen erst bei Einführung„Deckel drauf bekommen“Einfache Struktur, Qualitätssicherung zwischen PhasenEntspricht Denkweise: Geld für definierte Leistung



Iteratives VorgehenFrüher Nutzen für KundenBesseres, qualifizierteres FeedbackKosten für ÜbergangslösungenSchwieriger zu managenGeringeres Einführungsrisiko

60

Verbesserung: Gestuftes Vorgehen



Wasserfall als Vorgehen stößt an Grenzen

Große Projekte werden handhabbar

Verringern des RisikosFachliches RisikoTechnisches Risiko

Die elegante Art, „nein“ zu sagen: Stufen bedeuten, dass Anforderungen nicht oder erst später erfüllt werden

Widerstände müssen überwunden werden: Management-Aufgabe

61

Gestuftes Vorgehen

Bei Aufsetzen des ProjektsImmer den Umfang des Projekts im Auge behaltenBei größerem Umfang Stufung versuchen

Umfang niemals unterschätzen!

Nach Fachkonzeption oder StudieZusätzlicher Schnittpunkt für Stufenbildung (fachlich)

Indizien für zu großen ProjektumfangUmfang der Konzeptpapiere: größer als 200 Seiten?Feedback der Reviewer/externen Beteiligten: wirken sie noch mit, lesen sie die Papiere?



62

Beispiele für gestuftes Vorgehen im Projekt



63

Projektorganisation

Projektorganisation: Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes

[nach DIN 69 901]Einrichten einer projektspezifischen Organisation:

Aufbauorganisation:Einbinden des Projekts in die UnternehmensorganisationEinrichten von Rollen und Verantwortlichkeiten

Ablauforganisation:Abwickeln des Projekts entsprechend des EntwicklungsprozessFestlegen von Aktivitäten und Abläufen

In der Projektorganisation wird folgendes festgelegt:Arbeitsteilung zwischen Personen und TeamsAKV: Aufgaben, Kompetenzen, VerantwortlichkeitenWeisungsbefugnisse, Kontrollrechte und AufsichtspflichtenKoordinationsinstrumente (z. B. Abstimmungszirkel)



64

Unternehmensstrukturen

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, Methodenberatung



65Projektmanagement M2 –


Varianten von Organisationsformen

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 NiederlassungenNach Kunden

66

Bereichsstruktur



Schwerpunkte: Know-How-Transfer, Ressourcenflexibilität

67

Marktstruktur



Schwerpunkte: Effizienz, Produktidentifikation, minimierte Kommunikation

68

Vor-

und Nachteile der Organisationsformen

Bereichsstrukturierte Organisation:Vorteile:

Standardisierung der Abläufe, erhöhte WirtschaftlichkeitSpezialisierung, Fachhierarchien, Wissenstransfer

Nachteile:Aufwändige Koordination funktionsübergreifender TätigkeitenMangelnde Flexibilität

Ausrichtung: Fertigung von StandardproduktenMarktorientierte 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



69

Projektformen



Wesentliches Element: VerantwortungFachliche 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:Projektorganisation als Linien-OrganisationStab-Linien-OrganisationMatrixorganisation

70

Projektorganisation als Linienorganisation



• Eignung: Kritische Projekte mit hoher Priorität

71


Prinzip:Eigenständige Organisationseinheit für ProjektProjektmitarbeiter werden aus Bereichen freigestellt

Verantwortung Projektleiter:Fachliche Verantwortung UNDFührungsverantwortung

Vorteile:Klare Kompetenzen und VerantwortlichkeitenHohe ProjektidentifikationKurze Kommunikationswege

Nachteile:Umstellungsaufwände durch Aus- und WiedereingliederungSchwächung der Bereiche, ev. Konkurrenzsituation mit BereichenProblem der ungleichmäßigen Projektbelastung






Extremfall: Projektstruktur als Unternehmensform

73

Beispiel: sd&m

Sonderfall: IT-ProjekthäuserFür IT-Projekthäuser ist der Sonderfall „Projekt“ die Regel

können ihre Linienorganisation nach der Projektorganisation aufstellen.Dies betrifft aber nur den IT-Teil eines Projekts. Der Kontakt zum fachlichen Treiber des Projekts (Business-Case-Owner) und den Fachspezialisten des Unternehmens überschreitet die Projektgrenze

Das Unternehmen, das den Auftrag gibt, stellt in der Regel ein spiegelbildlich kleineres Projekt mit Ansprechpartnern für das externe IT-Projekt auf. Dabei muss der Konflikt zwischen Linien- und Projektorganisation gelöst werden.

©




Stab-Linien-Organisation

Eignung: Niedrigpriore Projekte oder Konsensprojekte



Stab-Linien-Organisation

Prinzip:Keine Leitungsinstanz/Organisationseinheit für ProjektProjektmitarbeiter verbleiben vollständig in Bereichen

Verantwortung Projektleiter (hier typischerweise „Koordinator“):Keine fachliche VerantwortungKeine FührungsverantwortungStabsfunktion (berichtend, koordinierend)

Vorteile:Schneller Know-How-TransferFlexible KapazitätsauslastungKeine Umstellungsaufwände

Nachteile:Aufwändige Koordinations- und AbstimmungsprozesseKeine ProjektidentifikationKeine Instanz mit Weisungsbefugnis

76

Matrixorganisation

Prinzip:Zeitlich befristetes MehrliniensystemProjektmitarbeiter verbleiben vollständig in Bereichen

Verantwortung Projektleiter:Fachliche VerantwortungKeine Führungsverantwortung

Vorteile:Schneller Know-How-TransferOptimale KapazitätsauslastungGeringe Umstellungsaufwände

Nachteile:Konfliktpotential durch DoppelunterstellungHohe Anforderungen an Selbstdisziplin und EigenständigkeitHohe Anforderung an Teamfähigkeit und Sozialkompetenz von Mitarbeitern und Leitungskräften



77

Matrixorganisation



Eignung: Flexible Projektabwicklung in dynamischem Umfeld (Markt und Technologiedynamik)

78

Interne Projektstruktur

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)



79

Ablauf-

vs. Produktorganisation von Projekten

Projektorganisation ähnlich ProduktstrukturMehrere Teams mit der Verantwortung für jeweils eine Produktkomponente, ein fachliches Thema, z. B.: Stammdatenverarbeitung, Versandfunktionen, …Koordination der erarbeiteten Ergebnisse durch fachlichen und technischen Architekten

Projektorganisation nach Phasen/Rollen im EntwicklungsprozessTeams für die Phasen des Entwicklungsprozesses:

Fachteam für fachliche SpezifikationTechnisches Team für technische Konstruktion, ImplementierungTest-Team

tech./fach. Architekten arbeiten in den Teams mit.





Produkt-

vs. Ablauforganisation

Produkt-Organisation:

Ablauf-Organisation:

81

Vergleich der Organisationsformen



Produktorganisation

Kontinuität, Wissenstransfer während der Phasen des Software-Entwicklungsprozesses besser.Fachliche Spezifikation entsteht im Bewusstsein, dass diese Spezifikation durch die gleichen Personen umgesetzt werden muss.Erfordert Generalisten, die gleich gut spezifizieren wie programmieren können.

AblauforganisationSpezialisten für einzelne Tätigkeiten können ihre Aufgabe besser durchführen.

Koordination und Wissensweitergabe zwischen Spezifikation und Umsetzung nur auf dem Papier.

Spezialisten sind im „Leerlauf“, wenn sie im SE-Prozess nicht benötigt werden.

82

Rollen

Rollenstruktur: Beeinflusst von:Prozessstruktur (z.B. Analyse, Design, Implementierung, Integration)Produktstruktur (z.B. Präsentation, Logik, Datenhaltung)

Projektrollen:ProjektausschussAuftraggeberAnwenderProjektleiterProjektmitarbeiter



83

Rolle: Projektleiter

Aufgaben:Erstellung Projekt-, Termin- und KostenplanOrganisation und Koordination ProjektteamDurchführung FortschrittskontrolleSteuerung und Festlegung von Entscheidungen (fachlich)Evtl.: Personelle Betreuung Projektmitarbeiter

Kompetenzen:Mitwirkung bei der ProjektzieldefinitionMitspracherecht bei der Bestimmung der Fachverantwortlichenprojektbezogenes Informations-, Weisungs- und Entscheidungsrecht



84

Rolle: Mitarbeiter

Aufgaben:Mitwirkung an ProjektplanungDurchführung der zugewiesenen ArbeitspaketeDokumentation der zugewiesenen Arbeitsergebnisse

Kompetenzen:Vorbereitung/Herbeiführung von EntscheidungenUmsetzung von VorgabenEinsatz von Ressourcen



85

Weitere Mitarbeiter-Rollen

Software Engineering-spezifische Team-Rollen:SystemanalytikerSystementwicklerTester

Software Engineering-spezifische Stabs-Rollen:Qualitätsmanager, QualitätsbeauftragterKonfigurationsmanagerIT-SicherheitsbeauftragterProjekt-Controller

Generelle Prinzipien:Personifizierte VerantwortungKlare Aufgaben und Kompetenzen



86

Zusammenfassung (1)

Das sequentielle Prozessparadigma (Wasserfall, klassisches V-Modell)ist

einfach durchzuführenauch für sehr große Projekte anwendbarsehr effizient bei bekannten und konstanten Anforderungen

ABER Risiken gesammelt am Schluss („Big Bang“) und starr während des Ablaufs

Das iterative Paradigma (RUP, Spiralmodell) erleichtertfrühe Erkennung von RisikenBerücksichtigung sich ändernder Anforderungen inkrementelle Auslieferung

ABER es erfordert Mehrarbeit, komplexeres Projektmanagement und istschwerer messbar



87

Zusammenfassung (2)

Das agile Prozessparadigma (XP) istGut einsetzbar bei unklaren Zielen und sich ändernden Anforderungen/UmgebungVerspricht besseres Kosten/Nutzen-VerhältnisVermutlich durchschnittliche Code-Qualität besser

ABER das Ergebnis ist nicht vorhersagbarQualitätseigenschaften können nicht garantiert werden

Ein gestuftes Vorgehen verbindet die Vorteile von sequentiellem und iterativem Vorgehen und vermeidet Nachteile wie „Big-Bang“ und hohem Mehraufwand.



88

Zusammenfassung (3)

Als Projektorganisation bezeichnet man die Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten ProjektesDie Grundstruktur eines Unternehmens besteht aus :

Organisationsleitung, Mittellinie, Betrieblichem Kern und StabMan unterscheidet Markt- und Bereichsstruktur

Mögliche Projektstrukturen sindStab-Linien-OrganisationProjektorganisation als Linien-OrganisationMatrixorganisation

Typische Projektrollen sind ProjektausschussAuftraggeberAnwenderProjektleiterProjektmitarbeiter



Projektmanagement: Projektvorbereitung und -abschluss

90

Ziele

Tätigkeiten der Projektvorbereitung kennen lernen:Projekt-Idee und StudieBeauftragung mit Ausschreibung, Angebot und AuftragProjektinitialisierung undKick-Off-Meeting

Tätigkeiten am Projektende kennen lernen:ProjektabschlussTouch Down Meeting


Projektvorbereitung

9191

Grundparameter Projektmanagement

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

92

Projektverlauf


Projektvorbereitung

93

Auslöser von Projekten

Beispiele für Auslöser von ProjektenIn Großunternehmen

Auslöser in Großunternehmen:In einem Großunternehmen wird eine neue Unternehmensstrategie festgelegt, bzw. neue Aspekte eingebracht.Eine neue IT-Strategie wird festgelegt.Ein Programm zur Kostensenkung/Effizienzsteigerung wird aufgelegt.Ein neuer Markt soll erschlossen werden.

Ein Business Case wird erstellt: Warum lohnt sich eine Investition, was ist der erwartete Nutzen, was sind die erwarteten Kosten? Ab wann überwiegt der Nutzen (gespartes/eingenommenes Geld) die Kosten der Investition? (ROI – Return On Investment)In der IT muss etwas gemacht werden: neue Software, umfangreiche Umstellung existierender Software – ein Projekt!

In der ForschungAuslöser

In einer Technologiestudie der EU wird Forschungsbedarf auf bestimmten Gebieten postulier; Projektideen werden in Workshops vorgestellt.

Ein neues Forschungsprogramm mit „Calls for Proposals“ wird beschlossen.Aufgrund von Projektideen formieren sich Forschungskonsortia, die Projektanträge einreichen.


Projektvorbereitung

94

Studie

Eine Studie dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts. Sie enthält i.a.

Grobdefinition der Ziele des ProjektsGrobabschätzung des NutzensGrobabschätzung der Kosten und benötigten EinsatzmittelErstvorschlag zur Projektorganisation

Eine Studie im Vorfeld gibt es z. B. in folgenden Fällenbei größeren Vorhabenwenn die Aufgabenstellung noch nicht ganz klar istwenn genauer nachvollzogen werden soll, ob sich die Investition lohnt.

Unterschiedliche Arten von StudienAuftragsprojekt: AnforderungskatalogInnovationsprojekt: Marktstudie/TechnologiestudiePflege/Änderungsprojekt: Verbesserungsvorgaben

Wichtig:Festlegung ProjekterfolgskriterienMessbare Kriterien


Projektvorbereitung

95

Durchführungsentscheidung

Ziel: Annahme/Ablehnung ProjektVerfahren:

Ermittlung Kosten: Auf Basis Studie/GrobplanPersonalkosten (inkl. Personalvorbereitung)BetriebsmittelkostenOrganisationskosten

Ermittlung Nutzen:Monetärer Gewinn: Marktanalyse, EffizienzanalyseInvestitionsgewinn

Risikoanalyse:Wirtschaftliche RisikenFachliche RisikenEvtl: Alternativen erstellen und beurteilen

Ergebnis: Annahme oder Ablehnung des Projekts


Projektvorbereitung

96

Beauftragung


Projektvorbereitung

97

Ein Projekt braucht einen Auftrag

Das neue Projektmanagement kommt ins Spiel: ein Auftrag für das Projekt wird erteilt, aber manchmal:

Leider nur mündlichZusätzliche AbsprachenUnvollständig

Im Projekt wird der Projektauftrag vervollständigt bzw. geschrieben.Zweck:

Ziele und Aufgabenstellung für das Projekt glasklar festlegenEin Auftrag muss schriftlich fixiert seinBei Gesprächen ist vieles „klar“, richtig klar ist es erst, wenn es schriftlich festgehalten ist.Verbindlichkeit schaffen: der Auftraggeber unterschreibt den Auftrag.


Projektvorbereitung

98

Inhalte eines Projektauftrags

Projektleiter: Verantwortlicher für das ProjektAuftraggeber: Wer will das Projekt eigentlich? Derjenige, der bezahlt, bestimmt auch – bzw. – wer bestimmen will, muss auch zahlen.Kurzbeschreibung des ProjektsZiele, ggf. hierarchisch verfeinertZu erbringende Leistungen und Ergebnisse, häufig als „Technischer Anhang“ mit

Beschreibung des Grobkonzepts (Systemspezifikation)Umfasst: Beschreibung des Leistungsumfang (Pflichtenheft)Umfasst: Beschreibung des Anwendungsgebietes (Lastenheft)

Projektgrobplan: Termine und AufwändeProjekthandbuch: Entwicklungsprozess

RahmenbedingungenAbhängigkeiten von anderen Projekten und Personen, ZulieferungenStart, Ende, Meilensteine


Projektvorbereitung

99

Wenn der Projektauftrag nicht fertig werden will…

Beispielhafte Gründe, warum man anfangen will, obwohl der Auftrag nicht fertig ist:

Geld ist schon da, verfällt sonstProjektmitarbeiter sind schon freigestellt, müssen beschäftigt werdenFormulierung scheitert an vermeintlich unwichtigen DetailsDas Schreiben ist lästig, der Kopf ist voller Ideen und man möchte lieber loslegen.

Dann kann/sollte man trotzdem……nicht anfangen!das Problem klar an die Leute eskalieren, die im Management die Verantwortung tragen


Projektvorbereitung

100

Projektinitialisierung


Projektvorbereitung

101

Projektinitialisierung

Ziel: Die Arbeit kann beginnen, das Team kann loslegen, alle Rahmenbedingungen sind geschaffen.Wichtig: Kernteam muss in der Projektinitialisierung besetzt sein

ProjektleiterQualitätssichererMitarbeiter, der inhaltlich für Kontinuität sorgt: Aus Angebot oder Vorstudie.

Der Auftraggeber muss auch ein Gegenstück/Ansprechpartner zum Projekt organisieren


Projektvorbereitung

102

Besetzung des Projektleiters

Häufiges Problem: Projektleiter kommt erst spät in das ProjektGute Projektleiter sind ein rares Gut und müssen oft erst aus anderen Projekten herausgelöst werden.Viele Mitarbeiter scheuen die Verantwortung, deswegen sind Projektleiter schwer zu finden.

Mögliche Konsequenzen:Die Initialisierung findet erst während des Projekts statt: ZeitverlustDer Projektleiter kann ein Projekt erst nach einer Einarbeitung sinnvoll leiten: Das Projekt ist zunächst führungslosDie Initialisierung wird nur halbherzig vorgenommen, weil derjenige, der die Konsequenzen einer mangelhaften Initialisierung ausbaden muss, noch nicht da ist.

Ein Projekt in einer bestimmten Richtung aufzusetzen und anzuschieben ist relativ einfach. Ein laufendes Projekt in eine andere Richtung zu lenken ist sehr aufwändig.Auch als designierter Projektleiter haben Sie die Möglichkeit darauf hinzuwirken, dass Sie nicht zu spät ins Projekt kommen.


Projektvorbereitung

103

Tätigkeiten während der Projektinitialisierung

Ziele klären Qualitätskriterien klärenOrganisation des Projekts festlegen, einschließlich Ansprechpartner des AuftraggebersProjektstruktur im Projektstrukturplan festlegen (falls nicht schon im Auftrag fixiert)Schätzung validierenPlanung: Grob- und Feinplanung für die ersten SchritteInfrastruktur etablierenStruktur für das Controlling aufsetzenIm Projekthandbuch festhalten


Projektvorbereitung

104

Initialisierung: Warum braucht ein Projekt Ziele?


Projektvorbereitung

Quelle: G. Pews sd&m

105

Ziele

Ziele sind elementar wichtig in einem ProjektErzeugen ein gemeinsames Bild, eine gemeinsame AusrichtungSind einfach kommunizierbar

Ziele sollte man für alle wichtigen Tätigkeiten definierenz. B.: Meetings (Schlechtes Ziel: „Wir haben darüber gesprochen“)z. B.: Dokumente: wozu ist das Dokument gut, was macht man damit?

Was ist ihr Ziel in dieser Vorlesung?


Projektvorbereitung

106

Ziele formulieren

AusgangsbasisAuftrag, Vertrag, Briefing, etc.

Was tun, wenn keine klare Aussage vom Auftraggeber vorhanden?Nicht einfach loslegen und die Versäumnisse anderer kompensieren wollen. Aber: einfach blockieren ist nicht hilfreich.Formulieren von Zielen als ArbeitshypothesenArbeitshypothesen dem Auftraggeber mitteilenDiese Technik funktioniert generell an vielen Stellen des Projekts.

Ziele SMART festhalten


Projektvorbereitung

107

SMARTe Ziele

S pezifisch Knackig, verständlich, eindeutig, stimmig mit anderen Zielen.

M easurable Messbar. Es muss klar sein, wann das Ziel erreicht ist.A chievable Erreichbar. Unerreichbare Ziele führen zu Demotivation.R elevant Die wichtigen Dinge als Ziel formulieren, nicht jeden

Kleinkram.T ime-based Es gibt einen Zeitpunkt, an dem das Ziel erreicht sein soll

(ist im Projektkontext automatisch gegeben)

Ziele müssen von ihrer Formulierung her attraktiv sein!


Projektvorbereitung


Projektvorbereitung

Antoine de Saint Exupéry:„Wenn du mit anderen ein Schiff bauen willst,so beginne nicht, mit ihnen Holz zusammeln, sondern wecke in ihnen dieSehnsucht nach dem großen, weiten Meer.“

109

Ziele formulieren

Ein Ziel aktiv formulieren:Nicht: Man wird mir das Rauchen abgewöhnenSondern: Ich werde nicht mehr rauchen.

Ein Ziel so formulieren, als ob es schon erreicht ist (Gegenwart statt Zukunft):

Nicht: Ich werde nicht mehr rauchenSondern: Ich rauche nicht mehr.

Ein Ziel positiv formulieren:Nicht: Ich rauche nicht mehr.Sondern: Ich kann frei atmen, ich bin gesund

Sinn: Den Zielzustand heute schon im Kopf erleben, damit man diesen Zustand anstrebt.


Projektvorbereitung

110

Qualitätskriterien festlegen

Vom Auftraggeber die Qualitätskriterien erfragen, nach denen er seine Zufriedenheit misst.Beispiele

Know-how beim Auftraggeber aufbauenSich pro-aktiv um alles kümmern (Auftraggeber-Sorglos-Paket)Qualifizierte Mitarbeiter ins Projekt steckenSchnelle Resultate, schnell ein vorzeigbares Ergebnisallg.: Herausfinden, an welchen Ecken des Teufelsquadrats gezogen werden kann

Tipps: Nicht mit einer Auswahlliste arbeiten, sondern frei formulieren lassen.Nur bei Bedarf mit Beispielen aushelfen

Vom Auftraggeber nicht genannte Kriterien sind für ihn entweder selbstverständlich oder weniger wichtig.


Projektvorbereitung

111

Projektstrukturplan

ZielZerteilung des Projekts in kleinere Einheiten, die man besser managen kann.

Grundsätzliche Struktur, die sich im gesamten Projekt wiederfindet.Strukturierungsmerkmale:

Orientierung an der Produktstruktur der SoftwareOrientierung am ProjektablablaufOrientierung an den Funktionen im Projekt

Mischformen sind üblichMuss (wie jeder Plan) bei Bedarf angepasst werden.


Projektvorbereitung

112

Projektinfrastruktur (1/2)

Die Projektinfrastruktur umfasst alle Hilfsmittel, die das Team zum Arbeiten benötigtInfrastruktur

Räume, Arbeitsmittel (Rechner, Drucker, Telefone, Videokonferenz…). Gemeinsame Räume sind wichtig für Informationsfluss und Teamgeist.

Software-Umgebungen (Entwicklung, Test, Qualitätssicherung)Projektkommunikation/Projektablage

Konform zu Organisation und Projektstrukturplanz. B. gemeinsames Wiki (mit Sicherung!) für verteilte Teams und Teams unterschiedlicher Firmen


Projektvorbereitung

113

Projektinfrastruktur

Werkzeuge bereitstellenOffice-Tools, Druckstückerzeugung/PDF, Konfig-Mgmt, Software-Entwicklung, Test, Anforderungsmanagement, Zeichentools, Modellierungstools, Projektplanungstool, DB-Tool

Wenn schon bekannt: Aufbau der Software-Infrastruktur planen bzw. veranlassen: z. B.:

Middleware wie CORBA, MQ-Series,Application Server,Datenbank,

Kommunikationstools wie Wiki, NetMeeting, etc.E-Mail Verteiler, etc.Nutzungskonzepte: Ein Werkzeug allein reicht oft nicht, es muss auch festgelegt sein, wie es im Projekt eingesetzt werden soll.


Projektvorbereitung

114

Infrastruktur etablieren

Etablieren der Infrastruktur hört sich trivial an, aberist zeitaufwändig und daher nicht zu unterschätzennicht vorhandene Infrastruktur behindert das Team massiv.

Tipp: Aufbau der Infrastruktur früh planen und initiieren, Anschaffungen haben oft langen Vorlauf.


Projektvorbereitung

115

Strukturen für Projektcontrolling aufsetzen

Verfolgung der Aufwände und des Budgets erfolgt i. d. R. über spezielle Zeiterfassungs-Tools oder manuell in tabellarischer Form.

Dabei vermerken die Projektmitarbeiter, an welchen Aufgaben sie wann und wie lange gearbeitet haben.Diese Informationen lassen sich im Nachhinein kaum noch rekonstruieren, sind aber die Grundlage für die Abrechung und die Aufwandsverfolgung.

Gerade in gemischten Teams mit Mitarbeitern verschiedener Firmen und Freelancern wichtig.In der Regel benötigt man zwei Sichten:

Die Projektinnensicht, auf der detailliert festgehalten ist, wer an welcher Aufgabe wie lange gearbeitet hat.Die Außensicht, die einem Auftraggeber gegenüber als Abrechnungsgrundlage dient.

Solche Sichten können sich unterscheiden:Die Granularität der Aufgaben, die ausgewiesen werden. Manchmal ist es auch nötig, nach außen andere Aufgaben auszuweisen als tatsächlich durchgeführt werden. Z. B.: Ausweisen von Reisekosten und -zeiten.Die Maßeinheiten der Abrechnung: Tage, Wochen oder Stunden. Festlegung, mit wie vielen Stunden ein Tag angesetzt wird: 7,7h (38,5h-Woche), 8h (40h-Woche), 9h oder 10h.


Projektvorbereitung

116

Tipps für das Projektcontrolling

Gerade wenn noch weitere Firmen (z. B. Freelancer, etc.) am Projekt teilnehmen, ist man verleitet, neue Sichten zu definieren. Auch wenn sich die Umrechnungsregeln einfach anhören mögen, bringt man leicht unnötige Komplexität in das Projekt.Im Controlling nicht zu fein erfassen wollen. Die Aufwände sollten sich noch in Tagen erfassen lassen, nicht in Stunden.Die Kontenstruktur orientiert sich an den Arbeitspaketen im Projektplan.


Projektvorbereitung

117

Kick-Off Meeting

Ziele des Kick-OffsDas Team auf ein gemeinsames Ziel einschwören.Bewussten Startpunkt für die Projektarbeit setzen: „Jetzt geht‘s los!“Teambuilding: es ist wichtig, dass sich Projektmitarbeiter als Team verstehenTeam über die wichtigsten Inhalte der Projektinitialisierung informieren, auf Stand zum Arbeiten bringen.

Inhalte des Kick-OffsProjektziele, Inhalt des ProjektauftragsProjektstrukturProjektvorgehen und Planung kommunizieren: wichtige MeilensteineWichtige Standards festlegenVerantwortlichkeiten, Rollen kommunizieren, OrganigrammVerhaltens- und Kommunikationsregeln des Teams, ggf. erarbeiten.


Projektvorbereitung

118

Durchführung des Kick-Offs

Dauer des Kick-Offs: ca. ½ - 1 TagModeration durch ProjektleiterTipps:

Früh genug darum kümmern, dass alle am Kick-Off teilnehmen könnenGut vorbereitet sein: Präsentation vorbereiten, nicht darauf verlassen, dass man die Inhalte aus der Initialisierung immer noch präsent hatBei Teams mit unterschiedlichem Erfahrungshintergrund die grundlegende Begriffe klarstellen

z. B. Begrifflichkeiten für elementare Tätigkeiten (Fachkonzept, Pflichtenheft, etc...)Spezialbegriffe des Projektmanagements: CR, QM-Plan, Projektstrukturplan, etc.

Das Meeting mit einem informellen Teil zu verbinden, z. B.:anschließendes, gemeinsames EssenBeieinandersein an Stehtischen im FoyerGute Gelegenheit, einen persönlichen Draht zu entwickeln und Meinungen zu hören, die die Leute in größerer Runde nicht äußern wollen

Meeting extern durchführen, z. B. in Tagungshotel


Projektvorbereitung

119

Nachbereitung des Kick-Offs

Zumindest ein Protokoll machen und Ergebnisse des Kick-Offs konservierenEin Protokoll ist ein gutes Symbol: Protokolle werden auch im weiteren Projekt benötigt, also gleich mit gutem Vorbild voran gehen. Protokolle erstellt und verschickt man zeitnah.Mit Folien zusammen per Email an die Teilnehmer verschicken odergleich die vorhergesehene Stelle auf der Teamablage nutzen


Projektvorbereitung

120

Projektablauf


Projektvorbereitung

121

Projektabschluss und Touch Down

Formaler Projektabschluss: Definierte Beendigung eines ProjektsErreichen des ProjektzielsAbbruch eines Projekts

Prozessabschluss hat unterschiedliche Dimensionen:Produktdimension:

Sicherung der Produkte und ErgebnisseVorbereitung Softwarepflege und ÄnderungVorbereitung der Wiederverwendung/Verbreitung der Ergebnisse

Projektdimension:Freigeben von Ressourcen und PersonalRechenschaftsberichte erstellenProjekt auflösen

Projektabschluss umfasst Abnahme durch Auftraggeber und (internen) Touch Down


Projektvorbereitung

122

Projektabschluss: Abnahme

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)


Projektvorbereitung

123

Projektabschluss: Abnahme

Zweigliedriger Abnahmebegriffkö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.)


Projektvorbereitung

124

Projektabschluss: Abnahmekriterien

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!


Projektvorbereitung

125

Projektabschluss: Abnahmephasen

Abnahmephasen:Ü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


Projektvorbereitung

126

Projektabschluss: Rechtliche Auswirkungen

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)


Projektvorbereitung

127

Projektabschluss: Bemerkungen

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


Projektvorbereitung

128

Touch-Down

Ziele des Touch-Downs: Nach abgeschlossenem Projekt ein Resümee ziehen und für das nächste Mal lernen.Vorbereitung des Touch-Down-Meetings

Besondere Erfahrungen des Projektteams werden konsolidiert und festgehalten

Nachkalkulation: Die tatsächlichen Aufwände mit den geschätzten Aufwänden aus der Angebotsphase verglichenArchivierung der Projektergebnisse: nicht einfach auf einem Laufwerk liegen lassen, irgendwann sind sie weg.


Projektvorbereitung

129

Touch-Down Meeting

Gegenstück zum Kick-Off: Das offizielle Ende der ProjektdurchführungTeilnehmer:

alle ProjektbeteiligtenBei Auftraggeber/Auftragnehmer-Situation: gern auch beteiligte Mitarbeiter des Auftraggebers, dann aber noch einen Auftragnehmer-internen Touch-Down machen

In einem Rückblick werden Stärken und Schwächen des Projekts und Probleme einzelner diskutiert.Im Projektrückblick werden die Leistungen in der Projektdurchführung kritisch betrachtet.Unangenehm? Trotzdem machen!


Projektvorbereitung

130

Exkurs: Werkleistungen und Dienstleistungen


Projektvorbereitung

Werkvertrag für Gewerkegeschuldet ist ein Werk, der ProjekterfolgGeld gibt‘s für den ErfolgDas Risiko liegt beim AuftragnehmerAber: der Auftragnehmer hat die Freiheit zu entscheiden, wie er den Erfolg erzielt.

Dienstvertrag für Dienstleistungen

Geschuldet ist die TätigkeitGeld gibt es, wenn man arbeitet, auch wenn der Projekterfolg nicht eintritt.Das Risiko liegt beim AuftraggeberAuftraggeber kann Vorgehensweise, Arbeitsort und -zeiten bestimmen. Abwertende Bezeichnung: BodyLeasing

131

Exkurs: Werkleistungen

Abnahme für das GewerkÜblich: Abnahme dadurch, dass ein System produktiv genutzt wird „konkludente Abnahme“Nach der Abnahme: Gewährleistung (2 Jahre nach Abnahme)Abschlagszahlungen auf Zwischenergebnisse (als Vorschuss auf dieGesamtvergütung)Oft: Werkvertrag zum Festpreis, Dienstvertrag nach Aufwand

muss aber nicht zwingend so sein.


Projektvorbereitung

132

Zusammenfassung (1)

Die Projektvorbereitung umfasst Projekt-Idee und StudieBeauftragung mit Ausschreibung, Angebot und AuftragProjektinitialisierung undKick-Off-Meeting

Eine Studie dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts.Ein Auftrag sollte enthalten

Projektleiter, Auftraggeber Kurzbeschreibung und Ziele des Projekts Zu erbringende Leistungen und Ergebnisse, häufig als „Technischer Anhang“RahmenbedingungenAbhängigkeiten von anderen Projekten und Personen, ZulieferungenStart, Ende, Meilensteine


Projektvorbereitung

133

Zusammenfassung (2)

Tätigkeiten während der Projektinitialisierung umfassenKlärung der Ziele und QualitätskriterienFestlegung der Organisation des Projekts und der Projektstruktur (im Projektstrukturplan) Validierung der Schätzung Grob- und Feinplanung für die ersten SchritteEtablierung der Infrastruktur und der Struktur für das Controlling

Ein Kick-Off-Meeting ist wichtig umdas Team auf ein gemeinsames Ziel einschwören undwichtige Ziele, Verantwortlichkeiten, Standards etc zu kommunizieren

Das Projektende tritt ein bei Erreichen des ProjektzielsAbbruch eines Projekts

Der Projektabschluss umfasst Abnahme durch Auftraggeber und (internen) Touch Down, um ein Resümee ziehen und für das nächste Mal zu lernen


Projektvorbereitung

Projektmanagement: Schätzverfahren

135

Ziele

Generelles Vorgehen bei Schätzungen kennen lernenGrundlegende Schätzmuster und Maße zur Systemkomplexität kennen lernenSchätzverfahren für den Aufwand eines Software-Projekts kennen lernen und beurteilen

Delphi-MethodeFunction PointsCoCoMo


Schätzung

136

Schätzverfahren

„Was man nicht misst, das kann man nicht steuern.“[Tom de Marco, Controlling Software Projects, 1982.]

Messung von Softwaresystemen:Zu Projektbeginn: Projektplanung (Schätzung)Bei Durchführung: Projektstatus/Projektsteuerung

Ziel des Schätzens:Bestimmung des Entwicklungsaufwands

RealisierungsaufwandRealisierungszeit

Abhängig von Systemkomplexität und ProduktivitätMöglichst vor Systemrealisierung

Prinzipielle Strategie beim Schätzen: per AnalogieSchätzungen sind „unfair“:

Passieren zu einem sehr frühen ZeitpunktMan weiß wenig über die AufgabeAuf die Zahlen wird man später festgenagelt


Schätzung

137

Herangehensweisen

Von den Arbeitspaketen zur AufwandszahlSchätzung der einzelnen ArbeitspaketeSumme ergibt GesamtaufwandSchätzung als Grundlage für Aufwand

Vom fixierten Aufwand zu den ArbeitspaketenFrage: Was darf es denn insgesamt kosten?Projekt so aussteuern, dass es im Kostenrahmen bleibtAufgaben werden nur so „gut“ erledigt, wie Geld da istSchätzung zur Prüfung der Machbarkeit

Faustregeln:Hochinnovative Projekte kann man nicht schätzenNur normales Vorgehen lässt sich schätzen, radikales nichtProjekte mit fließenden Anforderungen kann man nicht verlässlich schätzen


Schätzung

138

Auswirkungen einer „falschen“

Schätzung

Zu hohe SchätzungIst kaum festzustellen. Jedes Projekt schöpft den Kostenrahmen voll aus.Gefahr: Business Case rechnet sich nicht, bzw. Projekt wird an Mitbewerber verloren.

Zu geringe SchätzungGeld reicht nicht, Projekt kann im Budget nicht durchgeführt werden

Das Projektmanagement hat extrem großen Einfluss auf die verbrauchten Aufwände eines Projekts. Im Nachhinein ist schwer festzustellen, ob der geschätzte Kostenrahmen realistisch war.


Schätzung

139

Motivation für eine Schätzung

Wenn eine Schätzung so fehlerbehaftet und schwierig ist, warum schätzt man dann überhaupt?

Auch eine „falsche“Schätzung ist besser als ein kompletter BlindflugAuch Schätzen ist ein Prozess: sobald erste Erfahrungen und ermittelte Aufwände im Projekt vorliegen, wird nachgeschätzt und die Schätzung korrigiertDie Schätzung wird im Laufe des Projekts immer genauer.


Schätzung

140

Einflussfaktoren auf den Aufwand (wichtigste Faktoren)


Schätzung

Umzusetzende Fachlichkeit (funktional)

MaskenDruckstückeBerechnungenzu berücksichtigende FehlersituationenMigrationen aus AltsystemenAbhängigkeit von anderen Systemen

Technologische Umsetzung, nicht-funktionale Anforderungen

Performance, AntwortzeitverhaltenArchitekturSystemplattform, Basis-Technologien

Projektmanagement-FaktorenTeam

MitarbeiterqualifikationErfahrungEingespieltes Team

ProjektorganisationProjektvorgehen, MethodikUnterstützung durch Tools

Sonstige FaktorenAuftraggeberAufwände steigen mit Größe der Aufgabe

141

Generelles Vorgehen bei der Schätzung

Eine gute Vorbereitung ist elementar für die SchätzungKomplettieren und Strukturieren der Schätzgrundlage

(osintots – oh shit, I never thought of this)

Sammeln aller Faktoren

Nachschätzen und aus Projekterfahrungen lernen ist ein stetiger Kreislauf während des Projekts


Schätzung

142

Schätzmuster

Schätzungen werden fast immer aus einer Kombinationen der folgenden grundlegenden Schätzmuster hergeleitetInsbesondere beruhen auch ausgefeilte Schätzmethoden wie Function Points, CoCoMo oder Delphi auf diesen Mustern, meist ergänzt um konkrete Zahlenwerte für Schätzformeln.

Schätzmuster:Schätzen durch VergleichSchätzen durch Zerlegung

Anforderungendes Entwurfs

Schätzen durch ExpertenSchätzen mit KorrekturfaktorenSchätzen mit Stellvertretergröße


Schätzung

Schema für Schätzmuster:Problem/KontextVorgehensideeVorteile, Nachteileevtl. Varianten, Anmerkungen

143

Schätzen durch Vergleich

Problem/Kontext:Wenn keine bessere Schätzmethode verfügbar ist, aber Erfahrungen mit Entwicklung ähnlicher Dinge und deren Aufwände noch

bekannt sind

Vorgehensidee:Wähle aus dem Erfahrungsschatz das ähnlichste Ding aus und benutze dessen Aufwand als Schätzung

VorteileEinfach, schnell

NachteileEvtl. zu wenig Erfahrung; Ähnlichkeitsmaß

unklar

Variante:Wähle mehrere Ähnlichste und mittele die Schätzung

Anmerkung:Alle anderen Schätzverfahren basieren letzten Endes auf Vergleich (explizit oder intuitiv)


Schätzung

144

Schätzen durch Zerlegung (Anforderungen)

Problem/Kontext:Wenn Anforderungen wenig voneinander abhängen, d.h. das System nur einen kleinen Kern aufweist

Vorgehensidee:Schätze Aufwand pro Anforderung einzeln; summiere

Vorteile: Starke Reduktion der Komplexität

Nachteile:Nur in wenigen Anwendungsgebieten sinnvoll,Meist ist der Kern für den Aufwand sehr relevant,Aufwandsmessungen liegen selten in dieser Form vor.

Anmerkung:Das „Function Point" Schätzverfahren beruht auf diesem Muster und ist für einfache Informationssysteme sehr bewährt.


Schätzung

145

Schätzen durch Zerlegung (Entwurf)

Problem/Kontext:Wenn die Architektur des Systems bereits erkennbar ist

Vorgehensidee:Schätze den Aufwand für die Subsysteme und addiere

Vorteile:Im Prinzip ist eine sehr genaue Zerlegung und Schätzung möglich

Nachteile:Irrtümer über Architektur möglich (insbes. Teile übersehen)Vernachlässigt Aufwand für Integration und nichtfunktionale Anforderungen

Anmerkung:Zumindest grobe Zerlegung wird in der Praxis fast immer eingesetzt.Oft läuft ein großer Teil der Zerlegung auf bloße Zählung hinaus, z.B. Anzahl "Dialoge" (Bildschirmmasken)


Schätzung

146

Schätzen durch Experten

Problem/Kontext:Wenn es Erfahrungen und Aufwandsdaten nicht schriftlich, wohl aber im Kopf von Experten gibt

Vorgehensidee:Bitte jede/n Experten/in separat um eine SchätzungLasse die Experten Ihre Schätzungen und Begründungen diskutieren und modifizierenResultat: Konsens über einen geschätzten Aufwandsbereich

Vorteile: Sehr breitbandig, bezieht enorm viele Faktoren einUnsicherheit der Schätzung wird ggf. klar sichtbar

Nachteile:Kann bei "Group think" zu dramatisch falschen Ergebnissen führen, die scheinbar vertrauenswürdig sind

Variante:Black Box Schätzung nur eines/r Experten/in

Anmerkung:Das „Delphi"

Schätzverfahren beruht auf diesem Muster. Projektmanagement M4 -

Schätzung

147

Schätzen durch Experten (mit Kombination von Schätzungen)

Problem/Kontext:Wenn mehrere Schätzungen verfügbar sind, deren Qualität aber unklar ist

Vorgehensidee:Kombiniere die Schätzungen zu einer (durch Bereichsbildung, Mittelung, Zurückweisung von Ausreißern etc.)

Vorteile:Erhöht die Robustheit der Schätzung

Nachteile:Gibt es systematische Fehler in vielen der Schätzungen, dann führt das Kombinieren in die Irre

Anmerkung:Das „Delphi"

Schätzverfahren wendet meist die Kombination von Schätzungen an.


Schätzung

148

Schätzen mit Korrekturfaktoren

Problem/Kontext:Wenn ein ähnliches Ding zum Vergleich verfügbar ist, es aber zum jetzigen Ding (identifizierbare) Unterschiede gibt

Vorgehensidee:Benutze den Aufwand des ähnlichen Dings und korrigiere ihn für jeden Unterschied um einen prozentualen Faktor herauf/herunter.Die einzelnen Faktoren werden wiederum geschätzt oder aus Erfahrungen entnommen.

Vorteile: Recht flexibel

Nachteile:Bei zu vielen Korrekturen wird das Ergebnis dubios.Bei zu wenig Erfahrung über einzelnen Korrekturfaktor ebenfalls.

Anmerkung:Das „CoCoMo" Schätzverfahren beruht hauptsächlich auf diesem Muster


Schätzung

149

Schätzen mit Stellvertretergrößen

Problem/Kontext:Wir besitzen Aufwandsdaten nur über andere Erfahrungsgrößen als die, die wir schätzen wollen, z.B. Produktivität in Anzahl an Zeilen von Code (Lines of Code, LoC) pro Personenmonat, aber diese Erfahrungsgröße (oder etwas Verwandtes) lässt sich schätzen

Vorgehensidee:Schätze nicht den Aufwand, sondern die schätzbare Größe und rechne dann um.

Vorteile: Evtl. ist Stellvertretergröße anschaulicher und besser zu schätzen

Nachteile:Evtl. wird Kontextabhängigkeit übersehen, z.B. Abhängigkeit der Produktivität an Zeilen von Code von der Programmiersprache

Anmerkung:Das „CoCoMo" Schätzverfahren verwendet die „Anzahl der Zeilen von Code" als Ausgangspunkt


Schätzung

150

Schätzverfahren: Delphi-Methode

Charakteristikum: Systematische Befragung von mindestens zwei Experten, die aus Erfahrung Voraussagen über den Zeit/Ressourcen-Bedarf einzelner Projektaktivitäten machen.

Varianten: Standard Delphi-Verfahren:

Befragung anonymBreitband Delphi-Verfahren:

Schätzergebnisse werden gegenseitig bekanntgegeben, damit Resultate diskutiert und ggf. korrigiert werden könnenHäufig Schätzung im Rahmen einer Schätzklausur


Schätzung

151

Schätzklausur

Phase 1: AuftragsdefinitionAuftraggeber, Kunde, Verantwortliche und Durchführende festlegen Ziel definierenAufgaben analysieren (Prozesszerlegung)

Phase 2: SchätzungsvorbereitungGeeignete Leute einladenFachleute, Verantwortliche, Durchführende2 Stunden ansetzenExcel-Sheet vorbereiten

Phase 3: SchätzungProjekt und Projektplan vorstellen, Aufwands- und Zeitplan austeilen, ggf. korrigieren (lassen)Jeder schreibt seine Schätzungen auf Ansage aufJeder sagt seine Schätzungen auf Ansage anExtrema diskutieren, ggf. entfernenMittelwerte bildenSumme bilden


Schätzung

152

Schätzklausur


Schätzung

Meistens gibt es anschließend noch eine Phase 4, in der die Schätzung interessengeleitet verändert wird.

153

Zwischenfazit


Schätzung

Sind Schätzungen notorisch ungenau –

wieso?

In wohlgeordneten Prozessen sind Schätzungen von einem zum nächsten Mal vergleichbar.

Man kann also aus Fehlern lernen.

Nicht so bei ungeordneten Prozessen.

Hier werden Fehler versteckt oder verdeckt.

154

Schätzverfahren: Funktionspunkte (Function Points -

FP)

Historie:Eingeführt 1979 von Alan Albrecht (IBM). Seit 1986 verwaltet und normiert durch die International Function Point User Group (IFPUG); Gegenstand der ISO-Standards 10926 und 14143-1:1998.

Idee:Schätzung des Arbeitsaufwands in Mann-Stunden anhand der vom Kunden gewünschten Funktionen

Vorgehen:Zähle und klassifiziere (als einfach, mittel, komplex) wenige Arten von Anforderungen, vergebe dafür jeweils Funktionspunkte (FP), summiere diese und bestimme Aufwand daraus per empirischem Umrechnungsfaktor (unangepasste FP)FP ist also ein StellvertreterverfahrenAnschließend kann man noch Projektumstände berücksichtigen, um die Schätzung anzupassen (angepasste FP)Hinzu kommt also ein Korrekturfaktorverfahren


Schätzung

155

Unangepasste FP (UFP)

Messverfahren: Klassifiziere Anforderungen in Eingaben Eingabemasken, für die Datensätze eingegeben werden könnenAusgaben Datenpräsentationsdarstellung ("Report")Abfragen Eingabe eines Suchkriteriums plus Anzeige des GefundenenDatenbestände Intern verwalteter Datenbestand (z.B. DB-Tabelle)Referenzdaten Schnittstelle/Datenformat zur Anbindung an anderes System

Bewerte jedes Element als einfach, mittel oder komplex und bilde die gewichtete Summe nach folgender Tabelle:

Item

einfach mittel komplexEingaben 3 4 6Ausgaben 4 5 7Interaktionen 3 4 6Datenbestände 7 10 15Referenzdaten 5 7 10


Schätzung

156

Angepasste FP

FP = UFP * TKwobei der Korrekturfaktor Technische Komplexität (TK)

gebildet wird durch

TK

= 0.65+0,01 Σi=1..14 Fi (d.h. 0.65 <= TK <= 1.35)

und Fi Korrekturwerte gemäß dem Schwierigkeitsgrad gewisser nichtfunktionaler Anforderungen darstellen:

F1

Reliable back-up and recovery

F2

Data communicationsF3

Distributed functions

F4

PerformanceF5

Heavily used configuration

F6

Online data entryF7

Operational ease

F8

Online updateF9

Complex interface

F10

Complex processingF11

Reusability

F12

Installation easeF13

Multiple sites

F14

Facilitate changehaben je einen Wert zwischen 0 und 5 (für nicht

bzw. sehr stark vorhanden).


Schätzung

157

Technische Korrekturfaktoren Übersetzung und Erläuterung


Schätzung

Faktor

Originalname

Erläuterung

F1

Reliable back-up & recov.

Anforderungen an die DatenintegritätF2

Data communications

Datenaustausch mit UmsystemenF3

Distributed functions

Applikationen auf mehr als einem RechnerF4

Performance

Leistungsanforderungen

F5

Heavily used config.

Starke KonfigurationsabhängigkeitenF6

Online data entry

Interaktive BenutzungF7

Operational ease

InteraktionsqualitätF8

Online update

unmittelbare Aktualisierung (WYSIWYG)

F9

Complex interface

komplexe BenutzerschnittstelleF10

Complex processing

algorithmisch komplexe VerarbeitungF11

Reusability

geplante Wiederverwendung/WartungF12

Installation ease

Installationskomfort

F13

Multiple sites

mehrere (unterschiedliche) InstallationenF14

Facilitate change

Unterstützung der Anpassung in der Wartung

158

Berechnung am Beispiel „Ausleihmaske“


Schätzung

Lesernummer

Name

Vorname

Geburtsdatum

Stammdaten

OK Neu

Kontodaten

Titel Signatur Frist

Stammdaten Kontodaten Bestand

AusleihsystemMögliche Interaktionen:1) Ausweis scannen2) Konto-

und Stammdaten

abfragen durch Eingabe der Lesernummer 3) Stammdaten eingeben


Schätzung


1.) Elemente zählen

(1)

(2)

(3)

Eingaben

1x einfach -

1x mittel

Ausgaben

-

1x mittel -Abfragen

-

-

-

Referenzdaten

1x einfachDatenbestände

3x einfach


Schätzung


2.) UFP berechnen

(1)

(2)

(3)

Eingaben

1x 3

-

1x 4Ausgaben

-

1x 5 -

Abfragen

-

-

-

Referenzdaten

1x 5Datenbestände

3x 7

UFP = 3 + 4 +5 + 5 +21 = 38

161



Schätzung

3.) Technische Faktoren schätzen2 F1

Reliable back-up & recovery1 F2

Data communications2 F3

Distributed functions1 F4

Performance0 F5

Heavily used configuration3 F6

Online data entry5 F7

Operational ease3 F8

Online update2 F9

Complex interface0 F10

Complex processing1 F11

Reusability1 F12

Installation ease4 F13

Multiple sites1 F14

Facilitate change

Technische Komplexität TK = 0,65+0,01 Σi=1..14 Fi

hier alsoTK

= 0,65 + 0,01 * 26= 0,91

FP = TK * UFP Also im Beispiel

FP = 0,91 * 38 = 34,58

Falls in einer Firma 1 FP 2,1 PT entspricht, erhält man ca. 72 PT;

d.h. bei 18 PT pro Monat (220 PT pro Jahr) einen Entwicklungsaufwand von etwa 4 PM

162

Ist das Produktivitätsparadoxon behoben?


Schätzung

Sprache

LoC / FP

Komplexität

niedrig

mittel

hoch

Assembler 200

320

450

C

60

128

170Fortran

75

107

160

Cobol

65

107

150C++

30 53 125

Smalltalk

15 21 40

LoC / Mannmonat relativ konstant.

=> In einer höheren Programmiersprache schafft ein Programmierer mehr Funktionalität pro Zeiteinheit.

=> Es gibt Produktivitätsunter- schiede zwischen

Programmiersprachen.

Damit ist ein Teil des Produktivitätsparadoxons behoben, aber es gibt noch andere Einflussgrößen: Das Verhältnis LoC/FP hängt z.B. auch von der System-komplexität insgesamt ab. Aber FPs sind schon deutlich besser als LoC.

Erfahrungswert: Die Erstellung eines Function Points kostet etwa

1.500 €.

163

Schätzverfahren: CoCoMo (Constructive Cost Modeling)

Entwickler: Barry Boehm1981 CoCoMo I, ab 1995 CoCoMo II

Idee:Schätzung der Projektgröße Size in LOC (Lines of Code) bzw. KDSI (Kilo Delivered Software Instructions), d. h. ohne Kommentare.Gleichungen:

Aufwand: PMDEV

= a * Sizeb

* mLaufzeit: TDEV = 2,5 * PMDEV

d

PMDEV Entwicklungsaufwand in PM und TDEV Projektlaufzeita, b, d, m unternehmensspezifisch zu kalibrierende Faktorenb beschreibt überproportionale Auswirkung großer Projekte m dient zur Berücksichtigung von Korrekturfaktoren für Produkt, Vorgehen und die Qualität von Entwicklern


Schätzung

Barry Boehm*1935PhD UCLA,Prof. USC,Erfinder vonV-

und

Spiralmodell,CoCoMo

164

CoCoMo I

Differenzierung in Projekt-KlassenEinfach (Organic Mode)

einfache Anwendungssoftware, Größe <50 KDSIeingespieltes Team, bekannte Umgebung, wenig NeulandPMDEV = 2,4 * (KDSI) 1,05 * mTDEV = 2,5 * PMDEV

0,32

Mittelschwer (Semi-detached Mode)mittelschwere Projekte, Größe typischerweise <300 KDSIPMDEV = 3,0 * (KDSI) 1,12 * mTDEV = 2,5 * PMDEV

0,35

Eingebettete Systeme (Embedded Mode)schwierige Projekte, beliebige Größestarker Kosten-, Termindruck, viel NeulandPMDEV = 3,6 * (KDSI) 1,2 * mTDEV = 2,5 * PMDEV

0,38


Schätzung


Schätzung

COCOMO: Größe vs. Aufwand

166

Einflussfaktoren, Kostentreiber

ProduktRELY: geforderte Zuverlässigkeit der SoftwareDATA: Größe der DatenbasisCPLX: Komplexität des Produktes

ComputerTIME: benötigte RechenzeitSTOR: Nutzung verfügbarer SpeicherplatzVIRT: Änderungshäufigkeit der SystembasisTURN: Bearbeitungszyklus

ProjektMODP: Verwendung moderner EntwicklungsmethodenTOOL: Verwendung von ToolsSCED: Anforderungen an die Entwicklungszeit

PersonalACAP: Analysefähigkeit der ProjektmitarbeiterAEXP: Erfahrung der Mitarbeiter im ArbeitsgebietPCAP: Programmierfähigkeit der MitarbeiterVEXP: Erfahrung der Mitarbeiter in der SystemumgebungLEXP: Erfahrung der Mitarbeiter in der Programmiersprache


Schätzung

Der Korrekturfaktor m dient zur Berücksichtigung unternehmensspezifischer und projektspezifischer Kostenfaktoren (cost drivers):m = m1 * m2 * …

* m15

MMDEV

= a * KDSIb

* m


Schätzung

Kostenfaktoren m

= m1 * m2 * …

* m15

168

CoCoMo II

COCOMO II (Boehm et al. 2000) ist eine Weiterentwicklung von COCOMO zu einem 3-Stufen Modell, das bei Entwicklungsfortschritt immer genauere Schätzungen ermöglicht.

COCOMO II unterscheidet:Frühe Entwicklungsphasen (Early prototyping level)

Schätzung für Projekte mit Prototyperstellung und hoher Wiederverwendungbasierend auf Anwendungspunkten (application points) und einfacher Formel für die Aufwandsschätzung

Frühe Entwurfsphase (Early design level)Schätzung nach abgeschlossenen Festlegung der Systemanforderungen und einem ersten Entwurf basierend auf Funktionspunkten, die in LOC übersetzt werden.

Nach-Architektur-Phase (Post-architecture level)Schätzung nach Erstellung der Architektur basierend auf LOC


Schätzung

169

Nach-Architektur-Phase (Post-architecture level)

Wir betrachten hier nur die Post-Architektur-Phase (für eine kurze Beschreibung der anderen Phasen siehe Anhang). Neue universelle Grundgleichungen

Aufwand PM = 2,45 * KSLOCB * MEntwicklungszeit T = 2,66 * PM 0,33 + 0,2·(B - 1,01)

wobeiKSLOC: Kilo Source Lines of CodeWachstumsfaktor B = 1,01 + 0,01 Σ SFi

SFi sind insgesamt fünf Skalierungsfaktoren (scaling factors)M ist das Produkt der insgesamt 17 Kostenfaktoren (effort multipliers)


Schätzung

170

COCOMO II: Skalierungsfaktoren (scaling factors)

Faktor Sehrgering

Gering Nominal Hoch Sehrhoch

Extrahoch

Erfahrung 4,05 3,24 2,43 1,62 0,81 0Flexibilität 6,07 4,86 3,64 2,43 1,21 0Risikoumgang 4,22 3,38 2,53 1,69 0,84 0Zusammen-

arbeit4,94 3,95 2,97 1,98 0,99 0

Prozessreife 4,54 3,64 2,73 1,82 0,91 0


Schätzung

Erfahrung: Vertrautheit des Entwicklungsteams mit dem ProduktFlexibilität bezüglich der Einhaltung von Anforderungen / VorgabenRisiko-Umgang: Qualität des RisikomanagementsGüte der Zusammenarbeit zwischen allen ProjektbeteiligtenReife des Entwicklungsprozesses

171

Beispiel

Eine Firma will ein Projekt in einem neuen Gebiet durchführen. Der Kunde hat keinen speziellen Entwicklungsprozess gefordert und keine Zeit für die Risikoanalyse eingeplant. Die Firma besitzt eine Prozessreife der Stufe 1 (nach CMM – siehe später).

Skalierungsfaktoren:Erfahrung: neues Projekt S. gering (4,05)Prozessflexibilität Kunde lässt Freiheit S. hoch (1,21)Architecture/risk resolution Keine Risikoanalyse S. gering (4,22)Teamzusammenhalt Neues Team Nominal (2,97)Prozessreife CMM Level 1 Gering (3,64)Summe 16,19

Der Wachstumsfaktor ist also 1,01 + 0,16 = 1.17


Schätzung

172

COCOMO II: Kostenfaktoren (effort multipliers)


Schätzung

173

Beispiel: 2,45 * KSLOC1.17 * M


Schätzung

SLOC

174

Schätzverfahren in der Praxis

Oft sind Schätzungen gefragt, noch bevor man auch nur halbwegs den Projektinhalt versteht

und dennoch werden die Schätzergebnisse anschließend verbindlichViele Firmen sammeln Aufwandsdaten nicht

Dann hat man sie nur in den Köpfen der Entwickler/ProjektleiterDas ist sehr ungenau!

Oft wird das Ergebnis der Schätzung nicht akzeptiertsondern es gibt politischen Druck, die Schätzung zu verringern,aber die künstlich verminderte Schätzung wird trotzdem zur verbindlichen Vorgabe an das Projektteam.Dramatischste Ausprägung: "Todesmarsch-Projekte„

Schätzung liegt 50% oder mehr unterhalb "vernünftiger" Werte


Schätzung

175

Zusammenfassung (1)

Ziel des Schätzens ist die Bestimmung des Entwicklungsaufwands abhängig von Systemkomplexität und Produktivität und zwar möglichst vor SystemrealisierungTypische Maße zur Systemkomplexität sind Lines-Of-Code (LoC) und Non-Comment-Source-Statements. Weitere Komplexitätsmaße sind Zyklomatische Zahl, Kopplung/Kohäsion, Vererbungstiefe.Schätzungen werden fast immer aus einer Kombinationen der grundlegenden Schätzmuster hergeleitet

Schätzen durch VergleichSchätzen durch Zerlegung (Anforderungen oder Entwurf)ExpertenschätzungSchätzen mit KorrekturfaktorenSchätzen mit Stellvertretergröße


Schätzung

176

Zusammenfassung (2)

Wichtige Schätzverfahren sind das Delphi-Verfahren, Function Points und CoCoMo

Das Delphi-Schätzverfahren ist eine Expertenschätzung, bei der Experten aus Erfahrung Voraussagen über den Zeit/Ressourcen-Bedarf einzelner Projektaktivitäten machen.Mit Function Points schätzt man den Arbeitsaufwand in Personenstunden anhand der vom Kunden gewünschten Funktionen; dieses Verfahren ist bei einfachen (Informations-) Systemen gut anwendbar.CoCoMo dient zur Schätzung der Projektgröße Size in LOC (Lines of Code) bzw. KDSI (Kilo Delivered Software Instructions),

CoCoMo I beruht auf der Schätzgleichung PMDEV

= a * Sizeb

* mCOCOMO II ist ein 3-Stufen Modell, das bei Entwicklungsfortschritt immer genauere Schätzungen ermöglicht


Schätzung

Projektmanagement: Planung

178

Ziele

Kennenlernen der wichtigsten Planungstätigkeiten und Arten von ProjektplänenLernen Netzpläne und Balkendiagramme zu erstellenLernen Grundzüge der Risikoplanung zu verstehenAufgaben der Personalplanung kennenlernen

©


179

Warum denn überhaupt planen?

Auch ein „falscher“ Plan ist besser als kein PlanAlternative: totaler BlindflugEin Plan zeigt einen Weg, wie man das Ziel erreichen kann. Er weist die Machbarkeit nach.Ein Plan ist die Grundlage, um ein Projekt zu steuern

Ohne Steuerung und Plan erkennt man erst zu Projektende, ob sich der Projekterfolg einstellt.Mit Steuerung: Gefährdungen sind früh erkennbar, man kann darauf reagieren

Ein Plan wird im Projektverlauf ständig besser und erhöht die Sicherheit, das Projekt zum Erfolg zu führen.

©


180180

Wirkung des Planungsaufwands

181

4 Schätzverfahren und Projektplanung 4.2 Projektplanung

Planungstechniken Ziele:

Überblick über den ProjektablaufVorbereitung der ProjektdurchführungZeitschätzung und TerminbestimmungPlanung der Vergabe von Ressourcen

Resultate dienen als:Entscheidungs-, Steuerungs- und Kontrollunterlagen;Inhalte:

Definition Aufgabe: Was ist zu tun?Definition Vorgaben/Hilfsmittel: Wie ist es zu tun?Definition Termine: (Bis) Wann ist es zu tun?Definition Verantwortung: Wer hat es zu tun?

181

182

Planung ist ein Prozess

Zitat aus der Praxis: „Damals haben wir mit viel Aufwand den Plan gemacht und nach zwei Wochen hat er schon nicht mehr gestimmt.“Eine Planung wird zu Projektbeginn erstellt und dann ständig verfeinert und angepasst.Eine Planung veraltet, sobald sie fertig ist. (Und manchmal auch schon, während sie erstellt wird)Eine Planung ist keine Vorhersage. Ein Projekt kann man nicht ausrechnen.Die Planung ist ein Werkzeug. Sie ist das wichtigste Arbeitswerkzeug des Projektleiters

©


183

Planung im Projektverlauf

©


184

„Designregeln“

für eine gute Planung

Teile und herrsche –Eine Planung hat eine Top-Down-Zerteilung.In ihr finden sich Stufen und Phasen des SE-Prozesses wieder. Sie sind durch Meilensteine getrennt.Geringe Abhängigkeiten –Bilde Arbeitspakete so, dass deren Abhängigkeiten voneinander gering sind.Wenig Nebenläufigkeit –Vermeide gleichzeitiges Arbeiten einer Person an verschiedenen Aufgaben.Klare Aufgaben –Die Ergebnisse der geplanten Aufgaben müssen klar sein, es muss klar sein, was das Erreichungskriterium ist.Wichtiges und Lücken zuerst –Fokussiere in der Planung zunächst auf die wichtigen und dann auf die unbekannten Aufgaben.

©


185

Ein guter Plan hat eine „Story“und muss „erzählt“werden

Wie jedes gut verstandene Konzept lässt sich auch ein Projektplan in wenigen Sätzen zusammenfassen. Wenn man das nicht kann, ist die Planung noch nicht klar genug.

„Erst machen wir A, dann B, dann C“. Ein zweites Team kümmert sich um D.„Meier bearbeitet Thema 1 und lernt dabei Schulze an. Dann übernimmt Schulze Thema 2 und Meier lernt Müller in Thema 3 an.“

Die Planung muss ständig kommuniziert werdenDie Planung gibt es im Detail und in der Übersicht

Detail z. B.: Excel, MS ProjectÜbersicht z. B.: PowerPoint

Die Planung kommunizierenIn den Teamräumen aushängenBei jedem Teammeeting wiederholenProjektstatus im Rahmen der Planung darstellen

©


186

Das Team muss hinter der Planung stehen

Einzelne Planinhalte mit den vorgesehenen Bearbeitern durchsprechen.Die Teammitglieder müssen die Planung als realistisch und machbar ansehen –das heißt nicht, dass sie bequem sein muss.

Bei Feedback: „Das schaffen wir nie“Kritik aus dem Team ernst nehmen!Nicht aus der Position des Projektleiters „überstimmen“Commitment zur Planung erzielen: Planung ändern oder Bedenken ausräumen.

Eine Planung, an die alle Teammitglieder glauben, gibt Sicherheit

©


187

Beispiel

ProjektkontextEin mittleres Softwareprojekt soll durchgeführt werden.Der Aufwand wurde vorab geschätzt.Es gibt im Jahr nur zwei Termine (Januar und Juli), zu dem das System eingeführt werden kann.Das zu erstellende System löst ein bestehendes System ab, eine Datenmigration ist notwendig.

FragestellungIst eine Einführung im Januar 2009 oder erst im Juli 2009 möglich?

©


188

Grobplanung

Ausgehend von der Aufwandsdimensionierung von 9 -10 PJ kann man nach dem Schlüssel (30-15-40-15) eine ungefähre Verteilung auf die Projektphasen vornehmen

fachliche Konzeption (30%) ca. 35 PMtechnische Konzeption (15%) ca. 15 PMImplementierung (40%) ca. 45 PMIntegration & Test (15%) ca. 15 PM

Bei einem Einführungstermin zum Juli 2009 und Beginn Oktober 2007: Teamstärke von 5 –6 Personen.

Einschätzung: bequem machbarBei einem frühesten Einführungstermin zum Januar 2009, Beginn Oktober 2007: Teamstärke von im Schnitt ca. 9 Personen, Teamstärke im Projektverlauf ca. zwischen 5 und 14 Personen.

Einschätzung: sportlicher Terminplan, aber noch machbar

©


189

Projektplan

Funktion: 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 fertiggestelltKurzfristigkeit: kurze Zeitdauer zwischen MeilensteinenGleichverteilung: kontinuierliche und gleiche Verteilung

Abhängigkeiten zwischen Meilensteinen und Vorgängen:fachlicheterminliche Integration in Netzplänenpersonelle

Elemente (Planung):ProjektstrukturplanTerminplanPersonalplanRessourcenplan

Zusätzlich: Ist-Werte Projekt189

190190

Projektplan

Funktion: 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 fertiggestelltKurzfristigkeit: kurze Zeitdauer zwischen MeilensteinenGleichverteilung: kontinuierliche und gleiche Verteilung

Abhängigkeiten zwischen Meilensteinen und Vorgängen:fachlicheterminliche Integration in Netzplänenpersonelle

Elemente (Planung):ProjektstrukturplanTerminplanPersonalplanRessourcenplan

Zusätzlich: Ist-Werte Projekt

191191

Projektstrukturplan

Projektstrukturplan oder Work Breakdown StructureZiel:

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

192192

Projektstrukturplan

Projektstrukturplan

193

Typen von Projektstrukturplan

Objektorientierter ProjektstrukturplanDefinition 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)

193

194194

Projektstrukturplan

ProjektprozessauswahlAuswahl 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)

195

Meilensteine

Ziel: Ermöglichen die ProjektkontrolleGezieltes 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 liegtNicht: „Implementierung zu 80% abgeschlossen“

195

196196

Meilensteine

Achtung: 90%-Syndrom!

197

Projektablaufplan

Ein Projektablaufplan dient zur Darstellung des zeitlichen Verlaufs und der Abhängigkeiten von Projektaufgaben und –Ergebnissen:Abhängigkeiten

zwingende Folgeempfehlende Folgefreie Folge

Verschiedene Ablaufplänen mit unterschiedlichem InformationsgehaltLinearpläne Netzpläne

197

198198

Projektablaufplan

DarstellungstechnikenListungstechnik

nur bei kleinen (Linear-)Plänen sinnvoll einsetzbarTerminlisten:

Workpackages (Vorgangslisten), von außen vorgegebene TermineNetzplantechnik,

zusätzlich technologische Abhängigkeitenz. B.

Vorgangspfeilnetzplan (CPM)VorgangsknotennetzplanEreignisknotennetzplan

Balkendiagrammtechnikzusätzlich je Teilaufgabe Start- und Endtermin bzw. Dauerz. B.

Gantt-DiagrammPLANNET-Diagramm

Vernetzte Balkenplänezusätzlich einfache Abhängigkeiten zwischen Vorgängen

199199

Terminlisten

Enthält Liste der Aktivitäten

bzw. VorgängeZu jedem Vorgang wird die Liste der beteiligten oder verantwortlichen Personen angegebenWeiter 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)

200200

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.

201201

Netzplantechnik

NetzplantechnikenNetzplantechnik ist geeignet für:- Strukturplanung- Zeitplanung- Einsatzmittelplanung- Kostenplanungbewährte Arten von Netzplänen:- CPM: Critical Path Method- PERT: Program Evaluation and Review Technic- MPM: Metra-Potential-Methodzahlreiche Softwareprodukte unterstützen den Einsatz der Netzplantechnik; oft: Zusammenfassung verschiedener Arten von Netzplänen; daher: Vorsicht auf Konsistenz!

202202

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

203203

Netzplantechnik –

CPM

Beispiel:Tätigkeiten mit Zeitangaben und Vorgängerrelationen

204204

Netzplantechnik

NetzplantechnikenNetzplanvarianten:

Vorgangsknotennetzplan (z.B. MPM)-

Knoten (meist Rechtecke) sind Vorgänge (Ereignisse)-

Kanten sind benötigte Ressourcen/Produkte (Abhängigkeiten, Beziehungen)

Vorgangskantennetzplan (z.B. CPM), auch Vorgangspfeildarstellung-

Knoten (meist Kreise) sind Ereignisse-

Kanten/Pfeile sind Vorgänge -

Schwerpunkt: Vorgang ( = Tätigkeit) mit Dauer

Ereignisknotennetzplan (z.B. PERT)-

Knoten (meist Kreis) sind Ereignisse-

Kanten/Pfeile sind Abhängigkeiten, Beziehungen -

Schwerpunkt: Ereignis: beschreibt Projektzustand, Zustandsübergang kann mehrere Vorgänge umfassen, die nicht näher beschrieben werden.

205205

Netzplantechnik

Vorgangsknoten Netzpläne -

Activity on Node (AoN)Knoten: enthalten Vorgänge, Vorgangsnummern und DauernKanten: beschreiben die Anordnungsbeziehungen zwischen den Vorgängen

Vier Anordnungsbeziehungen zwischen VorgängenNormalfolge (Ende-Anfang Beziehung)Anfangsfolge (Anfang-Anfang Beziehung)Endfolge (Ende-Ende Beziehung)Sprungfolge (Anfang-Ende Beziehung)

206206

Netzplantechnik

Vorgangsknotennetzplan -

Beispiel

207207

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 }

208208

Netzplantechnik -


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

209209

Netzplantechnik -


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)

210210

Netzplantechnik -


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)

211211

Netzplantechnik -


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ätenBerechnung 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ätenBerechnung 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

212212

Netzplantechnik -


VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen

213213

Netzplantechnik -


214214

Netzplantechnik -


VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen

215215

Netzplantechnik -


216216

Netzplantechnik

Netzplantechnik umfasst folgende Schritte:Erstellen der Tätigkeitsliste aufgrund des ProjektstrukturplansErstellen des NetzplansBerechnen der VorgangszeitpunkteErmitteln der PufferzeitenErrechnen des kritischen WegesVerwendung des Netzplans als Basis von

Balkendiagrammen, z.B. Belegungsplan, EinsatzplanEinsatzmittel-Auslastungsdiagrammen, z.B. zwecks Bedarfsglättung

217217

Netzplantechnik –

CPM

CPM: Vorgangskantennetzplan

/ VorgangspfeilplanKnoten:

symbolisiert ein Ereignis, welches einen Zustand beschreibt; z.B.: Programm erstellt, Start für den Test;Darstellung: als Kreis oder Rechteck

Ereignisknoten enthält folgende Bestimmungsstücke:

Ereignisnummer

Zeitwert der Vorwärtsrechnung

Zeitwert der Rückwärtsrechnung

2

12 18

218218

Netzplantechnik –

CPM

CPM: Vorgangskantennetzplanoft werden Ereignisknoten auch folgendermaßen dargestellt

219219

Netzplantechnik –

CPM

CPM: Vorgangskantennetzplangerichtete Kante:

symbolisiert Vorgang oder Tätigkeit innerhalb eines Projektes; kein Zusammenhang zwischen der Länge des Pfeils und der Dauer des Vorgangs

Vorgangsbeschreibung: verbal oder Indexeintrag oberhalb des Pfeils; Vorgangsdauer: num. Eintrag unter dem Pfeil

220220

Netzplantechnik –

CPM

Regel 1:Ein Vorgang kann erst beginnen, wenn alle vorangehenden Vorgänge abgeschlossen sind. Dabei fällt, mit Ausnahme des ersten Vorgangs, das Anfangsereignis mit dem Endereignis des vorangehenden Vorgangs zusammen.

221221

Netzplantechnik –

CPM

Regel 2:Müssen mehrere Vorgänge beendet sein, bevor ein weiterer Vorgang beginnen kann, so enden sie im Anfangsereignis des nachfolgenden Vorgangs.

Regel 3:Können mehrere Vorgänge beginnen, nachdem ein vorangehender Vorgang beendet ist, so beginnen sie im Endereignis des vorangehenden Vorgangs.

222222

Netzplantechnik –

CPM

Regel 4: Haben zwei oder mehr Vorgänge gemeinsame Anfangs- und Endereignisse, so ist ihre eindeutige Kennzeichnung durch Einfügen von Scheinvorgängen zu gewährleisten.

223223

Netzplantechnik –

CPM

Regel 5: Beginnen und enden in einem Ereignis mehrere Vorgänge, die nicht alle voneinander abhängig sind, so ist der richtige Ablauf durch Auflösung der Unabhängigkeiten mittels Scheinvorgängen darzustellen.

Regel 6:Innerhalb einer Folge von Vorgängen können beliebig viele Scheinvorgänge eingefügt werden. Sie dienen neben der logischen Verknüpfung auch der besseren Übersicht.

224224

Netzplantechnik –

CPM

Regel 7: Kann ein Vorgang beginnen, bevor der vorangehende vollständig beendet ist, so ist der vorangehende weiter zu unterteilen, damit ein "Zwischen-Ereignis" definiert werden kann.

Regel 8:Jeder Vorgang kann nur einmal ablaufen. Daher dürfen im CPM-Netzplan keine Schleifen auftreten.

225225

Netzplantechnik –

CPM

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

226226

Netzplantechnik –

CPM

Beispiel: CPM Netzwerk -

Numerierung der Knoten

227227

Netzplantechnik –

CPM


Bestimmung der frühesten Beginnzeiten

228228

Netzplantechnik –

CPM


Bestimmung der spätesten Beginnzeiten

229229

Netzplantechnik –

CPM


Bestimmung des kritischen Pfades

230230

Netzplantechnik –

CPM

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

Errechnen der Zeitwerte und Bestimmung des kritischen Weges:Zeitwert der Vorwärtsrechnung: Beginn bei 0;dann: addieren der Zeiteinheiten nach der logischen Reihenfolge undEintrag in das linke untere Feld des Ereigniskreises;Bedeutung: Bestimmung der frühesten Ereigniszeitpunkte;

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

Bestimmung der spätesten Ereigniszeitpunkte durch Subtraktion der Zeitwerte;Eintrag in den rechten unteren Teil des Ereignisknotens;

Der kritische Weg umfasst alle Ereignisse, deren früheste und späteste Ereigniszeitpunkte gleich sind

Bedeutung: der kritische Weg enthält alle Tätigkeiten, die keine Pufferzeiten erlauben, d.h. zwischen dem geplanten Ende einer Tätigkeit und dem Start der Folgetätigkeit gibt es keine zeitliche Verschiebungsmöglichkeit, wenn das Ende des gesamten Vorhabens unbeeinflußt bleiben soll.

231231

Netzplantechnik –

CPM

Beispiel eines Netzplans mit einem kritischen Weg:

232232

Netzplantechnik –

CPM

Berechnen der Vorgangszeitpunkte (“Tätigkeitszeitpunkte”):frühester Anfangszeitpunkt des Ereignisses: FAspätester Endzeitpunkt eines Vorganges: SEfrühester Endzeitpunkt eines Ereignisses: FEspätester Anfangszeitpunkt eines Vorganges: SA

Zweck: Berechnung der Pufferzeiten und Erstellen des Einsatz-Auslastungsdiagramms, z.B. zwecks Bedarfsglättung

233233

Netzplantechnik –

CPM

234234

Netzplantechnik –

CPM

Aufgrund der Vorwärts- und Rückwärtsrechnung sind bekannt: FA (FZ) und SE (SZ)

FE(V1) = FA(V1) + D(V1) SA(V1) = SE(V1) - D(V1)

Pufferzeiten:Gesamte Pufferzeit (GP): GP = SE(j) - FA(i) - Doder GP = SZ(j) - FZ(i) - DBedeutung: GP gibt an, wie lange ein Vorgang höchstens verlängert/verzögert werden kann, ohne daß der Endtermin beeinträchtigt wird.

235235

Netzplantechnik –

CPM

Freie Pufferzeit

(FP):FP = FE(j) - FA(i) - Doder FP = FZ(j) - FZ(i) - DFreie Pufferzeit entsteht, wenn mehrere Vorgänge, die nicht alle zeitbestimmend sind, in einem Ereignis münden.Die freie Pufferzeit gibt den Zeitunterschied zwischen der zeitbestimmenden und der auf einem anderen Weg berechneten frühesten Lage eines Ereignisses an.Bedeutung: FP gibt an, wie lange ein Vorgang höchstens ausgedehnt/verzögert werden kann, ohne den Anfangszeitpunkt der Folgevorgänge zu beeinflussen.

236236

Netzplantechnik –

CPM

Unabhängige Pufferzeit (UP):UP = FE(j) - SA(i) - DBedeutung:UP gibt die Dauer an, die der Vorgang mit den Folgevorgaben ausgedehnt oder verschoben werden kann:a) das Startereignis muß zum spätesterlaubten Zeitpunkt beginnen undb) der Vorgang muß den frühestmöglichen Endzeitpunkt einhalten können.weitere Kenngröße:Schlupf im Zustand i: SL(i) = SZ(i) - FZ(i)

237237

Netzplantechnik –

CPM

Übersicht zu Pufferzeiten und Schlupf

238238

Netzplantechnik

ZusammenfassungNetzplantechnik

Eingabe:-

Projektstrukturplan-

Terminvorgaben-

Aufwandsschätzung (Zeitaufwände)

Ergebnis:-

Meilensteinplan-

Terminplan

Einschränkende AnnahmenAnnahme: Vorgangsdauer genau abschätzbarAnnahme: Ressourcen frei planbar

Konsequenz: Termin- und Ressourcenplanung verschränkt durchführen

239239

Balkendiagramm

Balkendiagramm (GANTT-Diagramm)Entwickelt von Henry L. Gantt, 1861–1919Graphische 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

240240

Balkendiagramm

Balkendiagramm (GANTT-Diagramm)Balkendiagramme:

vielseitige Verwendung;horizontale Achse: Zeitvertikale Achse: z.B.

-

Sachmittel: “Belegungsplan”-

Aufgaben: “Tätigkeitsplan”, “Projektfortschrittsplan”-

Aufgabenträger: “Einsatzplan”

Erweiterungen:Balken können mit Wert beschriftet werden

z.B. Mitarbeiternameje ein Balken für Soll- und Ist-Wert zwecks Vergleich

241241

Balkendiagramm

Balkendiagramm

Arbeitsschritte Meilensteine Jahr

Quartal 2 3 4 1 2 3 4 1 2 3 Insges. MID (Dipl.Ing

AP 1 Entwicklung Vorgehensmodell „BP2WS-Prozess“ 41,4 12,3 AP 1.1 Stand der Technik 0,7 2,1 0 AP 1.2 Vorgehensmodell „BP2WS“ 1,4 1,1 1,3 1,3 0,9 0,9 0,6 22,5 5 MS 1.1 BP2WS V1 MS 1.2 BP2WS V2 AP 1.3 Dokumentation 0,7 0,6 1 1,3 10,8 3 AP 1.4 UML Profile 0,5 0,5 0,3 0,7 6 2AP 2 Modelltransformation und Codegenerierung 43,8 10,8 AP 2.1 Stand der Technik 0,7 2,1 0 AP 2.2 Transformationssprache 0,9 0,8 0,8 0,8 0,4 11,1 MS 2.1 Transformationssprache V1 MS 2.2 Transformationssprache V2 AP 2.3 Regeln 1 1,1 2,2 1,5 1,3 1,4 1,1 0,6 30,6 7 MS 2.3 RegelbibliothekAP 3 Prototyp 48,3 42,6 AP 3.1 Anforderungen 0,5 0,3 2,4 1 AP 3.2 Modellierung 0,5 1,2 0,2 0,3 0,2 0,1 0,1 7,8 5 MS 3.1 Modellierung in Innovator AP 3.3 Tranformationen / Codegenerierung 3,1 3,5 3,1 2 1 38,1 3 MS 3.2 Transformations / Codegen. In InnovatorAP 4 Fallstudie 59,1 9,3 AP 4.1 Anforderungen Fallstudie 1,5 1,6 9,3 1 AP 4.2 Anforderungen an BP2WS 0,9 0,4 3,9 1 AP 4.3 Fallstudie 1 und Evaluation 3,6 2,4 18 2 MS 4.1 Fallstudie 1 und Eval AP 4.4 Fallstudie 2 und Evaluation 3,3 3,3 2,7 27,9 4 MS 4.2 Fallstudie 2 und EvalAP 5 Projektmanagement 0,8 0,2 0,3 0,35 0,25 0,1 0,3 0,25 0,25 0,8 10,8 2,1

Summen 4,6 6 4,8 4,95 5,05 8,6 7,8 10,25 8,65 7,1 203,4 77,1

Durchschnittliche Zahl von Personen pro Monat über Projektlaufzeit: 6,78

2006 2007

Einteilung nach Vergütungsg

bei Wirtschafts-Unternehmeo.ä.

Gesamtpersonalplan Alle Projektpartner kumuliert Zeitplan - Angaben als 'Personen pro Monat'

Balkendiagramm Meilensteine

PersonaleinsatQuartale berücksich0,2*3=0,6

2005

242242

Balkendiagramm

Vernetzte BalkenpläneIn das Balkendiagramm werden zusätzlich Informationen über einfache Abhängigkeiten zwischen den einzelnen Vorgängen eingefügtDarstellung: Pfeile vom Vorgänger-Balken zum jeweiligen NachfolgerDadurch gute Darstellung der direkten Abhängigkeiten, i.e. welche weiteren Vorgänge werden aufgrund einer Verzögerung ebenfalls verspätet ausgeführt und mit welchen Vorgängen kann im Zeitplan weiter wie geplant vorgegangen werden.Vernetzte Balkenpläne zählen zu den einfachsten und wichtigsten Kommunikationsinstrumenten im Projektmanagement

243243

Balkendiagramm

Balkendiagramm

244244

Balkendiagramm

17 19 21 23 25 27 29 313rd Quarter 1st Quarter 3rd Quart

Phase 1 Phase 2

ID ID Task Name1 WP1 WP1 Project Management & Coordination

2 T1.1 Selection of tools

3 T1.2 Management of CVS-server, Web-site, …

4 T1.3 Project Co-ordination

5 T1.4 Co-ordination with standards

6 D11 Selection of Tools

7 D12 Inter-working with other projects

8 D13 Impact on Standards

9 D14 Impact on Standards

10 D15 Project summary and exploitation plan

11 D16 Annual Report Review 2000

12 D17 Annual Report Review 2001

13 WP2 WP2 Field Trials

14 T2.1 Requirements of Field Trials

15 T2.2 Specifications of Field Trials

16 T2.3 Preparation of Field Trials

17 T2.4 Carry out Field Trials

18 T2.5 Evaluation of Field Trials

19 D21 Requirements of Field Trials

20 D22 Specifications of Field Trials

21 D23 Evaluation of Field Trials

22 WP3 WP3 Light. Ext. Agent Platform

23 T3.1 Set-up of the environment

24 T3.2 System Design, Architecture, API

25 T3.3 Implementation

26 T3.4 Integration

27 T3.5 Maintenance

28 D31 Specification of the LEAP Architecture

29 D32 Specification of LEAP API + profile

30 D33 LEAP Version 1.0

31 D34 LEAP Version 2.0

32 WP4 WP4 Agent Services & Applications

33 T4.1 Design

34 T4.2 Implementation

35 T4.2 Integration

36 T4.4 Maintenance

37 D41 Agent Services Design

38 D42 Lab Trial

39 D43 LEAP Application Implementations

40

31/03

31/03

31/03

30/05

30/06

31/12

31/12

30/04

30/08

30/06

31/05

31/07

31/12

30/08

30/08

31/12

28/09

-2 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 311st Quarter 3rd Quarter 1st Quarter 3rd Quarter 1st Quarter 3rd Quart

245245

Arbeitspaketbeschreibung

PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining

1)

Beschreibung des Arbeitspaketes

Vorbereitung, Durchführung und Nachbereitung von zwei je zweitägigen Trainings für Vertriebsmitarbeiter und ausgewählte Mitarbeiter über die neue Technologie und Funktionalität des Mobile-Odors-Telefons. Ergänzende Informationen:

Intensivtraining mit max. 4 TeilnehmernÜberwiegend folienbasiertes Training inkl. Übungen (ca. 80 Folien pro Tag)Es gibt bereits Unterlagen einer älteren Schulung, die für das Training benutzt/angepasst werden dürfen.Teilnehmerunterlagen werden durch Druckerei erstellt & geliefert. →Vorher Übergabe elektronisch in pdf-

Format.Nachbereitung: Teilnehmerzertifikate und im Kurs erarbeitete Unterlagen (elektronische Bilder via E-Mail)

2

)

Durchführende Personen oder Rollen

Chefdesigner

3

)

Notwendige Fähigkeiten des/der Durchführungen

Gute technische und funktionale Kenntnisse Mobile Odors, Trainerausbildung

246246



4

)

Dauer und AufwandSchulungsdauer: 2 Tage (à

8 Stunden), Aufwand noch zu bestimmen

5

)

Liefergegenstände

Trainerfolien, Trainingsorganisation, durchgeführte Trainings, Teilnehmerunterlagen

6)

Vorraussetzungen für die Durch-führung

Ausreichend zeitlicher Vorlauf bei der Planung, damit alle Teilnehmer mit den 2 Trainings erreicht werden.

7)

Vorraussetzungen für eine erfolg-reiche Abnahme

Teilnehmer kennen die Technologie und fühlen sich in der Lage, auch mit technisch versierten Kunden ein Vertriebsgespräch zu führen.

8

)

Kennzahlen zur Überprüfung der korrekten Durchführung

keine

247247



4

)

Dauer und AufwandSchulungsdauer: 2 Tage (à

8 Stunden), Aufwand noch zu bestimmen

5

)

Liefergegenstände

Trainerfolien, Trainingsorganisation, durchgeführte Trainings, Teilnehmerunterlagen

6)

Vorraussetzungen für die Durch-führung

Ausreichend zeitlicher Vorlauf bei der Planung, damit alle Teilnehmer mit den 2 Trainings erreicht werden.

7)

Vorraussetzungen für eine erfolg-reiche Abnahme

Teilnehmer kennen die Technologie und fühlen sich in der Lage, auch mit technisch versierten Kunden ein Vertriebsgespräch zu führen.

8

)

Kennzahlen zur Überprüfung der korrekten Durchführung

keine

248248

Personalplanung

PersonalplanungAufgaben der projektbezogenen Personalplanung

Sicherstellung der MitarbeiterverfügbarkeitOptimaler Einsatz der Mitarbeiter

-

Vermeidung von Mitarbeiterüberlastung-

Vermeidung von mangelnder Mitarbeiterauslastung

249249

Personalplanung

Ermittlung PersonalaufwandPrinzipieller Ansatz:

Eingaben: Aufwand Aktivität, Dauer AktivitätAusgabe: Anzahl benötigter MitarbeiterVerfahren:Zusätzlich: Benötigte Qualifikation

Rechenbeispiel: 10 PMDauer 10 KM : 1 MADauer 2 KM : 5 MA

Bemerkungen:Annahme der normierten Leistung (1 MA leitet 1 PM pro Monat)Annahme der unabhängigen Multiplizität von MitarbeiternBerücksichtigung Brutto/Netto-Leistung

250250

Personalplanung

PersonalplanungPrinzipieller Ansatz:

Ermittlung Personalaufwand (Projektstrukturplan, Aufwandsschätzung, Terminplan)Ermittlung PersonalressourcenPersonalzuordnung und Optimierung der Auslastung

Varianten der Zuordnung/Optimierung:Terminorientiert: Aufwände in Abhängigkeit vorgegebener TermineAufwandsorientiert: Termin in Abhängigkeit vorgegebener (Maximal-)AufwändeRealistisch: Mischverfahren

251251

Personalplanung

Optimierung

Varianten der Zuordnung/Optimierung:Terminorientiert:

-

Einhaltung vorgegebener Termine-

Erhöhung der Personalzuordnung

Aufwandsorientiert:-

Einhaltung vorgegebener (Maximal-)Aufwände-

Verschiebung des Termins

252252

Personalplanung

Organisatorische RandbedinungenQualifikation der Mitarbeiter:

Qualifizierte Mitarbeiter einsetzenMitarbeiter qualifizieren (Zeiten/Kosten einplanen)

Zeitliche/räumliche Verfügbarkeit:Zeitlich: Persönliche Planung berücksichtigen (Urlaub/Ausfall)Räumlich: Koordinationsverluste einplanen

Organisatorische Einbettung:Projektstruktur: Mitarbeiter nach Auslastung einplanenMatrixstruktur: Linenvorgesetzten in Planung einbeziehen

Generell: Mitarbeiter rechtzeitig in Planung einbeziehen

253253

Personalplanung

Humane RandbedingungenProduktivitätsvarianzen:

Starke Produktivitätsschwankungen zwischen MitarbeiternSchwache Produktivitätsschwankungen im Team

TeamkohäsionTeamidentifikation mittels gemeinsamer Normen„Never change a winning team“Ausrichtung auf ein gemeinsames Ziel

ProjektidentifikationIdentifikation erhöht ProduktivitätMultiprojekteinsatz reduziert Produktivität

Generell: Humane Faktoren sind primäre Produktivitätstreiber

254254

Personalplanung

Produktivität

Produktivitätsvarianzen:Beste Mitarbeiter um Faktor 10 besser als schlechtesteBeste Mitarbeiter um Faktor 2,5 besser als DurchschnittÜberdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittlicheUnabhängig von Leistungsmetrik:

-

Anzahl der Fehler-

Kalenderzeit bis Meilenstein-

Funktionspunkte pro Zeiteinheit

255255

Personalplanung

RessourcenplanungVerfahren:

Im wesentlichen analog PersonalplanungÄhnliche Probleme

-

Qualifikation: Vorbereitung-

Multiprojekteinsatz: Umrüstung

UnterscheidungNichtverbrauchbare RessourcenVerbrauchbare Ressourcen (eingebettete SW)

Projektmanagement: Controlling und Steuerung

257

Ziele

Massnahmen zum Controlling eines Projekts kennen lernenAspekte der Teamführung diskutieren


Controlling und Steuerung

258

Projektkontrolle (Controlling)

Controlling umfasst Fortschrittskontrolle Budget-/ZeitkontrolleÜberprüfen von Risiken im Rahmen des RisikomanagementMitarbeiterkontrolleÜberprüfen der Qualitätsstands im Rahmen des QualitätsmanagementKonfigurationsmanagement...

Ziele der Fortschrittskontrolle Bestandsaufnahme: 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



260

Zusammenhang zwischen Planung und Steuerung: Das Projekt wird entlang des Plans gesteuert. Abweichungen zwischen Planung und Projektverlauf führen zu Maßnahmen oder Planungsänderungen.

Wichtige Regel für den Projektleiter: Immer eine aktuelle Planung haben! Die Restaufwände kennen!



261

Prinzip des Controlling: Soll-Ist-Vergleich Beispiel: Was sagt diese Kurve aus?



262

Ist-Soll-Vergleich: Meilensteintrendanalyse

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



263

Meilensteintrendanalyse

Ziel: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 VerschiebungenStarke Schwankungen

Späte Neuschätzung: Terminasymptoten



264




Berichtszeitpunkte

Meilenstein-

Termine

IVIIIIII

IVIIIIII

IVIIIIII

IVIIIIII

IVIIIIII

200x

200x

200x

2

00x

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

265




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

266266



Erkennbare Fehler:Unterschätzung M1: Wiederholte Verschiebung (Messfehler)Überschätzung M2: Überhöhte Verschiebung (Planungsfehler)Fehlende Schätzung M3: Späte Verschiebung (Planungsfehler)

267

Wann wird das IST bestimmt?

Controlling so eng vornehmen, wie es der Projektsituation entspricht:Kritischer Zeitplan, hohes Terminrisiko

enges Controlling„Sicheres“ Projekt, erfahrene, selbständige Mitarbeiter

Weites Controlling

Mögliche Zeitpunkte für Bestimmung des Ist:Zu den MeilensteinenWöchentliche (oder mehr wöchentliche) Planungsmeetings, StatusmeetingsIn kritischen Phasen sogar täglich



268

Wie wird das IST bestimmt?

Möglichkeiten:Persönliches Gespräch:

Projektleiter geht herum, spricht mit Mitarbeitern die Aktivitäten durch. Ggf. feste Agenda, auf die sich MA vorbereitet.

Regelmäßige Statusberichte der Mitarbeiter: In Team-Meetings, Per Email

Bei Methode zu bedenken:Erfahrenheit der Mitarbeiter: Erfahrene Mitarbeiter können sich selbst besser einschätzen und wissen besser, welche Punkte wichtig sind.Statusberichte dienen zur Messung des aktuellen Status

Planung: Budgetbericht, Terminbericht, Aufwandsbericht, RisikoberichtQualitätssicherung: FehlerberichtStatusberichte haben einen formalen Rahmen, stellen sicher, dass alle Punkte beleuchtet werden



269

Preisfrage (Abfrage des IST in der Realisierung)

Wann ist ein Stück Software fertig entwickelt?„Wie weit bist du?“

„Fast fertig…“„Ich muss nur noch…“„Fertig, ich muss nur noch einchecken…“



270

Antwort

Erst fertig ist fertig.Erinnerung: ein Arbeitspaket/eine Aktivität hat definierte Ergebnisse und QualitätskriterienInsbesondere bei der Programmierung:

Code ist erst dann fertig, wenn der Entwicklertest erfolgreich stattgefunden hatNIEMALS auf die Antwort „Fast fertig“ einen Fertigstellungsgrad von mehr als 50% annehmen.





Technische Umsetzung des Controlling

Spalte für Restaufwände ab aktueller WocheIm Beispiel hier: bei wöchentlicher Statusabfrage werden Fertigstellungsgrad und Restaufwände ermittelt

272

Controlling der Restaufwände LOP –

Die Liste offener Punkte

Problemstellung:Selbstverständliche Dinge im Projekt geschehen nicht von selbst.Das Durchführen von Maßnahmen müssen überwacht werden.Wichtige Punkte gehen verloren, weil sich aktuell niemand darum kümmern kann.

Idee:Führen einer Liste der Offenen Punkte (LOP)



273

Controlling der Restaufwände LOP-

Umsetzung

Inhalte der LOPName des PunktsBeschreibungWer hat ihn eingestellt (wg. Nachfragen)?Wer kümmert sich um die Klärung?Bis wann?Statusbei großen Listen ggf.:

PrioriätOrdnungskriterium, z. B. Projektphase („Fachkonzept“ „Technisches Konzept“, etc.)

Umsetzung mit Tabellenkalkulation



274

Controlling der Restaufwände Vorgehen LOP

Verantwortlichen für die LOP benennen, Aufgaben:AktualisierungÜbersicht behaltenNachhalten von Terminen

Befüllen der LOPi. d. R.: jeder darf eintragen und sammeln.

Regelmäßig (z. B. zu den wöchentlichen Team-Meetings)Vorbereitung: Punkte durchgehen und bewertenIm Meeting Status erheben, Aufgaben verteilen



275

Typische Inhalte eines Statusreports

Ist-Zustand und aktuelle PlanungWo laufen Ist und Soll auseinander? Welche Maßnahmen wurden ergriffen?Sind Meilensteine gefährdet?

Aktuelle Risikoliste des ProjektsWelche Projektrisiken bestehen, welche Maßnahmen wurden ergriffen?

Nächste Schritte, Vorgehen bis zum nächsten TerminEntscheidungsbedarfReduktion auf Status-Ampel

grün: alles okgelb: Projekterfolg wahrscheinlich gefährdetrot: Projekterfolg gefährdet, Handlungsbedarf



276

Controlling entlang der Projekthierarchie



277

Statusreports auf höheren Organisationsebenen

Typische ReportingzyklenTeam an (Teil-)Projektleiter: wöchentlichTeilprojektleiter an Gesamtprojektleiter: wöchentlich bis 2-wöchentlich.Gesamtprojektleiter an Lenkungsgremium: 1 x im Monat oder seltener.

Bei Projektleitungsmeetings: StatusreportsNutzen entsteht bereits dadurch, dass der Berichtende sich selbst über den Status seines Teams bewusst werden muss.



278

Exkurs: Meetings



279

Die Einladungsmail

From: [email protected]: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]

Subject: Einladung

Hallo Kollegen,am 12.01.2007 findet um 14:15 in Raum 1.31 das Meeting

zum Thema „Integration von Web Services“

statt.

Mit freundlichen GrüßenMichael



280

Professionelle Meetings

Ziel festlegen – und aufschreiben!Verantwortlichen festlegenVerantwortlicher verschickt Einladung

Termin, Ort, ZeitrahmenTeilnehmer – Wer muss denn wirklich dabei sein?ZielAgenda

Wer moderiert, wer führt Protokoll?Technik vorher organisieren: Beamer, Flipchart, Getränke, …



281

Spielregeln für Meetings

Handy aus!Protokoll führen, wenn das Meeting wichtig ist.Die anderen ausreden lassen.Sich selbst kurz fassen.Für sich selbst reden.Zur Sache reden, nicht zur Person.Bei Telefonkonferenzen: Unbedingt ausführlich vorbereiten, straff moderieren.

[sd&m AG]



282

Das Protokoll

Protokoll vom 12.01.2007Anwesend: Hr. Meier, Fr. Müller, Hr. Schulze, Fr. SchmidtTOP* 1: WebServices

Herr Müller stellt das Konzept zur Integration von WebServices vor.Es muss geprüft werden, ob das auch mit MQ Series zusammen funktioniert.Das XML-Schema muss angepasst werden. => Müller/SchulzeHr. Schmidt klärt, ob die Services auch unter Windows genutzt werden sollen.

TOP 2: SecurityHerr Müller stellt das Security-Konzept vor.

Anlagen:Präsentation WebServicesPräsentation Security

*TOP = Tagesordnungspunkt



283

Was gehört ins Protokoll?

DatumTeilnehmerVerteiler (nicht teilgenommen, aber offiziell informiert)Vorgehen

Gleich nach dem Meeting aufschreiben, an Verteiler verschicken,ggf. Feedback einarbeiten.

TagesordnungspunkteInformation, Feststellung, Beschluss, AufgabeAufgaben immer mit Termin und einem Verantwortlichen



284

Protokoll Lenkungskreis Projekt XY

Protokoll vom 12.01.2007Anwesend: Hr. Meier, Fr. Müller, Hr. Schulze, Fr. Schmidt.Verteiler: Teilnehmer, Fr. WagnerTOP 1: Teilprojekt Dialoge

Information: Herr Müller stellt den Status des Teilprojekts vor.Festellung: Die Teilnehmer halten das Erreichen des Meilensteins 6 („Auslieferung Basis“) für unrealistisch

Beschluss: Die Dialoge zum erweiterten Suche werden aus dem Lieferumfang von Meilenstein 6 genommen und Meilenstein 8 zugeschlagen.Aufgabe: Hr. Müller stellt die Auswirkungen dieser Änderung und die aktualisierte Planung vor => Müller, bis 28.1.06Anlage:

Präsentation Teilprojekt Dialoge



285

Umgang mit Problemen -

Projektbeispiel

PL: Wir liefern am 4. Juli aus.Mitarbeiter: Das schaffen wir nicht.PL: Das ist mir egal. Wenn ich sage, wir liefern aus, dann liefern wir aus. Strengen Sie sich an.



286

Steuerung

ReaktionsmöglichkeitenPlanung anpassen

TermineInhalte, ErgebnisseQualitätMitarbeiter

Vergleiche: TeufelsquadratSonstige Maßnahmen

Ursache für Behinderung herausfindenAbstimmen



287

Wiederholung: Teufelsquadrat nach Sneed



288

Mögliche, typische Ursachen für zu geringe Produktivität

Mitarbeiter sind zum Teil im „Leerlauf“, weil Zulieferungen fehlen. Andere Mitarbeiter sind Flaschenhälse

in Planung berücksichtigen, Aufgaben neu verteilen.Mitarbeiter „verspielen“ sich in interessanten, aber unwichtigen Tätigkeiten

enger inhaltlich führen.Mitarbeiter glauben nicht an Projekterfolg und arbeiten nur mit halber Kraft: „Das schaffen wir sowieso nicht“

Planung muss von Mitarbeitern getragen werden.Mitarbeiter arbeiten doppelt, bzw. bereits fertig gestellte Ergebnisse passen nicht zusammen

in Planung berücksichtigen, Koordination etablieren (Chefdesign, Qualitätssicherung), ggf. auch Meetings etablieren.

Ursachen zu diffus und unklar z. B. Workshop oder Audit organisieren, Im Team Ursachen bestimmen und Maßnahmen entwickeln. Know-how von außen hinzuziehen. Wirkung der Maßnahmen überprüfen.



289

Mögliche Maßnahmen zur Produktivitätssteigerung –

die „typischen“

Reaktionen

Überstunden, Urlaubssperre, etc.Psychologisches Signal: das Projekt zeigt Einsatz. Der Projektleiter steht dem Auftraggeber gegenüber besser da.Bei intensiver Anwendung überwiegt der negative Effekt den Nutzen.

Überstunden Einmalige Wirkung, kein nachhaltiger Effekt. Dauernde Überstunden wirken eher produktivitätssenkend. Einmalig ok, als Dauerzustand vermeiden.

Urlaubssperre, Absage von Schulungen, etc. Sehr hartes Mittel. Erzeugt Wirkung. Schlecht für Team und Stimmung. Verärgert langfristig Mitarbeiter.Vermeiden!

NIEMALS die geschätzten Aufwände klein- und schönreden: „Das geht bestimmt auch in 3 statt 5 Tagen“Neue Mitarbeiter ins Projekt

Wirkt nur langfristig und begrenzt.



290

Druck und Mehrarbeit

Zitate aus „Der Termin“

von Tom DeMarco„Kurze Perioden der Anspannung und sogar Mehrarbeit können eine sinnvolle Taktik sein, weil sie die Konzentration der Mitarbeiter bündeln und das Gefühl für die Wichtigkeit der Arbeit erhöhen. Mehrarbeit über einen längeren Zeitraum hinweg ist aber immer ein Fehler“„Mehrarbeit über einen längeren Zeitraum hinweg ist eine Methode zur Produktivitätssenkung.“„Ein schrecklicher Verdacht: Möglicherweise steckt hinter Druck und Mehrarbeit der Grund, dass im Falle eines Scheiterns niemandem ein Vorwurf gemacht werden kann.“



291

Druck im Projekt Zitate aus „Der Termin“

von Tom DeMarco

„Menschen unter Druck denken nicht schneller“„Vielleicht setzen Manager Druck deshalb so oft ein, weil sie nicht wissen, was sie sonst tun sollen, oder die schwierigen Alternativen scheuen.“IT-Projekte sind Projekte, bei denen mit dem Kopf gearbeitet wird.

Die Haupttätigkeit ist Denken.Ein Projekt soll nicht vor sich hin plätschern, deshalb setzt man in der Planung gezielt Meilensteine, um Zwischenziele zu haben und einegesunde Spannung aufrecht zu erhalten. Übermäßiger Druck ist schädlich und wirkungslos.



292

Projekttagebuch –

Motivation

Störende Einflussfaktoren auf ein Projekt:Beistellungen verzögern sichExterne Entscheidungen verzögern sichHardware fällt aus, muss repariert/beschafft werden

…Diese Einflüsse verzögern das Projekt und sind vom Projekt selbst nicht zu verantworten.Trotzdem soll nicht gleich eskaliert werden, damit eine gute Zusammenarbeit im Verhältnis Auftraggeber-Auftragnehmer gewahrt wird.Diese Problemchen, die jedes für sich auch zu verkraften wären, können sich zu einem großen Problem akkumulieren. Falls es dann doch zu einer ernsthaften Diskussion über den Grund von z. B. Projektverzögerungen kommt, gerät das Projekt in Erklärungsnot.



293

Projekttagebuch –

Vorgehen

Führen eines „Tagebuchs“, in dem die kleinen Behinderungen und Besonderheiten dokumentiert werden, die nicht gleich an die große Glocke gehängt werden.Das Projekttagebuch wird durch den Projektleiter geführt.Es wird nur bei Bedarf herangezogen und dient der Absicherung des Projekts.



294

Teamführung

KommunikationFührungsstilVerhalten bei FehlernFeedback



295

Teamführung: Kommunikation

Kommunikation ist eine der wichtigsten Aufgaben des Projektleiters.Für Kommunikation muss man aktiv als Projektleiter sorgen, Kommunikation geschieht nicht automatisch von allein.Jeder Mitarbeiter sollte wissen, woran seine Kollegen arbeiten, z. B.

durch eine kurze Statusrunde im TeammeetingThemen und Verantwortliche im Arbeitsraum als Poster aufhängen

Als PL nicht davon ausgehen, dass das Team den gleichen Kenntnisstand hat wie man selber

Das eigene Bild vom Projekt und von Projektinhalten ändert sich schleichend und unbemerktRuhig auch mal die „selbstverständlichen“ Dinge kommunizieren



296

Die „selbstverständlichen“

Dinge…

…geschehen seltsamerweise nicht von selbst

BeispieleWenn ein Missstand entdeckt wird, muss man diesen beseitigen.Wenn eine Maßnahme beschlossen wird, muss man diese auch durchführen.

Häufige Ursache:Im Team fühlt sich niemand verantwortlichDer Projektleiter ist immer verantwortlich, er muss Mitarbeiter beauftragen und nachhaken





Praxisbeispiel: zwei Teams

Führungsstil Team AInformationen sind Herrschaftswissen.Planung erfolgt heimlich und im „stillen Kämmerlein“Jeder Mitarbeiter wird nur über die Dinge informiert, die er zur Erledigung seiner Aufgaben benötigt.Projektleitung zieht alle Aufgaben an sich.

Führungsstil Team BStetiger Informationsfluss ins Team (allerdings nicht über noch unsichere Dinge, die das Team verunsichern können)Informationen aus Steuerungsgremien sind weitgehend transparent.Projektleitung kommuniziert, vermittelt Bild für das GanzeProjektleitung gibt Aufgaben ab.

298

De Marco, Der Termin

Vier Grundsätze guten Managements:Wählen Sie die richtigen Leute aus.Betrauen Sie die richtigen Mitarbeiter mit den richtigen AufgabenMotivieren Sie die MitarbeiterHelfen Sie den Teams, durchzustarten und abzuheben.Alles andere sind Administrivialitäten



299

Umgang mit Fehlern und Kritik

Fehler sind niemals schön und erfreuen niemanden.Aber: honorieren, dass Fehler zugegeben werden. Auch schlechteNachrichten honorieren: „bad news welcome“Selber Fehler zugeben.Kritik immer zur Sache, niemals zur Person!



300

Das „Wer hält am längsten die Luft an“-Spiel

Beispiel für Konsequenzen des Fehler-Verschweigens:Ein großes Projekt besteht aus mehreren Teilteams.Alle Teilteams haben Zeitverzug, der Gesamt-Termin ist nicht mehr haltbar.Alle Teilteam-Leiter wissen, dass ihre Kollegen in Verzug sind und pokern darauf, dass ihre Kollegen zuerst Zeitverzug melden müssen.Sobald das erste Teilteam Zeitverzug anmeldet, melden dann auch alle restlichen Team Verzug an, mit Hinweis auf das zuerst „aufgetauchte“Teilteam.Das Gesamtprojekt steht vor einem Scherbenhaufen. Der Termin wäre noch zu retten gewesen, wenn frühzeitig der Zeitverzug gemeldet worden wäre.



301

Die Schere im Kopf

Projektsituation: Verfahrene Lage, größere ProblemeDa hilft nur ein Befreiungsschlag

Problem: Man hat „die Schere im Kopf“:Termine, bereits geleistete Arbeit, Budget, sonstige Verpflichtungen

Zur Entscheidung über das weitere Vorgehen muss man wissen, was die Probleme wirklich löst.Fragestellung an Experten/Mitarbeiter: „Was würden Sie machen, wenn Sie der Kaiser von China wären?“

Also: frei und unbefangen sagen, was in dieser Situation das beste ist.Danach die Entscheidung treffen.



302

Feedback

Feedback für das Team ist enorm wichtigRegeln:

zeitnah: sobald die Gelegenheit, der Anlass dazu da ist – sonst wirkt Feedback nicht.Zu Feedback gehört auch positives Feedback:MotiviertBestärkt

Beispiel: Sie fahren Auto in einer fremden Stadt. Wegbeschreibung:„Folgen Sie der Straße 5km“ oder„Folgen Sie der Straße 5km. Nach 800m passieren Sie eine Tankstelle. Nach 1,5km fahren Sie unter einer Brücke durch. Nach weiteren 2km ist auf der linken Seite eine Windmühle“

Ständige Bestätigung, dass man auf dem richtigen Weg ist, gibt Sicherheit und motiviert.„Nicht geschimpft ist genug gelobt“ reicht nicht!



303

Teambildung

Team bedeutet GemeinsamkeitTeambildung fördern:Gemeinsame ZieleRäumliche Nähe der BürosKaffeekücheTeam-Events, z. B.:Pizza Essen, Kanu fahren, Kegeln gehen, Team T-Shirt…Originalität ist wichtiger als Geld auszugeben, kreativ sein

Positiv: es bildet sich „Elite-Denken“: Wir sind die besten!



304

Zusammenfassung (1)

Ein Statusreport dient zur Feststellung des Ist-Zustande und zur aktuellen Planung und enthält

Aktuelle Risikoliste des ProjektsEv. Meilenstein-TrendanalyseNächste Schritte, Vorgehen bis zum nächsten TerminEntscheidungsbedarfStatus-Ampel

Professionelle Meetings folgen auf eine Einladung, haben ein Ziel, einen Verantwortlichen sowie Protokollführer und vorbereitete Technik Ein Protokoll wird sofort nach dem Meeting aufgeschrieben und enthält

Datum und TeilnehmerVerteiler (nicht teilgenommen, aber offiziell informiert)Tagesordnungspunkte



305

Zusammenfassung (2)

Teamführung heißtdie richtigen Leute auszuwählen, mit den richtigen Aufgabe zu betrauen und zu motivierenFehler zuzugeben und Missstände möglichst sofort zu behebenPositives Feedback zu geben

Übermäßiger Druck bei Projektverzug ist schädlich und wirkungslos

Eine Liste offener Punkte hilft beim ControllingEin Projekttagebuch dient der Absicherung des Projekts und wird nur bei Bedarf herangezogen.



Projektmanagement: Risiko-, Änderungs-

und Konfigurationsmanagement

307

Ziele

Projektrisiken einschätzen und vermeiden/verringern lernenÄnderungsmanagment mit Change Requests kennen lernenTechniken des Konfigurationsmanagments kennen lernen


Risiko-, Change-


308

Motivation: Herr Müller und die Sommerreifen

Das hab ich kommen sehen!15. November 2005: Herr Müller verlässt das Haus und steigt in seinen Wagen. Es hat über Nacht geschneit, doch der Wagen hat noch Sommerreifen. Herr Müller hat ein Problem: Der Weg führt über einen Hügel, aber mit Sommerreifen hat er keine Chance, über den Hügel zu kommen. Und jetzt sind die Werkstätten natürlich vollkommen überlaufen. Die Reifen können erst in zwei Wochen gewechselt werden.

Viele Probleme sind absehbar, wenn man sich nur früh genug Gedanken darüber macht.Ein Risiko ist ein potentielles Problem, das noch nicht eingetreten ist, das aber eintreten könnte.Risiken sind in der Regel einfacher zu bekämpfen als die Probleme!


Risiko-, Change-


309

Risikomanagement im Projekt

Risikomanagement ist ein ständiger Prozess.Risikomanagement geht alle im Projekt an.Verantwortlich für Risikomanagement:

Projektleiter, delegiert in der Regel an Qualitätssicherer oder Teammitglied.

Risiken ändern sich ständig und müssen immer wieder neu bewertet werden.


Risiko-, Change-


310

Risikomanagement und Projektphasen

Risikomanagementaktivitäten während der Projektdurchführung


Risiko-, Change-


311

Pareto-Regel

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

Konsequenzen:Fokussierung auf wichtige RisikenFrühzeitige Erkennung und Vermeidung


Risiko-, Change-


Vilfredo Federico Pareto (gebürtig Wilfried Fritz Pareto; 1848 -

1923)italienischer Ingenieur, Ökonom und Soziologe

313

Identifizieren von Risiken

Sammeln von Risikenspezielle Risikorunde (PL, QS,CD, einzelne Mitarbeiter)im regelmäßigen Team-Meeting: z. B. jedes 2. Mal werden die Risiken besprochen und neue Risiken und Maßnahmen gesammelt

Bereiche für Risiken (zur Klassifikation):TechnikFachlichkeitTeamVorgehen im Projekt, PlanungAuftraggeber


Risiko-, Change-


314

Beispiel SENSORIA


Risiko-, Change-


Wissenschaftliche Risiken

Technologische Risiken

Organisatorische Risiken

315

Risikoquellen


Risiko-, Change-


Anforderungen

Anforderungen insgesamt unausgereift oder in Teilen noch unklar

Voraussehbar zahlreiche Änderungen

Änderungsfreudigkeit des Kunden/Auftraggebers

Technik

Unrealistisches Design

Einzusetzende Technologie wird erst im Laufe des Projekts am Markt verfügbar

Unklar, ob geforderte Performanz erfüllt werden kann

Erstmaliger Einsatz neuer Tools, Soft- oder Hardwarekomponenten

Anwendung

Hohe Komplexität, viele ungelöste Probleme

Fehlende Erfahrung mit Teilaufgaben

Keine Erfahrung in neuer Anwendungsdomäne

Kunde

Konkurrierende Interessengruppen, Widerstände (z.B. von Anwendern)

Keine Erfahrung mit Auftragsvergabe nach außen

Mangelnde Kooperationsfähigkeit oder –bereitschaft

Integrierte Entwicklung Auftraggeber/Auftragnehmer

316

Risikoquellen


Risiko-, Change-


Projektauftrag, -abwicklung

Unrealistische Termine

Unrealistische Budgets

Projektorganisation

Einsatz von Unterlieferanten (generell)

Bekannte Probleme von Unterlieferanten

Zulieferungen von anderen Projekten oder internen Stellen

Ressourcen

Drohender Ressourcenentzug wegen anderer, wichtigerer Projekte

Ressourcenengpässe oder unzuverlässige Ressourcenzusagen

Personelle Mängel

Nicht der richtige Projektleiter (unerfahren, ungeeignet, nicht anerkannt etc.)

Nicht die richtigen Mitarbeiter (mangelnde Qualifikation oder Erfahrung)

Drohender Ausfall von Mitarbeitern (Krankheit, Kündigung)

317

Bewertung von Risiken

Bewertung:Wie schlimm sind die Auswirkungen, wenn das Risiko eintritt?Wie hoch ist die Wahrscheinlichkeit, dass das Risiko tatsächlich eintritt?Ist das Risiko vermeidbar?

Daraus Gesamtbewertung:Wie groß ist das Risiko?


Risiko-, Change-


318

Gesamtbewertung von Risiken

Üblich: 3-stufige Bewertung

gering, mittel, hoch.

Verrechnungeigentlich nach Formel:

Wahrscheinlichkeit * Schwere

Üblich: tabellarische Bewertung mit „Handjustierung“, d. h. Risiken können auch eine andere Kategorie haben als die der Tabelle


Risiko-, Change-


319

Beispiel Risikobewertung SENSORIA


Risiko-, Change-


320

Beispiel Risikobewertung SENSORIA


Risiko-, Change-


321

Beispiel: Risikoanalyse


Risiko-, Change-


KonventionalstrafeVerlust von Folgeaufträgen

nur Konventionalstrafe

wird übersehen oder kann nicht korrigiert werden

Auswirkungen mit Ereignisbaum abschätzen

wird rechtzeitig bemerkt und kann korrigiert werden

0,3 * 800.000 €

+ 0,7 * (0,2 * 11 Mio €

+ 0,8 * 1 Mio €)= 2,34 Mio €

Termin-überschreitung

+

+

1 Mio €

+ 10 Mio €

1 Mio €

Zusatzaufwand1000 PT = 800.000€

0,3

0,7

0,2

0,8

2,34 Mio €

errechnetgeschätzt

322

Beispiel: Risikoprioritätenbildung


Risiko-, Change-


Maßnahmen durch Entscheidungsbaum vergleichen

Vergleich der Alternativennichts tun:

0,11 * 2,34 Mio€

= 257.400 €Pioniere:

0,7*16,000 €

+ 0,3*2,356 Mio€

= 718.000 €Korrektur:

0,1*0,8 Mio €

+ 0,9* 3,14 Mio€

= 2,906 Mio €

Korrektur durchführen

Pioniere vorschicken

nichts tun

klappt

klappt nicht

klappt

klappt nicht

klappt

klappt nicht

2,356 Mio €

0 €

2,34 Mio €

20 PT à

800€=

16.000 €

800 T€

2,34 + 0,8 =

3,14 Mio €

0,110,89

0,30,7

0,90,1

323

Beispiel: Risikoprioritätenbildung


Risiko-, Change-


Maßnahmen durch Entscheidungsbaum vergleichen

Vergleich der Alternativennichts tun:

0,25 * 2,34 Mio€

= 585.000 €Pioniere:

0,7*16,000 €

+ 0,3*2,356 Mio€

= 718.000 €Korrektur:

0,7*0,8 Mio €

+ 0,3* 3,14 Mio€

= 1,602 Mio €

Korrektur durchführen

Pioniere vorschicken

nichts tun

klappt

klappt nicht

klappt

klappt nicht

klappt

klappt nicht

2,356 Mio €

0 €

2,34 Mio €

20 PT à

800€=

16.000 €

800 T€

2,34 + 0,8 =

3,14 Mio €

0,250,75

0,30,7

0,30,7

324

Maßnahmen entwickeln


Risiko-, Change-


Maßnahmen zielgerichtet entwickeln: für Risiken mit hohem Risiko sollte es Maßnahmen geben.

Gegebenenfalls kann man sich auch explizit entschließen ein Risiko einzugehen oder sich schon Maßnahmen einfallen lassen, um die Auswirkungen bei Eintritt zu mildern.

325

Beispiel SENSORIA

VorgehensweiseBeobachtung von „Symptomen“Planung von Korrektivmaßnahmen


Risiko-, Change-


326

Beispiel SENSORIA


Risiko-, Change-


327

Typische Präventivmaßnahmen


Risiko-, Change-


Bei technischen Risiken:

Simulation oder Prototyping von Systemen

Beratung, Reviews durch Unabhängige

Anbieten alternativer Funktionen/Konzepte (bei denen das Risiko nicht auftritt)

Vorherige Erprobung von neuen Technologien

Bei Risiken bezüglich Anforderungen/Kunde:

Verstärktes Bemühen um den Kunden, Kontaktpflege

Kundenworkshops

(Frühzeitige) Abnahme von Zwischenergebnissen vereinbaren

Pflichten des Kunden vertraglich absichern

328

Weitere Beispiele für Präventivmaßnahmen


Risiko-, Change-


Bei Ressourcenproblemen:

Schulung, Coaching von Mitarbeitern/Projektleiter

Einsetzen von Mitarbeitern in ähnliche Projekte im Vorfeld

Abwanderungsgefährdete Mitarbeiter zu halten versuchen

Prioritäten für die Ressourcenzusage mit Management diskutieren

Sonstiges

Preisaufschläge einkalkulieren

„Outsourcen“ von Risiken an Subunternehmer

330

Maßnahmen umsetzen und Wirkung prüfen

Maßnahmen sind Aufgaben:ein Verantwortlicherein Termin, bis zu dem die Maßnahme umzusetzen ist

Maßnahmen müssen wie jede andere Aufgabe auch nachgeprüft werden:

wurde die Aufgabe wirklich erledigt?

Maßnahmen können aber auch zu geringe Wirkung haben:

neue Maßnahmen oder konsequentere Umsetzung.


Risiko-, Change-


331

Dokumentation von Risiken: die Risikoliste

Eine Risikoliste umfasst:Beschreibung des Risikos

Name, BezeichnungWas kann passieren?Was sind die Konsequenzen?

BewertungWie groß ist der Schaden?Wie groß ist die Eintrittswahrscheinlichkeit?Gesamtbewertung

MaßnahmenMaßnahme, AufgabeVerantwortlicherTerminStatus


Risiko-, Change-


332

Beispiel: Risikobewertung


Risiko-, Change-


lfd.Nr.

Beschreibung

Wahrschein. Auswirkung Gewicht Gegenmaßnahme verantwortlich

Risikoliste zur Priorisierung von Risiken

1

Zulieferer fällt aus

30%

100 T 30 T 2. Zulieferer Störrle

2

Terminüber-

25%

2,34 M€

585 T€

Enge Kontrolle Wirsingschreitung

333

Tipps zum Risikomanagement

Risikomanagement darf kein leerer Formalismus sein – es muss gelebt werden.Risiken ernst nehmen, bei Erhebung nicht abblocken. Nicht sagen:„Das schaffen wir schon“Risiken gehen alle an: Mitarbeiter sollten alle die Top-5-Risiken kennenRisiken konkret formulieren – nicht abstrakt


Risiko-, Change-


334

Änderungsmanagement: Ein Szenario

Anwender Schulze:„In dem Fenster stört mich, dass ich nur zwischen den Anreden ‚Herr‘ und ‚Frau‘ auswählen kann. Eine zusätzliche Anrede ‚Familie‘ wäre praktisch.“

PL: „Ich kenne den Entwickler Meier, den rufe ich an und der macht das für mich.“Meier:

„Klar, das mach ich doch so nebenbei. Im nächsten Release ist das drin.“Alles klar?


Risiko-, Change-


335

…und die Fortsetzung

Wird das auch getestet? Irgendwo sonst im Code stand nämlich: if (anrede == „herr“) then …

else …

Passt das zu allen Schnittstellen?Wie lange dauert das Programmieren? Was bleibt deshalb liegen?Wer bezahlt das denn? – Insbesondere bei Projekten zum Festpreis

Ist das so wichtig wie der Änderungswunsch von Frau Schmidt?Ist das wirklich fachlich richtig?

Vielleicht war in der Anrede bisher das Geschlecht der Person codiert.Wer zieht das in der Nutzerdokumentation nach?

Änderungen in größeren Projekten erzeugen Unruhe, gefährden Termine, sorgen für sinkende Qualität!


Risiko-, Change-


336

Der Konflikt


Risiko-, Change-


337

Änderungsmanagement

Änderungen an Entwicklungsergebnissen sind unvermeidlichÄnderungen der AufgabenstellungNeue Erkenntnisse bei der ProduktentwicklungFehler bei der Produktentwicklung

Ziel der formalisierten Behandlung von Änderungen (Change Request) 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


Risiko-, Change-


338

Change Request

Ein Change Request ist eine Forderung nach einer Abweichung vom ursprünglich vereinbarten Leistungsumfang, vom Auftrag

Es gibt positive und negative Change Requests: Umfang kann steigen oder sinkenRegelfall: Umfang steigt

Change Requests können vom Auftraggeber und vom Auftragnehmer eingebracht werden

Regelfall: AuftraggeberChange Requests können nicht nur die Software, sondern z. B. auch die Projektorganisation oder das Projektvorgehen betreffenChange Requests können sich auf bereits erstellte oder auf noch zu erstellende Ergebnisse beziehen


Risiko-, Change-


339

Change Request-Verfahren

Das Change Request-Verfahren sorgt dafür, dass Änderungen kontrolliert in das Projekt einfließenEin Change Request sollte folgende Fragen beantworten bzw. stellen:

Was genau ist das Problem, was genau ist die Lösung?Wer will das, wer bezahlt das, wer ist davon betroffen?Wie wichtig ist der Change Request im Vergleich zu anderen? Was ist die Konsequenz, wenn der Change Request nicht umgesetzt wird?Welche Konsequenzen für Zeit, Budget, Projektinhalte hat der Change Request? (Zu ermitteln gemeinsam mit PL und Anforderer)

Beim Hinschreiben merkt man oft schon, dass mit Change Request etwas nicht stimmt.


Risiko-, Change-


Change Request bewerten

Change Request formulieren

Change Request entscheiden

Change bearbeiten

340

Change Request-Verfahren

Möglichkeiten der Entscheidung über Change Request:zulassenablehnenzurückstellen

Entscheidung durchProjektleiter (kleinere Change Requests)Lenkungskreis (größere Change Requests)

Die Änderung in die Projektplanung einarbeitenPlanung ändern


Risiko-, Change-


Change Request bewerten

Change Request formulieren

Change Request entscheiden

Change bearbeiten

341

Hinweise zum Change Request -Verfahren

Bearbeiten von Change Request-Anträgen dauert und kostet Geld, egal, ob diese umgesetzt werden oder nichtBei Projektbeginn schon die Spielregeln für Change Request-Verfahren bekannt machen, z. B. im Angebot bzw. im Projektauftrag beschreibenChange Requests technisch managen:

TabellenkalkulationSpezialsoftware, oft in Verbindung mit Konfig-Management und AnforderungenFreeware: BugZilla

Zurückgestellte Change Requests sind oft Basis für eine Folgestufe des ProjektsÜberspitzt formuliert ist ein Change Request-Verfahren ein Change-Verhinderungs-Verfahren:

Ein Change Request, der so ein Verfahren erfolgreich passiert, muss wirklich wichtig sein.

Changes sind keine FehlerOft schwierig auseinander zu halten, werden ähnlich gemanaged und eingeplant


Risiko-, Change-


342

Missbrauch des Change Request-Verfahrens

Anbieter gibt auf Ausschreibung ein nicht kostendeckendes, niedriges Angebot ab

Anbieter bekommt Zuschlag.Projekt startet

Auftraggeber ist an Anbieter gebundenDen Anbieter zu wechseln verzögert, das Projekt kostet mehr Geld

Im Verlauf eines Projekts ergeben sich zwangsläufig Change Requests des Auftraggebers

Anbieter finanziert das Projekt über Change RequestsAnbieter optimiert seinen Gewinn über Change Requests


Risiko-, Change-


343

Konfigurationsmanagement : Szenarien in der Software-Entwicklung

Szenario 1: „Der Fehler war doch schon mal draußen!“Wo kommt der Fehler denn jetzt wieder her, den habe ich doch schon vor Wochen beseitigtUrsachen: Code von anderen übernommen, mit der falschen Datei weitergearbeitet, etc.

Szenario 2: „Warum läuft das denn jetzt nicht mehr?“Mehrere Personen entwickeln gemeinsam. Auf jedem einzelnen Entwicklungsrechner ist der Code lauffähig, bei der Integration der beiden Codeteile nicht mehr.

Szenario 3: Wir müssen einen Fehler beheben. Und zwar in der Programmversion, die wir vor 6 Wochen ausgeliefert haben

Was war denn da genau für ein Code drin? Die neue Version ist noch nicht fertig und kann nicht genutzt werden.


Risiko-, Change-


344

Konfigurationsmanagement : Szenarien in der Software-Entwicklung

Szenario 4: Was habe ich denn eigentlich alles geändert?Der Code auf dem Entwicklerrechner ist lauffähig, aber es ist nicht klar, welche Dateien jetzt wirklich geändert wurden und welche nicht.

Szenario 5: In der Online-Hilfe ist das neue Fenster ja gar nicht beschrieben

Der Text ist aber irgendwo erstellt worden. Aber leider passen auch die GIFs nicht mehr zum Hilfetext in HTML.

Professionelle Software-Entwicklung benötigt professionelles Management der erstellten Ergebnisse/des Codes –

Konfigurationsmanagement


Risiko-, Change-


345

Konfiguration und Konfigurationsmanagement

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 und ihrer Versionen

KonfigurationEine Konfiguration ist eine (konsistente) Anordnung von Produkten einschließlich ihrer Beziehungen


Risiko-, Change-


346

Produkte und Aktivitäten

Produkt und Aktivität

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

Produkte:Synchronisieren, beeinflussen Aktivitäten


Risiko-, Change-


347

Konfigurationsmanagement: 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


Risiko-, Change-


349

Aufgaben Konfigurationsmanagement

Aufgaben KonfigurationsmanagementPlanung KonfigurationsmanagementBereitstellen Produkt-/KonfigurationsmanagementBereitstellung ÄnderungsmanagementBereitstellung von elementaren Diensten

Daten administrieren:-

Zentrale, projektübergreifende Haltung aller Daten-

Konsistente, vereinheitlichte DatendefinitionenSW-/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


Risiko-, Change-


350

Techniken des Konfigurationsmanagements

Einfachster Fall: Konfigurationsmanagement durch gemeinsame AblageVersionsverwaltungBilden von KonfigurationenAufgabenbezogenes Arbeiten


Risiko-, Change-


351

Einfachster Fall: Konfigurationsmanagement durch gemeinsame Ablage

Idee: alle Mitarbeiter arbeiten auf einer gemeinsamen Ablage, z. B. einem zentralen Repository oder einem gemeinsam genutzten Dateisystem.

Alle Änderungen sind damit für alle sofort sichtbar.Dateien sind gesperrt, so lange sie bearbeitet werden.

Häufig bei gemeinsam genutzten Modellierungstools (z. B. UML-Werkzeugen) anzutreffen.Funktioniert nur bei kleinen Teams und wenn die Mitarbeiter meistens auf disjunkten Dateibeständen arbeiten.Löst die meisten Probleme in den Eingangsszenarien nicht


Risiko-, Change-


352

Leistungsfähigere Ansätze


Risiko-, Change-


353

Versionsverwaltung


Risiko-, Change-


Idee: zentrales Repository (Datenbank)Verwaltet alle Dateien in allen jemals erstellten Versionen

Entwickler kopiert Dateien auf seinen Rechner (zum Lesen)Falls er eine Datei ändern will: checkout.Eine neue Version wird erstellt.Falls er die geänderte Datei in das Repository einstellen will: check-in.

Neue Version ist für alle anderen Entwickler verfügbar. Man kann aber auch auf alte Versionen zurückgreifen.

354

Versionsverwaltung -

Konflikte


Risiko-, Change-


Ein zweiter Nutzer will die Datei ändern:System kann dies verhindern (Normalfall)

oderSystem warnt, dass Datei zwischenzeitlich verändert wurdeNutzer führt eigene Änderungen mit fremden Änderungen zusammen

355

Versionsverwaltung

Der aktuelle Stand der Gesamtsoftware ist derjenige, der aktuell im Repository eingecheckt ist.Typisches Vorgehen: nightly builds

Alle Mitarbeiter müssen bis zum Abend ihren Code wieder in das System eingecheckt haben, damit kein Code gesperrt ist.Nachts wird der gesamte Code compiliert.

Wessen Code einen Compile-Fehler erzeugt, gibt eine Runde aus ☺Der nächtlich erzeugte Stand ist die Grundlage für die Arbeit am nächsten Tag

Probleme:Änderungen, die mehrere Tage in Anspruch nehmen, werden nicht unterstütztWie kommt man an den Stand vom letzten Februar?


Risiko-, Change-


356

Erweiterung: Bilden von Konfigurationen

Eine Konfiguration/Release legt zu jeder Datei festIst die Datei Teil der Konfiguration?In welcher Version ist sie Teil der Konfiguration?

Damit lassen sich beliebige Softwarestände konservieren und wieder herstellen. Das Laden einer Konfiguration ist möglich.Einsatzszenarien:

Als Ergänzung zum bisher geschilderten Vorgehen, nur mit mächtigerer HistorieStatt nightly builds: ein Mitarbeiter übernimmt die Rolle des Konfigurationsmanagers


Risiko-, Change-


357

Erweiterung: Aufgabenbezogenes Arbeiten

Problem: Um eine Änderung durchzuführen, müssen mehrere Dateien verändert werden. Diese Dateien sollen gemeinsam verwaltet werden.

Aufgabenbezogenes ArbeitenIn das Konfigurationsmanagement wird der Begriff der Aufgabe „Task“eingeführt. Ein Beispiel für eine Task ist: „Bearbeitung CR 234“ oder „Behebung Fehler XYZ“Der Entwickler meldet im Konfigurationsmanagement an, dass er eine bestimmte Task bearbeiten will. Alle jetzt bearbeiteten Dateien werden dieser Task zugeordnet.Diese Task lässt sich dann als eine Einheit verwalten, z. B. laden oder alle bereits gemachten Änderungen verwerfen.


Risiko-, Change-


358

Festlegungen für das Konfigurationsmanagement

Was soll alles verwaltet werden?CodeDokumentation?Testfälle?Executables?…

Wie ist das KM aufgesetzt?Eingesetztes ProduktProzesse: Wann darf wer den Code verändern?Verantwortliche: Wer darf Releases und Versionen erstellen?


Risiko-, Change-


359

Zusammenfassung

Risikomanagement umfasst sowohl die Identifikation und Bewertung von Risiken als auch die Planung, Durchführung und Prüfung der Wirkung von Korrektivmaßnahmen.Risiken werden nach ihrer Eintrittswahrscheinlichkeit und ihren Auswirkungen auf das Projekt (Schwere) bewertet und der nach Formel verrechnet:

Wahrscheinlichkeit * SchwereÄnderungsmanagement: Ziel der formalisierten Behandlung von Änderungen (Change Request) ist es, die Konsistenz der Entwicklungsergebnisse zu erhaltenEin Change Request ist eine Forderung nach einer Abweichung vom ursprünglich vereinbarten Leistungsumfang, bezieht sich typischerweise auf definierte Entwicklungsergebnisse oder die Organisation des Projekts und hat Auswirkungen auf

Teilprozesse (Meilensteine), davorliegende und nachgelagerte Entwicklungsergebnisse

Eine Konfiguration ist eine (konsistente) Anordnung von Produkten einschließlich ihrer Beziehungen. Aufgabe des Konfigurationsmanagement istdie Verwaltung von Produkten und Konfigurationen und deren Änderungen. Die Techniken des Konfigurationsmanagement umfassen

gemeinsame Ablage, Versionsverwaltung, Bilden von Konfigurationen undaufgabenbezogenes Arbeiten


Risiko-, Change-


Projektmanagement: Prozessverbesserung

361

Ziele

Wichtige Modelle zur Prozessverbesserung kennen lernenISO 9000 ff

Capability Maturity Model (CMM)

Software Process Improvement and Capability dEtermination (SPICE) ISO 15504

Konkrete Möglichkeiten zur Prozesseinführung und -verbesserung

kennen lernen


Prozessverbesserung

362

Prozessverbesserung

Beobachtung: Qualitätsverbesserung führt zuReduktion der EntwicklungszeitReduktion der EntwicklungskostenSteigerung der Wettbewerbsfähigkeit

Ansatz:Verbesserung EntwicklungsqualitätVerbesserung Entwicklungsprozess

(Software-)Entwicklungsprozess umfasst(Software-)lebenszyklusabhängigen Anteil

Analyse, Entwurf, RealisierungLebenszyklusunabhängigen Anteil

Planung, Kontrolle, Qualitätssicherung, KonfigurationsmanagementOrganisationsspezifischen Anteil

Prozess-Definition,-Bewertung, -Verbesserung, Ausbildung


Prozessverbesserung

363

Strukturierte Verbesserungsansätze

Ziele:Bereitstellung systematisches VorgehenRichtlinen für ProzesserfassungMetriken für ProzessbewertungMaßnahmen zur Prozessverbesserung

Ansätze:EFQM (European Foundation of Quality Management)

abstrakter, ganzheitlicher Ansatz, fragebogenbasiertCMM (Capability Maturity Model):

Reifegradbasiert, assessmentorientiertBOOTSTRAP

ähnlich CMM, detallierter, flexiblerSPICE (Software Process Improvement and Capability dEtermination)

ähnlich CMM, ISO-basiert, integriert ISO 9000, detallierter, umfassender


Prozessverbesserung

365

ISO 9000 ff –

Qualitätsmanagementsystem

ISO 9000 ff behandelt Qualitätsmanagement allgemein – nicht nur für Software. Teil 9000-3 bezieht sich auf Software.Idee: Die Gesamtheit der QS-Prozesse, Organisationsstrukturen etc. einer Firma bildet das Qualitätsmanagementsystem (QMS). Man kann Anforderungen an ein solches System definieren und ein QMS zertifizieren. Diese Zertifizierung muss in regelmäßigen Abständen wiederholt werden.Fragestellungen:

Sind die Prozesse festgelegt und dokumentiert?Werden diese Prozesse auch umgesetzt?Führen diese Prozesse zu guten Resultaten?


Prozessverbesserung

366

ISO 9000 ff –

Praxisbeispiele

Negativbeispiel: „erschlichene Zertifizierung“Positivbeispiel:

Eine Firma hat ein funktionierendes, schlankes QMSDie Auditierung für die Zertifizierung nach ISO 9000 hält diesem QMS den Spiegel vor:

Wo kann man das QMS noch verbessern?Wo sind Punkte, die man aus Betriebsblindheit übersehen hat?

Die angestrebte Zertifizierung erzeugt im Projektalltag einen gewollten Druck, damit Qualitätssicherungsaspekte nicht untergehen können.Die Produktqualität steigt, Qualität ist im Bewusstsein aller verankertDie bestandene Zertifizierung ist eine „Belohnung“, ein Lob über das sich alle freuen.


Prozessverbesserung

367

ISO 9126-1 Qualitätsmerkmale

Fragestellung: woran misst man Qualität?Problemstellung im Projekt:

Sicherstellen, dass kein wichtiger Aspekt übersehen ist:Bei der Definition von Qualitätszielen im QM-PlanBeim Erheben von Anforderungen

Ein Auftraggeber weiß unter Umständen gar nicht, dass er eine Anforderung zu einem bestimmten Kriterium hat oder er hält sie für so selbstverständlich, dass er sie gar nicht nennt.

ISO 9126-1 enthält ein Qualitätsmodell, in der Praxis am wichtigsten sind die Qualitätsmerkmale (quality model for external and internal quality)


Prozessverbesserung

368

SW-Qualität nach ISO 9126 (Wiederholung)

6 Qualitätsmerkmale nach DIN ISO 9126Funktionalität:

Vorhandensein von Funktionalität entsprechend den Anforderungen Richtigkeit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit

Zuverlässigkeit:Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu erbringenReife, Fehlertoleranz, Wiederherstellbarkeit

Benutzbarkeit:Aufwand für Benutzung, Beurteilung von BenutzergruppenVerständlichkeit, Erlernbarkeit, Bedienbarkeit

Effizienz: Verhältnis zwischen Leistungsniveau der SW und Umfang der eingesetzten BetriebsmittelZeitverhalten, Verbrauchsverhalten

Änderbarkeit: Aufwand für Korrekturen, Verbesserungen, AnpassungenAnalysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit

Übertragbarkeit: Eignung zur Übertragung in andere SW oder HW UmgebungAnpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit


Prozessverbesserung

369

CMMI

Capability Maturity Modelvon der Carnegie Mellon University (Software Engineering Institute) entwickeltes Qualitätsmanagementmodell (1991)2002 Aktualisierung zu Capability Maturity Model Integration (CMMI), in der zwischenzeitlich entstandene Spezialformen des CMM integriert wurden:

Software-CMM, Software Engineering-CMM, Integrated Product Development-CMM

Idee:Ausgangsfrage: Wie reif ist eine Organisation? Wie reif sind ihre Software Engineering Prozesse?Definition von fünf Stufen, um die Reife einer Organisation zu bewerten.


Prozessverbesserung

370

Capability Maturity Model (CMM) Aufbau

Ziel:Erhöhung der Qualität und ProduktivitätReduktion des Risikos

Verfahren: Stufenorientiert5 Stufen von 1 (schlecht) bis 5 (gut) zur Einordnung der aktuellen Prozessreife („maturity“) anhand von 18 Prozessbereichen („Key Process Areas“, KPAs)Feststellung der Einordnung mittels fragebogenbasierten AssessmentsStrukturierte Handlungsempfehlungen entsprechend Prozessreife

Zertifizierung: Einer Organisation wird die Reifegradstufe i nach CMM attestiert, wenn alle Prozessbereiche von der Organisation beherrscht werden, die zu den Reifegradstufen 1 bis inklusive i gehören.Solche Zertifizierungen sind langwierig und teuer, und im wesentlichen nur für sehr große Organisationen geeignet.Man rechnet ca. 2-3 Jahre um von Reifegradstufe i nach Reifegradstufe i+1 zu gelangen. Es gibt aber auch Fälle, wo eine Level-5-Organisation „auf der grünen Wiese“ aufgebaut wurde.


Prozessverbesserung

371

CMM Anspruch der Prozessverbesserung


Prozessverbesserung

Effizienz steigt ständig weiter„Processes are continuously and systematically improved.“

Ständige Verbesserung von Präzision und Effizienz.„Processes are quantatively understood and stabilized.“

Ausreißer werden selten„Problems are anticipated and prevented.“

Immer noch viele Pannen, aber realistischere Planung„Success depends on individuals, management supports.“

ungerechtfertigt optimistische Planung„Success depends on individual heroics.“

5

4

3

2

1

Zielgröße

Wsk

.

Ziel

Level

Ablauf

abgedeckte Prozessbereiche (KPAs)

372

CMM-Stufen

Level 1: „Initial“Wir machen es irgendwie.Wir wissen nicht so genau, wie wir es machen.

Level 2: „Managed“ (alter Name: „Repeatable“)Es gibt einen Software-Engineering Prozess.Was wir einmal hinbekommen haben, kriegen wir auch erneut hin.Das ist aber auch abhängig von den jeweiligen Personen.

Level 3: „Defined“Der Software-Engineering Prozess ist standardisiert.Wir können den Prozess auch umsetzen, wenn es mal schwierig wird.

Level 4: „Quantitatively Managed“ (alter Name: „Managed“)Der Prozess wird organisationsweit standardisiert durchgeführt.Die Ausführung des Prozesses wird dokumentiert und mitKennzahlen gemessen.

Level 5: „Optimizing“Aus den Kennzahlen leiten wir ab, wie wir uns verbessern können.


Prozessverbesserung


Prozessverbesserung

CMM-Verbreitung (SEI 2006)

374

CMM und CMM-I Bewertung und Ausblick

CMM war der erste systematische Ansatz zur Prozessverbesserung.Das CMM war aber in vielerlei Hinsicht unbefriedigend

unvollständigteuer und langsam, daher nur für große Organisationen geeignetsehr stark auf Qualität fixiert, daher nicht in allen Anwendungsgebieten kosteneffizient / wirtschaftlich sinnvoll: good-enough is better.

Es gab daher Verbesserungsbemühungen für die geplante Nachfolgeversion CMM v2.0. Parallel wurden aber auch andere Ansätze (weiter-)entwickelt, insbesondere ISO 12207 & ISO 15504.Die Nachfolgeversion von CCM ist

„Integriertes CMM“

(CMM-I), das sehr ähnlich zu ISO 12207 ist.


Prozessverbesserung

375

SPICE/ISO-15504 Ursprünge


Prozessverbesserung

S oftwareP

rocess

I

mprovement &C

apability

d E

termination

ISO/IEC TR 15504(SPICE)

SW-CMM ISO 12207

ISO-15504

SPICE war ursprünglich eine Europäische Initiative,wird heute sehr stark in Australien und Japan vorangetrieben

376

SPICE/ISO-15504 Grundprinzipien

Ansatz:Integration existierender Ansätze, z.B.:

CMMISO 9000

Verfahren:Bewertung des Entwicklungsprozesses durch AssessmentsUnterteilung in Prozess- und ReifegraddimensionUnabhängige Bewertung der ProzessdimensionenIdentifikation von Verbesserungsmöglichkeiten


Prozessverbesserung

377

SPICE/ISO-15504 Grundprinzipien

Prüfung der im Unternehmen gelebten Prozesse gegen ein ProzessmodellAnalyse der Stärken und SchwächenErstellung von Verbesserungsvorschlägen


Prozessverbesserung

378

SPICE und CMM

Wesentliche Neuerung gegenüber CMM:Reifegrad von einzelnen Prozessen und nicht von einem ganzen Unternehmen.

Ansatz:Eine Reihe von Prozessen

Eine Bewertung des Reifegrads für jeden Prozessunabhängig von anderen


Prozessverbesserung

379

SPICE/ISO-15504 Dimensionen

Prozessdimension:Umfang: 3 Kategorien, 11 Unterkategorien, ca. 50 Prozesse Kategorien:

Primäre Prozesse (Aquisitionsprozesse, Kunde-Zulieferer-Prozesse, Entwicklungsprozesse, ...)Unterstützende Prozesse (Konfigurationsmanagement, Produktkontrolle, Qualitätssicherung)Organisation (Management,Prozessverbesserung, Ressourcen und Infrastruktur, Wiederverwendung)

Reifegraddimension:Umfang: 6 Stufen, 9 AttributeDefiniert für jeden Prozess


Prozessverbesserung

380

SPICE/ISO-15504 Prozesse


Prozessverbesserung

382

SPICE/ISO-15504 Reifegradstufen


Prozessverbesserung

383

SPICE/ISO-15504 Bedeutung und Bewertung

Internationale Standard im Bereich Prozessverbesserung, es sind zur Zeit ca. 4000 Beurteilungen in 45 Ländern erfolgt.Verbreitung von SPICE vor allem in Europa, CMM vor allem in USA,Indien, China.

SPICE ist in vielerlei Hinsicht besser als CMM, aber vergleichbar mit CMMI und (der zugehörigen Assessmentmethode SCAMPI).

SPICE istmoderner: terminologisch und konzeptuell reifer;umfassender: deckt wirklich alle Prozesse ab, und ist konsistent mit ISO 12207;feinkörniger: präzisere Erfassung des Standes und der Ziele; flexibler: andere Ausrichtung als bestmögliche Qualität möglich (insbesondere auch wirtschaftliche Kenngrößen);leichter: Auch für kleine Firmen sinnvoll einsetzbar.

Aber: wie alles erfordert auch SPICE erhebliche Sachkenntnis.Projektmanagement M9 -

Prozessverbesserung

384

SPICE/ISO-15504 Weitere Entwicklung

Ein neue Version ISO/IEC 15504:2003/2005/2006

wurde im März 2006 veröffentlicht.

Spezialisierungen nach Branchen werden parallel entwickelt.SPICE 4 Space (ESA)Automotive SPICEMediSPICEOOSPICE (Komponentenbasierte Entwicklung)IT Infrastructure SPICE


Prozessverbesserung

385

Nutzen von Prozessverbesserung Empirische Werte


Prozessverbesserung

Capability MaturityModel (CMM)

Level 1

Level 2

Level 3

73%

16%

10% 45

0,6%0,4%

Untersuchung des CMM, Stand 3.3.2000knapp 500 untersuchte Institutionen

Je AuslieferungProzentpunkte

Fehler -50Dauer -30

Fehler -

20Dauer -10

386

Nutzen von Prozessverbesserung Empirische Werte

CMMLevel

Monate Personen-Monate

gefundeneFehler

ausgelieferteFehler

Gesamtkosten(1000 US$)

1 29,8 593,5 1348 61 5.440

2 18,5 143 328 12 1.311

3 15,2 79,5 182 7 728

4 12,5 42,8 96 5 392

5 9 16 37 1 146


Prozessverbesserung

Daten für ein 200 KLoC-Projekt (Schätzung der SemaTech)

387

Der Wasserfallprozess als Basis für empirische Untersuchungen


Prozessverbesserung

Prozessmessung und -verbesserung ist heute sehr stark auf das Wasserfallmodell hin ausgerichtet -

aber wie geht Prozessverbesserung

von „agilen“

Prozessen?

388

Prozessverbesserung: Nebenwirkungen

Strukturierte Prozessverbesserungsansätze:Ziele:

Messung/Steigerung Prozessproduktivität/QualitätMessung/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-Systemen zu Billing-Systemen


Prozessverbesserung

389

Prozessverbesserung: Risiken

Risiko: Verselbständigte ProzessverbesserungProzessbewertung wichtiger als Prozessverbesserung

„Ranking“ als Ziel der ProzessverbesserungÜbertriebenes Sicherheitsdenken:

Fokussierung auf stabilen Entwicklungsprozess

Auswirkung:Vermeidung risikoreicher InnovationenÜbernahme neuer Anwendungs-/Geschäftsfelder

„Die Projekte, die es wert sind, gemacht zu werden, werden Sie eine ganze

Ebene auf der Skala nach unten bringen.“

(T. DeMarco, T. Lister Wien wartet auf Dich. Hanser, 1999)


Prozessverbesserung

390

Konkrete Prozessverbesserung Probleme

Die Durchsetzung von Prozessverbesserungen nach CMM/SPICE erfordert

Sachverstand,Entschlossenheit undDurchhaltevermögen

seitens des Managements.

Bücher sind nicht geeignet („Shelfware“).

Poster, Aushänge an öffentlich zugänglichen Orten (4K: Korridor, Kopierer, Küche, Klo) sind hingegen sehr hilfreich.

EPG‘s und Wissens-Portale sind nützlich (-> Spearmint, VM-Browser, RUP-Browser), aber aufwändig.


Prozessverbesserung

391

Prozessreview und -beratung im echten Leben Woche 1

Infrastruktur vorbereitenMail-Ordner anlegen Verzeichnisstruktur im gesicherten Bereich anlegen

Übersicht herstellenOrganigramm

Namen, Bilder, Telefon-/Raumnummern, Email-AdressenKontextdiagramm (-> Stakeholder!)

Stakes, so wie es der Berater aktuell wahrnimmtDas alles auf 4 Seiten A4 und über den Schreibtisch

Ziel feststellenAuftrag: nicht geben lassen, sondern selber formulierenAufwand: Soll/Ist festhaltenVerbessern: bis wohin?Welche Aspekte haben Priorität?


Prozessverbesserung

392


Infrastruktur, Übersicht und Ziel pflegen und validierenKontinuierlich abgleichen und ergänzen!

Prüfgegenstände beschaffen

Erfassen und Bewerten bestehender Prozesse

Hilfestellung organisierenKann ich es alleine schaffen: inhaltlich/aufwandsmäßig?Wer kann mir helfen?

Entscheidungsvorlage skizzierenErste Ideen und Stichworte notieren


Prozessverbesserung

393


Es gibt in der Regel Defizite in jedem Bereich. Die Prioritäten und Ursachen sind aber von Projekt zu Projekt unterschiedlich.

Meistens ist mit einigen sehr einfachen Maßnahmen schon viel gewonnen.Erfahrungsgemäß sind folgende Maßnahmen schnell wirksam.

Start-/End-Workshops für Projektabschnitte und TeilprojekteOrganigramm zur allgemeinen VerfügungProjektplan mit Terminen, Meilensteinen und Verlaufsdaten des Projektes veröffentlichen (Poster, Kaffeeküche)Risikomanagement einführenErfolgskritische Teile identifizieren (in Abstimmung mit Kunde und Projektleitung), Stand dieser Teile mit Inspektionen bestimmen.Issue-Management einführenKonfigurations- und Änderungsmanagementautomatisches Make/Build


Prozessverbesserung

394

Zusammenfassung

Der gebräuchlichste Ansatz zur Verbesserung von Produktqualität führt über die Verbesserung der Prozessqualität.Die bedeutendsten Ansätze zur Prozessverbesserung sind CMMI und ISO 1504 (SPICE). Diese Ansätze sind oft teuer und langsam, aber letztlich alternativlos.Prozessqualität bemisst sich, abgesehen von der Produktqualität, nach Produktivität, Prognostizierbarkeit und Flexibilität.Bevor ein Prozess verbessert werden kann, muss es zunächst überhaupt einen definierten Prozess in einer Organisation geben.Etwa 2/3 aller SW-Organisationen haben keinen Prozess.Wo vollumfängliche Prozesseinführung unangemessen ist, kann man sich mit einigen einfachen ersten Schritten behelfen.


Prozessverbesserung

395

Nachbemerkungen (1)

Qualitätsmanagement ist eine eigene Vorlesung, hier geht es um die Ideen und die Einordnung zum Projektmanagement.In einem Formalismus stecken auch Gefahren:

Es können riesige Regelwerke entstehen, die niemand mehr überblicken kann und deren Inhalte nicht gelebt werden können. Hat ein Formalismus erst einmal diese Größe erreicht, ist er tot. Auch die vorhandenen sinnvollen Inhalte sind dann nutzlos.Eine „hauptberufliche“ QS neigt zur Überreglementierung, indem jeder Handschlag vorgeschrieben ist. Das tötet den Spaß an der Arbeit und letztendlich auch die Qualität.Einen Formalismus betreiben und überwachen kann man auch, wenn man keine Ahnung von den eigentlichen Inhalten der Arbeit hat. Dann hält man sich an Formalia fest, die eigentlich unnütz oder sogar schädlich sind.


Prozessverbesserung

396

Nachbemerkungen (2)

Jeder leere Formalismus ist nutzlos. Durch Formalismen lässt sich Qualität nicht erzwingen. Wenn Sie im Projekt auf solche Fossilien treffen, beseitigen Sie diese.Wenn aber im Projekt Qualität gelebt wird, sind Formalismen hilfreich

Sie geben einen Rahmen.Sie stellen sicher, dass nichts übersehen wird oder in Vergessenheit gerätSie können die Priorität der Ecke „Qualität“ im Teufelsquadrat erhöhen.

Insbesondere sollte man sich um den Software-Prozess kümmern - es lohnt sich.Das wichtigste ist, sich überhaupt zu kümmern. Wie das geschieht, ist eher zweitrangig.


Prozessverbesserung

Vorlesung VS SS 2007 · Projektmanagement ist ein wenig, wie sich das Rauchen abzugewöhnen: leicht...

Documents

Transcript of Vorlesung VS SS 2007 · Projektmanagement ist ein wenig, wie sich das Rauchen abzugewöhnen: leicht...