Software projects use build systems to automate the compilation, testing, and continuous deployment of their software products. As software becomes increasingly configurable, the build of multiple configurations is a pressing need, but expensive and challenging to implement. The current state of practice is to build independently (a.k.a., clean build) a software for a subset of configurations. While incremental build has been studied for software evolution and relatively small changes of the source code, it has surprisingly not been considered for software configurations. In this exploratory study, we examine the benefits and limits of building software configurations incrementally, rather than always building them cleanly. By using five real-life configurable systems as subjects, we explore whether incremental build works, outperforms a sequence of clean builds, is correct w.r.t. clean build, and can be used to find an optimal ordering for building configurations. Our results show that incremental build is feasible in 100% of the times in four subjects and in 78% of the times in one subject. In average, 88.5% of the configurations could be built faster with incremental build while also finding several alternatives faster incremental builds. However, only 60% of faster incremental builds are correct. Still, when considering those correct incremental builds with clean builds, we could always find an optimal order that is faster than just a collection of clean builds with a gain up to 11.76%.

Feature location is a traceability recovery activity to identify the implementation elements associated to a characteristic of a system. Besides its relevance for software maintenance of a single system, feature location in a collection of systems received a lot of attention as a first step to re-engineer system variants (created through clone-and-own) into a Software Product Line (SPL). In this context, the objective is to unambiguously identify the boundaries of a feature inside a family of systems to later create reusable assets from these implementation elements. Among all the case studies in the SPL literature, variants derived from ArgoUML SPL stands out as the most used one. However, the use of different settings, or the omission of relevant information (e.g., the exact configurations of the variants or the way the metrics are calculated), makes it difficult to reproduce or benchmark the different feature location techniques even if the same ArgoUML SPL is used. With the objective to foster the research area on feature location, we provide a set of common scenarios using ArgoUML SPL and a set of utils to obtain metrics based on the results of existing and novel feature location techniques.

The engineering of a Software Product Line (SPL), either by creating it from scratch or through the re-engineering of existing variants, it uses to be a project that spans several years with a high investment. It is often hard to analyse and quantify this investment, especially in the context of extractive SPL adoption when the related software variants are independently created by different developers following different system architectures and implementation conventions. This paper reports an experience on the creation of an SPL by re-engineering system variants implemented around an educational game called Robocode. The objective of this game is to program a bot (a battle tank) that battles against the bots of other developers. The world-wide Robocode community creates and maintains a large base of knowledge and implementations that are mainly organized in terms of features, although not presented as an SPL. Therefore, a group of master students analysed this variability-rich domain and extracted a Robocode SPL. We present the results of such extraction augmented with an analysis and a quantification regarding the spent time and effort. We believe that the results and the a-posteriori analysis can provide insights on global challenges on SPL adoption. We also provide all the elements to SPL educators to reproduce the teaching activity, and we make available this SPL to be used for any research purpose.

This year at SPLC we present a teaching and research project where a group of master students analysed a variability-rich domain and extracted an SPL (The Robocode SPL). We present the results of such extraction augmented with an analysis and a quantification regarding the time and effort spent. The research objective was to get and share data about an end-to-end SPL extraction which is usually unavailable in industrial cases because of their large size, complexity, and duration. We provide all the material to replicate, reproduce or extend the case study so it can be easily reused for teaching by anyone in our community. However, we were asking ourselves how can we leverage such case study for teaching to pursue research objectives. In this position paper, we aim to outline our initial ideas that we want to enrich with the others' viewpoints during SPLTea. Towards planning the settings of future teaching projects around this Robocode SPL case study, which can be the timely research objectives that we can identify? Can we involve others in planning this project in their institutions to get further relevant results?