Paulo Anselmo da Mota Silveira Neto’s research while affiliated with Federal Rural University of Pernambuco and other places

Software Product Lines (SPLs) improve time-to-market, enhance software quality, and reduce maintenance costs. Current SPL re-engineering practices are largely manual and require domain knowledge. Thus, adopting and, to a lesser extent, maintaining SPLs are expensive tasks, preventing many companies from enjoying their benefits. To address these challenges, we introduce Foundry , an approach utilizing software transplantation to reduce the manual effort of SPL adoption and maintenance. Foundry enables integrating features across different codebases, even codebases that are unaware that they are contributing features to a software product line. Each product produced by Foundry is pure code, without variability annotation, unlike feature flags, which eases variability management and reduces code bloat. We realise Foundry in prodScalpel , a tool that transplants multiple organs ( i.e. , a set of interesting features) from donor systems into an emergent product line for codebases written in C. Given tests and lightweight annotations identifying features and implantation points, prodScalpel automates feature extraction and integration. To evaluate its effectiveness, our evaluation compares feature transplantation using prodScalpel to the current state of practice: on our dataset, prodScalpel’s use speeds up feature migration by an average of 4.8 times when compared to current practice.

Turnover consists of moving into and out of professional employees in the company in a given period. Such a phenomenon significantly impacts the software industry since it generates knowledge loss, delays in the schedule, and increased costs in the final project. Despite the efforts made by researchers and professionals to minimize the turnover, more studies are needed to understand the motivation that drives Software Engineers to leave their jobs and the main strategies CEOs adopt to retain these professionals in software development companies. In this paper, we contribute a mixed methods study involving semi-structured interviews with Software Engineers and CEOs to obtain a wider opinion of these professionals about turnover and a subsequent validation survey with additional software engineers to check and review the insights from interviews. In studying such aspects, we identified 19 different reasons for software engineers' turnover and 18 more efficient strategies used in the software development industry to reduce it. Our findings provide several implications for industry and academia, which can drive future research.

Computational notebooks, such as Jupyter, have been widely adopted by data scientists to write code for analyzing and visualizing data. Despite their growing adoption and popularity, few studies were found to understand Jupyter development challenges from the practitioners’ point of view. This paper presents a systematic study of bugs and challenges that Jupyter practitioners face through a large-scale empirical investigation. We mined 14,740 commits from 105 GitHub open-source projects with Jupyter notebook code. Next, we analyzed 30,416 Stack Overflow posts, which gave us insights into bugs that practitioners face when developing Jupyter notebook projects. Next, we conducted nineteen interviews with data scientists to uncover more details about Jupyter bugs and to gain insight into Jupyter developers’ challenges. Finally, to validate the study results and proposed taxonomy, we conducted a survey with 91 data scientists. We also highlight bug categories, their root causes, and the challenges that Jupyter practitioners face.

Computational notebooks, such as Jupyter, have been widely adopted by data scientists to write code for analyzing and visualizing data. Despite their growing adoption and popularity, there has been no thorough study to understand Jupyter development challenges from the practitioners' point of view. This paper presents a systematic study of bugs and challenges that Jupyter practitioners face through a large-scale empirical investigation. We mined 14,740 commits from 105 GitHub open-source projects with Jupyter notebook code. Next, we analyzed 30,416 Stack Overflow posts which gave us insights into bugs that practitioners face when developing Jupyter notebook projects. Finally, we conducted nineteen interviews with data scientists to uncover more details about Jupyter bugs and to gain insights into Jupyter developers' challenges. We propose a bug taxonomy for Jupyter projects based on our results. We also highlight bug categories, their root causes, and the challenges that Jupyter practitioners face.

Context The development of systems that handle configuration options according to a specific environment is considered a hard activity. These kind of systems, Highly-Configurable Systems (HCS) are perceived by researchers and developers as complex and difficult to maintain due to the necessity of handling variation points. Although this perception is reported in the literature, no prior study investigated the differences between HCS and Single Systems (SS). Objective This study investigated similarities and differences between HCS and SS using well known metrics from the literature according to three different perspectives: product perspective (bug-proneness, complexity, and change size); process perspective (number of contributors, number of core developers, and accidental contributors); and people perspective (contributor retention and number of paid contributors). Method To perform this comparison, we collected data from two surveys and from a mining study (within 15,769 releases of 124 GitHub projects written in C). Results In general, we identified that for the majority of the metrics, the perception of practitioners and researchers about HCS and SS is different from our mining results. Conclusion The identification of similarities and differences of HCS and SS will help to initiate a discussion and further research in this direction.

Context: COVID-19 pandemic has impacted different business sectors around the world. Objective. This study investigates the impact of COVID-19 on software projects and software development professionals. Method: We conducted a mining software repository study based on 100 GitHub projects developed in Java using ten different metrics. Next, we surveyed 279 software development professionals for better understanding the impact of COVID-19 on daily activities and wellbeing. Results: We identified 12 observations related to productivity, code quality, and wellbeing. Conclusions: Our findings highlight that the impact of COVID-19 is not binary (reduce productivity vs. increase productivity) but rather a spectrum. For many of our observations, substantial proportions of respondents have differing opinions from each other. We believe that more research is needed to uncover specific conditions that cause certain outcomes to be more prevalent.

Context An increasing number of studies has demonstrated improvements in product quality, and time-to-market reductions when Software Product Line (SPL) engineering is introduced. However, despite the amount of successful stories about the use of SPL engineering, there is a lack of guidelines to support its adoption, especially to small-sized software organizations. Objective The aim of this study is to investigate SPL adoption in small organizations and to improve the generalization of evidence through the use of a multi-method approach. Method This paper reports on a multi-method study, where results from a mapping study, industrial case study and also expert opinion survey were considered to identify a set of findings. Results The study provides a better understanding of SPL adoption in the context of small to medium-sized organizations, by documenting evidence observed during the transition from single-system development to an SPL approach. This evidence is strengthened by the use of different research methods, which results in 22 findings regarding to the SPL adoption. Conclusion This research has synthesized the available evidence in SPL adoption and identifies gaps between required strategies, organizational structures, maturity level and existing adoption barriers. These findings are an important step to establish guidelines for SPL adoption.

Software Product Lines (SPL) demand mature software engineering, planning and reuse, adequate practices of management and development, and also the ability to deal with organizational issues and architectural complexity. Thus, it is important the development of new techniques, tools and methods to deal with SPL complexity required by the variability management. To address this issue, an SPL has been proposed, where the existing variability was implemented by applying conditional compilation. Moreover, no framework was used to develop it, allowing any researcher to use the SPL without losing time learning some framework. In this work, we implemented an SPL test bed containing 34 functional features has 26.457 lines of code, 1493 methods and 496 classes.

The idea of developing software components was envisioned more than forty years ago. In the past two decades, Component-Based Software Engineering (CBSE) has emerged as a distinguishable approach in software engineering, and it has attracted the attention of many researchers, which has led to many results being published in the research literature. There is a huge amount of knowledge encapsulated in conferences and journals targeting this area, but a systematic analysis of that knowledge is missing. For this reason, we aim to investigate the state-of-the-art of the CBSE area through a detailed literature review. To do this, 1,231 studies dating from 1984 to 2012 were analyzed. Using the available evidence, this paper addresses five dimensions of CBSE: main objectives, research topics, application domains, research intensity and applied research methods. The main objectives found were to increase productivity, save costs and improve quality. The most addressed application domains are homogeneously divided between commercial-off-the-shelf (COTS), distributed and embedded systems. Intensity of research showed a considerable increase in the last fourteen years. In addition to the analysis, this paper also synthesizes the available evidence, identifies open issues and points out areas that call for further research.

Context: Software product lines (SPLs) and Agile are approaches that share similar objectives. The main difference is the way in which these objectives are met. Typically evidence on what activities of Agile and SPL can be combined and how they can be integrated stems from different research methods performed separately. The generalizability of this evidence is low, as the research topic is still relatively new and previous studies have been conducted using only one research method. Objective: This study aims to increase understanding of Agile SPL and improve the generalizability of the identified evidence through the use of a multi-method approach. Method: Our multi-method research combines three complementary methods (Mapping Study, Case Study and Expert Opinion) to consolidate the evidence. Results: This combination results in 23 findings that provide evidence on how Agile and SPL could be combined. Conclusion: Although multi-method research is time consuming and requires a high degree of effort to plan, design, and perform, it helps to increase the understanding on Agile SPL and leads to more generalizable evidence. The findings confirm a synergy between Agile and SPL and serve to improve the body of evidence in Agile SPL. When researchers and practitioners develop new Agile SPL approaches, it will be important to consider these synergies.