Primeros meses con Sonar: El software se deteriora con el mantenimiento

Hace poco implantamos Sonar en nuestra organización con el objetivo de ir controlando la calidad del software que se nos iba entregando, ya que estamos bastante preocupados por la mantenibilidad del software, algo que todavía se acusa más en épocas como la actual donde cada céntimo de euro importa.

Una de las principales curiosidades que tenía era observar a través de las métricas que ofrece Sonar si efectivamente, desde el punto de vista de la complejidad y de la mantenibilidad del software, la realización de sucesivos mantenimientos correctivos y evolutivos empeoraba dichos indicadores, tal y como establece la teoría, así como multitud de estudios empíricos realizados sobre la materia.

Pese a que haría falta más tiempo para poder tener una mayor cantidad de datos y no he entrado en detalle en todas las métricas, se puede empezar a concluir que efectivamente en la mayoría de proyectos donde se han realizado tareas de mantenimiento correctivo y evolutivo se han empeorado indicadores. Hay excepciones, ya que en algunos casos existen métricas que han mejorado y otros en las que prácticamente conservan sus valores.

Las principales métricas que se han visto empeoradas han sido: LCOM4, líneas duplicadas, la complejidad ciclomática y los comentarios de las APIs públicas. Resulta en cierto modo lógico que se incremente la complejidad ciclomática, ya que ésta depende directamente del tamaño del código. Si hubiéramos tenido unos valores de cobertura de código aceptables, podrían haberse extraido conclusiones también sobre esta métrica, algo que no ha sido posible, porque como comenté en otro artículo, la mayoría de las aplicaciones que tenemos no bienen acompañadas de pruebas unitarias y por tanto no es posible bajar del 0%.

Por tanto, la deuda técnica lejos de reducirse, se está incrementando, lo que provoca que el software sea cada vez menos mantenible y en consecuencia cueste más realizar modificaciones en el mismo y exista una mayor probabilidad de que el software se entregue con errores.

Nuestra intención con Sonar, no es ser espectadores de sus métricas, sino con el paso del tiempo exigir que el software que se entregue alcance unos umbrales mínimos en las principales métricas, tanto en desarrollos nuevos como en mantenimientos, ya que si no controlamos no conseguiremos mejorar y reducir nuestros costes de mantenimiento y el número de errores del software que llegan a la fase de pruebas o a producción.

2 comentarios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: