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

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

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

Understanding, Analysis, and Handling of Software Architecture Erosion

Architecture erosion occurs when a software system's implemented architecture diverges from the intended architecture over time. Studies show erosion impacts development, maintenance, and evolution since it accumulates imperceptibly. Identifying early symptoms like architectural smells enables managing erosion through refactoring. However, research lacks comprehensive understanding of erosion, unclear which symptoms are most common, and lacks detection methods. This thesis establishes an erosion landscape, investigates symptoms, and proposes identification approaches. A mapping study covers erosion definitions, symptoms, causes, and consequences. Key findings: 1) "Architecture erosion" is the most used term, with four perspectives on definitions and respective symptom types. 2) Technical and non-technical reasons contribute to erosion, negatively impacting quality attributes. Practitioners can advocate addressing erosion to prevent failures. 3) Detection and correction approaches are categorized, with consistency and evolution-based approaches commonly mentioned.An empirical study explores practitioner perspectives through communities, surveys, and interviews. Findings reveal associated practices like code review and tools identify symptoms, while collected measures address erosion during implementation. Studying code review comments analyzes erosion in practice. One study reveals architectural violations, duplicate functionality, and cyclic dependencies are most frequent. Symptoms decreased over time, indicating increased stability. Most were addressed after review. A second study explores violation symptoms in four projects, identifying 10 categories. Refactoring and removing code address most violations, while some are disregarded.Machine learning classifiers using pre-trained word embeddings identify violation symptoms from code reviews. Key findings: 1) SVM with word2vec achieved highest performance. 2) fastText embeddings worked well. 3) 200-dimensional embeddings outperformed 100/300-dimensional. 4) Ensemble classifier improved performance. 5) Practitioners found results valuable, confirming potential.An automated recommendation system identifies qualified reviewers for violations using similarity detection on file paths and comments. Experiments show common methods perform well, outperforming a baseline approach. Sampling techniques impact recommendation performance