Variant Management of Safety-Critical Software-Intensive Systems

Variant Management for Software-intensive System Families Dr. Martin Becker http://vm.iese.fraunhofer.de

Engineering of variant-rich software / system families

Founded in 1996 One of the leading institutes in software engineering in Europe and worldwide 200 employees Six application-oriented business fields Product Sector Service Sector Itzehoe Rostock

Bremen

Hannover Special departments for all phases of the lifecycle Berlin Braunschweig Golm Teltow of software-based products Oberhausen Paderborn Magdeburg Cottbus Dortmund Halle Leipzig Duisburg Schmallenberg Schkopau Dresden Aachen St. Augustin Jena Euskirchen Ilmenau Chemnitz

Darmstadt Würzburg Kaiserslautern St. Ingbert Erlangen Nürnberg Saarbrücken Pfinztal Karlsruhe Stuttgart Freising München Freiburg Holzkirchen Efringen-Kirchen

Tool-based Analysis of Artifacts

Characterize & Understand Assessment of VM practices

Scoping Workshop Plan Domain Analysis & Modelling

Systematic Do Support for VM Tool Adoption Improvement

VM in Artefacts Variation Management Variation

Evolve Configuration Management

Change Management

 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

5 5

Motivation

Strategic Variant Management of Software-intensive Systems

Adoption Patterns and Experiences

Open Issues

Summary

 Customers request specialized products adapted to their needs  Different system configurations  Different behavior  Different system interfaces  Different look and feel

Function Complexity Product Portfolio Complexity Network Complexity

t t t

Overall Complexity

Software can be changed easily / lately / fast Software

Overall t Overall complexity increases exponentially 8 [source: adapted from Univ. of St. Gallen]

[source: CESAR Book, Springer] © Fraunhofer IESE Challenge: Speed Of Development

 Cycle time reduction outperforms efficiency improvements

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

t 10

Space (Variants) m Pn-1,m Pn,m

m-1 Pn-1,m-1 Pn,m-1 ...... Variability 3 P2,3 ... Pn-1,3 Pn,3

2 P1,2 P2,2 ... Pn-1,2 Pn,2

1 P1,1 P2,1 ... Pn-1,1 Pn,1

Time T T T T 1 2 ... n-1 n (Versions) Evolvability

2.000 customized Runtime variants per year adaptation

Surviving >1.000 variable the >10.000 variable features Variant parameters >10.000 variation points Jungle

variable shorter binding release cycles time

ISO 26262 12

Motivation

Strategic Variant Management of Software-intensive Systems

Adoption Patterns and Experiences

Open Issues

Summary

cloning custom adaptations no strategic reuse

parallel maintenance

time

CLONING REASONS CONSEQUENCES

. Unexpected“When a new requestcustomer forcame, a wesimilarneeded product . Short-term:“It is easier to start with something. . Littleto availabledecide how developmentto implement resourceshis . .+ CloningEffort givessavings[us] an initial basis.” requirements in the fastest way. We do “It saves time. These components were . Time,not have efforttime to think thoroughly about . .+ Quickalready deliveryused, tested, ofclosed the new. A kind productof . Missinggeneric focusapproaches on reuse.” an off-the-shelf software.” . Unknown future: reuse need not predictable . Long-term: “We need to perform many activities several . Deliberate“At the beginning decision:we did independencenot know that we from . .– High maintenance effort will have to support all the controllers that times: for each variant, we have to check the otherwe support projectsnow – this emerged over time.” . .–codeRepetitiveand implement maintenancethe change or tasksfix.” “(…) code that we cloned looses 14 connection with the product which it is “It gives freedom to change, [when cloned from, and then there is no © Fraunhofer IESEcloning] there is no damage to existing sharing of new insights and products.” innovations.” Challenge: Increasing Maintenance

100

80 Resources (%) Resources

developers maintainers 0 # delivered systems (to be maintained)

Maintenance Paralysis

P4 R

P2 R R

P1 R R R

P3 R R R

Px Project Branch Merge Bug Fix R Release Development Maintenance Integration 16

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]

Diverging Reuse repositories with more Sea of Look-alikes than 100 elements 18 can cause substantial

Try to identify and avoid With the ones that can be avoided! unnecessary variability 1. Avoid unnecessary variants 2. Master necessary variation 3. Reduce opportunistic variants/variation

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 Strategic Reuse / Variation Management is Needed for Business Benefits

pertain to «Business» Domain, Business Goals

is satisfied by

share an «Architecture» Solution / Organization

Structure Assets structures 2 Core «Technology» are built from V Components, Parts, Production Facilities

Product Line • Take economic advantage of commonality • bound variation 21

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

bdd [Package] Practice Areas [Operational Domain Model]

[source: ISO26550]

In order to achieve higher levels of reuse one needs to Increase the granularity of the reused parts Reuse-in-the-Small Reuse-in-the-Large

Provide building plan

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

Provide Adequate Variability

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

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.”

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 27

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).

VM / FM

29 Bill of Material  Bill of Features © Fraunhofer IESE Foundations Variability Management: Separation of Concerns

Application Engineering: Develop with Reuse

Variant Solution Specification Model Assets (Concrete Configuraiton)

Problem Solution Space/ Space/ External Internal Perspective Perspective

Variability Model Core (Variabilies, Variants, Assets, Dependencies, Configurations) Family Model

Domain Engineering: Develop for Reuse

Feature Modelling Decision Modelling

Domain Specific Languages

• Start with Feature Modelling • Develop DSL if FM is not adequate • [VM Tool support Adequate Specification lacking] Consider Approach usage of Decision Models 31

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 tool 32 support • Supports manual © Fraunhofer IESE resolution of VPs Feature Models Describes 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 Review Information Systems . Elsevier. 2010. 35(6). September 2010] © Fraunhofer IESE Available / Used Variability Mechanisms

General  Extension  Parameterization  Domain-Specific-Language  Configuration  Generation  Selection  Interpretation  Module-Replacement  Conditional Execution (at runtime)  Composition  Transformation

SW-Specific 34

VM / FM

stm StateMachine

Initial

Initialization ErrorState [InitOk == false]

Final

[InitOk == true] «p::v Restriction» {NOT(Warnings)}

ReadSensors UpdateDisplay

[ShutdownRequest == true] CheckValues

constraints {Warnings}

Final

35 Bill of Material  Bill of Features © Fraunhofer IESE [Remark] „As simple as possible, Success Stories no matter what the cost.“

Ludwig Mies van der Rohe

36 36 [source: adapted http://www.sei.cmu.edu/library/assets/spl-essentials.pdf] © Fraunhofer IESE 2nd Generation PLE Approach: 150%

[source: Provided courtesy of BigLever Software]

Feature Selection

Processing Application Engineering Application

Feature Model Core Assets

Family Engineering Family 38

stm StateMachine

Feature Selection Initial Initialization ErrorState [InitOk == false]

Final

[InitOk == true]

ReadSensors UpdateDisplay

[ShutdownRequest == true] Processing Final Application Engineering Application

stm StateMachine

Initial

Initialization ErrorState Feature Model Core Assets [InitOk == false] Final

[InitOk == true] «p::v Restriction» {NOT(Warnings)}

ReadSensors UpdateDisplay

[ShutdownRequest == true] CheckValues

constraints {Warnings}

Final

Family Engineering Family 39

Feature Selection

Processing Application Engineering Application

Feature Model Core Assets

Family Engineering Family 40

//main.cpp #ifdef COLOR paint(); #endif ... #if SIZE>20 large(); #else small(); #endif ...

Motivation

Strategic Variant Management of Software-intensive Systems

Adoption Patterns and Experiences

Open Issues

Summary

Independent Platform-based

Product Line Production (80%) Line (150%) S Managed Platform Configurable Strategic Cloning (50%) Product (150%) S S

hoc Clone&Own Reuse - S Repository Ad

Independent Platform-based

Product Line Production (90%) Line (150%) S Managed Platform Configurable Strategic Cloning (50%) Product (150%) S S

hoc Clone&Own Reuse - S Repository Ad

44 Diversification of Evolution of VM Lean & agile © Fraunhofer IESEVM approach approach VM approach A Lightweight Improvement Approach

Initiation Planning Improvement

Potential Improve Scoping Customize Reuse approach Analysis Reuse approach

Variant Specify Design QA Analysis Variability PL Architecture Improvements

Pilot Guide Core Development Assets Dev.

Reuse Instrastr. PL-Configuration Reuse Infrastr. Setup Management Improvements

Train VM Stakeholders

Funding 45

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

 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

Proj4 Core Proj2

Project 3

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

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

Analysis Method & Tool to:

Analyze reuse infrastructure, generic solutions

Create a comprehensive model of variabilities and their usage

Understand variability erosion Calculate and manage trends Variability-related metrics 51

How are the variation points nested? Identify dependencies of parameter names Are there clear hierarchical dependencies? to ease configuration

1334 nodes (variabilities) 1570 edges (dependencies)

Motivation

Strategic Variant Management of Software-intensive Systems

Adoption Patterns and Experiences

Open Issues

Summary

• Guidelines • Examples • Tool Integration

Interoperability Specification and Reference Technology Platform IESE Contribution: Tool and method integration in:  Variation Management  Model-based Requirements Engineering  Virtual Engineering (Simulation)  Safety Engineering 55

 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 56

Motivation

Strategic Variant Management of Software-intensive Systems

Adoption Patterns and Experiences

Open Issues

Summary

As with the Non-software Disciplines  Managing large-scale system families requires strategic variant 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 1 Dipl.-Inform. 67663 Kaiserslautern 58 Telefon +49(631) 6800-2246 Department Head ES Development Fax +49(631) 6800-92246 © Fraunhofer IESE [email protected] www.iese.fraunhofer.de