DevOps responds to the growing need of companies to streamline the software development process and thus has experienced widespread adoption in the past few years. However, the successful adoption of DevOps requires companies to address important cultural and organizational changes. Nevertheless, it is crucial to recognize that various DevOps taxonomies exist, both from academic and practitioner perspectives, which may lead to misleading or failed adoption of DevOps. This paper presents empirical research on the structure of DevOps teams in software-producing organizations. The goal is to better understand the organizational structure and characteristics of teams adopting DevOps by harmonizing the existing knowledge. To achieve this, we employed a grounded theory approach with collaborative coding, involving two research groups. Inter-Coder Agreement (ICA) was utilized to guide the discussion rounds. We conducted a comprehensive analysis of existing studies on DevOps teams and taxonomies to gain a deeper understanding of the subject. From the analysis, we built a substantive and analytic theory of DevOps taxonomies. The theory is substantive in that the scope of validity refers to the ten secondary studies processed and analytic in that it analyzes “what is” rather than explaining causality or attempting predictive generalizations. A public repository with all the data related to the products resulting from the analysis and generation of the theory is available. We built a theory on DevOps taxonomies and tested whether it harmonizes the existing taxonomies, i.e., whether our theory can instantiate the others. This is the first step to define which taxonomies are best suited to approach DevOps culture and practices according to the companies’ objectives and capabilities. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

The qualitative research on empirical software engineering that uses Grounded Theory is increasing (GT). The trustworthiness, rigor, and transparency of GT qualitative data analysis can benefit, among others, when multiple analysts juxtapose diverse perspectives and collaborate to develop a common code frame based on a consensual and consistent interpretation. Inter-Rater Reliability (IRR) and/or Inter-Rater Agreement (IRA) are commonly used techniques to measure consensus, and thus develop a shared interpretation. However, minimal guidance is available about how and when to measure IRR/IRA during the iterative process of GT, so researchers have been using ad hoc methods for years. This paper presents a process for systematically measuring IRR/IRA in GT studies, when appropriate, which is grounded in a previous systematic mapping study on collaborative GT in the field of software engineering. Meta-science guided us to analyze the issues and challenges of collaborative GT and formalize a process to measure IRR/IRA in GT. This process guides researchers to incrementally generate a theory while ensuring consensus on the constructs that support it, improving trustworthiness, rigor, and transparency, and promoting the communicability, reflexivity, and replicability of the research. The application of this process to a GT study seems to support its feasibility. In the absence of further confirmation, this would represent the first step in a de facto standard to be applied to those GT studies that may benefit from IRR/IRA techniques.

The research on empirical software engineering that uses qualitative data analysis is increasing. However, most of them do not deepen into the validity of the findings, specifically in the reliability of coding in which these methodologies rely on. This paper aims to establish a novel theoretical framework that enables a methodological approach for conducting this validity analysis through Inter-Coder Agreement (ICA), based on the use of coefficients to measure the degree of agreement in collaborative coding. We systematically review several existing variants of Krippendorff’s α coefficients and provide a novel common mathematical framework to unify them. Finally, this paper illustrates the use of this theoretical framework in a large case study on DevOps culture. We expect that this work will help researchers who are committed to measuring consensus with quantitative techniques in collaborative coding, conducted as part of a qualitative research, to improve the rigor of their findings.

Context: DevOps can be defined as a cultural movement to improve and accelerate the delivery of business value by making the collaboration between development and operations effective.Objective: This paper aims to help practitioners and researchers to better understand the organizational structure and characteristics of teams adopting DevOps.Method: We conducted an exploratory study by leveraging in-depth, semi-structured interviews with relevant stakeholders of 31 multinational software-intensive companies, together with industrial workshops and observations at organizations’ facilities that supported triangulation. We used Grounded Theory as qualitative research method to explore the structure and characteristics of teams, and statistical analysis to discover their implications in software delivery performance.Results: We describe a taxonomy of team structures that shows emerging, stable and consolidated product teams that are classified according to six variables, such as collaboration frequency, product ownership sharing, and autonomy, among others, as well as their implications on software delivery performance. These teams are often supported by horizontal teams (DevOps platform teams, Centers of Excellence, and chapters) that provide them with platform technical capabilities, mentoring and evangelization, and even temporarily may facilitate human resources.Conclusion: This study aims to strengthen evidence and support practitioners in making better informed about organizational team structures by analyzing their main characteristics and implications in software delivery performance.

DevOps is becoming a main competency required by the software industry. However, academic institutions have been slow to provide DevOps training in software engineering (SE) curricula. One reason for this is the fact that the problems addressed by DevOps may be hard to understand to students who have not previously worked in the industry or on projects of meaningful size and complexity. This paper shows an experience that integrates DevOps in SE curricula through research-based teaching (RBT). We aim to expose students to the problems that have led companies to adopt DevOps by researching and analyzing real cases of companies, thereby placing students at the center of learning. The contribution of this work is to innovate the application of RBT in software engineering by showing that the RBT approach is, at least, as good as the traditional approach and that it also leads to some extra benefits. This innovative solution has been implemented by using (i) qualitative analysis, specifically coding techniques, to discover knowledge and (ii) inter-coder agreement (ICA), specifically Krippendorff’s$\alpha$coefficients, to measure the extent of students’ learning. These techniques allow teachers to determine whether students’ learning in the subject is homogeneous and to analyze disagreements among students during their analysis. This approach provides teachers with new tools (Krippendorff’s$\alpha$coefficients) to identify those concepts that are less understood by students and to evaluate whether improvements in the research instruments (e.g., the codebook used in the qualitative analysis) also generate improvements in the students’ agreement. This RBT experience shows evidence that can be used to assess whether a similar experience and the use of ICA could be applied in similar learning contexts with similar research contexts.

Nowadays, software systems remain useful and competitive; entail the inevitable need to change over time and to be adapted to new technologies, platforms, and architectures. These quick changes imply following systematic, automated, or standardised processes that provide recommendations and guidelines to architects during software architecture reconstruction. Considerable research work on architecture reconstruction has been conducted. However, it needs to be studied thoroughly to determine what are the common activities and elements to reconstruct software architectures, and to define a reference process for systematically guiding the evolution of software architectures. This work addresses the need for defining a process for software architecture reconstruction called software improvement in the reconstruction of architectures (SIRA). This process has been rigorously designed from the results of a systematic literature review and a small survey of related work. As a result, SIRA integrates and extends previous research and can be conceived as a reference process to reconstruct software architectures in a semi-automated way. In addition, this work also determines the common elements of the architecture reconstruction process: (i) techniques and activities; (ii) architectural elements, patterns, and attributes; (iii) mechanisms and strategies; and (iv) the automation and recommendation tasks of the process.

Current Internet-of-Things (IoT) systems are highly distributed systems, which integrate cloud, fog, and edge computing approaches. Accelerating their maintenance and continuous improvement, while ensuring their availability, is complex. DevOps promotes fast and continuous feedback from operations to development to detect problems before customers are impacted, among other benefits. However, there is not any formal definition of how to do this. This article defines the “fast and continuous monitoring feedback of system availability” activity (F&CF availability) that supports automatic and continuous monitoring feedback from operations to the development of the IoT system availability. This activity has been formalized through the software and systems process engineering metamodel (SPEM). Its implementation is demonstrated in a real scenario that provides evidence that the formalization of the F&CF availability activity helps teams in better diagnosing and fixing outage problems. The result is a distributed and configurable monitoring component developed through code [monitoring as code (MaC)]. This component is embedded in the IoT infrastructure. MaC enables DevOps team to configure their own metrics and indicators at runtime, i.e., monitoring on demand. The formalization of this activity, based on an MaC technique, enables the automation, versioning, and replication of monitoring elements.

Edge computing is a reality for the current IoT systems that need fast processing and quick response time to make real-time decisions and IoT systems without permanent connectivity to the cloud (e.g., car manufacturing, precision agriculture, or cattle raising). Additionally, these industries are facing the need for rapid and continuous innovation by accelerating the delivery of over-the-air (OTA) software updates in edge devices. DevOps promotes collaboration between development and operation teams and automation at all steps of software construction to achieve continuous delivery (CD) of business value. Although DevOps has demonstrated numerous successful cases in the Web domain, in the IoT domain and, more specifically, at the edge, there are few reported cases. This work presents a success case of CD of customized software as a service software as a service (SaaS) updates at the IoT Edge. This may enable new business models at the IoT Edge. This article presents an architectural model of a highly distributed (cloud and edge) IoT system and a CD process flow for customized SaaS applications in edge nodes. Both the architectural model and the CD process flow are instantiated in a case study for precision agriculture.

Abstract Cyber‐physical systems (CPS) refer to the next generation of Information and Communication Technology systems that mainly integrate sensing, computing, and communication to monitor, control, and interact with a physical process to provide citizens and businesses with smart applications and services: health care, smart homes, smart cities, and so on. In recent years, health care has become one of the most important services due to the continuous increases in its costs. This has motivated extensive research onhealth care CPS, and some of that research has focused on describing the software architecture behind these systems. However, there is no secondary study to consolidate the research. This paper aims to identify and compare existing research on software architectures for health care CPS in order to determine successful solutions that could guide other architects and practitioners in their health care projects. We conducted a systematic literature review and compared the selected studies based on a characterization schema. The research synthesis results in a knowledge base ofsoftware architectures for health care CPS, describing their stakeholders, functional and non‐functional features, quality attributes architectural views and styles, components, and implementation technologies. This systematic literature review also identifies research gaps, such as the lack of open common platforms, as well as directions for future research.

Technical debt monitoring is one of the activities that have to be performed in technical debt management. To do that, there are different techniques that can be used to estimate technical debt and different tools that implement those different techniques. This paper presents TEDMA Tool, a tool for monitoring technical debt over the software evolution and that it is open to integrate third party tools. TEDMA is based on the analysis of source code repositories and is useful for researching using empirical data extracted from software projects. Currently, it is been used to analyze big projects in the execution of several case studies. The expected evolution of TEDMA will make the tool useful for software development industry.

Abstract Software Product Line Engineering (SPLE) demands upfront long‐term investment in (i) designing a common set of core‐assets and (ii) managing variability across the products from the same family. When anticipated changes in these core‐assets have been predicted with certain accuracy, SPLE has proved significant improvements. However, when large/complex software product line projects have to deal with changing market conditions, alternatives to supplement SPLE are required. Agile Software Development (ASD) may be an alternative, as agile processes harness change for the customer's competitive advantage. However, when the aim is to scale Agile projects up to effectively manage reusability and variability across the products from the same family, alternatives to supplement agility are also required. As a result, a new approach called Agile Product Line Engineering (APLE) advocates integrating SPLE and ASD with the aim of addressing these gaps. APLE is an emerging approach, which implies that organizations have to face several barriers to achieve its adoption. This paper presents a systematic literature review of experiences and practices on APLE, in which the key findings uncover important challenges about how to integrate the SPLE model with an agile iterative approach to fully put APLE into practice. Copyright © 2011 John Wiley & Sons, Ltd.