Software product line scoping: A systematic literature review

Software product line (SPL) scoping is important for planning upfront investment. One challenge with scoping comes from inaccuracies in estimated parameters and uncertainty in environment. In this paper, a method to incorporate uncertainty in SPL scoping optimization and its application to generate robust solutions is proposed. We model scoping optimization as a multi-objective problem with profit and stability as heuristics. To evaluate our proposal, a number of experiments are conducted. Analysis of results show that both performance stability and feasibility stability were improved providing the product line manager enhanced decision-making support.

The extractive adoption of Software Product Lines (SPL) relies on the reuse of the already developed systems, employing a reengineering process. However, due to the diversity of options found in the daily practice of SPL development, rigorous planning of scenarios is critical to perform SPL reengineering. This diversity is the result of different organizational aspects, such as team experience and product portfolio. Hence, a proper planning process must consider technical and organizational aspects, however, most existing studies in the field do not take into account organizational aspects of the companies. In this work, we present SPLReePlan, an automated framework to aid the SPL reengineering planning taking into account technical and organizational aspects. Our framework is supported by a web-based tool, ready to be used in the industry. To investigate how flexible is SPLReePlan to support the SPL reengineering planning in diverse situations, we extracted eight different scenarios from the SPL literature, which are used as input for the evaluation of SPLReePlan. The results indicate that SPLReePlan can be satisfactorily customized to a variety of scenarios with different artifacts, feature retrieval techniques, and reengineering activities. As a contribution, we discuss the lessons learned within the evaluation, and present challenges that were faced, being a source of information for tool builders or motivating new studies.

A systematic mapping study on software product line evolution: From legacy system reengineering to product line refactoring

Software product family or line is a software engineering paradigm that systematizes reuse. In software product line engineering, two phases are distinguished: domain engineering which is in charge of developing a common infrastructure and assets and application engineering which makes use of those assets to generate the products. One of the key aspects of product lines is variability and its management. However, the main focus has been on functional variability and quality variability in software product lines has not received so much attention by researchers. In a product line different members of the line may require different levels of a quality requirement, for instance they could differ in terms of their availability, security, reliability, etc. Due to this variability, quality evaluation in software product lines is much more complicated that in single-systems. One alternative is to evaluate all the products of a line but it is very expensive and ways of reducing evaluation efforts are necessary. In this direction, the paper presents a method for facilitating cost-effective quality evaluation of a product line taking into consideration variability on quality attributes.

In the software product line research, product variants typically differ by their functionality and quality attributes are not purposefully varied. The goal is to study purposeful performance variability in software product lines, in particular, the motivation to vary performance, and the strategy for realizing performance variability in the product line architecture. The research method was a theory-building case study that was augmented with a systematic literature review. The case was a mobile network base station product line with capacity variability. The data collection, analysis and theorizing were conducted in several stages: the initial case study results were augmented with accounts from the literature. We constructed three theoretical models to explain and characterize performance variability in software product lines: the models aim to be generalizable beyond the single case. The results describe capacity variability in a base station product line. Thereafter, theoretical models of performance variability in software product lines in general are proposed. Performance variability is motivated by customer needs and characteristics, by trade-offs and by varying operating environment constraints. Performance variability can be realized by hardware or software means; moreover, the software can either realize performance differences in an emergent way through impacts from other variability or by utilizing purposeful varying design tactics. The results point out two differences compared with the prevailing literature. Firstly, when the customer needs and characteristics enable price differentiation, performance may be varied even with no trade-offs or production cost differences involved. Secondly, due to the dominance of feature modeling, the literature focuses on the impact management realization. However, performance variability can be realized through purposeful design tactics to downgrade the available software resources and by having more efficient hardware.

A software product line (SPL) usually involves a shared set of core assets and a series of application products. To ensure consistency, the evolution of the core assets and all the application products should be coordinated and synchronized under a unified evolution process. Therefore, SPL evolution often involves cross-product propagation and synchronization besides application derivation based on core assets, presenting quite different characteristic from the evolution of individual software products. As software architectures, including the product line architecture (PLA) and application architectures, play a central role in SPL engineering and evolution, architecture-based evolution analysis is a natural way for analyzing and managing SPL evolution. In this paper, we explore common practices of architecture evolution and the rationale behind in industrial SPL development. To this end, we conduct a case study with Wingsoft examination system product line (WES-PL), an industrial product line with an evolution history of eight years and more than 10 application products. In the case study, we reviewed the evolution history of WES-PL architecture and analyzed several typical evolution cases. Based on the historical analysis, we identify some special problems in industrial SPL practice from the aspect of architecture evolution and summarize some useful experiences about SPL evolution decisions to complement classical SPL methodology. On the other hand, we also propose some possible improvements for the evolution management in WES-PL.

Software product line (SPL) is a software engineering paradigm for software development. A software product within a product line often has specific functionalities that are not common to all other products within the product line. Those specific functionalities are termed “variant features” in a product line. SPL paradigm involves the modeling of variant features. However, little work in SPL investigates and addresses the modeling of variant features specific to user interface (UI). Unified Modeling Language (UML) is the de facto modeling language for object-oriented software systems. It is known that UML needs better support in modeling UIs. Thus, much research developed UML extensions to improve UML support in modeling UIs. Yet little of this work is related to developing such extensions for modeling UIs for SPLs in which variant features specific to UI modeling must be addressed. This research develops a UML extension -Web User Interface Modeling Language (WUIML) to address these problems. WUIML defines elements for modeling variant features specific to user interfaces for Web-based SPLs. The model elements in WUIML extend from the metaclass and BasicActivity of the UML2.0 metamodel. WUIML integrates the modeling of variant features specific to user interfaces to UML. For example, in a Web-based patient registration software product line, member products targeting British users may use British date format in the user interface, while member products targeting United States users may use United States date format in the user interface. Thus, this is a variant feature for this product line. WUIML defines a model element, XOR, to represent such exclusive or conditions in a product line user interface model. WUIML would reduce SPL engineers’ efforts needed in UI development. To validate the WUIML research outcome, a case study was conducted. The results of this empirical study indicate that modeling UIs for Web-based SPLs using WUIML is more effective and efficient than using standard UML.

A Software Product Line (SPL) is a set of systems that share a group of manageable features and satisfy the specific needs of a particular domain. The features of an SPL can be used in variable combinations to derive product variants in the SPL domain. Because SPLs promote product development through reuse, it is vital to have a means to measure their quality in terms of quality attributes like complexity, reusability,… In this paper, we propose a set of metrics to evaluate the quality of an SPL at three levels: the feature model, design and code. We adapted a set of metrics for software quality and defined new metrics to deal with the inherent characteristics of SPLs, specifically the feature model and the traceability between features, design and code. Furthermore, to assist in interpreting the quality of a given SPL, we conducted an empirical study over ten open source SPLs to identify thresholds for the proposed metrics.

BackgroundThe software product lines (SPL) enable development teams to fully address a systematic reuse of shared assets to deliver a family of similar software products. Mobile applications are an obvious candidate for employing an SPL approach. This paper presents our research outcomes, based on empirical data from an industry-level development project. Two development teams were confronted with the same functionalities set to be delivered through a family of native mobile applications for Android and iOS.MethodsEmpirical data was gathered before, during and after a year of full-time development. The data demonstrate the impact of a SPL approach by comparing the SPL and non-SPL multiple edition development. One family of products (Android apps) was developed using an SPL approach, while another (iOS apps), functionally the same, was developed without employing an SPL approach. The project generated a volume of raw and aggregated empirical data to support our research questions.ResultsThe paper reports a positive impact of an SPL approach on product quality (internal and external) and feature output per week. As data shows, it also increases the delivery of functionalities (240% in 6 more editions), while investing the same amount of effort needed for a single-edition development. As a result of system-supported separation of development and production code, developers had a high confidence in further development. On the other hand, the second team delivered less new functionalities, only two new application editions, and lower software quality than the team that manages multi-edition development by employing an SPL approach.

At the heart of product line development is the assumption that through structured reuse later products will be of a higher quality and require less time and effort to develop and test. This thesis presents empirical results from two case studies aimed at assessing the quality aspect of this claim and exploring fault prediction in the context of software product lines. The first case study examines pre-release faults and change proneness of four products in PolyFlow, a medium-sized, industrial software product line; the second case study analyzes post-release faults using pre-release data over seven releases of four products in Eclipse, a very large, open source software product line.;The goals of our research are (1) to determine the association between various software metrics, as well as their correlation with the number of faults at the component/package level; (2) to characterize the fault and change proneness of components/packages at various levels of reuse; (3) to explore the benefits of the structured reuse found in software product lines; and (4) to evaluate the effectiveness of predictive models, built on a variety of products in a software product line, to make accurate predictions of pre-release software faults (in the case of PolyFlow) and post-release software faults (in the case of Eclipse).;The research results of both studies confirm, in a software product line setting, the findings of others that faults (both pre- and post-release) are more highly correlated to change metrics than to static code metrics, and are mostly contained in a small set of components/ packages. The longitudinal aspect of our research indicates that new products do benefit from the development and testing of previous products. The results also indicate that pre-existing components/packages, including the common components/packages, undergo continuous change, but tend to sustain low fault densities. However, this is not always true for newly developed components/packages. Finally, the results also show that predictions of pre-release faults in the case of PolyFlow and post-release faults in the case of Eclipse can be done accurately from pre-release data, and furthermore, that these predictions benefit from information about additional products in the software product lines.

Many organizations report dramatic benefits from the adoption of software product line practice. Organizations that have established software engineering process discipline are better poised to succeed with product lines. While we acknowledge that there are different paths to successful process discipline, in this technical note, we concentrate on approaches based on the Capability Maturity Model Integration (CMMI) models. We describe practices that are most crucial to product line success. While some of these relate directly to the CMMI models process areas, others are uniquely important to product lines. In this technical note, we first present fundamental concepts of software product lines. We then describe important product line practices as they have been documented in A Framework for Software Product Line Practice (framework). We next present an overview of the CMMI models, followed by a description of the general relationships between the framework and CMMI models. We amplify this comparison with a detailed example showing the relationship between configuration management practices in CMMI and in the framework. We conclude by describing the ways in which organizations can build upon their process improvement efforts to achieve success with product lines and realize additional benefits through the use of both technologies.

Software Product Lines (SPL) adoption can affect several aspects of an organization and it involves significant investment and risk. This way, SPL risk management is a crucial activity of SPL adoption. This study aims to identify SPL risks during the scoping and requirement disciplines to provide information to better understand risk management in SPL. In order to achieve the previous stated goal, a case study research was applied in an industrial project in the medical information management domain. Using the captured risks, a classification scheme was built and risk mitigation strategies were identified. We spent five months, totaling 79 hours, performing risk management (RM) in the scoping discipline and twelve months, totaling 148 hours, performing RM on the requirements discipline. We identified 32 risks during the scoping discipline and 20 risks during the requirements discipline, 14 risks occurred in both disciplines. Some identified risks are not particular to SPL development, however, they have their impact increased due to the SPL characteristic. All the study results and lessons learned are useful for all project managers and researchers who are considering the introduction of SPL risk management in industry or academia.

Lately, the demand for mobile applications development has increased significantly mainly due to growth of use of mobile devices and the need to port existing web applications. To reduce development’s time and cost, Software Product Lines (SPLs) have also been used in the context of mobile applications. However, the existing SPLs do not worry about supporting the development of mobile applications corresponding to the existing Web applications, as it is desirable to have access to the information and main features of these applications in mobile devices. In face of this problem, this paper discusses the motivation and presents the evolution from a SPL in the e-Gov Web (e-Gov Web SPL) domain to a SPL in the mobile domain (e-Gov Mobile SPL) having in mind the need to supply market demand. The conducted evolution was supported by the PLUS approach (Product Line UML-Based Software Engineering) and by the features model. Furthermore, this work debates the main results obtained through some e-Gov Mobile SPL instantiations in the precision livestock domain.KeywordsSoftware Product LineEvolutione-GovWebMobile

Context: Successful software systems continuously evolve to accommodate feature requests of a diverse customer-base. At some point during this evolution, the variety of customer needs and increased system complexity suggests the consideration of a software product line (SPL).Aim: The goal of this research is to support the decision maker facing the enhancement of an evolving software system (ESS) by determining the most appropriate product line design (out of a given set of candidate SPL portfolios) to minimize the technical risk and maximize the business value.Method: The proposed method called OPTESS is aimed at finding an evolution plan for the ESS which optimizes both the given technical and business objectives. Business analysis using a value-based pricing mechanism is applied to a set of initially proposed SPL portfolios (for enhancing the ESS) such that profit is maximized. Technical analysis is applied to the same initially proposed SPL portfolios to minimize the risk of failure of ESS due to implementation of new features. Business and technical analyses improve the performance of solutions for their respective objectives by modifying the feature sets of candidate SPL portfolios. OPTESS helps the decision maker select a plan for enhancement of an ESS by performing trade- off analysis between economic and technical objectives.Results: The method was initially evaluated through a case study for a set of 9 new candidate features to be added to an open source text editing system called jEdit. OPTESS helped the decision maker to identify 3 non-dominated solutions judged to be the best contenders for addition when considering both technical and economic criteria.

Software Product Line (SPL) is a new methodology that develops software products by configuring a software product from artifacts repository. Variability is one of the important issues in designing SPL. It reflects the diversity and commonality of the artifacts in a product line. The success of SPL is basically dependent on model's variability. SPL contains three main issues: variability modeling, configuration of new software and the analysis of SPL. Validation is a vital operation among all these issues. In the literature, many methods of modeling variability are proposed but none of them focuses on the validation. In this paper, an intelligent method for validating SPL is introduced. The proposed method is based on two layers. The higher layer is a graphical representation (satisfying visualization condition), and the lower layer is logical representation of the variability using first order logic (FOL). The way that the proposed method can be used to model variability, and support the analysis and validation of SPL is described. Later a new operation in SPL validation issue is presented. Finally, the implementation of the two basic operations in the analysis of SPL is illustrated.