Variant Management for Software-intensive System Families Dr. Martin Becker http://vm.iese.fraunhofer.de 1 © Fraunhofer IESE September 2, 2014 Copyright © 2014 by Fraunhofer IESE. Published and used by The SSSE and INCOSE with permission. Context Engineering of variant-rich software / system families 2 © Fraunhofer IESE Fraunhofer IESE – Facts & Figures 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 3 © Fraunhofer IESE Variation Management Improvement 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 4 © Fraunhofer IESE 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 5 5 © Fraunhofer IESE Agenda Motivation Strategic Variant Management of Software-intensive Systems Adoption Patterns and Experiences Open Issues Summary 6 © Fraunhofer IESE Challenge: Increasing Customization Demands Customers request specialized products adapted to their needs Different system configurations Different behavior Different system interfaces Different look and feel 7 © Fraunhofer IESE Challenge: Complexity Increase in Software-intensive Systems 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] © Fraunhofer IESE Industrial Trend: Front-Loading MB-SE 9 [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 © Fraunhofer IESE Challenge: Integrated Lifecycle and Variant Management 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 11 © Fraunhofer IESE Model- based/driven Development 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 © Fraunhofer IESE Agenda Motivation Strategic Variant Management of Software-intensive Systems Adoption Patterns and Experiences Open Issues Summary 13 © Fraunhofer IESE Clone-and-Own Approach has Limitations Based on our industry survey 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 (%) 60 40 20 developers maintainers 0 # delivered systems (to be maintained) Maintenance Paralysis 15 © Fraunhofer IESE Challenge: Management Complexity of Cloned Variants P4 R P2 R R P5 P1 R R R P3 R R R P6 Px Project Branch Merge Bug Fix R Release Development Maintenance Integration 16 © Fraunhofer IESE Manage Complexity with Strategic Reuse … Followed reuse approaches did not achieve expected improvements. Focus was small-grained, opportunistic, and technology-driven. 17 [source: adapted http://www.sei.cmu.edu/library/assets/spl-essentials.pdf] © Fraunhofer IESE Search & Assessment Efforts Diverging Reuse repositories with more Sea of Look-alikes than 100 elements 18 can cause substantial © Fraunhofersearch IESE and evaluation costs With Which Variants do you Earn the Most? 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 19 © Fraunhofer IESE 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. 20 [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] © Fraunhofer IESE ISO/IEC 26550 – PLE Reference Model bdd [Package] Practice Areas [Operational Domain Model] 22 © Fraunhofer IESE Software and Systems Product Line Engineering (PLE) 23 [source: ISO26550] © Fraunhofer IESE Reuse in the Large 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 vs Provide building plan 24 © Fraunhofer IESE Keep Adaptation Cost Small Study of reuse costs in NASA [1994, Barry Boehm] Provide Adequate Variability 25 [source: http://www.sigapp.org/acr/Issues/V5.2/cardino.html] © 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.” 26 © Fraunhofer IESE V: supported variability 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 27 © 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). 28 © Fraunhofer IESE Orthogonal VM / FM 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 30 © Fraunhofer IESE Foundations Variability Specification Approaches 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 © Fraunhofer IESE 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 tool 32 support • Supports manual © Fraunhofer IESE resolution of VPs Feature Models Describes the features (mandatory, optional, alternative) of a product line member 33 [Source: David Benavides, Sergio Segura and Antonio Ruiz Cortés : Automated Analysis of Feature Models 20 Years Later: A Literature