Unified Process (UP), Rational UP (RUP)

Präsentation zum Thema: "Unified Process (UP), Rational UP (RUP)"—  Präsentation transkript:

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, Anm: SW-technische Sicht W. Royce: „Software Project Management; A Unified Framework“; Addison Wesley, Anm: PM-Sicht Rational UP (RUP): Rational Suite Enterprise 2000; 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: Überblick
Skizze zu den 5 Workflows und 4 Projektphasen im UP ü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 List 2. Business or Domain Model 3. First Cut of a.    Use-Case Model b.    Analysis Model c.    Design Model 4. Optional: Implementation/Test model 5. 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
Exekutierbare Software Alle Modelle (Artefakte) des Systems Aktualisierte Architekturbeschreibung Vorläufiges Benutzerhandbuch, das für das Beta-Testen ausreichend ist Projektplan für die Transition-Phase 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
Exekutierbare Software inkl. Installationssoftware Alle gesetzlichen Verträge und vereinbarten Dokumente Product Release Baseline inkl. aller Modelle Alle Manuals (f. Benutzer, Operator, Systemadministrator, ...) und Trainingsmaterial 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 driven
Darstellung der Abhängigkeiten div. Modelle vom Use-Case Modell (andere 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 & inkrementell
Mit Ausnahme der ersten (beiden) und der letzten, durchläuft jede Iteration alle Workflows und resultiert in einem (exekutierbaren) Inkrement zum System! “Miniprojekt” Skizze einer Iteration: UP

30 Unified Process: 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 Deployment Model [Impl]
Projektidee Prerequirements Projektnebenbedingungen Business Model Supplementary Requirements [Pre] Feature List Requirements Use-Case Model User Interface Prototype Supplementary Requirements [Req] Glossary [Req] Analysis Analysis Model Supplementary Requirements [Anal] Glossary [Anal] Design Design Model Supplementary Requirements [Des] Behavior Model Deployment Model [Des] Glossary [Des] Implementation ImplementationModel Deployment Model [Impl] Glossary [Impl] Integration Build Plan Test {input from all models} Test Model UP Test Plan

32 “Prerequirements” betrifft nur die erste Iteration.
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 Inhalt des 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 Inhalt Test Modell
Weitere Artefakte: Test Plan Test Ergebnisse und Evaluierung 1 Test System Test Model * * * x x Test Case Test Procedure Test Component UP

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

36 Management Workflow – Business Case
Kontext (Unternehmen, Markt, Bereich,...) Technisches Vorgehen Plan zur Erfüllung der Features (Anforderungen) Qualitätsplan Engineering trade-off und Risiken technischer Art Management Vorgehen Div. Pläne, insbes. Plan zum Umgang mit Risiken Objektive Erfolgsmaßstäbe Evolutionär fortgeschriebene Anhänge: Finanzen: Kosten, Rücklauf, Basis der Schätzung UP

37 Management Workflow – SW-Entwicklungsplan
Kontext (Bereich, Ziele, Abgrenzung) SW-Prozessmodell: Phasen, Artefakte, Workflows, Meilensteine, ... Software Engineering Environment Software Change Management Software Assessment: Metriken, Risikenmanageent, Kontrollaspekte, Akzeptanztestplan, ... Standards und Richtlinien Evolutionär fortgeschriebene Anhänge: Humanressourcen, Schulung, Meilensteine,... UP

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

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 Benutzer Systemarchitekten System Ingenieure Entwickler Wartungspersonal Qualitätssicherungspersonal, Auftraggeber, Sponsoren, Subcontractors, Verkaufsfachleute,... Durchführung: (Kontinuum zwischen Varianten) als eine fortlaufende Sitzung aller Beteiligten; als inkrementeller, on-line Review einzelner Artefakte. UP