Plan Calidad Ciclo 3 - Uniandes-MISO4203-backup/artwork-201620-2 GitHub Wiki

Plan de calidad

Objetivo

Definición de las estrategias basadas en la utilización de las métricas de SonarQueb para mejorar la calidad del código de software producido durante la ejecución del ciclo del proyecto.

Estrategia

Cada integrante del equipo tendrá la responsabilidad de seguir y cumplir durante el desarrollo de sus requerimientos con los perfiles de calidad definidos para la evaluación de la calidad del código en SonarQueb:

Perfiles Java

Perfiles JavaScript

Perfiles CSS

También deberá construir las pruebas de unidad y de servicios correspondientes a la funcionalidad en desarrollo. Con el fin de poder realizar el seguimiento continuo del cumplimento de los perfiles de calidad y las pruebas de unidad y servicios, es necesario que al finalizar el desarrollo de una tarea correspondiente al requerimiento en curso, los cambios sean integrados (merge) a la rama principal del proyecto en Github. De esta forma el sistema de integración continua, ejecutará las pruebas de Unidad y Servicios sobre el nuevo código fuente y posteriormente se podrán evaluar los perfiles de calidad por medio de SonarQueb.

El líder de calidad será el responsable de revisar cada vez que se realice un cambio sobre la rama ‘master’ del proyecto, que la herramienta de integración continua ‘Travis’ no esté generando errores, que las métricas de calidad generadas a partir de SonarQueb en ningún momento se degraden y que la deuda técnica nunca aumente, de encontrarse algún problema o “issue” nuevo que degrade la calificación, el líder técnico podrá resolver directamente el problema dentro del código o si él requiere el trabajo de la persona que desarrollo el código que generó el problema, creará una tarea en TeamWork relacionada a la corrección del código para superar el problema reportado.

Las métricas a tener en cuenta para la evaluación de al calidad del código son las siguientes:

###Métrica - Reliability Esta métrica corresponde a la confiabilidad del código y está basada en los tipos de errores (bugs) encontrados en el código. ###Métrica - Security Esta métrica corresponde a que tan vulnerable es el código a ataques de seguridad comprometiendo la información y su disponibilidad. ###Métrica - Maintainability Esta métrica corresponde a la facilidad con que el código puede modificarse para incluir nueva funcionalidad, modificar la ya existente, depurar errores, o mejorar el rendimiento ###Métrica - Duplications Esta métrica indica el porcentaje de código duplicado que podría evitarse la crear métodos o clases que lo incluyan. ###Métrica - Size Esta métrica es simplemente una estadística del tamaño del código fuente analizado, incluye líneas de código, líneas físicas, métodos, clases, archivos, directorios y palabras claves del lenguaje. ###Métrica - Complexity Esta métrica determina la complejidad ciclomática del código fuente dada por el análisis del número de caminos independientes dentro de un fragmento de código. El valor es calculado por cada función y su mínimo valor es 1, entre mas alto el valor mas complejo el código de entender. ###Métrica - Documentation Esta métrica indica en qué porcentaje el código fuente analizado se encuentra documentado. ###Métrica - Issues Esta métrica muestra el historial de evolución de las incidencias (Bugs + Vulnerabilidades + Code Smells) en el código. ###Deuda Técnica Corresponde Costo creciente en días a pagar por haber hecho implementado un código pobre.

##Estado de la evaluación de calidad del proyecto antes iniciar el ciclo 3 de desarrollo.