A product line organization using an open development method

Opening access to the source code for a product is a business strategy that is increasingly used as the basis for innovative collaborations with stakeholders. The strategy has been successful at producing a large quantity of high-quality software. A tactic in this strategy is to effectively use the efforts of many widely dispersed professionals. The processes, software tools and the communication mechanisms used to facilitate concurrent development by a large number of people are of as much interest as the software being created. In this position paper we present our view of how a software product line organization might operate if it used an open development method (ODM) but is not necessarily producing open source software. We will describe a hypothetical product line (HPL), which is part speculation, part our experience, and partly the experience of others

A Model of Open Source Software-Based Product Line Development

Software Product Line (SPL) and Open Source Software (OSS) have emerged as successful modes of developing software. There is an increased interest in developing suitable approaches for combining the promised advantages of SPL andOSS. Researchers and practitioners have been emphasizing the need of exploiting the ever growing repositories ofOSScomponents for developing SPLs. However, there is no conceptual model for guiding the process of developing OSS-based SPLs. In this paper, we propose a model for developing software product line using open source software. This paper identifies and elaborates the essential phases and activities of the proposed model of developing OSS-based SPLs. This model emphasizes the vital role of software architecture and asserts that software architectures ofOSScan be exploited to establish a SPL. To demonstrate this, we have evaluated Eclipse’s architecture for its potential to support different flavors of a system

Open-source software product line extraction processes: the ArgoUML-SPL and Phaser cases

Software Product Lines (SPLs) are rarely developed from scratch. Commonly, they emerge from one product when there is a need to create tailored variants, or from existing variants created in an ad-hoc way once their separated maintenance and evolution become challenging. Despite the vast literature about re-engineering systems into SPLs and related technical approaches, there is a lack of detailed analysis of the process itself and the effort involved. In this paper, we provide and analyze empirical data of the extraction processes of two open source case studies, namely ArgoUML and Phaser. Both cases emerged from the transition of a monolithic system into an SPL. The analysis relies on information mined from the version control history of their respective source-code repositories and the discussion with developers that took part in the process. Unlike previous works that focused mostly on the structural results of the final SPL, the contribution of this study is an in-depth characterization of the processes. With this work, we aimed at providing a deeper understanding of the strategies for SPL extraction and their implications. Our results indicate that the source code changes can range from almost a fourth to over half of the total lines of code. Developers may or may not use branching strategies for feature extraction. Additionally, the problems faced during the extraction process may be due to lack of tool support, complexity on managing feature dependencies and issues with feature constraints. We made publicly available the datasets and the analysis scripts of both case studies to be used as a baseline for extractive SPL adoption research and practice.This research was partially funded by CNPq, grant no. 408356/2018-9; FAPPR, grant no. 51435; and FAPERJ PDR-10 Fellowship 202073/2020. Open access funding provided by Johannes Kepler University Lin

Trust Challenges in Reusing Open Source Software: An Interview-based Initial Study

Open source projects play a significant role in software production. Most of the software projects reuse and build upon the existing open source projects and libraries. While reusing is a time and cost-saving strategy, some of the key factors are often neglected that create vulnerability in the software system. We look beyond the static code analysis and dependency chain tracing to prevent vulnerabilities at the human factors level. The literature lacks a comprehensive study of the human factors perspective on the issue of trust in reusing open source projects. We performed an interview-based initial study with software developers to get an understanding of the trust issue and limitations among the practitioners. We outline some of the key trust issues in this paper and lay out the first steps toward the trustworthy reuse of software.Comment: To appear in Proceedings of 26th ACM International Systems and Software Product Line Conference - Volume

ISA PACKAGER: a Tool for SPL Deployment

In software projects, and particularly in Software Product Line (SPL) projects, product composition and deployment are tasks that are not supported by open source tools. These tasks are repetitive and error-prone. Automation helps on reducing the errors while the productivity increases. in this paper we present a real-world experience through ISA Packager, a generic tool to package and deploy SPLs. in this experience we build a SPL of SCADAs (Supervisory Control and Data Acquisition). Each customized SCADA product evolves in time and ISA Packager is in charge of easing product maintenance and updating

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

Adapting Open Source Software for Establishing Product Line Infrastructures

While we\u27re exploring two research projects (i.e., a system for virtual office of the future and an ambient intelligent system for assistant living), we could adapt open source software (workflow engine and middleware platform) to build product line infrastructures of the systems. Our experiences from both projects show that the product line architectures of the target systems played a key role for the adaptation of OSS. During the seminar, our experiences and questions arose from the projects will be discussed

Quality Assessment and Prediction in Software Product Lines

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