El concepto de deuda técnica fue introducido por Ward Cunningham en el año 1992 y viene a significar que las malas prácticas en el desarrollo de software provocan una situación de deuda que repercute en un sobrecoste no sólo en el proceso de mantenimiento del software de un sistema de información sino también en su propio funcionamiento.
La deuda técnica es un modelo que debe utilizarse para no ir empeorando un proyecto a lo largo de su ciclo de vida.
Si lo hemos tenido en cuenta desde el principio del proyecto conseguiremos mantener una deuda baja sin acumular demasiados intereses, sin embargo, si en el proyecto no se ha tenido en cuenta, la deuda puede ser tan alta que el proyecto se hace imposible de mantener y puede ser más rentable volver a construirlo de cero.
El método SQALE permite gestionar la deuda técnica de nuestros proyectos y conocer que características de nuestro código acumulan más deuda.
El método SQALE
El método SQALE se basa en ocho principios fundamentales:
- La calidad del código fuente es un requisito no funcional.
- Los requisitos en relación con la calidad del código fuente tienen que ser formalizados como cualquier otro requisito funcional. Como consecuencia, un requisito de calidad que afecte al código fuente tiene que ser al menos:
- Atómico
- No ambiguo
- No redundante
- Justificable
- Aceptable
- Implementable
- No contradictorio con cualquier otro requisito
- Verificable
- Medir o calcular la calidad del código es en esencia medir la distancia entre su estado actual y el objetivo esperado.
- El método SQALE mide la distancia a la conformidad de los requisitos considerando el coste de remediar o corregir el código fuente hasta alcanzar la conformidad.
- El método SQALE respeta la condición de representación, un componente importante de la teoría de medidas. La condición de representación afirma que una medida M tiene que mapear entidades en números y relaciones empíricas en relaciones numéricas de tal manera que se siga preservando el significado.
- El método SQALE utiliza la adición para agregar los costes de corrección y para calcular los indicadores de calidad.
- El modelo de calidad de SQALE es ortogonal. Esto significa que un requisito relacionado con un atributo de calidad sólo aparecerá una vez en el modelo de calidad. Un requisito se enlazará solamente con una subcaracterística de calidad. Y una subcaracterística se enlazará solamente con un característica.
- El modelo de calidad de SQALE tiene en cuenta el ciclo de vida del software. Las características, subcaracterísticas y requisitos se organizan de manera que se pueda reflejar correctamente la cronología de las necesidades tal y como aparecen en el ciclo de vida del software.
Estructura del modelo
El modelo de calidad se organiza en tres niveles jerárquicos. El primer nivel se compone de un conjunto de características, y el segundo nivel de subcaracterísticas. El tercer nivel se compone de los requisitos que relacionados con los atributos internos del código fuente.
 |
| Estructura del modelo |
Características
El método SQALE define ocho características de primer nivel que se deducen del ciclo teórico de un fichero de código fuente (codificar, testear, cambiar, entregar, mantener, portar, reutilizar).
Estas características se establecen conforme a la norma ISO 9126 y han sido seleccionadas para el modelo porque representan propiedades internas del código, y porque impactan directamente en las actividades típicas del ciclo de vida del desarrollo software.
El método SQALE es una proyección de la norma ISO 9126 sobre la cronología del ciclo de desarrollo del software.
 |
| Características del modelo |
Subcaracterísticas
Cada una de las características se “rompe” en un conjunto de subcaracterísticas. Estas subcaracterísticas se utilizan para agrupar los requisitos y así permitir realizar análisis con varios niveles de abstracción.
Existen dos tipos de subcaracerísticas:
- Las que se corresponden con actividades del ciclo de vida como pruebas unitarias, pruebas de integración, optimización del uso de procesador o del tamaño del código generado.
- Las que resultan de aplicar reglas en términos de buenas o malas prácticas relacionadas con la arquitectura del software y la codificación.
Requisitos
Este nivel del modelo contiene todos los requisitos de calidad del código, siempre respetando los criterios presentados en los principios fundamentales. Estos requisitos se refieren a aspectos que existan en el código fuente.
Por ejemplo, supongamos que se especifica un requisito relacionado con la complejidad ciclomática. Este requisito tendrá impacto sobre las pruebas unitarias (por tanto, afectará a la característica de la facilidad de prueba) y a la legibilidad (y por tanto, afectará a la característica de mantenibilidad).
Cada uno de los requisitos se enlaza con el nivel más bajo posible, en relación con la primera característica de calidad a la que contribuya cronológicamente.
Un ejemplo de requisito puede ser un umbral límite para una métrica estructural, o respetar una regla sintáctica.
Calificación SQALE
La calificación consiste en producir una métrica derivada en una escala ordinal, como por ejemplo: bien, normal, mal.Por ejemplo, podemos tener una escala de cinco valores: A, B, C, D y E.
La calificación para una característica concreta y un artefacto concreto es el resultado de una comparación del coste estimado de corregirla respecto a la estimación del coste de desarrollo de ese artefacto, o lo que es lo mismo la deuda técnica de tu artefacto software.
¿Y cómo ponerlo en práctica?
Todo esto es la teoría, podéis leer más detalles en la propia definición del método ya que es un documento libre que cualquiera puede descargar. Pero, ¿cómo lo ponemos en práctica?
Pues para poder implementar el método simplemente necesitamos implementar los tres pilares básicos: los requisitos, las características y las subcaracterísticas. Pueden ser los que uno desee y como desee, pero deben cumplir las condiciones expresadas en el método, que básicamente se traduce en que:
- El requisito debe poder medirse y no ser ambiguo, por ejemplo, un requisito puede ser "código duplicado menor del 5 %" .
- El requisito solo puede afectar a una subcaracterística.
- Una subcaracterística solo puede afectar a una característica.
- Se ha de poder medir la distancia entre la situación del requisito en un momento dado y la situación a alcanzar. Por ejemplo: ¿cuánto me cuesta arreglar un bloque de código duplicado?
Y una vez tenemos definida nuestra implementación pues se trata de medir y de controlar como van evolucionando esas medidas y nuestra deuda técnica.
Afortunadamente el método es conforme a la norma ISO 9126, por lo que no hay que volver a definir las características y subcaracterísticas (no tenemos que reinventar la rueda), sin embargo el método es suficientemente flexible como para que puedas definir las tuyas propias.
Herramientas
Implementar el método SQALE y no tener herramientas que lo soporten para poder gestionarlo no sería muy práctico. Por ello en la propia página de SQALE hay un listado de herramientas disponibles que implementan el método.
De todas ellas me quedo con Sonar, herramienta que forma parte de nuestra plataforma QAlitaX y sobre la que desarrollamos nuestras propias extensiones (Sonar City Model, ABC Metric, PMD Model, Findbugs Model, ...)
Y es aquí es donde está la gracia, ya que a través de la extensión de Sonar para el método SQALE desarrollada por el equipo de Sonarsource podemos implementar nuestro modelo de calidad del método SQALE y tener un cuadro de mando para la gestión de la deuda técnica muy completo:
 |
| Cuadro de mando de SQALE en Sonar |
Podemos incluso conocer qué características y subcaracterísticas son las que acumulan más deuda técnica y de esa manera atacar problemas específicos de calidad en nuestro proyecto de desarrollo de software:
 |
| Gráfico SQALE con el reparto de deuda técnica por características y subcaracterísticas |
En el ejemplo de la imagen superior podemos ver como la mayor deuda técnica se acumula en la característica de adaptabilidad, afectando a las subcaracterísticas de adaptabilidad relacionada con la lógica, adaptabilidad relacionada con los datos y adaptabilidad relacionada con la arquitectura.
La deuda técnica en forma de ciudad
Los diferentes gráficos que proporciona el plugin de SQALE para Sonar son útiles para conocer la deuda a través de las diferentes características del modelo, pero también es muy interesante poder visualizar la deuda en cada elemento del proyecto, es decir, ¿qué clases de mi proyecto son las que más deuda tienen? Esto lo puedes hacer a través del navegador de métricas de Sonar, pero sin embargo si utilizas la extensión City Model para representar tu código fuente en forma de ciudad 3D, podrás configurar el modelo para que utilice la deuda técnica a la hora de representar los edificios.
Un simple vistazo a la ciudad te permitirá conocer rápidamente cuales son los barrios que acumulan más deuda y poder acceder a las clases específicas para ir resolviendo las diferentes evidencias.
La siguiente ciudad representa un modelo en el que los colores de los edificios se corresponden con la calificación SQALE, desde el mejor caso, verde (calificación A) hasta el pero caso, rojo (calificación E):
 |
| Ciudad que representa la deuda técnica de un proyecto (calificación SQALE) |
Esta representación visual te da una idea general de donde se concentra la mayor deuda técnica de tu proyecto sin necesidad de conocer la arquitectura técnica de la aplicación ni tener que navegar por listas de ficheros, paquetes, o abrir un entorno de desarrollo completo. El modelo también puede parametrizarse para que en lugar de la calificación representa la deuda técnica exacta en cada edificio.
Resumen
La deuda técnica te permite conocer los intereses que están generando las malas prácticas en el ciclo de vida de un proyecto de software. Cuanta más deuda acumulada, más difícil que el proyecto sea un proyecto de éxito. La deuda técnica responde a la pregunta: ¿qué sobrecoste están introduciendo las malas prácticas en mi proyecto?
El método SQALE lleva el concepto de deuda técnica un poco más lejos, creando un modelo de calidad a partir de unos requisitos, características y subcaracterísticas. Esto permite conocer el detalle de a qué características está afectando la deuda técnica y así poder gestionar mejor su corrección. El modelo de calidad de SQALE responde a la pregunta: ¿a qué características de calidad está afectando la deuda técnica que se esta acumulando?
Y por último, QAlitaX City Model te permite de forma sencilla visualizar los puntos débiles de tu proyecto en función de su deuda. City Model responde visualmente a la pregunta: ¿qué elementos de mi código están acumulando mayor deuda técnica?
Poder contestar a esas tres preguntas es la clave para asegurar el éxito y la calidad de un proyecto de software. Y vosotros, ¿cómo gestionáis la deuda técnica de vuestros proyectos de desarrollo?
Más información
- La deuda técnica en la wikipedia.
- El método SQALE, portal del método y documentación asociada.
- SQALE Quality Model, implementación del modelo de calidad de SQALE en Sonar.
- Sonar City Model, modelado de ciudades en 3D a partir de código fuente y métricas de calidad.