Complejidad ciclomática, o la métrica esencial para evaluar el diseño software
Archivado en calidad, diseño, métricas en Oct.27, 2007 por jgarzas
Fue en 1976 cuando Thomas McCabe publicó un artículo en el que argumentaba como la complejidad del código puede obtenerse desde su flujo de control, o dicho de una manera más exhaustiva del número de rutas linealmente independientes del código, definiendo para ello una de las métricas más útiles en ingeniería del software, y que denominó “complejidad ciclomática”. En sí el concepto no era nuevo, ya que supone la adaptación de la prueba general de compresibilidad de Flesch-Kincaid (que suena raro pero es bastante conocida en mediciones de la comprensibilidad de un texto), pero supuso una gran aportación al diseño software. No voy a entrar en su cálculo, ya que hay numerosos sitios donde lo explican.
Y ¿Por qué es tan importante y aún la citamos?
- Permite apreciar la calidad del diseño software, de una manera rápida y con independencia del tamaño de la aplicación. Es una medida esencial cuando necesitas “tomar la temperatura” de un diseño software (más si estás realizando una auditoría externa y no conocías de antes la aplicación) de un tamaño considerable, y que se puede obtener fácilmente y de manera automatizada (ver aquí, además los PMD, etc., la obtienen fácilmente).
- También la hemos utilizado para planificar proyectos de mejora de grandes productos software, para priorizar las partes del diseño a mejorar.
- Por otro lado, en muchas ocasiones, es base para calcular el valor de las mejoras del diseño, o el valor que aporta introducir un patrón o buena práctica.
- Y, además, nos da el número de casos de prueba unitarios básicos para obtener una cobertura del 100%.
- También una aproximación al grado de comprensibilidad del diseño.
De manera general es un síntoma que nos ayuda a determinar muchas de las posibles enfermedades del software, como sobre coste de realizar evolutivos debido a la rigidez del diseño, carencias modulares del diseño, diseños estructurados en entornos orientados a objetos, etc. Existe una relación entre el esfuerzo (horas – hombre, coste) necesario para mantener la aplicación y la complejidad de su diseño.
Si quieres puedes suscribirte al RSS del blog (¿qué es un RSS?)
Otras entradas relacionadas con esta:
November 4th, 2007 a las 3:21 am
La complejidad ciclomatica es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.
El valor calculado como complejidad ciclomatica define el numero de caminos independientes del conjunto básico de un programa y nos da un limite superior para el numero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.
1. V (G) = a – n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.
2. V (G) = r, siendo r el número de regiones cerradas del grafo.
3. V (G) = c + 1, siendo c el número de nodos de condición.
En mi opinión, veo que las pruebas son una de las etapas más importantes de la vida del software, no sólo porque se comprueba el correcto funcionamiento del sistema, sino porque es un mecanismo que ayuda al programador a saber si el sistema que ha realizado satisface las necesidades del usuario.
La fase de pruebas se considera una de las fases más difíciles sin embargo la mayoría de los programadores no le dan la importancia y no lo realizan de la forma adecuada.
El problema es en los sistemas que necesitan muchos casos de prueba para ejecutarse por ejemplo los sistemas de la NASA, los sistemas de aviones representan casos especiales donde debemos tener una certeza segura de la validez del programa, es en este tipo de aplicaciones donde las pruebas del software representan un factor fundamental para asegurar el correcto funcionamiento para cualquier situación.
En mi punto de vista, veo que la mejor forma de comprobar el software es crear además del sistema un programa que compruebe el propio sistema y así se facilite al programador la tarea que le considere difícil y aburrida,
Este programa que el programador va a crear ejecutara los diferentes casos de prueba del sistema y sacara los diferentes errores que han ocurrido, en que sentencia, en que caso, etc…
Y veo también útil utilizar las verificaciones formales que se usan paralelamente al desarrollo del software. El sistema formal de HOARE es un mecanismo que se aplica al programa que consta de una precondición P, una instrucción simple o compuesta (programa) S y una poscondición Q. P y Q son afirmaciones sobre los estados de programa.
Normalmente el equipo de desarrollo del proyecto se encuentra presionado por la necesidad de cumplir con las fechas establecidas y el proceso de pruebas no se cumple o se ejecuta de una manera desorganizada, sin método y sin considerar los tiempos establecidos para esta fase. El resultado es un software sin las pruebas mínimas requeridas y sin el nivel de calidad esperado.
Otra solución será contar con un grupo externo especializado en procesos de aseguramiento de calidad y específicamente en pruebas de software, que por medio de un método establecido y maduro, sin presiones políticas propias de la organización, pueda ayudar a alcanzar el nivel de calidad esperado del software y alcanzar el éxito del proyecto.
Entonces el aseguramiento de la calidad del software cada vez se convierte a una necesidad porque cada vez los errores en el software afectan de manera directa o indirecta en graves consecuencias para la organización.
Ouafae