Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Esta obra est´a bajo una Licencia
Creative Commons Atribuci´on
4.0 Internacional.
Tipo de art´ıculo: Art´ıculos de revisi´on
Tem´atica: Ingenier´ıa de software
Recibido: 29/4/2025 |Aceptado: 13/6/2025 |Publicado: 30/9/2025
Identificadores persistentes:
DOI: 10.48168/innosoft.s24.a287
ARK: ark:/42411/s24.a287
PURL: 42411/s24.a287
Identificaci´on y Medici´on de Deuda T´ecnica Autoadmitida en
Herramientas de Aprendizaje Profundo: Una Revisi´on
Sistem´atica
Identification and Measurement of Self-Technical Debt in
Deep Learning Frameworks: A Systematic Review
Elizabeth Cuatecontzi Cuahutle1[0009- 0008- 0531- 0354]*, Mar´ıa Guadalupe Medina
Barrera2[0009-0008-0531-0354], Ra´ul Cortes Maldonado3[0009-0008-0531-0354], Carlos Bueno
Avenda˜no4[0009- 0008- 0531- 0354]
1Tecnol´ogico Nacional de M´exico – Instituto Tecnol´ogico de Apizaco. Tlaxcala-M´exico. C´odigo Postal: 90491.
elizabeth.cc@apizaco.tecnm.mx
2Tecnol´ogico Nacional de M´exico – Instituto Tecnol´ogico de Apizaco. Tlaxcala-M´exico. C´odigo Postal: 90491.
Autor2@email.com
3Tecnol´ogico Nacional de M´exico – Instituto Tecnol´ogico de Apizaco. Tlaxcala-M´exico. C´odigo Postal: 90491.
Autor3@email.com
4Tecnol´ogico Nacional de M´exico – Instituto Tecnol´ogico de Apizaco. Tlaxcala-M´exico. C´odigo Postal: 90491.
Autor4@email.com
∗Autor para correspondencia: elizabeth.cc@apizaco.tecnm.mx
Resumen
La Deuda T´ecnica en el desarrollo de Software se refiere a las consecuencias de decisiones que priorizan solu-
ciones r´apidas sobre soluciones ´optimas. Este concepto, introducido por Ward Cunningham en 1992, ha sido
ampliamente estudiado para mejorar la calidad del software. En el contexto del aprendizaje profundo, la DT
tambi´en est´a presente debido al uso de herramientas que, aunque facilitan la creaci´on de modelos, pueden ge-
nerar DT y afectar su rendimiento. Con un proceso de tres fases, este trabajo presenta una revisi´on sistem´atica
de la literatura con el objetivo de identificar los tipos de DT presentes en herramientas de aprendizaje pro-
fundo, as´ı como las t´ecnicas empleadas para su identificaci´on y medici´on. Los estudios revisados muestran
que la DT puede aparecer en diversas fases del desarrollo, como el dise˜no, definici´on de requisitos, pruebas,
documentaci´on, c´odigo, algoritmos y compatibilidad. Adem´as, se identifican aspectos adicionales afectados,
tales como los datos, los modelos, el conocimiento y la infraestructura.Para identificar la DT, se han utiliza-
do enfoques como el an´alisis de comentarios en c´odigo est´atico, pull requests ycommits, aplicando t´ecnicas
manuales, miner´ıa de texto, redes neuronales y algoritmos de procesamiento de lenguaje natural. En cuanto a
su medici´on, predominan los m´etodos estad´ısticos. Los hallazgos de esta revisi´on permiten comprender mejor
c´omo la DT impacta las herramientas de aprendizaje profundo y ofrecen una base para orientar investigaciones
futuras sobre su gesti´on y mitigaci´on en el desarrollo de sistemas inteligentes.
Palabras claves: Aprendizaje profundo, deuda t´ecnica, herramientas de aprendizaje profundo, medici´on de
la deuda t´ecnica, tipos de deuda t´ecnica.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
171
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Abstract
Technical Debt in software development refers to the consequences of decisions prioritizing quick solutions
over optimal ones. This concept, introduced by Ward Cunningham in 1992, has been widely studied to improve
software quality. In the context of deep learning, Technical Debt is also present due to the use of tools that,
while facilitating model creation, may generate debt and negatively impact performance. Through a three-
phase process, this study presents a systematic literature review to identify the types of Technical Debt found
in deep learning tools and the techniques used for its identification and measurement. The reviewed studies
show that Technical Debt can arise in various development phases, such as design, requirements definition,
testing, documentation, source code, algorithms, and compatibility. Other affected aspects include data, models,
knowledge, and infrastructure. Several approaches have been used to identify technical debt, such as analyzing
comments in static code, pull requests, and commits, applying manual techniques, text mining, neural networks,
and natural language processing algorithms. In terms of measurement, statistical methods are predominantly
used. The findings of this review provide a better understanding of how Technical Debt impacts deep learning
tools and offer a foundation for guiding future research on its management and mitigation in the development
of systems within intelligent environments.
Keywords: Deep learning, deep learning tools, technical debt, types of technical debt, technical debt measure-
ment
1. Introducci´on
La aplicaci´on de tecnolog´ıas como la visi´on por computadora, el procesamiento de lenguaje natural y el
reconocimiento de voz ha permitido que la Inteligencia Artificial (Artificial Intelligence, AI por sus siglas en
ingl´es) revolucione y beneficie a m´ultiples sectores de la sociedad. Para lograrlo, la AI utiliza herramientas
como el aprendizaje autom´atico (Machine Learning, ML) y aprendizaje profundo (Deep Learning, DL).
El ML consiste en extraer conocimiento de los datos mediante algoritmos que permiten a la AI imitar la forma
en que los humanos aprenden [1]. En esta disciplina, el DL es una sub´area basada en redes neuronales, cuya
estructura y funcionamiento est´an inspirados en el cerebro humano [2]. La arquitectura de los modelos de DL
est´a compuesta por unidades interconectadas, llamadas neuronas, organizadas en una capa de entrada, una
o m´as capas ocultas y una capa de salida. Las redes de DL emplean m´ultiples capas ocultas profundamente
anidadas, lo que les permite realizar operaciones avanzadas, como convoluciones. Gracias a esta estructura, las
redes DL pueden procesar datos de entrada sin requerir un preprocesamiento extenso, generando autom´atica-
mente representaciones ´utiles para la tarea de aprendizaje [3]. De acuerdo con [4] esta capacidad ha convertido
al DL en una herramienta poderosa para resolver problemas complejos, lo que ha impulsado su popularidad
en la comunidad cient´ıfica para el desarrollo de aplicaciones.
Durante la creaci´on de este tipo de aplicaciones, los desarrolladores suelen apoyarse en herramientas y marcos
de trabajo (frameworks) de c´odigo abierto que facilitan su implementaci´on, una evaluci´on de herramientas
populares de DL son presentadas en [2]y[5]. Sin embargo, debido a la falta de conocimiento, la presi´on del
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
172
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
tiempo, el contexto complejo, entre otros factores, surgen incertidumbres durante su desarrollo lo que lleva
realizar suposiciones sobre su uso, lo que podr´a producir resultados no esperados [6].
Al igual que en los sistemas tradicionales, Suculley et al. en [7] se˜nalan que, en las herramientas y sistemas de
DL, factores como la presi´on del tiempo incrementan el riesgo de priorizar soluciones r´apidas sobre soluciones
´optimas. Esta tendencia, que antepone la velocidad de desarrollo a los costos y est´andares de calidad conduce
a la acumulaci´on de Deuda T´ecnica (DT). La DT es una met´afora introducida por Ward Cunningham en 1992
para describir los costos a largo plazo asociados con decisiones aceleradas durante el desarrollo de software. La
DT tiene una variedad de forma y puede afectar m´ultiples cualidades del software que incluye per no limita
a la legibilidad, el desempe˜no, y estructura [8]. En el contexto de ML, en [7] se abordan los desaf´ıos y costos
ocultos relacionados con la construcci´on y mantenimiento de sistemas de aprendizaje autom´atico, argumentan
que estos sistemas pueden acumular DT, ya que enfrentan problemas de mantenimiento t´ıpicos del c´odigo
tradicional y desaf´ıos espec´ıficos del ML, como la dependencia de datos, la configuraci´on de los datos y la
representaci´on del modelo.
Con una adaptaci´on del proceso de tres fases propuesto por Brereton et al. [9] y Kitchenham et al. [10], este
trabajo presenta los resultados de una Revisi´on Sistem´atica de la Literatura (RSL) sobre las pr´acticas actuales
en la identificaci´on y medici´on de la DT en herramientas de DL. El objetivo es identificar los tipos de DT m´as
comunes, los procesos, t´ecnicas y herramientas utilizadas para su detecci´on, as´ı como los criterios de medici´on
aplicables.
Los resultados de esta revisi´on motivan futuras investigaciones sobre el impacto de la DT en herramientas DL
para desarrollar sistemas DL aplicables en la soluci´on de problemas en diversos sectores de la sociedad.
Este documento se organiza en cuatro secciones. En la secci´on dos, se expone la motivaci´on que dio origen a
esta RSL. La secci´on tres detalla el proceso metodol´ogico de la revisi´on. En la secci´on cuatro, se discuten los
resultados obtenidos y se propone una metodolog´ıa para un estudio m´as amplio sobre la DT en herramientas
de DL y su impacto en aplicaciones de DL.
2. Motivaci´on
Las necesidades tecnol´ogicas en el desarrollo de las ciencias y en ´areas como la medicina, la educaci´on, la
manufactura y la ciberseguridad son cada vez m´as diversas, lo que hace que la incorporaci´on de tecnolog´ıas
emergentes como la AI, el ML y el DL sea de gran utilidad.
El DL ha contribuido con soluciones innovadoras en ´areas como el procesamiento de lenguaje natural, el
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
173
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
reconocimiento del habla y la visi´on por computadora. En DL se han desarrollado m´etodos basados en datos
que emplean m´ultiples capas de unidades interconectadas (neuronas) para aprender patrones y representaciones
a partir de datos. Una revisi´on sobre modelos de DL y sus aplicaciones es presentada en [11], mientras que [4]
presentan un analisis del progreso y los desaf´ıos actuales del DL.
La literatura tambien reporta un gran n´umero de aplicaciones de sistemas basados en DL. Por ejemplo,
en [2], [12]y[13] presentan una revisi´on del uso del DL en sistemas de salud, destacando aplicaciones clave
como el diagn´ostico por im´agenes, el procesamiento de se˜nales y el an´alisis de texto m´edico. En sus trabajo,
se˜nalan desaf´ıos como la falta de datos, la calidad de los resultados, problemas ´eticos, la interpretabilidad
de los modelos y la escalabilidad. Adem´as, abordan cuestiones como la integraci´on de modelos en entornos
cl´ınicos reales y la interoperabilidad tecnol´ogica.
Por otro lado, para apoyar el desarrollo de sistemas de DL, se han dise˜nado y utilizado herramientas que
integran bibliotecas de funciones y algoritmos de DL, que se aplican a una amplia variedad de contextos
cient´ıficos y tecnol´ogicos. Una evaluaci´on integral de herramientas populares de DL (TensorFlow, MXNet,
PyTorch, Theano, Chainer y Keras) en arquitecturas como CNN, R-CNN y LSTM es presentada en [2]. Su
estudio evalu´o la precision, el tiempo de entrenamiento y consumo de recursos de cada una. As´ı mismo,
en [5] se ofrece un an´alisis de las herramientas y marcos de trabajo m´as recientes que facilitan la creaci´on,
implementaci´on y expansi´on de modelos de DL, eval´uan las capacidades de marcos como Tensor Flow, Pytorch
y Keras. Por su parte, en [14] evaluaron el rendimiento de modelos de aprendizaje autom´atico y herramientas
de DL como PyTorch, Keras, TensorFlow, Caffe y Theano. Destacan que, aunque el uso de estas herramientas
est´a ampliamente difundido, es necesario evaluar su calidad, los desarrolladores de sistemas DL pueden asumir
supuestos sobre el uso y desempe˜no de estas herramientas, lo que podr´ıa derivar en vulnerabilidades, fallos,
inconsistencias o un incremento en los costos en las aplicaciones de DL.
Uno de las primeras investigaciones sobre la caracterizaci´on de la DT en herramientas de DL es realizada
y presentada en [15]. Sin embargo, el creciente desarrollo de sistemas basados en DL y el uso extendido de
estas herramientas motivan la necesidad de actualizar y profundizar estos hallazgos. Por su parte, Bathia et
al. [16] afirma que a pesar de los esfuerzos recientes para comprender la introducci´on y eliminaci´on de SATD
en herramientas de aprendizaje profundo, todav´ıa no se sabe mucho sobre la difusi´on y evoluci´on de la deuda
t´ecnica en los sistemas basados en ML utilizando tales herramientas.
De igual relevancia y en relaci´on con la identificaci´on y mitigaci´on de la DT es de suma importancia estudiar
la aplicaci´on de pr´acticas de ingenier´ıa de software para el ML. Nascimento et al, en [17] analizan como la
ingenier´ıa de software ha sido aplicada en el desarrollo de la AI y el ML, por su parte Serban et al. [18] destacan
la importancia de las pr´acticas de ingenier´ıa de software y publican una gu´ıa pr´actica para el desarrollo de
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
174
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
software con componentes de aprendizaje autom´atico.
3. Metodolog´ıa
Con una adaptaci´on del proceso de tres fases propuesto por Breton et al. [9] y Kitchenman et al. [10], se realiz´o
una RSL sobre la Identificaci´on y Medici´on de la Deuda T´ecnica en Herramientas de Aprendizaje Profundo.
La figura 1 muestra la metodolog´ıa que se sigui´o en este trabajo.
Figura 1. Proceso de RSL sistem´atica de la literatura. Adaptaci´on de la propuesta de [9] y [10]
Con esta propuesta se realiz´o la b´usqueda de art´ıculos cient´ıficos en bases de datos acad´emicas como IEEE
Xplore, ACM Digital Library, Science Direct, Springer Link, Google Scholar y Arxiv, para ello se inici´o de-
finiendo la cadena de b´usqueda utilizando palabras clave relacionadas con los t´erminos de ”deuda t´ecnica”,
”herramientas de aprendizaje profundo”, “categor´ıas o tipos de deuda t´ecnica” y “medici´on de deuda t´ecnica”.
Los criterios de inclusi´on se centraron en estudios que abordaran expl´ıcitamente la caracterizaci´on, identifica-
ci´on y medici´on de la DT en herramientas de aprendizaje profundo, finalmente se obtiene una s´ıntesis con los
resultados de esta Revisi´on.
Fase 1. Planeaci´on de la RSL.
Preguntas de investigaci´on. Se pretende identificar trabajos que estudian la presencia de DT en herramientas
de DL, los tipos que pueden existir, caracter´ısticas, etapa de desarrollo en que ocurren, y que herramientas de
aprendizaje profundo se presentan y con qu´e frecuencia. De igual forma se tiene inter´es en identificar procesos,
t´ecnicas, herramientas y recursos para identificarla y medirla.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
175
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
As´ı las preguntas que gu´ıan esta RSL son:
Pregunta 1. ¿Cu´ales son los tipos de deuda t´ecnica de mayor presencia en herramientas de aprendizaje pro-
fundo?
Pregunta 2. ¿Qu´e proceso y herramientas se utilizan para identificar y medir la DT en DL a trav´es de un
estudio descriptivo?
Protocolo de b´usqueda. Para dar respuesta a estas preguntas se forma una cadena de b´usqueda con las palabras
clave: Deuda T´ecnica, herramientas de aprendizaje profundo y criterios de medici´on.
(”Technical Debt.OR ”TechDebt.AND charac*) AND (”Deep Learning Frameworks.OR ”DL Frameworks”) AND
(Measurement)
Esta se aplica en los motores de b´usqueda de las principales Bibliotecas Digitales cient´ıficas como la IEEE
Xplore, ACM Digital Library, Springer Link, Science Direct, Google Acad´emico y ArXiv.
Criterios de inclusi´on y exclusi´on. En la RSL se trata de identificar trabajos relevantes sobre el estado actual
del estudio de la DT en herramientas de DL. Por lo que se consideran reportes de conferencias, congresos
y art´ıculos de los ´ultimos cinco a˜nos, adem´as se busca que los trabajos sean resultado de investigaciones
primarias realizadas por profesionales en centros de investigaci´on y/o universidades. Especialmente trabajos
que documenten aspectos de presencia DT, y su categorizaci´on de tipos de DT presentes en herramientas de
DL, o bien que informen de herramientas o t´ecnicas que permitan identificar y medir su presencia e impacto. Se
considera publicaciones anteriores a este periodo en el caso de trabajos cuya aportaci´on ha tenido un impacto
relevante en el tema de DT y herramientas de DL. Los trabajos que no se consideran en esta RSL son aquellos
que no sean primarios o trabajos informales como blogs de autores o instituciones no reconocidos, art´ıculos no
sujetos a revisi´on por pares o reportes del desarrollo de sistemas de DL.
Fase 2. Ejecuci´on de la RSL.
Selecci´on de los estudios relevantes. En cada Biblioteca Digital se aplic´o la cadena de b´usqueda definida en
el protocolo de la RSL, como resultado de esta b´usqueda se obtuvieron 244 documentos relacionados, cabe
se˜nalar que se realizaron ajustes para cumplir con la sintaxis del motor de b´usqueda. A continuaci´on, se realiza
una revisi´on general en los metadatos de los art´ıculos encontrados y se seleccionan solo aquellos que cumplen
con los criterios de inclusi´on definidos.
Registro de la extracci´on de datos del documento investigado. Con la informaci´on de los trabajos seleccionados,
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
176
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
se realiza una base de datos simple con los siguientes campos como elementos: T´ıtulo del art´ıculo; a˜no, autor(s);
biblioteca digital; objetivo(s) de la investigaci´on, metodolog´ıa, conceptos relevantes utilizados para describir
el dominio del tema; resultados y trabajos futuros propuestos.
Sintetizar la informaci´on. Para una mejor comprensi´on de la relaci´on de los trabajos seleccionados y su impacto
con el tema de inter´es, se analizan y se crea una s´ıntesis, identificando la informaci´on que da respuesta a las
preguntas de investigaci´on que se plantearon para esta RSL y tambi´en informaci´on adicional relevante que
aporte al tema.
Fase 3. Documentar la RSL.
Escribir el informe. Se presenta el informe de la RSL de la literatura realizada con las preguntas planteadas.
Pregunta 1. ¿Cu´ales son los tipos de deuda t´ecnica de mayor presencia en las herramientas de aprendizaje
profundo?
Para identificar los tipos de DT en software, [19] analizar´on comentarios en el c´odigo fuente de proyectos
de c´odigo abierto alojados en repositorios como GitHub. Estos comentarios introducidos deliberadamente
por los propios desarrolladores hacen referencia a observaciones sobre tareas pendientes, errores o posibles
fallas que ocurren en distintas fases del desarrollo como la codificaci´on o las pruebas. Generalmente, estos
problemas surgen de la adopci´on de soluciones r´apidas o temporales, lo que representa DT auto admitida.
Por su parte, [20] clasificaron y cuantificaron diferentes tipos de DT auto admitida mediante la extracci´on y
an´alisis de comentarios en el c´odigo. Identificaron cuatro tipos principales: deuda de dise˜no, deuda de defectos,
deuda de documentaci´on y deuda de pruebas.
De forma similar, [15] exploraron la presencia de DT en herramientas de DL de c´odigo abierto, para ello,
extrajeron comentarios realizados por los desarrolladores en diferentes etapas, incluyendo problemas de imple-
mentaci´on, pull requests y commits. Este enfoque les permiti´o identificar la existencia de DT auto admitida
en herramientas DL. En este trabajo, los investigadores analizaron herramientas populares como TensorFlow,
Keras, PyTorch, Caffe, MXNet, CNTK y DL4J. En su estudio, encontraron una cantidad significativa de DT
auto admitida, incluyendo dise˜no sub´optimo, defectos sin resolver, documentaci´on incompleta, deficiencias en
las pruebas e implementaci´on incompleta de m´etodos requeridos. Adem´as, identificaron DT de algoritmo, refi-
ri´endose a ella como las implementaciones sub´optimas de la l´ogica algor´ıtmica de los modelos de DL y m´odulos
de redes neuronales. Tambi´en detectaron DT de compatibilidad, asociada con dependencias inmaduras entre
proyectos, lo que obliga a utilizar soluciones temporales para garantizar la funcionalidad. Posteriormente, [21]
realizaron un estudio sobre la introducci´on y eliminaci´on de diferentes tipos de DT en herramientas de DL.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
177
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
En el trabajo realizado por [22], centraron su investigaci´on en la refactorizaci´on de c´odigo, haciendo ´enfasis
en la relaci´on entre el dise˜no y la fase de pruebas para mejorar el desempe˜no y alcanzar el requerimiento.
Por su parte, en [6] destacaron la necesidad de abordar la DT auto admitida en diversas fases del desarrollo,
incluyendo requisitos, dise˜no, codificaci´on, algoritmos, pruebas y documentaci´on. Tambi´en en [8] reconocieron
la presencia de DT en las fases de requerimientos, dise˜no, pruebas y documentaci´on.
As´ı mismo, [16] estudiaron la DT auto admitida e identifican DT de c´odigo, de dise˜no, de documentaci´on de
defectos, de pruebas y de requerimientos, las cuales afirma ocurren tanto en software tradicional y de confi-
guraci´on que es especifica de sistemas ML. La Tabla 1 resume los tipos de DT auto admitida en herramientas
de DL, identificados en distintas fases del desarrollo y reportados por diversos investigadores.
En la realizaci´on de esta RSL tambi´en se identificar´on trabajos que analizan tipos espec´ıficos de DT en ML
y DL. Por ejemplo, [22] examinan la relaci´on entre la deuda t´ecnica de c´odigo y la refactorizaci´on. Proponen
una taxonom´ıa jer´arquica de refactorizaciones en sistemas de aprendizaje autom´atico, considerando aspectos
como la reorganizaci´on del c´odigo, mejoramiento del desempe˜no, migraci´on de c´odigo, eliminaci´on de c´odigo
duplicado, mejoras en la seguridad, problemas de configuraci´on, comprensi´on del c´odigo y reutilizaci´on del
c´odigo, entre otros. Los autores ofrecen recomendaciones y mejores pr´acticas para desarrollar sistemas de DL,
para minimizar la acumulaci´on de DT.
amssymb
Tabla 1. Tipos de DT auto admitida en herramientas de DL.
Estudio Dise˜no Requisitos Documen-
taci´on
Pruebas Defectos C´odigo Algoritmo Compati-
bilidad
[15]✓ ✓ ✓ ✓ ✓ ✓ ✓
[23]✓ ✓ ✓
[6]✓ ✓ ✓ ✓ ✓ ✓
[21]✓ ✓ ✓ ✓ ✓ ✓ ✓
[8]✓ ✓ ✓ ✓ ✓ ✓
[16]✓ ✓ ✓ ✓ ✓ ✓
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
178
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Tabla 2. Problem´aticas identificadas en herramientas y sistemas DL, que inducen DT
[6] [8] [24] [25]
Problemas de:
Configuraci´on del
modelo y los da-
tos. Definici´on del
Tensor y variable
Dise˜no Varias.
Problemas de: Depen-
dencia de datos Depen-
dencia de c´odigo Esca-
labilidad Confiabilidad
Desempe˜no
Problemas de: Infra-
estructura. Hardware
APIS para la integra-
ci´on. Ciclo de vida del
desarrollo de DL Dato
Modelo Entrenamiento
Inferencia Flujo de
trabajo
Categor´ıas de proble-
mas relacionados con:
El procesamiento de da-
tos. Arquitectura y con-
figuraci´on del modelo
Entrenamiento del mo-
delo Resultados de la
predicci´on Inferencia de
los resultados. Entorno
de ejecuci´on Visualiza-
ci´on de los datos.
Tambi´en han surgido investigaciones que profundizan en el estudio de la DT en herramientas de DL, conside-
rando la naturaleza espec´ıfica de estos sistemas. La tabla 2 muestra los estudios relacionados, mismos que se
describen de forma breve.
Por ejemplo, [8] estudian la DT auto admitida en ML, incluyendo a DL, y reconocen su presencia en diversas
fases del desarrollo, como la definici´on de requerimientos, las pr´acticas de codificaci´on, la implementaci´on,
la deficiencia de pruebas, la falta de buenas pr´acticas de dise˜no y la documentaci´on inadecuada. Proponen
una taxonom´ıa para el estudio de la DT auto admitida, organizada en nueve grupos: dependencia de datos,
dependencia de c´odigo, concientizaci´on, modularidad, configuraci´on, deuda de escalabilidad, confiabilidad,
desempe˜no y eliminaci´on de c´odigo duplicado. Cada grupo incluye subtipos que, en conjunto, forman lo que
los autores denominan las 23 sombras de la DT auto admitida en software de ML.
Otros afirman que durante el desarrollo de sistemas DL, surgen hip´otesis relacionadas con las herramientas de
DL, [6] sostiene que las suposiciones son conocimientos en el desarrollo de software que se dan por hecho o se
aceptan como verdaderos sin evidencia, la falta de conciencia sobre estas suposiciones puede provocar problemas
cr´ıticos como vulnerabilidades, fallos, inconsistencias y aumento de costos. Estas suposiciones se clasifican en
categor´ıas como configuraci´on y contexto, y variable, dise˜no y miscel´anea, esta ´ultima abarca aspectos como
conjuntos de datos, pruebas, errores y fallos, usuarios, costo-beneficio y rendimiento. Enss [14] destacan que los
stakeholders (partes interesadas) en el desarrollo de herramientas de DL suelen hacer suposiciones relacionadas
con decisiones de dise˜no, requisitos y DT. Estas decisiones pueden resultar no v´alidas, lo que provoca fallos en
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
179
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
los sistemas DL.
Otro estudio es el presentado por [24], quienes, tras analizar manualmente comentarios en proyectos de c´odigo
abierto desarrollados con herramientas de Deep Learning como TensorFlow y PyTorch, crean una taxonom´ıa
espec´ıfica de Deuda T´ecnica (DT) auto admitida. En su propuesta, identifican dos categor´ıas principales
relacionadas con aspectos de infraestructura y el ciclo de vida del desarrollo en Deep Learning. La categor´ıa de
infraestructura abarca aspectos vinculados al hardware necesario para ejecutar modelos de DL y a las API para
la integraci´on de herramientas en el proceso de desarrollo. Tambi´en incluye la compatibilidad entre diferentes
herramientas y la optimizaci´on del uso de recursos computacionales. Por otro lado, la categor´ıa del ciclo de
vida del desarrollo comprende tareas y desaf´ıos en distintas etapas del proceso de creaci´on de sistemas de DL.
Estas etapas incluyen: definici´on de datos, dise˜no y configuraci´on del modelo, configuraci´on del proceso de
entrenamiento, inferencia (tratamiento y an´alisis de los resultados generados durante la ejecuci´on del modelo)
y el dise˜no y optimizaci´on del flujo de trabajo completo, desde la entrada de datos hasta la salida de resultados.
Finalmente, los autores concluyen que cuando estos desaf´ıos se abordan con soluciones sub´optimas, se genera
una DT espec´ıfica de DL, lo que puede afectar la calidad, mantenibilidad y escalabilidad de los sistemas
desarrollados.
En esta RSL tambi´en se observ´o constante referencia a los desaf´ıos enfrentados en el desarrollo de sistemas de
DL, por lo que se incluyeron estudios relacionados con los problemas de los desarrolladores al crear y mantener
estos sistemas. Por ejemplo, [25] analizan publicaciones y preguntas que los desarrolladores realizan en sitios
como Stack Overflow, identifican siete categor´ıas y 63 subcategor´ıas de problemas relacionados con los marcos
de DL TensorFlow, PyTorch, y Theano. Los autores encontraron que las dificultades en la implementaci´on
representan la mayor´ıa de las preguntas formuladas por los desarrolladores (97.7 %), lo que sugiere problemas
en la estabilidad de las aplicaciones construidas con estos marcos. Estos defectos reflejan DT acumulada, lo
que impacta negativamente en la calidad general de los proyectos de DL. Las categor´ıas son: 1) Problemas
relacionados con el procesamiento de datos, 2) dificultades con la arquitectura y configuraci´on del modelo,
3) desaf´ıos encontrados durante la fase de entrenamiento de los modelos, 4) problemas que surgen al hacer
predicciones con los modelos entrenados, 5) dificultades relacionados con la evaluaci´on del rendimiento y la
precisi´on de los modelos, 6) dificultades asociados con el entorno en el que se ejecutan los modelos, incluyendo
dependencias y compatibilidad, y 7) preocupaciones sobre la visualizaci´on de datos, el rendimiento del modelo
y los resultados.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
180
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Figura 2. Distribuci´on de la DT en DL seg´un su tipo. Elaboraci´on propia con datos de [15] y [21]
En relaci´on con la distribuci´on de la DT en las herramientas de DL, [15] analizaron comentarios en repositorios
de c´odigo en GitHub e identificaron la presencia de DT auto admitida en herramientas de DL como Tensor
Flow, Keras, Caffe, PyTorch, MXNet, CNTK y DL4J. La Figura 2 muestra la evoluci´on de la DT en los
periodos analizados, destacan que la deuda de dise˜no es la m´as prevalente durante el proceso de desarrollo,
seguida por la deuda de requisitos y la deuda de algoritmo. Posteriormente [21] encontraron que la DT de
requisitos, seguida por la DT de dise˜no, son las que se eliminan con mayor frecuencia. Por el contrario, la DT
de documentaci´on y la DT de pruebas son las que menos se remueven, mientras que la DT de compatibilidad
y la DT de pruebas presentan los procesos de eliminaci´on m´as lentos. La Tabla 3 resume la ocurrencia de
los distintos tipos de DT en los marcos de DL analizados, proporcionando una visi´on comparativa seg´un su
frecuencia y persistencia en el tiempo.
Pregunta 2. ¿Qu´e procesos y herramientas se utilizan para identificar y medir la DT en DL a trav´es de un
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
181
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
estudio descriptivo?
Para identificar la deuda t´ecnica auto admitida los trabajos revisados analizan comentarios que los desarrolla-
dores realizan en el c´odigo, en los commits o en pullrequest de las herramientas, en plataformas de preguntas
y respuestas. Para medir su presencia estudios proponen el uso m´etricas cuantitativas basadas en el an´alisis
del c´odigo est´atico, mientras que otros sugieren enfoques cualitativos, como revisiones de c´odigo, hay incluso
propuestas de herramientas de miner´ıa texto y t´ecnicas de procesamiento de lenguaje natural (PLN). La ta-
bla 4 resume las fuentes, mecanismos y herramientas y/o t´ecnicas que los investigadores han utilizado para
identificar la DT en herramientas DL.
Tabla 3. Presencia de la deuda T´ecnica en herramientas de aprendizaje profundo. Puede observarse que CNTK
present´o el mayor porcentaje de DT en los dos a˜nos estudiados.
A˜no 2020 2021
Tipo de DT Mayor Menor Mayor Menor
Dise˜no CNTK -
65.27 %
Keras - 24.07 % CNTK - 76.33 % Caffe 48.52 %
Requisitos DL4J -
20.67 %
Caffe - 5.62 % Keras - 16.75 % CNTK - 7.04 %
Documentaci´on Caffe -
15.62 %
Keras - 0.00 % Caffe - 20.00 % Keras - 0.00 %
Pruebas Tensorflow
- 7.70 %
Keras - 0.00 % Tensorflow -
5.12 %
Keras - 0.52 %
Defectos MXNet -
8.47 %
Keras - 1.85 % CNTK - 5.54 % MXNEt - 3.01 %
Algoritmo Keras -
31.48 %
Tensorflow -
7.09 %
Keras - 14.14 % DL4J - 4.82 %
Compatibilidad Keras -
35.18 %
DL4-J 0.21 % Caffe - 10 % DL4-J 0.0 %
En el estudio realizado por [15] extrajeron comentarios del c´odigo fuente, commits y pullrequest en herramientas
de aprendizaje profundo como TensorFlow, Keras, DL4J, Caffe, PyTorch, MXNet y CNTK, accesando a
repositorios alojados en GitHub. Para este proceso, emplearon herramientas como srCML y el m´odulo tokenize
de la librer´ıa est´andar de Python, que proporciona un esc´aner l´exico para identificar comentarios en el c´odigo.
Con los datos recolectados, realizaron una revisi´on y clasificaci´on manual en cinco categor´ıas: deuda de dise˜no,
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
182
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
deuda de defectos, deuda de requerimientos, deuda de documentaci´on y deuda de pruebas. La propuesta de
estas categor´ıas fue tomada de [20]. Este proceso de an´alisis de comentarios incluy´o varias iteraciones, evaluadas
cualitativamente por varios investigadores para garantizar la coherencia en la clasificaci´on. Para medir el grado
de acuerdo entre los evaluadores, los autores utilizaron la m´etrica estad´ıstica del coeficiente de Cohen’s kappa.
El an´alisis del c´odigo abarc´o distintos niveles de granularidad, incluyendo comentarios en m´etodos, clases y
archivos que conten´ıan metainformaci´on de la herramienta. Un ejemplo de este an´alisis es el, por ejemplo, el
commit:
“TODO: this option should be abstracted, if we decide to generalize this training master” - [from DL4J]
“TODO: make it public?” - [from Keras],
indica qu´e, si bien la implementaci´on actual ha cumplido las funcionalidades expl´ıcitas en el requisito, el dise˜no
del c´odigo no es ´optimo.
Posteriormente, [21] extienden su estudio para identificar la frecuencia de ocurrencias y eliminaci´on de DT
auto admitida en siete herramientas de DL, sus hallazgos indican que durante el proceso de desarrollo la
deuda de dise˜no es la que m´as se introduce, la deuda de requisitos es la que m´as se elimina, y son los propios
desarrolladores quienes eliminan la DT. Para su identificaci´on utilizan un algoritmo basado en procesamiento
de lenguaje natural (PLN) para identificar autom´aticamente los comentarios que indican DT. La clasificaci´on
la realizaron de forma manual, en dos iteraciones utilizando el enfoque card sorting de Spencer (2009). En
este trabajo tambi´en eval´uan el desempe˜no de SATD-Detector, que es una herramienta para la clasificaci´on de
texto con PLN desarrollada por [26] para identificarla y la cual se entren´o para ello.
Por su parte [6], al analizar supuestos auto admitidos en herramientas de DL, para su identificar su distribuci´on,
clasificaci´on e impacto, utilizan comentarios de c´odigo de nueve herramientas populares de herramientas DL
alojadas de GitHub, utilizan herramientas de Visual Studio y librer´ıas de Python para recolectar los comentarios
de c´odigo relacionados, utilizaron t´erminos relacionados con supuestos como assumption, assumptions, assume,
assuming, assummed. Para la clasificaci´on una revisi´on cualitativa por varios autores y en diferentes rondas,
utilizaron y coeficiente de Cohen Kappa para medir la concordancia entre los evaluadores. Para el an´alisis de
datos utilizaron estad´ıstica descriptiva.
En el caso del estudio presentado por [8] para el an´alisis de la DT auto admitida en proyectos ML escritos en
Python, minan comentarios de sistemas ML en GitHub, emplearon Boa [27], un lenguaje dise˜nado espec´ıfica-
mente para extraer comentarios de repositorios de software identifica cuando un comentario ha sido introducido
o eliminado en las actualizaciones del c´odigo. Con una inspecci´on manual clasifican comentarios que represen-
tan DT auto admitida y los que no. Tambi´en utilizaron la herramienta de clasificaci´on SATD-Detector [26]
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
183
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
entrenado con palabras clave asociadas a la categorizaci´on, y aplicaron el coeficiente Kappa de Cohen para
medir el grado de acuerdo entre evaluadores. La clasificaci´on se realiz´o manualmente tras definir un esquema
que considera una taxonom´ıa propuesta por [7] y nuevamente aplicaron coeficiente Cohen Kappa.
En la propuesta de [25] analizan publicaciones en sitios de comunidades de desarrolladores, en este Stack
Overflow. Identifican publicaciones que se relacionan con problemas de implementaci´on en herramientas de
DL, en este caso con TensorFlow, PyTorch y Theano. El estudio incluy´o la recolecci´on de datos, seguida de un
proceso de refinamiento y obtenci´on de caracter´ısticas, para la construcci´on de una taxonom´ıa; realizan una
clasificaci´on y predicci´on utilizando modelos de Redes Neuronales.
Tabla 4. T´ecnicas y herramientas para identificaci´on y an´alisis de DT en herramientas de DL.
Estudio Fuente Datos T´ecnicas y/o herramientas de
extracci´on y an´alisis de DT
[15] Repositorios GitHub
de herramientas DL de
TensorFlow, Theano,
Pytorch, Caffe, MXNet,
Keras, CNTK, DL4J, y
Paddle Paddle.
Extracci´on de co-
mentarios en c´odigo
fuente
Herramientas de extracci´on:
srcML, M´odulo Tokenize de
Python. Clasificaci´on: Manual
realizada por varios autores en
varias iteraciones. An´alisis y
validaci´on: Coeficiente de kap-
pa de Cohen y m´etricas es-
tad´ısticas.
[21] Extracci´on de archi-
vos de comentarios
en versiones sucesi-
vas de las herramien-
tas de DL
Clasificaci´on: Manual con
t´ecnica Card Sorting, eval´uan
algoritmos basados en NLP y
herramienta SAT-Detector
[6] Repositorios en GitHub
de TensorFlow, Theano,
Pytorch, Caffe, MXNet,
Keras, CNTK, DL4J, y
Paddle Paddle.
Extracci´on y an´alisis
de comentarios que
indican deuda t´ecni-
ca auto admitida.
Herramientas de extracci´on:
Visual Studio y herramientas
de Tokenizaci´on de Python
Clasificaci´on: Manual por au-
tores An´alisis y validaci´on:
Revisi´on cualitativa, Coefi-
ciente de kappa de Cohen y
Estad´ıstica descriptiva.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
184
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Estudio Fuente Datos T´ecnicas y/o herramientas de
extracci´on y an´alisis de DT
[8] Repositorios GitHub de
sistemas DL
Extracci´on de co-
mentarios, que in-
dican deuda t´ecnica
auto admitida
Herramientas de extracci´on:
Lenguaje BOA para minar da-
tos. Clasificaci´on: Manual pa-
ra identificas SAT y SAT-
Detector de la que no lo es.
Clasificaci´on manual para cla-
sificar de acuerdo con la taxo-
nom´ıa. An´alisis y validaci´on:
Coeficiente de kappa de Co-
hen
[25] Sitio web Stack Over-
flow
Publicaciones re-
lacionadas con
problemas de im-
plementaci´on en
herramientas DL
de Tensorflow y
Pytorcg
Extracci´on: Manual Clasifica-
ci´on: Modelos de Redes Neu-
ronales
[14] Herramientas DL en
GitHub
Comentarios de
c´odigo, pullrequest y
commits relaciona-
dos con supuestos.
Clasificaci´on y an´alisis con
modelos no transformadores
(M´aquinas de Vectores de So-
porte y ´
Arboles de Decisi´on),
el modelo ALBERT y modelos
de solo codificador.
Recientemente, [14] clasifican suposiciones de decisiones de dise˜no requisitos y deuda t´ecnica en el desarrollo
en herramientas de DL, a partir de la colecci´on de un conjunto de datos de comentarios de supuestos desde el
punto de vista de desarrolladores y usuarios. Los datos son recolectados de fuentes como comentarios de c´odigo,
pullrequest ycommits alojados repositorios de las herramientas DL en GitHub. En su primer estudio analizaron
y clasificaron los supuestos de forma manual; en este estudio tras la construcci´on de un conjunto de datos mayor
y la definici´on de un esquema de clasificaci´on, exploran el desempe˜no de cuatro modelos no transformadores
(ejemplo, M´aquinas de Vectores de Soporte, ´
Arboles de Decisi´on), el modelo ALBERT (a lite Bidirectional
Encoder Representations from Transformers) y tres modelos de solo codificador (ejemplo, ChatGpt, Claude y
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
185
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Gemini). Observaron que el modelo ALBERT alcanza el mejor desempe˜no en la clasificaci´on. ALBERT es un
modelo de PLN desarrollado por Google [28].
4. Discusi´on
Con la revisi´on sistem´atica de la literatura realizada se encontraron estudios relevantes sobre la identificaci´on
y medici´on de DT en herramientas de DL. Los hallazgos permitieron identificar los tipos de DT presentes en
estas herramientas y, en algunos casos, analizar su incidencia. Adem´as, se identificaron m´etodos y herramientas
utilizados para su detecci´on y medici´on.
Los estudios muestran que la DT en el contexto de las herramientas y sistemas de DL puede ocurrir en diversas
etapas de su desarrollo y tambi´en en alguno de sus componentes. Los estudios muestran que la DT suele ocurrir
en las fases de dise˜no, requisitos, c´odigo, pruebas y documentaci´on, determin´andose como los tipos de deuda
en DL. Entre estos, la DT de mayor presencia es la de dise˜no, la cual puede ocurrir por diversos factores
como un dise˜no modular deficiente o r´ıgido que dificulta la incorporaci´on de nuevas funcionalidades o bien, su
mejoramiento.
Otros estudios abordan aspectos espec´ıficos del DL, como la DT de compatibilidad, esta ocurre cuando las
herramientas o bibliotecas no son f´acilmente actualizables ni compatibles entre versiones o con versiones futuras.
Tambi´en se encuentra DT de algoritmo, que surge al implementar un algoritmo sub´optimo sin previsi´on de
necesidades futuras, o inadecuadas para redes profundas.
En las herramientas de DL tambi´en se encuentra DT que se relaciona con los datos, los modelos, la infra-
estructura o incluso el conocimiento del modelo y la herramienta. La DT en datos puede ser originada por
sesgos, dependencia de las fuentes de obtenci´on o falta de trazabilidad. La DT en los modelos, puede ocurrir
cuando los par´ametros de este no se ajustan u optimizan correctamente para el problema en cuesti´on. La DT
en infraestructura puede deberse a la dependencia del hardware o a la integraci´on con los sistemas de software.
La DT de conocimiento puede generarse por el mismo desconocimiento de los desarrolladores sobre los modelos
o falta de formaci´on en nuevas tecnolog´ıas.
La principal fuente de obtenci´on de datos para el estudio de la DT son los comentarios que desarrolladores
realizan directamente en el c´odigo o cuando realizan acciones de pullrequest o commits. Por lo que se le ha
denominado DT auto admitida. Estos comentarios son ubicados en los repositorios de las herramientas como
PyTorch, Keras, Caffe, Theano, etc., que al ser de c´odigo abierto es posible acceder a ellos. Otra fuente de
obtenci´on de datos son los comentarios que usuarios de las herramientas de DL realizan en sitios de las propias
herramientas o en sitios web como Stackoverflow.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
186
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
Para extraer los comentarios, se realiza manualmente o bien, se utilizan herramientas autom´aticas, para su
clasificaci´on se identific´o que en varios de los trabajos aplican t´ecnicas manuales, pero en trabajos recientes
se han aplicado herramientas de miner´ıa de texto, redes neuronales e incluso algoritmos de procesamiento
de lenguaje natural. En cuanto a la medici´on de la DT, se observ´o la aplicaci´on de m´etodos cuantitativos y
cualitativos con t´ecnicas estad´ısticas
Es importante mencionar que durante la revisi´on se observ´o la existencia de diversos e importantes investi-
gaciones relacionados con el estudio de la DT auto admitida y su caracterizaci´on. Sin embargo, muchos de
estos estudios se enfocaron al software tradicional, pero existen muy pocos en los sistemas de aprendizaje
autom´atico y, en menos cantidad, se ubican los estudios relacionados con la identificaci´on y medici´on de la
DT en herramientas de DL. En [16] realizan un estudio sobre DT auto admitida en software tradicional y en
software de ML que afirman que la DT aparece en una etapa m´as temprana del proceso de desarrollo.
Lo anterior podr´ıa deberse a que desde su surgimiento en 1990 el concepto propuesto por Ward Cunnigham,
ha sido ampliamente estudiado en Ingenier´ıa de Software y metodolog´ıas ´agiles. Sin embargo, aunque el DL
surgi´o en los a˜nos 40 con las primeras redes neuronales, este ha ganado relevancia en los ´ultimos 15 a˜nos [29],
adem´as sus tecnolog´ıas e investigaciones evoluciona r´apidamente, tanto en aspectos de infraestructura, modelos
y herramientas, por lo que consideramos que, si bien hay avances, a´un se est´a en proceso de definir claramente
el concepto DT en DL y como medirla, para entonces poder vislumbrar su impacto. Otro aspecto importante a
considerar y que no facilita su an´alisis es que la deuda no solo es c´odigo, tambi´en se involucran datos y modelos,
incluso infraestructura, su interacci´on pueda ocultarla, Sculley et al. [7], adem´as la naturaleza no determinista
de los sistemas ML complica la aplicaci´on de la Ingenier´ıa de Software Giray [30], Nascimento et al. [17]
investigaron como la ingenier´ıa de software ha sido aplicada en el desarrollo de sistemas de ML e identificaron
los retos y pr´acticas aplicables a las necesidades profesionales. Podemos afirmar que, para software tradicional,
existen m´etricas bien definidas para evaluar la DT, y en DL como hemos observado se estan explorando.
Nos damos cuenta tambi´en que muchas investigaciones sobre DT provienen de la comunidad en Ingenier´ıa de
Software y poco de las comunidades de Inteligencia Artificial y Aprendizaje Autom´atico, pareciera ser que
existe un puente que separa objetivos y metodolog´ıas que permitan identificar, definir, medir y mitigar esta
deuda.
Con base en lo anterior podemos visualizar ´areas de oportunidad como:
1. Dado que, la fuente de informaci´on principal para el estudio de la DT en DL proviene de comentarios que
son introducidos deliberadamente por desarrolladores, misma que es conocida como DT auto admitida,
consideramos pertinente un ´area futura de investigaci´on, enfocada al estudio de la Deuda T´ecnica Auto
Admitida en Herramientas de Aprendizaje Profundo, concepto que dar´ıa pauta para estudiar su origen,
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
187
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
caracterizaci´on, evoluci´on e impacto.
2. Consideramos como ´area de oportunidad explorar herramientas de clasificaci´on y predicci´on usando PLN,
ya que ha mostrado resultados importantes en el an´alisis y predicci´on de textos; y dado que la DT auto
admitida tomo como base el an´alisis de comentarios, una oportunidad de investigaci´on es el estudio,
desarrollo y aplicaci´on una metodolog´ıa basada en PLN que contribuyan a las existentes.
3. Finalmente, dado el crecimiento del desarrollo de sistemas basados en DL y su impacto en la sociedad,
es crucial continuar investigando c´omo la DT afecta su evoluci´on y calidad. Los resultados obtenidos
muestran avances relevantes, nos damos cuenta de la importancia y pertinencia de esta revisi´on pues
puede sentar las bases para futuras investigaciones que eval´uen el impacto de la DT en el desarrollo de
sistemas DL y su repercusi´on en la sociedad.
Conclusiones
Esta revisi´on sistem´atica identific´o enfoques para detectar y medir Deuda T´ecnica en herramientas de Apren-
dizaje Profundo, destacando que para su an´alisis se recurre a la extracci´on de comentarios en repositorios de
GitHub, mismos que realizan los desarrolladores.
La clasificaci´on m´as usada es la de [20], que distingue Deuda Tecnica en dise˜no, defectos, documentaci´on y
pruebas. Sin embargo, estudios recientes en herramientas de Aprendizaje profunfo incluyen categor´ıas como
Deuda T´ecnica de algoritmo, compatibilidad, dependencia de datos, modelo e infraestructura.
Para su medici´on, se observ´o el uso de m´etricas cuantitativas y enfoques cualitativos como revisiones de c´odigo,
miner´ıa de texto y Procesamiento de Lenguaje Natural.
Como trabajo futuro, se plantea la oportunidad de realizar un estudio descriptivo de la DT en DL y con una
metodolog´ıa con enfoque en ingenier´ıa de software y con el uso de algoritmos y herramientas de PLN, para en
un futuro evaluar el impacto de la DT en aplicaciones DL en ciencia y sociedad.
Agradecimientos
Expreso mi profundo agradecimiento a Tecnol´ogico Nacional de M´exico-Instituto Tecnol´ogico de Apizaco por
brindarme la formaci´on acad´emica y los recursos necesarios para el desarrollo de esta investigaci´on, tambi´en
por las facilidades para poder dedicar tiempo a este proyecto, as´ı como a mis colegas por su colaboraci´on
y valiosas contribuciones. Finalmente expreso mi agradecimiento a la Secretar´ıa de Ciencia, Humanidades,
Tecnolog´ıa e Innovaci´on en M´exico por su respaldo y compromiso con la innovaci´on, lo que ha hecho posible
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
188
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
la realizaci´on de este trabajo.
Contribuci´on de Autor´ıa
Elizabeth Cuatecontzi Cuahutle: Conceptualizaci´on,Metodolog´ıa,Investigaci´on,Software,Validaci´on,Redac-
ci´on - borrador original. Mar´ıa Guadalupe Medina Barrera: Conceptualizaci´on,Metodolog´ıa,An´alisis formal,
Recursos,Visualizaci´on,Supervisi´on,Administraci´on de proyectos,Adquisici´on de fondos,Curaci´on de da-
tos,Escritura, revisi´on y edici´on. Ra´ul Cortes Maldonado: Conceptualizaci´on,Metodolog´ıa,An´alisis formal,
Recursos,Visualizaci´on,Supervisi´on,Administraci´on de proyectos,Curaci´on de datos,Escritura, revisi´on y
edici´on. Carlos Bueno Avenda˜no: Conceptualizaci´on,Metodolog´ıa,An´alisis formal,Recursos,Visualizaci´on,
Supervisi´on,Administraci´on de proyectos,Curaci´on de datos,Escritura, revisi´on y edici´on.
Referencias
[1] R. Y. Choi, A. S. Coyner, J. Kalpathy-Cramer, M. F. Chiang, and J. P. Campbell, “Introduction to
machine learning, neural networks, and deep learning,” Transl Vis Sci Technol, vol. 9, no. 2, 2020.
[2] R. Elshawi, A. Wahab, A. Barnawi, and S. Sakr, “Dlbench: a comprehensive experimental evaluation of
deep learning frameworks,” Cluster Comput, vol. 24, no. 3, pp. 2017–2038, 2021.
[3] C. Janiesch, P. Zschech, and K. Heinrich, “Machine learning and deep learning,” Electronic Markets,
vol. 31, no. 3, pp. 685–695, 2021.
[4] M. H. M. Noor and A. O. Ige, “A survey on state-of-the-art deep learning applications and challenges,”
2024.
[5] N. L. Rane, S. K. Mallick, O. Kaya, and J. Rane, “Tools and frameworks for machine learning and
deep learning: A review,” in Applied Machine Learning and Deep Learning: Architectures and Techniques.
Deep Science Publishing, 2024.
[6] C. Yang, P. Liang, L. Fu, and Z. Li, “Self-claimed assumptions in deep learning frameworks: An exploratory
study,” in Evaluation and Assessment in Software Engineering. New York, NY, USA: ACM, Jun. 2021,
pp. 139–148.
[7] D. Sculley, D. Holt, E. Davydov, and T. Phillips, “Hidden technical debt in machine learning systems,”
Adv Neural Inf Process Syst, 2015.
[8] D. OBrien, S. Biswas, S. Imtiaz, R. Abdalkareem, E. Shihab, and H. Rajan, “23 shades of self-admitted
technical debt: an empirical study on machine learning software,” in Proceedings of the 30th ACM Joint
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
189
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
European Software Engineering Conference and Symposium on the Foundations of Software Engineering.
New York, NY, USA: ACM, Nov. 2022, pp. 734–746.
[9] P. Brereton, B. A. Kitchenham, D. Budgen, M. Turner, and M. Khalil, “Lessons from applying the
systematic literature review process within the software engineering domain,” Journal of Systems and
Software, vol. 80, no. 4, pp. 571–583, 2007.
[10] B. Kitchenham and P. Brereton, “A systematic review of systematic review process research in software
engineering,” Inf Softw Technol, vol. 55, no. 12, pp. 2049–2075, 2013.
[11] S. Dong, P. Wang, and K. Abbas, “A survey on deep learning and its applications,” Comput Sci Rev,
vol. 40, p. 100379, 2021.
[12] S. Shamshirband, M. Fathi, A. Dehzangi, A. T. Chronopoulos, and H. Alinejad-Rokny, “A review on deep
learning approaches in healthcare systems: Taxonomies, challenges, and open issues,” J Biomed Inform,
vol. 113, p. 103627, 2021.
[13] C. Aracena, F. Villena, F. Arias, and J. Dunstan, “Applications of machine learning in healthcare,”
Revista Medica Clinica Las Condes, vol. 33, no. 6, pp. 568–575, 2022.
[14] C. Yang, P. Liang, and Z. Ma, “An exploratory study on automatic identification of assumptions in the
development of deep learning frameworks,” Sci Comput Program, vol. 240, p. 103218, 2024.
[15] J. Liu, Q. Huang, X. Xia, E. Shihab, D. Lo, and S. Li, “Is using deep learning frameworks free?” in Procee-
dings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering
in Society. New York, NY, USA: ACM, Jun. 2020, pp. 1–10.
[16] A. Bhatia, F. Khomh, B. Adams, and A. E. Hassan, “An empirical study of self-admitted technical debt
in machine learning software,” 2024.
[17] E. Nascimento, A. Nguyen-Duc, I. Sundbø, and T. Conte, “Software engineering for artificial intelligence
and machine learning software: A systematic literature review,” 2020.
[18] A. Serban, K. van der Blom, H. Hoos, and J. Visser, “Software engineering practices for machine learning
— adoption, effects, and team assessment,” Journal of Systems and Software, vol. 209, p. 111907, 2024.
[19] A. Potdar and E. Shihab, “An exploratory study on self-admitted technical debt,” in 2014 IEEE Inter-
national Conference on Software Maintenance and Evolution. IEEE, Sep. 2014, pp. 91–100.
[20] E. da S. Maldonado and E. Shihab, “Detecting and quantifying different types of self-admitted technical
debt,” in 2015 IEEE 7th International Workshop on Managing Technical Debt (MTD). IEEE, Oct. 2015,
pp. 9–15.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
190
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 171-191
https://revistas.ulasalle.edu.pe/innosoft
[21] J. Liu, Q. Huang, X. Xia, E. Shihab, D. Lo, and S. Li, “An exploratory study on the introduction and
removal of different types of technical debt in deep learning frameworks,” Empir Softw Eng, vol. 26, no. 2,
p. 16, 2021.
[22] Y. Tang, R. Khatchadourian, M. Bagherzadeh, R. Singh, A. Stewart, and A. Raja, “An empirical study
of refactorings and technical debt in machine learning systems,” in 2021 IEEE/ACM 43rd International
Conference on Software Engineering (ICSE). IEEE, May 2021, pp. 238–250.
[23] ——, “An empirical study of refactorings and technical debt in machine learning systems,” in 2021
IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, May 2021, pp.
238–250.
[24] F. Pepe, F. Zampetti, A. Mastropaolo, G. Bavota, and M. D. Penta, “A taxonomy of self-admitted
technical debt in deep learning systems,” 2024.
[25] C. Liu, R. Cai, Y. Zhou, X. Chen, H. Hu, and M. Yan, “Understanding the implementation issues when
using deep learning frameworks,” Inf Softw Technol, vol. 166, p. 107367, 2024.
[26] Z. Liu, Q. Huang, X. Xia, E. Shihab, D. Lo, and S. Li, “Satd detector,” in Proceedings of the 40th
International Conference on Software Engineering: Companion Proceeedings. New York, NY, USA:
ACM, May 2018, pp. 9–12.
[27] R. Dyer, H. A. Nguyen, H. Rajan, and T. N. Nguyen, “Boa:ultra-large-scale software repository and
source-code mining,” ACM Transactions on Software Engineering and Methodology, vol. 25, no. 1, pp.
1–34, 2015.
[28] Z. Lan, M. Chen, S. Goodman, K. Gimpel, P. Sharma, and R. Soricut, “Albert: A lite bert for self-
supervised learning of language representations,” 2019.
[29] O. S. Ekundayo and A. E.-S. Ezugwu, “Deep learning: Historical overview from inception to actualization,
models, applications and future trends,” 2024.
[30] G. Giray, “A software engineering perspective on engineering machine learning systems: State of the art
and challenges,” Journal of Systems and Software, vol. 180, p. 111031, 2021.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
191
