Back to raw metrics – Vuelta hacia las métricas elementales.

Un cliente te pide una auditoría de la calidad de una aplicación o de un portafolio de aplicaciones. Espera una respuesta a una cuestión muy precisa. Por ejemplo:

• Esta aplicación constituye una parte importante de mi presupuesto: ¿es posible reducir sus costes y cómo?
• Me piden recuperar el mantenimiento de esta aplicación. Solamente sé que se trata de una aplicación compleja. ¿Qué debo esperar?
• ¿Es posible hacer un outsourcing de esta aplicación? ¿Cuáles son los riesgos?
• Vamos a fusionarnos con esta otra entidad. ¿Cuáles sistemas utilizar? ¿Los suyos o los nuestros?

Hay dos cuestiones distintas en estas cuestiones.

1. ¿Cuáles son los costes?
2. ¿Cuáles son los riesgos?

El departamento TI produce aplicaciones. Pone á disposición de los usuarios las aplicaciones que les permiten ejercer el negocio de la empresa. Si estas aplicaciones tienen defectos, producen errores, funcionan demasiado lentamente, pierden datos, los usuarios están descontentos.

Una auditoría de la calidad de una aplicación debería siempre responder a esta cuestión doble: ¿cómo optimizar los costes sin arriesgar la calidad del producto?

Comencemos con las métricas cuantitativas disponibles con una herramienta de análisis de código.

La talla de la aplicación o de sus diferentes módulos, en número de líneas de código (LOC). Esta medida es dependiente de la tecnología: 200 000 líneas de código (o 200 kLOC) representa una talla importante para una aplicación J2EE pero relativamente mínima para Cobol.

El número de objetos. Por objeto, entiendo por supuesto los ficheros, pero también los componentes: clases y métodos Java, páginas JSP, ficheros Javascript, programas y párrafos Cobol, funciones y procedimientos SQL, etc. En sí mismo, este número no es significativo, pero con el total de líneas de código, obtenemos una medida muy importante: la granularidad de los objetos.
200 kLOC en 200 clases Java representa 1 000 líneas de código por clase: es enorme. Esta aplicación es probablemente poco ‘legible’, y necesitará un esfuerzo – pues un coste – más importante si deseamos trasladarla a otro equipo. A tomar en consideración si nuestro cliente debe recuperar el mantenimiento aplicativo o para un outsourcing.

El número de métodos por clase: cuanto más elevado, más las clases serán llenas de funcionalidades. Esto puede indicar un problema de diseño, que va a ser un peso adicional para la comprensión de la aplicación, pero también aumentará la dificultad en hacer evolucionarla. El riesgo se vuelve más elevado de introducir defectos cuando un desarrollador efectúa una modificación. Prever una carga de pruebas en consecuencia. Esto va a hacer crecer los costes de mantenimiento.

También mires al número de LOC por método para medir la portabilidad de la aplicación. Sobre todo, el porcentaje de comentarios (líneas de comentarios / total LOC). Estas medidas permiten precisar el coste de transferencia de la aplicación.

El número de líneas de código en comentarios. Un desarrollador pone el código en comentarios con el fin de guardar esta versión del código. Esto indica que no está seguro, o sea de la nueva funcionalidad á implementar, o sea del código á producir para ésta.
Generalmente es un buen indicador de la edad de la aplicación. Cuanto más elevado el código en comentarios, más se sucedieron desarrolladores en la aplicación, más la aplicación es antigua. Una vez sin embargo, esta tasa de código en comentarios fue elevada en una aplicación que era en su primera versión, lo que indicaba una evolución de las especificaciones funcionales durante la fase de desarrollo.

Otras medidas interesantes, cuando están disponibles: los comentarios vacíos. O los objetos cuyo código completo está en comentarios: el programa o el método no hace nada. Aparte aumentar las cargas de mantenimiento inútilmente.

El número de líneas duplicadas. Muy peligroso para la fiabilidad de la aplicación. Si el mismo bloque de código es duplicado N veces, cada modificación de este código deberá realizarse N veces. No sólo esto es un peso para el coste de mantenimiento, pero si el desarrollador olvida repercutir la modificación sobre un solo bloque, el riesgo de malfonction para los usuarios es elevado. Pues carga de evolución importante y carga de pruebas también. Sería más juicioso de disponer de un componente único que implemienta esta funcionalidad. Un componente reutilizable y de calidad en lugar de N componentes duplicados: ¿que prefieras, para tu presupuesto y tus usuarios?

La complejidad ciclomática (CC). Sin entrar en el detalle de esta medida, digamos que la CC es un buen indicador del número de reglas funcionales o técnicas presentes en un componente o una aplicación. Más allá de 60 000 puntos de CC, una aplicación incluye tantas funcionalidades que se vuelve muy difícil á someter a pruebas. Prever una herramienta de automatización de las pruebas, o vas a estallar tu presupuesto y tus planificaciones.

Identificar los componentes con la CC más elevada con el fin de identificar los que serán los más difíciles á hacer evolucionar.

Cruces la complejidad con el número de líneas de código, y tendras los componentes más peligrosos para tus usuarios: el riesgo de introducir un defecto es elevado ya que el componente es á la vez pesado y complejo. De nuevo, pruebas obligatorias, rigurosas y exhaustivas. Si por encima es poco documentado, puedes pensar en reescribirlo.

Vemos que bastan algunas métricas elementales (raw metrics) para poder comenzar a responder a las cuestiones de nuestro cliente:

• ¿Cuál es el coste de transferencia de esta aplicación? ¿Cuál es el esfuerzo para que un nuevo desarrollador sea operacional con esta aplicación?
• ¿Cuál es el coste de una evolución para esta aplicación? ¿Cuáles cargas de pruebas prever?
• ¿Cuál es el riesgo de introducir un defecto cuando se realiza una evolución? Cual es el riesgo de no fiabilidad para los usuarios.

Con un poco de experiencia – estos números pueden variar según las tecnologías – pero sobre todo un poco de sentido común, aprendemos rápidamente cuales son los datos interesantes y cómo combinarlos con el fin de optimizar estas algunas medidas.

Una métrica es sólo un número. Es la utilización que hacemos de ella quién le da todo su valor para responder á la cuestión de nuestro cliente: ¿costes y riesgos?

Esta entrada está disponible también en Lire cet article en français y Read that post in english.