Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

UP1 Unified Process (UP), Rational UP (RUP) Prozessmodell passend zu UML und teils in UML spezifiziert; sehr mächtiges Prozessframework; baut auf den best.

Ähnliche Präsentationen


Präsentation zum Thema: "UP1 Unified Process (UP), Rational UP (RUP) Prozessmodell passend zu UML und teils in UML spezifiziert; sehr mächtiges Prozessframework; baut auf den best."—  Präsentation transkript:

1 UP1 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;

2 UP2 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)

3 UP3 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.

4 UP4 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,...

5 UP5 Einschub: Engineering versus Produktion – Ausrichtungen {werden im UP verfeinert!} LIFE-CYCLE ASPEKTENGINEERING AUSRICHTUNG PRODUKTION AUSRICHTUNG Risiko ReduktionZeitplan, technische Machbarkeit Kosten ProdukteArchitektur BaselineProdukt Release Baseline AktivitätenAnalyse, Design, Planung Implementierung, Testen AssessmentDemonstration, Inspektion, Analyse Testen ÖkonomieDiskussion im Bereich von Größenordnungen Ausnützen ökonom. Größenordnungen ManagementPlanungOperation

6 UP6 Unified Process: Überblick Skizze zu den 5 Workflows und 4 Projektphasen im UP überlagert dazu: Management Workflow

7 UP7 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))

8 UP8 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.

9 UP9 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 InceptionElaboration Construction Transition LCO LCA IOC PRM

10 UP10 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?

11 UP11 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

12 UP12 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

13 UP13 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?

14 UP14 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.

15 UP15 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

16 UP16 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

17 UP17 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

18 UP18 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?

19 UP19 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.

20 UP20 Unified Process: Projektphase Construction - Artefakte 1.Exekutierbare Software 2.Alle Modelle (Artefakte) des Systems 3.Aktualisierte Architekturbeschreibung 4.Vorläufiges Benutzerhandbuch, das für das Beta-Testen ausreichend ist 5.Projektplan für die Transition-Phase 6.Business Case, die Situation zu Ende der Phase reflektierend.

21 UP21 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?

22 UP22 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,...

23 UP23 Unified Process: Projektphase Transition - Artefakte 1.Exekutierbare Software inkl. Installationssoftware 2.Alle gesetzlichen Verträge und vereinbarten Dokumente 3.Product Release Baseline inkl. aller Modelle 4.Alle Manuals (f. Benutzer, Operator, Systemadministrator,...) und Trainingsmaterial 5.Referenzen zu weiterführenden Informatioen und Bunutzersupport

24 UP24 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?

25 UP25 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

26 UP26 UP-Charakteristikum: Use-Case driven Darstellung der Abhängigkeiten div. Modelle vom Use-Case Modell (andere Abhängigkeiten sind in der Abb. vernachlässigt)

27 UP27 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

28 UP28 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.

29 UP29 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:

30 UP30 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

31 UP31 Prerequirements Analysis Design Implementation Test {input from all models} ProjektnebenbedingungenProjektidee Requirements Business Model Feature List Supplementary Requirements [Pre] Supplementary Requirements [Req] Supplementary Requirements [Anal] Supplementary Requirements [Des] Use-Case Model Glossary [Req] User Interface Prototype Analysis Model Glossary [Anal] Design Model Glossary [Des] Implementation Model Test Plan Deployment Model [Des] Behavior Model Glossary [Impl] Integration Build Plan Deployment Model [Impl] Test Model

32 UP32 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

33 UP33 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

34 UP34 weiteres Beispiel: UP-Artefakte: Struktur und Inhalt Test Modell Weitere Artefakte: Test Plan Test Ergebnisse und Evaluierung 1 Test Model Test System x x Test CaseTest ProcedureTest Component * **

35 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 CaseStatus Assessments – Fortschrittskontrolle Software Entwicklungsplan (Prozessplan) Änderungsauftrags- verwaltungssystem Release Spezifikationen (Bereich, Versionsplan, Ziele) Deploymentdokumente – Schulung, Verkauf, Installation,... Umgebung – Voraussetzungen, Vogaben

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

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

38 38 Folge von Management Artefakten im UP DokumentInceptionElaborationConstructionTransition WBS ^ ^ ^ Business Case ^ ^ ^ Release Spec. [^] ^ ^ ^ ^ ^ SW Dev. Plan ^ ^ Release Desc. [^] [^] ^ ^ ^ ^ ^ Status Assess. [^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^] SW change d. ^ ^ ^ ^ Depl. doc. [^] ^ Environment [^] ^ ^

39 UP39 Folge von Requirements Artefakten im UP Requirements Document InceptionElaborationConstructionTransition Vision document ^ ^ ^ Requirements models; [Architecture description] ^ [^] ^

40 UP40 Meilensteine Major Milestones: am Ende jeder Phase Minor Milestones: am Ende jeder Iteration Verschiedene Beteiligte haben verschiedene Blickwinkel und Interessensbereiche: KundenBenutzer SystemarchitektenSystem Ingenieure EntwicklerWartungspersonal Qualitätssicherungspersonal, Auftraggeber, Sponsoren, Subcontractors, Verkaufsfachleute,... Durchführung: (Kontinuum zwischen Varianten) –als eine fortlaufende Sitzung aller Beteiligten; –als inkrementeller, on-line Review einzelner Artefakte.


Herunterladen ppt "UP1 Unified Process (UP), Rational UP (RUP) Prozessmodell passend zu UML und teils in UML spezifiziert; sehr mächtiges Prozessframework; baut auf den best."

Ähnliche Präsentationen


Google-Anzeigen