Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Größe: px

Ab Seite anzeigen:

Download "Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation"

Oskar Biermann
vor 8 Jahren
Abrufe

1 Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags Einführung Rational Unified Process Requirements workflow Praxisberichte Projekt be ISNet Projekt bei Zuehlke Engineering Schlussfolgerungen 1

Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags Einführung Rational

2 Rational Unified Process (1) Software Engineering Prozess Prozessprodukt : HTML-basierten Online-Version Liefert eine Anleitung über die Ordnung der Team- Aktivitäten Spezifizieren von Art und Zeitpunkt der Erstellung von Teilprodukten Lenkt die Aufgaben einzelner Entwickler und des gesamten Teams Bietet Kriterien für die Überwachung und Messung der Projektprodukte und -aktivitäten an Integriert in viele SW-Entwicklungswerkzeuge des Rational Suite erfüllt 6 Software Best Practices Rational Unified Process (2) Software Best Practices Software iterativ entwickeln Anforderungen verwalten Komponentenbasierte Architekturen verwenden Software visuell modellieren Qualität der Software verifizieren Veränderungen an der Software kontrollieren 2

-aktivitäten an Integriert in viele SW-Entwicklungswerkzeuge des Rational Suite erfüllt 6 Software Best Practices Rational Unified Process (2) Software Best Practices Software iterativ

3 Rational Unified Process (3) The big picture Requirements Workflow (1) Zweck des Workflows Übereinstimmung mit Kunden Besseres Verständnis über die Anforderungen des Systems Funktionalität des Systems definieren Grundlage für Kosten- und Zeitabschätzung Benutzerschnittstelle definieren 3

über die Anforderungen des Systems Funktionalität des Systems

4 Requirements Workflow (2) Anforderung in RUP Bedingung oder Fähigkeit, die das System einhalten bzw. besitzen muss Kategorisierung mit FURPS+ Management der Anforderungen Systematisches Vorgehen um die Anforderungen des Systems zu definieren, zu organisieren und zu dokumentieren um ein Abkommen über die sich verändernden Anforderungen zwischen Kunden und Entwicklungsteam zu finden Requirements Workflow (3) 4

Anforderungen des Systems zu definieren, zu organisieren und zu dokumentieren um ein Abkommen über die

5 Requirements Workflow (4) Analyze the Problem Requirements Workflow (5) Arbeiter System Analyst Software Architect Requirements Specifier User-interface Designer Artifacts Vision document Use case model Supplementary specifications 5

Requirements Specifier User-interface Designer Artifacts

6 Praxisbericht : Zuehlke (1) Die Firma : Zuehlke Engineering, Schlieren National und international tätig Über 150 hochqualifizierte Mitarbeiter: Ingenieure, Physiker, Chemiker, Informatiker und Wissenschaftler Beratung, Entwicklung und Realisierung auf den Gebieten: Business, Process, Product, Software Engineering Kontakt : Michael Hirsch, Business Unit Leiter Praxisbericht : Zuehlke (2) Generelles Schema für die Anforderungspezifikation : keine formale Methoden folgt die Core Workflows von RUP Artifacts : Visionsdokument (obligatorisch) use-case Modell (obligatorisch) suplementary specifications glossary Iterative Entwicklung 6

Kontakt : Michael Hirsch, Business Unit Leiter Praxisbericht : Zuehlke (2) Generelles Schema für die Anforderungspezifikation : keine formale Methoden folgt

7 Praxisbericht : Zuehlke (3) Uebersicht über das Projekt Java-GUI für das Profile Generator AMAT CCC verwendet Paetra CAD für das Design von Dampfturbinen Für jede Aenderung, Generierung von allen nötigen Daten für die Fertigung der Dampfturbine => sehr langsam Prototyp bei CCC : nur das Design ohne alle Fertigungsdaten GUI bei Zuehlke : Verbesserung des Prototyps Artifacts Visionsdokument Use case Modell Praxisbericht : Zuehlke (4a) Visionsdokument Kapitel 1-4 Ziel des GUI, Scope, Erklärung des Problems Kapitel 5 Profil des GUI-Benutzer (Dampfturbine-Designer) Technische Gegebenheiten (Bildschirmbreite, OS, etc.) Kapitel 6 Uebersicht über das Produkt : sehr komplex Kapitel 7 GUI Funktionalitäten Generelle Funktionalitäten Design Funktionalitäten 7

Visionsdokument Use case Modell Praxisbericht : Zuehlke (4a) Visionsdokument Kapitel 1-4 Ziel des GUI, Scope, Erklärung des Problems Kapitel 5 Profil des GUI-Benutzer

8 Praxisbericht : Zuehlke (4b) Visionsdokument Kapitel 8-10 Technische Aspekte, die erfüllt bzw. berücksichtigt werden sollen Kapitel 11 Dokumentation-Standards von CCC Kapitel 12 : Appendix Versionen der Visionsdokumente Praxisbericht : Zuehlke (5a) Use-Case Modell Kapitel 1 Ziel Kapitel 2 Referenzen Kapitel 3 Uebersicht über das Use-Case Modell Kapitel 4 Profil eines GUI-Benutzers 8

Versionen der Visionsdokumente Praxisbericht : Zuehlke (5a) Use-Case Modell Kapitel 1 Ziel

9 Praxisbericht : Zuehlke (5b) Use-Case Modell Kapitel 5 Beschreibung der 5 Use-Cases Kapitel 6 Screenshots und Skizze des GUI Kapitel 7 Versionen der use case Modellen Use cases Verfeinerung Normal flow of events Praxisbericht : Zuehlke (6) Auswertung von Herrn Michael Hirsch + Praktischer Prozess, kommt aus der Praxis + Preis + Requirements Workflow gut dokumentiert + Artifacts - Dokumentation in einigen Worklfows 9

flow of events Praxisbericht : Zuehlke (6) Auswertung von Herrn Michael Hirsch + Praktischer Prozess,

10 Praxisbericht : ISNet (1) Die Firma : ISNet, Sierre Professoren der HES-SO (Technische Hochschulen der West-Schweiz) führen Projekten mit Unternehmungen Kontakt : Yves Rey, Direktor der Abteilung Wirtschaftsinformatik an der Hochschule Wallis Praxisbericht : ISNet (2) Generelles Schema für die Anforderungspezifikation Keine formale Methoden Verwenden nur Teile von RUP Mit Werkzeuge : Rational Rose für das Use-Case Modell Sybase PowerAmc für das konzeptuelles Datenbank-Modell MS Visual Basic für die Generierung von GUI-Prototypen 10

Generelles Schema für die Anforderungspezifikation Keine formale Methoden Verwenden nur Teile von RUP Mit Werkzeuge : Rational Rose

11 Praxisbericht : ISNet (3a) Uebersicht über das Projekt Marconi Entwicklung einer Applikation für das Management von technischen Dokumenten für Bobst SA in Mex Bobst SA : weltweit Marktführer für die Montage von Maschinen, die Karton-Elemente falten und kleben Sammlung von Know-How über das Management von Dokumenten für die Erstellung eines Meta-Modells Praxisbericht : ISNet (3b) Was soll die Applikation ermöglichen Redaktion von Prozessen für die Montage von Maschinen Verwendung dieser Dokumenten (Monteure) 11

kleben Sammlung von Know-How über das Management von Dokumenten für die Erstellung eines Meta-Modells Praxisbericht : ISNet (3b)

12 Praxisbericht : ISNet (3c) Was soll die Applikation ermöglichen Verfolgung der Bestellungen (Meister) Praxisbericht : ISNet (4a) Das Visionsdokument Kapitel 1 Ziel des Projektes, Partners, Werkzeuge Wie wird eine Machine montiert? Was ist ein Dokument? Kapitel 2 Akteure für die Redaktion, die Verwaltung und die Benutzung von technischen Dokumenten : Monteur, Meister, System, Redakteur... 12

Werkzeuge Wie wird eine Machine montiert? Was ist ein Dokument?

13 Praxisbericht : ISNet (4b) Globale Uebersicht Praxisbericht : ISNet (4c) Modulen Basis für die Implementierung 13

14 Praxisbericht : ISNet (4d) Use-Cases für jeden Modul Praxisbericht : ISNet (4e) Sequence Diagrams für jedes Use- Case (Hier für das Erzeugen eines Dokuments) 14

15 Praxisbericht : ISNet (5) Auswertung von Herrn Yves Rey + Einfach zu einführen + Artifacts : einfach zu verstehen und praktisch + Preis (Schule) - Am Anfang : Zeit investieren - Nicht alle Artifacts nötig - Wechsel von Prozess nicht immer einfach Schlussfolgerungen : Stärken Marktdominanz Gut dokumentiert (im Produkt selbst und Bücher) Für eine Unternehmung wird es schwierig sein, ein so komplettes Prozess für weniger als CHF pro Benutzer zu entwickeln Dialog mit Stakeholders wird durch das Benützen von UML und Artifacts vereinfacht. 15

Stärken Marktdominanz Gut dokumentiert (im Produkt selbst und Bücher) Für eine Unternehmung wird es schwierig sein, ein so komplettes

16 Schlussfolgerungen : Schwächen Wo ist die Wartung im Prozess? Der Konzept der Wiederbenutzbarkeit der Komponenten fehlt Wo ist das Management der Human Ressources? Ist es nicht ein Kochbuch? ISNet und Zuehlke Engineering verwenden nur Teile von RUP Bei Zuehlke wurden die Core Workflows verfolgt Bei ISNet wurden nur die Artifacts verwendet!! Wo ist der Prozess??? 16

Ähnliche Dokumente

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses