Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Größe: px

Ab Seite anzeigen:

Download "Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)"

Nelly Kraus
vor 8 Jahren
Abrufe

1 Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent: Carlos Lenz / Fabian

Historisch Kulturelle Informationsverarbeitung

2 Gliederung I. Entstehungsgeschichte II. Der Unified Process III. Der Lebenszyklus des Unified Process IV.Anforderungs - Workflow V.Analyse - Workflow

3 I. Entstehungsgeschichte 1967 Ericsson, software engineering process 1987 Ivar Jacobson, Objectory 1999 schreiben Ivar Jacobson, Grady Booch und James Rumbaugh das Buch "Unified Software Development Process" Unified Software Development Process = Unified Process (UP)

Jacobson, Grady Booch und James Rumbaugh das Buch "Unified

4 I Entstehungsgeschichte Die UML wurde parallel dazu entwickelt Weiterentwicklung des UP ist der Rational Unified Process von IBM ABER: Dieses Referat ist über den Unified Process (UP)

5 II. Notwendigkeit des Unified Process (UP) Warum gibt es den UP überhaupt? Höhere Ansprüche an Softwaresysteme (z.b. SAP) von Seiten der User (Privatleute, Firmen etc.) und sie sollen schnell verfügbar und zuverlässig sein Anforderung => Entwicklung => Softwaresystem Der UP beschreibt und modelliert alle 3 Phasen, allerdings am stärksten die 2. Phase

SAP) von Seiten der User (Privatleute, Firmen etc.

6 II. Grundlagen des UP Der UP ist use-case-driven Use-cases sind Anforderungen der User an ein System z.b.: Abheben bei einem Bankautomaten, Tonartbestimmung bei einem Musikstück Von use-cases geht bei der Entwicklung alles aus. Klassen & Programme können / sollen schnell angepasst werden

: Abheben bei einem Bankautomaten, Tonartbestimmung bei einem

7 II. Grundlagen des UP Mehrere Use-Cases zusammen bilden ein sog. Use- Case-Model Es gibt zwei Arten von Use-Case-Models: Generelle Funktionsbeschreibung (normaler Ablauf) Optionale Funktionsbeschreibung (Abweichungen)

8 II. Architektur des UP Die Architektur eines UP besteht aus 3 Teilen: 1. Organisation der Anforderungen 2. Die Identifizierung von Subsystemen während des Entwurfs eines Systems 3. Was für eine Art von Architektur optimal ist für das zu entwickelnde System Die Architektur stellt das Gerüst dar, das mit Programmen und Interfaces gefüllt wird

Die Identifizierung von Subsystemen während des Entwurfs eines Systems 3.

9 II. Eigenschaften des UP Der Lebenszyklus des UP besteht aus 4-Phasen Die 4 Phasen bestehen aus n-iterationen Das sog. Inkrement bezeichnet in diesem Kontext die Größe in der sich die Iterationen und ihre einzelnen Workflows bewegen (grob / detailliert etc.)

Inkrement bezeichnet in diesem Kontext die Größe in der sich die

10 III. Der Lebenszyklus (LZ) des UP Der Lebenszyklus des UP besteht aus 4 Phasen

11 III. Die 4 Phasen Die 4 Phasen stellen den Lebenszyklus der Erschaffung eines Softwaresystems dar Phase 1: Beginn (Inception) Eine Idee wird zu einer Vision des fertigen Endproduktes, bestehend aus Anforderungen Fragen wie z.b. Was wird das System den Usern hauptsächlich bringen? werden beantwortet (Idealfall)

12 III. Die 4 Phasen Phase 2: Ausarbeitung (Elaboration) Die Architektur des Systems wird erdacht ( Skelett / baseline) Es wird versucht die Vision in kleinere use-cases aufzuteilen, um effektiver zu arbeiten Aus diesen use-cases kann der Projektleiter die konkreten Aufgaben an sein Team vergeben Entwicklungszeit wird geschätzt

use-cases aufzuteilen, um effektiver zu arbeiten Aus diesen use-cases kann der

13 III. Die 4 Phasen Phase 3: Konstruktion (Construction) Diese Phase beinhaltet nach der konzeptuellen Planung die tatsächliche Programmierung und Implementation Es können Fehler entdeckt werden, die dem Architekten mitgeteilt werden zur Verbesserung Erste Tests von Seiten der Mitarbeiter, damit eine Beta-Version den Usern gegeben werden kann

können Fehler entdeckt werden, die dem Architekten mitgeteilt werden zur Verbesserung

14 III. Die 4 Phasen Phase 4: Übergang (Transition) Beta-Releases werden veröffentlicht und getestet von Usern Fehler aus Sicht der User werden mitgeteilt zur weiteren Verbesserung des Systems

15 III. Zusammenfassung des LZ Der UP besitzt 4 Phasen, die den Lebenszyklus der Entwicklung für ein Softwaresystem darstellen (1:4) Bei den sog. Milestones wird das Ergebnis überprüft

16 III. Die Iterationen in einer Phase Alle 4 Phasen können aus mehreren Iterationen bestehen

17 III. Iterationen Eine Phase kann mehrere Iterationen besitzen (1:n) Es kommt erst die nächste Iteration, sobald die derzeitige Iteration vollendet ist

18 III. Iterationen Eine Iteration in sich besteht aus allen 5 Workflows (1:5) Iterationen = Miniprojekte

19 III. Über die Workflows Wie sind die 5 Workflows in sich aufgebaut?

20 III. Workflows / Models Jeder Workflow erzeugt ein Model

21 III. Zusammenfassung des UP Ein Lebenszyklus im UPsetzt sich wie folgt zusammen: 4-Phasen => n-iterationen => 5 Workflows => 5-6 Models

22 IV. Anforderungen (1. WF) Man versucht in der sog. Anforderungserfassung (Requirements Capture) die Wünsche der User in Anforderungen (1. Workflow) umzusetzen Aus diesem Grund ist jedes Softwaresystem einzigartig, da es einen Teil dieser Welt modelliert, z.b. MuWi-System <> SAP Man verwendet hierzu im Detail das sog. Domain Model und das speziellere Business Model

23 III. Domain Model Das Domain Model (DM) versucht wichtige allgemeine Arten von Objekten innerhalb eines Systems zu identifizieren und als Anforderung zu benennen Hierbei sind die Anforderungen gemeint, die jedes System braucht, z.b.: Jedes Softwaresystem (z.b. SAP, Bankautomat) braucht Eingabe / Ausgabe und Interfaces für die User

24 III. Business Model Das Business Model (BM) = spezielleres Domain- Model, das für wirtschaftliche Softwaresystem wie z.b. SAP gebraucht wird Anforderungen, die von SAP gestellt werden sind z.b. Funktionen für das Rechnungswesen, die Lohnverwaltung, Aufträge, interne Programmierung mit ABAP oder Java oder Arbeitsteilung

25 III. Business Model Im einzelnen besteht das Business Model (BM) aus: 1. Business Use Case Model Eine grobe Einteilung eine grobe Benennung der Use-Cases 2. Business Object Model Eine genauere Einteilung der User Genaure Einteilung der Aufgaben Relationen zwischen User und Aufgaben werden gebildet

26 III. Business Object Model Im einzelnen bedeutet das Business Object Model z.b. für ein SAP System: Rechnungswesen => keine SAP Programmierung Programmierer => keine Geschäftszugriffe Der Vorteil liegt hier in der Sicherheit und die in ihren Aufgaben verschiedenen User brauchen nicht Zugriff auf sämtliche Funktionen eines Systems

27 V. Analyse (2. WF) Der Analyse Workflow beinhaltet die konzeptuelle Betrachtung der Anforderungen, die für die Programmierer wichtig sein werden Die Sprache soll eine sein, die den Programmierern zugänglich sein soll und auch aus Fachbegriffen besteht

28 V. Analyse Ziel des Analyse Workflows ist ein Analysemodell, das wie folgt aufgebaut ist und sich aus folgenden 3 Bestandteilen zusammensetzt

29 V. Einfluss auf die Architektur Der Architekt des Systems muss prüfen ob dieses Analysemodell vereinbar ist mit der Architektur ist und ob es Vorteile bringt Weitere Personen, die sich um die Integrität der Use Cases und der Analyse Klassen / Packages sind der Use Case Ingenieur und der Komponenten Ingenieur

30 V. Zusammenfassung Analyse Workflow: Analyse Packages werden identifiziert Analyse Klassen liefern Informationen über ihre Verantwortlichkeit, ihre Attribute und die Relationen zu anderen Klassen Use Case Realisierungen beschreiben, wie Use Cases umgesetzt werden können von den Progammiern Architektur <=> Analyse Model => Design Model

31 Fragen???

32 Vielen Dank!!!

Ä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