copyright: dr. klaus röber 1 workshop: grundlagen des it-projektmanagements - version 3.0 -...
TRANSCRIPT
Copyright: Dr. Klaus Röber 1Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Vorgehensmodelle für IT-Projekte
Copyright: Dr. Klaus Röber 2Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Vorgehensmodelle
Ein Vorgehensmodell stellt Methoden und Elemente des Projektmanagements zu Prozessen und Phasen eines standardisierten Projektablaufes zusammen.
In diesem Sinne ist ein Vorgehensmodell als Projektmanagementsystem nach DIN 69904 und 69905 anzusehen.
Voraussetzung für ein sinnvolles Vorgehensmodell ist die Einengung auf eine Projektart, da ansonsten doch wieder das gesamte Fachwissen des Projektmanagements integriert werden müsste.
Copyright: Dr. Klaus Röber 3Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Merkmale eines Vorgehensmodells
Ein Vorgehensmodell ist ein generischer Leitfaden. Projekte benutzen es als Schablone oder als Baukasten
zur Generierung eines eigenen, für den jeweiligen Projekttyp angepassten Planungsleitfadens ( „Projekt-Vorgehensmodell“ !! )
Ein Vorgehensmodell ist ( aufgrund der langjährigen praktischen Erfahrungen ) eine sehr fundierte, vorgedachte Abbildung eines IT-Projektes:– es beinhaltet alle wesentlichen Aktivitäten und Ergebnisse eines IT-
Projektes
– die Reihenfolge der Aktivitäten
– praktische erprobte Methoden Es ist eine Art Checkliste, die eine professionelle
Planungsbasis für jedes konkrete Projekt darstellt.
Copyright: Dr. Klaus Röber 4Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Vorgehensmodell: Zusammenhang der Aktivitäten
SoftwareentwicklungKonfigurationsmanagementÄnderungswesenQualitätsmanagementProjektmanagementProjektcontrolling
Anmerkung: In der Literatur beschriebene Vorgehensmodelle umfassen nicht immer alle Aktivitäten
SWEKMÄWQMPMPC
======
Copyright: Dr. Klaus Röber 5Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Allgemeines Phasenschema
Problemstellung
Konzepterstellung
Definition
Entwicklung
Produktion
Nutzung
Außerdienststellung
Missstand, Initialzündung, Projektidee
Phasenmodelle kamen zuerst bei der RealisierungVon Raumfahrt- oder Militärprojekten in den USAZur Anwendung (z. B. 1964 bei der US Air Force und 1968 bei der NASA. Sie gingen auf ebenfalls von amerikanischen Unternehmen entwickelte Grundlagen des Systems Engineering zurück.In Europa wurde dieses Planungsinstrument beim Bau von Trägerraketen für die Weltraumfahrt verwendet. Projektspezifische Phasenabläufe im deutsch- sprachigen Raum fanden sich in Projekten des Bundesverteidigungsministeriums zur Entwicklung der Wehrtechnik (1971).Auch bei der Entwicklung von Elektronik-Komponen- ten setzte der Philips Konzern dieses Instrument ein (1973).
: Meilenstein = Entscheidung über Abbruch oder Fortsetzung
Copyright: Dr. Klaus Röber 6Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Phasenmodell der HOAI (Stand 1.1.96)
9. Objektbetreuung + Dokumentation
8. Objekt-(Bau-) überwachung
7. Mitwirkung bei der Vergabe
6. Vorbereitung der Vergabe
5. Ausführungsplanung
4. Genehmigungsplanung
3. Entwurfsplanung
2. Vorplanung
1. Grundlagenermittlung
Konzeption
Vorbereitung
Konstruktion
Ausführung
Überwachung der Beseitigungvon Mängeln und Dokumentationdes Gesamtergebnisses
Überwachung der Ausführung
Prüfung Angebote, Mitwir-kung bei Auftragsvergabe
Mengenermittlung, Aufstellungvon Leistungsverzeichnissen
Erarbeitung und Darstellungder Planungslösung
Vorlagenerstellung für erfor-derliche Genehmigungen
Lösungserarbei tung derPlanungsaufgabe
Erarbeitung Teillösungder Planungsaufgabe
Voraussetzungsermittlung zurLösung der techn. Aufgabe
Ein Beispiel für ein sehr bekanntes Phasenmodell, das in der Wirtschaft außerhalb der Informatik angewandt wird, ist das Phasenmodell derHOAI (Honorarordnung für Architekten und Ingenieure, das schon aus der Mitte der 70iger Jahre stammt. Auch hier ist die Grundlage, dassz. B. der Bau eines Hauses in einer bestimmten Reihenfolge abläuft. Da der Architekt als Freiberufler meist nicht solange warten kann, bisder Bau steht, dient das Phasenmodell als Basis für die Abrechnung von Teilleistungen. .
Copyright: Dr. Klaus Röber 7Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Wasserfallmodell
Untersuchung
Analyse
Design
Realisierung
Abnahme
ImplementierungBegrif f von Boehm, Software Engineer ing Econ omics, P rentice Hall 1981Abbild ung vgl. Raasch, J., Sys tementwicklung mit strukturierten Methoden,Hanser 1991
Das Wasserfall-Modell ist eine Weiterentwicklung des „stagewise model“ (Bennington 1956). Das Modell legt fest, dass Software in sukzes-Siven Stufen entwickelt wird. Das von Royce 1970 vorgeschlagene Wasserfall-Modell erweitert das „stagewise model“ um Rückkopplungs-Schleifen zwischen den Stufen. Die Rückkopplungen werden jedoch auf angrenzende Stufen beschränkt, um teure Überarbeitungen überMehrere Stufen hinweg zu vermeiden. Dieses Modell wurde von Boehm 1981 Wasserfallmodell genannt.
Copyright: Dr. Klaus Röber 8Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
SE 4-SW:SW-Grobentwurf
SE-4-HW:HW-Grobentwurf
SE 5-SW:SW-Feinentwurf
SE-5-HW:HW-Feinentwurf
SE 6-SW:SW-Implementierung
SE-6-HW:HW-Implementierung
SE 7-SW:SW-Integration
SE-7-HW:HW-Integration
SE 8 : System-Integration
SE 9 : Überleitung in die Nutzung
SE 1: System-Anforderungsanalyse
SE 2 : Systementwurf
SE 3 : SW-/HW-Anforderungsanalyse
Software Hardware
SW-/HW-Einheit
IT-System
Technisches Umfeld
Organisatorisches Umfeld
Vorgehensmodelle: V-Modell
V-Modell
Das V-Modell ist eine Erweiterung des Wasserfallmodells. Es integriert die Qualitätssicherung.
Copyright: Dr. Klaus Röber 9Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Erweitertes V-Modell
Spezifizieren der Anforderungen
Spezifizieren des Modultests
Ausführen desModultests
Codierender Programme
Spezifizieren des Design
Ausführen desSystemtests
Ausführendes Integrations-und Funktionstests
Ausführen desAkzeptanztests
Review/Audit des Modultests
Reviewdes Codes
Spezifizieren des Integrations-und Funktionstests
Spezifizieren des System- und Akzeptanztests
Review derAnforderungen
Review/Audit desIntegrations-
und Funktionsteststests
Review desDesigns
Review desSystem- und
Akzeptanztests
Spezifizierende Tätigkeiten
Ausführende Tätigkeiten
Überprüfende Tätigkeiten
Quelle: Daic h, G. et al., “Software Test Technolog ies Repo rt”STSC, Hill Air Forc e Base 1994
Die Abbildung zeigt die erweiterte Fassung von Daich. Ausgehend vom allgemeinen V-Modell wurde ein Vorgehensmodell zunächst für die Bundeswehr und anschließend die Behörden entwickelt (1992/93). Es dient der Standardisierung der Softwareentwicklung im Bereich der Bundesverwaltung. 1997 wurde das V-Modell wesentlich überarbeitet, da es sich als sehr schwerfällig und Dokumentationslastig erwiesen hatte.
Copyright: Dr. Klaus Röber 10Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Prototyping-Modell
Anforderungenausweisen
Prototyp-Design
Prototyp-Realisierung
Bewertung/Verfeinerung derAnforderungen
Produkt-entwicklung
vg l. Raasch, J., Systementwicklung mit strukturier ten Methoden,Hanser 1991
Erfahrungsgemäß treten bei der Softwareentwicklung eine Reihe von Problemen auf, die mit traditionellen Prozessmodellen – wie dem Was-serfallmodell und dem V-Modell – nur unvollkommen gelöst werden können (z. B. Unfähigkeit des Anwenders, seine Anforderungen vollständigzu spezifizieren, experimentelle Erprobung verschiedener Lösungsmöglichkeiten, ausprobieren der Anforderungen an z. B. Echtzeitbetrieb). Diese Probleme können – zumindest teilweise – durch das Prototypingmodell gelöst werden.
Copyright: Dr. Klaus Röber 11Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Übung
Welche Vor- und Nachteile hat Ihrer Meinung nach das Prototyping im Gegensatz zu einer sequentiellen Entwicklung?
Welche Voraussetzungen beim Anwender und bei den Entwicklern müssen gegeben sein, damit Prototyping erfolgreich eingesetzt werden kann?
Arbeit in Gruppen (3-5), Zeit 20 Minuten
Copyright: Dr. Klaus Röber 12Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Lösung – Vorteile (vgl. Balzert)
Das Prototypingmodell besitzt folgende Vorteile:– Reduzierung des Entwicklungsrisikos durch frühzeitigen
Einsatz von Prototypen– Prototypen können sinnvoll in andere Prozessmodelle
integriert werden– Prototypen können durch geeignete Werkzeuge schnell
erstellt werden– Prototyping verbessert die Planung der
Softwareentwicklung– Labormuster fördern die Kreativität für
Lösungsalternativen– Starke Rückkopplung mit dem Endbenutzer und dem
Auftraggeber– Auch für die Entwicklung von Expertensystemen und
Management-Informationssystemen geeignet
Copyright: Dr. Klaus Röber 13Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Lösung – Nachteile (vgl. Balzert)
Das Prototypingmodell besitzt folgende Nachteile:– Höherer Entwicklungsaufwand, da Prototypen meist
zusätzlich erstellt werden– Gefahr, dass ein „Wegwerf“-Prototyp aus
Termingründen doch Teil des Endprodukts wird– Standardverträge für die Softwareerstellung
berücksichtigen Prototyping oft nicht– Prototypen werden oft als Ersatz für die fehlende
Dokumentation angesehen– Die Beschränkungen und Grenzen von Prototypen sind
oft nicht bekannt
Copyright: Dr. Klaus Röber 14Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Lösung - Voraussetzungen (vgl. Balzert)
Erfolgreiches Prototyping setzt folgendes voraus– Es muss ausreichend Wissen über das
Anwendungsgebiet vorhanden sein– Allein auf der Basis vorgegebener schriftlicher
Dokumente kann kein Prototyp erstellt werden. Die Entwickler müssen deshalb Zugang zu den Benutzern haben
– Der Endbenutzer muss am Prototyping beteiligt werden, die Benutzerbeteiligung ersetzt jedoch nicht die kreativen Ideen und Lösungsvorstellungen der Entwickler
– Alle an der Entwicklung beteiligten Personengruppen müssen in direktem Kontakt stehen
– Prototypen müssen im richtigen Umfang dokumentiert werden
– Die Vorgehensweise hängt von der zu untersuchenden Fragestellung ab (also nicht Standard!)
– Geeignete Werkzeuge müssen verfügbar sein
Copyright: Dr. Klaus Röber 15Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Spiralmodell
Bei dem von Boehm 1988 entwickelten Modell handelt es sich um ein Meta-Modell. Für jedes Teilprodukt und jede Verfeinerungsebene sindvier zyklische Schritte zu durchlaufen. Die Vorgehensweise erfordert einen hohen Managementaufwand, minimiert aber die Risiken der Ent-wicklung. Sie ist deshalb besonders für große (und teure) Projekte geeignet, bei denen das Endergebnis noch nicht ganz feststeht.
Copyright: Dr. Klaus Röber 16Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
SAP-Einführung
Copyright: Dr. Klaus Röber 17Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Der Rational Unified Process (RUP)
Der RUP ist eine konkretisierte, jedoch umfangreichere Variante des sog. Unified Software Development Process (aus Verschmelzung derMethoden Objectory, Booch Method, Object Modeling Technique entstanden). Die Schlüsselkonzepte und Ansätze sind vollständig aus dem USDP übernommen. Er werden jedoch zahlreiche Unterstützungsprozesse (z. B. Projektmanagement, Configuration Management) und neue Aspekte (z. B. Prototyping) beschrieben, die im abstrakteren USDP nicht vorhanden sind. Der RUP stellt ein mächtiges Prozessrahmenwerk dar, das auf verschiedene Entwicklungssituationen zurecht geschnitten werden kann.
Copyright: Dr. Klaus Röber 18Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
JEF Engineering Process (Lufthansa Systems)
Der JEF (Java Enterprise Framework) Engineering Process ist ein von der LH Systems aus dem RUP Process entwickeltes Vorgehensmodell für dieEntwicklung von Java-Anwendungen (Möller, 2003).
Copyright: Dr. Klaus Röber 19Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
IS Generic Lifecycle (Airbus 2002)B
us
ine
ssC
ha
ng
esId
eas
M0
En
try
in
toS
erv
ice
(Re
lea
se
N )
Co
mm
itm
en
t
IS P
roje
ct
La
un
ch
ing
Dev
elo
pm
en
tL
au
nc
hin
g
Go
ah
ead
fo
rD
eplo
ym
en
t
Con
cep
t P
hase
Solu
tion
Defi
nit
ion
Op
port
un
ity
Stu
dy
Solu
tion
Develo
pm
en
t
Accep
tan
ce
Testi
ng
Dep
loy-
men
t
Op
era
tion
al
Use
Req
uire
men
tA
naly
sis
&S
olut
ion
Pre
limin
ary
Des
ign
Bus
ines
sca
se
Bus
ines
sP
relim
inar
yne
eds
Req
uire
men
tD
efin
ition
Tec
hnic
al &
Fun
ctio
nal
Acc
epta
nce
Impl
emen
-ta
tion
&F
inal
Tes
t
T
rain
ing
Beg
inA
cce
pta
nc
eT
est
WP
n
WP
n
WP
n
TestWP
2
WP
2
WP
2
TestCod
ing
&C
usto
miz
ing
Det
aile
dD
esig
nW
P 1
WP
1
WP
1T
est
Glo
bal I
SF
unct
iona
l &T
echn
ical
Des
ign
Bus
ines
sob
ject
ives
Dec
isio
n f
or
Pro
jec
t s
co
pin
g
En
d P
roje
ct
Rev
iew
afte
r 1s
tpe
riod
of u
se
Fin
al
Acc
ep
tan
ce
M13M11M1 M3 M5 M7
M14M12M10
IS Generic Lifecycle
Release N+1 ( phase depending on context)
Service Delivery
Problem Management & Escalation
Change Process
Legend : Red milestones (M3, M5, M11 and M12) are GO / NO GO milestones
Copyright: Dr. Klaus Röber 20Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
PRO-IV: Phase I
Entw icklgIndividual SW
Custom.Standard SW
Grob-Spezifikation
Meilen-stein 1
Meilen-stein 2
Q ualitäts-Sicherung
EntscheidM ake- or
Buy :
Soll-Konzept
B A 01
Ist-Analyse
Basis
B A 02
Anfor-derungs-Katalog
B a04
B A 03
Lösungs-
Quali-täts-/Prüf-Plan
Alter-nativen
M B 01
Kriterien-Katalog
M ake- orBuy-Konzept
M B 02
Markt-Über-sicht
M B 03
Machbar-keits-
Analyse
M B 05
Entschei-dungs-
Vorlage
ProjektM anagem ent
Projekt-
P lan
Ab-nahm e-p ro toko ll
En tscheidLösungs-
A lte r-na tive
Meilen-stein 3
M B 04
Wirt-schaft-lichkeit
SK01 System-Architektur
SK02 Prototyp
SK03 Ablauf-Struktur
SK04 Funktions-Struktur
SK05 Daten-Struktur
SK06 Org-Struktur
SK07 Geschäfts-Modell
SK08 Oberflächen-Design
SK09 Schnittstellen
ProjektS tart
PRO-IV ist ein von der Airbus 1997 entwickeltesVorgehensmodell,das hier beispielhaft fürdetaillierte Ausarbeitungendes allgemeinen Wasserfall-Modells durch Firmen steht
Copyright: Dr. Klaus Röber 21Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
PRO-IV: Phase II
Fein-Spezifikation
M eilen-stein 4
M eilen-stein 5
Q ualitäts-Sicherung
ProjektM anagem ent
funktion .A bnahm e-p ro toko ll
system -techn .A bnahm eP ro toko ll
A uftraginte rn /exte rn
EntwicklgIndividual SW
IV-Konzept
IK 01
IV-Design
IK 02
Test-Anforde-rungen
IK 03
Einführ-ungs-Konzept
W I01
Wirt-schaft-lichkeit
A D 01
Admin.int./ext.Beauftr.
Fein-Konzept
P f l i c h t e n h e f tI n d i v i d u a l - S W
Fein-K onzeptFK01 System-Architektur
FK02 Prototyp
FK03 Ablauf-Struktur
FK04 Funktions-Struktur
FK05 Daten-Struktur
FK06 Org-Struktur
FK07 Geschäfts-Modell
FK08 Oberflächen-Design
FK09 Schnittstellen
FK10 Funktionsw ert-Analyse
.
Copyright: Dr. Klaus Röber 22Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
PRO-IV: Phase III
IV-technische Realisierung
P ro jektM anagem ent
P ro jekt-/Q ua litä ts-P lan
sys tem -techn .A bnahm e-P ro toko ll
funk tion .A bnahm e-P ro toko ll
M eilen-stein 1
M eilen-stein 2
Q ualitäts-S icherung
IR 03
M igra-tions-Plan
IR 01
Daten-bankenDateien
IR 02
M oduleKompo-nent. Pro-gram me
IR 05
TestDoku-menta-tion
H B 01
Benut-zer-Hand-buch
H B 02
System -Hand-buch
H B 03
Schul-ungs-Hand-buch
Realis ierung Handbuch
IR 04
PlanungPilot-Installa-tion
Copyright: Dr. Klaus Röber 23Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
PRO-IV: Phase IV
Einführung
ProjektM anagem ent
P rojekt-/Q ualitä ts-P lan
E ntlast-ungP ro jekt-le iter
A bschluß -berich t
Meilen-stein 1
Meilen-stein 2
Q ualitäts-S icherung
EF03
ProtokollBeobach-tungsph.Prod.
EF01
ProtokollMigrationAlt-Daten
EF02
ProtokollInstal.Prod.-Umgeb.
ProjektEnde
E ntscheidP rod.F re igabe
F achlich-organis .A bnahm e
Einführung 1
Einführung 2
Copyright: Dr. Klaus Röber 24Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Nutzen in der praktischen Arbeit
Der gesamte Entwicklungsprozess muss nicht in jedem Projekt neu überlegt werden.
Nutzung als „Checkliste“ oder „to do-Liste“– um nichts zu vergessen ( gibt Sicherheit )– um zu entscheiden, ob im konkreten Projekt eine Aktivität
durchgeführt und ein bestimmtes Ergebnis erzeugt werden muss. Ein erster Plan liegt ( fast ) auf Knopfdruck vor. Erleichterung der Kommunikation im Team und mit dem Management
( z.B. Begriffsklarheit Aktivitäten und Ergebnisse ) Muster-Ergebnisse sind vorhanden und können verwendet werden Erfahrungswerte bezogen auf den Aufwand und die benötigten Rollen
liegen für jede Aktivität vor. Der Einsatz eines Mitarbeiters in einem anderen Projekt oder Bereich
wird durch eine einheitliche Terminologie erleichtert.
Copyright: Dr. Klaus Röber 25Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Einfacher Ansatz zur Projektplanung
Eine einfache standardisierte Vorgehensweise: Auswahl eines Prozessmodells (Vorgehensmodells =
Modell des Entwicklungsprozesses, z. B. das bekannte V-Modell oder das Modell PRO-IV)
Zuschneiden des Prozessmodells auf die Projektbelange (Tailoring)
Zerlegung der Aufgaben des Prozessmodells in Vorgänge bzw. Teilaufgaben
Gruppieren der Teilaufgaben in Arbeitspakete Festlegen der Meilensteine
Copyright: Dr. Klaus Röber 26Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle
Übung: Projektaufgaben festlegen
Beschäftigen Sie sich mit dem Vorgehensmodell und fragen sich: Welche Tätigkeiten müssen für dieses Projekt durchgeführt werden?
Kann man Tätigkeiten eventuell weglassen, da sie für die IAA Entwicklung nicht relevant sind?
Gibt es zusätzliche Tätigkeiten?
Wenn Sie Fragen zu einzelnen Tätigkeiten des Vorgehensmodells haben, stellen Sie diese bitte.
Zeit: 45 Minuten Präsentieren (und begründen!) Sie anschließend Ihr Ergebnis.