![](bg7.png)
ones found in literature, we recognise a spike in the
communication activity support in the last year. Li et
al. (Li et al., 2015) mentioned that only 28% of the
tools provide support to communication, contrasting
with 63% identified during our systematic mapping.
Tools like AnaConDebt supports the creation of a TD-
enhanced backlog, allowing the tracking of TD items,
and thus facilitating their estimation and communica-
tion among the stakeholders. We can conjecture that
this trend will continue over the next years since com-
munication activities make the technical debts more
visible and understandable to stakeholders allowing
them to be discussed and managed appropriately. In
line with this trend, we also identified an increase on
the support to the TD documentation activity, indi-
cating that researchers are studying and devising new
approaches to address technical debts that are not di-
rectly related to source code. We identified that TD
documentation is supported by 30% (15/50) of tools.
For example, Teamscale applies code quality analyses
to detect missing software documentation.
Regarding the TD prioritization activity, our map-
ping study found 13 tools, i.e. 23% of them, that han-
dle this activity. However, most of these tools only
provide means to assign priority to a given TD, thus
only a few tools implement an approach to assign a
priority to a TD automatically. Currently, there is no
consensus on what are the critical factors and how to
prioritize them. This context is mirrored in the frag-
mented support offered by the tools, leading to a lack
of widely used and validated set of tools specific to
TD prioritization (Lenarduzzi et al., 2019). Besides
that, our work revealed a scarcity of approaches that
account for cost, value, and resources constraint, and
a lack of industry evaluation of this kind of tool. Nev-
ertheless, this context reveals exciting gaps in the lit-
erature. We believe research on TD prioritization is
still evolving and is a promising research direction.
Next, we have the prevention and repayment ac-
tivities, both supported by 12% (6/50) of the tools.
Although there are several strategies proposed to TD
management in the literature, preventing the TD in-
sertion with explicit actions is not yet common prac-
tice (Rios et al., 2018). This can be the reason for
the relatively low number of tools that address this
activity. However, interestingly, we can also observe
that the scientific interest on prevention approaches
has been increasing since 2015. We conjecture that
this trend derives from the awareness of the technical
debt cost and the consensus that TD prevention can
occasionally be cheaper than its repayment. More-
over, prevention may also help other TD manage-
ment activities, as well as help in catching inexperi-
enced developer (Yli-Huumo et al., 2016). For ex-
ample, Themis (Foucault et al., 2018) is a customized
gamification tool that integrates with SonarQube and
version control tools with the aim of identifying and
measuring TD. Themis uses gamified features such
as points, leaderboards, and challenges as a way to
provide suggestions for developers on where to focus
their effort, and visualizations for managers to track
technical debt activities. The monitoring features pro-
vided by Themis become the technical debt more visi-
ble to the developers helping in the prevention of tech-
nical debts.
Regarding the repayment activity, it usually con-
cerns resolving technical debt through techniques
such as reengineering or refactoring. There are many
challenges in applying refactorings to repay technical
debt in large-scale industrial software projects (Surya-
narayana et al., 2015). For example, it is hard to en-
sure that the behavior of the software is unchanged af-
ter the refactorings. It is not surprising that the num-
ber of tools addressing this concern is low. For ex-
ample, JCaliper (Kouros et al., 2019) applies search-
based software engineering techniques as a means of
assessing TD and proposing a set of refactorings to
address it. It performs local search algorithms to ob-
tain a near-optimum solution and to propose TD re-
payment actions, automatically extracting the num-
ber, type and sequence of refactoring activities re-
quired to obtain the design without TD.
Our study also identified that 78% (39/50) of the
tools are dedicated to more than one TD activity. The
tools are usually associated with at least two different
TD activities, like Arcan that deals with identification
and measurement activities, or SATD that provides
support to TD monitoring and identification. On the
other hand, 22% (11/50) of the tools are specialized in
just one TDM activity, like FITTED that only focuses
on measurement.
Figure 4 presents the different level of attention re-
ceived by each TDM activity and TD type. The num-
ber into the bubbles represents the number of tools
associated with both a TD type and a TDM activity.
Among the ten TD types, as mentioned before, the TD
code is the most investigated in the selected papers.
It is also the TD type that is approached for all TD
activities, especially identification and measurement.
Therefore, code is the most valuable source of infor-
mation for technical debt tools. Most of the technical
debt tools exploit static code analysis techniques, so
this finding is in line with the expectations.
The RQ4 results are useful to inform practitioners
what approaches they have addressing specific TDM
activities, and also to help researchers to identify re-
search gaps in approaches for various TDM activities.
ICEIS 2021 - 23rd International Conference on Enterprise Information Systems
94