A systematic mapping study on technical debt and its management

Using Naming Patterns for Identifying Architectural Technical Debt

“…This work can be considered a valid proposal for ATD, because it corresponds to ATD by non-uniformity of patterns [2], and it takes into account a debt that affects maintainability and evolvability of software, without been included in not accepted topics as technical debt [37]. The approach of this proposal gives relevance to class names, and these determines the maintainability and legibility of software, between others [4,7,18,28,29,33,34].…”

“…Taking an easy solution on short-term in an activity of any phase of software development (i.e., requirements, design, implementation), can generate an accumulated technical debt, which, in a given period of time, can become big enough to affect future deliveries, making hard getting a successful outcome [6,24,37]. The debt comprises any aspect known as inappropiate which has not been addressed in due time (e.g., complex source code that needs refactoring) [24].…”

“…Frequently the technical debt, when is inserted, is less visible for decision makers in the software development [5]. The development of techniques for identifying and monitoring incidences of technical debt, is important for making explicit the debt and it could be resolved in due time [3,11,22,24,35,37].…”

An Open Tool for Assisting in Technical Debt Management

“…The available tools are focused on implementing metrics, specific techniques for TDM, or both of them. Techniques and tools for TD have been analyzed in literature reviews previously [4], [1], [3]. The goal of this tools is not to be a quality tool that implements metrics to keep the code quality.…”

“…Technical debt (TD) monitoring is one of the activities in technical debt management (TDM) [1]. To monitor TD, it is necessary to analyze the change of TD indicators over the software evolution.…”