Hoy terminamos nuestra evaluación de la calidad del código Cobol analizado con el Sonar.

En el post anterior, hemos trabajado con las métricas que medían el tamaño del código, su complejidad, el nivel de documentación y de duplicación, lo que nos permitió formular algunas primeras recomendaciones a los responsables de esta aplicación.

Blockers et Critical

A ver las violaciones ahora. Recuerdate que hemos orientado nuestro modelo Calidad hacia la identificación de defectos de robustez y de rendimiento, los que afectan lo más a los usuarios.

El número de defectos bloqueantes es poco elevado. Encontramos el ‘SORT’ de lo que hablamos anteriormente, y 5 ‘OPEN’ de ficheros en un bucle. Este tratamiento costoso para el sistema operativo por supuesto debe realizarse antes del bucle. Estas violaciones presentan un riesgo elevado para el rendimiento pero son fáciles de corregir.

Los defectos críticos se refieren a la robustez:

• Un código de ‘status’ declarado para la gestión correcta de un archivo no ha sido probado durante una operación en este fichero (OPEN, READ, WRITE, …). Un intento de escribir en un archivo no abierto, de leer en un archivo abierto en escritura (Output file), un tamaño de registro (RECORD) incorrecto son errores que pasarán inadvertidos.
• Un GOTO que encamina el tratamiento fuera del módulo corriente rompe la lógica de ejecución de éste.
• El EVALUATE sin WHEN OTHER es clásico: si ninguna de las condiciones del EVALUATE es verificada, la lógica del programa se vuelve imprevisible.
• La última regla sobre el tamaño del fichero sólo se aplica a Cobol Microfocus, no z/OS (mainframe IBM).

Es muy probable que exista un estándar de calidad para la gestión del código ‘status’ de ficheros, pero que esta ‘best practice’ se olvida a veces. No se puede evitar la falta de atención. Sin prueba de este código, un tratamiento incorrecto puede llevar a cabo una inconsistencia de los datos sin que se detecta.. La búsqueda de la causa del error también será más difícil. Al igual que el EVALUATE sin WHEN OTHER.

Cualquier violación de estas reglas para la gestión de errores impacta no sólo a los usuarios, sino también a los costes de mantenimiento. En nuestro caso, sus números son suficientemente altos para pensar que se necesita recordar estas buenas prácticas a los desarrolladores.

Costes de remediación

¿Te recuerdas el widget que hemos utilizado en el post anterior, con los defectos más frecuentes?

Encontramos de nuevo el IF sin END-IF de que ya hemos hablados, los peligrosos GOTOs, más de 4 500 párrafos sin documentación y código duplicado. Estas violaciones impactan la mantenibilidad de la aplicación, como se puede ver en este diagrama:

No vamos a comentar en detalles estos defectos ya que nuestro objetivo es identificar a los que impactan a los usuarios. Pues las 45 violaciónes de tipo ‘Blockers’ y los 292 ‘Critical’ representan, respectivamente, 5.6 días y 50.5 días de corrección.

Aproximadamente dos semanas de trabajo para un equipo de 5 o 6 personas versus más de 10 años/hombre para corregir todas las violaciónes que afectan los costes de mantenimiento.

Plan de acción

Por supuesto, vamos a presentar los resultados al equipo del proyecto y comentar con ellos para comprobar nuestras hipótesis. Sin embargo, nuestro objetivo no es realizar una auditoría exhaustiva, sino mostrar cómo es posible llegar a algunas conclusiones basadas en estos datos, y formular un plan de acción preliminar.

Acciones a corto plazo:

• Corregir los defectos ‘Blockers’ que afectan al rendimiento: 5 días.
• Corregir los defectos críticos, una fuente potencial de errores: 55 días.
• Recordar a los equipos Cobol: nada de GOTO – especialmente cuando crean una excepción a la lógica del módulo – y recordar también las mejores prácticas de gestión de errores, como la obligación de comprobar el estado de un archivo después de cualquier operación sobre él y el EVALUATE sin WHEN OTHER.
• Realizar análisis periódicos de esta applicación y verificar que no vuelven a aparecer defectos bloqueantes o críticos.

Estas acciones no cuestan mucho y se pueden realizar a corto plazo, para un beneficio optimal. Ellas conducen a la creación de un proceso de mejora continua. Los usuarios te lo agradecerán.

Esta aplicación cuenta con altos costes de mantenimiento. Consulte con el management si es el caso y cual es su opinión al respecto. Es muy posible que esta aplicación tenga pocas evoluciones o ninguna, y en tal caso, el mantenimiento no es un problema.

Verifica también las hipótesis que hemos formulado en el post anterior (applicación batch orientada a la gestión de ficheros de datos, poca critica) y explica bien que ella no puede ser subcontratada con seguridad.

Propone el plan de acción siguiente:

• Identificar y eliminar los 184 archivos duplicados, que pesan sobre el mantenimiento.
• Realizar un nuevo análisis para calcular la deuda técnica y el coste estimado de refactorización.

Estrategia aplicativa

El refactoring de una aplicación en Cobol es una operación que rara vez se considera, porque los costes son demasiado altos. En general, la aplicación puede morir de muerte natural, y se busca otra solución (por ejemplo, ERP).

Deseamos formular recomendaciones realistas. Pues esto es lo que hago: buscar los programas que tienen el mayor número de líneas y de defectos.

Aquí tenemos tres programas que representan más de 27 000 líneas, el 15% del tamaño total de la aplicación (LOC).

También están entre los cinco primeros más complejos, con un total de 5 900 puntos de Complejidad Ciclomática, o el 26% de la complejidad total de la aplicación.

Y son los tres programas en los cuales se concentran más violaciónes, de tipo mayor, pero pocos críticos más.

En total, más de 6.700 violaciónes, casi una cuarta parte (24%) del número total de defectos encontrados en esta aplicación.

Claro, el coste de remediación de estos tres programas es muy alto: 735 días, alrededor de 3 años-hombre.

¿Qué información podemos ofrecer?

Un refactoring parcial en estos tres programas que representan el 15% del tamaño de la aplicación y el 26% de su complejidad, eliminaría una cuarta parte del número total de defectos, casi exclusivamente en Maintainability.

Imaginamos que esta refactorización parcial reduciría el coste de mantenimiento en la misma proporción (25%), lo que representa para un equipo de 6 personas una ganancia de 1.5 persona al año. Versus un coste de refactorización de 3 años-hombre, el retorno de la inversión es de 2 años.

Cierto, esta es una estimación rápida, si no poca precisa. Pero quiero ilustrar de esta forma que el valor de una auditoria es proporcionar información objetiva que permita tomar decisiones a los responsables. La deuda técnica de cualquier aplicación en general da como resultado una única decisión posible: echar esta aplicación. Una estimación de las ganancias y los costes y retorno de la inversión con una refactorización parcial puede llegar a imaginar una estrategia. El management prefiere unos datos para alimentar la reflexión a no tener nada y aunque tus cifras suponen un cierto margen de error, el es plenamente consciente de lo que es tu intención y aprecia su valor.

Vende el valor

Este post concluye nuestra serie sobre análisis de código Cobol con el Sonar. Nuestra intención en esta serie fue demostrar que es posible evaluar la calidad de las aplicaciones Cobol sin ser un experto en el mundo Mainframe. Del mismo modo, no es necesario ser un gurú en Open Source o un experto en J2EE para llevar a cabo análisis con Sonar.

Con un conocimiento basico de la tecnología Cobol y de Sonar, podemos ofrecer a los equipos de proyecto, los stakeholders y el management un plan de acción a corto / medio plazo que mejora el rendimiento y la robustez de la aplicación, sino también el cumplimiento de las buenas prácticas y la calidad del códigoo.

También podemos ofrecer a los managers lo que solicitan lo más: información para una mejor toma de decisiones. Ahi es el valor de tus análisis. Vende este valor, no las métricas o tus conocimientos técnicos.

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