RE in der Praxis. Ein Bericht aus zwei Projekten. SOPHIST GmbH Vordere Cramergasse Nürnberg. Tel.:+49 (0)

Ähnliche Dokumente
Übung Einführung in die Softwaretechnik

Kapitel 2 - Die Definitionsphase

Use Cases vs. Funktionale Spezifikation

Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh

Requirements Engineering Übung am

INSPIRE - Modellierung

Software Engineering. 3. Analyse und Anforderungsmanagement

DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten. 08. Juni 2011

Setze ich als bekannt voraus: Wo steckt RE in Scrum? RE & SCRUM. Sprint Backlog Product Backlog. Deliverables. Product Owner

Universität Karlsruhe (TH)

Modellbasiertes manuelles Testen: Techniken und Tücken

Model-based Requirements Engineering

Klausur. Softwareentwurf. 14. Februar 2011 Bearbeitungszeit: 120 Minuten

Software-Praktikum. Überblick und Zeitplan

Lernen durch Feedback aus Inspektionen Dr. Andrea Herrmann

Vorlesung Programmieren

NACHRICHTENTECHNISCHER SYSTEME

Tamagotchi-Spezifikation in UML

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick

Software- und Systementwicklung

DOORS Schema IBM Rational DOORS Start-Up Training - Teil 3

Ziele und Tätigkeiten von Architekten

Grundproblem. Kommunikation zwischen unterschiedlichen Sprachen. Einfach englisch spezifizieren

IT-Projekte: "Planungssicherheit bis zur Implementierung"

CARL HANSER VERLAG. Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins. UML 2 glasklar

Ereignis-basierter Test grafischer Benutzeroberflächen ein Erfahrungsbericht

Variantenmanagement im Requirements Engineering: Mammutaufgabe oder leicht gemacht? Merkmalbasiertes Variantenmanagement in Spezifikationsdokumenten

MDRE die nächste Generation des Requirements Engineerings

Von UML 1.x nach UML 2.0

Modellierung von Echtzeitsystemen mit dem UML CASE Tool Telelogic Tau G2 Developer

Softwaretechnik 2015/2016

Herzlich willkommen DevDay Zürich 2016

Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Bessere Service-Modellierung durch Kombination von BPMN und SoaML. Nürnberg, 24. Februar 2011

UML 2.0 als Architekturbeschreibungssprache? Seminar: Architekturbeschreibungssprachen Manuel Wickert

Objektorientierte Systementwicklung

Jason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel

Projektmanagement: Werkzeuge & Methoden

Vorlesung Software-Engineering I

Dokumente eines IT-Projektes:

Bilder sagen mehr als Worte. arvato IT services. Modellbasierte Softwarespezifikation Jan Leßner

Softwaretechnik 1 und 2. Vorlesung Informatik Bachelor, 3. / 4. Semester Prof. Dr.-Ing. Stefan Bente. Lehrkonzept. Stand:

GAUSS towards a common certification process for GNSS applications using the European Satellite System Galileo

Die Unified Modeling Language UML

SOFTWAREPROJEKT (WI) Anforderungsanalyse. Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing.

RUP Analyse und Design: Überblick

Projektmanagement Projektablauf

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

IT-Transformation How to run changing systems

Projekttitel:Sleep-2-Go Projekthomepage:swe2012.webnode.at

Softwareentwicklungspraktikum Sommersemester Grobentwurf

IT-Projekt-Management

Systematisches Requirements Engineering und Management

HMI Spezifikation Methode, Prozess & Tool

Radikaler Umbruch in der Fahrzeug- und Systemabsicherung. Steffen Kuhn

Objektorientierte Analyse (OOA) Inhaltsübersicht

Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

Vorlesung Programmieren

UML Crashkurs v0.1. UML für Fachinformatiker. von Hanjo Müller

Lösungsvorschlag für Übungsblatt 4 Software Engineering 1 (WS 2012/13)

Guido de Melo Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Inhaltsverzeichnis. Teil I Grundlagen 1

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07

SysML Die Zukunft des Systems Engineering?

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE)

UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language

Artefakte, Linktypen und Besonderheiten von OOSE/RUP

Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Prof. Dr. R. Dumke. Prüfungsklausur Softwaretechnik I. Bewertung

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

Grosse Systeme im Griff

Index. CSQFD-Modell 327 Customer Satisfaction and Quality Function Deployment 126, 315, 325

Erstellung eines Pflichtenhefts (I)

Softwaremigration in der Praxis: Übertragung alter Softwaresysteme in eine moderne Umgebung (Wirtschaftsinformatik)

Vom Lastenheft zur User-Story Matthias Strößner

Testdokument (Universität Paderborn, Softwaretechnikpraktikum SS2006)

Requirements Engineering

Dipl.-Inform. Lars Ebrecht

IT Service Management Wo beginnen wir? Alex Lichtenberger ITIL-forum Schweiz

XTRACT ein Überblick VL XML, XPath, XQuery: Neue Konzepte für Datenbanken

Specifying Patterns for Dynamic Pattern Instance Recognition with UML 2.0 Sequence Diagrams. Lothar Wendehals. Universität Paderborn

Formale Modellierung Vorlesung vom : Beyond JML

Schnellere Innovationszyklen für Elektroniksysteme entlang der Automobilwertschöpfungskette

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Prozesse Last oder Lust?

Rhapsody in J Modellierung von Echtzeitsystemen

Systematisches Requirements Engineering

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil.

Design Thinking Eine Hands-On Einführung

Unified Modeling Language (UML )

ID-Management, Fachbereich Informatik. AusweisApp2 WISSENSCHAFTLICHE BEGLEITUNG

Customer-specific software for autonomous driving and driver assistance (ADAS)

Unified Modeling Language 2

Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management

Kompetenzzentrum für nicht-textuelle Materialien Kooperation Leibniz-Gemeinschaft <>TIB. Margret Plank Leibniz Gemeinschaft AK Presse

Modellbasierte Software- Entwicklung eingebetteter Systeme

HERZLICH WILLKOMMEN. e n g i n e e r i n g a u s l e i d e n s c h a f t! eng-craft \\ Beratung & Ingenieurdienstleistungen

Requirement: Klar und testbar!

Auf dem Weg zum optimalen Druckdialog. User Experience als Integrationsprozess

Transkript:

RE in der Praxis Ein Bericht aus zwei Projekten SOPHIST GmbH Vordere Cramergasse 13 Tel.:+49 (0)911 40 900-0 www.sophist.de 90478 Nürnberg Fax:+49 (0)911 40 900-99 heureka@sophist.de

Wer bin ich? Die SOP PHISTen Matthias Strößner Trainer, Berater, Speaker, Vertriebsleiter Überwiegend im Automotive & Versicherungsumfeld tätig. Führt RE & RM in Unternehmen ein. Optimiert bestehende RE-Prozesse Strategische RE & RM Beratung

Die SOPHISTen SOPHIST GmbH Beratungs-/ Schulungshaus und Methodenführer im Bereich RE/RM/OO Die SOP PHISTen 40 Mitarbeiter mit hochspezialisiertem Wissen Berater und Trainer mit Projekterfahrung und unterschiedlichsten Kompetenzfeldern Gründungsjahr: 1996 Standort: Nürnberg

Wer schreibt, der bleibt Die Bücher der SOPHISTen Vortra agstitel www.sophist.de/publikationen

1 Projekt 1 Einführung von RE & Anwendung bei einem Telematiksystem 3 Projekt 2 Einführung von RE bei einer Versicherung RE in der Praxis

Spezifikationslandschaft System 1 System System n System 1 Komponente 1 Komponente 1 Siehe nächste Folie Komponente Komponente n Fkt. HMI Architektur SOPHIST GmbH Seite 6

Spezifikation einer Komponente Spezifikation einer Komponente Funktionale Anforderungen Architektur Anforderungen NFA, Ausgelagerte Normen, ISO, Standards etc. HMI Anforderungen Strukturanforderungen SOPHIST GmbH Seite 7

RE bei der Entwicklung eines Telematiksystems Spezifikationszeit 0,5-1 Jahr bis zur Vergabe 80.000 textuelle Anforderungen in DOORS für ein Steuergerät Rund 2 Jahre Spezifikationsabstimmung (Lastenheft) RE-Team ca. 12 Personen inkl. Toolsupport stehen 100 Entwicklern gegenüber SOPHIST GmbH Seite 8

Einführung von RE die Massen zähmen Ausgangsituation: Jeder schreibt wie und was er will! Lösung über die 3 Arbeitspakete: 1) Marketing Infoveranstaltungen, Werbung etc. 2) Leitfaden Methodisches Rückgrat und Nachschlagewerk 3) Coaching Unterstützung der Anwender beim Schreiben von Anforderungen SOPHIST GmbH Seite 9

Die Wandeltreppe nach Czichos Akzeptieren Erfolg/Programmieren Ausprobieren Fragen/Nachdenken Kampf/Flucht Schock/Konfusion SOPHIST GmbH Seite 10

Beispiel für eine Spezifikation - 1 Vereinfachtes Beispiel Headunit CAN-Bus Überlegungen: Steuergerät Kameras & Sensorik Was muss ich wo spezifizieren? Wie viele Spezifikationen müssen erstellt werden? SOPHIST GmbH Seite 11

Beispiel für eine Spezifikation - 2 Vereinfachtes Beispiel Headunit CAN-Bus Steuergerät Kameras & Sensorik Wie schaut diese Spezifikation aus? SOPHIST GmbH Seite 12

Begründeter Regelbruch Veränderung der Satzschablone Regel: SOPHIST-Satzschablone einsetzen er Praxis SHALL <process> RE in de [<When?> <Under what conditions?>] THE SYSTEM <systemname> SHOULD WILL PROVIDE <whom?> WITH THE ABILITY TO <process> BE ABLE TO <process> <object> <additional details about the object> SOPHIST GmbH Seite 13

Begründeter Regelbruch Veränderung der Satzschablone Bruch der Regel: Nur shall statt shall/could/will Typ 3 nicht enthalten Grund: Offshore-Entwicklung, starres Vertragswerk, alle Anforderungen sind (erst einmal) verpflichtend Erfahrungswert: Typ 3 wird selten benötigt, jedoch sehr häufig falsch verwendet (statt Typ 1) SOPHIST GmbH Seite 14

Was hat geholfen? 1) Spezifikationslandschaft 2) Spezifikationstemplate 3) Anforderungstemplate 4) Variantenmanagement 5) Komponentendiagramme 6) Sequenzdiagramme 7) Abstimmungsworkshops bis zum jetzigen Fortschritt des Projekts SOPHIST GmbH Seite 15

Projekt 2 Einführung von RE bei einer Versicherung SOPHIST GmbH Seite 16

Versicherungsbranche Einführung von RE Problemstellung: Änderungen an Tarifen, Verbesserungen bei Produkten Zwischen 1 Tag und 2-3 Monate Spezifikationszeit kaum Abstimmung AG-AN Veränderung bestehender AWL 4 Leute im RE-Team stehen 6 Fachbereich á 30 Mann gegenüber SOPHIST GmbH Seite 17

Beispiel aus der Praxis Idee des Fachbereichs SVS- Anforderungs steckbrief Projektantrag Grobkonzept Abnahme Betrieb Fachkonzept bzw.: Pflichtenheft Test Realisierung SOPHIST GmbH Seite 18

Gewalt ist keine Lösung Allgemeine Prinzipien zur Förderung von Veränderung Aufklärung Problem verständlich und greifbar machen und Perspektiven aufzeigen Bedrohung Es folgen Konsequenzen, falls Methode nicht angewandt wird Vorbild Es hat woanders auch funktioniert Absicherung des Weges Klare, einfache Hilfsmittel anbieten Motivation Die erreichbaren Ziele sichtbar machen Tool-Unterstützung Erleichterung der Arbeit oder Einschränkung der Möglichkeiten SOPHIST GmbH Seite 19

Hauptschwierigkeiten in der Praxis Die täglichen Steine in unserem Weg Fehlender Bezug zur Informatik Hohe Motivation, geringe Entscheidungskompetenz Geringe Motivation, hohe Entscheidungskompetenz Fehlende Kooperations- Bereitschaft Angst vor Veränderung Leidtragende schlechter Anforderungen können diese nicht ändern Gefangensein in alten Mustern SOPHIST GmbH Seite 20

Was hat geholfen? 1) Spezifikationslandschaft 2) Spezifikationstemplate 3) Anforderungstemplate 4) Aktivitätsdiagramm 5) Klassendiagramm (Begriffe) 6) Use-Case-Diagramm bis zum jetzigen Fortschritt des Projekts SOPHIST GmbH Seite 21

Vielen Dank für Ihre Aufmerksamkeit! Haben Sie weitere Fragen? SOPHIST GmbH Seite 22

RE in der Praxis SOPHIST GmbH Seite 23

Quellenverzeichnis - Fotos Titel: Scientists Quelle: istockphoto Autor: H-Gall Titel: Start Quelle: istockphoto Autor: Mehli Comiczeichnungen Quelle: SOPHIST SOPHIST GmbH Seite 24