Technical Debt Tools: A Systematic Mapping Study

Saraiva, Diego; Neto, José Gameleira; Kulesza, Uirá; Freitas, Guilherme; Rebouças, R.B.; Coelho, Roberta

doi:10.5220/0010459100880098

Cited by 5 publications

(4 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In light of agile development, a growing consensus is that the presence of TD is inevitable 29 and even desirable under some circumstances. 30 A large body of research has looked into strategies, processes, factors, and tools to identify 19,27,28,31 and manage [32][33][34][35] TD in software development. Nonetheless, the presence of Naïve TD 27 should and can be avoided through training and process improvement.…”

Section: Kruchten Et Al's Td Landscapementioning

confidence: 99%

Technical debt in the engineering of complex systems

Yang

Verma

Antón³

2023

Systems Engineering

View full text Add to dashboard Cite

The metaphor of technical debt (TD) is widely adopted in the software engineering field, referring to short‐term compromises in software artifacts in exchange for speed or to meet release schedules or other constraints. The implication is that TDs accumulate over time, and may eventually make rework or maintenance very expensive or even impossible. The analogy is generally applicable in the systems engineering field, particularly concerning numerous program cancellation and obsolescence challenges due to premature decisions made in early acquisition phases. This paper adapts this metaphor of TD to the systems engineering field, and proposes a TD taxonomy to support the early identification and assessment of TD items in engineering complex systems, especially in the early life cycle phases of engineering complex, distributed systems. The taxonomy identifies seven TD types: functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic, based on systematic indicators and signs discoverable during early acquisition activities. We expect that the notion and the taxonomy of TD will offer an additional perspective for design decisions that will help mitigate challenging integration and obsolescence issues in the engineering of complex systems.

show abstract

Section: Kruchten Et Al's Td Landscapementioning

confidence: 99%

Technical debt in the engineering of complex systems

Yang

Verma

Antón³

2023

Systems Engineering

View full text Add to dashboard Cite

show abstract

“…More recently, Saraiva et al (2021) performed a systematic mapping study to investigate the current state of the art of TD tools, identifying which activities, functionalities and types of debt are handled by the existing tools to support TD management. The study identified 50 tools, 42 of which are new tools, and 8 tools extend an existing one.…”

Section: Introductionmentioning

confidence: 99%

Investigating the Relationship between Technical Debt Management and Software Development Issues

Berenguer¹,

Borges²,

Rios

et al. 2023

JSERD

View full text Add to dashboard Cite

Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for non-repayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and non-coding issues of the software development process. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the TD Management stage. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, and the organization are also common sources of TD. We organize the results in a hump diagram and specialize it considering the point of view of practitioners that have used agile, hybrid, and traditional process models in their projects. Conclusion: The hump diagram, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. The results shed light on TD management of software elements, beyond source code related artifacts.

show abstract

“…A systematic pattern application method requires a framework construction to help a designer detect MT problems at the specification stage. Then, based on the identified problem, the framework will suggest a number of appropriate patterns to mitigate the raised issue 15,16 . Boussaidi and Mili 17 proposed a model‐driven framework to represent and apply design patterns.…”

Section: Introductionmentioning

confidence: 99%

“…Then, based on the identified problem, the framework will suggest a number of appropriate patterns to mitigate the raised issue. 15,16 Boussaidi and Mili 17 proposed a model-driven framework to represent and apply design patterns. This framework involves three steps: (1) understanding the problem context, (2) recognizing the problem instance in the given model, and (3) transforming model by applying suitable pattern to resolve the issue.…”

Section: Introductionmentioning

confidence: 99%

Towards a pattern‐based model transformation framework

Rouhi

Lano

2023

Softw Pract Exp

View full text Add to dashboard Cite

Model‐Driven Development (MDD) is one of the important approaches to develop complex software systems. This approach tries to model a system in high‐abstraction level. Then through applying multiple transformations step by step, the model abstraction level is reduced and finally yields to executable code. As a result, Model transformation (MT) plays a pivotal role on the realization of MDD goals. Due to the increasing complexity of software systems, MTs naturally become more complex. Hence, qualitative technical issues may be overlooked or forgotten in these model transformations. To alleviate these issues in terms of technical debts/code smells in MTs, we can apply MT patterns. A main drawback on applying patterns is that most of them are cataloged in informal language. Additionally, construction of a conceptual framework to help MT designers through applying patterns requires a precise specification of the underlying MT patterns. With a formal basis, this paper is trying to realize the proposed framework. Hence, some of the existing well‐known MT patterns are formalized. Then based on the identified common technical debts/code smells in MTs, a designer can be directed to apply the appropriate patterns and resolve the detected problems iteratively. For the applicability and functionality of the proposed framework, several examples of problematic model transformations in terms of quality flaws were considered and resolved using the appropriate patterns. We consider the Epsilon Transformation Language (ETL) cases of model transformations in this paper, and other similar MT languages could be treated using the same measures and patterns as well.

show abstract

Technical Debt Tools: A Systematic Mapping Study

Cited by 5 publications

References 0 publications

Technical debt in the engineering of complex systems

Technical debt in the engineering of complex systems

Investigating the Relationship between Technical Debt Management and Software Development Issues

Towards a pattern‐based model transformation framework

Contact Info

Product

Resources

About