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

A Case Study on Effectively Identifying Technical Debt

Context: The technical debt (TD) concept describes a tradeoff between short-term and long-term goals in software development. While it is highly useful as a metaphor, it has utility beyond the facilitation of discussion, to inspire a useful set of methods and tools that support the identification, measurement, monitoring, management, and payment of TD. Objective: This study focuses on the identification of TD. We evaluate human elicitation of TD and compare it to automated identification. Method: We asked a development team to identify TD items in artifacts from a software project on which they were working. We provided the participants with a TD template and a short questionnaire. In addition, we also collected the output of three tools to automatically identify TD and compared it to the results of human elicitation. Results: There is little overlap between the TD reported by different developers, so aggregation, rather than consensus, is an appropriate way to combine TD reported by multiple developers. The tools used are especially useful for identifying defect debt but cannot help in identifying many other types of debt, so involving humans in the identification process is necessary. Conclusion: We have conducted a case study that focuses on the practical identification of TD, one area that could be facilitated by tools and techniques. It contributes to the TD landscape, which depicts an understanding of relationships between different types of debt and how they are best discovered

Factors affecting Technical Debt Raw data from a systematic literature map

"This document presents the complete list of references that have been short listed during the systematic review process carried out during the months of April-September 2012. The objective of the systematic review was to identify current research trends in technical debt and to explore the relationship between technical debt measures and agile software development. This documents includes 352 references that are categorized according to their relevance to technical debt research." [Abstract

¿Cuáles son los límites de la metáfora?

"Deuda técnica es una metáfora utilizada para representar los problemas que ocurren cuando una de las dimensiones de la gestión de proyectos es priorizada por sobre otra, típicamente presiones de calendario por sobre requerimientos de calidad. Aunque la metáfora es ilustrativa y comunicable, el conocimiento sobre deuda técnica generada en los proyectos de software y su incidencia en la empresa es un tema todavía en desarrollo. La deuda técnica es relativizada como una problemática académica, ajeno a los técnicos y actores que participan en los proyectos de software. Para entender la viabilidad del uso de la metáfora como herramienta para la gestión de proyectos se realizó un mapeo sistemático de la literatura. Este trabajo tiene dos objetivos. El primero es mostrar los hallazgos resultantes del mapeo sistemático realizado en relación a las definiciones de deuda técnica que se están utilizando y qué nivel de actividad existe sobre el tema. El segundo objetivo es establecer un marco de discusión para interpretar: “¿Hasta dónde podemos llevar la metáfora? Los hallazgos son que si bien existen definiciones, éstas no son consensuadas, principalmente cuando la deuda técnica es referida más allá de la calidad de código. La cantidad creciente de artículos publicados muestra que es un tema de interés para la comunidad científica." [Abstract

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 of 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 of 557 unique papers published until 2019, following a consolidated methodology applied in software engineering. We included 44 primary studies.Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present 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 the important factors are and how to measure them. Consequently, we cannot consider current research\ua0conclusive. In this paper, we therefore outline different directions for necessary future investigations

Study of Code Smells: A Review and Research Agenda

Code Smells have been detected, predicted and studied by researchers from several perspectives. This literature review is conducted to understand tools and algorithms used to detect and analyze code smells to summarize research agenda. 114 studies have been selected from 2009 to 2022 to conduct this review. The studies are deeply analyzed under the categorization of machine learning and non-machine learning, which are found to be 25 and 89 respectively. The studies are analyzed to gain insight into algorithms, tools and limitations of the techniques. Long Method, Feature Envy, and Duplicate Code are reported to be the most popular smells. 38% of the studies focused their research on the enhancement of tools and methods. Random Forest and JRip algorithms are found to give the best results under machine learning techniques. We extended the previous studies on code smell detection tools, reporting a total 87 tools during the review. Java is found to be the dominant programming language during the study of smells

Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations

In this paper, we present a tertiary systematic literature review of previous surveys, secondary systematic literature reviews, and systematic mappings. We identify the main observations (what we know) and challenges (what we do not know) on code smells and refactoring. We show that code smells and refactoring have a strong relationship with quality attributes, i.e., with understandability, maintainability, testability, complexity, functionality, and reusability. We argue that code smells and refactoring could be considered as the two faces of a same coin. Besides, we identify how refactoring affects quality attributes, more than code smells. We also discuss the implications of this work for practitioners, researchers, and instructors. We identify 13 open issues that could guide future research work. Thus, we want to highlight the gap between code smells and refactoring in the current state of software-engineering research. We wish that this work could help the software-engineering research community in collaborating on future work on code smells and refactoring

Proposta de modelo ?nico para prioriza??o de d?vida t?cnica

Over the years, software has become more and more present in the people?s and compani?es daily life. The software development companies aiming to understand customer needs, often investing in optimization, improving the product quality. However, software development companies have been dealing with limited amounts of time and resources, which have to be applied to generate in a short term financial gains and in addition they also have to develop features that satisfy the customers. Therefore, managers and developers focus other aspects than quality to establish a balance between the objectives, features and functionalities of the product, development can be taken shortcuts because of the short time to prioritize this over the quality. In 1992, the term technical debt was cited by Ward Cunningham to reflect the scenario in which to accelerate the development of software would require the writing of an immature code, thereby generating a debt. This metaphor gradually extended to other parts of the software, generally reflecting the immature, inadequate, or incomplete artifacts present in the development life cycle. Due to limited resources, identified technical debt items should be prioritized, seeking to classify and rank debts from technical factors or needs. Although there are some studies on technical debt prioritization, there are still many gaps on how to prioritize a technical debt item. So, it is important to elaborate new models to help developers to prioritize technical debt items, seeking to assist in decision making and aiming to clarify to entrepreneurs the real benefits linked to technical improvements. The objective of this study is to identify and categorize the technical debt prioritization approaches in the literature and, finally, a unique model of prioritization was proposed based on the characteristics derived from these studies. The approach developed is intended to prioritize classes affected by code smells, which are design problems at the source code level of a system and can indicate technical debt points. The model has six phases of classification, each phase representing specific ranking metrics. At the end of the prioritization process, the classes smelly with the highest priority of correction are obtained in relation to the considered criteria. The proposed model was validated with specialists in the area in order to verify its contribution and relevance.Com o passar dos anos, os softwares tornaram-se cada vez mais presentes no cotidiano de pessoas e empresas. As ind?strias desenvolvedoras, visando atender as necessidades dos seus clientes investem frequentemente em otimiza??o, buscando melhorias na qualidade do produto final. Por?m, as ind?strias de desenvolvimento de software lidam com valores limitados de tempo e recursos, fazendo com que essas tenham que aplic?-los de forma a gerar um retorno financeiro a curto prazo e ao mesmo tempo, desenvolvendo funcionalidades que possam satisfazer os clientes. Com isso, aspectos internos de qualidade s?o alvos de indecis?o por parte dos gerentes e desenvolvedores, retratando o contexto da d?vida t?cnica, em que para se estabelecer um equil?brio entre os objetivos, recursos e funcionalidades do produto, atalhos de desenvolvimento podem ser tomados a curto prazo. Em 1992, o termo d?vida t?cnica foi citado por Ward Cunningham para refletir o cen?rio em que para acelerar o desenvolvimento de software seria necess?rio a escrita de um c?digo imaturo, gerando-se assim uma d?vida. Essa met?fora estendeu-se gradualmente a outras partes do software, refletindo de maneira geral aos artefatos imaturos, inadequados ou incompletos presentes no ciclo de vida de desenvolvimento. Devido aos recursos limitados, os itens de d?vida t?cnica identificados devem ser priorizados, buscando classificar e ranquear as d?vidas a partir de fatores ou necessidades t?cnicas. Embora j? existam alguns estudos sobre prioriza??o, ainda existem muitos desafios em como definir a prioridade de um item de d?vida t?cnica. Por isso, ? necess?ria a elabora??o de novos modelos para priorizar os itens com sucesso, buscando auxiliar na tomada de decis?o e visando esclarecer aos empres?rios os reais benef?cios vinculados ?s melhorias t?cnicas. O objetivo deste trabalho ? identificar e categorizar as abordagens de prioriza??o de d?vida t?cnica existentes na literatura e por fim, prop?s-se um modelo ?nico de prioriza??o baseado nas caracter?sticas oriundas desses estudos. A abordagem desenvolvida tem como objetivo priorizar classes afetadas por code smells, que s?o problemas de design ao n?vel do c?digo-fonte de um sistema e podem indicar pontos de d?vida t?cnica. O modelo possui seis fases de classifica??o, sendo que cada fase representa m?tricas espec?ficas de ranqueamento. No final do processo de prioriza??o, obt?m-se as classes smelly com maior prioridade de corre??o em rela??o aos crit?rios considerados. O modelo proposto foi validado com especialistas na ?rea a fim de verificar sua contribui??o e relev?ncia

EMPIRICAL ASSESSMENT OF THE IMPACT OF USING AUTOMATIC STATIC ANALYSIS ON CODE QUALITY

Automatic static analysis (ASA) tools analyze the source or compiled code looking for violations of recommended programming practices (called issues) that might cause faults or might degrade some dimensions of software quality. Antonio Vetro' has focused his PhD in studying how applying ASA impacts software quality, taking as reference point the different quality dimensions specified by the standard ISO/IEC 25010. The epistemological approach he used is that one of empirical software engineering. During his three years PhD, he's been conducting experiments and case studies on three main areas: Functionality/Reliability, Performance and Maintainability. He empirically proved that specific ASA issues had impact on these quality characteristics in the contexts under study: thus, removing them from the code resulted in a quality improvement. Vetro' has also investigated and proposed new research directions for this field: using ASA to improve software energy efficiency and to detect the problems deriving from the interaction of multiple languages. The contribution is enriched with the final recommendation of a generalized process for researchers and practitioners with a twofold goal: improve software quality through ASA and create a body of knowledge on the impact of using ASA on specific software quality dimensions, based on empirical evidence. This thesis represents a first step towards this goa

Modelo para el tratamiento de la deuda técnica orientado a la evolución de los componentes para que las aplicaciones sean sostenibles a largo plazo

La Deuda Técnica es un fenómeno habitual del proceso de construcción de software, la cual es reconocida como un conjunto de malas prácticas y decisiones incorrectas en la fase de construcción de software, aceptada generalmente como efecto colateral en proyectos de software donde puede existir presiones de cronograma y con entregas continuas de valor a corto plazo. Ciertos aspectos de este fenómeno son conocidos de forma general, lo que sigue sin conocerse en profundidad, es cómo la deuda técnica se manifiesta y afecta específicamente los procesos de software, y cómo las técnicas de desarrollo de software empleadas acomodan o mitigan la presencia de esta deuda (Holvitie et al., 2018). La deuda técnica ha ganado visibilidad en los últimos años debido al interés en los proyectos de software que usan marcos de desarrollo ágil, los cuales detallan la responsabilidad que tienen los equipos de desarrollo en producir código de calidad, y que en su afán de entregar software funcionando en el menor tiempo posible, renuncian a actividades relacionadas con la producción de código de calidad, como son, el uso de buenas prácticas de codificación, definiciones de diseños y arquitecturas incompletas, poca cobertura de pruebas y documentación, entre otros, que a largo plazo acumulan una gran cantidad de deuda técnica que se vuelve perjudicial para el éxito de los proyectos. Parte de este estudio es comprender los antecedentes, dimensiones, atributos y consecuencias de la deuda técnica, para así poder proponer un modelo de referencia para el tratamiento de la deuda técnica, y cómo puede éste ser adaptado como parte de un proceso de madurez similar a los existentes en desarrollo de software general. El entendimiento de las causas para lograr que las aplicaciones puedan ser sostenibles a largo plazo, será el principal enfoque para la selección de las principales técnicas para el tratamiento de la deuda técnica definidas en la literatura, las tecnologías y herramientas que serán útiles para registrar y hacer las mediciones de deuda técnica, especificar qué actividades y ejemplos claros de cómo deberían ser implementadas según el modelo por parte de los equipos de desarrollo, contribuyendo a reducir y gestionar la deuda técnica en las aplicaciones. El modelo propuesto debe proporcionar un enfoque útil para comprender y gestionar la deuda técnica con fines prácticos, que involucre futuras líneas de investigación.Technical Debt is a common phenomenon of the software construction process, the quality is recognized as a set of bad practices and incorrect decisions in the software construction phase, normally accepted as a side effect in software projects where there may be schedule difficulties and with continuous deliveries of short-term value. Certain aspects of this phenomenon are generally known, what remains unknown in depth, is how technical debt manifests and specifically affects software processes, and how the software development techniques used accommodate or mitigate the presence of this debt (Holvitie et al., 2018).Technical debt has gained visibility in recent years due to interest in software projects that use agile development frameworks, which detail the responsibility that development teams have in producing quality code, and that in their eagerness to deliver software functioning in the shortest possible time, they give up activities related to the production of quality code, such as the use of good coding practices, definitions of incomplete designs and architectures, little evidence and documentation coverage, among others, that over term accumulate a large amount of technical debt that becomes detrimental to the success of the projects. Part of this study is to understand the background, dimensions, attributes and consequences of technical debt, in order to propose a reference model for the treatment of technical debt, and how it can be adapted as part of a maturity process similar to those existing in general software development. Understanding the causes to ensure that applications can be sustainable in the long term will be the main approach for the selection of the main techniques for the treatment of technical debt defined in the literature, the technologies and tools that will be useful for recording and make the measurements of technical debt, specify what activities and clear examples of how they should be implemented according to the model by the development teams, contributing to reduce and manage the technical debt in the applications. The proposed model should provide a useful approach to understand and manage technical debt for practical purposes, which involves future lines of research.Magíster en Ingeniería de SoftwareMaestrí