Estrategia del proyecto

Riesgos

1. Si el equipo no tiene un entendimiento suficiente sobre la arquitectura y las tecnologías del proyecto, entonces habrá retrasos, mala calidad en lo que se entrega y poca motivación del equipo.
2. Si el equipo no entiende los requerimientos, entonces se desarrollará una aplicación de mala calidad porque no va a satisfacer los requerimientos del cliente y todo el trabajo se perderá.
3. Si el equipo no trabaja de manera organizada y coordinada, entonces: el proyecto no cumplirá los requerimientos, tendrá retrasos importantes, mala calidad y el equipo no estará motivado.
4. Si algún miembro del equipo no cumple con las tareas que le fueron asignadas, entonces el trabajo de todos será retrasado y se afectará la calidad del producto.
5. Si la comunicación entre los miembros del equipo no es clara y directa, entonces habrán malentendidos que causarán desmotivación y entregas de mala calidad.
6. Si no se verifica correctamente la calidad del código desarrollado, entonces se dificultará la integración continua y probablemente se encontrarán errores inesperados que afectarán la calidad del producto entregado.
7. Si la diferencia entre las metodologías de trabajo de los integrantes del equipo es significativamente grande entonces se dificultará el trabajo en equipo y se dificultará consecuentemente la construcción de un producto de valor.

Estrategias de mitigación

1. Se promoverá una actitud positiva frente a dudas que surjan en cuanto a la arquitectura, herramientas y las tecnologías del proyecto, estableciendo espacios donde los miembros del equipo puedan expresar sus dudas y posiblemente obtener respuestas dentro del mismo.
2. En caso de que surjan dudas respecto a la arquitectura o las tecnologías del proyecto que ninguno de los miembros del equipo esté en capacidad de resolver, se distribuirán las tareas apropiadas para obtener una respuesta. Por ejemplo, se nombrará a un representante para buscar respuesta con los docentes.
3. Se plantearán reuniones para monitorear el desarrollo progresivo de la aplicación y garantizar que los requerimientos en desarrollo correspondan adecuadamente con los objetivos y alcance del proyecto.
4. Se realizarán pequeñas reuniones a momentos apropiados en las cuales las nuevas tareas y responsabilidades que surjan en el desarrollo del proyecto sean distribuidas de forma clara y organizada.
5. Los compromisos grupales serán comunicados por un medio de comunicación instantánea que permita mantener registro de los mismos al alcance de todos los miembros del equipo.
6. Al final de cada ciclo se realizará una actividad retrospectiva en la cual se analizarán posibles fallos de comunicación o trabajo en equipo que pudieron haberse tenido y se plantearán correcciones pertinentes.
7. Se deberá respaldar toda pieza de funcionalidad incorporada al proyecto con pruebas unitarias correctamente aprobadas.
8. Se buscará identificar constantemente que metodologías de trabajo son aquellas que permiten que los miembros del equipo presenten mejores resultados y se iterará a una siguiente metodología en caso tal de que alguna no de los resultados deseados.

#Arquitectura del proyecto [Arquitectura del Proyecto](Arquitectura del proyecto)

#Calidad del código actual El proyecto en sonar lo nombramos “artwork”, obtuvimos el siguiente resultado como resumen del análisis del código fuente inicial.

Con solo la información mostrada en el resumen de los resultados, podríamos concluir que el código fuente en análisis cumple parcialmente con los requerimientos mínimos de calidad, la métrica “Quality Gate” que determina si sobre el código fuente se detectaron problemas críticos que podrían comprometer su salida a producción, fue el nivel medio “Warning”.

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.
• No se encontró ningún error por lo que la calificación fue la más alta, tipo A.

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.
• Se encontraron 38 vulnerabilidades críticas (que deben ser solucionados lo antes posible), por lo que se obtuvo la una calificación baja D. El tiempo estimado para subir la calificación es aproximadamente 7 horas. Todas las 38 vulnerabilidades corresponden al mismo tipo “Use a logger to log this exception”, lo cual sugiere hacer manejo adecuado de las excepciones utilizando un mecanismo de registro o traza.

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
• Se encontraron 277 “Code Smells”, o síntomas de problemas de código, 40 críticas, 78 altas y 159 bajas. Aunque el número de incidentes es alto, no son determinantes para dar una calificación baja, por el contrario, esta métrica da una calificación A. La mejor

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.
• Se determinó que existe un 13% de código duplicado, en 115 bloques, 1,690 líneas y 55 archivos. No es un mal resultado, pero definitivamente se podría mejorar, lo cual ayudaría en gran medida su mantenibilidad.

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.
• El resultado es:
  • 12,377 Líneas físicas
  • 5,942 Líneas con código fuente
  • 1,923 palabras claves del lenguaje
  • 537 Métodos o funciones
  • 102 Clases
  • 104 Archivos
  • 20 Directorios

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 más complejo el código de entender.
• Partiendo del hecho que el valor 1 es el mínimo por método, el resultado obtenido de 1.3 es muy bueno, lo que indica un código simple fácil de seguir.

Deuda Técnica

• Entendiendo como deuda técnica: el costo creciente en días a pagar por haber implementado un código pobre, el valor calculado por SonarQueb utilizando el método Squale es 6 días, que corresponde a la suma de la deuda técnica cada uno de los Issues.