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.