Definiciones y tendencia de deuda técnica

Definiciones y tendencia de deuda técnica:
Un mapeo sistemático de la literatura
Alberto Villar, Santiago Matalonga
Universidad ORT Uruguay
Montevideo Uruguay
(avillar, smatalonga)@uni.ort.edu.uy
Abstract. Deuda técnica es una metáfora utilizada para explicar que cuando
una dimensión de la gestión de proyectos es priorizada a favor de otra, se
genera una deuda que tendrá que ser pagada en el futuro. Típicamente es la
dimensión calidad la que tiende a perder preferencia por sobre presiones de
recursos, fechas o funcionalidades. Consideramos que esto se da porque la
dimensión calidad es más difícil de medir cuantitativamente y por tanto los
gerentes de proyecto no tienen visibilidad de las decisiones que afectan esta
dimensión. La metáfora de deuda técnica pretende contribuir a esta visibilidad
en la gestión de proyectos.
Para entender la viabilidad del uso de la metáfora como herramienta para la
gestión de proyectos se realizó un mapeo sistemático de la literatura. El objetivo
de este trabajo es intentar responder cómo se define el concepto de deuda
técnica, cuáles son los referentes en el tema y qué nivel de actividad existe. Este
artículo presenta los resultados del mapeo sistemático de la literatura realizado.
Los principales hallazgos son que no existen definiciones consensuadas para la
metáfora de deuda técnica y que la mayoría de estas están orientadas a la
calidad de código sobre los procesos en general. La cantidad creciente de
artículos publicados muestra que es un tema de interés para la comunidad
científica.
Keywords: technical debt, design debt, systematic mapping studies.
1
Introducción
La metáfora de deuda técnica fue mencionada en primera instancia por Ward
Cunningham en el congreso de orientación a objetos OOPSLA en el año 1992[1].
Explica que la deuda técnica se genera por las actividades que los miembros del equipo
o el equipo optan por no hacerlas correctamente ahora y que impiden el desarrollo
futuro si no se resuelven. Asimismo, los intereses representan el costo que se paga día
a día por mantener la deuda y se suma al costo total de eliminarla. Desde entonces,
otros autores reconocidos la tomaron y realizaron sus propias definiciones basadas en
la metáfora original con agregados y/o diferencias según distintos puntos de vista. Por
ejemplo, Martin Fowler asocia la deuda técnica con la deuda financiera y agrega
formas de pago e intereses generados[2]. Chris Sterling suma el concepto de
degradación de los componentes la cual también es parte de la deuda técnica
generada[3]. Y Robert Martin hace una diferencia entre deuda técnica y malas
prácticas[4]. Según este autor deuda técnica se compone de decisiones que se realizan
en proyectos reales en forma consciente y, aunque riesgosas, pueden ser beneficiosas
para el mismo en un momento determinado del proyecto.
Todas estas definiciones se refieren mayoritariamente a deuda de diseño y
codificación. Chris Sterling realiza una agrupación más amplia y habla de deuda de
software. En ella describe 5 tipos de deuda: la técnica, de calidad, generada en el
manejo de la configuración, de diseño y de experiencia en la plataforma.
Más allá de las diferentes definiciones existe unanimidad de los autores
mencionados sobre la importancia del tema ya que no controlarla tiene necesariamente
consecuencias económicas negativas muy importantes sobre el proyecto hasta tal punto
que puede hacerlo fracasar. Debido a esta incidencia resulta imprescindible poder
gestionarla adecuadamente. Para poder realizar la gestión de la deuda técnica es
necesario contar con definiciones exactas así como medidas cuantitativas de los
componentes que la conforman en forma consensuada y estandarizada por parte de la
industria. La obtención de esta información ayudará a tener mayor visibilidad del
problema de la deuda técnica y poder gestionar la misma.
Este trabajo presenta los resultados de un mapeo sistemático realizado con el
objetivo de identificar el estado actual de las definiciones de deuda técnica y las
medidas utilizadas para gestionarla. Los resultados de este trabajo ayudaron a conocer
el nivel de definiciones existentes en el ámbito académico así como los autores que
están trabajando activamente en el tema.
Como síntesis de nuestras conclusiones, consideramos que analizar la deuda
técnica desde un punto de vista exclusivo de la calidad de código, como lo hace la
mayoría de las definiciones encontradas, no es suficiente. Se debe analizar la deuda
técnica desde una óptica más amplia. No solamente se genera en el código, un mal
diseño o una mala documentación, sino que es parte de la arquitectura de la solución,
de un proyecto o de toda la organización involucrando a todos los actores, no
solamente a los relacionados en la construcción del software. Algunos autores se
refieren a la deuda técnica generada a través de decisiones de la empresa, políticas y
oportunidades y que, como tal, debe ser atacada de una forma integral, por ejemplo,
administrada en un portfolio de proyectos a nivel de toda la organización[5].
Consideramos que esta forma de ver la deuda técnica desde un punto de vista más
holístico de la empresa es necesario y el involucramiento de los distintos actores
incluyendo los roles gerenciales y de toma de decisiones es imprescindible. El mapeo
realizado buscó evidencia de las distintas perspectivas del tema y realizó una
clasificación al respecto la que evidenció un crecimiento en los últimos años de
artículos orientados a una visión más general e integral del tema, aunque también se
siguen generando artículos orientados a las primeras definiciones orientadas
fuertemente a la calidad de código.
Por último, el mapeo sistemático también confirmó la importancia creciente del
tema evidenciado por la cantidad de artículos que se están generando en los últimos
años.
El artículo está organizado de la siguiente manera. La sección 2 describe el proceso
seguido para el mapeo sistemático, las preguntas de investigación, los criterios de
inclusión, exclusión y las clasificaciones realizadas. La sección 3 presenta los
resultados obtenidos del mismo. La sección 4 analiza las preguntas abiertas para
nuevas líneas de investigación. La sección 5 describe las posibles amenazas a la
validez encontradas en este mapeo. Finalmente la sección 6 detalla las conclusiones
alcanzadas.
2
MAPEO SISTEMÁTICO DE LA LITERATURA
En base a los lineamientos provistos en[6] y[7], los pasos seguidos para el mapeo
sistemático son:
1)
Definición de las preguntas de investigación (desarrollado en el apartado A
de esta sección).
2)
Búsqueda de la literatura relevante (desarrollado en el apartado B de esta
sección)
3)
Selección de los estudios pertinentes (desarrollado en el apartado B y C de
esta sección)
4)
Clasificación de los artículos (desarrollado en el apartado C de esta
sección)
5)
Extracción y agregación de los datos (desarrollado en la sección
Resultados obtenidos).
2.1
Preguntas de investigación
El objetivo principal de este mapeo sistemático es tener una visión del estado del
arte realizada en torno al tema de deuda técnica para obtener información de
actividades y evolución del tema.
Para este estudio, las preguntas que se buscan responder son las siguientes:
P1. ¿Cuáles son las definiciones encontradas de deuda técnica y deuda de diseño?
P2. ¿Qué actividad de investigación ha habido a lo largo del tiempo?
P3. ¿Cuál es la evolución de los temas a lo largo del tiempo?
P4. ¿Cuáles son los principales investigadores en el tema?
2.2
Selección de los motores de búsquedas y artículos pertinentes
Para las búsquedas se utilizaron las siguientes bases de datos bibliográficas: ACM,
Springer, IEEE Explore, SciVerse y CiteSeerx. La selección de los motores de
búsqueda se vio limitada por la disponibilidad de los mismos en el Portal Timbo1 y la
biblioteca de la Universidad ORT Uruguay con el agregado de Citeseerx ya que es un
motor de búsqueda de acceso libre.
Para la construcción de las cadenas de búsquedas se utilizaron las palabras claves:
“technical debt”. En las primeras lecturas de los artículos seleccionados, en muchos de
ellos, aparecieron referencias de deuda de diseño por lo que se agregó a la búsqueda las
palabras “design debt” y así obtener un alcance más amplio de las mismas. Como
consecuencia también se agregaron a la pregunta de investigación las definiciones
encontradas para estos términos. (Pregunta P1). El filtro inicial fue el menos restrictivo
posible y el filtro de exclusión es más intensivo (ver apartado C de esta sección). Con
este formato se redujo el riesgo de eliminar artículos útiles. La tabla 1 presenta los
resultados crudos de las búsquedas y las fechas en que se ejecutaron las mismas.
Tabla1.Resultados de las búsquedas
Identificador
Cant.
(SR)***
TD+DD
14/06/2012
70
ACM
TD+DD
27/05/2012
31
Springer
TD+DD
27/05/2012
100
IEEE
TD
28/05/2012
18
SciVerse TD
DD
27/05/2012
6
SciVerse DD
TD
13/06/2012
17
Citeseerx TD
DD
28/05/2012
43
Citeseerx DD
TOTAL
285
*Se utilizó el string de búsqueda “tecnical debt” “design debt” o ambos
** Fecha de ejecución de las búsquedas en los distintos motores
***Cantidad de artículos excluyendo los repetidos
2.3
TD/DD*
Fecha**
Cantidad
Artículos
71
31
100
18
8
17
47
Selección de los artículos pertinentes
Se definieron los siguientes criterios de inclusión:
 todos los artículos, libros y reportes indexados en los motores de búsqueda
utilizados que definan y/o nombren “technical debt” o “design debt” en
cualquier parte del documento o metadata (título, abstract, cuerpo).
 No existe límite de fecha de publicación.
Los criterios de exclusión son los siguientes:
 No es del tema software (D_NET).
 Es un artículo que podría ser clasificado (analizando el abstract si tiene)
pero no es posible accederlo (NA).
 No hay datos, no se puede leer el documento ni hay abstract (D_NHD).
 No existe el documento, tiene entrada en el buscador pero el link es
inválido (NED).
 Descartado por lectura del abstract (D_PA).
1www.timbo.org.uy
Portal uruguayo de búsqueda.



Descartado por lectura del cuerpo del artículo (D_PL).
Descartado porque es un índice, una tabla de contenido, son notas de
publicación o presentaciones de simposios (D_ITOC).
Repetido (REP).
La tabla 2 muestra los resultados de los artículos excluidos.
D_ITOC
0
0
5
0
3
8
9
0
12
8
2
31
Total
2
0
1
0
5
8
REP
27
8
3
7
3
48
D_PL
0
4
2
0
36
42
D_PA
D_NET
ACM
Springer
IEEE
SciVerse
Citeseerx
Total
NA
Motor de
búsqueda
Tabla2.Resultados excluidos por motor de búsquedas
20
1
1
1
4
27
58
13
24
16
53
164
Luego de aplicar los criterios de exclusión mencionados, de un total de 285
artículos accedidos por las búsquedas se seleccionaron 121 artículos que contienen las
palabras claves, su texto es accesible y pertenecen al tema.
3
Resultados obtenidos
Este apartado presenta los resultados obtenidos de clasificar los artículos para dar
respuesta a las preguntas de investigación. Para cada pregunta se realizó una
clasificación que se muestra con su correspondiente tabla, exceptuando las definiciones
que por ser descriptivas se listan.
P1. ¿Cuáles son las definiciones encontradas de deuda técnica y deuda de diseño?
A continuación se detallan todas las definiciones encontradas sin exclusión para
poder obtener conclusiones al respecto. En caso de que fueran referencias, si la
definición está escrita en el artículo se tomó en cuenta, tal es el caso de las dos
definiciones de deuda de diseño. El orden que se muestran es el ascendente por año de
publicación.
TDD_1: Es de esperar que una falta de foco en la arquitectura fuerce el punto ideal
hacia lo cierto: el esfuerzo necesario para refactorizar el código para posibilitar el
desarrollo del siguiente sistema. Este efecto es también conocido como deuda
técnica[8].
TDD_2: La deuda técnica se refiere a los costos del envejecimiento del software
que no son atendidos, los cuales por consiguiente, necesitan ser reparados en una fase
posterior. Parnas asevera que "nuestra experiencia con el envejecimiento del software
nos dice que debemos ver más allá de la primera versión hasta el momento en que el
producto es viejo", indicando que hay una necesidad de considerar aspectos a largo
plazo[9].
TDD_3: Deuda técnica es el crédito que el equipo de desarrollo asume por atajos
tomados durante los ciclos de desarrollo previos. Dichos atajos consisten en poca
revisión de código, unidades de testeo no automáticas, carencia de calidad en el testing
y la pobre implementación[10].
TDD_4: El entorno de desarrollo, la base de datos, el control del código y el
manejo de dependencias en instalación de un proyecto no conocido pueden ser
extremadamente complicados. Esto es esencialmente "Deuda técnica", que también
aparece en Scrum normal, pero es mucho más aparente en Scrum de empresas cuando
los equipos se mueven entre diferentes productos[11].
TDD_5: Deuda técnica es algo en lo que no podemos improvisar, específicamente
en el código fuente. Por ejemplo, un módulo existente puede ser refactorizado para
ganar mejor cobertura de testeo o para limpiar código innecesario[12].
TDD_6: Deuda técnica es una metáfora para los inmaduros, incompletos o
inadecuados artefactos en el ciclo de vida del desarrollo de software, que pueden
causar altísimos costos y baja calidad en el largo plazo, dicen los autores
de “Measuring and Monitoring Technical Debt”, Carolyn Seaman y Yuepu Guo[13].
TDD_7: Los proyectos de mantenimiento de software son a menudo ajustados por
el presupuesto, fechas y recursos. Para hacer frente a esos ajustes, se hacen
compensaciones durante todo el ciclo de desarrollo del software. Cuando esas
compensaciones permiten a los equipos del proyecto hacer frente a las expectativas de
la dirección y del cliente en el corto plazo, el compromiso resulta en costo adicional
posterior en el proceso de mantenimiento. Este fenómeno es conocido como "deuda
técnica"[14].
TDD_8: Deuda técnica es una metáfora que describe las concesiones entre las
actividades de desarrollo técnico que son demoradas para conseguir el pago de
compensaciones en el corto plazo, como ser una versión del software a tiempo. El
término "deuda" es usado para describir como esas actividades pueden ser saldadas en
el corto plazo. Como entrar en una deuda financiera para comprar un nuevo auto,
aunque igual la paguemos más tarde. Si se acumula demasiada deuda técnica en el
proyecto de software, se retrasará el desarrollo, por ejemplo, por incrementar el pobre
mantenimiento del código[15].
TDD_9: Deuda técnica es una metáfora usada para describir la práctica de
sacrificar las metas a largo plazo a cambio de un [barato y rápido] logro de metas a
corto plazo[16].
TDD_10: Deuda técnica es una metáfora que describe situaciones en las cuales los
desarrolladores aceptan sacrificios en una dimensión del desarrollo (por ejemplo,
calidad de software) para optimizar otra dimensión (por ejemplo, características de
implementación necesarias antes del tiempo límite)[16].
TDD_11: Deuda técnica es una metáfora que ha ganado popularidad en la
comunidad del desarrollo ágil para describir la brecha entre el estado actual del sistema
y el estado ideal del mismo, usualmente en situaciones en donde un compromiso es
hecho durante el desarrollo para satisfacer demandas en una dimensión, como el
tiempo de entrega, sacrificando trabajo en otra dimensión, como la arquitectura[17].
En el caso de las definiciones de deuda de diseño se encontraron solamente dos
definiciones que se detallan a continuación:
DDD_1: Evitar la tentación de parar el trabajo y refactorizar por varias semanas.
Aun el equipo más disciplinado inadvertidamente asume deuda de diseño, por lo tanto
eliminar la deuda es una actividad continua. Tenga su equipo acostumbrado a
refactorizar como parte de su trabajo diario. En este caso son dos artículos los que
referencian esta definición[18][19].
DDD_2: Además, el costo se incrementa largamente en las deficiencias
tecnológicas no corregidas, hasta que el código se transforma en inmanejable y
esencialmente debe ser completamente reescrito. Este creciente problema es llamado
deuda de diseño[20].
P2. ¿Qué actividad de investigación ha habido a lo largo del tiempo?
De la agrupación de los artículos seleccionados por año puede observarse una
tendencia ascendente en cantidades absolutas de publicaciones sobre el tema. En la
figura 1 se ve esta tendencia ascendente a través de los años.
50
40
30
20
10
0
Fig. 1. Gráfica de resultados agrupados por año de publicación. *Año 2012 representado hasta las
fechas de búsquedas (ver tabla 1)
P3. ¿Cuál es la evolución del concepto a lo largo del tiempo?
Para responder a esta pregunta, además de la agrupación de los artículos por año de
publicación, se categorizaron en 4 grupos. Las agrupaciones son:
N_NOM: Son los artículos que solo nombran el término de deuda técnica y que en
su contexto no se pueden clasificar de otra forma. Estos artículos realmente están
relacionados con el tema y podrían aplicar tanto a N_TD_C como N_TD_A no así para
N_TD_I.
N_TD_C: Los artículos clasificados bajo esta agrupación son los que referencian
solamente al tema del código. Utilizan el término para referirse a la deuda generada por
código mal construido por no seguir buenas prácticas, la no aplicación de patrones, el
bajo nivel de testing del mismo y la poca experiencia del desarrollador, es decir, la baja
calidad del código generado.
N_TD_A: Esta clasificación incluye la anterior y además agrega factores de pobre
arquitectura, infraestructura mal dimensionada, requerimientos mal detallados,
documentación desactualizada y valor del negocio solo desde el punto de vista del
costo de pagar la deuda técnica. En este caso se ve un alcance más amplio del concepto
integrando más actores.
N_TD_I: Esta clasificación incluye la anterior y además agrega otros stakeholders
(jefes de proyecto, todas las demás áreas de la empresa, directorio, PMO) al problema
de la deuda técnica. Los generadores de deuda técnica no son solamente los integrantes
del grupo técnico (arquitectos, diseñadores, implementadores, testers, etc.) sino que
también se da por otras necesidades de la organización como son oportunidades de
negocio y ventanas de tiempo. Por la forma de la deuda y cómo influye en la
organización se debe tratar su pago, generación y pago de intereses como un elemento
más del portfolio de proyectos y actividades de la organización, además de la
necesidad de involucrar a toda la organización en el tratamiento del problema.
La tabla 3 muestra las cantidades de artículos encontrados para cada una de las
clasificaciones.
Estas categorizaciones son ordenables desde el punto de vista del alcance del uso
del término. Alcance se refiere a las etapas y/o actividades que comprende el concepto.
En este caso van desde un alcance centrado solamente en la codificación hasta uno que
cubre todas las etapas, actividades y roles involucrados en un proyecto de software.
2000
2004
2005
2006
2007
2008
2009
2010
2011
2012*
TOTAL
2
1
2
2
1
8
1
4
3
2
8
8
14
12
23
5
80
1
2
1
4
8
1
17
2
3
8
3
16
TOTAL
N_TD_I
N_TD_A
N_TD_C
Año
N_NOM
Tabla3.Resultados agrupados por criterios
1
4
4
2
8
14
16
21
41
10
121
P4. ¿Cuáles son los principales investigadores en el tema?
Se seleccionaron los autores con más de 2 publicaciones realizadas.
Algunas de las publicaciones son capítulos de libros y se contaron como
publicaciones independientes. La tabla 4 muestra los resultados obtenidos. Aunque se
contabilizaron los capítulos de un mismo libro como publicaciones independientes se
marcó con asteriscos esta situación.
Tabla4.Autores con mayor actividad de publicaciones
Autores
Kruchten, Philippe
Seaman, Carolyn
Gee, Joseph
Holtsnider, Bill
Martin, Angela
Shull, Forrest
Stragand, George
Sutherland, Jeff
Wheeler, Tom
Blankenship, Jerrel
Guo, Yuepu
Millett, Scott
Brown, Nanette
Murphy-hill, Emerson
Ozkaya, Ipek
Wall, Anders
Zazworka, Nico
Cantidad
6
6
5*
5*
5
5
5*
5
5*
4*
4
4*
3
3
3
3
3
* Son capítulos de libros expuestos en los motores de búsquedas como artículos, por lo que se
contabilizaron como tales.
Por lo mostrado en la tabla 4 solamente el 10% de los autores publicaron más de 2
artículos. Este dato se puede interpretar como que la mayoría de los autores que
publicaron artículos de deuda técnica no es su tema principal de investigación. Por el
tipo de tema este dato es esperable ya que es un concepto amplio que impacta en varios
aspectos (como se explicó anteriormente) y por consiguiente es normal que aparezca
en artículos de software relacionados indirectamente. Cabe recordar que la inclusión
del artículo en el mapeo alcanzó solamente con nombrar el tema. Esto hace que exista
un conjunto grande de los mismos que nombra el tema para soportar solamente una
sección del mismo.
4
Trabajos futuros
Como se mencionó en la sección II, el objetivo de un mapeo sistemático de la
literatura es identificar los actores clave y abrir líneas de investigación en el tema. En
esta sección se analizan algunas de las preguntas abiertas que pueden conducir a
nuevas líneas de investigación.
4.1
¿Qué medidas se pueden utilizar para medir la deuda técnica desde los
distintos aspectos y etapas del proceso de software?
Las definiciones encontradas apuntan a que no hay una definición aceptada, sino
que hay diferentes definiciones que tienen distintos matices de orientación. La mayoría
de las mismas se orientan a la deuda generada en el código. En este aspecto existen
varias medidas de calidad de código que son universalmente aceptadas.
Como ya se comentó, otros trabajos analizan la deuda técnica desde un punto de
vista más amplio que incluyen documentación, requisitos, decisiones de arquitectura,
etc. Sobre tales artículos se investigó qué clase de medidas de calidad aparecían y qué
valores tomaban. Cabe aclarar que no se agregó a las preguntas a responder por el
mapeo sistemático la búsqueda de medidas ya que se analizaron únicamente un
subconjunto de los artículos seleccionados, exactamente los agrupados en N_TD_A y
N_TD_I. En este caso se observa que las medidas definidas no están consensuadas, es
decir, no existe un conjunto de medidas aceptadas por la comunidad y además son
medidas de calidad que no están cuantificadas, en particular en costos económicos.
Estas características dificultan el cálculo de deuda técnica.
Desde este punto de vista creemos que es importante tener definido un conjunto de
medidas universalmente aceptadas que cubra la totalidad de los factores generadores de
deuda técnica que sirvan de referencia para el cálculo de la misma. Este enfoque
aseguraría un cálculo más exacto de la deuda ya que se estarían incluyendo todos los
factores y además se obtendría un marco de referencia que, con adecuaciones, pueda
ser aplicado a distintos entornos. Además la estandarización de este conjunto de
medidas hace posible obtener estadísticas tanto dentro de la propia empresa como en
toda la industria por lo que se alcanza una ventaja de reducción de costos y esfuerzo en
el cálculo de la deuda técnica que, por la cantidad de variables en juego, no es un valor
despreciable.
4.2
¿Se puede utilizar el concepto de deuda técnica en etapas tempranas de un
proyecto de software para la toma de decisiones?
Los artículos analizados ven la deuda técnica como un elemento a ser eliminado.
Desde este punto de vista existen propuestas de cuándo y cómo pagarla luego de
generada la misma[21]. Algunos artículos tratan la deuda como un costo a ser
enfrentado por la empresa y por consiguiente manejado desde un punto de vista global
[22] y por lo tanto compite en recursos con otros proyectos[23]. Sin embargo no
encontramos evidencia que analice la deuda no generada aún y que esta definición sea
analizada en el contexto de todo el proyecto de desarrollo. Desde este punto de vista no
existen métricas que provean una visión holística del tema y que a partir de ella se
pueda inferir cuál es el nivel de deuda técnica aceptable que se pueda incurrir en un
proyecto, en qué etapa del mismo y en qué momento se debería pagar.
4.3
¿Existe evidencia de experimentación en deuda técnica?
El mapeo sistemático realizado no consideró en sus criterios la búsqueda de
evidencia de experimentación en deuda técnica. Existen casos de estudio asociados a la
calidad de código[24], calidad de diseño[25], costo en el mantenimiento[26] y
mediciones de esfuerzo en arquitectura como un componente de calidad en los
proyectos[8]. Todos estos factores aplican sobre algunas de las medidas que conforman
la deuda técnica. Tales casos de estudio no están directamente asociados al concepto de
deuda técnica por lo que las búsquedas deberán orientarse sobre cada una de las
medidas que la componen. En este sentido el mapeo podría ser inalcanzable en una
primera aproximación. Quizás una forma de atacar este problema es realizar mapeos
independientes para cada uno de los componentes de la deuda técnica definidos.
5
Amenazas a la validez
Al igual que la mayoría de los estudios empíricos, el estudio del mapeo sistemático
se ve amenazado por la forma en que la investigación se lleva a cabo. Por lo general, la
motivación para llevar a cabo estudios sistemáticos es que otros investigadores puedan
reproducir los resultados obtenidos por el investigador inicial. En este trabajo se
visualizan cuatro amenazas a la validez.
En primer lugar, el alcance del mapeo se acotó a 5 motores de búsqueda, cuatro de
ellos accedidos desde Portal Timbo y un quinto de acceso libre (Citeseerx). Estos
motores indexan en sus bases de datos artículos de ciertas características, como ser
journals, procedings y capítulos de libros presentados como artículos independientes.
Esta selección deja fuera toda la bibliografía gris como son sitios web de autores, blogs
de discusión, etc. Al ser un tema relativamente nuevo en algunos conceptos podemos
estar excluyendo artículos, notas y discusiones que estén más avanzados en el tema y
que modifiquen nuestros resultados. Por ejemplo, pueden existir autores que están
trabajando fuertemente en deuda técnica que en este trabajo no aparezcan, o tengan
otras definiciones que no aparezcan en los artículos obtenidos.
En segundo lugar, el acceso a los motores de búsqueda se limitó a la capacidad de
acceso de los investigadores. Pueden existir otros motores que no se pudieron acceder.
En este caso creemos que la amenaza es baja ya que se utilizaron los motores más
significativos en el área de software. A su vez no se pudo tener acceso al texto
completo de todos los artículos por lo que algunos de ellos se clasificaron solamente
por abstract. En este caso pudo perderse alguna definición y los valores de agrupación
pueden ser diferentes, aunque por la cantidad no accesible del total consideramos que
no cambia la tendencia de los mismos.
En tercer lugar, los criterios de agrupación de los artículos son criterios que en su
definición contienen al anterior, es decir, un criterio de agrupación contiene las
características del criterio anterior y agrega nuevas características. Por ejemplo,
N_TD_A incluye las características de N_TD_C más las características de pobre
arquitectura, etc. Al no ser ortogonales las clasificaciones seleccionadas se puede
incurrir en errores en la clasificación de artículos donde las características buscadas no
se encuentren claramente identificadas. Un caso particular es la separación entre
arquitectura de bajo nivel y el diseño de alto nivel. En este caso la distancia es corta y
define características de distintos grupos.
Por último siempre existe el error de interpretación del investigador en la cual
algunos artículos podrían ser clasificados de distinta manera por otros investigadores.
6
Conclusiones
Este artículo presentó los resultados del mapeo sistemático de la literatura con el
objetivo de evaluar la literatura disponible sobre el tema de deuda técnica para analizar
la importancia y vigencia del mismo en ámbitos de investigación. Las preguntas
planteadas apuntaron hacia tal objetivo.
Los resultados obtenidos en las definiciones encontradas de deuda técnica y deuda
de diseño muestran que ambas siguen siendo orientadas fuertemente a deuda de código
y, con diferencia de matices, siguen siendo similares a la primera definición de
Cunningham. No se encontró una definición consensuada del término, sino que cada
autor ha ampliado o modificado la misma para cubrir su visión. Tampoco se
encontraron definiciones que amplíen el concepto desde el punto de vista general de la
organización más adecuadas a las características de la clasificación de tipo N_TD_I.
El aumento de las publicaciones sobre el tema muestra interés por parte de la
comunidad científica. El crecimiento es general para todas las clasificaciones aunque
se muestra un crecimiento más marcado en los orientados a una visión más integral
(los clasificados como N_TD_A y N_TD_I) principalmente en los últimos 4 años.
Este es un indicador esperado ya que las tendencias a atacar la deuda técnica desde
estos puntos de vista son nuevas mientras que las definiciones de deuda técnica
orientadas a código existen desde las primeras definiciones.
Como trabajo futuro, pretendemos orientar la investigación a la obtención de
medidas de deuda técnica a lo largo del proyecto así como el uso del concepto para la
toma de decisiones podría mejorar el entendimiento del tema y aportar en información
que ayude a las organizaciones a controlar el problema de la deuda técnica.
Referencias
[1]
W. Cunningham, “The wycash portfolio management system,” in OOPSLA
’92: Addendum to the proceedings on Object-oriented programming systems,
languages, and applications (Addendum), 1992, pp. 29–30.
[2]
M. Fowler, “Technical debt,” 2009. [Online]. Available:
http://martinfowler.com/bliki/TechnicalDebt.html.
[3]
C. Sterling, Managing Software Debt, 1st ed. Westford,Massachusetts:
Addison Wesley, 2010.
[4]
M. R, “A mess is not a Technical Debt,” 2009. [Online]. Available:
http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technicaldebt.
[5]
T. Klinger, P. Tarr, P. Wagstrom, and C. Williams, “An enterprise perspective
on technical debt,” in Proceeding of the 2nd working on Managing technical
debt - MTD ’11, 2011, p. 35.
[6]
K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson, “Systematic mapping
studies in software engineering,” pp. 68–77, Jun. 2008.
[7]
H. Arksey and L. O Malley, “Scoping studies: towards a methodological
framework,” International Journal of Social Research Methodology, vol. 8,
no. 1, pp. 19–32, 2005.
[8]
E. Rommes, A. Postma, and P. America, “Measuring Architecting Effort,” in
5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05),
2005, pp. 229–230.
[9]
M. Lindgren, R. Land, C. Norstrom, and A. Wall, “Key Aspects of Software
Release Planning in Industry,” in 19th Australian Conference on Software
Engineering (aswec 2008), 2008, pp. 320–329.
[10]
J. Thomas, “Introducing Agile Development Practices from the Middle,” in
15th Annual IEEE International Conference and Workshop on the
Engineering of Computer Based Systems (ecbs 2008), 2008, pp. 401–407.
[11]
D. R. Greening, “Enterprise Scrum: Scaling Scrum to the Executive Level,”
in 2010 43rd Hawaii International Conference on System Sciences, 2010, pp.
1–10.
[12]
J. Blankenship, M. Bussa, and S. Millett, Pro Agile .NET Development with
Scrum. Berkeley, CA: Apress, 2011, pp. 84–129.
[13]
C. Seaman and Y. Guo, Chapter 2 – Measuring and Monitoring Technical
Debt, vol. 82. Elsevier, 2011, p. Pages 25–46.
[14]
Y. Guo, C. Seaman, R. Gomes, A. Cavalcanti, G. Tonin, F. Q. B. Da Silva, A.
L. M. Santos, and C. Siebra, “Tracking technical debt — An exploratory case
study,” in 2011 27th IEEE International Conference on Software
Maintenance (ICSM), 2011, pp. 528–531.
[15]
N. Zazworka, C. Seaman, and F. Shull, “Prioritizing design debt investment
opportunities,” in Proceeding of the 2nd working on Managing technical debt
- MTD ’11, 2011, p. 39.
[16]
M. Smit, B. Gergel, H. J. Hoover, and E. Stroulia, “Code convention
adherence in evolving software,” in 2011 27th IEEE International Conference
on Software Maintenance (ICSM), 2011, pp. 504–507.
[17]
K. Wiklund, S. Eldh, D. Sundmark, and K. Lundqvist, “Technical Debt in
Test Automation,” in 2012 IEEE Fifth International Conference on Software
Testing, Verification and Validation, 2012, pp. 887–892.
[18]
E. Murphy-hill and A. P. Black, “Refactoring tools: Fitness for purpose,”
IEEE SOFTWARE, 2008.
[19]
E. Murphy-hill and X. Codeguide, “– Only 2 used Refactoring Tools.”
Portland State University, p. 36, 2007.
[20]
J. Heidenberg and I. Porres, “Metrics Functions for Kanban Guards,” in 2010
17th IEEE International Conference and Workshops on Engineering of
Computer Based Systems, 2010, pp. 306–310.
[21]
F. Buschmann, “To Pay or Not to Pay Technical Debt,” IEEE Software, vol.
28, no. 6, pp. 29–31, Nov. 2011.
[22]
T. Theodoropoulos, M. Hofberg, and D. Kern, “Technical debt from the
stakeholder perspective,” in Proceeding of the 2nd working on Managing
technical debt - MTD ’11, 2011, p. 43.
[23]
Y. Guo and C. Seaman, “A portfolio approach to technical debt
management,” in Proceeding of the 2nd working on Managing technical debt
- MTD ’11, 2011, p. 31.
[24]
B. Curtis, J. Sappidi, and J. Subramanyam, “Measuring the Structural Quality
of Business Applications,” in 2011 AGILE Conference, 2011, pp. 147–150.
[25]
N. Brown, I. Ozkaya, R. Sangwan, C. Seaman, K. Sullivan, N. Zazworka, Y.
Cai, Y. Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, and
R. Nord, “Managing technical debt in software-reliant systems,” in
Proceedings of the FSE/SDP workshop on Future of software engineering
research - FoSER ’10, 2010, p. 47.
[26]
A. Nugroho, J. Visser, and T. Kuipers, “An empirical model of technical debt
and interest,” in Proceeding of the 2nd working on Managing technical debt MTD ’11, 2011, p. 1.