Measuring Software Process: A Systematic Mapping Study

Context: Measurement is essential to reach predictable performance and high capability processes. It provides support for better understanding, evaluation, management, and control of the development process and project, as well as the resulting product. It also enables organizations to improve and predict its process’s performance, which places organizations in better positions to make appropriate decisions. Objective: This study aims to understand the measurement of the software development process, to identify studies, create a classification scheme based on the identified studies, and then to map such studies into the scheme to answer the research questions. Method: Systematic mapping is the selected research methodology for this study. Results: A total of 462 studies are included and classified into four topics with respect to their focus and into three groups based on the publishing date. Five abstractions and 64 attributes were identified, 25 methods/models and 17 contexts were distinguished. Conclusion: capability and performance were the most measured process attributes, while effort and performance were the most measured project attributes. Goal Question Metric and Capability Maturity Model Integration were the main methods and models used in the studies, whereas agile/lean development and small/medium-size enterprise were the most frequently identified research contexts.Ministerio de Economía y Competitividad TIN2013-46928-C3-3-RMinisterio de Economía y Competitividad TIN2016-76956-C3-2- RMinisterio de Economía y Competitividad TIN2015-71938-RED

Influential factors of aligning Spotify squads in mission-critical and offshore projects – a longitudinal embedded case study

Changing the development process of an organization is one of the toughest and riskiest decisions. This is particularly true if the known experiences and practices of the new considered ways of working are relative and subject to contextual assumptions. Spotify engineering culture is deemed as a new agile software development method which increasingly attracts large-scale organizations. The method relies on several small cross-functional self-organized teams (i.e., squads). The squad autonomy is a key driver in Spotify method, where a squad decides what to do and how to do it. To enable effective squad autonomy, each squad shall be aligned with a mission, strategy, short-term goals and other squads. Since a little known about Spotify method, there is a need to answer the question of: How can organizations work out and maintain the alignment to enable loosely coupled and tightly aligned squads? In this paper, we identify factors to support the alignment that is actually performed in practice but have never been discussed before in terms of Spotify method. We also present Spotify Tailoring by highlighting the modified and newly introduced processes to the method. Our work is based on a longitudinal embedded case study which was conducted in a real-world large-scale offshore software intensive organization that maintains mission-critical systems. According to the confidentiality agreement by the organization in question, we are not allowed to reveal a detailed description of the features of the explored project

Technical Debt Prioritization: State of the Art. A Systematic Literature Review

Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review among 384 unique papers published until 2018, following a consolidated methodology applied in Software Engineering. We included 38 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and optimizing on different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We report an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that technical Debt prioritization research is preliminary and there is no consensus on what are the important factors and how to measure them. Consequently, we cannot consider current research conclusive and in this paper, we outline different directions for necessary future investigations

How Satellites are Moving Beyond the Class System: Class Agnostic Development and Operations Approaches for Constraints-Driven Missions

Should we abolish the Class System? The Class A/B/C/D mission assurance and risk posture designations familiar to most satellite developers were established in 1986. They are used by both the Department of Defense (DoD) and National Aeronautics and Space Administration (NASA) to define risk and risk mitigation requirements for flight missions. However, many of today’s satellites are different – smaller, digitally engineered, designed for production, and increasingly destined for proliferated architectures. The rate of development is increasing while the uniqueness of the systems being built is decreasing. The need to move faster and the ability to utilize, for the first time in space, real product-line components challenges the premise and assumptions behind the Class A through D designations. The traditional “Class System” is not as applicable to most small satellite developments, which instead focus on ways to prioritize key, high impact, agile processes in an effort to cut costs and timelines. Operating within this environment requires satellite developers to apply practices that are agnostic to class definition (e.g., the practices that are most fundamental to ensuring the mission meets the needs). This paper outlines the Class Agnostic approach and constraints-based mission implementation practices. It will describe several real-life examples from Air Force Research Laboratory, Space and Missile System Center, and Space Rapid Capabilities Office missions that are applying a “class agnostic” approach to their missions. It will include lessons learned from missions which failed critical Do No Harm requirements and lost a flight to missions that have fully utilized the class agnostic approach. It will also discuss how the several missions used class-agnostic techniques to balance requirements of scope, risk, cost, and schedule to maximize the chances of mission success within hard constraints. The approaches used in these missions are applicable not only to small satellites, but also to any mission intending to move beyond the “Class System” to a more agile and flexible mindset for risk mitigation and mission assurance