Documento resumen Sprint nº4
- La asignación de dichas historias de usuario es la que se muestra al final de la página principal de la wiki de Github.
- Hemos creado una sola tarea y rama para implementar la funcionalidad que se indica en cada historia de usuario.
- Para implementar el código hemos utilizado la metodología de programación por parejas. De esta forma mientras un miembro de la pareja programaba el otro integrante observaba el proceso para detectar el máximo nº de errores posibles durante el desarrollo.
- Las respectivas pruebas unitarias que se han añadido, han sido realizadas por la pareja que implementaba la funcionalidad correspondiente que explica la historia de usuario.
- Se han terminado de implementar las funcionalidades restantes y se han realizado todas las pruebas restantes de las mismas.
- De la misma forma que con las pruebas unitarias, las pruebas de rendimiento y sus respectivas ejecuciones (test de carga y estrés) han sido realizadas por la pareja que tenía asignada la historia de usuario correspondiente a esa prueba de rendimiento.
- La documentación correspondiente al rendimiento, "profiling" y refactorización ha sido realizada en grupo. Cada miembro se encargaba de una parte de los mismos como por ejemplo: análisis de los resultados de las pruebas de rendimiento, redacción de la documentación, realización de las refactorizaciones, análisis del "dashboard" de SonarQube, etc.
P1: Francisco Antonio Arroyo Aponte y Francisco Javier Romero González-Regueral
P2: Alejandro Blanco Pérez y Carlos Cruz Martínez
P3: Adrián Fernández Fernández y Maria de Gracia Piñero Pastor
- Para llegar al nivel de 6 puntos hemos realizado las pruebas de rendimiento para cada uno de las 25 historias de usuarios que tenemos. (Se ha usado Notepad ++ para la edición de los scripts obtenidos de la herramienta Gatling)
Para cada prueba se realizó la grabación con Gatling y posteriormente se editaba el script obtenido para seguir el mismo formato que se explicaba en el contenido téorico (separar cada petición en objetos, especificar dos escenarios, etc)
Tras dicha edición primero se ejecutaba un test de estrés para comprobar donde se producía el "cuello de botella" en la aplicación cuando había un número elevado de usuarios. En todos los casos dicho cuello de botella se producía en la CPU.
En segundo lugar se realizaba un test de carga, utilizando un número de usuarios que permitiese a la aplicación funcionar correctamente. Este dato se sacaba de los usuarios que aguantaba la aplicación en el test de estrés antes de que se empezasen a perder peticiones.
Finalmente redactamos un documento con todos los datos obtenidos en las diferentes ejecuciones de las pruebas para historia de usuario, diferenciando entre los test de carga y los de estrés.
- Para llegar al nivel de 8 puntos hemos realizado el "profiling" de tres historias de usuario que considerábamos que tenían un peor rendimiento (basándonos en los resultados del apartado anterior) para cada tipo de petición principal (GET,POST y UPDATE). Las historias de usuarios seleccionadas fueron: HU01, HU07 y HU25. Para realizar el "profiling" utilizamos la herramienta de Glowroot. Para cada historia de usuario, mientras Glowroot estaba capturando el tráfico de la aplicación, ejecutábamos un test de carga con Gatling para obtener los datos del rendimiento de la aplicación en esas situaciones. Una vez ejecutado el test se analizaban distintos datos que ofrece la herramienta de Glowroot, haciendo especial hincapié en el tiempo que tardaban las "queries" en ejecutarse, en el tiempo medio de ejecución y en las trazas lentas de la aplicación.
Una vez realizado este proceso para las tres historias de usuario se documentó los datos obtenidos y se realizó el análisis de los mismos.
Con respecto a la refactorización para completar este objetivo hemos realizado refactorizaciones para 6 tipos de Code Smells distintos. Nos ayudamos de la herramienta de SonarCloud y del contenido teórico para detectar dichos Code Smells.
- Para llegar al nivel de 9 puntos hemos realizado una refactorización para mejorar el rendimiento de la aplicación. Tras el "profiling" realizado en el apartado anterior consideramos que la historia de usuario que tiene mayor margen de mejora es la HU01. Para mejorar su rendimiento hemos implementado caché en la sección de buscar y filtrar productos en la aplicación.
Tras implementar esta mejora realizamos otro análisis con Glowroot para comparar los resultados obtenidos con los del apartado anterior. Dichos cambios y los resultados del análisis fueron documentados para dejar constancia de los mismos en la documentación de la entrega.
Adicionalmente realizamos un segundo análisis con SonarCloud para contrastar las mejoras obtenidas tras aplicar la refactorización de los 6 tipos de Code Smells mencionados en el apartado anterior.
Los cambios de código y los resultados aportados por SonarCloud fueron documentados para dejar constancia de los mismos en la documentación de la entrega.
El Cuarto Sprint se ha desarrollado según lo previsto, terminando todos el contenido entregable antes de la fecha de final. Hemos tenido diversos problemas con el uso de las herramientas de análisis de rendimiento ya que era la primera vez que trabajábamos con ellas. A su vez como el concepto de "rendimiento" en una aplicación no era muy conocido por el equipo hemos tenido dificultades a la hora de entender cuales eran los elementos más importantes a la hora de realizar los análisis. También cabe remarcar que debido a la carga de trabajo de otras asignaturas y la situación actual, el trabajo no ha sido muy constante y hemos tenido que dedicarle mucho tiempo casi al final de la entrega. Sin embargo, como se comenta al principio hemos conseguido llegar a la fecha de entrega sin ningún problema.
Pareja 1 Miembros: Francisco Javier Romero González-Regueral (25) y Francisco Antonio Arroyo Aponte (25)
Esta pareja ha realizado un esfuerzo total de 50 horas.
Análisis retrospectivo de la Pareja 1 sobre el primer Sprint:
Que seguir haciendo: Los análisis de rendimiento de otras funcionalidades ya que permiten conocer que aspectos se pueden mejorar en el código que implementamos.
Que dejar de hacer: Dejar el trabajo para el final del Sprint ya que produce que se acumule el mismo.
Que empezar a hacer: Concretar un horario que sea cómodo para los dos integrantes de la pareja para evitar tener que trabajar por separado.
Pareja 2 Miembros: Carlos Cruz Martínez (19) y Alejandro Blanco Pérez (19)
Esta pareja ha realizado un esfuerzo total de 38 horas.
Análisis retrospectivo de la Pareja 2 sobre el segundo Sprint:
Que seguir haciendo: Mantener el ritmo de trabajo actual, con la buena calendarización realizada hasta el momento.
Que dejar de hacer: Dar por finalizadas partes del desarrollo sin revisar el formato del código, provocando que algunas partes no estén bajo el formato común del grupo y dificultando la legibilidad del mismo.
Que empezar a hacer: Llevar la teoría a aplicar durante la sesión vista de forma previa a la misma para maximizar la eficacia del tiempo invertido en el desarrollo y no invertir una parte del mismo en revisar el contenido subido.
Pareja 3 Miembros: María de Gracia Piñero Pastor (12) y Adrián Fernández Fernández (11)
Esta pareja ha realizado un esfuerzo total de 23 horas.
Análisis retrospectivo de la Pareja 3 sobre el segundo Sprint
Que seguir haciendo: Preveer un tiempo "de colchón" para imprevistos, por si aparece algún problema que nos ocupe más tiempo del esperado, poder solventarlo y llegar a tiempo al "Milestone"
Que dejar de hacer: No consultar a los compañeros cuando nos quedamos atascados en un problema. Esto solo ralentiza la implementación del proyecto.
Que empezar a hacer: Desglosar y planificar la implementación de las funciones para una mejor organización y eficiencia.