Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (3/3)

6. Diseño

 

diseñoFigura 10. Métricas de diseño

Esta métrica nos sirve para controlar nuestro diseño. Aunque un diseño sea bastante bueno desde el principio, puede ir sufriendo una cierta erosión a lo largo del tiempo. Esta métrica calcula los ciclos que hay entre paquetes en nuestro sistema, por lo que ir revisándola cada cierto tiempo es bueno para saber cómo evoluciona el diseño de nuestro software y poner remedio si empeora.
Cuando dos, tres o cuatro paquetes están involucrados en un ciclo, quiere decir que esos paquetes dependen unos de otros y no se pueden dividir, reduciendo la modularidad del sistema, y haciendo que el sistema sea más difícil de probar y menos mantenible.
A la izquierda de este cuadro de mando de diseño, aparece el número total de ciclos presentes en todo el sistema, y el índice de interdependencia entre paquetes, que nos da una idea del grado de acoplamiento general del sistema (un valor 0% significa que no hay ningún ciclo en el sistema, y un valor de 100% que los paquetes están muy acoplados).
 
La fórmula del índice de interdependencia entre paquetes es la siguiente:
dependenciaPaquetesFormula
 
Donde:

Dependencias entre archivos que hay que reducir indica  el número de dependencias entre archivos que hay que reducir para eliminar todos los ciclos entre directorios.

Una vez que hemos observado la zona izquierda de este cuadro de mando, tendremos una idea general acerca del estado del diseño de nuestro software. En la parte derecha de esta sección, Sonar nos indicará cuántas dependencias concretas entre paquetes y archivos hay que eliminarpara mejorar el diseño.
Si por ejemplo pinchamos sobre el número de dependencias a cortar entre paquetes (en  el caso de la Figura 10, hacemos click en la línea que dice “230 entre paquetes”), accederemos a una pantalla en la que podremos ver cuáles son esas dependencias entre paquetes que tenemos que eliminar y los paquetes que están involucrados en los ciclos.
Uno de los elementos presentes en esta vista será la Matriz de dependencias de Sonar (Figura 11):

matrizDependencia1

Figura 11. Matriz de dependencias. Ciclos sospechosos a eliminar

En gris aparecen las dependencias entre los distintos paquetes, y en rojo los ciclos sospechosos y que involucran a los paquetes.
Por ejemplo, si nos fijamos en el paquete .list, y hacemos click en el número 2 con el cuadrado rojo, la vista cambiará a la Figura 12. El paquete .iterators queda seleccionado, con lo que quiere Sonar nos quiere decir que el paquete .list tiene 2 dependencias con el paquete .iterators que deben ser eliminadas.
matrizDependencia2

 Figura 12. Matriz de dependencias

Profundizando un poco más en esta sección y haciendo más clicks, podremos saber en qué archivos están las dependencias y en qué parte del código.
 

7. Test

pruebas

Figura 13. Test

Por último, hay una sección en el cuadro de mando principal de Sonar, donde se muestra información acerca de las pruebas: el % de cobertura de pruebas, y en el caso de que las haya, cuántos test ha pasado o no nuestro software.
Para obtener resultados en esta sección, es necesario utilizar un lanzador que analice los proyectos de Sonar compilando el código, por ejemplo Maven.
 

Posts anteriores:

Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (1/3)
Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (2/3)

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *