Third International Workshop on Reverse Variability Engineering (REVE 2015)

Software product line (PL) engineering has been established in the last decade as a proven way to build flexibility and reusability into software systems. This approach is centred around the idea that the initial investments made in the development of reusable artefacts are outweighed by the quality and product improvements gained through the reuse of such artefacts. While there are many studies on introducing PL engineering into software development and calculating expected value upfront, there is little documented evidence of long-term experiences with PL engineering. This paper examines perceptions of the value of PL engineering for three PL of different ages. The paper confirms that, while PL engineering enhances product value and quality through shared components and architecture, this is also the predominant limitation of PL engineering. Furthermore, our investigations show that while perceptions of product quality differ depending on PL maturity, this is not the case for time-to-market and cost.

Software Product Line Engineering (SPLE) has been proven to reduce development and maintenance costs, improving the time-to-market, and increasing the quality of product variants developed from a product family via systematic reuse of its core assets. SPLE has been successfully used in the development of safety-critical systems, especially in automotive and aerospace domains. Safety-critical systems have to be developed according to safety standards, which demands safety analysis, Fault Tree Analysis (FTA), and assurance cases safety engineering artefacts. However, performing safety analysis, FTA, and assurance case construction activities from scratch and manually for each product variant is time-consuming and error-prone, whereas variability in safety engineering artefacts can be automatically managed with the support of variant management techniques. As safety is context-dependent, context and design variation directly impact in the safety properties changing hazards, their causes, the risks posed by these hazards to system safety, risk mitigation measures, and FTA results. Therefore, managing variability in safety artefacts from different levels of abstraction increases the complexity of the variability model, even with the support of variant management techniques. To achieve an effective balance between benefits and complexity in adopting an SPLE approach for safety-critical systems it is necessary to distinguish between reusable safety artefacts, whose variability should be managed, and those that should be generated from the reused safety artefacts. On the other hand, both industry and safety standards have recognized the use of model-based techniques to support safety analysis and assurance cases. Compositional safety analysis, design optimization, and model-based assurance cases are examples of techniques that have been used to support the generation of safety artefacts required to achieve safety certification. This thesis aims to propose a model-based approach that integrates modelbased development, compositional safety analysis, and variant management techniques to support the systematic reuse and generation of safety artefacts in safety-critical software product line engineering. The approach contributes to reduce the effort and costs of performing safety analysis and assessment for a particular product variant, since such analysis is performed from the reused safety artefacts. Thus, variant-specific fault trees, Failure Modes and Effects Analysis (FMEA), and assurance case artefacts required to achieve safety certification can be automatically generated with the support the model-based safety analysis and assurance case construction techniques.

Automotive manufacturing ranks among the most extreme instances of systems and software product line engineering (PLE). The product family numbers in the millions, each product is highly complex in its own right, and the variation across products is literally astronomical in scale. This paper explores the aspects that make the domain extreme and the very specific implications they have for PLE. These implications include the need for efficient manufacturing, complexity management, concurrent development streams, globally distributed engineering and production, a hierarchical product family tree, multi-level variation binding, constraint management, and a highly robust and integrated PLE tooling environment. Happily, the PLE paradigm supporting these implications brings about a number of opportunities for analysis and automation that provide efficiencies of production previously unattainable. We focus on one example in depth: The management and automated generation of the many thousands of calibration parameters that determine vehicle-specific software behavior. Throughout, we use the vehicle product line at General Motors, which we believe to be the world's largest, to illustrate and ground our journey through automotive PLE.

IBED: Combining IBEA and DE for optimal feature selection in software product line engineering

Software Product Line Engineering (SPLE) has drawn large amounts of attention during the last two decades as it offers the benefits of reducing cost and time to market by reusing requirements and components. Recently, more and more large scale industries start to implement SPLE in their domains (combining SPLE with model-based modelling methods). However, the problem of how to combine SPLE with Model-Based System Engineering is still a challenge, as systems are much broader than the software domain. Unlike software engineering, system engineering has to consider the physical resources aspect. This paper classifies typical types of physical variability and provides general modelling solutions for each type of physical variation at the system design stage. Specifically, this approach combines a variability model with a SysML Block Definition Diagram and an Internal Block Diagram to model the contextual variability, architectural variability, connector variability, instance number variability, component variability, location variability and evolutional variability of physical designs. Variability is modelled separately to help reduce the complexity of design models. Last but not least, the proposed method is illustrated by an aircraft system case study.

Software Product Line Engineering (SPLE) is a software development paradigm that aims at reducing the development effort and shorting time-to-market through systematic software reuse. While this paradigm has been successfully applied for the development of embedded systems in various domains, new challenges have emerged from the development of safety critical systems that require certification against a specific standard. Existing SPLE approaches do not explicitly consider the various certification standards or levels that products should satisfy. In this paper, we focus on several practical issues involved in the SPLE process, establishing an infrastructure of a product line engineering for certified products. A metamodel is proposed to capture the entities involved in SPL certification and the relationships among them. ProLiCES, which is a model-driven process for the development of SPLs, was modified to serve as an example of our approach, in the context of the UAV (Unmanned Aerial Vehicle) domain.

Due to ever-evolving software developments processes, companies are motivated to develop desired quality products quickly and effectively. Industries are now focusing on the delivery of configurable systems to provide several services to a wide range of customers by making different configurations in a single largest system. Nowadays, component-based systems are highly demanded due to their capability of reusability and restructuring of existing components to develop new systems. Moreover, product line engineering is the major branch of the component-based system for developing a series of systems. Software product line engineering (SPLE) provides the ability to design several software modifications according to customer needs in a cost-effective manner. Researchers are trying to tailor the software product line (SPL) process that integrates agile development technologies to overcome the issues faced during the execution of the SPL process such as delay in product delivery, restriction to requirements change, and exhaustive initial planning. The selection of suitable components, the need for documentation, and tracing back the user requirements in the agile-integrated product line (APL) models still need to improve. Furthermore, configurable systems demand the selected features to be the least dependent. In this paper, a hybrid APL model, quality enhanced application product line engineering (QeAPLE) is proposed that provides support for highly configurable systems (HCS) by evaluating the dependency of features before making the final selection. It also has a documentation and requirement traceability function to ensure that the product meets the desired quality. Two-fold assessments are undertaken to validate the suggested model, with the proposed model being deployed on an active project. After that, we evaluated the proposed model performance and effectiveness using after implementing it in a real-world environment and compared the results with an existing method using statistical analysis. The results of the experimental study proofs that the proposed model is practically and statistically significant as compared to the existing method in terms of effectiveness and participants’ performance. Hence, the statistical results of the comparative analysis show that the proposed model improved ease of understanding and adaptability, required effort, high-quality achievement, and version management are significant i.e., more the 50% as compared to the exiting method i.e., less than 50%. The proposed model offers to assist in the development of a highly configurable system that achieves the needed quality. Therefore, the proposed model manages the variation identification, versions control, components dependency for correct selection of components, and validation activities from domain engineering to application engineering.

Software Product Line Engineering (SPLE) is a software engineering paradigm that focuses on reuse and variability. Although feature-oriented programming (FOP) can implement software product line efficiently, we still need a method to generate and prove correctness of all product variants more efficiently and automatically. In this context, we propose to manipulate feature modules which contain three kinds of artifacts: specification, code and correctness proof. We depict a methodology and a platform that help the user to automatically produce correct-by-construction product variants from the related feature modules. As a first step of this project, we begin by proposing a language, GFML, allowing the developer to write such feature modules. This language is designed so that the artifacts can be easily reused and composed. GFML files contain the different artifacts mentioned above.The idea is to compile them into FoCaLiZe, a language for specification, implementation and formal proof with some object-oriented flavor. In this paper, we define and illustrate this language. We also introduce a way to compose the feature modules on some examples.

Structuring the modeling space and supporting evolution in software product line engineering

Context. From recent works on product properties resulting from configurations and the optimisation of these properties, one comes quickly to more complex challenges such as multi-objective optimisation, conflicting objectives, multiple stakeholders, and conflict resolution. The intuition is that Software Product Line Engineering (SPLE) can draw from other disciplines that deal with decision spaces and complex decision scenarios.Objectives. We aim to (1) explore links to such disciplines, (2) systematise and compare concepts, and (3) identify opportunities, where SPLE approaches can be enriched.Method. We undertake an exploratory study: Starting from common SPLE activities and artefacts, we identify aspects where we expect to find corresponding counterparts in other disciplines. We focus on Multiple Criteria Decision Analysis (MCDA), Multi-Objective Optimisation (MOO), and Design Space Exploration (DSE), and perform a comparison of the key concepts.Results. The resulting comparison relates SPLE activities and artefacts to concepts from MCDA, MOO, and DSE and identifies areas where SPLE approaches can be enriched. We also provide examples of existing work at the intersections of SPLE with the other fields. These findings are aimed to foster the conversation on research opportunities where SPLE can draw techniques from other disciplines dealing with complex decision scenarios.

Version control (VC) and Software Product Line Engineering (SPLE) are two software engineering disciplines to manage variability in time and variability in space. In this paper, a thorough comparison of VC and SPLE is provided, showing that both disciplines imply a number of desirable properties. As a proof of concept for the combination of VC and SPLE, we present SuperMod, a tool realizes an existing conceptual framework that transfers the iterative VC editing model to SPLE. The tool allows to develop a software product line in a single-version workspace step by step, while variability management is completely automated. It offers familiar version control metaphors such as check-out and commit, and in addition uses the SPLE concepts of feature models and feature configuration the definition of logical variability and to define the logical scope of a change. SuperMod has been implemented in a model-driven way and primarily targets EMF models as software artifacts. We successfully apply the tool to a standard SPLE example.

<title>ABSTRACT</title> <p>The ISO 26580 Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering (PLE)<xref rid="R1" ref-type="bibr">1</xref> standard provides the guidance and direction to be successfully applied to military ground vehicle systems. Implementing PLE provides military stakeholder benefits such as increased commonality, functionality, quality, and productivity, while also delivering decreased risk and cost. Moreover, these benefits last through multiple generations of ground vehicle sytems. Merging PLE into a Digital Engineering (DE)/Model-based System Engineering (MBSE) environment is a critical proven combination for successful automotive manufacturers today. This same approach can be extended to the military ground vehicle family of vehicles resulting in the ability to rapidly design, assess, evaluate, simulate, manage, and instantiate product variants from a common feature catalog.</p>

Software product-line engineering is arguably one of the most successful methods for establishing large portfolios of software variants in an application domain. However, despite the benefits, establishing a product line requires substantial upfront investments into a software platform with a proper product-line architecture, into new software-engineering processes (domain engineering and application engineering), into business strategies with commercially successful product-line visions and financial planning, as well as into re-organization of development teams. Moreover, establishing a full-fledged product line is not always possible or desired, and thus organizations often adopt product-line engineering only to an extent that deemed necessary or was possible. However, understanding the current state of adoption, namely, the maturity or performance of product-line engineering in an organization, is challenging, while being crucial to steer investments. To this end, several measurement methods have been proposed in the literature, with the most prominent one being the Family Evaluation Framework (FEF), introduced almost two decades ago. Unfortunately, applying it is not straightforward, and the benefits of using it have not been assessed so far. We present an experience report of applying the FEF to nine medium- to large-scale product lines in the avionics domain. We discuss how we tailored and executed the FEF, together with the relevant adaptations and extensions we needed to perform. Specifically, we elicited the data for the FEF assessment with 27 interviews over a period of 11 months. We discuss experiences and assess the benefits of using the FEF, aiming at helping other organizations assessing their practices for engineering their portfolios of software variants.

Software product-line engineering is one of the few approaches to software engineering that shows promise of improving software productivity by factors of 5 to 10. There are still few examples of its successful application on a large scale, partly because of the complexity of initiating a product-line engineering project and the many factors that must be addressed for such a project to be successful. This tutorial draws on experiences in introducing and sustaining product-line engineering in Lucent Technologies and in Avaya. The objective is to convey to participants the obstacles involved in transitioning to product line engineering and how to overcome such obstacles, particularly in large software development organizations. Participants will learn both technical and organizational aspects of the problem. Participants will leave the tutorial with many ideas on how to introduce product line engineering into an organization in a systematic way.

Agile Software Development (ASD) and Software Product Line Engineering (SPLE) methodologies have proved significant benefits in software development. Although they pursue common promises (faster time-to-market, better quality and lower cost), many of their foundations are completely different. ASD focuses on requirements at hand and proposes continuous delivery of valuable software by short time-framed iterations.Instead, SPLE exploits the commonality across the products of a same family by investing on an upfront design of reusable assets (domain engineering) which are assembled into customer-specific products (application engineering).KeywordsDomain EngineeringAgile MethodAgile PracticeAgile Software DevelopmentProduct Line EngineeringThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.