IT-Projektmanagement - Der Gegenstand von...

Wintersemester 2012/2013

Dr. Gerhard Pews

IT-Projektmanagement

Teil 2: Der Gegenstand von Softwareprojekten

Dieser Vorlesungsteil vertieft den Gegenstand von Softwareprojekten.

Einordnung in den Fahrplan der Vorlesung

© 2010 Capgemini – All rights reserved

02-GEGENSTAND VON SW-PROJEKTEN.PPTX 2

Inhalte

• Einführung

• Das „Was“: Der Gegenstand von Softwareprojekten

• Das „Wie“: Die Tätigkeiten in einem Projekt und wie man sie ausführt

• Vorbereitung eines Projekts

• Projektplanung

• Durchführen eines Projekts

• Unterstützende Tätigkeiten

• Soft Factors

• Wirtschaftliche Aspekte



• Motivation

• Tätigkeiten bei der SW-Entwicklung

• Diese Tätigkeiten im Kontext von Vorgehensmodellen

• Stufen

AGENDA



• Motivation



• Stufen

AGENDA



Ziel dieser Einheit ist, den Studierenden den Inhalt von SW-Projekten und

dessen Implikationen auf das Projektmanagement zu vermitteln.

Ziele der Vorlesungseinheit

Rahmen

• Fokus der Vorlesung liegt im BereichSoftware-Entwicklung. Das deckt auch Reengineering, Wartung und Weiterentwicklung in Projektform ab.

• Häufigster Fall von IT-Projekten

• Vorgehensweise und Erkenntnisse übertragbar auch auf andere Projekte.

Fragestellungen

• Wie gehe ich in meinem Projekt vor, um es zum Erfolg zu führen?

• Wie erreiche ich den Projekterfolg mit Sicherheit und nicht nur durch Zufall?



• Motivation



• Stufen

AGENDA

In Software-Entwicklunsprojekten finden sich immer die gleichen

Tätigkeiten wieder.

Elementare Tätigkeiten in Software-Entwicklungsprojekten



Anforderungs-

analyse

& Fachliche

Konzeption

Technische

Konzeption

Realisierung Integration

und Test

In jedem Softwareentwicklungsprojekt finden sich vier grundlegende

Tätigkeiten.

Überblick über die Tätigkeiten



Tätigkeit

Anforderungsanalyse & Fachliche Konzeption

Technische Konzeption

Realisierung

Integration & Test

Kurzbeschreibung/Fragen

• Was soll das System inhaltlich tun?

• Welche Anforderungen soll es erfüllen?

• Wie sieht die fachliche Lösung aus?

• Wie sieht die technische Lösung aus?

• Wie soll das System programmiert werden?

• Erzeugen von Code

• Zusammenfügen mit Nachbarsystemen

• Funktionaler Gesamttest

Anforderungsanalyse und Fachliche Konzeption sind schwer zu trennen.

Details zur Anforderungsanalyse & Fachlicher Konzeption



Tätigkeit



Realisierung

Integration & Test

Hinweise

• Anforderungsanalyse und Fachliche

Konzeption sind oft nicht zu trennen.

• Ergebnisse

– Anforderungen (funktional und nicht-

funktional)

– Fachliche Beschreibung der Lösung

– Prozesse

– Use Cases (durch Software

unterstützte Prozess-Schritte)

– Fachliches Datenmodell

– Fachlicher Sytemüberblick innen und

außen, Fachliche Architektur

Anforderungsanalyse und Fachliche Konzeption bilden die Grundlage der

Softwareentwicklung.

Details zur Technischen Konzeption



Tätigkeit



Realisierung

Integration & Test

Hinweise

• Inhalte der Technischen Konzeption

– Technischer Systemüberblick innen

und außen

– Software-Architektur (Module,

Schichten, Komponenten, etc.)

– Technisches Datenmodell

– Systemarchitektur (Hardware)

– Betriebsdokumentation

– Vorlage für die Implementierung,

Design für Implementierung

In der Realisierung wird das System programmiert.

Details zur Realisierung



Tätigkeit



Realisierung

Integration & Test

Hinweise

• Inhalte der Realisierung

– Programmieren

– Testen (Entwicklertest)

– Dokumentieren

• Ergebnisse

– Code

– Dokumentation

Integration und Test bereiten das System auf die Inbetriebnahme vor.

Details zu Integration und Test



Tätigkeit



Realisierung

Integration & Test

Hinweise

• Ergebnis:

– Fertiges System

• Inhalte von Integration & Test

– Systemintegration: Kopplung mit

Nachbarsystemen, Zusammenführen

einzelner Module System ist „als

Ganzes“ vollständig.

– Systemtest (gesamt, funktional):

Fachliche Tester testen das System

so, wie es später im

Produktionsbetrieb genutzt werden

soll.

Die grundlegenden Tätigkeiten der Software-Erstellung werden oft

unterschiedlich bezeichnet.

Synonyme zu den eingeführten Begriffen



• Die Begriffe des Software Engineering sind (leider) nicht genormt. Sowohl die Inhalte als auch die Bezeichnungen der Schritte können variieren.

• Häufig werden alternative Namen genutzt.

Anforderungsanalyse & Fachliche Konzeption Requirements analysis, Analysis, Analyse, Fachkonzept, Spezifikation, Lastenheft, Pflichtenheft,

Technische Konzeption DV-Konzept, Konstruktion, Design, Pflichtenheft. Definition

Realisierung Implementierung, Programmierung

Integration & Test Systemintegration, Gesamtintegration

Unzureichende Standardisierung

Wie verhalten sich die Kosten für Fehlerbehebung in Relation zum

Zeitpunkt im Projekt, an dem sie gefunden werden?

Fragestellung



Quelle: B. Boehm, sd&m Konferenz 2001

?

Die Kosten zur Fehlerbehandlung steigen sehr stark an, wenn die Fehler

erst spät gefunden werden.

Antwort



Quelle: B. Boehm, sd&m Konferenz 2001



• Motivation



• Stufen

AGENDA

Im Wasserfall-Vorgehen sind die Tätigkeiten sequentiell angeordnet.

Schematisches Wasserfall-Vorgehen



Fach. Konzeption

Tech. Konzeption

Realisierung

Test & Integration

nach Winston W. Royce 1970

Projektstart Ziel

Der Wasserfall ist ein einfaches und robustes Vorgehen, das Probleme

bei Änderungen der Anforderungen erzeugt.

Beschreibung und Bewertung des Wasserfall-Vorgehens



• Alle Schritte werden sequentiell durchgeführt

• Mit einem Schritt wird erst dann begonnen, wenn der vorige Schritt fertig ist, d. h. das Ergebnis der vorigen Phase vorliegt.

Wasserfall

• Einfach zu verstehen

• Einfach zu managen

• Einfach zu controllen (Definierte Phasenübergänge)

Vorteile

• Was tun, wenn sich Anforderungen ändern?

Nachteil

Im Wasserfall-Vorgehen mit Rückkopplung sind Rücksprünge möglich.

Schematisches Wasserfall-Vorgehen mit Rückkopplung



Fach. Konzeption

Tech. Konzeption

Realisierung

Test & Integration

Projektstart Ziel

nach B. Boehm 1981

Aber: Was tun, wenn sich Anforderungen ändern? keine wirklich gute Antwort

Ein Ausweg aus dem Dilemma ist, die Projekte so zu beschleunigen, dass

es zu weniger ungeplanten Änderungsanforderungen kommt.

Reaktionsmöglichkeiten auf Änderungsanforderungen



Änderungs- anforderung

Abblocken

Annehmen und in Software einbauen, im Projekt einplanen

Schneller im Projekt sein. Dadurch gibt es weniger Zeit für Änderungen in den Anforderungen

Iterative Verfahren wiederholen die Schritte mehrfach

Schema für ein iteratives Vorgehen



• Die Kette der Tätigkeiten

wird iteriert, bis das

Projektziel erreicht ist.

In der Projektabwicklung erzeugt ein iteratives Verfahren eine Sequenz

von Aktivitäten

Sequenz der Aktivitäten in der Projektabwicklung



Fach. Konz.

Tech. Konz

Rea Test & Int. Fach.

Konz. Tech. Konz

Rea Test & Int.

Fach. Konz.

Tech. Konz

Rea Test & Int.

Zeit

Ein evolutionäres Verfahren wiederholt bei jeder Iteration eine Fachliche

Konzeption

Sequenz der Aktivitäten bei evolutionärem Vorgehen



Fach. Konz.

Tech. Konz

Rea Test & Int. Fach.

Konz. Tech. Konz

Rea Test & Int.

Fach. Konz.

Tech. Konz

Rea Test & Int.

Zeit • Fragestellung: Wann erreiche ich mein Ziel? Was ist dann

überhaupt mein Ziel?

• Zeit? Kosten? Leistungsumfang?

Ein inkrementelles Verfahren lässt keine wesentlichen Änderungen in der

Fachlichkeit mehr zu.

Sequenz der Aktivitäten bei inkrementellen Vorgehen



Zeit

Fach. Konz.

Tech. Konz

Rea Test & Int.

Tech. Konz

Rea Test & Int.

Tech. Konz

Rea Test & Int.

Evolutionäres und inkrementelles Vorgehen unterscheidet sich in der

Festlegung, welches Ergebnis im Projekt erreicht werden soll.

Gegenüberstellung evolutionär und inkrementell



• Anforderungsanalyse und Fachliche Konzeption pro Iteration

evolutionär

• Anforderungsanalyse, Konzeption, konkretes Festlegen der Ziele nur zu Beginn

• Jede Iteration erzeugt ein weiteres Stück der Lösung

• Schneller zu ersten Ergebnissen, aber immer noch anfällig gegen Änderung der Anforderungen

inkrementell

Grundlegender Konflikt: Flexibilität gegen garantierte Zielerreichung.

Prototyping ist eine Technik zur Verbesserung der Anforderungsanalyse

und fachlichen Konzeption.

Vorstellung Prototyping und typische Stolpersteine



Grundideen

• Ergänzender Schritt, bzw. konkrete Ausgestaltung von „Anforderungsanalyse & fachliche Konzeption“

• Bau eines Prototypen, der einen Eindruck der zu erstellenden Software vermittelt.

• Besseres Verständnis für Auftraggeber und Auftragnehmer

• Besseres Feedback

• Prototyp wird nach der Konzeption weggeworfen

• Kosten für Prototyp müssen erbracht werden.

• Prototyp wird nicht weggeworfen.

Stolpersteine

Prototyping kann sinnvoll durch Tools unterstützt werden

Beispiel für Tooleinsatz: Balsamic MockUps



Hinweise

• Es gibt verschiedenste Tools in unterschiedlichen Preisklassen

• Tools beschleunigen die Erstellung von Prototypen

• Dem Eindruck, dass die Software schon fast fertig ist, kann durch einen „Sketchy-Look“ entgegengewirkt werden

Das Spiralmodell wurde 1988 von B. Boehm entwickelt.

Spiralmodell



Das Spiralmodell hat vor allem Bedeutung als Wegbereiter für iterative

Ansätze.

Hinweise zum Spiralmodell



• Beschreibt einen iterativen Prozess

• Wichtiger Aspekt: Risikominimierung

• Iteratives Durchlaufen der Phasen in einer Spirale

– Ziele bestimmen, Alternativen, Zusammenhänge

– Alternativen analysieren, Risken identifizieren und bewerten

– Entwickeln, verifizieren

– Nächste Phase planen

• „Flächeninhalt“ der Spirale repräsentiert Kosten

• Bewertung

– Akademische Sicht auf iterative Entwicklung

Der Rational Unified Process hat in den letzten Jahren zunehmend an

Bedeutung gewonnen.

Überblicksdiagramm RUP



Aufsetzen Ausarbeiten Bauen Einführen

Der Rational Unified Process ist ein Prozessmodell

Charakteristika des RUP



• Merkmale

– Prozessmodell. Definition: Ein Prozessmodell legt umfassend

fest:

- Phasen und deren Aktivitäten

- Produkte auch Zwischenprodukte

- Rollen (KVQ - Kompetenzen, Verantwortlichkeiten,

Qualifikationen)

- Methoden, Werkzeuge, Standards, Richtlinien

• Iterativ, objektorientiert

• Im Ursprung eine enge Verknüpfung mit den Produkten der

Firma Rational, heute IBM

• Bewertung

– An vielen Stellen etabliert, zumindest dem Namen nach

Das V-Modell hat im öffentlichen Bereich eine große Bedeutung.

Überblick über Elemente des V-Modells



Das V-Modell definiert Entscheidungspunkte, deren Ablauf angepasst

werden kann (Tailoring)

Entscheidungspunkte des V-Modells



Projektabgeschlossen

Projektbeauftragt

Abnahmeerfolgt

Anforderungenfestgelegt

Systemelementerealisiert

Änderungsplanfestgelegt

Projektgenehmigt

Projektausgeschrieben

Angebotabgegeben

Systemspezifiziert

Systementworfen

Feinentwurfabgeschlossen

Systemintegriert

Lieferungdurchgeführt

VerbesserungVorgehensmodell konzipiert

VerbesserungVorgehensmodell realisiert

Vorgehensmodellanalysiert

Projektdefiniert

Systementwicklungsprojekt eines

Auftraggebers

Systementwicklungsprojekt eines

Auftragnehmers

Einführung und Pflege eines

organisationsspezifischen

Vorgehensmodells

Zuordnung der

Entscheidungspunkte zu

Projekttypen

Die Entscheidungspunkte bei der Systemerstellung haben paarweise

Gegenstücke.

Entscheidungspunkte bei der Systemerstellung



Das V-Modell XT ermöglicht eine projektspezifische Ausplanung der

Projektdurchführungsstrategie

Beispielhaftes Tailoring



Agiles Manifest (Feb 2001)

Das agile Manifest fordert eine Orientierung auf die Werte hinter den

Formalismen der Softwareentwicklung.

© 2010 Capgemini – All rights reserved 37

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge

• Funktionierende Programme sind wichtiger als ausführliche Dokumentation.

• Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen.

• Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans.

In wie weit ist das neu oder einfach nur gesunder Menschenverstand?

eXtreme Programming ist ein agiles Verfahren, das weniger

Dokumentenbasiert ist.

eXtreme Programming und späte Projektphasen



Gedankenspiel

Boehm hat nicht recht: Moderne Software-Entwicklungsumgebungen und Sprachen machen den Umbau der Software billiger. Konzeptpflege und -aktualisierung ist aufwändig

Merkmale des eXtreme Programming sind kleine Releases, ständiges

Refactoring und qualitätsverbessernde Programmiertechniken

Wichtige Merkmale des XP-Ansatzes



Merkmale von XP

• XP arbeitet mit kleinen Releases, unterteilt in Iterationen und Arbeitspakete.

• Anforderungsanalyse: Aufgaben und Anforderungen in Form von Stories

• Beschränkung auf wenige Anforderungen pro Iteration, Programmierung in kleinen Releases

• Pair Programming: Zwei Personen vor einem Rechner, einer programmiert, der andere ist Sparringspartner

• Kontinuierliches Refactoring

• Umfangreiche Unit-Tests: Voraussetzung für Refactoring. Produkt für Java: JUnit

eXtreme Programming hat viele Vorzüge, wird aber wegen der schlechten

Planbarkeit relativ selten eingesetzt.

Bewertung des XP-Ansatzes



Bewertung von XP

• Technologie-Getrieben: Refactoring Ansatz erfordert entsprechende Programmiersprache und Technologien

• Refactoring ist für fachliche Anforderungen möglich, nicht aber für Architekturänderungen.

• Beruht auf der Annahme, dass Code-Umbau billig ist (im Gegensatz zu Boehm)

• explorativ: Anforderungen dürfen sich ändern

• Auftraggeber wird besser mit eingebunden, kann konkrete Ergebnisse sehen

• Enthält Elemente des Prototyping, allerdings ohne Wegwerfen

• Kostenabschätzung vorab nicht möglich

Scrum ist ein iteratives Verfahren, in dem Erkenntnisse aus klassischen

Produktionsprozessen in die Softwareerstellung übertragen worden sind.

Grundsätzliches zu Scrum



• 1987: Ikujiro Nonaka and Hirotaka Takeuchi

• 1991: Ken Schwaber, Jeff Sutherland und Mike Beedle

• Aus Produktionsprozessen, Stichwort: „Lean Production“

Wurzeln

• Agiles Verfahren

• Software wird in ca. monatlichen Iterationen entwickelt „Sprint“

• Das Entwicklungsteam organisiert sich selbst macht kleine, tägliche Iterationen

• Genau eine Person vertritt die Anforderungsseite

• Präzise vorgegebener Rahmen mit Rollenbeschreibungen, Prozessen und Artefakten

Grundideen

• Übernimmt Organisation von Product Owner und Team, damit diese ungestört arbeiten können.

• Greift nicht inhaltlich ein: kein Tech-Guru, ist nicht der Product Owner

Scrum Master

• Organisiert sich selbst

• Setzt die Anforderungen um

• Richtgröße 7 ± 2

Team

• Genau 1 Person

• Vertritt die Fachseite, Anforderungen

• Ist für die fachliche Tragfähigkeit des Ergebnisses verantwortlich

Product Owner

Es gibt drei zentrale Rollen in Scrum mit festen Aufgabenbereichen

Rollen in Scrum



Das Vorgehen in Scrum ist als Rahmen sehr genau vorgegeben.

Beschreibung des iterativen Vorgehens in Sprints



Sprint

Tägliche Iteration

• Die Software wird in Sprints entwickelt.

• Dauer ca. 1 Monat ± 1-2 Wochen

• Während eines Sprints sind keine Änderungen „Change Requests“ möglich.

• Ergebnis ist ein potentiell nutzbares Produkt.

• Ablauf:

• Zu Beginn Sprint Planung: Festlegen des Ziels und der Anforderungen, die im Sprint umgesetzt werden sollen

• Sprint wird in täglichen Iterationen umgesetzt

• Am Ende Review: Produkt wird getestet, typischerweise Demo

• Sprint Retrospektive: Identifizieren von Prozessverbesserungen

Vorgehen

Weitere Artefakte

Die Artefakte in Scrum sind – genau wie der Prozess –

präzise vorgegeben.

Artefakte in Scrum



• Anforderungen

• Priorisierung

Anforderungen in Backlogs

Product Backlog: alle Anforderungen an die Software

Selected Backlog: Anforderungen für einen Sprint

Sprint Backlog: Anforderungen in Ein-Tages-Häppchen

Impediment Backlog: Hindernisse in der Softwareentwicklung, werden durch Srcum Master beiseite geräumt.

Burndown-Chart: Grafische Darstellung der Restaufwände

Scrum findet gerade für kleinere Projekte zunehmend Verbreitung.

Bewertung von Scrum



• Stellt einen Mittelweg zwischen inkrementellen und explorativen Ansätzen dar: Anforderungen dürfen sich ändern, aber nicht innerhalb der Sprints

• Findet zunehmend Verbreitung, insbesondere für kleinere Projekte

• Gutes Beispiel dafür, dass „agil“ nicht „chaotisch“ heißt: gibt einen festen Rahmen für ein Projekt vor

• Umgeht Probleme in der Anforderungsanalyse, indem genau eine Person als Product Owner vorgegeben wird. Löst damit nicht das Problem, wie aus widersprüchlichen Anforderungen verschiedener Personen eine gemeinsame Lösung entsteht.

• Setzt intensive Mitarbeit des Product Owners voraus.

Bewertung



• Motivation



• Stufen

AGENDA

Die Wahl des geeigneten Vorgehens hat eine zentrale Rolle für die

Projektdurchführung

Entscheidung zwischen den Modellen



Fachliche Konzeption


Realisierung

Test & Integration

Beide Vorgehensmodelle haben ihre Stärken

Bewertung der Vorgehensmodelle



• Hohe Sicherheit für Software-Anbieter

• Gesamtblick (aber: zu viele Details)

• Unüberschaubare Konzeptpapiere

• Geringere Flexibilität, aber Change-Request-Verfahren

• Nutzen erst bei Einführung

• „Deckel drauf bekommen“

• Einfache Struktur, QS zwischen Phasen

• Entspricht Denkweise: Geld für definierte Leistung

• Fachliche Konzepte können „die Vorstellungskraft sprengen“

Wasserfall Iterativ

• Früher Nutzen für Kunden

• Besseres, qualifizierteres Feedback

• Kosten für Übergangslösungen

• Schwieriger zu managen

• Geringeres Einführungsrisiko

Stufen bilden einen Mittelweg zwischen den Extremen

Rolle von Stufen



Fachliche Konzeption


Realisierung

Test & Integration

Stufen

Wasserfall schlecht

Inkrementell Chaos

Die optimale Stufenzahl muss für jedes Projekt festgelegt werden.

Gegenüberstellung von Stufung und Stichtagsumstellung



Bereich der optimalen Stufenzahl

Kosten: Provisorien, Mehrfachtest, etc.

Einführungsrisiko *

* Erwartungswert des Schadens bei Systemausfall

(ge

sch

ätz

te)

Ko

ste

n

Anzahl Einführungsstufen

Bei größeren Aufgaben ist ein gestuftes Vorgehen empfehlenswert.

Motivation für ein gestuftes Vorgehen



Stufung

• Wasserfall als Vorgehen stößt an Grenzen

• Große Projekte werden handhabbar

• Stufen verringern das Risiko

• Fachliches Risiko

• Technisches Risiko

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

• Widerstände für eine Stufung müssen überwunden werden: Management-Aufgabe

Der Ablauf eines gestuften Projekts ist oft verschränkt.

Beispiel für gestuften Projektablauf



Studie & Grobanalyse

T&I FK TK R Stufe 1

Stufe 2

Stufe 3

T&I FK TK R

T&I FK TK R

Stufen können nach festen Kriterien identifiziert werden.

Kriterien für Stufen



• Unabhängig einführbar

– Fachlich

– Technisch

• Das Ergebnis einer Stufe kann produktiv gestellt werden.

• Nutzen stiften

– Fachlichen Nutzen stiften

– Technische Sicherheit gewinnen - Schwieriges zuerst

– Organisatorische Sicherheit gewinnen

• Schrittweiser Aufbau von Technologien

• Fachlichkeit ist größter Hebel zur Stufenbildung

• In der ersten Stufe wird i. d. R. die technologische Basis

geschaffen

Fallbeispiele zeigen die Anwendbarkeit von Stufungen in Projekten

Fallbeispiele für Stufen



• Buchungssystem

– Zu Beginn keine Stufung identifiziert

– Fachliche Stufung: zunächst Buchungen für eine Region

• Portalanwendung

– technisch/fachliche Stufung: zunächst Minimalausstattung

technische Infrastruktur

– fachlich: erst eine Applikation komplett entwickelt, andere nur

Integriert Provisorium wurde permanente Lösung

• Data Warehouse

– fachliche Stufen nach Kundenkreisen

Stufen sollten zu Beginn eines Projekts identifiziert werden, ggf. auch

nach der Fachlichen Konzeption.

Hinweise zur Bildung von Stufen im Projekt



• Bei Aufsetzen des Projekts

– Immer den Umfang des Projekts im Auge behalten

– Bei größerem Umfang Stufung versuchen

- Umfang niemals unterschätzen!

• Nach Fachkonzeption oder Studie

– Zusätzlicher Schnittpunkt für Stufenbildung (fachlich)

• Indizien für zu großen Projektumfang

– Umfang der Konzeptpapiere: größer als 200 Seiten?

– Feedback der Reviewer/externen Beteiligten: wirken sie noch

mit, lesen sie die Papiere?

Das Projektmodell bei Capgemini CSD Deutschland entspricht dem RUP-

Modell

Beispiel: Projektmodell bei Capgemini CSD Deutschland



Stufen und Stufentypen

• Entwicklung erfolgt in Stufen

• T-Stufe: Schwerpunkt ist technische Verifikation und Schaffung der technischen Grundlagen

• A-Stufe: Schwerpunkt ist fachliche Anwendung

Jede Stufe hat 5 Phasen

Ausgestaltung der Stufen

• Stufenmuster für T- und A-Stufen aus der Projektpraxis

t

Anforderungen des Kunden

Abnahme

Produktion

Anforderungsmanagement & Änderungsverfahren

Querschnitt (PM, QM, CD, etc.)

A-Stufe

R. Release

Systemerstellung

A-Stufe

T-Stufe

Spezifikation

Konstruktion

Realisierung

Integration

Initia

lisie

rung

Das Vorgehen innerhalb der Stufe richtet sich nach dem Projekt.

Beispiele für Vorgehen innerhalb einer Stufe



Inkrementelles Vorgehen

Verzahntes Wasserfallmodell

Inkrementell mit Vorspezifikation

• Ist Spezialfall einer Stufe mit nur einem Inkrement

• Funktionsumfang früh definiert und weitgehend fix

Motivation / Einsatz Besonderheiten

• Mischform der beiden obigen Modelle

• Schwerpunkt ab zweitem Inkrement auf Realisierung (weniger Konstruktion)

• Frühes Feedback durch schnell lauffähiges Teilsystem

• Schrittweises Verfeinern

• Gesamtspezifikation zu Beginn der Stufe

• Gesamtaufwand leichter planbar als bei inkrementellem Vorgehen

• Kleines Projekt • Klarer, überschaubarer

Funktionsumfang • Frühe

Gesamtspezifikation erforderlich

• Schnelle Ergebnisse & schnelles Lernen – auch bei komplexer Funktionalität

• Risiko reduzieren durch „Wichtigstes zuerst“

Spezifikation

Konstruktion

Realisierung

Integration

Initia

lisie

rung

Spezifikation

Konstruktion

Realisierung

Initia

lisie

rung

Integration

Spezifikation

Konstruktion

Realisierung

Integration

…

Konstruktion

Realisierung

Initia

lisie

rung

Integration Spezifik

ation

…

Konstruktion

Realisierung

Integration

Vielen Dank für Ihre Aufmerksamkeit!

www.capgemini.com

IT-Projektmanagement - Der Gegenstand von...

Documents

Transcript of IT-Projektmanagement - Der Gegenstand von...