Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E nergiesysteme MuSofT LE 3.2-2 Prozessmodelle Prozessmodelle Inhalt

MuSofT LE 3.2-2 Prozessmodelle

Universität Stuttgart W

isse

nsv

erar

be

itu

ng

un

d N

um

erik

Institut für Kernenergetikund Energiesysteme

Prozessmodelle

Inhalt Prozessmodell im Management

Prozess Was leisten PM Wasserfall-Modell Iterativ inkrementelles Vorgehen Beispiel für iterativ inkrementelles

Vorgehen: der RUP Beispiel für Koppelung von SE

Entwicklung mit QS und PM: das V-Modell

Weitere Prozessmodelle Verbesserung des SE Prozesses

am Beispiel des Capability

Maturity Modell

P-Modell/2


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Struktur der Einheit Prozessmodelle in LO‘s

Inhalt + Learning Object StructureGO EinleitungGO Prozessmodell im Management ProzessGO Was leisten Prozessmodelle

Wasserfall-Modell RUP kurz V-Modell kurz Sonstige

GO Verbesserung des SE Prozesses - (CCM kurz)GO Abspann

P-Modell/3


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vorbemerkung

Prozessmodelle - häufig auch Vorgehensmodelle genannt - haben zum Ziel, den Prozess der Entwicklung von Softwaresystemen zu strukturieren und planbar zu machen. Sie bilden damit die Grundlage des prozessorientierten Qualitätsmanagements. Durch Tayloring kann aus einem Prozessmodell der organisatorische Rahmen der Softwareentwicklung innerhalb eines konkreten Projektes entwickelt werden. Anhand des Wasserfallmodells werden die grundlegenden Festlegungen eingeführt (Aktivitäten, Produkte einschliesslich Layout und Qualitätskriterien, Qualifikationen, Rollen und Entwicklungsumgebung). Es werden die Schwächen des Phasenmodells aufgezeigt und alternative Modelle skizziert.

P-Modell/4


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Das sollten Sie heute lernen

P-Modell/5


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Was ist ein Softwareentwicklungsprozess?

– Eine Menge von Tätigkeiten, die die Entwicklung der Software als Ziel

haben

– Allgemeine Tätigkeiten in allen Softwareprozessen sind:

Spezifikation - Was das System können muss unter gegebenen

Entwicklungsbedingungen

Entwicklung - Produktion des Softwaresystems

Validierung - Testen, ob die Software das macht, was der Kunde

wollte

Wartung - Änderungen der Software in Antwort auf die

Änderungswünsche

P-Modell/6


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Software-Entwicklungsprozess - Ziele

Alle Elemente eines Systementwurfs sind in einem Repository erfaßt und damit quantitativ definiert. Sie bilden die Grundlage für die Aufwandskalkulation, stehen über festgelegte Strukturen in Beziehung zueinander und können in mehreren Projekten verwendet werden.

Alle Systementwürfe und -dokumente beziehen sich begrifflich auf diese Elemente mit einheitlichen Schreibweisen und konsistenten Begriffen - inklusive der an der Benutzeroberfläche (Masken, Listen, Belege) verwendeten Bezeichnungen.

Es besteht jederzeit Transparenz darüber, wo welche Elemente auftreten beziehungsweise benutzt werden. Die Beschreibung referenzierter Objekte ist direkt abrufbar.

Die Entwürfe werden automatisch formalen Plausibilitätsregeln unterworfen. Die Definitionen sind eins zu eins die Basis für Texte in Benutzerdokumenten

und Online-Help-Systemen.

P-Modell/7


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Was leisten Prozessmodelle - 1

Software Erstellungsprozess wird transparent Vergabe von Zielen, Wegen, Mitteln, Aufgaben, Rollen

Software Erstellung wird überprüfbar Erfüllung der Aufgabe Erreichung der Ziele Aufdeckung von Risiken Beurteilung des Projektfortschrittes

Management von Ressourcen wird möglich Kosten Zeit Personen

Erfahrungen werden gesammelt und wiederverwendbar Tailoring von Workflows Best Practice Effekt

P-Modell/8


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Was leisten Prozessmodelle - 2

Prozessmodelle strukturieren den Vorgang der Software Erstellung Definieren Aktivitäten Legen deren Ergebnisse fest Geben Empfehlungen für die Abarbeitung der Aktivitäten

Prozessmodelle müssen daher für jedes Projekt für jedes Projektteam

ausgewählt und angepasst werden. Das in einem konkreten Projekt verwendete Prozessmodell

charakterisiert die Komplexität und den Lösungsansatz im Projekt Die Instanzierung des Prozessmodelles spiegelt die

Entwicklungskultur eines Software Unternehmens wieder

P-Modell/9


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Prozess-Qualität in der Softwareentwicklung

Niedrige ProzeßqualitätImprovisierter, ad hoc-Prozeß

Reaktion bei Problemen

Kosten- und Terminpläne werden im allgemeinen nicht eingehalten

Qualitäts- und Funktionsreduktion bei Terminproblemen

QS-Aktivitäten werden bei Terminproblemen nicht durchgeführt

Hohe ProzeßqualitätProfessionell durchgeführter Prozeß

Vermeiden von Problemen

Bessere Planung durch geeignete Prozeßverfahren

Probleme werden frühzeitig erkannt und behoben

Der Prozess wird kontinuierlich verbessert

Die Verbesserung der Prozeßqualität erfordert ein Ziel (Prozeßwahl), die Erhebung des Istzustandes (Audit oder Assessment) und die Auswahl von Schritten zur Annäherung des Istzustandes an das Ziel.

P-Modell/10


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Software Entwicklungsprozess - häufige Fehler

Auf ein Datenmodell wird im fachlichen Entwurf verzichtet Systeme und ihre Funktionen werden nicht über ein Repository

sondern direkt als Word-Dokument beschrieben. Für Funktions- und Maskenabläufe werden, wenn überhaupt

vorhanden, bunte Folien etwa über Powerpoint erstellt. Die zum System gehörenden Teile werden erst in der technischen

Umsetzung eindeutig beschrieben und vielleicht bei Projektende nachdokumentiert.

Dokumente werden in uneinheitlichen Formaten, Ablagemedien und -strukturen verwaltet.

Es gibt kaum qualitätssichernde Prüfungen.

P-Modell/11


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Zeitliche Zerlegung Software-Lebenszyklus

Phase Ergebnis1. Problemanalyse - Pflichtenheft

2. Programmentwurf - Spezifikation

3. Programmierung - Programm

4. Testprogramm - Testbericht des AuftragNehmer

5. Abnahme - Abnahmebericht

6. Verifikation - Erfahrungsbericht des AuftragGeber

7. Wartung - Fortschreibung aller Berichte

P-Modell/12


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Aufgaben von Lebenszyklusmodellen

Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen:

Definition der Tätigkeiten im Entwicklungsprojekt

Zusicherung von Konsistenz zwischen einzelnen Projekten

Schaffung von Kontrollpunkten für das Management

Lebenszyklusmodelle gliedern eine Gesamtaufgabe in Teilaktivitäten, denen Methoden und Personen zugeordnet werden

Die Aktivitäten können Phasen zugeordnet sein.

P-Modell/13


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Aufgaben in den einzelnen Phasen

In allen Phasen ergeben sich phasenspezifische und Aktivitäten genereller Art

Zielfestlegung für die Phase Bestimmung von Alternativen Bestimmung von Restriktionen Risikobewertung

P-Modell/14


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Was macht eine Phase aus ?

Personen Methoden

Eingangs-daten

ErgebnisseAktivität

Zeit

P-Modell/15


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Definition von Phasen

Eine einzelne Phase ist durch folgende Kriterien definiert:

Abgeschlossene Teilaufgabe (Zeit, Umfang) definierte Eingangsdaten definiertes Ergebnis involvierter Personenkreis benutzte Methoden

P-Modell/16


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Typische Projektaktivitäten

Analyse Design Umsetzung Inbetriebnahme Wartung

P-Modell/17


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Kategorisierung

Lebenszyklusmodelle können nach unterschiedlichen Kriterien kategorisiert werden:

Art und Inhalt der Phasen Beziehungen zwischen den Phasen Anordnung der Phasen Betrachteter Projektumfang

P-Modell/18


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Phasenbeziehung und -anordnung

Phasen können in unterschiedlicher Weise miteinander in Beziehung stehen und angeordnet sein:

Streng sequentiell mit Einfluss auf zurückliegende Phasen sich wiederholend mit oder ohne Überlappung

P-Modell/19


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Kritik am Modell Lebenszyklus

ErfahrungDie Behebung von Fehlern ist umso schwieriger, je früher sie im Lebenszyklus-Modell entstanden ist.

Kritik am LebenszyklusmodellZu starrer Ablauf,

zu wenig Wechselwirkung zwischen Phasen,

zu unflexibel bei

Fehlern,

Änderungen.

Kaum Möglichkeiten für

Überspringen von Phasen,

Überarbeitung früherer Phasen,

inkrementelle Erweiterung.

P-Modell/20


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel: Wasserfallmodell als einfaches Phasenmodell

Voraussetzungen: Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) Bekannte Technologien und Verfahren

Analyse

Design

Kodierung

Test

Produkte:• Spezifikation• Entwurf• Programm•Abnahmebericht

Aktivitäten

P-Modell/21


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Wasserfallmodell

Vorteile: Klare Aufgaben in jeder Phase „relativ einfach“ Genaue Planung bei geringem Overhead

Nachteile: Rückkehr in eine frühere Phase ist aufwendig Probleme werden erst spät erkannt

Gut geeignet für kleine Projekte und StandardprojekteUngeeignet für Neuentwicklungen komplexer Systeme

P-Modell/22


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Eigenschaften des Wasserfallmodells

Eigenschaften:

Grundlegendes Modell für andere Modelle Ergebnisse einer Phase gehen in nächste

Phase über kein Einfluss auf vorherige Phasen (nur bei

Fehlern) Phasen müssen jeweils vollständig

abgeschlossen werden

P-Modell/23


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vor- und Nachteile des Wasserfallmodells

Das Wasserfallmodell hat durch seine Einfachheit

diverse Vorteile: Überschaubare Aufteilung der Gesamtaufgabe Verfügbarkeit von Zwischenergebnisse fester Lösungsweg

Nachteile sind dafür: Keine Berücksichtigung überlappender Aktivitäten Beschränkung der Rückkopplung auf den Fehlerfall große Systeme nicht vollständig vorplanbar kein Einfluss des Benutzers

P-Modell/24


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Das Prototyp-Modell nach Yourdon

Discuss initial requirements with user

Develop prototype

Demonstrate prototype to user

Prototype acceptable ?

Formal analysis

Formal design

Formal code, test, etc.

yes

Revise prototypeno

P-Modell/25


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Das Spiralenmodell

Jede Spirale

Analyse - Entwurf - Alternativen - Prototyp

Grobentwurf

Feinentwurf

Durchführung

P-Modell/26


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Prototyping

Prototyping soll folgende Probleme lösen helfen: Häufige Änderungen während des Projektes bewirken

Rückkopplung und Berichtigungen Benutzereinfluss selten gegeben keine Möglichkeit der Überprüfung des Designs in

frühen Phasen

Dies soll durch Einsatz von Prototypen erreicht werden, die schnell entwickelt werden können, aber nur teilweise funktionsfähig sind

P-Modell/27


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Arten des Prototyping

Es existieren unterschiedliche Arten des Prototyping:

horizontal/ Realisierung einzelner vertikal: Schichten bzw. einzelner

Funktionalitäten

explorativ: Frühe Präzisierung von Anwender-wünschen

experimentell: Überprüfung des Lösungskonzepts auf Softwareebene

evolutionär: Permanente Adaption, keine Trennung von Wartung und Entwicklung

P-Modell/28


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Methoden des Prototyping

Möglichkeiten

Rohfassung ohne Qualitätssicherung

Hohe Programmiersprache (LISP mit ADT-Liste)

Datenbanksprache (4GL-Werkzeug)

Werkzeugsystem (UNIX mit YACC, LEX, AWK, ...)

Wiederverwendbare Software (OOPS)

Diese Liste kann erweitert werden.

Prototypart Wegwerf

inkrementell

evolutionär

P-Modell/29


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Bewertung von Prototyping

Der Einsatz von Prototyping lässt sich wie folgt beurteilen:

Sinnvolle Ergänzung zu allen Lebenszyklus-modellen

unterstützt wichtige Wiederverwendung von Ideen und Konzepten

Benutzeranforderungen müssen trotzdem festgehalten werden

P-Modell/30


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Weitere Prozessmodelle - Definitionen

Spiralmodell Eine Softwareentwicklung durchläuft mehrmals einen aus vier Schritten bestehenden Zyklus mit dem Ziel, frühzeitig Risiken zu erkennen und zu vermeiden. Pro Zyklus kann dann ein Prozess-Modell oder eine Kombination von Prozess-Modellen zur Erstellung eines Teilprodukts oder einer Ebene eines Teilprodukts festgelegt werden.

Prototypen-Modell Frühzeitige Erstellung ablauffähiger Modelle (Prototypen) des zukünftigen Produkts zur Überprüfung von Ideen oder zum Experimentieren.

V-Modell Ein um die Aktivitäten Verifikation und Validation erweitertes Wasserfallmodell, ursprünglich für eingebet-tete, militärische Entwicklungen vorgesehen. Inzwischen gibt es in Deutschland eine Weiterentwicklung, die auch andere Anwendungsklassen abdeckt (V-Modell 97 erweitert in Richtung Objektorientierung).

P-Modell/31


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Weitere Prozessmodelle - Eigenschaften

Prozess- Primäres Antreibendes Benutzer- CharacteristikaModell Ziel Moment beteiligung

Wasserfall- minimaler Dokumente gering sequentiell,modell Management- volle Breite

aufwand

Spiralmodell Risiko- Risiko mittel Entscheidung prominimierung Zyklus über

weiteres Vorgehen

Prototypen- Risiko- Code hoch nur TeilsystemeModell minimierung (horizontal

oder vertikal)

V-Modell maximale Dokumente gering sequentiell,Qualität volle Breite,(safe-to- Validation,market) Verifikation

Diesen Prozessmodellen liegt im Wesentlichen das Paradigma der strukturierten Methoden zu Grunde. Die Objektorientierung wird erst durch neuere Modelle adäquat unterstützt. Dazu gehören das V-Modell-97 und der hier weiter vorgestellte Rational Unified Process

P-Modell/32


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Rational Unified Process (RUP) - Definitionen

Dem Rational Unified Process (RUP) liegt ein best practice objektorientiertes Modell zu Grunde. Der RUP definiert sich über Workflows, die parallel und in Phasen ablaufen. Innerhalb jeder Phase sind Iterationen und inkrementelle Verbesserungen möglich.

Zur Definition der Workflows stehen im RUP eine Reihe von Hilfsmitteln zur Verfügung (Schlüsselkonzepte), die miteinander wechselwirken. Zum Beispiel werden Aktivitäten von Workers erbracht, die dadurch Artefakte produzieren. Zur Gestaltung der Artefakte werden Guidelines und Templates zur Verfügung gestellt.

P-Modell/33


isse

nsv

erar

be

itu

ng

un

d N

um

erik



RUP- Phasen

Der RUP kennt 4 Phasen Konzeptionalisierung Entwurf Konstruktion + Realisierung Einführung + Betrieb

Die Definitionen aller verfügbaren Phasen finden Sie über den Index (Glossary) des RUP-Handbuch oder wenn Sie auf der Einführungsseite Phasen aktivieren

P-Modell/34


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vorgehensmodelle verbinden Prozess- und Qualitäts- Management

Anforderungs-definition

Grobentwurf

Feinentwurf

Modul-implementation

Modultest

Integrationstest

Systemtest

AbnahmetestAnwendungsszenarien

Testfälle

Testfälle

Testfälle

Validierung

Verifikation

P-Modell/35


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vorgehensmodelle -2

Das V-Modell in seiner ursprünglichen Fassung war eine Erweiterung des Wasserfall-Modells. Es integriert die Qualitätssicherung in das Wasserfall-Modell. Die Verifikation und Validation der Teilprodukte sind Bestandteile des V-Modells.

Unter Verifikation wird die Überprüfung der Übereinstimmung zwischen einem Software-Produkt und seiner Spezifikation verstanden.

Unter Validation wird die Eignung bzw. der Wert eines Produktes bezogen auf seinen Einsatzzweck verstanden. (Prüfung ob Modell adäquat)

Das V-Modell wurde zunächst für die Bundeswehr und anschließend für Behröden entwickelt.

P-Modell/36


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Verbesserung der Prozeßqualität: Ansätze und Ziele

QM-Systeme Assessment

Statische Ansätze zurVerbesserung der

Prozeßqualität

ISO 9000-3Erreichung der

nächsten Reifegradstufe

PrinzipienForderungen an Prozesse

TQMBusiness

Engineering

Audit SPICE CMM

Quelle: Banford, R.C., Deibler II W.J., Comparing, contrasting ISO 9001 and the SEI capability maturity model, in: Computer, Oct. 1993, pp. 68-70.

P-Modell/37


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Prozeßstruktur des ISO 9001/9004 Prozeßmodells

Anforderung Aktivitäten Erfüllung

Die neuen Normen sind vor allem Kunden- und Prozess-orientiert

ProduktVerantwortung

RessourcenVerwaltung

Produktrealisierung

QM zur ProduktVerbesserung

P-Modell/38


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Diese Fragen sollten Sie jetzt beantworten können

P-Modell/39


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Links

P-Modell/40


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Literatur

P-Modell/41


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Quellen

P-Modell/42


isse

nsv

erar

be

itu

ng

un

d N

um

erik




QUALITY MANAGEMENT SYSTEM CONTINUAL IMPROVEMENT OF THE

Managementresponsibility

Resourcemanagement

Value addingInformation

Legend:

Measurement,analysis andimprovement

CUSTOMER

Requirements

Satisfaction

CUSTOMER

Productrealization

Input Output

Product

Die neuen Normen sind vor allem Kunden- und Prozess-orientiert


P-Modell/43


isse

nsv

erar

be

itu

ng

un

d N

um

erik




Intertested Parties

Measurement Analysis and Improvement

ResourceManagement

Requirements

Input Output

Continual Improvement of the Quality Management System

Product Realization

Product

Interested Parties

Satisfaction

Management Responsibility


P-Modell/44


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Anhang: Software Projekte nach dem Unified Process

Aufgaben des Managements

Planung und Überwachung

Phasen und Iterationen

Planung eines Projektes - ein pragmatischer Ansatz

P-Modell/45


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Motivation

Softwaresysteme gehören zu den komplexesten

Gebilden, die von Menschen geschaffen wurden

Software ist meist einzigartig unterschiedliche Randbedingungen Integration von Altlasten Schneller technologischer Wandel Änderung der Anforderungen der Anwender Unterschiedliche Fähigkeiten der Mitarbeiter

P-Modell/46


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Aufgaben des Managements (1)

Planung und Überwachung

- Pläne erstellen und verfolgen

- Auswertung von Informationen

- Risikomanagement

Führung und Steuerung

- Kommunikation der Projektziele

- Setzen von Schwerpunkten

- Entscheidungen treffen

P-Modell/47


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Aufgaben des Managements (2)

Teamaufbau- Teambildung / Teamarbeit

- Langfristige Bindung guter Mitarbeiter

- Weiterbildung

- Mitarbeitermotivation

Sonstiges- Bereitstellung der Arbeitsumgebung

- Koordination mit Alltagsgeschäft und anderen Projekten

P-Modell/48


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Planung und Überwachung: Vorgehensmodelle

Sequentielle Modelle- Wasserfallmodell

- Phasenmodell

Iterative-inkrementelle Modelle- Spiralenmodell

- Booch-Methode

- OOSE

- Unified Process

P-Modell/49


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Planung und Überwachung: Wasserfallmodell (1)

Voraussetzungen: Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) Bekannte Technologien und Verfahren

Analyse

Design

Kodierung

Test

P-Modell/50


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Planung und Überwachung: Wasserfallmodell (2)

Vorteile: Klare Aufgaben in jeder Phase „relativ einfach“ Genaue Planung bei geringem Overhead

Nachteile: Rückkehr in eine frühere Phase ist aufwendig Probleme werden erst spät erkannt

Gut geeignet für kleine Projekte und StandardprojekteUngeeignet für Neuentwicklungen

P-Modell/51


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Planung und Überwachung:

Iterative-Inkrementelle Vorgehensmodelle (1)

Annahmen: Anforderungen sind unvollständig wichtige Erkenntnisse werden erst im Laufe des Projektes gewonnen

Analyse

Design

Kodierung

Test

Analyse

Design

Kodierung

Test

Iteration 1

Iteration 2

Iteration N

P-Modell/52


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Planung und Überwachung:

Iterative-Inkrementelle Vorgehensmodelle (2)

Geeignet für Projekte mit Unwägbarkeiten

Inkrementell - Verbesserung in Breite iterativ - Verbesserung in Tiefe

Vorteile: Evolutionäre SW-Entwicklung (Iterationsende: Programm) Reaktion auf Änderungen und Unvorhergesehenes einfacher Feinere Steuerung möglich

Nachteile: scheinbar mehr Aufwand Schwierigere Umsetzung

P-Modell/53


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Planung und Überwachung: Wasserfall vs. Iterative Modelle

Wasserfallmodell:- einfacher umzusetzen

- geeignet für Projekte mit bekannten Verfahren in einem stabilen Umfeld

Iterative-Inkrementelle Modelle- Flexibel

- Probleme werden frühzeitig erkannt

- Nach jeder Iteration steht ein Produkt, das ggf. ausgeliefert werden könnte

- Erlaubt schnelle Reaktion auf Unvorhergesehenes

P-Modell/54


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Phasen und Iteratioen

Konzeption Entwurf Konstruktion Einführung

VorläufigeIterationen

Iteration#1

Iteration#2...

Iteration#n

Iteration#n+1...

Iteration#m+1...

Iteration#m

Managementsicht

Technische Sicht

Jede Phase endetmit einem Meilenstein

Jede Iteration endetmit einem ausführbarenProdukt

P-Modell/55


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Phasen und Iterationen:Gesamtplanung des Projektes

Was soll geplant werden? Grobe Festlegung der Phasen und Iterationen

- Meilensteine

- Aufwandsschätzung und Terminplanung

Feinplanung mit Aufwandsabschätzung (nur) der nächsten Iteration

Wer plant? Projektleiter Architekt ggf. weitere Fachleute

P-Modell/56


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Phasen und Iterationen:Vorbereitungs- (Konzept-)phase

Ziel: Planungs- und Entscheidungsgrundlagen schaffen

Aufgaben: Vorstudie zur Machbarkeit erstellen Definition des Projektzieles und Abgrenzung Erarbeitung, Bewertung, Empfehlung und Entscheidung über

Realisierungsalternativen Überblick über Problembereich und Anforderungen Grobe Projektplanung (Iterationen etc.) Identifizierung der Projektrisiken

P-Modell/57


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Phasen und Iterationen: Entwurfsphase

Ziel: Erfassung der wichtigsten funktionalen und nichtfunktionalen

Anforderungen Validierte, stabile und ausführbare Software-Architektur

Aufgaben: Entwicklung von Systemteilen mit hoher Priorität und hohem

Risiko Use Case-Modell erstellen (Anforderungsanalyse) Festlegung der Anwendungsarchitektur Feinplanung der jeweiligen Iteration erstellen

P-Modell/58


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vorplanung von Projekten: Besetzung der Rollen

Alle als projektnotwendig identifizierte Rollen müssen mit geeignet qualifiziertem Personal besetzt werden

Eine Person kann gleichzeitig mehrere Rollen übernehmen Ggf. muß benötigtes Know-How durch Weiterbildung geschaffen

oder zugekauft werden Besetzung der Rollen kann Aufwände bis zu einem Faktor 10

variieren lassen oder Projekte sogar ganz zum Scheitern bringen

P-Modell/59


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Bewährtes Mischmodell

Anforderungsanalyse

Grobdesign,Komponentenbildung

Iterativ inkrementelleEntwicklung

Systemtest undEinführung

P-Modell/60


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Anforderungsanalyse

Detaillierte Analyse des fachlichen Feinkonzepts Grobentwurf von Use Cases Workshops mit Fachexperten und Systemanalytikern

- Detaillierung der Use Cases

- Akteure identifizieren (wer hat welche Aufgaben, Kompetenzen)

- Erstellung eines Glossars der Fachbegriffe

- Priorisierung der Use Cases

- Ggf. erste Dialogentwürfe Aktivitätsmodellierung

- Konkretisierung der Anforderungen

- Übergang zum Design (wie soll das System arbeiten) Identifizierung von Lösungsalternativen, Evaluierung und Empfehlung

geeigneter Lösungen Planung des weiteren Vorgehens

P-Modell/61


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Grobdesign und Komponentenbildung

Modellierung von Geschäftsklassen und fachlichen Klassen Identifikation von Subsystemen und Komponenten Detaillierung der Systemarchitektur Entwicklung eines Prototypen zur Verifizierung der Architektur Planung der iterativ inkrementellen Komponentenentwicklung

P-Modell/62


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Releaseplanung

Releaseplanung- Wieviel Iterationen ?

- Reihenfolge der Komponenten (-ausbaustufen)

-- riskante Komponenten,

-- hoch priorisierte Komponenten und

-- Basiskomponenten zuerst

- Richtwert für Iterationsdauer: 6 bis 8 Wochen

Bildung von Teilprojekten/Teams

P-Modell/63


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Iterativ, inkrementelle Komponentenentwicklung

Detailplanung der bevorstehenden Iteration Komponentenspezifisch:

- Analyse

- Design

- Realisierung

- Test

Regelmäßige Integration zum Gesamtsystem (z.B. wöchentlich) Regelmäßiges Kundenreview (z.B. alle zwei Iterationen)

(nimmt mit Anzahl der Iterationen ab)

P-Modell/64


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Systemtest und Einführung

Teilabnahmen können bereits während der Projektlaufzeit auf Basis von Subsystemen erfolgen, sofern diese unab-hängig voneinander getestet und abgenommen werden können.

Planung und Durchführung des Rollouts Parallele Inbetriebnahme des neuen IMIS Test und Abnahme des Gesamtsystems

P-Modell/65


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Aufgaben des Auftraggebers

Grobdesign, Komponentenbildung

___________________

Klärung speziellerDetailfragen

Anforderungsanalyse___________________

Detaillierung Use CasesVerifizierung v. Modellen

Iterativ inkrementelleEntwicklung

___________________

Review von Teilergebnissen

Systemtest undEinführung

___________________

Test und Abnahme

Documents

Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E nergiesysteme MuSofT LE 3.2-2 Prozessmodelle Prozessmodelle Inhalt