UP 1
Unified Process (UP), Rational UP (RUP) Prozessmodell passend zu UML und teils in UML
spezifiziert; sehr mächtiges Prozessframework; baut auf den “best practices“ der SW-Entwicklung
als auch des Managements von IT-Projekten auf; Literatur, Tool zu RUP: z.B.:
I. Jacobson et al.: “The Unified Software Development Process“ Addison Wesley, 1999. Anm: SW-technische Sicht
W. Royce: „Software Project Management; A Unified Framework“; Addison Wesley, 1998. Anm: PM-Sicht
Rational UP (RUP): Rational Suite Enterprise 2000; http://www.rational.com/UML
UP 2
Unified Software Development Proceess
• Ziel: Grober Überblick zum Unified Process aus management Sicht, basierend auf software-technischer Sicht
• Schwerpunkte: Erklärung der - Grundsätze:
- Use-Case driven- Architecture centric- Iterative and incremental
- Phasen und wesentlichen Meilensteine- Tätigkeitsfolgen der (“workflows“) und- Dokumente (“artifacts“)
UP 3
SW Entwicklungsprozeß – Definition und Anforderungen
• Ein Softwareentwicklungsprozess umfasst eine Menge von Aktivitäten, die notwendig sind, um die Anforderungen der Benutzer (und Auftraggeber) in ein Software System zu transformieren.
• Anforderungen an ein Prozessmodell:– Regelt die Aktivitäten eines Teams und deren
Anordnung.– Leitet die Aufgaben einzelner Entwickler und des
Teams.– Spezifiziert welche Artefakte (Dokumente) zu erstellen
sind.– Bietet Kriterien zur Bewertung der Aktivitäten und
Produkte eines Projektes.
UP 4
Unified Process
• Allgemeines zum Unified Process:– Umfassendes, generisches Framework – Soll für den Spezialfall angepasst werden– Orientiert sich eng am Spirallen-Lebenszyklusmodell– Das Zielsystem wird komponentenweise entwickelt– Der Prozess ist in UML (mit Erweiterungen) beschrieben
Annahme: für die Modellierung wird UML eingesetzt– Beinhaltet Aspekte des Projektmanagements, z. B.:
• Aktivitäten werden Entwicklerrollen (Workers) zugeschrieben• Projektantrag, Projektauftrag, Entwicklungsplanung angesprochen• Meilensteine und Projektfortschrittskontrolle angesprochen• Der Entwicklungsablauf ist auf die Minimierung der Risiken des
Projektes ausgerichtet, ...
UP 5
Einschub: Engineering versus Produktion – Ausrichtungen {werden im UP verfeinert!}
LIFE-CYCLE ASPEKT ENGINEERING AUSRICHTUNG
PRODUKTION
AUSRICHTUNG
Risiko Reduktion Zeitplan, technische Machbarkeit
Kosten
Produkte Architektur Baseline Produkt Release Baseline
Aktivitäten Analyse, Design, Planung
Implementierung, Testen
Assessment Demonstration, Inspektion, Analyse
Testen
Ökonomie Diskussion im Bereich von Größenordnungen
Ausnützen ökonom. Größenordnungen
Management Planung Operation
UP 6
Unified Process: ÜberblickUnified Process: Überblick
Skizze zu den 5 Workflows und 4 Projektphasen im UPSkizze zu den 5 Workflows und 4 Projektphasen im UPüberlagert dazu: Management Workflowüberlagert dazu: Management Workflow
UP 7
Unified Process: Kommentar zum Überblick
• Jeder Workflow (eig. Entwicklungsphase) umfasst eine Anordnung von Aktivitäten zur Erstellung von Artefakten.– Beispiel: Der Requirements Workflow resultiert im Use-
Case Modell, einem Data Dictionary einer Liste nichtfunktionaler Anforderungen und einer Spezifikation der Benutzerschnittstelle.
• Jede Projektphase (z. B. “Elaboration“) hat spezielle Ziele und wird mit einem Meilenstein abgeschlossen (z.B. LCA (LifeCycle Architecture))
UP 8
Unified Process: Kommentar zum Überblick
• Projektphasen werden weiter durch Iterationen unterteilt. In jeder Iteration (ausser den ersten) werden ausgewählte Use-Cases (“Increments“) analysiert, entworfen, implementiert und getestet.
• Nach Abschluss jeder Iteration wird ein “minor Milestone“ gesetzt.
• Die “Güpfe“ im Diagramm skizzieren den (in etwa) je Projektphase und Workflow anfallenden Aufwand.
UP 9
Unified Process: wesentlichste Meilensteine
• Meilensteine dienen als Checkpoints im Prozess, sind am Ende einer Phase angesiedelt:
• LCO: Life-Cycle Objectives Milestone• LCA: Life-Cycle Architecture Milestone• IOC: Initial Operational Capability Milestone• PRM: Product Release Milestone• näheres siehe Ende des Abschnitts
Inception Elaboration Construction Transition
LCO LCA IOC PRM
UP 10
Unified Process: Projektphase “Inception“
• Ziele: – Umsetzung einer guten Idee in eine Vision über das
Endprodukt– Formulierung eines Projektantrags (siehe PRI I)
• Inhalt: beantwortet Fragen wie:– Was soll das System für jeden Benutzer bewerkstelligen?
Use-Case Modell mit den wesentlichsten Use-Cases.– Wie kann ein Architekturgerüst für das System aussehen?
Identifikation der wichtigsten Subsysteme.– Wie sieht ein grober Plan aus und in welchen Dimensionen
bewegen sich die Projektkosten? – Worin liegen Risiken in der Entwicklung und wie kann man
diese minimieren?
UP 11
Unified Process: Projektphase “Inception“ - Artefakte
1.Feature List2.Business or Domain Model3.First Cut of
• a. Use-Case Model• b. Analysis Model• c. Design Model
4.Optional: Implementation/Test model5.Supplementary requirements
UP 12
Unified Process: Projektphase “Inception“ – Artefakte (Fortsetzung)
6.First draft of candidate architecture description with views of individual models
7.Optional: proof-of -concept prototype
8.Initial risk list
9.Use-Case ranking list
10. Beginnings of a plan for the entire project
11. First draft of business case
UP 13
UP: Projektphase “Inception“ - Evaluierungskriterien
Stimmen alle Beteiligten zu Thema („Scope“), Kosten und Zeitabschätzungen zu?
Werden die Anforderungen verstanden? Sind die kritischen Use-Cases glaubhaft?
Kann man den Schätzungen zu Kosten, Prioritäten, Risiken, Entwicklungsprozessen vertrauen?
Wird Obiges durch den Architektur-Prototyp demonstriert?
Stehen die tatsächlichen Aufwände versus den geplanten in einem akzeptablen Verhältnis?
UP 14
Unified Process: Projektphase Elaboration
• Ziele:– Feststellung, dass das System - aufbauend auf dem
entworfenen Architekturskelett - auf ökonomische Art erstellt werden kann.
– Grundlage für die wichtigste Entscheidung im Projektverlauf, nämlich das System zu realisieren oder davon Abstand zu nehmen.
– Projektplan und Kostenschätzung• Durchläuft, wie alle Projektphasen, alle Workflows
mit eindeutigem Schwerpunkt auf Requirements und Design.
UP 15
Unified Process: Projektphase Elaboration
• Inhalte:– Spezifikation des Großteil der Use-Cases zur
Beschreibung der funktionalen und nicht funkt. Anforderungen.
– Festlegen der Systemarchitektur, “architectural views“ auf alle Modelle
– “Architectural baseline“ des Systems: exekutierbares Kernsystem, welches ca. 5-10% der Use-Cases implementiert
– Projektplan mit Details zur Projektphase Konstruktion (“Construction“)
– Projektauftrag mit Kostenschätzung
UP 16
Unified Process: Projektphase Elaboration - Artefakte
1. Preferably a complete business (or domain) model which describes the context of the system
2. New version of all models (complete between 10% - 80%):
- use-case- analysis- design- deployment, implementation
3. executable architectural baseline
UP 17
Unified Process: Projektphase Elaboration – Artefakte (Fortsetzung)
4.Architecture description
5.Updated risk list
6.Project plan for the construction and transition phases
7.Completed business case
UP 18
UP: Projektphase “Elaboration“ - Evaluierungskriterien
Ist die Vision (der Inception Phase) stabil? Ist die Architektur stabil?Zeigt die exekutierbare Demonstration, dass die
wesentlichsten Risiken “im Griff“ sind?Stimmen alle Beteiligten überein, dass die
momentane Vision erfüllt werden kann, wenn der vorliegende Plan, im Kontext der vorgeschlagenen Architektur, eingehalten wird?
Stehen die tatsächlichen Aufwände versus den geplanten in einem akzeptablen Verhältnis?
UP 19
Unified Process: Projektphase Construction
• Ziel: – Funktionsfähiges System, welches in der
Benutzerumgebung operiert.– Erstellt durch eine Serie von Iterationen, die
schrittweise Use-Cases implementieren (“increments”)
• Zustand:– Alle Use-Cases sind implementiert– System kann noch fehlerhaft sein– Minimale Änderungen der Systemarchitektur noch
möglich.
UP 20
Unified Process: Projektphase Construction - Artefakte
1. Exekutierbare Software2. Alle Modelle (Artefakte) des Systems3. Aktualisierte Architekturbeschreibung4. Vorläufiges Benutzerhandbuch, das für
das Beta-Testen ausreichend ist5. Projektplan für die Transition-Phase6. Business Case, die Situation zu Ende der
Phase reflektierend.
UP 21
UP: Projektphase “ Construction“ - Evaluierungskriterien
Ist die Produkt Baseline reif genug, im den Benutzern übergeben werden zu können?
Ist die Produkt Baseline stabil genug, im den Benutzern übergeben werden zu können?
Sind die Projektbeteiligten für die Transition bereit?
Stehen die tatsächlichen Aufwände versus den geplanten in einem akzeptablen Verhältnis?
UP 22
Unified Process: Projektphase Transition
• Ziel:– Erstellung des endgültigen Systems, welches allen
Anforderungen gerecht wird; “beta-Release”
• Tätigkeiten:– Fehlerkorrektur
– Modifizierung, um früher nicht erkannte Schwachstellen zu beseitigen
– Schulungen, hot-line Hilfestellung, Vermarktung,...
UP 23
Unified Process: Projektphase Transition - Artefakte
1. Exekutierbare Software inkl. Installationssoftware
2. Alle gesetzlichen Verträge und vereinbarten Dokumente
3. Product Release Baseline inkl. aller Modelle4. Alle Manuals (f. Benutzer, Operator,
Systemadministrator, ...) und Trainingsmaterial5. Referenzen zu weiterführenden Informatioen
und Bunutzersupport
UP 24
UP: Projektphase “ Transition“ - Evaluierungskriterien
Sind die Benutzer zufrieden?Nehmen die hineinkommenden Fehlerraten
ab?Stehen die tatsächlichen Aufwände versus
den geplanten in einem akzeptablen Verhältnis?
UP 25
UP-Charakteristikum: “Use-Case driven“
• Kernfrage: Was macht das System für jeden Aktor !• Das Use-Case Modell:
– Bietet eine Vorlage für alle weiteren Modelle
– Dirigiert den Prozess
– Bietet Rückverfolgbarkeit (traceability) zu den Anforderungen (und ggf. bis zum Business Model)
– Bietet Grundlage für die Systemarchitektur
– Beinhaltet nichtfunktionale Anforderungen
– Ermöglicht die unmittelbare Ableitung von Testfällen
UP 26
UP-Charakteristikum: Use-Case drivenUP-Charakteristikum: Use-Case driven
Darstellung der Abhängigkeiten div. Modelle vom Use-Case Modell (andere Darstellung der Abhängigkeiten div. Modelle vom Use-Case Modell (andere Abhängigkeiten sind in der Abb. vernachlässigt)Abhängigkeiten sind in der Abb. vernachlässigt)
UP 27
UP-Charakteristikum: architecture centric
• Architektur: zentrale Rolle in der Entwicklung– zu jedem Modell wird “architectural view” erstellt
• z.B.: 5-10% der Use-Cases sind architektonisch signifikant
• Strategie: Implementiere Grundgerüst und baue Funktionalität schrittweise auf
• Architektur im Projektverlauf:– Inception: erster Architekturvorschlag
zuerst: applikationsunahbängige Teile (meist Schichten)dann: applikationsabhängige Subsysteme
– Elaboration: “architectural baseline” wird implementiert(“small and skinny system to be filled with muscles”)
– Konstruktion: Stabilisierung der Architektur
UP 28
UP-Charakteristikum: iterativ & inkrementell
• Kernstrategie: Entwicklung in kleinen, durchsichtigen Schritten:– Plane ein wenig.– Spezifiziere, entwerfe und implementiere ein wenig.– Integriere, teste und exekutiere jede Iteration ein wenig.
• Motivation für “iterativ & inkrementell”:– Signifikante und kritische Risiken werden frühzeitig
berücksichtigt– Vorlage eines Architekturskelettes für die weitere Entwicklung– Bietet einen Rahmen, in dem (unausweichbare) Änderungen
der Anforderungen besser handhabbar sind– Schrittweise Erstellung des Systems macht den Fortschritt
evidenter.• Jede Projektphase umfasst eine oder mehrere Iterationen.
UP 29
UP-Charakteristikum: iterativ & inkrementellUP-Charakteristikum: iterativ & inkrementell
Mit Ausnahme der ersten (beiden) und der letzten, durchläuft Mit Ausnahme der ersten (beiden) und der letzten, durchläuft jede Iteration alle Workflows und resultiert in einem jede Iteration alle Workflows und resultiert in einem (exekutierbaren) Inkrement zum System! “Miniprojekt”(exekutierbaren) Inkrement zum System! “Miniprojekt”
Skizze einer Iteration:Skizze einer Iteration:
UP 30
Unified Process: Core Workflows
• Core Workflows: – Requirements, Analysis, Design, Implementation, Test– Management Workflow
• sind definiert durch:– Aktivitäten, insbesondere
• deren Input und Output in Form von Artefakten• deren Zuordnung zu Entwicklerrollen: “Workers”• deren Anordnung
– Artefakte, charakterisiert durch• Inhalt, genauer: Inhalt je Zustand, abhängig von Projektphase• Form, insbesondere UML Diagrammarten• views: Ausschnitte, z.B architectural view• trace-Beziehungen zu anderen Artefakten
UP 31
Prerequirements
Analysis
Design
Implementation
Test {input from all models}
ProjektnebenbedingungenProjektidee
Requirements
Business Model
Feature List
SupplementaryRequirements [Pre]
SupplementaryRequirements [Req]
SupplementaryRequirements [Anal]
SupplementaryRequirements [Des]
Use-Case Model
Glossary [Req]User InterfacePrototype
Analysis Model
Glossary [Anal]
Design Model
Glossary [Des]
ImplementationModel
Test Plan
Deployment Model [Des]
Behavior Model
Glossary [Impl] IntegrationBuild Plan
Deployment Model [Impl]
Test Model
UP 32
UP: Kommentar zum Aktivitätsdiagramm zu den Workflow-Aktivitäten & Artefakten; {Näheres s. Software Engineering I}
• “Prerequirements” betrifft nur die erste Iteration.• Die erste (die ersten beiden) Iterationen reichen nur in etwa
bis Design, es sei denn, ein rapid Prototype wird erstellt.• Die letzte Iteration beginnt in etwa bei Design• Business Model: Modell, welches die Entitäten und
Geschäftsabläufe in einem Unternehmen beschreibt.• Domain Model: beschreibt die Konzepte/Entitäten eines
Bereiches; statische Sicht, Abläufe werden nicht modelliert.• Das Vorhandensein eines Business Modells erleichtert die
Entwicklungsarbeit wesentlich, insbesondere die Ableitung der “System Use-Cases” aus den “Business Use-Cases”.
• Deployment Model: ist dargestellt als Deployment Diagramm
UP 33
Beispiel: Struktur und Inhaltdes Artefaktes: Use-Case Model ab Requirements WF
• Use-Case Modell:– Use-Case Diagramm mit Aktoren– Flow-of-events Beschreibung (Text) zu jedem
Use-Case• Normalszenario• Alternativszenarien
– Diagramm(e) mit Use-Case Beziehungen, (ggf. Packages)
– nicht-funktionale Anforderungen zu Use-Cases
UP 34
weiteres Beispiel: UP-Artefakte: Struktur und InhaltTest Modell
Weitere Artefakte:Test PlanTest Ergebnisse und Evaluierung
1
Test Model Test System
xx xx
Test Case Test Procedure Test Component
**
** **
35
Management Workflow• Nebenläufig zu den Core-Workflows
• Management Set an Artefakten:
betr. PLANUNG: betr. OPERATION:
Projektstruktur (AP, Finanzen)(work breakdown structure)
Release Beschreibungen
Business Case Status Assessments –Fortschrittskontrolle
Software Entwicklungsplan(Prozessplan)
Änderungsauftrags-verwaltungssystem
Release Spezifikationen(Bereich, Versionsplan, Ziele)
Deploymentdokumente –Schulung, Verkauf, Installation, ...
Umgebung – Voraussetzungen, Vogaben
UP 36
Management Workflow – Business Case
1. Kontext (Unternehmen, Markt, Bereich,...)2. Technisches Vorgehen
Plan zur Erfüllung der Features (Anforderungen)QualitätsplanEngineering trade-off und Risiken technischer Art
3. Management VorgehenDiv. Pläne, insbes. Plan zum Umgang mit RisikenObjektive Erfolgsmaßstäbe
4. Evolutionär fortgeschriebene Anhänge:Finanzen: Kosten, Rücklauf, Basis der Schätzung
UP 37
Management Workflow – SW-Entwicklungsplan
1. Kontext (Bereich, Ziele, Abgrenzung)2. SW-Prozessmodell: Phasen, Artefakte,
Workflows, Meilensteine, ...3. Software Engineering Environment4. Software Change Management5. Software Assessment: Metriken,
Risikenmanageent, Kontrollaspekte, Akzeptanztestplan, ...
6. Standards und Richtlinien7. Evolutionär fortgeschriebene Anhänge:
Humanressourcen, Schulung, Meilensteine,...
38
Folge von Management Artefakten im UP
Dokument Inception Elaboration Construction Transition
WBS ^ ^ ^
Business Case ^ ^ ^
Release Spec. [^] ^ ^ ^ ^ ^
SW Dev. Plan ^ ^
Release Desc. [^] [^] ^ ^ ^ ^ ^
Status Assess. [^
^ ^ ^ ^ ^ ^ ^ ^
^ ^ ^]
SW change d. ^ ^ ^ ^
Depl. doc. [^] [^] ^
Environment [^] ^ ^
UP 39
Folge von Requirements Artefakten im UP
RequirementsDocument
Inception Elaboration Construction Transition
Vision
document
^ ^ ^
Requirements
models;
[Architecture
description]
^
[^]
^
^
^
^
UP 40
Meilensteine
• Major Milestones: am Ende jeder Phase• Minor Milestones: am Ende jeder Iteration• Verschiedene Beteiligte haben verschiedene
Blickwinkel und Interessensbereiche:Kunden BenutzerSystemarchitekten System IngenieureEntwickler WartungspersonalQualitätssicherungspersonal, Auftraggeber, Sponsoren, Subcontractors, Verkaufsfachleute,...
• Durchführung: (Kontinuum zwischen Varianten)– als eine fortlaufende Sitzung aller Beteiligten;– als inkrementeller, on-line Review einzelner Artefakte.