Managing Variant Complexity across the Development Lifecycle

posted May 9, 2018, 3:01 AM by Attila Nemeth   [ updated May 9, 2018, 3:21 AM ]

No concept shall go without a decent Before/After comparison, so in this post we fill this long standing gap.

The Before-image shows the result of an assessment we were tasked with by one of our customers who apparently had issues with managing the complexity of their product line development: variability was managed using different concepts at different stages of the development lifecycle, out of synch, without any chance for consistency.


The After-image shows the basic idea of PLE to extract varibility information to a central model (in this case the so called Feature Model)  that allows expressing variability, their dependencies on a higher abstraction level and in a central place, in a neat and consistent manner.

And the Disclaimer: Any Resemblance to Your Actual Situation is Purely Coincidental (but not without any reason).

Engineering competitiveness as core added value of a company

posted Mar 13, 2017, 8:04 AM by Attila Nemeth

The Thales Group is a French multinational company that designs and builds electrical systems and provides services for the aerospace, defence, transportation and security markets, facing increasing complexity.

If we go through the 2015 annual report of the company we can spot some interesting and at the same time remarkable gems between the long list of numbers and charts:
  1. Thales recognized engineering competitiveness as one of the key elements for their success (page 19) .

  2. They define "Engineering: the core added value of Thales" (page 24):
    • ~22,500 engineers worldwide (1/3 of group staff)
    • Combining hardware, software and systems expertise to design differentiated solutions
    • Addressing increasingly complex and critical situations
    •  Improved methods, processes and tools key to increase engineering performance
Those points listed sound familiar, right? Yes, they sound like Product Line Engineering!
 

How does Product Line Engineering reduce development costs?

posted Jan 3, 2017, 2:07 AM by Attila Nemeth

One of the key motivators for Product Line Engineering (PLE) is to provide customized products at reasonable costs. Although there are other important factors to be considered, even the sustainability of the business is affected, let us now concentrate on how PLE can help to reduce development costs, as this is the immediate question that is analyzed before any investment is done.

If we take a look at the "Main Challenge" part for PLE in the previous article, we find some things that sound like we have to spend money: "Collaboration is more complex. Higher coupling of activities on assets in reused parts. Possibly higher QA effort."

Actually, this is true: PLE uses reusable assets to produce multiple systems in an efficient way. We clearly gain a benefit by not having to develop and(!) maintain the same thing multiple times, but to be able to make an asset reusable, upfront investment needs to be done.



Looking at the numbers, in case this investment is lower than the benefit we gain, PLE is a thing for us. Depicting the total cost of 'n' different systems to be developed, we can find a break even point where taking also the upfront investment of PLE into calculation, the accumulated costs developing multiple systems will be lower than in case of single system development. According to empirical studies in different domains, the break even point is around 3-5. This means if a company has more similar products in the portfolio, the investment into PLE might be worthy.

Of course, this is a simplified calculation, in fact several of organization specific factors influence where the break even point is located in a specific case. 

Other reuse approaches can be compared to PLE in a similar way. In some development aspects the gap between the lines might be lower than in case of single systems development and PLE, however only PLE provides a holistic approach in each development aspect.

Well, there is another kind of break even point in development of multiple systems that is indirectly connected to costs but has even a bigger impact, and that is the sustainability of the business itself. At this break even point, using conventional approaches adding more engineering capability will be exceeded by the complexity of the development.



The consequences may be familiar: despite hiring additional engineers at all costs no new projects can be engaged and customers must be turned down. This can easily disrupt any business.

What can we do then? Actually, we can flatten the curve for engineering complexity and in the area of multiple systems development PLE is the approach that can be used to achieve this.


Comparison of reuse approaches in the software industry

posted Dec 25, 2016, 3:23 AM by Attila Nemeth   [ updated Dec 25, 2016, 3:30 AM ]

It is not always clear how Product Line Engineering fits into the world of reuse approaches commonly used throughout the software engineering landscape. Therefore in this article we take a look at different methodologies, evaluate their capabilities, their benefits and biggest challenges along the properties most important to systematic and efficient reuse. Following reuse approaches are investigated: Parametrization, Components, Clone and Own / Branching, Versioning, Frameworks, Domain Specific Languages and finally Product Line Engineering itself.

 
 Name: Parametrization
 Short Description: Configurable Parameters are used to changed / adapt control flow and behaviour of assets.
 Supported Granularity: Fine Grained
 Main Challenge: Parameter dependencies are usually not expressed explicitly in a fully formal, provable way. It is often complex to read parametrized code since it requires the reader to instantiate the code relevant for a specific variant manually on the fly (#ifdef, if (param == 12) ).
 Main Benefit: Performance (#ifdef), Dynamic Change (if (param == 12) ).
 Variation Scope: Structural (any granularity), Parametric
 Direct Link to Use of Assets: No
 Required Tool Support: Each tool must provide parametrization concept (control structures, preprocessor, … ).
 Explicit Evolution Support: No

 Name: Components
 Short Description: Components with well defined interfaces are composed into a system. Composition selects suitable components and connects them.
 Supported Granularity: Coarse Grained (Interface and/or Component level)
 Main Challenge: Modifying existing components must not break existing uses of the component. This often leads to interface bloat and related code bloat to support varying use cases. Makes components complex and hard to maintain and increase memory footprint. Often leads to components with versioned interfaces which then increase number of maintained assets and make composition process complex. Usually combined with internal parametrization for variation handling.
 Main Benefit:  Well defined interfaces decouple development and simplify testing. For stable components reuse is easy.
 Variation Scope: Structural (Component Level)
 Direct Link to Use of Assets: No
 Required Tool Support: Can be implemented by convention only (file system conventions) or with dedicated approaches such as AUTOSAR and suitable tools.
 Explicit Evolution Support: No

 Name: Clone and Own / Branching
 Short Description: A suitable asset is selected from a repository. It is copied / branched and modified to suit the changed requirements.
 Supported Granularity: Coarse Grained (Branchable / Copyable Asset, usually file level or above)
 Main Challenge: Since the copied/branched assets in most cases are not directly matching the minimal variation granularity, common code / information is duplicated. This creates increased mainteance effort. It also increases the total size of the to be considered assets for reuse, making selection and composition incrementally more complex over time. It also complicates reuse since merging of functionalities from different, independently evolved assets is often complex.
 Main Benefit: High decoupling of development paths, permits quick modifications without harming others.
 Variation Scope: Structural (Asset Level)
 Direct Link to Use of Assets: Yes
 Required Tool Support: File system conventions / Version Control System
 Explicit Evolution Support: Partially

 Name: Versioning
 Short Description: Changed assets are identified by version numbers. Systems are composed by selecting a valid combination of assets and version numbers to fit needs.
 Supported Granularity: Coarse Grained (Versionable asset, usually file or larger)
 Main Challenge: Version numbers do not contain information about the variation, they merely denote a variation. For selecting the right version extra information has to be used for selection. Since in principle each version of an asset can be reused, the number of assets to consider grows quickly. Usually this leads to adoption of a clone and own approach with constant reuse degradation and increased maintenance effort.
 Main Benefit: Decoupling of development paths, may permit quick modifications without harming others.
 Variation Scope: Structural (Component Level)
 Direct Link to Use of Assets: Yes
 Required Tool Support: Depending on the approach usually a version control system or similar (PLM, Component Repository)
 Explicit Evolution Support: Partially

 Name: Frameworks
 Short Description: A framework provides a defined set of services used by applications.
 Supported Granularity: Flexible
 Main Challenge: Required flexibility usually leads to complex configuration/parametrization framework. Performance & memory footprint is often not as good as in other approaches if framework is always deployed completely. Usually covers only architectural/implementation part, not requirements.
 Main Benefit: A framework is tested and released as whole. High reuse can be achieved if framework variation is kept minimal.
 Variation Scope: Parametric and Structural (Granularity framework dependent, usually framework level)
 Direct Link to Use of Assets: No
 Required Tool Support: Flexible, depending on framework
 Explicit Evolution Support: No

 Name: Domain Specific Languages
 Short Description: Domain specific languages constructed to provide application specific constructs like states and state transistions to abstract from "low level" general purpose programming languages. May include explicit variation point concept.
 Supported Granularity: Flexible (depends on DSL)
 Main Challenge: Requires investment and know-how in designing an suitable DSL and for maintenance of it. Usually covers only architectural/implementation part, not requirements.
 Main Benefit: Properly designed DSL reduce the size of the to be maintained assets and simplify understanding them. DSL may also include appropriate variation point concepts and can provide users with the necessary tools to deal with increased reuse complexity.
 Variation Scope: Any (Structural, Parametric, … depending on DSL)
 Direct Link to Use of Assets: No
 Required Tool Support: Usually DSL development tools and tools generated from DSL specification.
 Explicit Evolution Support: No

 Name: Product Line Engineering
 Short Description: Integrates reuse approaches into a holistic view by providing explicit notion of variants derived from reusable assets and connecting reuse concepts throughout the development using a uniform variation notation. It also covers the processes to handle the evolution of assets.
 Supported Granularity: Flexible
 Main Challenge: Collaboration is more complex. Higher coupling of activities on assets in reused parts. Possibly higher QA effort.
 Main Benefit: Leverages existing variation concepts in each domain, connects them. Usually reduces the size / amount of to be managed assets significantly. This reduces complexity and maintenance effort and increases reuse. Version management is simplified significantly.
 Variation Scope: Any (Structural, Parametric, … on any suitable level)
 Direct Link to Use of Assets: Yes
 Required Tool Support: No necessarily, but in most cases dedicated variant management tool to maintain variant information and uniform variability model is required
 Explicit Evolution Support: Yes

1-4 of 4