Context: Variability (i.e., the ability of software systems or artifacts to be adjusted for different contexts) became a key property of many systems. Objective: We analyze existing research on variability in software systems. We investigate variability handling in major software engineering phases (e.g., requirements engineering, architecting). Method: We performed a systematic literature review. A manual search covered 13 premium software engineering journals and 18 premium conferences, resulting in 15,430 papers searched and 196 papers considered for analysis. To improve reliability and to increase reproducibility, we complemented the manual search with a targeted automated search. Results: Software quality attributes have not received much attention in the context of variability. Variability is studied in all software engineering phases, but testing is underrepresented. Data to motivate the applicability of current approaches are often insufficient; research designs are vaguely described. Conclusions: Based on our findings we propose dimensions of variability in software engineering. This empirically grounded classification provides a step towards a unifying, integrated perspective of variability in software systems, spanning across disparate or loosely coupled research themes in the software engineering community. Finally, we provide recommendations to bridge the gap between research and practice and point to opportunities for future research.

The evolution of Software Product Lines (SPL) is challenging because stakeholders have to deal with both regular evolution and the co-existence of different products. Our focus of product evolution is on the tasks integrators have to perform to update deployed SPL products with minimal interruption of services. In case of Egemin, our industrial partner, the updates of SPL products is further hampered as a consequence of outdated and imprecise architectural knowledge of deployed products. To facilitate the updates of products, we have developed the architecture-centric approach which comprises two complementary parts: an update viewpoint and a supporting tool. In this paper we present an evaluation of the architecture-centric approach. The approach is compared with the Egemin's current update approach in a controlled experiment. In the experiment 17 professionals were asked to perform 68 updates of logistic systems. The results obtained from the experiment show that the architecture-centric approach significantly improves the correctness of updates and reduces the interruption of services during updates of Egemin's SPL products.

Despite the fact that some practitioners and researchers report successful stories on Software Product Lines (SPL) adaptation, the evolution of SPL remains challenging. In our research we study a specific aspect of SPL adaptation, namely on updating of deployed products. Our particular focus is on the correct execution of updates and minimal interruption of services during the updates. The update process has two stages. First, the products affected by the evolution must be identified. We call this stage SPL-wide change impact analysis. In the second stage, each of the affected products has to be updated. In our previous work we have addressed the second stage of the update process. In this paper we report on our early results of the first stage: change impact analysis. We discuss how existing variability models can be employed to support automated identification of the products that require an update. The discussion is illustrated with the examples from an educational SPL that we are developing at K.U. Leuven.

Despite the successes of software product lines (SPL), managing the evolution of a SPL remains difficult and error-prone. Our focus of evolution is on the concrete tasks integrators have to perform to update deployed SPL products, in particular products that require runtime updates with minimal interruption. The complexity of updating a deployed SPL product is caused by multiple interdependent concerns, including variability, traceability, versioning, availability, and correctness. Existing approaches typically focus on particular concerns while making abstraction of others, thus offering only partial solutions. An integrated approach that takes into account the different stakeholder concerns is lacking. In this paper, we present an architectural approach for updating SPL products that supports multiple concerns. The approach comprises of two complementary parts: (1) an update viewpoint that defines the conventions for constructing and using architecture views to deal with multiple update concerns, and (2) a supporting framework that provides an extensible infrastructure supporting integrators of a SPL. We evaluated the approach for an industrial SPL for logistic systems providing empirical evidence for its benefits and recommendations.

Software Engineering is developing very fast. To keep up with the changes, software companies need effective methods of knowledge transfer. In the paper a 3-step approach to knowledge transfer, called Technical Drama, is presented. The paper is focused on transferring knowledge concerning architecture evaluation, but the approach could also be applied to transferring knowledge concerning inspections, testing etc. It is claimed in the paper that the Technical Drama can be useful in the industrial context (two case studies are described) as well as at university (then a kind of software studio is required).