Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar:

Präsentation zum Thema: "Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar:"—  Präsentation transkript:

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

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)

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

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

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

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

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

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

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!!!