Variant Management for Software-intensive System Families ...

© Fraunhofer IESE

1

September 2, 2014

Variant Management for Software-intensive System FamiliesDr. Martin Becker

http://vm.iese.fraunhofer.de

Copyright © 2014 by Fraunhofer IESE. Published and used by The SSSE and INCOSE with permission.

© Fraunhofer IESE

2

© Fraunhofer IESE

Context

Engineering of variant-rich

software / system families

© Fraunhofer IESE

3

Itzehoe

BerlinGolm

Magdeburg

Hannover

Braunschweig

Bremen

OberhausenDortmund

Duisburg

AachenEuskirchen

SchmallenbergSt. Augustin

IlmenauJena

Dresden

Chemnitz

Würzburg

Erlangen

Pfinztal

DarmstadtKaiserslauternSt. Ingbert

SaarbrückenKarlsruhe

Stuttgart

Freiburg

Freising

Rostock

Teltow

CottbusHalleSchkopau

Paderborn

Nürnberg

Efringen-Kirchen

MünchenHolzkirchen

Leipzig

Itzehoe

BerlinGolm

Magdeburg

Hannover

Braunschweig

Bremen

OberhausenDortmund

Duisburg

AachenEuskirchen


IlmenauJena

Dresden

Chemnitz

Würzburg

Erlangen

Pfinztal



Stuttgart

Freiburg

Freising

Rostock

Teltow


Paderborn

Nürnberg

Efringen-Kirchen

MünchenHolzkirchen

Leipzig

Itzehoe

BerlinGolm

Magdeburg

Hannover

Braunschweig

Bremen

OberhausenDortmund

Duisburg

AachenEuskirchen


IlmenauJena

Dresden

Chemnitz

Würzburg

Erlangen

Pfinztal



Stuttgart

Freiburg

Freising

Rostock

Teltow


Paderborn

Nürnberg

Efringen-Kirchen

MünchenHolzkirchen

Leipzig

Fraunhofer IESE – Facts & Figures

Founded in 1996One of the leading institutes in software

engineering in Europe and worldwide200 employeesSix application-oriented business fields

Product SectorService Sector

Special departments for all phases of the lifecycleof software-based products

© Fraunhofer IESE

4

Syst

emat

icV

aria

tio

n M

anag

emen

tIm

pro

vem

ent

Variation Management Improvement

Characterize & Understand

Plan

Do

Evolve

Assessment of VM practices

Tool-based Analysis of Artifacts

Scoping Workshop

Domain Analysis & Modelling

VM in Artefacts

Support for VM Tool Adoption

Configuration Management

Change Management

© Fraunhofer IESE

5

© Fraunhofer IESE

5

Exercise

Discussion

Please introduce yourself

What is your background?

What systems are you dealing with?

Complexities in your context:

System size

Organization (Distributed development,…)

State your expectations

© Fraunhofer IESE

6

Agenda

Motivation

Strategic Variant Management of Software-intensive Systems

Adoption Patterns and Experiences

Open Issues

Summary

© Fraunhofer IESE

7

Challenge: Increasing Customization Demands

Customers request specialized products adapted to their needs

Different system configurations

Different behavior

Different system interfaces

Different look and feel

© Fraunhofer IESE

8

Challenge: Complexity Increase in Software-intensive Systems

t t

Overall complexity increases exponentially

t

Software can be changed

easily / lately / fast

Function Complexity Product Portfolio Complexity Network Complexity

Overall

Software

t

Overall Complexity

[source: adapted from Univ. of St. Gallen]

© Fraunhofer IESE

9

Industrial Trend: Front-LoadingMB-SE

[source: CESAR Book, Springer]

© Fraunhofer IESE

10

Challenge: Speed Of Development

Cycle time reduction outperforms efficiency improvements

t

Cycle time

“If you are not moving at the speed of the marketplace you’re already dead – you just haven’t stopped breathing yet.” Jack Welch

© Fraunhofer IESE

11

© Fraunhofer IESE

Challenge: Integrated Lifecycle and Variant Management

T2 Tn-1... Time(Versions)

Space(Variants)

P1,1 P2,1

P2,2P1,2

P2,3

Pn-1,m-1

Pn-1,m

Tn

Pn-1,2

1

2

3

...m-1

m Pn,m

Pn,m-1

... ...

T1

Pn-1,1

Pn-1,3 Pn,3

Pn,1

Pn,2...

...

...

Varia

bilit

y

Evolvability

© Fraunhofer IESE

12

Survivingthe

Variant Jungle

>1.000 variablefeatures

>10.000 variationpoints

Runtimeadaptation

2.000 customizedvariants per year

variablebinding

time

ISO 26262

Model-based/drivenDevelopment

>10.000 variableparameters

shorterrelease cycles

Presenter

Presentation Notes

Der VM / LM Dschungel und seine Herausforderungen

© Fraunhofer IESE

13

Agenda

Motivation



Open Issues

Summary

© Fraunhofer IESE

14

Clone-and-Own Approach has Limitations

time

cloning

custom adaptations

CLONING REASONS Unexpected request for a similar product Little available development resources

Time, effort Missing focus on reuse

Unknown future: reuse need not predictable Deliberate decision: independence from

other projects

CONSEQUENCES Short-term:

.+ Effort savings .+ Quick delivery of the new product

Long-term: .– High maintenance effort .– Repetitive maintenance tasks

Based on our industry survey

parallel maintenance

no strategic reuse

“It gives freedom to change, [whencloning] there is no damage to existingproducts.”

“At the beginning we did not know that wewill have to support all the controllers thatwe support now – this emerged over time.”

“When a new customer came, we neededto decide how to implement hisrequirements in the fastest way. We donot have time to think thoroughly aboutgeneric approaches.”

“It is easier to start with something.Cloning gives [us] an initial basis.”

“It saves time. These components werealready used, tested, closed. A kind ofan off-the-shelf software.”

“We need to perform many activities severaltimes: for each variant, we have to check thecode and implement the change or fix.”

“(…) code that we cloned loosesconnection with the product which it iscloned from, and then there is nosharing of new insights andinnovations.”

© Fraunhofer IESE

15

Challenge: Increasing Maintenance

0

20

40

60

80

100

developersmaintainers

Reso

urces (%

)

# delivered systems (to be maintained)

MaintenanceParalysis

© Fraunhofer IESE

16

Challenge: Management Complexity of Cloned Variants

R

R

R R

RP2

P3

P6

P4

P5

RR RP1

Branch Merge Bug Fix ReleaseR Development MaintenancePx Project Integration

R

© Fraunhofer IESE

17

Manage Complexity with Strategic Reuse …

Followed reuse approaches did not achieve expected improvements.Focus was small-grained, opportunistic, and technology-driven.

[source: adapted http://www.sei.cmu.edu/library/assets/spl-essentials.pdf]

© Fraunhofer IESE

18

Reuse repositories with more than 100 elements

can cause substantial search and evaluation costs

Search &Assessment

Efforts

DivergingSea of

Look-alikes

© Fraunhofer IESE

19

With Which Variants do you Earn the Most?

With the ones that can be avoided!

1. Avoid unnecessary variants

2. Master necessary variation

3. Reduce opportunisticvariants/variation

Try to identifyand avoid

unnecessary variability

© Fraunhofer IESE

20

Success Story: Cummins, Inc.

Cost Management estimates product line ROI of 10:1

Time to Market Product cycle time: a year to a few days

Productivity 20 product groups 1000 separate applications 75% of all software comes from core assets Productivity improvement of 360%

Enter new Markets Capability let Cummins enter and dominate industrial diesel engine market

Quality Software quality is at an all-time high 15 of 15 projects are on track (was 3 of 10) Customer satisfaction is high.

[source: SEI]

© Fraunhofer IESE

21

© Fraunhofer IESE

Strategic Reuse / Variation Managementis Needed for Business Benefits

2

«Business»Domain, Business Goals

«Architecture»Solution / Organization

Structure

«Technology»Components, Parts, Production Facilities

is satisfied by

structures

are built from

share an

pertain to

Product Line• Take economic advantage of commonality• bound variation

Co

re A

sset

s


V

© Fraunhofer IESE

22

ISO/IEC 26550 – PLE Reference Model

bdd [Package] Practice Areas [Operational Domain Model]

© Fraunhofer IESE

23

© Fraunhofer IESE

Software and Systems Product Line Engineering (PLE)

[source: ISO26550]

© Fraunhofer IESE

24

Reuse in the Large

In order to achieve higher levels of reuse one needs to

Increase the granularity of the reused parts

Provide building plan

Reuse-in-the-Large

vs

Reuse-in-the-Small

© Fraunhofer IESE

25

Keep Adaptation Cost Small

Study of reuse costs in NASA [1994, Barry Boehm]

[source: http://www.sigapp.org/acr/Issues/V5.2/cardino.html]

Provide AdequateVariability

© Fraunhofer IESE

26

© Fraunhofer IESE

Foundations

Core Asset

Core Asset:==

“subset of assets that are developed in the domain engineering process or obtained by another way for reuse in the application engineering process.”

V: supported variability

© Fraunhofer IESE

27

Variability

Variability :==

“a property that is different among the members of a product line”

“a capability to change or adapt a system”

Notes:

Counterpart commonality: … same … all

A kind of variable feature

Delayed (design) decision: FE -> AE

Variability Decision

© Fraunhofer IESE

28

© Fraunhofer IESE

Foundations

Variation Point

Variation Point :==“represents one or several locations

at which variation will occur

within core assets”.

1. to highlight where variant elements occur(which makes variation easy to see and control)

2. to improve traceability of variability(requires that goal 1 has been fulfilled).

© Fraunhofer IESE

29

Orthogonal VM / FM

VM / FM

Bill of Material Bill of Features

© Fraunhofer IESE

30

© Fraunhofer IESE

Foundations

Variability Management: Separation of Concerns

Domain Engineering: Develop for Reuse

Application Engineering: Develop with Reuse

ProblemSpace/ExternalPerspective

SolutionSpace/Internal

Perspective

Variability Model(Variabilies, Variants,

Dependencies, Configurations)

Variant Specification Model

(Concrete Configuraiton)

CoreAssets,

Family Model

SolutionAssets

© Fraunhofer IESE

31

© Fraunhofer IESE

Foundations

Variability Specification Approaches

Adequate SpecificationApproach

Domain Specific

Languages

DecisionModelling

Feature Modelling

• Start with Feature Modelling

• Develop DSL if FM isnot adequate

• [VM Tool supportlacking] Considerusage of DecisionModels

© Fraunhofer IESE

32

Decision Models

A decision model is a model that captures variability in a product line in terms of open decisions, possible values/resolutions and the respective effects

Decision models can be used regardless the type of the artifact (documents, models, code) => orthogonal variability modeling

• Requires no toolsupport

• Supports manualresolution of VPs

© Fraunhofer IESE

33

Feature ModelsDescribes the features (mandatory, optional,

alternative) of a product line member

[Source: David Benavides, Sergio Segura and Antonio Ruiz Cortés : Automated Analysis of Feature Models 20 Years Later: A Literature ReviewInformation Systems . Elsevier. 2010. 35(6). September 2010]

http://www.lsi.us.es/%7Edbc/en/?download=benavides10-is.pdf

© Fraunhofer IESE

34

© Fraunhofer IESE

Available / Used Variability Mechanisms

General

Parameterization

Configuration

Selection

Module-Replacement

Composition

SW-Specific

Extension

Domain-Specific-Language

Generation

Interpretation

Conditional Execution (at runtime)

Transformation

© Fraunhofer IESE

35

Orthogonal VM / FM

VM / FM

Bill of Material Bill of Features

stm StateMachine

Initial

ReadSensors

Initialization ErrorState

CheckValues

constraints{Warnings}

UpdateDisplay

«p::v Restriction»{NOT(Warnings)}

Final

Final

[ShutdownRequest == true]

[InitOk == true]

[InitOk == false]

© Fraunhofer IESE

36

© Fraunhofer IESE

36

Success Stories

[Remark] „As simple as possible,

no matter what the cost.“

Ludwig Mies van der Rohe


© Fraunhofer IESE

37

2nd Generation PLE Approach: 150%

[source: Provided courtesy of BigLever Software]

© Fraunhofer IESE

38

© Fraunhofer IESE

Feature-based Variability ManagementA

pp

licat

ion

En

gin

eeri

ng

Feature Selection

Processing

Fam

ily E

ng

inee

rin

g Feature Model Core Assets

© Fraunhofer IESE

39

© Fraunhofer IESE

Feature-based Variability Management in Practice: Pure::VariantsA

pp

licat

ion

En

gin

eeri

ng

Feature Selection

Processing

Fam

ily E

ng

inee

rin


stm StateMachine

Initial

ReadSensors


CheckValues

constraints{Warnings}

UpdateDisplay

«p::v Restriction»{NOT(Warnings)}

Final

Final


[InitOk == true]

[InitOk == false]

stm StateMachine

Initial

ReadSensors


UpdateDisplay

Final

Final


[InitOk == true]

[InitOk == false]

© Fraunhofer IESE

40

© Fraunhofer IESE

Feature-based Variability Management in Practice: GEARSA

pp

licat

ion

En

gin

eeri

ng

Feature Selection

Processing

Fam

ily E

ng

inee

rin


© Fraunhofer IESE

41

© Fraunhofer IESE

Challenge: Variability Erosion of Core Assets

//main.cpp#ifdef COLOR

paint();#endif...#if SIZE>20

large();#else

small();#endif...

© Fraunhofer IESE

43

© Fraunhofer IESE

Common Variant Management ApproachesSt

rate

gic

Ad

-ho

c

S

S

Platform-basedIndependent

S

Product Line(80%)

Platform(50%)

ProductionLine (150%)

S

Clone&Own

ManagedCloning

ReuseRepository

ConfigurableProduct (150%)

© Fraunhofer IESE

44

© Fraunhofer IESE

SConfigurableProduct (150%)

Observations of Variant Management ApproachesSt

rate

gic

Ad

-ho

c

S

Platform-basedIndependent

S

Product Line(90%)

Platform(50%)

ProductionLine (150%)

S

Clone&Own

ManagedCloning

ReuseRepository

Evolution of VM approach

Diversification ofVM approach

Lean & agile VM approach

© Fraunhofer IESE

45

A Lightweight Improvement Approach

Initiation Planning Improvement

Potential Analysis

Scoping Customize Reuse approach

SpecifyVariability

DesignPL Architecture

Guide CoreAssets Dev.

Train VM Stakeholders

PL-ConfigurationManagement

Pilot Development

Reuse Infrastr.Improvements

VariantAnalysis

ImproveReuse approach

Reuse Instrastr.Setup

QA Improvements

Funding

© Fraunhofer IESE

46

Scoping

Goals:

Define business goals and constraints

Plan the product line

Activities: PuLSE™-ECO Scoping

Prepare Scoping

Conduct Scoping Workshops

Results:

Product-Release-Plan

Product-Feature-Matrix

Domain- and Asset-Assessment

© Fraunhofer IESE

47

Variant Analysis

Variant Analysis can be used for: Analyzing the reuse potential

Both high-level and detailed analysis

Determining suitable reuse approach (product lines, reusable libraries,…)

Analyzing existing variants For example preprocessor-based code

Planning migration towards the selected reuse approach Determining migration scope

Determining suitable starting point

Supporting the migration Detailed analysis results very helpful for restructuring the code

Fast model updates possible after any change

© Fraunhofer IESE

49

Specify Variability

Goals:

Provide variability model(s) for reuse programme

Activities:

Refine varibility-related information from scoping

Provide overview on variability modeling approaches & tools

Model variability (including interdependencies) in a dedicated variability model

Results:

Variability Model

Tool selection

© Fraunhofer IESE

50

PL Architecture Design

Goals:

Design PL architecture (addressing VM aspects)

Evaluate PL architecture for its suitability

Document and communicate PL architecture to relevant stakeholders

Activities:

Design PL architecture in an incremental and iterative way

Evaluate PL architecture with relevant stakeholders

Plan communication of the architecture

Document architecture in adequate manner (e.g. UML / SysML)

Continuously communicate the architecture

Results:

Documented and communicated PL architecture

© Fraunhofer IESE

51

Fraunhofer Variability Improvement Analysis (VITAL)

Analysis Method & Tool to:

Analyzereuse infrastructure,

generic solutions

Understandvariability erosion

trends

Create a comprehensivemodel of variabilities

and their usage

Calculate and manageVariability-related metrics

© Fraunhofer IESE

52

Fraunhofer Variability Improvement Analysis (VITAL)

How are the variation points nested?

Are there clear hierarchical dependencies?

1334 nodes (variabilities)

1570 edges (dependencies)

Identify dependenciesof parameter namesto ease configuration

© Fraunhofer IESE

55

CRYSTAL Project

Interoperability Specification andReference Technology Platform

IESE Contribution:

Tool and method integration in:

Variation Management

Model-based Requirements Engineering

Virtual Engineering (Simulation)

Safety Engineering

http://www.crystal-artemis.eu/

© Fraunhofer IESE

56

Variant Management ofSafety-critical Software-Intensive Systems

Different Cost-of-Change profile

Cost-of-Change is often not known

What are the areas where variant management is most useful / applied?

How to establish reuse-able building blocks on technical solution level?

How big are typical reusable buildung blocks?

Shall reuse-able solutions be fixed or configurable?

How to approach variant management, if the standard is not (that) reuse aware?

Where to apply variant management: functional architecture / logical architecture?

Proactive variant management seems to be more suitable

© Fraunhofer IESE

58

© Fraunhofer IESE

Summary

As with the Non-software Disciplines

Managing large-scale system families requires strategicvariant management approaches

Business-driven, Architecture-Centric, Coordinated

Sound management of interdependencies is key

SW-specific Issues

Speed of development is competitive factor

Broad range of variant management approaches exists

No one-size-fits all – domain specific tailoring of VM approach

Support transition between VM approaches ( refactoring)

Contact:

Dr. Martin Becker Fraunhofer-Platz 1Dipl.-Inform. 67663 Kaiserslautern

Telefon +49(631) 6800-2246Department HeadES Development Fax +49(631) 6800-92246

[email protected]

Thank you for your attention!

Variant Management for Software-intensive System Families ...

Documents

Transcript of Variant Management for Software-intensive System Families ...