8 criterios de elección de una herramienta de análisis de código (2/2)

En el primer post de esta serie “Cómo elegir una herramienta de análisis de código?”, hemos mencionado cuatro criterios que encontramos a menudo, aunque su importancia varía en función de lo que se quiere hacer.

Número de tecnologías analizadas

No elijas una herramienta, únicamente porque puede analizar también PL1 o Powerbuilder si estas tecnologías representan menos de 10 % del sistema de información.

No se desarrollan nuevas aplicaciones con estos lenguajes, y se espera que las aplicaciones existentes mueran o sean migradas. Y ya sabes bien que la inversión de un editor de software en una tecnología es proporcional a las ventas: un analizador PL1 jamás ofrecerá el mismo nivel de funcionalidades que un analizador J2EE. No los pongas en el mismo plano.

Número de métricas

La mayoría de los casos de uso de una herramienta de análisis de código – Integración Continua, Mejora de Calidad, Quality Gate y Gestión de outsourcing – se basa en un conjunto reducido de 10 a 20 métricas. Identificad las métricas críticas para los casos de uso que querreis implementar. Luego los indicadores que parecen interesantes o útiles. El resto es “nice to have”.

Capacidad de crear nuevas métricas

¿Por qué el 90% de los usuarios de una herramienta de análisis de código son satisfechos con las métricas por defecto? Porque corresponden a estándares del mercado. No jugues al aprendiz de brujo creando tus propios estándares: esto viene con un coste, de desarrollo, de mantenimiento, de implementación y de soporte a cada upgrade de la herramienta.

Vínculos entre los componentes

De las tres tecnologías más encontradas – J2EE, Cobol, SAP – solamente la primera es multi-capas. Si utilizas frameworks J2EE, las métricas basadas en la relación entre los componentes pueden ser útil. Recuerdate, sin embargo, que representan una pequeña proporción del total de las reglas, y que tienen un coste, especialmente de validación de falsos positivos.

Veamos ahora 3 criterios que creo realmente importantes.

Modelos multiples de Calidad

El conjunto de las métricas y su organización en diferentes factores constituyen un modelo de Calidad, la tabla de medidas según la cual vas evaluando la calidad de las aplicaciones. Más flexibilidad en la constitución de diferentes modelos, más fácil la evaluación.

¿A partir de cuántas líneas un programa Cobol es muy voluminoso? ¿A partir de cuántos puntos de complejidad (CC) es muy complejo? Los programas Batch son más pesados que los programas TP (transaccionales) y es recomendable poder afectar umbrales diferentes sobre estas métricas. Si no, un equipo de proyecto que debe efectuar el mantenimiento de una aplicación Batch será penalizado frente a un equipo que administra una aplicación TP.

Otros ejemplos:

  • Una base de datos crece con la acumulación de datos y, en el curso del tiempo, algunas ‘bad practices’ de programación SQL comenzan a producir efectos nefastos para el rendimiento de las aplicaciones. No esperas a que se pongan en el rojo con los umbrales por defecto: poder subir el nivel de criticidad permite una gestión proactiva de los riesgos para el rendimiento.
  • ¿Sabes cuánto cuesta un proyecto de upgrade de version SAP? ¿Sabes el número de días necesarios para identificar los componentes que dejarán de funcionar porque utilizan sintaxis no soportadas por la nueva versión o porque acceden al núcleo de SAP? O tienes una aplicación C++ destinada a manejar cajas registradoras de diferentes marcas con sistemas operativos distintos. En tales casos, la portabilidad del código se hace el factor más crítico de tu modelo Calidad, aunque no lo es nunca usualmente.

No existe un Quality Model único: sería como medir manzanas y patatas. Poder definir y escoger un modelo de calidad adaptado a una aplicación es un criterio más importante que los de la lista anterior.

Personalización del dashboard

Los resultados de las métricas calculadas con el código fuente de las aplicaciones aparecen en un ‘dashboard’ o panel de control del pilotaje de la calidad. La capacidad de personalizar este dashboard basandose en casos de uso, tecnologías o incluso una aplicación es un factor de éxito de tu proyecto Calidad.

Imaginemos que se te pide efectuar una auditoría de una aplicación crítica y presentar los resultados a los arquitectos y al equipo de proyecto. En el último momento, antes de entrar en la sala, te anuncian que el director informático estará presente. Éste llega para sumergirse inmediatamente en la lectura de sus e-mails en su Blackberry. ¿Que haces para interesarle por tu presentación?

Simple. Muestrale cuánto le cuesta esta aplicación.

Un arquitecto Java o un responsable Calidad sabe lo que es la Complejidad Cyclomatica o una métrica tal como LCOM4. Puedo pues presentarles un dashboard con ciertas métricas (LOC, CC, tasa de comentarios o de código duplicado), pasar a la lista de los defectos más graves y concluir con una evaluación cualitativa y cuantitativa.

Para un director informático, un responsable de desarrollo o un manager Outsourcing, voy a comenzar con una evaluación de costes. Quiero mostrar la deuda técnica en la parte superior de la primera pagina del dashboard, bajar en ejes funcionales tales como la mantenibilidad o la fiabilidad de la aplicación, luego una lista de indicadores presentes en un SLA (Acuerdo de nivel de servicio) y terminar con un plan de acción.

Imagina que puedes construir cualquier panel de control por drag and drop, con el usuario á tu lado, diciéndole: ‘ ¿Eso quieres? ‘, ‘ ¿Este diagrama allí? ‘, ‘ ¿Cuáles indicadores te interesan primero? ‘.

Eso sí es un criterio importante.

Integración con otras herramientas

Ya lo sabes, lo más antes un defecto es identificado, lo menos es costoso a resolver. Y lo más antes para identificar un defecto, es cuando el programador acaba de hacerlo. Así como decía un responsable: “si tengo 30 desarrolladores trabajando en una aplicación, no voy a esperar al final de la semana para arreglar sus bugs”. A 5 días a la semana y por programador, esto hace 150 días de defectos que se acumulan. Demasiado tarde.

Idealmente, deseamos:

  • Poder administrar los componentes de una aplicación en un repositorio de gestión de versión o de configuración.
  • Poder lanzar un ‘build’ (nueva versión) de la aplicación cada vez que un desarrollador crea una nueva versión de un componente en el repositorio. De esa manera, se puede comprobar que la versión compila correctamente y poner en marcha automáticamente un análisis del código fuente con el fin de identificar cuanto antes todo nuevo defecto.
  • Disponer de alertas automáticas cuando aparecen ciertos defectos y pedir una corrección.
  • Actualizar automáticamente la lista de tareas de cada desarrollador con las correcciones que hay que efectuar.

Para más detalles, también ver ‘Mejora continúa de la calidad‘.

Coste

Evidentemente, es un criterio determinante de una elección de herramientas, y se necesitaría un post entero con el fin de discutir sobre eso. Simplemente quiero mencionar la aparición de nuevos modelos de coste.

Todo el mundo conoce el modelo tradicional basado en una licencia por usuario que se caracteriza por un coste inicial más o menos elevado – según el número de licencias, de módulos adicionales y de otros factores tales como finales del trimestre o del año cuando un editor de software está más fácilmente dispuesto á algunas concesiones tarifarias.

El mundo Open Source trajo nuevas prácticas con una licencia por servidor de análisis y no por usuario, y un modelo económico orientado al servicio: no pagas el mantenimiento sino un soporte de nivel más alto. ¿Cuál es la diferencia? Puedes dejar de pagar sin perder por eso el beneficio de nuevas actualizaciones o el soporte de la comunidad.
Por fin, vemos aparecer cada vez más soluciones de tipo SaaS, con un coste a la utilización o en forma de abono.

Hice algunas simulaciones y le animo a hacer lo mismo. Algunas conclusiones, demasiado rápidas y que necesitaríamos afinar, pero:

  • El modelo ‘licencia’ es más costoso que el modelo ‘suscripción’ (Open Source / Saas) en los primeros años; el modelo ‘suscripción’ puede – eventualmente – volverse más costoso al cabo de un período bastante largo (8 – 10 años mínimo).
  • El éxito del modelo ‘suscripción’ es fuertemente dependiente de la tasa de renovación.

Una diferencia del 5 % en la renovación de las suscripciones impacta muchísimo la rentabilidad y el valor de un editor tipo SaaS u Open-Source. Entiendes por qué él tiene interés en cuidarte.

En conclusión, me parece importante definir los criterios de elección de una herramienta de análisis de código con una identificación precisa de las necesidades, centrada en el portafolio de aplicationes y los casos de utilización que se desea implementar.

Intentaré ilustrar algunos de estos casos en el futuro. En la espera, no dudéis en dejar vuestros comentarios en el blog.

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

Deja un comentario

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