Perspectiva de Deuda Tecnica

1. 1er Taller Internacional sobre Análisis Técnico de Deuda (TDA 2016)
Perspectivas sobre la gestión de la deuda técnica
Un punto de transición y una hoja de ruta desde Dagstuhl
Clemente Izurieta1, Ipek Özkaya2, Carolyn Seaman3, Philippe Kruchten4, Robert Nord2, Will Snipes5, París Avgeriou6
1clemente. izurieta@montana.edu , Universidad Estatal de Montana, Bozeman, MT, EE. UU.
2{ozkaya, rn}@sei.cmu.edu, Instituto de Ingeniería de Software, Universidad Carnegie Mellon, Pittsburgh, PA, EE. UU.
3cseaman@umbc.edu , Universidad de Maryland Condado de Baltimore, Maryland, MD, EE. UU.
4pbk@ece.ubc.ca , Universidad de Columbia Británica, BC, Canadá
5will.snipes@us.abb.com , ABB Corporate Research, Raleigh, Carolina del Norte, EE. UU.
6paris@cs.rug.nl , Universidad de Groningen, Groningen, Países Bajos
Abstracto—Treinta y tres profesionales, investigadores, estudiantes y
proveedores de herramientas se reunieron en Dagstuhl, Alemania, durante
cinco días en abril de 2016 para discutir el estado de la gestión de la deuda
técnica en la ingeniería de software. Los participantes reflexionaron sobre los
importantes avances que ha logrado la comunidad de Gestión de la Deuda
Técnica (MTD) desde su creación en 2010; llegó a un consenso sobre una
definición, denominada definición de deuda técnica Dagstuhl 16K; y
discutieron vías para el progreso futuro en el área. Este artículo proporciona
una breve historia, resume la investigación actual y ofrece una hoja de ruta y
una visión que describe las áreas de investigación donde aún persisten
desafíos importantes.
la periferia de la definición. Ejemplos de esto último incluyen la deuda
social, de documentación, de procesos y de infraestructura. Por lo
tanto, presentamos un modelo conceptual que permite la extensión y
representación contextual de varios artefactos.
II. BANTECEDENTES
La comunidad de Gestión de la Deuda Técnica (MTD) existe
formalmente desde 2010. La Figura 1 muestra la cronología de eventos
anteriores e ilustra nuevas reuniones que representan un mayor nivel
de actividad. El resultado de estos esfuerzos ha sido más de 200
artículos de investigación escritos por grupos de investigación de todo
el mundo, estudios bibliográficos sistemáticos que organizan el espacio
y demuestran lagunas, y números especiales en revistas profesionales y
de investigación comoSoftware IEEEy elRevista de sistemas y software.
Posiblemente el resultado más bienvenido y desafiante haya sido una
participación cada vez mayor de la comunidad de profesionales. Como
resultado, muchos proveedores de herramientas han comenzado a
agregar o reutilizar funciones para respaldar el análisis técnico de la
deuda. Muchas organizaciones también están estudiando la posibilidad
de desarrollar sus propias mejores prácticas internas para gestionar la
deuda técnica y necesitan ayuda.
Palabras clave—deuda técnica; calidad del software; deterioro del software;
economía del software; gestión de proyectos de software
yo yoNTRODUCCIÓN
Si bien otras disciplinas de la ingeniería de software (como la
sostenibilidad, el mantenimiento y la evolución del software, la
refactorización, la calidad del software y la ingeniería de software
empírica) han producido resultados relevantes para la gestión de la
deuda técnica, ninguna de ellas por sí sola es suficiente para
modelar, gestionar y comunicar las diferentes facetas de la deuda
técnica. los problemas de compensación de diseño involucrados en
la gestión de la deuda técnica. Aunque la metáfora de la deuda
técnica puede atribuirse a Cunningham [1], un consenso
comunitario sobre una definición concisa y enfocada ha sido una
barrera para el progreso de la investigación que podría abordar las
necesidades inmediatas más apremiantes de la comunidad de
ingeniería de software. La metáfora de la deuda técnica describe
una situación en la que los desarrolladores aceptan compromisos
de calidad en la versión actual para cumplir con una fecha límite
(por ejemplo, entregar una versión a tiempo).
El Cuadro 1 ilustra los temas en los que se ha centrado la
investigación técnica de la deuda desde 2006. Vemos claramente una
clara distinción entre los artefactos que son más fáciles de medir, como
el código, y los que no lo son, como las personas. También muestra qué
temas han recibido más y menos investigación.
III. tÉLDAGSTUHLFORMATO
Dagstuhl reunió a investigadores, profesionales,
estudiantes y proveedores de herramientas del mundo
académico y de la industria interesados en los fundamentos
teóricos de la deuda técnica y cómo gestionarla (por ejemplo,
técnicas de medición, análisis y prevención). Los organizadores
crearon un blog donde los asistentes publicaron posiciones e
iniciaron debates para facilitar la siembra de ideas antes del
seminario. Los organizadores agruparon debates y entradas de
blogs en temas relevantes que incluyeron la creación de una
definición común y un modelo conceptual de deuda técnica,
medición y análisis de la deuda técnica, gestión de la deuda
técnica y una hoja de ruta de investigación para la gestión de la
deuda técnica. No se presentaron charlas largas. Cada día
contó con tres tipos de sesiones. Hubo una sesión plenaria
para “charlas relámpago,
Hasta la fecha, la metáfora de la deuda técnica ha servido como un
fuerte mecanismo de comunicación y referencia, pero la comunidad
ahora entiende que la deuda técnica también es un artefacto de
desarrollo de software en el que se incurre (en su mayoría) sin
intención y se descubre durante etapas posteriores del desarrollo de
software. Además, la comunidad también reconoce que los principales
desafíos de investigación que se avecinan no pueden abordarse
simplemente reutilizando el análisis de calidad y mantenibilidad del
código como análisis técnico de la deuda. La definición de deuda
técnica del Seminario Dagstuhl 16162 (Dagstuhl 16K) se centra en los
artefactos de diseño e implementación que afectan la mantenibilidad y
la capacidad de evolución del software. Esta definición también impulsó
a la comunidad a abordar el problema de clasificar los artefactos en
84
Traducido del inglés al español - www.onlinedoctranslator.com

2. 1er Taller Internacional sobre Análisis Técnico de Deuda (TDA 2016)
IV. tEQUIPODEBT “En los sistemas intensivos en software, la deuda técnica es un conjunto
de estructuras de diseño o implementación que son convenientes en el corto
plazo, pero que establecen un contexto técnico que puede hacer que los
cambios futuros sean más costosos o imposibles. La deuda técnica presenta
un pasivo real o contingente cuyo impacto se limita a las cualidades internas
del sistema, principalmente la mantenibilidad y la evolución”.
Los resultados importantes del seminario incluyen una definición,
un modelo conceptual y una lista de desafíos que enfrentamos en el
avance de la agenda de investigación y las perspectivas de transición
para la gestión de la deuda técnica. La definición y el modelo sirven
como puntos de partida para que la comunidad construya y mejore.
La definición de Dagstuhl 16K presenta una expansión con respecto
a definiciones anteriores al tener en cuenta las preocupaciones
escuchadas en eventos técnicos de deuda anteriores y el pensamiento
que ha ocurrido a lo largo de los años. Específicamente, esta definición
eleva los conceptos de evolucionabilidad y mantenibilidad como focos
principales de la investigación técnica de la deuda, combina conceptos
de diseño e implementación y resalta las compensaciones específicas
del contexto que deben realizarse de manera conveniente.
B. Modelo Conceptual y Actividades Relacionadas de Deuda
Técnica
Otro resultado del seminario fue el reconocimiento de que, al igual
que otros artefactos complejos de ingeniería de software, la deuda
técnica se describe mejor a través de múltiples puntos de vista. Los
conceptos relacionados con la deuda técnica deben discutirse desde
dos puntos de vista relacionados:
a) el punto de vista que describe las propiedades, artefactos y elementos
relacionados con las partidas técnicas de la deuda (ver Fig. 2)
b) el punto de vista que articula las actividades de gestión y
de proceso a realizar o los distintos estados por los que
puede atravesar la deuda
A. Definición de deuda técnica
Los asistentes coincidieron en lo siguiente (Dagstuhl 16K)
definición [2][5] de deuda técnica:
85

3. 1er Taller Internacional sobre Análisis Técnico de Deuda (TDA 2016)
Figura 2.Cifra contextual de deuda técnica [2][5]
La Figura 2 muestra el modelo conceptual en forma de diagrama
de clases UML, que se centra en el primer punto de vista y ayudó al
grupo a converger en conceptos clave. La deuda técnica asociada con
un sistema intensivo en software se compone de un conjunto de
elementos de deuda técnica (TD), y esta deuda técnica es una de las
muchas preocupaciones asociadas con un sistema. Los elementos TD
tienen causas y consecuencias. La causa de la deuda técnica puede ser
un proceso, una decisión, una acción (o la falta de ella) o un evento que
desencadena la existencia de ese elemento de TD, como presión en el
cronograma, indisponibilidad de una persona clave o falta de
información sobre un característica técnica. Las consecuencias de un
elemento de TD son muchas: la deuda técnica puede afectar el valor del
sistema, los costos de cambios futuros, el cronograma y la calidad del
sistema. Los objetivos comerciales de la organización patrocinadora
que desarrolla o mantiene el sistema de software se ven afectados de
varias maneras: a través de retrasos, pérdida de calidad de algunas
características del sistema y dificultades para mantener las operaciones
del sistema (continuidad). Un elemento TD está asociado con uno o más
artefactos concretos y tangibles del proceso de desarrollo de software,
principalmente el código, pero también, hasta cierto punto, la
documentación, los defectos conocidos y las pruebas asociadas con el
sistema.
atravesar. Una visión centrada en la actividad trazaría temas de
investigación a estudiar, como identificar, visualizar, evaluar y
tomar decisiones sobre la deuda técnica. También es importante
investigar los fenómenos a lo largo de la cadena causal de causas y
consecuencias.
C. Gestión técnica de la deuda
Gestionar la deuda técnica incluye reconocerla, analizarla,
monitorearla y medirla. Hoy en día, muchas organizaciones no cuentan
con prácticas establecidas para gestionar la deuda técnica, y tanto los
gerentes de proyectos como los desarrolladores solicitan métodos y
herramientas que les ayuden a planificar, rastrear y pagar
estratégicamente la deuda técnica. Identificamos dos grandes desafíos
de alta prioridad:
1) Desarrollar herramientas efectivas (académica e industria) para
ayudar a evaluar la deuda técnica:Varios estudios han
examinado la relación entre la calidad del código de
software y la deuda técnica. Este trabajo ha aplicado la
detección de "olores de código" (baja calidad del código
interno), acoplamiento y cohesión, y análisis de
dependencia para identificar la deuda técnica. Sin embargo,
todos los ejemplos empíricos recopilados de la industria
señalan que la deuda técnica más importante es causada
por compensaciones en el diseño, que no son detectables
midiendo la calidad del código. Por ejemplo, una decisión
arquitectónica que se encuentra al principio de la etapa de
diseño es la selección de un patrón de visitante frente a
diseños basados en herencia. Cualquiera de las
selecciones de diseño puede ser apropiada en el contexto
actual y no produciría olores; sin embargo, pasos evolutivos
posteriores pueden revelar diferentes problemas de
mantenimiento, según la elección. Además,
Siguiendo con la metáfora financiera, el impacto en los costos de la
deuda técnica puede verse como compuesto de principal e intereses. El
principal es el ahorro de costos obtenido al adoptar algún enfoque
inicial o atajo en el desarrollo (el principal inicial, a menudo el beneficio
inicial) o el costo que ahora implicaría desarrollar una solución
diferente o mejor (el principal actual). El interés se compone de costos
que se acumulan a medida que pasa el tiempo. Hayinterés recurrente:
Costo adicional incurrido por el proyecto en presencia de deuda
técnica, debido a la reducción de la velocidad (o productividad),
defectos inducidos y pérdida de calidad (la mantenibilidad se ve
afectada). Y ahí estáintereses devengados:el costo adicional de
desarrollar nuevo software dependiendo de un código no del todo
correcto (la capacidad de evolución se ve afectada).
Sin embargo, esta visión que resume los elementos relacionados
con la deuda técnica no capta las actividades que deben realizarse para
gestionar la deuda técnica o los estados en que la deuda puede
2) Establecer una base empírica y ciencia de datos para
deuda técnica:Los puntos de referencia bien definidos (con niveles de
incertidumbre) proporcionan una base para evaluar nuevos enfoques y
86

4. 1er Taller Internacional sobre Análisis Técnico de Deuda (TDA 2016)
ideas. También son un primer paso esencial hacia la creación de una
base empírica sobre la cual el trabajo en esta área pueda crecer de
manera más efectiva. Los puntos de referencia eficaces y bien
aceptados permiten a los investigadores validar su trabajo y adaptar los
estudios empíricos para que sean sinérgicos. La evolución de la
definición de deuda técnica y su sensibilidad al contexto han inhibido el
desarrollo de puntos de referencia hasta ahora. Un punto de referencia
ideal para la investigación de deuda técnica consistiría en una base de
código, modelos arquitectónicos (quizás con varias versiones) y
elementos de TD conocidos. Se podrían aplicar nuevos enfoques a estos
artefactos para ver qué tan bien revelan los elementos TD. La industria
necesita orientación sobre cómo y qué datos recopilar y qué artefactos
pueden poner a disposición para permitir avances en la comprensión,
medición y gestión de la deuda técnica.
una relación esencial con cómo se desarrolla la deuda técnica en la práctica.
Las actividades específicas incluyen
• Identificar los factores contextuales importantes (por ejemplo,
volatilidad del código, contexto empresarial, personal de
desarrollo) que afectan la evaluación de la deuda técnica.
• Comprender la relación de otros tipos de deuda (por ejemplo,
social, de infraestructura) como causas o consecuencias de la
deuda técnica.
• Explorar el papel de las metodologías de desarrollo para
gestionar la deuda técnica.
3) La Infraestructura Necesaria:Construyendo lo compartido
infraestructura que facilite todas nuestras actividades de investigación. Las
actividades específicas incluyen
• compartir conjuntos de datos experimentales y diseños de estudios
• Crear puntos de referencia en un esfuerzo por estandarizar
herramientas y medidas.
• desarrollar técnicas para inyectar diferentes formas de
deuda técnica en conjuntos de datos con el fin de evaluar,
predecir y validar técnicas
V.R.BÚSQUEDAROADMAPA YVISIÓN
Los participantes de Dagstuhl dedicaron algún tiempo a
imaginar cómo sería el mundo si la investigación técnica de la
deuda fuera tan exitosa como podríamos esperar. La visión
resultante se resume en los siguientes puntos:
• La deuda técnica se gestionará tan bien como ahora
gestionamos defectos, vulnerabilidades y nuevas funciones.
• Tenemos una manera de traducir las preocupaciones de los desarrolladores en
preocupaciones de los administradores: una base para tomar decisiones sobre
la asignación de tiempo para reducir la deuda técnica.
• La deuda técnica se contraerá en su mayor parte de forma intencionada.
• Los proyectos que gestionan la deuda técnica son más eficientes,
eficaces y sostenibles que los proyectos que no lo hacen.
• Existe apoyo para el trabajo arquitectónico inicial y
continuo (frente a la arquitectura emergente) y evidencia
de que ayuda a evitar y gestionar la deuda técnica.
• Las herramientas respaldan todos los aspectos de la gestión técnica de la
deuda y todas las partes interesadas las adoptan y utilizan.
• El desarrollo técnico consciente de la deuda (prácticas y
herramientas) es una forma aceptada de producir software.
CONCLUSIÓN
La deuda técnica es un campo activo de investigación con una comunidad
en crecimiento, como lo demuestra el éxito de las reuniones y el aumento de
la producción de investigación, como artículos, herramientas comerciales y
nuevos proyectos. Sin embargo, aún quedan desafíos importantes para
satisfacer las demandas de herramientas efectivas, establecer una base
empírica y señalar artefactos que sirvan como insumos para la medición y el
análisis y, lo más importante, que sean útiles en la práctica. La hoja de ruta
de la investigación es un documento y una actividad en evolución que
requiere la participación activa de la comunidad general de académicos y
profesionales por igual. La esperanza es que se siga perfeccionando y
ejemplificando en reuniones de investigadores e ingenieros interesados en
investigaciones futuras sobre gestión técnica de la deuda.
Esta visión preparó el escenario para el inicio de una hoja de ruta de
investigación que guiará las investigaciones futuras para establecer un cuerpo
cohesivo de conocimientos sobre cómo gestionar la deuda técnica. La hoja de ruta
de la investigación consta de tres partes principales:
ARECONOCIMIENTO
Copyright 2016 Universidad Carnegie Mellon. Este material se basa en el trabajo
financiado y apoyado por el Departamento de Defensa bajo el Contrato No. FA8721-05-
C-0003 con la Universidad Carnegie Mellon para la operación del Instituto de Ingeniería
de Software, un centro de investigación y desarrollo financiado con fondos federales.
1) El núcleo:Definir, comprender y centro.SIN GARANTÍA. ESTE MATERIAL DEL INSTITUTO DE INGENIERÍA DE SOFTWARE Y DE LA
UNIVERSIDAD CARNEGIE MELLON SE PROPORCIONA “TAL CUAL”. LA UNIVERSIDAD CARNEGIE
MELLON NO OFRECE GARANTÍAS DE NINGÚN TIPO, YA SEA EXPRESA O IMPLÍCITA, EN CUANTO A
NINGÚN ASUNTO, INCLUYENDO, PERO NO LIMITADO A, GARANTÍA DE IDONEIDAD PARA EL
PROPÓSITO O COMERCIABILIDAD, EXCLUSIVIDAD O RESULTADOS OBTENIDOS DEL USO DEL
MATERIAL. LA UNIVERSIDAD CARNEGIE MELLON NO OFRECE NINGUNA GARANTÍA DE NINGÚN
TIPO CON RESPECTO A LA LIBERTAD DE PATENTES, MARCAS REGISTRADAS,
operacionalizar el concepto devalorrespecto a la deuda técnica. Las
actividades específicas incluyen
• Investigar el papel del costo de oportunidad para medir las
diferencias de valor entre una decisión de implementar nuevas
características que incurren en deuda técnica o realizar
mejoras de infraestructura que eviten la deuda técnica
mientras se renuncia a las características.
• Comprender los factores, más allá del capital y los
intereses, que intervienen en la toma de decisiones sobre
incurrir, pagar y gestionar la deuda técnica.
• Comprender cómo modelar los fenómenos de deuda
técnica a lo largo del tiempo, que no es lineal en el
desarrollo de software.
O INFRACCIÓN DE DERECHOS DE AUTOR.[Declaración de distribución A] Este material ha sido
aprobado para su publicación pública y distribución ilimitada. Consulte el aviso de
derechos de autor para uso y distribución fuera del gobierno de EE. UU. DM-0004135.
Agradecemos a Tamara Marshall-Keim por su aportación experta.
REFERENCIAS
[1] W. Cunningham, “El sistema de gestión de cartera WyCash”, SIGPLAN
OOPS Mess., vol. 4, núm. 2, págs. 29 y 30, diciembre de 1992.
[2] Gestión de la deuda técnica en ingeniería de software, Dagstuhl Reports, vol. 6,
Número 4,17 al 22 de abril de 2016.http://www.dagstuhl.de/16162
[3] Octavo Taller Internacional sobre Gestión de la Deuda Técnica (MTD), Raleigh, Carolina
del Norte, 4 de octubre de 2016.
[4] NSR Alves et al., Tecnología de la información y software 2016, vol. 70, págs.
100-121.
[5] Blog de Dagstuhl. https://mtd2016dagstuhl
2) El contexto esencial:Comprender los fenómenos que
quedan fuera de la definición básica de deuda técnica y que tienen
87