re bei adessofg-re.gi.de/fileadmin/gliederungen/fg-re/treffen_2014/fgre... · innovation!...

21.01.15

RE bei adesso Projekte im Spannungsfeld zwischen Gestaltung und Erhebung

Dr. Kim Lauenroth Chief Requirements Engineer

Folien vor 10 Jahren ...

21.01.15 3

15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 1/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 1 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004

Zentrale Variabilitätsmodellierung für Requirements Artefakte in der Produktlinienentwicklung1

Stan Bühne, Günter Halmans, Kim Lauenroth, Klaus Pohl

FG-Treffen 2.1.6 „RE“

25./26. November 2004

1Diese Arbeit wurde gefördert durch die Projekte Cafe, Families und Prime15.5.2002© Prof. PohlUniversität Essen

Software Systems Engineering © Prof. Dr. Pohl 3/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 3 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004

Überblick

¾Grundlagen: Variabilität & Produktlinien Framework

¾Herausforderung: RE für Produktlinien

¾ Lösungsansatz: Zentrales Variabilitätsmodell

¾Beispiele

¾Zusammenfassung / Aktuelle Arbeiten


Variabilität als zentrales Konzept der PL Entwicklung

Variante

Variations-punkt

VPAutofarbe

Auto rot

Auto schwarz

Auto weiß

Varianten

Variabilität ist die Fähigkeit änderbaroder gestaltbar zu sein.


Produktlinien Framework


Herausforderungen: RE in PL

1. Konsistente Dokumentation der Variabilität in unterschiedlichen Anforderungsartefakten

2. Definition und Dokumentation der Variabilität im Domain Engineering

3. Bindung der Variabilität im Application Engineering zur Produkterstellung

4. Kommunizierbarkeit von Variabilität (für Kunde/Entwickler/Produktmanager)


ZentralesVariabilitäts-

modell

Lösungsansatz: Zentrales Variabilitätsmodell

Variation Point

Variant

Constraints

requires

exclusive

mandatory

alternative

optional

Requirements Artefact

Goal Scenario Requirement

Requirements

... ...

VariabilityDependency


Requirements Artefakte

VariabilitätsmodellNavigation

VP

Stau-meldung

V

Stimme

VBildschirm-darstellung

V

Alternative

Optional

Z1

Z2 Z3

Z5Z4

A B C

Ziele Szenarien Anforderungen

R1: Die Meldung von Staus

R2: Die Routenführung durch Stimme

R3: Die Routenführung am Bildschirm

Link

Beispiel: Konsistente Dokumentation (1) der Variabilität in unterschiedlichen Artefakten

Routen-führung

V

Mandatory


Zentrales Variabilitätsmodell

Beispiel: Kommunikation (4) und Bindung (3)

Kommunikation mit Kunden/Entwicklern/Produktmanagement

Requirements Artefakte

Scheiben-wischer

Verdeck-steuerung

Fahr-licht

VP VPVP

Interval-steuerung

VInterval-steuerung

VRegen/Licht-sensor

VRegen/Licht-sensor

VWasch-funktion

VWasch-funktion

V

ManuelleSteuerung

VManuelleSteuerung

V

Sensor-steuerung

VSensor-steuerung

VManuelleSteuerung

VManuelleSteuerung

V

Sensor-steuerung

VSensor-steuerung

V

Fahrzeug-typ

VP

Kombi

V

Kombi

V

Cabrio

V

Cabrio

V

Beziehungen

Produkt RequirementsSicht

+ Auswahl

Bindung durch Auswahl von Varianten und Sichtengenerierung

Z1

Z2 Z3

Z5Z4

A B C




R3: Die Routenführung am Bildschirm

Z1

Z3

Z5

A B





Zusammenfassung

¾ Kernthese: Variabilität als eigenständiges Modell ermöglicht:

� Konsistente Dokumentation in verschiedenen Anforderungsartefakten

� Kommunizierbarkeit von Variabilität

� Ableitung von Beziehungen zwischen Artefakten, dadurch

� konsistente Durchführung von Änderungen

¾ Nachteil: Zusätzlicher Aufwand (durch Verlinkung)

¾ Aktuelle Arbeiten

� Change und Versionsmanagement (mit und im Variabilitätsmodell)

� Analyse von Anforderungsmodellen (bzgl. Verlinkung), z.B. UML 2.0

� Tool-Support & Evaluation mit Industriepartnern

Bild: office.microsoft.com (MP900448608)

Intellektuelle(Lockerungsübung-


Entwicklungstrend in den vergangenen 15-20 Jahren

21.01.15 6

Steigende Komplexität

Kostendruck

Kürzere Entwicklungszeiten

Software-basierte Innovationen

Steigende Qualitätsanforderungen

Erfolgsquoten für Softwareprojekte

21.01.15 7

Quelle: CAOS Report 1994-2012. Standish Group.

16% 27% 26% 28% 34% 29% 35% 32% 37% 39%

53% 33% 46% 49%

51% 53% 46% 44% 42% 43%

31% 40%

28% 23% 15% 18% 19% 24% 21% 18%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

100%

1994 1996 1998 2000 2002 2004 2006 2008 2010 2012

erfolgreich eingeschränkt gescheitert

TOP 5 Gründe für Fehlschläge / Erfolgsfaktoren

1995 (Fehlschläge)

1.  mangelnde Einbeziehung der Nutzer

2.  unvollständige Anforderungen

3.  Änderungen von Anforderungen

4.  Fehlende Managementunterstützung

5.  technologische Inkompetenz

2012 (Erfolgsfaktoren)

1.  Managementunterstützung

2.  Einbeziehung der Nutzer

3.  Klare Zielvorgaben

4.  Emotionale Reife

5.  Optimierung

21.01.15 8

Quelle: CAOS Report 1995 & 2012. Standish Group. Hinweise: 1995 benennt der CAOS Report Gründe für Fehlschläge, 2012 werden stattdessen Erfolgsfaktoren benannt

Requirements Engineering (Definition nach IREB) Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

(1) Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.

(2) Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren

(3) Die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

9 21.01.15

Innovation! Kreativität! Software Engineering? Requirements Engineering??

21.01.15 11 © Olympus

Requirements Engineers sind KEINE Diktiergeräte

Kreativität!

Kreativität? Bild: office.microsoft.com (MP900443136)

21.01.15 Anforderungsmanagement in der Auftragsabwicklung 14

"Computers are good at following instructions, but not at reading your mind.“

- Donald E. Knuth

©iStockphoto.com/JamesBrey (11451754)

Crea,vity(is(not(a(talent.((It(is(a(way(of(opera,ng.(

- John Cleese

Wer als Werkzeug nur einen Hammer hat ...

... sieht in jedem Problem einen

Nagel!

- Paul Watzlawick Bild: iStockphoto.com/gilas (1368321)


Anforderung(

Anforderung (Definition IEEE 610-1990)

1)  Eine Bedingung oder Fähigkeit, die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

2)  Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.

3)  Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß (1) oder (2).

System

Stakeholder

An was?

Wer?

Zweck?

Problem

Lösung

Warum?

Wann?

für Anforderung

Was ist eine Anforderung?


Es(gibt(keine(lösungsneutralen(Anforderungen!(

Problem Lösung Anforderung

Fahrer vor zu geringem Reifenluft- druck warnen

Reifen- druck-

messung

Auswertung von ESP-

Daten

Der Sensor mussden Druck im Bereich zwischen 0 und 5 Bar mit einer Genauigkeit von +/-x% messen.

Der Reifendruck mussl alle y Sekunden gemessen werden.

Das ESP-System musskontinuierlich die Reifendrehzahl aller vier Räder überwachen.

Zu geringer Reifendruck liegt vor, wenn über einen Zeitraum von y Sekunden eine Abweichen in der Drehzahl eines Reifens von z% vorliegt.

Die Reifendrehzahl muss mit einer Genauigkeit von +/-x% gemessen werden.

Zu geringer Reifendruck liegt vor, wenn der gemessene Druck unter den Grenzwert z sinkt.

Bild: iStockphoto.com/1MoreCreative (15251741)

int mult(int a, int b) { return a*b; }

0 1 2 3 4 5

0 0 0 0 0 0 0

1 0 1 2 3 4 5

2 0 2 4 6 8 10

3 0 3 6 9 12 15

4 0 4 8 12 16 20

5 0 5 10 15 20 25

int mult(int a, int b) { int result=0; for (int i=0; i<a; i++) result = result + b return result; }


Mode-of-Opera4ng-(

Prinzip(1:(Trennung(von(Problem,(Anforderung(und(Lösung(

Problem Anforderung Lösung 21.01.15 24

„Das System zeigt den aktuellen Druck auf allen vier

Reifen im Display unterhalb des Drehzahlmessers

an, so kann der Fahrer sofort erkennen, ob der

Druck auf den Reifen zu gering ist.“

Problem Anforderung Lösung





21.01.15 25





Bruch der Abstraktionsebene: �  Display ist Teil des Systems �  Welches Problem wird hierdurch gelöst?

21.01.15 26

…so what?


APIs, Bibliotheken Hochsprachen

CPUs, RAM Register true, false +5 Volt, -5 Volt

Compiler

Betriebssystem Maschinensprachen

Mensch (Design Patterns,

Frameworks, MDA)

Fachliche Architektur Funktionale Architektur Technische Architektur

Abstraktion Prinzip der Reduktion und Verallgemeinerung


Wir sitzen auf einem Eisberg von Abstraktionsstrukturen

21.01.15 30

Nutzer Anwendungs-Entwickler

Framework-Entwickler

Programmiersprachen-Entwickler

Betriebssystem-Entwickler

T


Abstraktion bewusst verwenden

Drei prinzipielle Abstraktionsstufen

Kontext:-System(als(Blackbox;(Beziehung(zur(Umgebung(steht(im(Fokus(

System:(AuMau(des(Systems(mit(logischen(Einheiten-

Technologie:(AuMau(des(Systems(mit(technischen(Einheiten-

21.01.15 32

Kontext

System

System/Technologie

Ein PKW fährt auf einer Straße im Berufsverkehr. Das erste Fahrzeug einer Kolonne von PKWs bremst scharf ab, da ein Kind auf die Straße springt. Die nachfolgenden Fahrzeuge werden vom Fahrzeug unmittelbar durch ein Funksignal über die Notbremsung informiert und leiten ebenfalls automatisch ein Bremsmanöver ein. Das Kind bleibt unverletzt und es passiert kein Auffahrunfall.

Technologie

21.01.15 33

System/Technologie?

Technologie

Kontext

System

Kontext

Ein PKW fährt auf einer Straße im Berufsverkehr. Das erste Fahrzeug einer Kolonne von PKWs bremst scharf ab, da ein Kind auf die Straße springt.

Die nachfolgenden Fahrzeuge werden unmittelbar über die Notbremsung informiert und können dadurch rechtzeitig abbremsen.

Das Kind bleibt unverletzt und es passiert kein Auffahrunfall.

Die Information über Notbremsung wird über ein Funksignal übertragen.

Das rechtzeitige Bremsen kann durch dediziertes automatisches Notbremssystem realisiert werden.

21.01.15 34


Mode-of-Opera4ng-(

Prinzip(1:(Trennung(von(Problem,(Anforderung(und(Lösung(

(Prinzip(2:(Benennung(und(

Anwendung(von(Abstrak,onsstufen(

Problem Anforderung Lösung

Synthese der Prinzipien: PAL-Modell

Kontext:-System(als(Blackbox;(Beziehung(zur(Umgebung(steht(im(Fokus(

System:(AuMau(des(Systems(mit(logischen(Einheiten-

Technologie:(AuMau(des(Systems(mit(technischen(Einheiten-

21.01.15 36

Lauenroth, K.: Starten Sie mit einem Blatt Papier - Strukturieren und Analysieren von Anforderungen mit dem PAL-Modell. Objektspektrum 03/2013.

Bild: iStockphoto.com/Brigida_Soriano (14696510)

Grau,(teurer(Freund,((ist(alle(Theorie(...(

( ( (P(Mephisto((Goethes(Faust)((


Beispiel(Abwickler(–(S,rbt(das(

PosUach(mit(dem(Anwalt?(21.01.15 39


Beispiel(BearbeitungsP

auWragsP(maschine((BAM)(

21.01.15 40


Beispiel(Erfassung(von(

Risikozuschlägen(21.01.15 41


Beispiel(BeauskunWung(

21.01.15 42

“We(have(always(thought(of(design(as(being(so-much-more-than-the-way-something-looks(P(It’s(the(whole(thing.(((The-way-something-actually-works-on-so-many-different-levels.”((

- Jonathan “Jony” Ive(

re bei adessofg-re.gi.de/fileadmin/gliederungen/fg-re/treffen_2014/fgre... · innovation!...

Documents