Abstract Reversing an outsourcing decision and retaking control of the development and operations of IT systems can be a viable option for organizations facing outsourcing-related challenges, such as problematic vendor relationships, high costs, or the recognition of software development as a core competence. Despite its increasing practical importance, backsourcing has received little attention in the software engineering literature. This paper presents an in-depth case study of a large public organization that successfully backsourced the development of the majority of its large portfolio of software systems. Based on interviews with 61 representatives of the backsourcing organization and its vendors and an analysis of corporate documentation, we present the rationale for backsourcing, the six main guiding principles shaping the approach, and the outcomes and lessons learned from the initiative. The primary reason for backsourcing in the case organization was cost reduction. The IT department led the effort, granting various application areas considerable autonomy in the practical implementation of backsourcing. The effort was characterized by close and constructive collaboration with the outsourcing vendors, who were being phased out, an incremental approach to assuming responsibility for the applications, and the concurrent implementation of agile development at scale. Over three years, the organization successfully backsourced over 100 systems and established an agile development organization with over 300 people. As a result of backsourcing, the organization reported an increased sense of system ownership, increased personnel motivation, faster deliveries, and better quality-in-use. We were unable to find clear evidence of significant cost savings. Key challenges included managing the change effort, building and retaining the necessary competencies, and addressing organizational tensions resulting from the IT department’s central role in the backsourcing effort.

Abstract Context: Interest in global software development (GSD) has led to the publication of numerous studies. Over time, these studies should be updated to verify if their findings and conclusions remain valid. Objective: To update a tertiary study, published in 2014, focused on investigating risks and risk mitigation advice in the context of GSD. Method: We conducted a systematic literature study based on forward snowballing, out of which we identified and selected 25 unique studies. Results: We extracted: (a) 118 risks (75 of which already identified in the original work), and (b) 167 mitigation advice (44 of which were identified in the original work). Out of 43 new risks identified, just 10 are specific to GSD settings; the others are risks of the software process described in the context of GSD. The evidence supporting these risks and mitigation were extracted from 619 and 389 primary sources, respectively. Given the amount of evidence found, we have reported only those with higher empirical support. The raw data is available online as complementary material. Conclusions: Interest in GSD, its potential risks, and mitigation strategies, remains high. This update has allowed increasing the level of empirical support provided by the findings of the original work.

Context: Electroencephalograms (EEG) have been used in a few cases in the context of software engineering (SE). EEGs allow capturing emotions and cognitive functioning. Such human factors have already shown to be important to understand software engineering tasks. Therefore, it is essential to gain experience in the community to utilize EEG as a research tool. Objective: To report experiences of using EEG in the context of a software engineering education (review of master theses proposals). We provide our reflections and lessons learned of (1) how to plan an EEG study, (2) how to conduct and execute (e.g., tools), (3) how to analyze. Method: We carried out an experiment using an EEG headset to measure the participants' attention rate. The experiment task includes reviewing three master thesis project plans. Results: We describe how we evolved our understanding of experimentation practices to collect and analyze psychological and cognitive data. We also provide a set of lessons learned regarding the application of EEG technology for research. Conclusions: We believe that that EEG could benefit software engineering research to collect cognitive information under certain conditions. The lessons learned reported here should be used as inputs for future experiments in software engineering, where human aspects are of interest.

Background: Survey is a method of research aiming to gather data from a large population of interest. Despite being extensively used in software engineering, survey-based research faces several challenges, such as selecting a representative population sample and designing the data collection instruments.

Systematic Literature Review (SLR) is a key tool for evidence-based practice as it combines results from multiple studies of a specific topic of research. Due its characteristics, it is a time consuming, hard process that requires a properly documented protocol for scientific acknowledgment. In this context, this paper presents the SESRA -- a web-based automated tool to support all phases of the SLR process, contributing to its productivity and reliability. We also present a use case on the software engineering field, applying specific knowledge to set the process in the discipline. Further, we discuss how to use the tool to establish a more formal and controlled process and to reduce effort on its repetitive activities. The outcomes and feedback obtained in early use have shown that SESRA could support the SLR process, automating some of its key activities.