Definiciones y tendencia de deuda técnica:

Transcripción

1 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,

2 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.

3 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

4 búsqueda se vio limitada por la disponibilidad de los mismos en el Portal Timbo 1 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 TD/DD* Fecha** Cantidad Artículos Cant. (SR)*** ACM TD+DD 14/06/ Springer TD+DD 27/05/ IEEE TD+DD 27/05/ SciVerse TD TD 28/05/ SciVerse DD DD 27/05/ Citeseerx TD TD 13/06/ Citeseerx DD DD 28/05/ 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 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). 1 Portal uruguayo de búsqueda.

5 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. Tabla2.Resultados excluidos por motor de búsquedas Motor de búsqueda D_NET NA D_PA D_PL D_ITOC REP Total ACM Springer IEEE SciVerse Citeseerx Total 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].

6 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

7 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 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

8 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. Tabla3.Resultados agrupados por criterios Año N_NOM N_TD_C N_TD_A N_TD_I TOTAL * TOTAL

9 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 Cantidad Kruchten, Philippe 6 Seaman, Carolyn 6 Gee, Joseph 5* Holtsnider, Bill 5* Martin, Angela 5 Shull, Forrest 5 Stragand, George 5* Sutherland, Jeff 5 Wheeler, Tom 5* Blankenship, Jerrel 4* Guo, Yuepu 4 Millett, Scott 4* Brown, Nanette 3 Murphy-hill, Emerson 3 Ozkaya, Ipek 3 Wall, Anders 3 Zazworka, Nico 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

10 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.

11 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

12 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 [2] M. Fowler, Technical debt, [Online]. Available: [3] C. Sterling, Managing Software Debt, 1st ed. Westford,Massachusetts: Addison Wesley, 2010.

13 [4] M. R, A mess is not a Technical Debt, [Online]. Available: [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 , Jun [7] H. Arksey and L. O Malley, Scoping studies: towards a methodological framework, International Journal of Social Research Methodology, vol. 8, no. 1, pp , [8] E. Rommes, A. Postma, and P. America, Measuring Architecting Effort, in 5th Working IEEE/IFIP Conference on Software Architecture (WICSA 05), 2005, pp [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 [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 [11] D. R. Greening, Enterprise Scrum: Scaling Scrum to the Executive Level, in rd Hawaii International Conference on System Sciences, 2010, pp [12] J. Blankenship, M. Bussa, and S. Millett, Pro Agile.NET Development with Scrum. Berkeley, CA: Apress, 2011, pp [13] C. Seaman and Y. Guo, Chapter 2 Measuring and Monitoring Technical Debt, vol. 82. Elsevier, 2011, p. Pages [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 th IEEE International Conference on Software Maintenance (ICSM), 2011, pp [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.

14 [16] M. Smit, B. Gergel, H. J. Hoover, and E. Stroulia, Code convention adherence in evolving software, in th IEEE International Conference on Software Maintenance (ICSM), 2011, pp [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 [18] E. Murphy-hill and A. P. Black, Refactoring tools: Fitness for purpose, IEEE SOFTWARE, [19] E. Murphy-hill and X. Codeguide, Only 2 used Refactoring Tools. Portland State University, p. 36, [20] J. Heidenberg and I. Porres, Metrics Functions for Kanban Guards, in th IEEE International Conference and Workshops on Engineering of Computer Based Systems, 2010, pp [21] F. Buschmann, To Pay or Not to Pay Technical Debt, IEEE Software, vol. 28, no. 6, pp , Nov [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 [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.