testen variantenreicher systeme - method park...mass production mass customization …1913 heute . 6...

1

Testen

variantenreicher

Systeme Dr. Sebastian Oster

15.09.2015

2

Detroit, Miami

Boston, Chicago, Seattle,

San Francisco

USA

Erlangen, München, Stuttgart

London, Paris, Wien, Zürich, Mailand,

Sibiu

EUROPA

Bangalore, Beijing, Shanghai, Tokyo

ASIEN

Method Park Standorte

Mitarbeiter: 125

Umsatz: 11,8 Mio. €

3

Training

Umfangreiches Seminarangebot rund um Software- und Systems-Engineering Akkreditiert von folgenden Organisationen: SEI, ISTQB, iSQI, iNTACS, IREB, iSAQB, ECQA

Engineering

Software-Entwicklung von der Anforderung bis zum Test für Komponenten oder Gesamtsysteme Branchen: Automotive, Defense, Maschinenbau/ Automatisierung, Government/Public, Healthcare, IT

Consulting/Coaching

zu folgenden Themen

Software Process Improvement

CMMI®, SPICE, Automotive SPICE®

AUTOSAR, Functional Safety

Anforderungsmanagement

Projekt- und Qualitätsmanagement

Software Architektur & Design

Software Testing

Variantenmanagement

Produkt

Lösung für integriertes Prozessmanagement

Method Park

4

Themen:

Variantenreiche E/E-Architekturbewertung

Software-Produktlinien-Management

Funktionsverortung

KPI-basierte Bestimmung von Varianten

Komplexitätsmanagement

Modularisierung und Standardisierung

Vielfaltsmanagement

Modellbasierte Entwicklung und Test

Method Park

Variantenmanagement

5

Motivation

Mass Production Mass Customization

…1913 heute

6

Gründe für die Variantenvielfalt

Kundenspezifische Produktentwicklung Technologie-Affinität des Kunden Auswahl ist Messlatte der Innovation Wettbewerb Globalisierung Erschweren der Vergleichbarkeit Innovation und Variantenvielfalt ist einer der besten Kopierschutz-

Mechanismen

OEM und Funktionsvielfalt Wettbewerb Preisdruck Globalisierung Erschweren der Vergleichbarkeit Auswahl ist Messlatte der Innovation Innovation und Variantenvielfalt ist einer der besten

Kopierschutz-Mechanismen

7

Nutzen der Variabilität

Differenzierung

Präzise Kundenwunsch-

Abdeckung

Sichtbare Innovationen

Gestaffelte Preise/Lizenzen

Wiederverwendung

Ressourceneffizienz

Kundenbindung durch Design

und Emotionen

…

www.mercedes-benz.de

8

Kosten der Variabilität

0

1

2

3

4

5

Erzeugung von Varianten

Anteil der anfallenden Kosten für Varianten

hoch/ häufig

selten/ niedrig

Generierung/ Kostenanfall

Varianten- verursacher

Kostenträger

Quelle: Skript Komplexitätsmanagement Prof. Wildemann, TCW

9

Kosten der Variabilität

Herausforderung:

Varianten

Ko

sten

Zeit (Versionen)

Für die Kunden muss über die Zeit eine wachsende Anzahl an Varianten und Versionen vorgehalten werden.

Die Komplexität wächst über die gesamte Wertschöpfungskette in

Entwicklung

Organisationstrukturen

Bestandsmanagement

Produktion

Systematisches Variantenmanagement hilft Ihnen, die Vorteile der Variantenvielfalt in Ihrer Systemlandschaft auszuschöpfen bei gleichzeitiger Kontrolle über Kosten, Aufwand und Ressourcen.

10

Variantenmanagement

Extrahieren Sie ihre Komplexität und Varianten aus den einzelnen Etappen im V-Modell in einen übergreifenden Variantenmanagement-Prozess Etablieren Sie durch das Variantenmanagement eine Struktur Verwalten Sie die Variantenvielfalt Ihrer Requirements, Abhängigkeiten, Architektur usw. systematisch

Maßnahmen

11

Explizite Darstellung von

Gemeinsamkeiten und Variabilität

Ein Feature repräsentiert Anforderungen (1…n) Architekturkomponenten Codefragmente Test Cases Bedingungen zwischen Features …

Variabilitäts-Modell

12

Software-Produktlinien-Management

Body Comfort System

Human Machine Interface

Automatische Fensterfunktion

ManuelleFensterfunktion

Zentral-verriegelung

Fenster-heber

Funkfern-bedienung

Verstellbarer Aussenspiegel

Status LED

Türsystem Sicherheit

Steuerung Fensterfunktion

exclude

LED Zentral-verriegelung

LED Fenster-

heber

require

require

Problemraum

Lösungsraum

Variabilitätsmodell Konfiguration

Body Comfort System





Fenster-heber

Funkfern-bedienung


Status LED



exclude


LED Fenster-

heber

require

require

150% Anforderungen

150% Funktionalität

150% Test

100% Anforderungen

100% Funktionalität

100% Test

150% Implementierung Produkt

13

Wiederverwendung

Lego® Brick = Reusable Asset

14

Fokus: Produkte

Individuell Wiederverwendung

alle

Teilmenge

Produkt- individuell

Wieder- verwendung

Repräsentative Teilmenge

Produkt-individuell Jedes Produkt individuell testen

Wiederverwendung Jedes Produkt aber mit Wiederverwendungs-Techniken z.B.:

Test Ergebnisse

(z.B. Regressionstest)

Test Artefakte

(z.B. Modellbasiertes Testen)


Testen einer repräsentativen Teilmenge basierend auf einer bestimmten Metrik

Testen variantenreicher Systeme

15

Motivation:

• Produktindividuelles Testen aufgrund der hohen Produktanzahl nicht möglich

• …auch nicht mit Wiederverwendungstechniken

• Ansätze zur Berechnung repräsentativer Mengen ignorieren in der Regel den vollständigen virtuellen Produktraum

Zielsetzung:

Integration der bestehenden Ansätze

Individuell Wiederverwendung

alle

Teilmenge

Produkt- individuell

Wieder- verwendung


Testen variantenreicher Systeme

16

Featuremodell: • Hierarchische Anordnung von Features • Explizite Darstellung von Gemeinsamkeiten und Variabilität • zusätzliche Abhängigkeiten

Body Comfort System





Fenster-heber

Funkfern-bedienung


Status LED




LED Fenster-

heber

Body Comfort System





Fenster-heber

Funkfern-bedienung


Status LED




LED Fenster-

heber

Beispiel

Oder 2Oder 1PflichtOptional OderEntweder

Oder-Gruppe Alternativ-Gruppe

40 Konfigurations- möglichkeiten

Body Comfort System





Fenster-heber

Funkfern-bedienung


Status LED



exclude


LED Fenster-

heber

require

require

[LOGS2011,Mueller2009]

17

• Featuremodell repräsentiert die SPL-Anforderungen (Gemeinsamkeiten und Variabilität)

• Testen einzelner Features ist nicht ausreichend

• Feature-Interaktion fehleranfällig

• Beispiel: Automatische Fensterfunktion und Zentralverriegelung interagieren

Body Comfort System





Fenster-heber

Funkfern-bedienung


Status LED



exclude


LED Fenster-

heber

require

require

Ein Feature A interagiert mit einem Feature B, wenn das Verhalten von A von der Anwesenheit von B abhängt.

Fehleranfällige Feature-Interaktionen

18

• Beispiel: 3 optionale Features • 8 Konfigurationen müssten getestet werden • Mit Pairwise: nur 4 Kombinationen zu testen Pairwise Feature-Interaktion

Sicherheit Zentralver-

riegelung

Außen-

spiegel

S, Z Z, A S, A

1 true true true true, true true, true true, true

2 true true false

3 true false true

4 true false false true, false false, false true, false

5 false true true

6 false true false false, true true, false false, false

7 false false true false, false false, true false, true

8 false false false

Kombinatorisches Testen

19

• Features als Eingabeparameter der SPL

• Kombinatorik zur Generierung einer repräsentativen Menge

• Features können nicht willkürlich kombiniert werden

• Hierarchie im Featuremodell

• Beziehungen

(Optional, Pflicht, Alternativ und Oder)

• Abhängigkeiten (Require und Exclude)


Funkfern-bedienung


Sicherheit


require

Abdeckung von Feature-Interaktion

20

• Gegeben: Featuremodell und Featurepaare

• Problem: Finde eine minimale repräsentative Teilmenge an Konfigurationen, die alle Paare von Features abdeckt.

• Mengenüberdeckungsproblem

• ist NP-Vollständig

• Heuristik


21

Solver

Abzudeckende Paare

Lösche invalides Paar

Lösche abgedeckte Paare

Repr. Menge von Konfigurationen Übergebe

Konfiguration Übergebe Paar

9 statt 40!

body comfort system

hmi autpwmanpwdoor system,

power window

excluderequire

require

require

requirerequire

require

human machine interface

manual power window, automatic

power window

central locking system

remote control key

adjust exterior mirror

status LEDdoor system,

power windowsecurity

control automatic power window

LED central locking system

LED power window

¬ sLEDsLEDLEDcls

¬ LEDcls

LEDpw

¬ LEDpw

¬ secsec ¬ clscls ¬ rckrck ¬ capwcapw ¬ aemaem

requirerequire

requirerequire


22

Fazit

Ja, denn 100% T-wise Feature-Interaktions-Abdeckung

In 2 industriellen SPLs mit n-Fehlern evaluiert mit Pairwise wurden > 95% der Fehler gefunden Nicht abgedeckte Fehler basierten auf 3-wise Feature-Interaktion

Bsp. 287 Features 2.26 x 1049 Konfigurationen 225 Pairwise Konfigurationen

Ist es möglich eine variantenreiche Systeme systematisch und ökonomisch zu testen ohne jedes einzelne Produkt zu testen?

23

KONTAKT Dr. Sebastian Oster

0162 2911706

[email protected]

testen variantenreicher systeme - method park...mass production mass customization …1913 heute . 6...

Documents