08-Vorgehensmodelle_neu - Informatik

Vorgehensmodelle/Schelle Januar 02 

Vorgehensmodelle im Projektmanagement 

1


Projektstart Produktziel Produkt Produkt 

definiert gefertigt getestet 

Zieldefinition Produkt fertigen Produkt testen 

Projektphasen 

Meilenstein 

2


Zwei Definitionen: 

Meilenstein (Schlüsselereignis) : Ereignis besonderer 

Bedeutung (DIN 69 900) 

Projektphase : Zeitlicher Abschnitt eines Projektablaufs 

, der sachlich gegenüber anderen Abschnitten 

getrennt ist ( DIN 69 901) 

3


Erweiterte Meilensteindefinition 

Ein Meilenstein ist ein "definiertes Sachergebnis (Meilenstein-Inhalt) gekoppelt an einen 

Fertigstellungstermin (Meilenstein-Termin) " 

o Meilensteinergebnisse können z.B. sein : Pflichtenhefte, Spezifikationen, fertiggestellte 

Teilprodukte, Testergebnisse etc. 

o Der Meilensteininhalt wird in der Ablaufplanung des Projekts festgelegt . Meilensteine 

können den Abschluß einer Projektphase bilden oder auch zwischen den Phasengrenzen 

liegen. 

o Meilensteine werden so präzise wie möglich und als 100%-Ereignisse definiert. 

Ein Hilfsmittel dafür sind z.B. Gliederungen und Inhaltsangaben von Dokumenten. 

o Der Meilenstein ist erst erreicht, wenn die die definierten Ergebnisse vorliegen. 

Jeder Meilenstein muß auf Inhalt und Qualität überprüft werden. 

4


Arten von Meilensteinergebnissen 

Bei Meilensteinergebnissen wird in der 

Praxis häufig unterschieden in 

o Ergebnisse u. Zwischenergebnisse, 

die das Produkt selbst betreffen ( Spezifikationen, 

Lastenhefte, Prototypen etc.), 

o Dokumentation u. Manuale, 

o Ergebnisse des Qualitätsmanagements 

(z.B. Test- oder Abnahmebericht), 

o Ergebnisse der Projektplanung incl. Konfigurationsmanagement 

(z.B. überarbeiteter Terminplan). 

5


Die präzise Definition von Meilensteinergebnissen 

und die Überprüfung wird durch Standards wie 

z.B. Mindestinhalte von Pflichtenheften, Checklisten 

etc. erheblich erleichtert ( Siehe nächste Folien) 

6


Ausschnitt aus Phasenplan 

Phase 0 1 

Anstoß Studie 

Phasenziel 

Phasenentscheidung 

Meilensteine 

Teilprodukte 

Quelle: Siemens AG 

Projekt-/Pro- Systemfordeduktziel 

- rungen u. 

setzungen Randbedinfestlegen 

gungen festl. 

1 2 

A10 

Pflichtenheft 

A20 

+ Gliederung Pflichtenheft 

+ 1. Zusammenfassung 

- 1.1 Problembeschreibung 

- 1.2 Kurzbeschreibung d. Leistungsmerkmale 

- 1.3 Technische Anforderungsanalyse 

- 1.4 Projekt-Anforderungsanalyse 

- 1.5 Lösungsaltern. u. Aufwände 

- 2. Requirementkatalog 

- 3. Technische Anforderungsanalyse 

- 4. Projekt-Anforderungsanalyse 

+ 5. Erster Systementwurf 

- 5.1 Gesamtsystem 

+ 5.2 Funktionsgruppen 

- 5.2.1 Schnittstellen z. Benutzer 

- 5.2.2 Schnittstellen z. and. Funktionsgr. 

- 6. Lösungsalternativen und Aufwände 

+ 7. Abnahmebedingungen 

- 7. 1 Software-System 

- 7.2 Bibliotheks-Inhalte 

- 8. Rapid Prototype ( b. Bedarf) 

- 9. Randbedingungen 

7


Weiteres 

Beispiel 

Empfohlene Inhalts-Kategorien für das Pflichtenheft eines 

materiellen Produkts 

1. Produktidentifikation ( Name, Bezeichnung, Nummer) ggf. mit kurzer 

Erläuterung von Art und Verwendung, Gebrauch, Verbrauch. Ggf. 

verwandte Produkte (eigen/fremd), Zugehörigkeit zu Produktgruppen. 

2. Marketing-Ziele, die damit erreicht werden sollen ( Anwender-, 

Verbrauchergruppen, Herstellmengen, Zielmärkte (Branchen und 

Regionen), Image, Anspruchsniveau 

3. Preis - und Kostenvorstellungen (Vorgaben) als Handlungsrahmen 

4. Funktionelle Anforderungen ( technisches Konzept) 

- Prinzip, Arbeitsweise, Arbeitsbereiche 

- Leistungsdaten, Grenzwerte, Toleranzen 

- Abnahmebedingungen 

5. Abmessungen und Gewichte 

- Form, Baumaß, Lage und Funktion der Energiezufuhr 

- Anschlüsse für Energien, Abluft und Abwasser 

6. Betriebsbedingungen einschl. Umwelt, ggf. für das Exportland 

7. Konstruktionsbedingungen 

- Bedienbarkeit, Zugänglichkeit 

- Wartungsbedingungen, Reparaturmöglichkeit 

- Verschrottung 

- Kontrollsysteme 

8. Sicherheitsvorschriften 

- Betriebssicherheit, Sicherheit gegen Arbeitsunfälle 

- Schadenschutz, Lärmschutz 

- Entsorgung, Umweltschutz 

Quelle: Schönbach, G.: Das Projektbegleitende Qualitätsmanagement.In: 

Schelle, H.; Reschke, H.; Schnopp, R.; Schub, A. (Hrsg.) : Loseblattsammlung 

"Projekte erfolgreich managen", Köln 1994, Kap. 4.8.1, S 30. 

8


Ausschnitt aus einer Checkliste für Entwurfsüberprüfungen 

Fragen Ja Nein nicht zutreffend 

1. Enthält die Spezifikation sämtliche 

Auftraggeberforderungen? 

2. Erfüllt der Entwurf sämtliche Funktionsanforderungen? 

3. Berücksichtigt der Entwurf sämtliche 

Umgebungsbedingungen (Temperatur, 

Vibration, Korrosion usw.) 

4. Wurden vorhandene Informationen 

ähnlicher Entwürfe überprüft und mit 

einbezogen? 

5. Wurden, wo immer möglich, Standardbauteile 

verwendet? 

6. Sind die geforderten Toleranzen in der 

Produktion einzuhalten? 

7. Führt der Entwurf zu optimalen Installationsbedingungen? 

8. Führt der Entwurf zu optimalen 

Wartungsbedingungen? 

9. Wurde eine gründliche Wertanalyse 

gemacht? 

10. Wurden sämtliche Sicherheitsvorkehrungen 

berücksichtigt ? 

Quelle: Madauss, B.: 

Handbuch 

Projektmanagement. 

5. Auflage Stuttgart 

1994, S. 158 

9


Gute und schlechte Beispiele für Meilensteinformulierungen 

„Technischer Technischer und vertrieblicher Produktplan vom Projektteam ausgearbeitet” 

ausgearbeitet” 

Sehr viel geeigneter, weil besser auf Erfüllung überprüfbar, wäre: wäre: 

1 

` 

: 

„Technischer und vertrieblicher Produktplan (Formular III/1 und III/2 

der Produktplanungsrichtlinie) vom Projektteam ausgearbeitet und 

vom Projektlenkungsausschuß unterzeichnet.“ 

10


Ein weiteres Beispiel für eine präzise Meilensteinformulierung 

· “Die umzustellenden Attribute in den Datenbanken und die zu 

erweiternden Schlüssel sind identifiziert, die Art der Umstellung 

ist festgelegt. Die Klassifizierung der Softwareelemente in ´löschen`, 

`garantiert nicht zu ändern`, `wird abgelöst` ist verlässlich und verbindlich. 

Die entsprechende Löschung ist in die Wege geleitet.” 

Quelle: Grahl, J.; Puchan, J.; Senzenberger, A.: Systematisches 

Management eines Jahr-2000-Projekts. In: Etzel, H.-J.; Heilmann, 

H.; Richter, R. (Hrsg.): IT-Projektmanagement - Fallstricke und 

Erfolgsfaktoren. Erfahrungsberichtaus der Praxis. Heidelberg 

2000, S. 230 

11


Wer überprüft die Phasenergebnisse? 

Mehrere Alternativen: 

o Projektleiter ( häufig bei Projekten mit sehr hohem Neuheitsgrad) 

o Permanentes Review-Team ( Beispiel : Software-Projekte), 

das am Projekt selbst nicht beteiligt ist 

12


Wer überprüft die Phasenergebnisse? 

Vorschlag der NASA: 

1) Permanentes Review-Team 

o Projektleiter 

o Leiter Systemtechnik 

o Leiter Qualitätssicherung 

o Fertigungsleiter 

o Testleiter 

o Leiter Zuverlässigkeit 

o Leiter Vertragsmanagement 

o Vertreter des Auftraggebers 

2) Unterstützend hinzugezogene Review- 

Teammitglieder 

o Wartungsexperten 

o Wertanalyse-Fachleute 

o Beschaffungs-Experten 

Quelle: Madauss, B.: 

Handbuch 

Projektmanagement. 

5. Auflage Stuttgart 

1994, S. 155 

13


Bei kleineren Projekten kann die Überprüfung der Meilen- 

steinergebnisse weniger aufwendig sein. 

Sie sollte aber nie zum bloßen Ritual verkommen! 

14


Beispiele für Vorgehensmodelle 

Technische 

Projektaufgaben 

Konzeptionsphase 

Planungsphase 

Realisierungsphase 

Einführungsphase 

Nutzungsphase 

Außerdienststellungsphase 

Recycling/Modifikationsphase 

15



Organisationsprojekte 

Projektstart u. Projektplanung 

Istanalyse 

Zielplanung 

Soll-Konzeption 

Pilotanwendung 

Evaluierung Pilotversuch 

Umsetzung Gesamtkonzept 

Schulung 

Evaluierung 

16



Investitionsprojekte 

Projektstart u. Projektplanung 

Engineering 

Behördenverfahren 

Beschaffung 

Bau und Montage 

Inbetriebnahme 

Schulung und Dokumentation 

Planung der Nutzung 

17



Entwicklung von Produkten 

Projektstart und Projektplanung 

Markt- und Eigenanalyse 

Machbarkeitsstudie 

Produktentwicklung 

Produkttest und Freigabe 

Null-Serie 

Planung der Markteinführung 

18


Vorgehensmodell bei Bauprojekten 

Die Honorarordnung für Ingenieure und Architekten definiert im § 15 

folgende Leistungsphasen: 

1. Grundlagenermittlung 

2. Vorplanung (Projekt- und Planungsvorbereitung) 

3. Entwurfsplanung (System- und Integrationsplanung) 

4. Genehmigungsplanung 

5. Ausführungsplanung 

6. Vorbereitung der Vergabe 

7. Mitwirkung bei der Vergabe 

8. Objektüberwachung (Bauüberwachung) 

9. Objektbetreuung und Dokumentation 

19

Phase 


Vorgehensmodelle in der Praxis : Ein Modell 

der Siemens AG für Software-Entwicklung 

0 1 2 3 4 5 6 7 

Anstoß Studie Projektierung Design Implementie- Systemintegr. Abnahme Betreuung 

rung Test 

Phasenentscheidung 

1 22 3 4 

5 6 7 

8 

Meilenstein 

Teilprozesse 

o Produkt 

o Manual 

A10 A20 A30 T 20 T 26 T 50 B 30 

B 90 

o Produktidee o Requirements o Leistungs- o Design- o Komponente o Integriertes o einsatzreifes o Produkto 

Lastenheft o Pflichtenheft beschreib. spezifikation u. getestetes Produkt protokoll 

Produkt 

o Manualgrob- o Manualfein- o Manuale o Manuale o Übersichtsplan 

plan ( Manuskript) ( druckfertig) dokumente 

o Test o Abnahme o Testkonzept o Testplan o Komponen- o Systemtest- o Abnahme- o Testbericht 

bedingungen Testsystem- testbericht bericht bericht 

spezifikation o einsatzfäh. 

Testsystem 

o Planung o Projektplan 0 o Projektplan 1 o Projektpl. 2 o Projektpl. 3 o Phasenpl. 5 o Phasenpl.6 o Betreuungs- o Betreuungso 

QS-Plan 0 o QS-Plan 1 o QS-Plan 2 o QS-Plan 3 plan plan 

o Phasenpl. 1 o Phasenpl. 2 o Phasenp. 3 o Phasenpl.4 o Projektber. 

Order-Baseline 

Design-Baseline 

Produkt-Baseline 

20


Das V-Modell für IT-Projekte 

PM 1 

Projektinitialisierung 

PM 2 

Vergabe/Beschaffung 

PM 3 

Auftragnehmer-Mgmt 

Qualitätssicherung 

QS 1 

QS-Initialisierung 

QS 2 

Prüfungsvorbereitung 

QS 3 

Prozeßprüfung 

QS 4 

Produktprüfung 

QS 5 

QS-Berichtswesen 

PM 4 

Feinplanung 

PM 5 

Kosten-/Nutzenanalyse 

PM 6 

Durchführungsentsch. 

Projektmanagement 

Systemerstellung 

SE 1 

Systemanforderungsanalyse 

SE 2 

Systementwurf 

SE 3 

SW-/HW-Anforderungsanalyse 

SE 4-SW bis SE 7-SW 

SW-Entwicklung 

SE 8 

Systemintegration 

PM 7 

Risikomanagement 

PM 8 

P.-Kontrolle/Steuerung 

PM 9 

Informationsdienst 

SE 4-HW bis SE 7-HW 

HW-Entwicklung 

SE 9 

Überleitung in die Nutzung 

Interaktion der Submodelle auf oberster Betrachtungsebene 

PM 10 

Schulung/Einarbeitung 

PM 11/12/13 

diverses 

PM 14 

Projektabschluß 

Konfigurationsmanagement 

KM 1 

KM-Initialisierung 

KM 2 

Produkt- und 

Konfigurationsverwaltung 

KM 3 

Änderungsmanagement 

KM 4 

KM-Dienste 

21


Vorgehensmodelle in der Praxis : Beispiel Anlagenbau 

( Friedmann KG, Wien) 

PHASE ANSTOSS STUDIE ANLAGENKONZEPT REALISIERUNG UNTERSTÜTZUNG UNTERLAGEN- 

ÜBERARBEITUNG 

PHASEN- 

ZIEL 

VORAUS- 

SETZUNGEN 

E 

R 

G 

E 

B 

N 

I 

S 

S 

E 

t 

e 

c 

h 

n 

i 

s 

c 

h 

- qualität 

s-sichernd 

- projektsteu- 

Klärung bis zur Vertragsreife 

- Lastenheft (LH) 

oder 

Technologische und 

technische Klärung 

- Abgestimmte Anforderungen 

- Produktvorschlag 

Systemanforderungen 

oder 

- Projektplan 

Anfrage 

- Bestellung 

Anlagenkonfiguration Erstellung technischer Unterlagen 

- Pflichtenheft 

- QS-Plan 

- Erweiterter Projektplan 

Problemlose Fertigung, Montage 

und Inbetriebsetzung 

- Blockschaltpläne - Technische Unterlagen 

- 1-pol. Übersichtsschalt- - Subaufträge abgeschlossen 

pläne 

- Spezifikationen 

- Anlagendispositionszeichnungen 

- Meß- und Regelschemata 

Korrekte Unterlagen 

- Unterlagen von MA und IBS 

retour an TA 

- Produktvorschlag - Pflichtenheft (PH) - Anlagenspezifikation 

- Funktionspläne 

- Mechanische Auführung- - Anlage betriebsbereit - Aktualisierte Unterlagen 

- Anstoß für Entwicklung - Blockschaltpläne 

(ggf. LH) 

- 1-pol. Übersichtsschaltpläne 

- Anlagendispositionszeichnungensunterlagen 

- Elektrische Ausführungsunterlagen 

- Regelprogramme 

- Steuerprogramme 

- Handschriftlich aktualisierte - Zusammengestellte Enddo- 

Unterlagen 

kumentation für den Kunden 

- Meß- und Regelschemata 

- Funktionspläne 

- Schnittstellenspezifikation 

- Lastenhefte für Subauftragnehmer 

- Bauentwurfszeichnungen 

- Projektplan - Erweiterter Projektplan 

- Phasenabnahmebe- 

- QS-Plan - Fortgeschriebener QS- 

Plan 

- Ausgefüllte Checklisten 

- Nahtstellenfestlegung 

- Fortgeschriebener Projektplan 

- Freigegebene Unterlagen 

- TA-Angabenblätter 

- Abgeschlossener QS- 

Plan 

- Pojektplan 

- Phasenabnahmebericht 

- Technischer Abnahmebericht 

- Beginn Probebericht 


- Archivierung 

- Abgeschlossener Projektplan 


22


Ein häufiges Mißverständnis in der 

IT-Branche 

Ob man ein Vorgehensmodell wie das „Wasserfallmodell“ 

( Vgl. Folie 20 und 21) oder ein anderes Vorgehensmodell 

wie das der „inkrementellen Entwicklung“ wählt, um 

die präzise Formulierung von Meilensteinen kommt man 

niemals herum. 

23


Phasenmodelle und ISO 9000 ff. 

Zitat aus einem Kommentar zum QM-Element 4 

“Designlenkung” (DIN ISO 9001 alt) 

“ Bei umfangreicheren Entwicklungen sollten Sie die Entwicklungs- 

und Konstruktionstätigkeit ....mit Hilfe eines sogenannten 

Meilensteinplans zeitlich im Griff behalten....... Sehen 

Sie in Ihrem Entwicklungsplan nach Abschluß von Zwischenstufen 

Meilensteine vor, sowie am Ende der Entwicklung 

und Konstruktion eine Prüfung und Bewertung der Ergebnisse.” 

24


Designlenkung (DIN ISO 9001) 

4.4.6 Design-Prüfung 

In zweckmäßigen Designphasen müssen formelle, dokumentierte 

Prüfungen der Designergebnisse geplant und ausgeführt werden. 

.............................................................................................................. 

.............................................................................................................. 

4.4.7 Designverifizierung 

In zweckmäßigen Designphasen muß eine Designverifizierung 

vorgenommen werden, um sicherzustellen, daß das Entwicklungsergebnis 

der betreffenden Phase die Forderungen aus den Designvorgaben 

für die betreffende Phase erfüllt........ 

.............................................................................................................. 

25


Überlappung von Phasen 

Studie 

Projektierung 

Design 

Vorgehensmodelle 

schließen Überlappungen 

nicht aus, der Projektleiter muß 

aber das Risiko einer Phasenüberlappung 

prüfen. 

Implementierung 

26


Zwei unverdächtige Befürworter von 

Vorgehensmodellen: 

“ Die Parallelisierung von Entwicklungsaktivitäten 

erfordert eine noch stärkere Synchronisation. Der Planung 

und Überwachung von Meilensteinen als Synchronisierungs- 

und Kontrollpunkte kommt deshalb 

in parallelisierten Entwicklungsprozessen eine größere 

Bedeutung als in sequentiellen Abläufen zu.” 

(H. J. Schmelzer; K.H. Buttermilch, Siemens AG) 

Quelle: H.J. Schmelzer; K.H. Buttermilch: Reduzierung 

von Entwicklungszeiten in der Produktentwicklung als 

ganzheitliches Problem. In: Brockhoff, K. et alii (Hrsg): 

Zeitmanagement in Forschung und Entwicklung, zfbf, 

Sonderheft 23/1988, S. 43 - 72 

27


Einige Argumente der Kritiker: 

o Ein bürokratisch gehandhabtes Vorgehensmodell 

schadet dem Projekt mehr als es nützt. 

o In vielen Fällen kommt es zur Überlappung 

von Phasen. 

o Der Projektablauf gleicht oft einer “Echternacher 

Springprozession” ( Weltz) - zwei 

Schritte vor, einen zurück. 

o Es besteht eine Diskrepanz zwischen “Planung 

und wirklichem Leben.” 

28


Aber : Die Kritiker bieten keine praktikablen 

Alternativen an, sondern verweisen am Ende 

z. T. selbst wieder auf Vorgehensmodelle . 

29


? 

Einige kritische Fragen*: 

Frage 1 :Was geschieht, wenn ein Arbeitspaket, das einer Phase 

zugeordnet wurde, zum Phasenende nicht fertig ist ? 

Frage 2 : Ist es möglich, die Arbeitspakete einer Phase so zu 

bestimmen, daß alle frühestens nach der Freigabe 

dieser Phase starten oder müssen Arbeitspakete u.U zeitlich 

vorgezogen werden ? 

30


Idealfall: Arbeitspakete sind eindeutig einer 

Phase zugeordnet und werden innerhalb einer 

Phase ordnungsgemäß abgearbeitet. 

� 

� 

Phase 1 

� 

� 

� 

31


? 

Frage 3 :Was tun, wenn sich beim Review herausstellt, daß 

Arbeitspakete nochmals neu ausgeführt werden müssen 

oder zumindest Nachbesserungen erforderlich sind? 

Frage 4: Wie geht man mit Arbeitspaketen um, die sich über 

mehrere Projektphasen erstrecken? 

32


Frage 1: 

Wenn das Arbeitspaket nicht projektentscheidend ist, 

kann die nächste Phase dennoch freigegeben werden. 

Beispiel: Dokumentation, die erst später benötigt wird. 

Arbeitspaket 

Phase I Phase II 

Phasenfreigabe 

Aber : Endgültige Fertigstellung muß überwacht werden! 

33


Frage 2: 

Unter Umständen müssen Arbeitspakete schon während 

einer vorgelagerten Projektphase begonnen werden. 

Beispiel : Bestellung von Bauteilen mit sehr langer Lieferfrist 

(“Langläufer”), obwohl die Systemspezifikation noch 

nicht vollständig ist. 

Spezifikation fertig 

Bestellung “Langläufer”+ Lieferfr. 

Spezifikationsphase Prototypphase 

Aber : Damit verbundenes Risiko ist zu bewerten! 

34


Frage 3 : Der Rücksprung auf eine frühere Phase ist eher 

die Regel als die Ausnahme. 

Änderung Konstr. 

Subsystem X 

Test Subsystem X 

Konstruktionsphase Testphase 

Subsystem erfüllt Spezifikation nicht! 

Aber : Modifikation oder Neukonstruktion muß überwacht 

werden ( To-do-Liste oder Definition eines zusätzlichen 

Arbeitspakets). Siehe auch Antwort auf Frage 1 

35


Frage 4 : 

Arbeitspakete, die sich über alle oder mehrere Phasen erstrecken, 

kommen häufiger vor. Beispiel : Projektbegleitende 

Dokumentation. 

Projektbegleitende Dokumentation 

Phase I Phase II Phase II 

36


Zu Frage 4 ( Fortsetzung): 

Ratschlag : Handelt es sich um projektentscheidende 

Arbeitspakete ( z.B. terminkritisch oder wichtig für die 

endgültige Abnahme durch den Kunden) empfiehlt sich 

eine weitere Detaillierung in einzelne Vorgänge. 

Projektbegleitende Dokumentation 

37


“ Immer noch Phasenmodelle? 

Kennen Sie denn keine modernere Methode für unser 

Projekt? Welche? Eine modernere halt.” 

“Warum sollte das Vorgehen nach Phasen “out” sein? Weil 

die meisten DV-Projekte danach durchgeführt werden und 

dennoch nicht den erhofften Erfolg bringen? Ich meine, 

daß DV-Projekte nicht deshalb so oft in ihren Ergebnissen 

enttäuschen, weil , sondern obwohl sie phasenweise durchgeführt 

werden? Es liegt auch nicht an den Phasen, sondern 

daran, wie gearbeitet und gemanagt wird”. 

Quelle: Kellner, H.: Die Kunst, DV-Projekte zum Erfolg 

zu führen. München 1994, S. 82 

38


“ Gegen die altmodischen Phasenmodelle läßt sich 

viel sagen, sie haben aber den Vorteil, daß man weiß, 

wo man steht. Für die Projektverfolgung ist das eben 

ideal”. 

Zitat aus : Weltz, F. : Softwareentwicklung im Umbruch : Projektmanagement 

als dynamischer Prozeß. In : Balck, H. (Hrsg.) : Networkung und Projektorientierung. 

Gestaltung des Wandels in Unternehmen und Märkten. Berlin-Heidelberg-New 

York 1996 

39


Einige Vorteile von Vorgehensmodellen 

o Vorgehensmodelle strukturieren durch abgegrenzte, 

überschaubare Projektabschnitte und machen 

damit Komplexität beherrschbar. 

o Sie reduzieren das Risiko der Projektabwicklung 

durch Definition von Abbruchstellen an den 

Phasenübergängen (Projektreview). 

o Ein Vorgehensmodell mit klar definierten Meilensteinergebnissen 

und Reviews verschafft Transparenz 

im Projekt. 

o Die Vorgabe von Zwischenergebnissen gibt den 

am Projekt beteiligten Mitarbeitern Orientierung. 

40


Einige Vorteile von Vorgehensmodellen (Forts.) 

o Das Vorgehen nach zeitlich aufeinanderfolgenden 

Phasen entspricht dem Verhalten des Menschen 

beim Lösen von komplexen Aufgaben. 

o Da die nächste Phase erst beginnen darf, wenn die 

vorangegangene mit vollständigen und richtigen 

Zwischenergebnissen abgeschlossen wurde, kann 

man Fehler früh erkennen. 

Mängel werden nicht verschleppt. 

41


Einige Fehler , die in der Praxis bei der Verwendung von 

Vorgehensmodellen gemacht werden: 

o Man beginnt bereits mit Arbeiten der Folgephase , bevor 

die vorhergehende Phase abgeschlossen ist. 

“ Whisky-Syndrom” : “Why is`nt Sam coding yet?” 

o Parallele Teilprojekte werden nicht ausreichend koordiniert. 

Keine Synchronisation der Ergebnisse. 

o Kein sorgfältiger Review. Phasenergebnis wird z.B. 

aus firmenpolitischen Gründen abgenommen. 

o Nachträgliche Änderungen werden “unter der Hand” 

ohne systematisches Änderungsmanagement eingeschleust. 

42


Zusammenhang zwischen Projektstrukturplan, detaillierter 

Ablaufplanung und phasenorientierter Planung 

Entwicklgs- 

Antr. stellen 

u. genehm. 

Netzplanausschnitt 

Arbeitspaket 1 Arbeitspaket 2 Arbeitspaket 3 Arbeitspaket 4 

Schaltung 

entwerfen 

Entwicklungsantrag 

genehmigt 

Arbeitspaket 

Stückliste 

erstellen 

Bauteile 

bestellen 

Gehäuse 

konstruieren 

Schaltung 

bauen 

Arbeitspaket 5 Arbeitspaket 6 

Gehäuse 

bauen 

Prototypphase 

= Netzplanvorgang 

Arbeitspaket 7 Arbeitspaket 8 

Zus.bau 

Prototyp 

Protyptest 

Prototyp 

getestet 

Arbeitspakete 

aus dem Projektstrukturplan 

43


Meilensteintermine 

Meilensteintrendanalyse 

Dez 98 

Nov 98 

Sep 98 

Jul 98 

Jun 98 

Apr 98 

Feb 98 

Jan 98 

Nov 97 

Okt 98 Okt 98 

Jun 98 

Apr 98 

Jul 98 

Mai 98 Mai 98 

Berichtszeitpunkte 

Nov 98 Nov 98 

Aug 98 Aug 98 

Jun 98 

Dez 98 

Sep 98 

Jul 98 

Okt 97 Nov 97 Dez 97 Jan 98 Feb 98 

M1 

M2 

M3 

44


Ausschnitt aus dem Standardphasenplan eines 

Herstellers von Konsumgüterelektronik 

Prototypphase 

Arbeitspakete 

Meilenstein III 

Beteiligte Stellen 

Verantwortlich 

Prototyp konstruieren/bauen 

Verbindliche Form und Ansichtsmodell 

bauen, Fotovorlage 

Fertigungszeichnungen erstellen 

Kalkulation und Wirtschaftlichkeitsrechnung 

Patentlage klären 

Prototyp beurteilen und Entscheidung 

vorbereiten 

Prototyp und Fertigungsmittel 

freigeben 

PA (Produktausschuß) 

PL (Projektleiter ) 

PMT (Teilprojektleiter Technik) 

PP ( Produktplanung) 

EW (Entwicklung) 

FG (Formgebung) 

EK (Einkauf) 

PPS (Produktionsplanung - 

und -steuerung) 

QS (Qualitätssicherung) 

C (Controlling) 

Beteiligte Instanzen 

PA PL PMT PP EW FG EK PPS QS C 

45

08-Vorgehensmodelle_neu - Informatik

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?