Unified Process (UP), Rational UP (RUP)

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!} 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 Architekturvorschlagzuerst: 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 • 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. Projektidee Prerequirements Projektnebenbedingungen Business Model Supplementary Requirements [Pre] Feature List Requirements Use-Case Model User InterfacePrototype 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} UP Test Model Test Plan

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 DeploymentDiagramm 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 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:

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

39. Folge von Requirements Artefakten im UP 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. UP