Post on 05-Apr-2015
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Das sollten Sie heute lernen
P-Modell/5
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Was macht eine Phase aus ?
Personen Methoden
Eingangs-daten
ErgebnisseAktivität
Zeit
P-Modell/15
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Typische Projektaktivitäten
Analyse Design Umsetzung Inbetriebnahme Wartung
P-Modell/17
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Das Spiralenmodell
Jede Spirale
Analyse - Entwurf - Alternativen - Prototyp
Grobentwurf
Feinentwurf
Durchführung
P-Modell/26
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Diese Fragen sollten Sie jetzt beantworten können
P-Modell/39
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Links
P-Modell/40
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Literatur
P-Modell/41
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Quellen
P-Modell/42
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Prozeßstruktur des ISO 9001/9004 Prozeßmodells
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
Anforderung Aktivitäten Erfüllung
P-Modell/43
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Prozeßstruktur des ISO 9001/9004 Prozeßmodells
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
Anforderung Aktivitäten Erfüllung
P-Modell/44
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Planung und Überwachung: Vorgehensmodelle
Sequentielle Modelle- Wasserfallmodell
- Phasenmodell
Iterative-inkrementelle Modelle- Spiralenmodell
- Booch-Methode
- OOSE
- Unified Process
P-Modell/49
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
Bewährtes Mischmodell
Anforderungsanalyse
Grobdesign,Komponentenbildung
Iterativ inkrementelleEntwicklung
Systemtest undEinführung
P-Modell/60
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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
Universität Stuttgart W
isse
nsv
erar
be
itu
ng
un
d N
um
erik
Institut für Kernenergetikund Energiesysteme
MuSofT LE 3.2-2 Prozessmodelle
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