Deuda Tecnica metafora para teoria y practica.

1. ENFOCAR:Introducción de los editores invitados
Deuda técnica:
De la metáfora
a la teoría
y practica
Philippe Kruchten,Universidad de
Columbia Británica, Vancouver
Robert L. Nord e Ipek Ozkaya,
Instituto de Ingeniería de Software
La metáfora deLa deuda técnica en el
desarrollo de software fue introducida
hace dos décadas por Ward Cunningham.1
explicar a las partes interesadas del producto
sin conocimientos técnicos la necesidad de lo
que ahora llamamos "refactorización". Ha
sido perfeccionado y ampliado desde
entonces, especialmente por Steve McConnell
en su taxonomía,2Martin Fowler con sus
cuatro cuadrantes,3y Jim Highsmith y sus
colegas del Cutter Consortium con su modelo
del impacto de la deuda técnica sobre el
coste total de propiedad.4
De la descripción original: "código no del
todo correcto y posponemos corregirlo"1—Varias
personas han utilizado la metáfora de la “deuda”
técnica para describir muchos otros tipos de
deudas o males del desarrollo de software,
abarcando en términos generales cualquier cosa
que se interponga en el camino de la
implementación, venta o evolución de un
sistema de software o cualquier cosa que
aumente la fricción. que sufren los esfuerzos de
desarrollo de software: deuda de pruebas,
deuda de personas, deuda de arquitectura,
deuda de requisitos, deuda de documentación o
simplemente una deuda de software amorfa y
que lo abarca todo.5En consecuencia, el
concepto de deuda técnica
en el desarrollo de software se ha diluido un
poco últimamente. ¿Un nuevo requisito,
función o característica aún no implementado
es una “deuda de requisitos”? ¿Llamamos a
posponer el desarrollo de una nueva función
“planificación de la deuda”? La metáfora está
perdiendo parte de su fuerza.
Además, una vez que identificamos
herramientas como los analizadores de código
estático que nos ayudan a identificar la deuda
técnica, existe el peligro de equipararla con
cualquier cosa que nuestras herramientas puedan
detectar. Este enfoque lleva a dejar de lado grandes
cantidades de deuda técnica potencial que es
indetectable mediante herramientas, como la deuda
estructural o arquitectónica o las brechas
tecnológicas. Las brechas en tecnología son de
particular interés porque la deuda contraída
Ver www.computer.org/software
- multimedia para contenido multimedia
relacionado con este artículo.
18Software EEE|PUBL I DERRAMADO POR LA SOCIEDAD INFORMÁTICA I EEE 074 0 -74 5 9 / 12 / $ 31. 0 0 © 2 0 12 IEEE
Traducido del inglés al español - www.onlinedoctranslator.com

2. Visible Mayormente invisible Visible
arquitectura código
Nuevas características Deuda arquitectónica
Deuda estructural
Baja calidad interna
Complejidad del código
Violaciones de estilo de codificación
Defectos
Funcionalidad adicional El código huele Baja calidad externa
deuda de prueba
Deuda de documentación
Problemas de evolución: evolucionabilidad Problemas de calidad: mantenibilidad
Figura 1.El panorama de la deuda técnica. A la izquierda, la evolución o sus desafíos; a la derecha, cuestiones de calidad, tanto internas como externas.
no es el resultado de haber tomado una decisión
equivocada originalmente, sino más bien el
resultado de la evolución del contexto (el paso
del tiempo) de modo que la elección no es del
todo correcta en retrospectiva. La deuda técnica
en este caso se debe a acontecimientos
externos: obsolescencia tecnológica, cambio de
entorno, rápido éxito comercial, aparición de
nuevas y mejores tecnologías, etc.; en otras
palabras, los aspectos invisibles del
envejecimiento y la evolución natural del
software. Incluso se podría argumentar que
“dorar” un diseño arquitectónico, haciendo que
el sistema sea más flexible y adaptable de lo que
realmente necesita ser, puede ser una forma de
deuda técnica, si esta flexibilidad adicional
obstaculiza el desarrollo futuro sin ser realmente
explotada.
elementos visibles como nuevas
funcionalidades para agregar y defectos para
corregir, y los elementos invisibles (o mejor
dicho, aquellos visibles solo para los
desarrolladores de software). Podemos ver
que en la izquierda nos ocupamos
principalmente de la evolución o sus desafíos,
mientras que en la derecha nos ocupamos de
cuestiones de calidad, tanto internas como
externas. Proponemos limitar la deuda a los
elementos invisibles, es decir, a los elementos
de la caja rectangular, incluidos los aspectos
invisibles de la evolución y la calidad.
a largo plazo, y la falta de rigor o de pruebas
sistemáticas (incluidas las pruebas
automatizadas) lleva a algunos proyectos
ágiles a endeudarse enormemente
rápidamente. De hecho, esa deuda puede
acumularse mucho más rápidamente que en
cualquier proyecto tradicional tipo cascada.
Pero al final, todo es una cuestión de
elección: cuando el tiempo de
comercialización es esencial, la deuda podría
ser en realidad una buena inversión, pero es
imperativo ser consciente de esta deuda y de
la mayor fricción que impondrá al equipo de
desarrollo, ya que -sugirió Cunningham.1
Entonces, ¿cómo podemos abordar la deuda
técnica, o al menos evitar acumular demasiada?
El primer paso es la concientización: identificar la
deuda y sus causas. El siguiente paso es
gestionar esta deuda de forma explícita, lo que
implica enumerar las tareas relacionadas con la
deuda en un trabajo pendiente común durante
la planificación del lanzamiento y la iteración,
junto con otras “cosas por hacer”.7La Figura 2
ilustra cómo estos elementos podrían
organizarse en un trabajo pendiente.8Los colores
de las áreas de elementos concilian cuatro tipos
de posibles mejoras: las tareas a atender en el
futuro para aumentar el valor, como agregar
nuevas características (verde) o invertir en la
arquitectura (amarillo), y reducir los efectos
negativos sobre el valor de defectos (rojo) o
deuda técnica (negro).
Los proyectos pendientes a menudo contienen sólo
Abordar la deuda técnica
La mayoría de los autores coinciden en que la
causa principal de la deuda técnica es la presión
en el cronograma. Sin embargo, en el lado
derecho del cuadro, cuando la deuda se asocia
con problemas de calidad y mantenibilidad,
otras causas se vuelven probables, como
descuido, falta de educación, procesos
deficientes, verificación no sistemática de la
calidad o incompetencia básica.
Debido a que utilizan un proceso de
desarrollo iterativo, muchos equipos ágiles
parecen creer que son completamente inmunes
a la deuda técnica. Aunque las iteraciones
ofrecen la oportunidad de reembolsar la deuda
de manera oportuna, a menudo ocurre lo
contrario. Desarrollarse y entregarse muy
rápidamente, sin tiempo para un diseño
adecuado o para reflexionar sobre el
organización del panorama
de la deuda técnica
Para lograr algún progreso, debemos ir más allá
de la deuda como un “concepto retórico”.6
Necesitamos una mejor definición de lo que
constituye deuda técnica y algunas
perspectivas o puntos de vista que nos
permitan razonar sobre una amplia gama de
deuda técnica. En resumen, necesitamos una
base teórica.
La Figura 1 muestra una posible organización
de un panorama de deuda técnica o, más bien,
de mejora del software a partir de un estado
determinado. podemos distinguir
NOVIEMBRE /DICIEMBRE 2012|Software EEE19
Brecha
tecnológica

3. ENFOCAR:Introducción de los editores invitados
la dedicación y la artesanía ciertamente
ayudarán, pero no son los determinantes
clave para reducir la deuda técnica.
un taller reciente de la CISE sobre deuda
técnica,9Uno de ellos (el VPN) es el más
prometedor: está mejor formalizado que el
costo de oportunidad y es más simple y
menos propietario que el TCO, mientras que
el ROA puede verse como una extensión
probabilística del VPN. El TCO presenta el
peligro, mencionado anteriormente, de diluir
la deuda técnica al introducir elementos no
relacionados con el desarrollo de software
(implementación, operaciones y soporte).
La deuda técnica no debe tratarse de forma
aislada de agregar nuevas funciones o corregir
defectos, aunque estos no estén incluidos en la
definición de deuda que se presenta aquí. El
desafío está en expresar todas las actividades de
desarrollo de software en términos de
secuencias de cambios asociados con un costo y
un valor (a lo largo del tiempo).
Desafortunadamente, estos cambios no son
independientes. Sus interdependencias juegan
un papel importante; como han demostrado
Mark Denne y Jane Cleland-Huang, en particular,
las características visibles dependen de aspectos
arquitectónicos menos visibles.10
Desde esta nueva perspectiva, la deuda
técnica de un sistema en un momento dado
podría definirse como oportunidades de
inversión diferidas o riesgos mal administrados.
Visible Invisible
Nuevas características
Agregado
funcionalidad
Arquitectónico,
estructural
características
Positivo
valor
¿Una teoría unificada?
Negativo
valor
Kevin Sullivan sugirió que un modelo simple
para abordar la deuda técnica representa un
esfuerzo de desarrollo de software como una
secuencia de cambios, la mayoría de ellos
mejoras.9En un momento dado, el conjunto
pasado de cambios es lo que define el estado
actual del software. Algunos de estos cambios
pasados son los acontecimientos que
desencadenaron la deuda actual: el cambio o la
forma en que se implementó no es del todo
correcto desde la perspectiva actual.
El principal problema que enfrenta la
organización de desarrollo de software es cómo
decidir sobre cambios futuros: ¿qué evolución
debe sufrir el sistema de software y en qué
secuencia? Esta evolución está, en la mayoría de
los casos, limitada por el costo: los recursos
disponibles para aplicar para realizar estos
cambios, muy probablemente impulsados por
el valor, según lo ven las partes interesadas
externas.
El proceso de toma de decisiones sobre
qué secuencia de cambios aplicar podría
ser el principal punto de conciliación en
todo el panorama que se muestra en la
Figura 1, desde agregar nuevas
características y adaptarse a nuevas
tecnologías hasta corregir defectos y
mejorar la calidad, intrínseca o extrínseca.
Dado que este proceso de decisión trata
de equilibrar costo y valor, tal vez los
modelos económicos o financieros podrían
convertirse en el concepto unificador
detrás de todo el panorama. Algunos ya
han sido explorados hasta cierto punto:
Técnico
deuda
Defectos
Figura 2.Cuatro colores en un atraso. Las áreas de
elementos concilian cuatro tipos de posibles
mejoras: las tareas a atender en el futuro para
aumentar el valor, como agregar nuevas
características (verde) o invertir en la arquitectura
(amarillo), y reducir los efectos negativos sobre el
valor de los defectos ( rojo) o deuda técnica
(negro).
los elementos verdes; Algunos profesionales
técnicos recuerdan los elementos amarillos.
Los elementos rojos aparecen en otra parte,
tal vez en una base de datos de defectos, y
los elementos negros no se encuentran por
ninguna parte, pero paralizan cada vez más el
desarrollo, reduciendo la velocidad.
Es importante tener en cuenta, sin embargo,
que la deuda técnica no se trata sólo del código y la
calidad del código. Las herramientas de análisis de
código identificarán una pequeña cantidad de
elementos negros. Por lo tanto, las herramientas de
análisis de código no son suficientes para identificar
la deuda técnica: la mayoría de las veces, la deuda
técnica no está relacionada con el código y sus
cualidades intrínsecas sino con opciones
estructurales o arquitectónicas o con brechas
tecnológicas. Ninguna herramienta revelará que,
hace dos años, el equipo debería haber utilizado
alguna herramienta para internacionalizar y localizar
el código.
La arquitectura juega un papel importante
en el desarrollo de sistemas grandes, junto
con otras actividades de desarrollo, como la
documentación y las pruebas (que a menudo
faltan). Estas actividades pueden aumentar
significativamente la deuda y, por lo tanto,
son parte del panorama técnico de la deuda
en la Figura 1. El análisis del código solo
abordará el lado derecho del cuadro.
Profesionalismo, diligencia,
En este asunto
Esta entrega deSoftware IEEE ofrece a los
lectores diferentes ilustraciones del concepto
multifacético de deuda técnica. Erin Lim, Nitin
Taksante y Carolyn Seaman se adentraron en
la industria para comprobar cómo los
desarrolladores de software realmente
conceptualizan, perciben, experimentan y
gestionan la deuda técnica. Informan sus
resultados en "Un acto de equilibrio: lo que
los profesionales del software tienen que
decir sobre la deuda técnica". Su análisis
describe el amplio y complejo espacio
comercial de las preocupaciones a corto y
largo plazo de las partes interesadas y sus
estrategias para mantenerlos en equilibrio.
Raja Bavani complementa esta visión
desde las trincheras con entrevistas de
dos expertas ágiles, Johanna Rothman y
Lisa Crispin, en “Distributed
• Valor Actual Neto (VAN) de un
producto, del mundo financiero;
• costo de oportunidad;
• análisis de opciones reales (ROA), o
valoración; y
• costo total de propiedad (TCO) de un
sistema de TI.
Estos cuatro modelos fueron discutidos en
20Software EEE|www.computEr.org/SoftwarE

4. Equipos, pruebas ágiles y deuda
técnica”. Luego continúa ofreciendo su
propia taxonomía de deuda técnica y su
relación con las pruebas.
Bill Curtis, Jay Sappidi y Alexandra Szynkarski
exploran la viabilidad de un marco de estimación
para detectar deuda técnica utilizando datos del
mundo real. Utilizan el conjunto de herramientas
de análisis de código desarrollado por CAST
Software para identificar la deuda técnica en
sistemas grandes, basándose en datos de
calidad estructural, y literalmente le ponen un
precio en "Estimación del principal de la deuda
técnica de una aplicación".
Como alternativa, Jean-Louis Letouzey y
Michel Ilkiewicz describen la “Gestión de la
deuda técnica con el método SQALE”. El
enfoque SQALE se basa en un análisis del
código fuente de una aplicación, utilizando
los indicadores de atributos de calidad
definidos por los sistemas ISO y el
estándar de calidad del software
(capacidad de prueba, mantenibilidad,
portabilidad, etc.) para limitar el punto de
enfoque.
¿Hemos superado la metáfora de la deuda
financiera? ¿Todavía funciona? ¿Lo usamos
mal? Israel Gat y Christof Ebert no están de
acuerdo sobre este tema en un artículo de
punto/contrapunto.
Philippe KrüchTenes profesor de ingeniería de software en la Universidad de
Columbia Británica en Vancouver, Canadá. Miembro fundador de IFIP
WG2.10, realiza investigaciones sobre el proceso de desarrollo de software y
la arquitectura de software. Kruchten recibió su doctorado en la École
Nationale Supérieure des Télécommunications de París. Es un ingeniero
profesional en Canadá, un CSDP del IEEE y miembro senior (pero no senil) de
la IEEE Computer Society. Contáctelo en kruchten@ieee.org .
Robert L. norDes un miembro senior del personal técnico del Programa de
Investigación, Tecnología y Soluciones de Sistemas del Instituto de
Ingeniería de Software. Participa en actividades centradas en la
arquitectura ágil y a escala y trabaja para desarrollar y comunicar métodos
y prácticas eficaces para la arquitectura de software. Nord obtuvo un
doctorado en informática de la Universidad Carnegie Mellon y es un
miembro distinguido de ACM. Contáctelo en rn@sei.cmu.edu .
IpeK ozKayaes un miembro senior del personal técnico del Programa de
Investigación, Tecnología y Soluciones de Sistemas del Instituto de Ingeniería de
Software. Realiza investigaciones sobre métodos empíricos para mejorar la
eficiencia del desarrollo de software y la evolución del sistema con un enfoque en
las prácticas de arquitectura de software, la economía del software y la gestión de
requisitos. Ozkaya obtuvo un doctorado en diseño computacional de la
Universidad Carnegie Mellon. Ella forma parte del consejo asesor deSoftware IEEE
. Contáctela en ozkaya@sei.cmu.edu .
expresiones de gratitud 5. C. libra esterlina,Gestión de la deuda de software:
construcción para un cambio inevitable, Addison-
Wesley Profesional, 2010.
W.
Muchas gracias a todos los participantes del 3er
Taller Internacional sobre Deuda Técnica en ICSE
2012 en Zúrich y a nuestros revisores, Len Bass y
Raghvinder Sangwan. Este material se basa en el
trabajo financiado y respaldado por el
Departamento de Defensa de EE. UU. bajo el
contrato número 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. Este material ha sido aprobado para su
publicación pública y distribución ilimitada.
Esperamos que esta metáfora de la
deuda siga siendo útil limitándola
a lo que realmente es
una deuda -es decir, el resultado invisible de
decisiones pasadas sobre software que
afectan negativamente su futuro- y al no
extender el concepto a nada que tenga un
costo. Desde una perspectiva práctica,
esperamos ver más herramientas y métodos
para identificar y gestionar la deuda,
cubriendo más elementos del panorama.
Desde un punto de vista teórico, veremos
surgir modelos, muy probablemente
arraigados en teorías financieras, como el
VPN, a partir de los cuales se pueden realizar
mejores mediciones y razonamientos sobre
esta forma de deuda en el contexto más
amplio de la evolución o mejora del software.
6. N. Brown et al., "Gestión de la deuda técnica en
sistemas intensivos en software",Proc. Futuro del
Software Ing. Investigación, ACM, 2010, págs. 47–
52; doi: 10.1145/1882362.1882373.
7. N. Brown, R. Nord e I. Ozkaya, "Habilitar la agilidad a
través de la arquitectura",diafonía, noviembre/
diciembre 2010, págs. 12-18.
8. P. Kruchten, “¿De qué color es su cartera de pedidos?”,
blog, 2008; http://philippe.kruchten.com/talks.
9. P. Kruchten et al., “Informe sobre el tercer taller
sobre gestión de la deuda técnica”, que se
publicará enACM SIGSOFT Software Ing. Notas,
vol. 37, núm. 5, 2012; http:www.sigsoft. org/
SEN.
referencias
1. W. Cunningham, "El sistema de gestión de
cartera WyCash",Proc. OOPSLA, ACM, 1992;
http://c2.com/doc/oopsla92.html.
10. M. Denne y J. Cleland-Huang, "El método de
financiación incremental: desarrollo de software
basado en datos",Software IEEE, vol. 21, núm. 3,
2004, págs. 39–47.
2. S. McConnell, “Deuda técnica”, blog, 2007;
http://blogs.construx.com/blogs/stevemcc/
archive/2007/11/01/technical-debt-2.aspx.
3. M. Fowler, “Deuda técnica”, blog, 2009; http://
martinfowler.com/bliki/TechnicalDebt.html.
Los artículos y columnas de CS seleccionados
también están disponibles de forma gratuita en
http://ComputingNow.computer.org.
4. I. Gat, ed., “Número especial sobre deuda técnica”,
Cortador IT J., vol. 23, núm. 10, 2010.
NOVIEMBRE /DICIEMBRE 2012|Software EEE 21
t
el
ors