Copyright: Dr. Klaus Röber 1 Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004Modul: Vorgehensmodelle Vorgehensmodelle für IT-Projekte

Copyright: Dr. Klaus Röber 1Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Vorgehensmodelle

Vorgehensmodelle für IT-Projekte


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.


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.


Vorgehensmodell: Zusammenhang der Aktivitäten

SoftwareentwicklungKonfigurationsmanagementÄnderungswesenQualitätsmanagementProjektmanagementProjektcontrolling

Anmerkung: In der Literatur beschriebene Vorgehensmodelle umfassen nicht immer alle Aktivitäten

SWEKMÄWQMPMPC

======


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


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


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.


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.


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.


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.


Ü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


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


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


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


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.


SAP-Einführung


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.


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


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


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


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

.


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


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


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.


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


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

Documents

Copyright: Dr. Klaus Röber 1 Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004Modul: Vorgehensmodelle Vorgehensmodelle für IT-Projekte