ICSE 2013


System-of-Systems Platform Scoping
John Klein and John McGregor

In a system of systems, interoperability among constituent systems is a primary architecture concern. One architecture strategy to promote interoperability in this design context is to create a system-of-systems platform to provide certain common services to all constituent systems, with the goal of reducing development effort for the constituent systems and reducing integration and assurance cost for the system of systems. A successful system-of-systems platform must balance sufficient commonality to support economical reuse, while also providing variability and extensibility to enable innovation in system and system of systems capabilities. These commonality/variability tradeoffs for system-of-systems platforms are frequently tacit decisions, since there are no existing techniques for analyzing such decisions at the scale and degree of requirements uncertainty that characterize most systems of systems.


Variability Support for Variant-Rich Software Ecosystems
Klaus Schmid

Lately, software ecosystems have generated a lot of attention as they are very important to modern software industry. Over the course of several research projects, we addressed the problem of variability-rich software ecosystems and their relation to software product lines in our research group. This paper summarizes some of the problems we identified and describes some solutions we created both on a conceptual level and implemented in a prototype tool environment.


Moving Towards Industrial Software Ecosystems: Are our Software Architectures Fit for the Future?
Klaus-Benedikt Schultis, Christoph Elsner and Daniel Lohmann

The development of large-scale software product-lines within large enterprises commonly involves various internal business units. Although within the same enterprise, each business unit has individual motivations and participation interests. For coordinating development, the emerging discipline of software ecosystems intents to explicitly discover and analyze the different players' interests, and manage them, often by means of a suitable software architecture. Already within a single enterprise, this discipline can be of high value. Instead of detailed managerial orders to coordinate internal interactions, an analysis of the players, their interests, and a suitable software architecture may slacken organizational structures and simplify processes. We have started to analyze the ecosystems of several Siemens internal product-lines in order to determine the different players and their interests, and to derive suitable software architectural requirements from this setting. This will enable us to compare these requirements to the actual architecture, for identifying reusable pain points and best practices of the existing system. However, there is no systematic (A) approach to model and analyze the collaboration among the participants from a technical perspective, as well as (B) to derive reusable architectural design-patterns and anti-patterns from such software ecosystems. By illustrating these problems using an existing software product-line that moves towards a software ecosystem, we are looking for answers to the two questions above to evaluate whether our product-lines are fit for a future as internal software ecosystems.


How to exploit domain knowledge in multi product lines?
Simon Urli, Sebastien Mosser, Mireille Blay-Fornarino and Philippe Collet

As Software Product Lines (SPL) are inevitably moving towards a multiple form to tackle issues of reuse and complexity, variability management across the composed SPLs is still addressed with basic inter-constraints. Based on two disjoint case studies (digital signage and cloud computing), we identified this challenging problem for the SPL community. In this paper we describe how the domain knowledge needs to be exploited to support a more complete definition of Multiple Software Product Lines (MSPL). Such an exploitation implies the definition of a domain-driven definition of configuration and an order independent configuration process.


What Makes It Hard to Apply Software Product Lines to Educational Technologies?
Sridhar Chimalakonda and Kesav Vithal Nori

In this paper, we present our experience of mining a software product line (SPL) from 9 existing eLearning systems developed at 9 different locations by 9 different teams following 9 varied development processes over a decade. The goal of this family of eLearning systems is to address 287 million adult illiterates in India spread across 22 Indian languages. This presents a unique and challenging situation as the SPL arises from a societal context rather than a business context as in traditional SPL. We explain the context of this domain and present the key challenges of mining an SPL from these eLearning systems. The main intent of this paper is to present our journey of applying SPL to these legacy eLearning systems in the last six years. Finally, we briefly discuss the ideas of Lean Software Product Lines and Global Software Product Lines as two potential future research directions for the SPL community.


Challenges in Managing Behavior Variability of Production Control Software
Miao Fang, Georg Leyh, Christoph Elsner and Jörg Dörr

Software product line engineering helps organizations to achieve systematic software reuse by taking advantage of commonalities and predicted variability. Variability management has been considered as one important issue in product line development. In this paper, a variability analysis in production control systems reveals that the variability in such systems lays in the dynamic behavior and interaction of configured components, which we consider as behavior variability. This paper identifies the three main challenges to be solved for applying a product line approach to the domain of production control systems: (1) the selection or design of a proper variability language for describing the flexible behavior variability, (2) the need to model variability of behavior at different levels of granularity, as well as to map the elements among different levels, (3) the binding of behavioral variation points and variants into the various involved systems in a manageable way.


Graphical User Interfaces in Dynamic Software Product Lines
Dean Kramer, Samia Oussena, Peter Komisarczuk and Tony Clark

Dynamic Software Product Line Engineering has gained interest through its promise of being able to unify software adaptation whereby software can be configured at compile time and runtime. While previous work has concentrated on language support and other platform support, little attention has been placed on graphical user interface variability. In this paper, we present the motivation for handling dynamic graphical user interface variability and the challenges that require tackling to enable this.


Knowledge-assisted Product Requirements Configurator
Preethu Rose, Shashikant Sharma, Manish Motwani and Smita Ghaisas

Producing timely and customer oriented products is a key determinant for the success of any product-based business. Product requirement elicitation and configuration practices therefore play a major role in taking products to market efficiently. Knowledge of the existing generic product is crucially important while creating its variants. In this paper, we discuss an ontological representation of product primitives for a knowledge-assisted requirements configurator and illustrate its use for a financial product suite.


Variability in Software Process Models: Requirements for Adoption in Industrial Settings
Jocelyn Simmonds, María Cecilia Bastarrica, Luis Silvestre and Alcides Quispe

It is an increasing trend to apply Software Product Line (SPL) concepts and techniques for software process tailoring, generating a Software PRocess Line (SPrL). However, there are several aspects that must be addressed before SPrLs can be fully adopted by industry, a key aspect being how software process variability is specified and managed. In the literature, there are several general-purpose as well as domain-specific proposals for specifying process variability. In this paper, we analyze the benefits and drawbacks of two general-purpose (feature models and OVM) and two domain-specific (SPEM variability primitives and vSPEM) approaches, as well as discuss what hinders industry adoption in each case.


Products as Product Lines
Grady Campbell

An argument is made that a product line approach can be beneficial for even single product development, particularly for products that support customers whose needs are likely to change over time. Furthermore, product line techniques for identifying requirements and design alternatives and documenting rationale for decisions would benefit any product development effort.


Domain Analysis for Mining Software Repositories -Towards Feature-based DSL Construction
Changyun Huang, Kazuhiro Yamashita, Yasutaka Kamei, Kenji Hisazumi and Naoyasu Ubayashi

The mining software repositories (MSR) analyze data stored in software repositories and discover meaningful information to support software development. However, MSR is complex due to conducting large scale data collection with various repositories. To help practitioners perform MSR analysis, one possible way is to apply the approaches of software product line (SPL) to the MSR domain to understand variability and commonality for the domain, and to construct domain specific languages (DSLs) because DSLs have high readability to reduce the complexity of the procedure of MSR. In this paper, we construct a SQL-based DSL to support MSR and provide a systematic approach to conduct Feature-Oriented Domain Analysis (FODA) for MSR towards the construction of the DSL. We provide the syntax of the DSL and explain how to locate language elements of the DSL to the four-layer structure used in FODA.


RECoVar: A Solution Framework towards Reverse Engineering Variability
Bo Zhang and Martin Becker

As a Software Product Line (SPL) evolves variability specifications in problem space and variability realizations in solution space erode over time and impact productivity during development. On the one hand, the variability model tends to be incomplete and inconsistent with the core assets; on the other hand, the core assets become overly complex, which make them difficult to understand and maintain. In this paper, we present the RECoVar framework towards reverse engineering of SPL variability. The framework includes two approaches: a) code-based variability model extraction; and b) complex feature correlation mining. These two approaches help to extract various variability information, so that variability specifications and realizations can be maintained in an efficient way.


Requirements-based Delta-oriented SPL Testing
Michael Dukaczewski, Ina Schaefer, Remo Lachmann and Malte Lochau

Variability of modern software systems increases potential sources of errors and demands appropriate quality assurance strategies. In order to reduce the test effort when testing software product lines, incremental model-based testing strategies have been proposed, based on the conceptual ideas of delta modeling. It requires executable system specifications to derive and classify test cases. However, in industrial practice such system models rarely exist, but requirements and test cases are captured in natural language. In order to make delta-oriented testing strategies applicable in this context, we transfer them to the requirements level and show how a delta-oriented classification of requirements and associated test cases reduce test effort in these less formal domains.


Feature Interaction Testing of Variability Intensive Systems
Sachin Patel, Priya Gupta and Vipul Shah

Testing variability intensive systems is a formidable task due to the combinatorial explosion of feature interactions that result from all variations. We developed and validated an approach of combinatorial test generation using Multi-Perspective Feature Models (MPFM). MPFMs are a set of feature models created to achieve Separation of Concerns within the model. This approach improves test coverage of variability. Results from an experiment on a real-life case show that up to 37% of the test effort could be reduced and up to 79% defects from the live system could be detected. We discuss the learning from this experiment and further research potential in testing variability intensive systems.