3.4 Unified Process Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

Größe: px

Ab Seite anzeigen:

Download "3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process."

Alke Auttenberg
vor 8 Jahren
Abrufe

1 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes Vorgehensmodell zur Softwareentwicklung Anwendungsfälle (Use Cases) Architektur im Zentrum Inkrementelles Vorgehen

1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002

2 : Historie

3 Inkrementelles Vorgehen (Beispiel 2 Wochen It.) Montag: Verteilen und Klären der Aufgaben/Anforderungen 1 Person: reverse-engineering (code -> UML) Dienstag: Design am Whiteboard in Paaren (UML Diagramme, pseudo code, Design-Notizen) 8 Tage: Implementation, Testen, Design, Integration Tägliches System bauen, testen, stabilisieren Parallel: Demo, Evaluation, Planung der nächsten It.

-> UML) Dienstag: Design am Whiteboard in Paaren (UML Diagramme, pseudo code, Design-Notizen) 8

4 Eckdaten im Unified Process: Kein sofortiges Codes (Design-Phase) Keine langen, detaillierten Design-Phasen Ergebnis jeder Iteration ist ein ausführbares (unvollständiges) System Keine Entwicklung von Wegwerf-Prototypen Kein reaktiver feature -getriebener Prozess Viele kurze Iterationen (10-15, ~2-6 Wochen) Festes Zeitfenster für Iterationen Frühes Feedback des Anwenders

Entwicklung von Wegwerf-Prototypen Kein reaktiver feature -getriebener Prozess Viele kurze

5 Best Practices: Hohes Risiko und hoher Wert zuerst Kontinuierliches Feedback von Endnutzern Geschlossene Kernarchitektur zuerst Kontinuierliche Qualitätskontrollen Anwendung von Use-Cases Visuelle Softwaremodellierung (UML) Sorgfältige Verwaltung von Anforderungen Anforderungen managen

Kontinuierliche Qualitätskontrollen Anwendung von Use-Cases Visuelle

6 3.4 UP: Anforderungen managen Kategorisierung von Anforderungen (FURPS+): Functional Usability Reliability Performance Supportability Untergeordnete Faktoren (Randbedingungen): Implementation, Interface, Betrieb, Recht,...

Reliability Performance Supportability Untergeordnete

7 3.4 UP: Use-Cases Use-Case Modell: Aufschreiben von Anforderungen im Kontext (kein OO-Konzept). Typen: Kurzform: textuelle Zusammenfassung in einem Absatz. Freiform: informelle textuelle Beschreibung, die mehrere Szenarien umfasst. Vollform ( fully dressed ): Detaillierte Einzelschritte und Variationen, Akteure, Vorraussetzungen, und Erfolgskriterien

Freiform: informelle textuelle Beschreibung, die mehrere Szenarien umfasst.

8 3.4 UP: Use-Cases

9 3.4 UP: Visualisierung Beispiel Domänen-Modell: visuelles Wörterbuch der Begriffe und Abstraktionen (Konzepte) der Domäne (reale Welt) Objekte/Konzepte aus der Domäne besteht aus Symbol, Intention, Extension Assoziationen zwischen Konzepten need to know, auf Anforderungen achten! Attribute von Konzepten Meistens keine innere Struktur (sonst Konzept)

besteht aus Symbol, Intention, Extension Assoziationen zwischen Konzepten need to know,

10 3.4 UP: Visualisierung/Domänenmodell

11 3.4 UP: Visualisierung/Domänenmodell

12 3.4 UP: flexibles Design GRASP (General Responsibility Assignment Software Patterns/Principles) Objekt-Design: Definieren der Kommunikation zwischen Objekten, um die Anforderungen zu erfüllen. Ziel: Durch die Verwendung von Patterns (Entwurfsschablonen) Flexibilität bewahren und gemeinsame Metaphern etablieren.

Objekten, um die Anforderungen zu erfüllen.

13 Lifecycle des Unified Process Inception: Machbarkeit feststellen, grobe Vision, Umfang, Business Case (betriebswirtschaftliches Szenario) Elaboration: Verfeinerte Vision, Anforderungen, Umfang, Kernarchitektur, realistischer Aufwand Construction Umsetzung abschließen, Auslieferung vorbereiten Transition (beta-tests, Auslieferung)

Vision, Anforderungen, Umfang, Kernarchitektur, realistischer Aufwand Construction

14 development cycle iteration phase inc. elaboration construction transition milestone release increment final production release

15 UP Disciplines (Aktivitäten) Business Modeling Domänenmodell, Geschäftsprozesse Requirements Use Cases, (nicht)funktionale Anforderungen Design Architektur, Objekte, Kommunikation Implementation Programmierung, System bauen etc.

(nicht)funktionale Anforderungen Design Architektur,

17 Was Unified Process (UP) NICHT ist Denken, dass inception=anforderungen, elaboration=design, construction=implementation. Denken, dass der Zweck der Elaborationsphase der Entwurf präziser Modelle wäre. Versuch, alle Anforderungen vor Design und Implementierung zu definieren. Versuch, das Design vor der Implementierung festzulegen

Denken, dass der Zweck der Elaborationsphase der Entwurf präziser Modelle wäre.

18 Was Unified Process (UP) NICHT ist (Fortsetzung) Es wird eine lange Zeit für Anforderungen und Design (vor der Implementation) verwendet. Iterationen sind länger als 4 Monate. Denken, Programmierung wäre nur eine mechanische Umsetzung der Modelle. Denken, dass UP ein formaler, genau vorgegebener Prozess wäre. Versuch, ein Projekt von Anfang bis Ende im Vorraus zu planen (mit glaubwürdigen Schätzungen).

Denken, Programmierung wäre nur eine mechanische Umsetzung der Modelle.

Ähnliche Dokumente

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das