Challenges for Requirements Engineering and Management in Software Product Line Development

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.

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

Social network services allow a large population of end-users of software products to publicly share their concerns and experiences about software systems. From a software engineering perspective, such data can be collected and analyzed to help software development organizations to infer users’ emerging demands, receive their feedback, and plan the rapid evolution of software product lines. For the evolution of software product lines, organizations supplement emerging requirements in their products to meet user’s needs and also to retain their dominance in the market. Therefore, social network services, being a communication channel, have supported a number of software development activities such as requirements engineering. It has supported software development organizations to cope with numerous limitations of the traditional requirements engineering approaches by eliciting, prioritizing, and negotiating user requirements. However, these approaches do not consider eliciting requirements in terms of variability and commonality while identifying requirements. To address this issue, we have proposed a social network service-based requirement engineering process. It considers the attributes of users’ opinions to determine variability and commonality. In order to justify our proposed approach, a controlled experiment was conducted on a sample set of end-users on Facebook and Twitter. The experimental results show that the team using the proposed approach performed better in terms of efficiency and effectiveness than the team that used a traditional requirements engineering approach.

Software product lines enable reuse of shared software across a family of products. As new products are built in the product line, new features are added. The features are units of functionality that provide services to users. Unwanted feature interactions, wherein one feature interferes with another feature’s operation, is a significant problem, especially as large software product lines evolve. Detecting feature interactions is a time-consuming and difficult task for developers. Moreover, feature interactions are often only discovered during testing, at which point costly re-work is needed. This paper proposes a similarity-based method to identify unwanted feature interactions much earlier in the development process. It uses knowledge of prior feature interactions stored with the software product line’s feature model to help find unwanted interactions between a new feature and existing features. The paper describes the framework and algorithms used to detect the feature interactions using three path similarity measures and evaluates the approach on a real-world, evolving software product line. Results show that the approach performs well, with 83% accuracy and 60% to 100% coverage of feature interactions in experiments, and scales to a large number of features.

The quality assurance of software product lines (SPL) achieved via testing is a crucial and challenging activity of SPL engineering. In general, the application of single-software testing techniques for SPL testing is not practical as it leads to the individual testing of a potentially vast number of variants. Testing each variant in isolation further results in redundant testing processes by means of redundant test-case executions due to the shared commonality. Existing techniques for SPL testing cope with those challenges, e.g., by identifying samples of variants to be tested. However, each variant is still tested separately without taking the explicit knowledge about the shared commonality and variability into account to reduce the overall testing effort. Furthermore, due to the increasing longevity of software systems, their development has to face software evolution. Hence, quality assurance has also to be ensured after SPL evolution by testing respective versions of variants. In this thesis, we tackle the challenges of testing redundancy as well as evolution by proposing a framework for model-based regression testing of evolving SPLs. The framework facilitates efficient incremental testing of variants and versions of variants by exploiting the commonality and reuse potential of test artifacts and test results. Our contribution is divided into three parts. First, we propose a test-modeling formalism capturing the variability and version information of evolving SPLs in an integrated fashion. The formalism builds the basis for automatic derivation of reusable test cases and for the application of change impact analysis to guide retest test selection. Second, we introduce two techniques for incremental change impact analysis to identify (1) changing execution dependencies to be retested between subsequently tested variants and versions of variants, and (2) the impact of an evolution step to the variant set in terms of modified, new and unchanged versions of variants. Third, we define a coverage-driven retest test selection based on a new retest coverage criterion that incorporates the results of the change impact analysis. The retest test selection facilitates the reduction of redundantly executed test cases during incremental testing of variants and versions of variants. The framework is prototypically implemented and evaluated by means of three evolving SPLs showing that it achieves a reduction of the overall effort for testing evolving SPLs.

As a software product line evolves, it typically introduces new features and includes new products over time. A known cause of software aging in product lines is the introduction of new features that interact in unplanned and even risky ways with the existing features. This can lead to failures, performance degradation, and hazardous states in a new product. Software product line developers currently identify new, unwanted feature interactions primarily in the testing of each new product. This incurs significant costs, comes late in development, and does not exploit the knowledge of prior feature interactions within a product line. The contribution of our paper is to leverage knowledge of prior feature interactions in a product line, together with similarity measures between the features in known feature interactions and the new features, in order to detect similar feature interactions in a new product much earlier in the development process. Results from application to a case study from the literature show that this approach accurately detected 73% of feature interactions. This small study suggests that using similarity measures at the feature level within a product line to detect problematic interactions involving a new feature can effectively reduce this cause of aging in a software product line.

Academic and commercial approaches to software product line development have concentrated on the rapid instantiation of source code assets to minimise product time to market. Generative programming and model-based software engineering approaches have been suggested as effective ways of achieving this. However, for high-integrity software systems the instantiated product source code has to be accompanied by development process assets that demonstrate and support the product assurance arguments. This paper describes an approach to the model-based development of software product lines that is specifically designed to address the needs of high-integrity software systems. The approach consists of a reference architecture model and component-based development style, supported by model transformations to instantiate the project-specific components and associated development assets.

Software product lines (PLs) are large, complex systems, demanding high maintainability and enhanced flexibility. Nonetheless, in the state of the art PL methods, features are scattered and tangled throughout the system components, leading to poor maintainability. Additionally, the majority of PL methods support manual product composition, while the implementation of feature-level variability in PL products influences the system's conceptual integrity. Generative programming techniques do enhance flexibility, but on the cost of maintainability. The feature-architecture mapping (FArM) method provides a stronger mapping between features and the architecture. It is based on a series of transformations on the initial PL feature model. During these transformations, architectural components are derived, encapsulating the business logic of each transformed feature and having interfaces reflecting the feature interactions. The flexibility of FArM architectures is supported through the explicit integration of plug-in mechanisms. The methodology is evaluated in the context of a wireless handheld device PL.

Product derivation is an important part of the Software Product Line (SPL) development process. The quality of a product derivation process has a direct impact in decreasing software product costs and time-to-market. In this paper, we present an approach that represents the SPL with a set of integrated models and automatically derives executable products with model transformations. We combine SPL and Model-Driven Engineering (MDE) into a comprehensive and extremely effective framework in order to get advantages of both techniques. In order to evaluate the feasibility of our approach, we have designed and implemented it using existing and available technologies. Keywords: Product derivation, Software product line, Domain specific language, Model‑driven engineering. DOI: https://doi.org/10.18267/j.aip.90

Software Product Line (SPL) development is a new approach to software engineering that aims at the development of a whole range of products. One of the problems which hinders the adoption of that approach is related with the management of the products of the line. Additionally, the scope of a software product line is determined by the bounds of the capabilities provided by the collection of products in the product line. This introduces new challenges related to the scope problem. One of the main three different forms of scoping is the Product Portfolio Scoping (PPS). PPS aims at defining the products that should be developed as well as their key features. While this has an impact on the actual reuse opportunities, it is usually driven from marketing aspects. Defining a product portfolio by considering costumers satisfaction and cost aspects is a NP-hard problem. This work presents a hybrid approach, which combines fuzzy inference systems and the multi-objective metaheuristics NSGAII to support product management by generating portfolios of products, based in segments of users and the development cost of the assets of the SPL. Fuzzy inference systems are used to generate development cost of an asset by using coupling, number of code lines and cyclomatic complexity and also to estimate the quality of the products generated by the optimization module of our approach. The NSGA-II metaheuristic is used to search for products minimizing the cost and maximizing the relevance of the candidate products. The results show that the proposed approach is effective in proposing the best products in terms of relevance and cost of the assets.

One of the central activities of software product line development is variability modeling for a product family. Because variability models are needed at various stages of software product line development, determining whether a variability model has been modeled correctly is an essential activity for successful software product line development. Existing studies proposed various methods for analysis of various aspects of correctness of a variability model. In particular, analyzing whether a variability model is consistent or not is considered the most important analysis perspective since it is impossible to configure products from such a model. There are few studies in the software product line field that locate causes of inconsistency in a variability model. Furthermore, these existing methods cannot locate the exact causes of inconsistency due to the fact that the feature model they are based on allows ambiguity in its parent–child relationship or due to the fact that they are designed to produce explanations rather than locations of causes, resulting in producing long and complex explanations as the size of the feature model increases. In this work, we propose a method that determines whether or not a variability model has an inconsistency and identifies the exact locations of its causes if it has an inconsistency. To evaluate the proposed method, we developed a tool that automatically performs all the steps of the method and used it to conduct experiments with 49 models, including real-world variability models. As a result, the proposed method accurately identified all models with an inconsistency and located all causes of inconsistency in them.

In the face of development of a software-intensive products family in a domain, Software Product Line Engineering (SPLE) itself is a best practice that has been representatively demonstrated by the cases inducted into Software Product Line Hall of Fame. SPLE best practice is supported by various and vivid meta best practices generated from concrete activities through solution finding processes. This paper describes the evolution of the FISCAN MTMSIS software product line, nominated to the Hall of Fame at SPLC 2010. FISCAN applies SPLE in the security inspection domain and has identified SPLE best practices through years of experience in the past. This paper discusses some representative best practices and the lessons we learned during the process. More work, both development and research, are still in progress on the platform of the MTMSIS software product line and FISCAN will continue to apply SPLE in the future.

Managing the evolution of system families in space and time, i.e., system variants and their revisions is still an open challenge. The software product line (SPL) approach can support the management of product variants in space by reusing a common set of features. However, feature changes over time are often necessary due to adaptations and/or bug fixes, leading to different product versions. Such changes are commonly tracked in version control systems (VCSs). However, VCSs only deal with the change history of source code, and, even though their branching mechanisms allow to develop features in isolation, VCS does not allow propagating changes across variants. Variation control systems have been developed to support more fine-grained management of variants and to allow tracking of changes at the level of files or features. However, these systems are also limited regarding the types and granularity of artifacts. Also, they are cognitively very demanding with increasing numbers of revisions and variants. Furthermore, propagating specific changes over variants of a system is still a complex task that also depends on the variability-aware change impacts. Based on these existing limitations, the goal of this doctoral work is to investigate and define a flexible and unified approach to allow an easy and scalable evolution of SPLs in space and time. The expected contributions will aid the management of SPL products and support engineers to reason about the potential impact of changes during SPL evolution. To evaluate the approach, we plan to conduct case studies with real-world SPLs.

A code smell is any symptom in the source code that possibly indicates a bad design or programming problem. Many code smells in aspect-oriented programming (AOP) are very different from those in object-oriented programming. Therefore, new detection strategies should be conceived to identify whether a particular slice of aspect-oriented code is affected by a specific smell. Unfortunately, research on AOP usually focuses on providing abstract descriptions of code smells, without providing operational definitions of their detection strategies. Such strategies are becoming increasingly required due to the growing use of AOP in the development of long-living systems, including frameworks, libraries and software product lines. This paper presents a family of metric-based strategies that support the detection of recurring smells observed in existing aspect-oriented systems. We analyzed the accuracy of such smell detection strategies and also of those previously reported in the literature. Our study involved in total 17 releases of 3 evolving aspect-oriented systems from different domains. The outcome of our evaluation suggests that strategies for previously-documented AOP smells do not present a satisfactory accuracy. Our analysis also revealed that: (1) newly-discovered strategies achieved better results than well-known ones, and (2) the detection strategies seem to have high accuracy with respect to the identification of both trivial and non-trivial code smells.

Control systems for autonomous robots are concurrent, distributed, embedded, real-time and data intensive software systems. A real-world robot control system is composed of tens of software components. For each component providing robotic functionality, tens of different implementations may be available. The difficult challenge in robotic system engineering consists in selecting a coherent set of components, which provide the functionality required by the application requirements, taking into account their mutual dependencies. This challenge is exacerbated by the fact that robotics system integrators and application developers are usually not specifically trained in software engineering. In various application domains, software product line (SPL) development has proven to be the most effective approach to face this kind of challenges. In a previous paper [D. Brugali and N. Hochgeschwender, Managing the functional variability of robotic perception systems, in First IEEE Int. Conf. Robotic Computing, 2017, pp. 277–283.] we have presented a model-based approach to the development of SPL for robotic perception systems, which integrates two modeling technologies developed by the authors: The HyperFlex toolkit [L. Gherardi and D. Brugali, Modeling and reusing robotic software architectures: The HyperFlex toolchain, in IEEE Int. Conf. Robotics and Automation, 2014, pp. 6414–6420.] and the Robot Perception Specification Language (RPSL) [N. Hochgeschwender, S. Schneider, H. Voos and G. K. Kraetzschmar, Declarative specification of robot perception architectures, in 4th Int. Conf. Simulation, Modeling, and Programming for Autonomous Robots, 2014, pp. 291–302.]. This paper extends our previous work by illustrating the entire development process of an SPL for robot perception systems with a real case study.