en DESARROLLO DE SOFTWARE

Métricas para la calidad del software

Definí una vez la ingeniería del software es aquel conocimiento específico que busca maximizar la calidad del software y minimizar su coste. Siguiendo con esa misma idea: ¿Cómo se podría maximizar la calidad del código escrito (incluyendo su diseño)? Los pasos básicos serían:

  1. establecer una serie de métricas (variables a maximizar o minimizar) sobre el código. Sólo nos sirve aquello que podamos medir.
  2. montar un sistema automático que genere información sobre esas variables y su evolución a lo largo del desarrollo (integración continua).
  3. aplicar medidas sobre el código y observar si se consigue maximizar o minimizar la variable objetivo

Muchas de las medidas que maximizan la calidad producen como efecto colateral una diminución en el coste, y viceversa. Tradicionalmente se piensa que aumentar la calidad es aumentar el coste en tiempo. Pero muchas veces el tiempo invertido en aumentar la calidad (robusto, flexible, mantenible, escalable) repercute en el futuro en un menor coste de desarrollo o mantenimiento.

Valores abstractos del software:

  • Robusto: libre de errores.
  • Flexible: permite reutilización y adaptación a nuevos requisitos.
  • Mantenible: permite entender el código tiempo después de haber sido escrito y/o por personas que no lo escribieron (estándares de sintaxis y documentación).
  • Escalabilidad y rendimiento: al aumentar el número de usuarios, el rendimiento no disminuye exponencialmente.
  • Seguridad: existen herramientas que enfrentan a tu código a una base de datos de vulnerabilidades conocidas.

Las variables medibles (métricas) que pongo a continuación están centradas en el código, no en la gestión de proyectos (no se incluyen métricas como “esfuerzo del equipo”, etc…). Tampoco en temas propiamente web como la accesibilidad ni el diseño de interfaces (usabilidad).

  • Número de lineas de código: tiene una utilidad limitada. Depende de la forma de escribir el código, la misma sentencia se puede escribir en una o varias lineas, en diferentes lenguajes la misma funcionalidad puede tener diferente cantidad de lineas, etc. Pero si se utiliza para comprar el número de lineas de código entre dos versiones del mismo software, se puede observar si el crecimiento en lineas de código es lineal o no. Si no lo es, puede valer la pena investigar por qué.
  • y : se trata de analizar todos los caminos que llevan al mismo código y medir cuantos caminos hay. Da una medida de la reutilización que se hace del código. No se busca ni maximizarla ni minimizarla, sino mantenerla entorno a una cifra.
  • : porcentaje de código cubierto por las pruebas. Se aplica de forma práctica en las pruebas unitarias. Los principales frameworks xUnit dan datos de code coverage. Se busca maximizarla.
  • Cohesion:  mide la relación entre las responsabilidades de las clases de un mismo módulo.  Se busca maximizarla.
  • Acoplamiento: Si dos clases están poco acopladas, si se hace un cambio en una de las clases repercutirá poco o nada en la otra clase. Si están muy acopladas, un cambio en una clase supondrá cambios importantes en la otra. Se busca software con alta cohensión y  bajo acoplamiento. El acoplamiento se puede medir en función del número de imports (includes), extends, implements, que relaciona a unas clases y módulos con otras.

Un software cuyo código tiene una cohesión alta, un acoplamiento bajo, tiene un alto porcentaje de código cubierto por pruebas unitarias y/o funcionales, tiene código que se reutiliza desde diferentes partes y cuyas lineas crecen de manera controlada, es un código que permitirá añadir funcionalidades facilmente (reduciendo el coste de añadirlas) y permitirá mantener más fácilmente el código existente.

    Algunas herramientas para aplicar métricas sobre el software:

    .

    Escribe un comentario

    Comentario

    1. hola!

      el PHP Depends me ha parecido que estaba un poco en bragas todavía… 😀
      Si lo pruebas, comenta a ver qué tal lo ves… el PMD, en cambio, parece estar mucho más desarrollado…