Tips Sonar: Cálculo manual del porcentaje de las violaciones.

Si nos fijamos en el panel de control del Sonar podemos observar como uno de los widgets que nos muestra es el número de violaciones que incumplimos.

Sonar Apache Lucene. Widget violaciones.
Sonar Apache Lucene. Widget violaciones.

NOTA:  Imagen del proyecto: http://nemo.sonarsource.org y como ejemplo el tablero de la aplicación Apache Lucene.

Estas violaciones son el resultado de incumplir algunas de las reglas que tenemos definidas en nuestro perfil de calidad. Son las reglas que normalmente tenemos definidas para las tres herramientas de análisis de código estático que utiliza el Sonar:

Bueno, si volvemos al widget de violaciones, podemos observar como:

Violaciones Sonar
Violaciones Sonar
  • Nos indica el número total de violaciones.
  • El tanto por ciento de reglas que cumplimos.
  • Y luego organizadas por categorías: blocker, crítical, major, minor, info el número de violaciones que tenemos de cada tipo.

Lo que voy a explicar a continuación, es como se calcula el porcentaje de cumplimientos de reglas.

Hay que partir de cada categoría de violaciones tiene asignada un peso. Esto se puede ver en la configuración del Sonar: System | General Settings  | General.

configurarpesoviolacionessonar

Como podemos ver:

INOF=0;MINOR=1;MAJOR3;CRITICAL=5;BLOCKER=10

Y el tanto % se calcula en función de la siguiente formula:

Porcentaje_violaciones_tipo_xxxx = nº_violaciones_tipo_xxxx * peso_violaciones_tipo_xxxx / nº líneas total

Por tanto, vamos a ver como en nuestro ejemplo como se obtiene el 75,8% que muestra la figura .

En primer lugar multiplicamos el número de violaciones por el peso correspondiente en cada categoría:

0 * 10 +
6 * 5 +
6.208 * 3 +
0 * 1 +
816 * 0
= 0 + 30 + 18624 + 0 + 0 = 18654

Y este valor lo dividimos para el número de lineas: 77.087

18.654/77.087=24,1986% aproximadamente 24,20%.

Es decir, incumplimos un 24,20% de reglas lo que supone que tenemos un 75,8% de reglas correctas. Esto nos permite también calcular el porcentaje por categoría, etc.

¿Y todo esto para que nos sirve? Nos permite conocer el peso de las violaciones por categorías en el computo global. Normalmente cuando se establece una perfil de calidad, se establece unos valores mínimos que se deben cumplir

  • Puede ser que nos pidan que las blocker y crítical deban ser 0 y que el porcentaje global debe ser del 85%. ¿cuantas bloqueantes podríamos tener como máximo para llegar al 85%?
  • Puede que nos pidan que las bloqueantes no pasen del 0,2% del total.
  • Y nos puede servir para establecer estrategias optimas de limpieza de código de manera que con menos esfuerzo cumplamos un mayor número de reglas.

En cualquier caso, lo mejor es  no generar violaciones y gestionar el tema desde el inicio. Cuando se dejan estas cosas para el final en un proyecto muy grande el proceso es laborioso. Ademas parece muy poco profesional:  ¿que pasa? ¿solo sabemos programar bien al final?.

Si fuese el cliente y gestionase el cumplimiento de las reglas, más que la situación actual miraría la evolución de dichas reglas y exigiría que desde un principio se mantuviese a un nivel aceptable.  Poca confianza me produciría un código que se siempre esta alrededor del 75% y que de repente en pocos días pasa al 85%/90% ¿que o parece?.

NOTA: Gracias a Guillerme Iglesias que me explico el otro día estos cálculos, precisamente para saber si cumplíamos con los requisitos del cliente.

Tips Sonar: Cálculo manual del porcentaje de las violaciones.

Ecosistemas de desarrollo de software: lineas de automatización.

Todo este tema de los Ecosistemas de Software y la Integración Continua me encantan y me fascinan.

Se por experiencia que la mayor parte de los problemas y retrasos que se producen en los proyectos actuales es por no poner cuidado y el suficiente cariño en estos temas. No se les da la importancia adecuada y luego pasa lo que pasa.

  • Se puede llegar a estar hasta varios días sin poder realizar el build del proyecto.
  • Los errores y problemas se detectan demasiado tarde, lo que multiplica exponencialmente el coste de su solución.
  • Las modificaciones y correcciones no producen más que nuevos errores que, como indico en el punto anterior, se detectan tarde.
  • Los programadores tardan horas en desarrollar sus tareas por trabajar en un entorno poco optimizado.
  • Los programadores se desmotivan, se van del proyecto, con la perdida de conocimiento que ello implica en algunos casos.
  • Se pierde una cantidad enorme de horas en procesos manuales facilemente automatizables.
  • Se produce un “proceso de involución en el proyecto” en el que parece que este empeora en lugar de mejorar. Digo “parece” porque realmente no solemos tener herramientas fiables y “sinceras” que nos proporcionen la situación del proyecto. He puesto la palabra “sincera” a propósito, porque en la mayor parte de las ocasiones, quien proporciona esta información es una persona que miente descaradamente.
  • El proyecto se llenan de auditores y “tecnocratas” que con sus Word, Excel y Projects intentan solucionarlo. Y entonces se pieder el norte, ya no se sabe si el objetivo es el proyecto, o todos los informes que debes pasar a estas personas… que cuestan un montón de horas y dinero.
  • Etc, etc, etc…

Y si,  estoy convencido que muchos de estos problemas se podrían evitar si se decidises invertir tiempo en estos temas:

Ecosistema de software

 Un ecosistema de desarrollo software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

Integración continua

La integración continua es una práctica en el desarrollo de software que consiste en poner en común todos los cambios que afecten al resultado final de nuestro proyecto de una forma frecuente con el objetivo de ver la evolución de sus efectos.

Automatización

Y en la automatización  de estas 5 líneas que se suelen recomendar para conseguir un nivel óptimo de madurez en el desarrollo de software:

  • Build (compilación, empaquetado y distribuibles)
  • Automatic Documentation Generation
  • Testing
  • Continuous Inspection
  • Continuous Deployment

De todo esto es de lo que nos habla Manuel Jesús Recena Soto en esta estupenda presentación que realizo el pasado 14 de Febrero como ponente invitado al Máster de Ingeniería y Tecnologías Informáticas que se imparte en la Universidad de Sevilla.

Ecosistemas de desarrollo de software: lineas de automatización.

22 pequeñas reflexiones sobre la gestión y el desarrollo de proyectos

22 “pequeñas” reflexiones sobre la gestión y el desarrollo de proyectos.

  • La calidad es el aliado de la planificación, no su adversario. Si sacrificamos la calidad por la planificación lo estamos haciendo mal
  • “El software y las catedrales son muy similares. Primeros los construimos, después rezamos”, Sam Redwine.
  • No existe calidad del software sin satisfacción del usuario.
  • “Los buenos programadores utilizan sus cerebros, sin embargo las buenas prácticas nos permite no tener que pensar en todos los casos”.
  • La documentación se convierte en un problema cuando se convierte en un factor externo al desarrollo, como si fuera un elemento independiente.
  • Testing, ¿hasta donde?. Es difícil definir cual. obj. en este proceso sin llegar a la elim. de todos los err, algo que resulta imposible
  • Testing, ¿hasta donde?. No existe relación entre el tamaño del error y los problemas que causa.
  • Testing, ¿hasta donde?. Cohete de 18 mill. de dolares había sido destruido en vuelo debido a un simple guión que faltaba en un programa.
  • Los departamentos de calidad del software requieren una comunicación continua y fluida con los departamentos de desarrollo.
  • La documentación debe acompañar el desarrollo de software, ser parte de él. Debe servir al proyecto y no ser un obstáculo en el mismo.
  • No hay nada que justifique que el software se tenga que ir deteriorando conforme se van realizando tareas de mantenimiento con el mismo.
  • “Un programador trabaja para un resultado libre de errores; un tester, para encontrarlos”, Moses Oliver,
  • “La estructura de un sistema software refleja la estructura de comunicación del equipo que lo ha desarrollado”, Richard E. Fairley.
  • Cometer errores en el desarrollo de software es algo natural. Lo importante no es no equivocarse sino detectar los errores a tiempo.
  • “Copiar y pegar código de Internet en el código del programa es como masticar chicle que has encontrado en la calle”, Mike Johnson,
  • La detección de errores, lo más próxima posible a su origen, ahorra dinero.
  • Un programa que no funciona es incorrecto; pero un programa que funciona no es necesariamente correcto: difícil de mantener, entender ..
  • El origen de la sabiduría de un desarrollador se basa en conocer la diferencia entre un programa que funciona y un programa correcto,
  • Uno de los principales problemas con que se encuentran los equipos de testing es que se consideran obstáculos,
  • Los testers son desarrolladores de software, son una pieza más dentro del equipo, hacen otro tipo de trabajo, pero de gran importancia.
  • “El código no existe hasta que se sube a un repositorio de fuente”, Jeff Atwood
  • Escribid el código para que os entiendan otras personas, no sólo para que os entienda la máquina.
Y mucho más en: http://jummp.wordpress.com/
22 pequeñas reflexiones sobre la gestión y el desarrollo de proyectos