Sie sind auf Seite 1von 32

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

Gliederung

I. Entstehungsgeschichte

II. Der Unified Process

III. Der Lebenszyklus des Unified Process

IV.Anforderungs - Workflow

V.Analyse - Workflow

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)

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)

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

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

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)

: ● Generelle Funktionsbeschreibung (normaler Ablauf) ● Optionale Funktionsbeschreibung (Abweichungen)

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

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

III. Der Lebenszyklus (LZ) des UP

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

Der Lebenszyklus des UP besteht aus 4 Phasen

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)

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

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

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

III. Zusammenfassung des LZ

Der UP besitzt 4 Phasen, die den Lebenszyklus der Entwicklung für ein Softwaresystem darstellen (1:4)

der Entwicklung für ein Softwaresystem darstellen (1:4) ● Bei den sog. Milestones wird das Ergebnis überprüft

Bei den sog. Milestones wird das Ergebnis überprüft

III. Die Iterationen in einer Phase

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

Alle 4 Phasen können aus mehreren Iterationen bestehen

III. Iterationen

Eine Phase kann mehrere Iterationen besitzen (1:n)

Es kommt erst die nächste Iteration, sobald die derzeitige Iteration vollendet ist

Iterationen besitzen (1:n) – Es kommt erst die nächste Iteration, sobald die derzeitige Iteration vollendet ist

III. Iterationen

Eine Iteration in sich besteht aus allen 5 Workflows

(1:5)

Iterationen = Miniprojekte

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

III. Über die Workflows

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

Wie sind die 5 Workflows in sich aufgebaut?

III. Workflows / Models

Jeder Workflow erzeugt ein Model

III. Workflows / Models ● Jeder Workflow erzeugt ein Model

III. Zusammenfassung des UP

III. Zusammenfassung des UP ● Ein Lebenszyklus im UPsetzt sich wie folgt zusammen: – 4-Phasen =>
III. Zusammenfassung des UP ● Ein Lebenszyklus im UPsetzt sich wie folgt zusammen: – 4-Phasen =>

Ein Lebenszyklus im UPsetzt sich wie folgt zusammen:

4-Phasen => n-Iterationen => 5 Workflows => 5-6 Models

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

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

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

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

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

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

V. Analyse

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

Analyse Workflows ist ein Analysemodell, das wie folgt aufgebaut ist und sich aus folgenden 3 Bestandteilen

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

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

Fragen???

Vielen Dank!!!