Technical Debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefits but might hurt the long-term health of a software system. With the increasing amount of data generated when performing software development activities, an emergent research field has gained attention: applying Intelligent Techniques to solve Software Engineering problems. Intelligent Techniques were used to explore data for knowledge discovery, reasoning, learning, planning, perception, or supporting decision-making. Although these techniques can be promising, there is no structured understanding related to their application to support Technical Debt Management (TDM) activities. Within this context, this study aims to investigate to what extent the literature has proposed and evaluated solutions based on Intelligent Techniques to support TDM activities. To this end, we performed a Systematic Mapping Study (SMS) to investigate to what extent the literature has proposed and evaluated solutions based on Intelligent Techniques to support TDM activities. In total, 150 primary studies were identified and analyzed, dated from 2012 to 2021. The results indicated a growing interest in applying Intelligent Techniques to support TDM activities, the most used: Machine Learning and Reasoning under uncertainty. Intelligent Techniques aimed to assist mainly TDM activities related to identification, measurement, and monitoring. Design TD, Code TD, and Architectural TD are the TD types in the spotlight. Most studies were categorized at automation levels 1 and 2, meaning that existing approaches still require substantial human intervention. Symbolists and Analogizers are levels of explanation presented by most Intelligent Techniques, implying that these solutions conclude a general truth after considering a sufficient number of particular cases. Moreover, we also cataloged the empirical research types, contributions, and validation strategies described in primary studies. Based on our findings, we argue that there is still room to improve the use of Intelligent Techniques to support TDM activities. The open issues that emerged from this study can represent future opportunities for practitioners and researchers.

Agile software development (ASD) promotes minimal documentation and often prioritizes functional requirements over quality requirements (QRs). The minimal documentation emphasis may be beneficial in reducing time-to-market for software. However, it can also be a concern, especially with QRs, since they are challenging to specify and document and are crucial for software success. Therefore, understanding how practitioners perceive the importance of QR documentation is valuable because it can provide insight into how they approach this task. It also helps in developing models and guidelines that support the documentation of QRs in ASD, which is a research gap. We aim to understand practitioners’ perceptions of QR documentation and factors influencing this task to derive a model that supports optimal QR documentation in ASD. We conducted a multiple case study involving 12 participants from three cases that apply ASD. Practitioners identify QR documentation as important and perceive it as contributing to ensuring quality, clarifying QRs, and facilitating decision-making. Time constraints, QR awareness, and communication gaps affect QR documentation. Missing and outdated QR documentation may lead to technical debt and a lack of common understanding regarding QRs. We introduce a model to support optimal QR documentation in ASD by focusing on the factors: time constraints, QR awareness, and communication gaps. The model provides a representation and explanation of the factors affecting QR documentation in ASD and identifies mitigation strategies to overcome issues that may occur due to these factors. The study reveals the importance of documenting QRs in ASD. It introduces a model that is based on empirical knowledge of QR documentation practices in ASD. Both practitioners and researchers can potentially benefit from the model. For instance, practitioners can analyze how time constraints or QR awareness affect documentation, see potential issues that may arise from them, and utilize strategies suggested by the model to address these issues. Researchers can learn about QR documentation in ASD and utilize the model to understand the topic. They can also use the study as a baseline to investigate the topic with other cases.

In despite of agile and rapid software development (ARSD) being researched and applied extensively, managing quality requirements (QRs) are still challenging. As ARSD processes produce a large amount of data, measurement has become a strategy to facilitate QR management. This study aims to survey the literature related to QR management through metrics in ARSD, focusing on: bibliometrics, QR metrics, and quality-related indicators used in quality management. The study design includes the definition of research questions, selection criteria, and snowballing as search strategy. We selected 61 primary studies (2001–2019). Despite a large body of knowledge and standards, there is no consensus regarding QR measurement. Terminology is varying as are the measuring models. However, seemingly different measurement models do contain similarities. The industrial relevance of the primary studies shows that practitioners have a need to improve quality measurement. Our collection of measures and data sources can serve as a starting point for practitioners to include quality measurement into their decision-making processes. Researchers could benefit from the identified similarities to start building a common framework for quality measurement. In addition, this could help researchers identify what quality aspects need more focus, e.g., security and usability that have surprisingly few metrics reported.

Value-Based Software Engineering stresses the role of value in software related decisions. In the context of feature selection, software features judged to provide higher value take priority in the development process. This paper focuses on what value means when selecting software features. Using grounded theory, we conducted and analyzed semi-structured interviews with 21 key stakeholders (decision-makers) from three software/software-intensive companies, within a context where value-based decision-making was already established. Our analysis led to the building of a theory of value for value-based feature selection that identifies the nature of value propositions considered by key stakeholders when selecting software features (i.e., decision-making criteria for deciding upon software features, as suggested by Boehm (2003)). We found that some value propositions were common to all three company cases (core value propositions), whereas others were dependent upon the context in which a company operates, and the characteristics of the product under development (specific value propositions). Moreover, value propositions vary according to the stakeholder group and the type of feature being assessed. Our study provides significant insight into value in the context of feature selection, and generates new concepts around value-based feature selection such as new value propositions.

Background:The existing literature in software engineering reports adverse effects of confirmation bias on software testing. Confirmation bias among software testers leads to confirmatory behavior, which is designing or executing relatively more specification consistent test cases (confirmatory behavior) than specification inconsistent test cases (disconfirmatory behavior).Objective:We aim to explore the antecedents to confirmatory and disconfirmatory behavior of software testers. Furthermore, we aim to understand why and how those antecedents lead to (dis)confirmatory behavior.Method:We follow grounded theory method for the analyses of the data collected through semi-structured interviews with twelve software testers.Results:We identified twenty antecedents to (dis)confirmatory behavior, and classified them in nine categories. Experience and Time are the two major categories. Experience is a disconfirmatory category, which also determines which behavior (confirmatory or disconfirmatory) occurs first among software testers, as an effect of other antecedents. Time Pressure is a confirmatory antecedent of the Time category. It also contributes to the confirmatory effects of antecedents of other categories.Conclusion:The disconfirmatory antecedents, especially that belong to the testing process, e.g., test suite reviews by project team members, may help circumvent the deleterious effects of confirmation bias in software testing. If a team’s resources permit, the designing and execution of a test suite could be divided among the test team members, as different perspectives of testers may help to detect more errors. The results of our study are based on a single context where dedicated testing teams focus on higher levels of testing. The study’s scope does not account for the testing performed by developers. Future work includes exploring other contexts to extend our results.

Abstract Agile methods can deliver software that fulfills customer needs rapidly and continuously. Quality requirements (QRs) are important in this regard; however, detailed studies on how companies applying agile methods to manage QRs are limited, as are studies on the rationale for choosing specific QR management practices and related challenges. The aim of this study was to address why practitioners manage QRs as they do and what challenges they face. We also analyzed how existing practices mitigate some of the found challenges. Lastly, we connect the contextual elements of the companies with their practices and challenges. We conducted 36 interviews with practitioners from four companies of varying sizes. Since each company operates in different domains, comparing QR management strategies and related challenges in different contexts was possible. We found that the companies apply proactive, reactive, and interactive strategies to manage QRs. Additionally, our study revealed 40 challenges in six categories that companies applying agile methods may face in QR management. We also identified nine contextual elements that affect QR management practice choices and which, importantly, can explain many related challenges. Based on these findings, we constructed a theoretical model about the connection between context, QR management practices, and challenges. Practitioners in similar contexts can learn from the practices identified in this study. Our preliminary theoretical model can help other practitioners identify what challenges they can expect to face in QR management in different developmental contexts as well as which practices to apply to mitigate these challenges.

Context: Quality requirements (QRs) have a significant role in the success of software projects. In agile software development (ASD), where working software is valued over comprehensive documentation, QRs are often under-specified or not documented. Consequently, they may be handled improperly and result in degraded software quality and increased maintenance costs. Investigating the documentation of QRs in ASD, would provide evidence on existing practices, tools and aspects considered in ASD that other practitioners might utilize to improve documentation and management of QRs in ASD. Although there are some studies examining documentation in ASD, those that specifically investigate the documentation of QRs in depth are lacking.

Background: Practitioners would like to take action based on software metrics, as long as they find them reliable. Existing literature explores how metrics can be made reliable, but remains unclear if there are other conditions necessary for a metric to be actionable. Context & Method: In the context of a European H2020 Project, we conducted a multiple case study to study metrics' use in four companies, and identified instances where these metrics influenced actions. We used an online questionnaire to enquire about the project participants' views on actionable metrics. Next, we invited one participant from each company to elaborate on the identified metrics' use for taking actions and the questionnaire responses (N=17). Result: We learned that a metric that is practical, contextual, and exhibits high data quality characteristics is actionable. Even a non-actionable metric can be useful, but an actionable metric mostly requires interpretation. However, the more these metrics are simple and reflect the software development context accurately, the less interpretation required to infer actionable information from the metric. Company size and project characteristics can also influence the type of metric that can be actionable. Conclusion: This exploration of industry's views on actionable metrics help characterize actionable metrics in practical terms. This awareness of what characteristics constitute an actionable metric can facilitate their definition and development right from the start of a software metrics program.

Agile software development (ASD) promotes minimal documentation and often prioritizes functional requirements over quality requirements (QRs). This may be beneficial in reducing the time to market of software. When considering QRs in ASD, the minimal documentation practice may be seen as a concern since QRs determine the success of software projects and are as well not easy to specify and document. Nevertheless, what do practitioners think of the necessity of documenting QRs in ASD? How do they perceive factors that may affect documentation of QRs in ASD? We conducted a multiple case study of three cases applying ASD, involving 12 participants. ASD practitioners identify that it is important to document QRs, and perceive that it contributes to ensuring quality, clarifying QRs, and helping in decision making. Time constraint, QR awareness and communication gaps on QRs influence the documentation of QRs in ASD. ASD teams may align their documentation practices to fit the sprint duration. The influence of QR awareness on documentation was dependent on project context and roles. Communication gaps can create confusion on QRs. Missing and outdated QR documentation may result in accruing technical debt, and lack of common understanding on QRs. The study synthesizes empirical evidence on the significance of documenting QRs in ASD and provides an insight into factors affecting documentation of QRs in ASD.

One source of software project challenges and failures is the systematic errors introduced by human cognitive biases. Although extensively explored in cognitive psychology, investigations concerning cognitive biases have only recently gained popularity in software engineering research. This paper therefore systematically maps, aggregates and synthesizes the literature on cognitive biases in software engineering to generate a comprehensive body of knowledge, understand state-of-the-art research and provide guidelines for future research and practise. Focusing on bias antecedents, effects and mitigation techniques, we identified 65 articles (published between 1990 and 2016), which investigate 37 cognitive biases. Despite strong and increasing interest, the results reveal a scarcity of research on mitigation techniques and poor theoretical foundations in understanding and interpreting cognitive biases. Although bias-related research has generated many new insights in the software engineering community, specific bias mitigation techniques are still needed for software professionals to overcome the deleterious effects of cognitive biases on their work.

Numerous software companies are adopting value-based decision making. However, what does value mean for key stakeholders making decisions? How do different stakeholder groups understand value? Without an explicit understanding of what value means, decisions are subject to ambiguity and vagueness, which are likely to bias them. This case study provides an in-depth analysis of key stakeholders' value propositions when selecting features for a large telecommunications company's software-intensive product. Stakeholders' value propositions were elicited via interviews, which were analyzed using Grounded Theory coding techniques (open and selective coding). Thirty-six value propositions were identified and classified into six dimensions: customer value, market competitiveness, economic value/profitability, cost efficiency, technology & architecture, and company strategy. Our results show that although propositions in the customer value dimension were those mentioned the most, the concept of value for feature selection encompasses a wide range of value propositions. Moreover, stakeholder groups focused on different and complementary value dimensions, calling to the importance of involving all key stakeholders in the decision making process. Although our results are particularly relevant to companies similar to the one described herein, they aim to generate a learning process on value-based feature selection for practitioners and researchers in general.

Background: Despite the growth in the use of software analytics platforms in industry, little empirical evidence is available about the challenges that practitioners face and the value that these platforms provide. Aim: The goal of this research is to explore the benefits of using a software analytics platform for practitioners managing quality. Method: In a technology transfer project, a software analytics platform was incrementally developed between academic and industrial partners to address their software quality problems. This paper focuses on exploring the value provided by this software analytics platform in two pilot projects. Results: Practitioners emphasized major benefits including the improvement of product quality and process performance and an increased awareness of product readiness. They especially perceived the semi-automated functionality of generating quality requirements by the software analytics platform as the benefit with the highest impact and most novel value for them. Conclusions: Practitioners can benefit from modern software analytics platforms, especially if they have time to adopt such a platform carefully and integrate it into their quality assurance activities.

Existing literature proposes success factors for establishing metrics programs. However, very few studies focus on factors that could ensure long-term use of metrics, and even fewer studies investigate such factors in the context of Agile Software Development (ASD). Motivated by this knowledge gap, we aim to identify success factors for operationalizing metrics in ASD, particularly, factors that could help in the long-term use of metrics. We conducted a multiple case study, where we operationalized process metrics at two software-intensive companies using ASD. We learned that data availability and development process are the two fundamental success factors for process metrics operationalization, albeit less prominent in literature. Companies prefer iterative and incremental operationalization of stable and functional process metrics, which is analogous to the agile way of working. Metrics trustworthiness plays a key role in successful operationalization of process metrics, and is potentially vital to ensuring their long-term use. By comparing the identified success factors with the existing literature, we conclude that success factors concerning data availability, development process, and metrics trustworthiness warrant greater attention, especially to maximize the chances of long-term use of process metrics.

To sustain growth, maintain competitive advantage and to innovate, companies must make a paradigm shift in which both short- and long-term value aspects are employed to guide their decision-making. Such need is clearly pressing in innovative industries, such as ICT, and is also the core of Value-based Software Engineering (VBSE). The goal of this paper is to detail a framework called VALUE—improving decision-making relating to software-intensive products and services development—and to show its application in practice to a large ICT company in Finland. The VALUE framework includes a mixed-methods approach, as follows: to elicit key stakeholders’ tacit knowledge regarding factors used during a decision-making process, either transcripts from interviews with key stakeholders are analysed and validated in focus group meetings or focus-group meeting(s) are directly applied. These value factors are later used as input to a Web-based tool (Value tool) employed to support decision making. This tool was co-created with four industrial partners in this research via a design science approach that includes several case studies and focus-group meetings. Later, data on key stakeholders’ decisions gathered using the Value tool, plus additional input from key stakeholders, are used, in combination with the Expert-based Knowledge Engineering of Bayesian Network (EKEBN) process, coupled with the weighed sum algorithm (WSA) method, to build and validate a company-specific value estimation model. The application of our proposed framework to a real case, as part of an ongoing collaboration with a large software company (company A), is presented herein. Further, we also provide a detailed example, partially using real data on decisions, of a value estimation Bayesian network (BN) model for company A. This paper presents some empirical results from applying the VALUE Framework to a large ICT company; those relate to eliciting key stakeholders’ tacit knowledge, which is later used as input to a pilot study where these stakeholders employ the Value tool to select features for one of their company’s chief products. The data on decisions obtained from this pilot study is later applied to a detailed example on building a value estimation BN model for company A. We detail a framework—VALUE framework—to be used to help companies improve their value-based decisions and to go a step further and also estimate the overall value of each decision.

[Context]: To remain competitive, innovative and to grow, companies should use a value-based decision-making where decisions are the best for that company's overall value creation. However, without tool support, the use of explicit value propositions and aggregation of different key stakeholders' decisions during decision-making may be a challenge for many companies. [Goal]: The goal of this paper is to investigate the extent to which a Web-based tool for value-based decision-making can successfully support stakeholders' decision-making process. [Method]: We conducted three case studies across four software projects, during six weeks, in the contexts of feature selection, test cases execution prioritization and user interfaces design selection. Prior to using the tool, stakeholders' value propositions were elicited via focus-group meetings; later, during a post-mortem phase, data was gathered via observation, semi-structured interviews and structured questionnaires. [Results]: Participants reported an improvement of their decision-making process and quality of decisions; further, they also felt confident about using the tool, and that it can be useful to their work. [Conclusions]: Results suggested that the use of tool support by the stakeholders in the investigated company for value-based decision-making improved their decision-making process and the quality of decisions.

The potential shown by Lean in different domains has aroused interest in the software industry. However, it remains unclear how Lean can be effectively applied in a domain such as software development that is fundamentally different from manufacturing. This study explores how Lean principles are implemented in software development companies and the challenges that arise when applying Lean Software Development. For that, a case study was conducted at Ericsson R&D Finland, which successfully adopted Scrum in 2009 and subsequently started a comprehensible transition to Lean in 2010. Focus groups were conducted with company representatives to help devise a questionnaire supporting the creation of a Lean mindset in the company (Team Amplifier). Afterwards, the questionnaire was used in 16 teams based in Finland, Hungary and China to evaluate the status of the transformation. By using Lean thinking, Ericsson R&D Finland has made important improvements to the quality of its products, customer satisfaction and transparency within the organization. Moreover, build times have been reduced over ten times and the number of commits per day has increased roughly five times.The study makes two main contributions to research. First, the main factors that have enabled Ericsson R&D’s achievements are analysed. Elements such as ‘network of product owners’, ‘continuous integration’, ‘work in progress limits’ and ‘communities of practice’ have been identified as being of fundamental importance. Second, three categories of challenges in using Lean Software Development were identified: ‘achieving flow’, ‘transparency’ and ‘creating a learning culture’.

Earlier empirical studies have demonstrated the interest that agile methods have generated in the software industry. Currently, lean approaches are increasingly adopted for complementing agile methods in software processes. With the goal of providing up-to-day results that can be used by organizations implementing or planning to implement agile and/or lean methods, we have conducted a study on the current stage of agile and lean adoption and usage in the software industry. For this purpose, we conducted an extensive survey among Finnish software practitioners in 2011, using the membership registry of The Finnish Information Processing Association (FIPA) as a sampling frame. 408 responses were collected from 200 software intensive organizations in the study. The survey included questions for identifying the rate of agile and lean usage in software organizations as well as the implementation of specific methods and practices, goals in adopting agile and lean, reasons for not applying these methods and effects of the agile and lean usage. The results of the survey reveal that a majority of respondents' organizational units are using agile and/or lean methods (58%). Furthermore, lean appears as a new player, being used by 24% of respondents, mainly in combination with agile (21%). The reasons and benefits for using agile and lean methods appeared to correspond in most parts to the findings of the earlier research. Generally, the experiences of using agile and lean methods seem to be rather positive, although challenges, such as obtaining management support and limitations for scaling agile in distributed settings, were also identified.