Informe final del proyecto
- Introducción
- Producto
-
Proceso
- Estrategia y herramientas usadas para tests
- Definición de hecho
- Estrategia para la construcción automática del software
- Estrategia de control de versiones
- Esfuerzos por persona y por actividad
- Diagramas de trabajo
- Velocidad del equipo
- Resultados de la retrospectiva
- Medidas que se llevarán a cabo para mejorar
- Conclusiones
- ANEXO I: Bocetos de GUI
En este documento se describe el informe final del proyecto Smart CampUZ, desarrollado por el grupo “lis16_g1” y recoge los resultados de sus sprints. En primer lugar, se va a realizar una descripción del proyecto junto con la descripción del equipo de desarrollo.
En segundo lugar, se va a hablar sobre el producto y su estado actual, enumerando así: el plan del producto, la planificación de los lanzamientos, un análisis de riesgos, la pila del producto en su estado actual, estado actual de la aplicación y vistas de la arquitectura del sistema.
En tercer lugar se van a desarrollar los detalles del proceso de desarrollo de la aplicación , es decir: estrategia y herramientas usadas para tests y cobertura de los tests automáticos implementados, definiciones de hecho, estrategia para la construcción automática del software, estrategia de control de versiones que se sigue, esfuerzos por persona y por actividades, diagrama de trabajo completado, velocidad del equipo, resultados de la última retrospectiva y cualquier otro aspecto relacionado con el proceso de trabajo y la gestión del proyecto, además de medidas que se llevarán a cabo para mejorar lo citado anteriormente.
En último lugar se va a realizar una conclusión del proyecto, además de un resumen de lo principal del documento y el grado de cumplimiento de cada objetivo de los indicados en la sección de evaluación del proyecto de la presentación de la asignatura.
Smart CampUZ es una aplicación web centrada en ser un "Smart Campus" del campus Río Ebro de la Universidad de Zaragoza. Se trata de un sistema de información y aplicaciones que da soporte a las distintas actividades y necesidades del campus universitario, más en específico a la gestión de reservas de aulas y la gestión de sugerencias o incidencias por parte de usuarios anónimos, profesores, personal de mantenimiento y administradores/gestores. La aplicación cuenta con un mapa interactivo del lugar, con el cual se puede interactuar para facilitar la localización/filtro de dichas funcionalidades.
El equipo del proyecto está formado por cuatro miembros: Rubén Moreno Jimeno, Iñigo Gascón Royo, Sergio Martín Segura y Catalin Constantin Dumitrache. Para el desarrollo de la aplicación se ha seguido la metodología Scrum, distribuyendo así los roles en:
- Dueño del producto: Rubén Béjar
- Scrum master: Sergio Martín
- Equipo de desarrollo: Rubén Moreno, Sergio Martín, Iñigo Gascón y Catalin Dumitrache
Dado que es un equipo multidisciplinar en el que cada uno de los miembros domina lenguajes distintos de programación, se ha decidido que cada uno de ellos se encargue de unos temas en específico:
- Rubén Moreno Jimeno: Front-end Developer, Configuration Manager, Graphical Designer, Testing Engineer.
- Iñigo Gascón Royo: Back-end Developer, Testing Engineer, Quality Assurance, Configuration Manager.
- Sergio Martín Segura: Back-end Developer, Testing Engineer.
- Catalin Constantin Dumitrache: Front-end Developer, Back-end Developer, Testing Engineer.
Smart CampUZ es una aplicación web centrada en ser un "Smart Campus" del campus Río Ebro de la Universidad de Zaragoza. Se trata de un sistema de información y aplicaciones que da soporte a las distintas actividades y necesidades del campus universitario. La aplicación cuenta con un mapa interactivo del lugar, con el cual se puede interactuar para facilitar la localización/filtro de incidencias, sugerencias y/o reservas.
Un usuario anónimo o un usuario de tipo profesor puede indicar sugerencias o incidencias, y reservar un aula durante un periodo de horas en una determinada localización del campus interactuando con el mapa, teniendo los profesores preferencia en la reserva.
Un usuario de tipo administrador puede ver y filtrar, gracias al mapa interactivo, todas las sugerencias del campus, así como gestionar el estado en el que se encuentran o asignar a un trabajador de mantenimiento a la incidencia que se desee. Además, puede aceptar o denegar la reserva de aula que haya realizado algún usuario previamente.
Por último, un usuario de tipo mantenimiento, puede ver las incidencias que tiene asignadas y filtrarlas mediante el mapa interactivo, así como indicar cuando una de ellas se ha completado.
- Lanzamiento del proyecto (2017/02/13 - 2017/02/22) Reunión de lanzamiento del proyecto en la que se han decidido los roles de Scrum a seguir por el equipo de desarrollo, definición del primer sprint, creación de la pila del producto inicial y la planificación de lanzamiento y grooming inicial de la pila del producto
- Primer lanzamiento - Primer Sprint (2017/02/23- 2017/04/06) Realización del primer Sprint del primer lanzamiento del producto, incluyendo únicamente los requisitos de iniciar sesión, visualizar dashboard, indicar feedback, listar y filtrar feedback, gestionar estado de feedback, y asignar trabajador a un feedback.
- Primer lanzamiento - Segundo Sprint (2017/04/07 - 2017/05/18) Realización del segundo Sprint del primer lanzamiento del producto y finalización del mismo, incluyendo las funcionalidades del primer sprint y las siguientes: listar incidencias asignadas a worker, indicar tarea hecha/problema, solicitar reserva de aula, mandar correo de confirmación, aprobar/denegar reserva de aula, y teselar el servicio de mapas WMS.
- Segundo lanzamiento (2017/05/18 - 2017/07/01) Realización del segundo lanzamiento, incluyendo las funcionalidades del primero y las siguientes: listar los feedback de una localización, solicitar cancelación de reserva de aula, y cancelación de reserva de aula.
Esta sección realiza un inventario de los riesgos potenciales del proceso de desarrollo más importantes. Anticipando lo que puede ocurrir, es posible mitigar el riesgo tomando las medidas oportunas. Los riesgos aplican directamente al proceso de desarrollo o tienen una consecuencia directa sobre el proceso de desarrollo. El registro y monitorización de estos riesgos continúa después de que se haya redactado este informe, ya que es un proceso continuo.
Los siguientes riesgos se han identificado para el proceso de desarrollo, con un total de 4 riesgos de nivel alto, y 2 de nivel medio:
| Nº | Evento | Consecuencia | Impacto (1-5) | Probabilidad (1-5) | Exp. al riesgo | Medidas | Responsable de tomar medidas |
|---|---|---|---|---|---|---|---|
| 1 | Falta de formación de los desarrolladores en el proceso. | Retraso en general en el proceso debido a una baja eficiencia de alguno de los miembros del equipo de desarrollo. | 2 | 3 | 6 | Establecer un periodo de aprendizaje para formar al equipo de desarrollo correctamente. | Todo el equipo de desarrollo. |
| 2 | Falta de uso, en la gestión del proceso, del uso de métricas e indicadores. | Falta del uso de métricas e indicadores para poder analizarlas y mejorar la gestión del proceso. | 4 | 2 | 8 | Realizar una recopilación y análisis de métricas del proceso durante la duración del mismo. | Todo el equipo de desarrollo. |
| 3 | Falta una herramienta de gestión de proyectos de software. | Falta del uso de herramientas específicas para la gestión del proyecto. | 4 | 2 | 8 | Buscar una herramienta específica para la gestión del proyecto adecuada al entorno actual. | Scrum Master. |
| 4 | Falta de formación del equipo en el uso de algunas herramientas. | Retraso en general en el proyecto debido a una baja eficiencia del equipo de desaarrollo. | 2 | 3 | 6 | Establecer un periodo de aprendizaje para formar al equipo de desarrollo correctamente. | Todo el equipo de desarrollo. |
| 5 | Novedad de la tecnología a construir en la organización. | Posibilidad de no finalización del proyecto. | 4 | 4 | 16 | Establecer un periodo de aprendizaje para formar al equipo de desarrollo correctamente. | Todo el equipo de desarrollo. |
| 6 | Creación de nuevos algoritmos para los requisitos. | Posibilidad de no finalización del proyecto. | 3 | 3 | 9 | Estudiar con detenimiento el comportamiento de los algoritmos a implementar. | Todo el equipo de desarrollo. |
| 7 | Creación de nuevos componentes para los requisitos. | Posibilidad de no finalización del proyecto. | 4 | 4 | 16 | Estudiar con detenimiento el comportamiento de los componentes a implementar. | Todo el equipo de desarrollo. |
| 8 | Personas que trabajan en múltiples proyectos. | Retrasos en las estimaciones realizadas en el proecto y posibilidad de no finalización del mismo. | 5 | 1 | 5 | Tratar de que el equipo de desarrollo no esté inmerso en múltiples proyectos o tenerlo en cuenta para las estimaciones. | Scrum Master. |
| 9 | El equipo de desarrollo no ha recibido la capacitación necesaria. | Posibilidad de no finalización del proyecto. | 4 | 4 | 16 | Encargarse de que el equipo de desarrollo reciba la capacitación necesaria de parte de los docentes de la asignatura. | Scrum Master y todo el equipo de desarrollo. |
El equipo de desarrollo, el Scrum Master, y el dueño del producto son conscientes de los riesgos y monitorizan las medidas adoptadas.
En la siguiente tabla se recoge el estado actual de la pila junto con los criterios de aceptación. Las pantallas mencionadas hacen referencia a los bocetos de GUI incluidos en el ANEXO I.
V Login (13)
- Esta funcionalidad estará accesible siempre desde el navbar.
- El usuario podrá introducir un email de un usuario ya registrado y una contraseña para completar el login y poder acceder a la aplicación.
- El usuario no podrá autenticarse en el sistema con un email de un usuario no registrado.
- El sistema comprobará que la contraseña introducida coincide con la contraseña del usuario.
- El sistema redirigirá a la pantalla de administrador, a la de mantenimiento, o se quedará en la actual, dependiendo de si se ha autenticado como un usuario tipo administrador, mantenimiento, o profesor respectivamente.
- Esta funcionalidad estará disponible como un modal que se abre desde el botón iniciar sesión en el navbar.
V Dashboard (8)
- El sistema siempre mostrará el mismo esqueleto en la pantalla de usuario independientemente de si ha iniciado sesión o no.
- El sistema siempre mostrará un mapa con el cual se puede interactuar para ayudar a las tareas de localización/filtrado en la mitad izquierda de la pantalla.
- El sistema siempre mostrará una lista de acciones asociada al tipo de usuario que se encuentre utilizándolo en la mitad derecha de la pantalla.
- El sistema siempre mostrará un navbar con el logo y al menos, la funcionalidad de inicio de sesión en la parte superior de la pantalla.
V Indicar feedback (8)
- El usuario anónimo y el usuario profesor podrán reportar feedback.
- El usuario podrá seleccionar una localización en el mapa, en la sección de la izquierda de la pantalla, para marcar la zona en la que quiere reportar feedback.
- El sistema mostrará siempre la localización que se tiene seleccionada del mapa para reportar feedback.
- El usuario no podrá reportar feedback sin haber seleccionado previamente una localización en el mapa.
- El usuario tendrá visible permanentemente una opción en la sección de la derecha de la pantalla que muestre un formulario para reportar feedback.
- El formulario constará de una descripción de texto que no puede ser nulo y un botón para enviar la información al sistema.
- El sistema mostrará un mensaje indicando si se ha realizado o no la petición y un breve texto explicativo.
V Listar y filtrar todos los feedback (8)
- El usuario administrador podrá listar y filtrar todos los feedbacks.
- El usuario administrador tendrá visible permanentemente una opción en la sección de la derecha de la pantalla que permitirá mostrar el listado de todos los feedback.
- El sistema mostrará inicialmente toda la lista de feedbacks sin aplicarle ningún filtro.
- El usuario administrador podrá seleccionar una localización en el mapa, en la sección de la izquierda de la pantalla, para filtrar la lista de feedbacks por localización.
- El usuario administrador podrá filtrar el listado con unas opciones, en la sección de la derecha de la pantalla, por el estado de los feedback.
- El sistema mostrará siempre la localización que se tiene seleccionada del mapa para filtrar feedback.
V Gestionar estado de feedback (5)
- El usuario administrador dispondrá de un listado con todos los posibles estados de cada feedback que aparecerán en la parte derecha de la pantalla, una vez que pulse un determinado feedback.
- El usuario administrador podrá asignar un estado a un feedback desde el menú que aparezca cuando pulse sobre un feedback existente.
- El sistema contendrá los siguientes estados disponibles para los feedbacks: Asignado, Aprobado, Hecho, Confirmado, Denegado, Notificado.
- El sistema dispondrá de una política interna que regulará las transiciones de un estado a otro, permitiendo únicamente las transiciones válidas.
- El usuario administrador podrá cambiar el estado de un feedback, desde el menú que aparece cuando pulse sobre un feedback de la lista de la derecha de la pantalla.
V Asignar trabajador a un feedback (5)
- El usuario administrador podrá asignar un trabajador existente en el sistema a un feedback cuando el estado del mismo es Asignado. Esto se hará desde la parte derecha de la pantalla, una vez que se pulse sobre un feedback.
- El sistema permitirá asignar un trabajador existente en el sistema a un feedback desde el menú que aparece una vez que pulse sobre un feedback en la parte derecha de la pantalla.
V Listar incidencias asignadas a worker (2)
- El sistema permitirá listar las incidencias que tiene asignadas un trabajador. Se mostrará un listado permanente en la parte derecha de la pantalla del trabajador
- El usuario trabajador dispondrá de una lista con las incidencias que se le asignan.
V Indicar tarea hecha/problema (3)
- El sistema permitirá que un feedback se almacene como finalizado, bien porque ha sido completado, o bien porque ha surgido un problema y no se puede arreglar.
- El usuario administrador podrá marcar el estado de un feedback como Hecho ó Notificado, indicando que ese feedback no se debería seguir procesando.
V Listar slots libres (8)
- El sistema permitirá listar las horas disponibles para su reserva de cada estancia sobre la que el usuario haga click.
- El listado incluirá tanto las horas disponibles como las que no se pueden reservar, diferenciándo las segundas (resaltándolas en color rojo) de las primeras.
V Ver reservas pendientes (5)
- El sistema permitirá mostrar en pantalla las reservas de aulas pendientes de aprobar o denegar mediante un sencillo listado.
- El usuario administrador podrá ver el listado de reservas pendientes desde la parte derecha de su interfaz.
V Solicitar reserva de aula (13)
- El sistema permitirá la reserva de aulas por parte de usuarios que dispongan de correo electrónico.
- El sistema dispondrá de una interfaz intuitiva en la mitad derecha de la pantalla donde el usuario tendrá disponible un sistema de calendario y horas para reservar un aula en el horario que desee.
- El sistema dispondrá de una política sobre horarios de apertura/cierre del campus en los que no se podrán reservar aulas.
- El usuario deberá hacer click sobre una estancia del campus para tener acceso al listado de horas disponibles para dicha estancia.
- El usuario deberá proporcionar su correo electrónico al igual que una descripción del uso que va a hacer de la estancia.
V Aprobar/denegar reserva de aula (8)
- El sistema deberá permitir al administrador aprobar/denegar solicitudes pendientes de reserva de aulas.
- El administrador deberá disponer de un listado con todas las solicitudes de reservas sin resolver.
- El sistema debe eliminar aquellas solicitudes de reserva de aula incompatibles con otra que acaba de ser aprobada por el administrador.
V Mandar correo de confirmación (1)
- El sistema deberá enviar un correo para notificar al usuario de la aprobación/denegación de una reserva tanto cuando el administrador apruebe/deniegue dicha reserva como cuando el administrador apruebe una reserva que es incompatible con otras.
V Teselar el servicio de mapas WMS (2)
- El sistema debe servir los mapas del campus mediante un servicio de teselado WMS.
El estado actual de la aplicación se puede ver en el siguiente documento: Estado actual de la aplicación.
Estos aspectos se pueden encontrar en este otro documento: Vistas del sistema.
Las pruebas realizadas para el sistema se han decidido lleva a cabo mediante tests automáticos unitarios y de integración. Para ello, se han empleado las herramientas JUnit 5 y MockMVC, proporcionadas por el framework SpringMVC. Mediante estos tests, se han probado tanto la API pública con las funcionalidades que se le ofrecen al cliente, como los servicios privados empleados por estas funcionalidades. Además, también se han probado los repositorios, entidades y objetos valor pertenecientes al modelo de datos del sistema.
MockMVC permite realizar peticiones REST a un endpoint de la misma forma que la haría el cliente desde el front-end. De esta forma, se realizan peticiones a cada uno de los servicios que se ofrecen para probar que todos y cada uno de ellos funcionan correctamente, no sólo con peticiones válidas sino, claro está, con todas aquellas que podrían dar problemas, probando así la gestión de errores de cada funcionalidad. Dado que MockMVC crea peticiones HTTP para enviarlas a un endpoint y Spring se ocupa del mapeo, los tests realizados con esta herramienta se consideran tests de integración.
Por otro lado, como se ha mencionado, se cuenta también con tests unitarios, en este caso todos aquellos que se ocupan de probar lo relativo a la persistencia del sistema, es decir, entidades, objetos valor y repositorios del modelo.
En relación a la cobertura de los tests que se han mencionado, se ha decidido integrar en el proyecto una nueva herramienta que permite, mediante un análisis del código, mostrar en cada estado del proyecto la cobertura del código en ese momento. Dicha herramienta es Codecov, la cual se ha integrado con GitHub, dándole acceso al repositorio para realizar el análisis tras cada commit y pull request. De esta forma, Codecov muestra si la cobertura del código ha aumentado, descendido o si sigue igual tras añadir el contenido que se incluya en dicho commit o pull request.
En el momento de la finalización del primer sprint se consiguió alcanzar un 64,59% de cobertura total del proyecto, como puede verse en las figuras X1, que muestra el estado del proyecto en ese momento, y X2, que muestra el progreso de la cobertura del proyecto a lo largo del sprint.
Figura X1. Cobertura del proyecto al final del primer sprint.
Figura X2. Gráfica del progreso de la cobertura del proyecto en el primer sprint.
Finalmente, tras finalizar el segundo y último sprint del primer lanzamiento del proyecto, la cobertura total del proyecto ha alcanzado el 71,56%, tal como se muestra en la figura X3. Además, en la figura X4 también puede apreciarse el avance de dicha cobertura tanto desde el comienzo del proyecto como del final del sprint anterior.
Figura X3. Cobertura del proyecto al final del primer lanzamiento.
Figura X4. Gráfica del progreso de la cobertura del proyecto durante el primer lanzamiento.
- Todo el equipo de desarrollo pre-verifica los criterios de satisfacción (10 minutos).
- El producto ha sido incluido en la rama master del repositorio de la organización y supera todos los test unitarios y de integración automáticos con TravisCI, siguiendo un Integration-manager workflow (10 minutos).
- Tanto código de producto como su API están correctamente documentados siguiendo los estándares definidos en el documento de estándares (10 minutos).
- El código del producto sigue los estándares de codificación definidos en el documento de estándares (5 minutos).
- Los nombres de las variables, métodos y clases tienen que ser mínimamente descriptivos, así como guardar una consistencia semántica entre las distintas capas de implementación si se refieren al mismo concepto.
Para la construcción automática del software se ha hecho uso de la herramienta Gradle. Esta herramienta es un sistema de construcción automático OpenSource que se basa en los conceptos de construcción de Apache Ant y Apache Maven, e introduce un lenguaje específico de dominio basado en Groovy (DLS) en lugar del formulario XML utilizado por Apache Maven para declarar la configuración del proyecto.
Se ha añadido la dependencia de un plugin de Spring llamado Spring-Boot-Starter, gracias al cual se consiguen unos despliegues automáticos de la aplicación con un simple comando (gradle bootRun), pudiendo elegir el puerto local a desplegar. Además, se ha añadido el plugin Spring-Boot-Devtools, el cual permite hacer auto-recargas cada vez que se realizan cambios en los ficheros binarios.
Se ha decidido usar esa estrategia de construcción, ya que se trata de una aplicación
Web. De esta forma se puede probar la aplicación desplegándola en un servidor de forma rápida y sencilla con tan solo un comando. La aplicación está configurada para que el comando gradle bootRun despliegue en la dirección “localhost:8090”. Todo ello resulta
especialmente útil a la hora de desarrollar o probar la aplicación Web, agilizando así el proceso
del feedback.
Por último se dispone de tres ficheros llamados "resetDB.sh", "dump.sh", y "geoconfig.sh" (estos dos últimos no están alojados en el repositorio de GitHub ya que contienen datos que no pueden ser compartidos por orden del centro universitario), los dos primeros han de ejecutarse la primera vez que se va a iniciar la aplicación para crear y poblar todas las bases de datos, el último ha de ejecutarse para instalar y configurar geoserver.
Dada la importancia de agilizar el proceso de desarrollo del proyecto, pero sin dejar de lado un buen control de versiones, se ha decidido usar la herramienta GitHub creando una organización llamada "smartCampUZ" y siguiendo un workflow tipo “Integration-manager workflow". De esta forma la organización posee un repositorio upstream al cual nadie puede hacer ningún tipo de push directo (salvo en excepciones y situaciones extremas). A su vez, cada miembro de la organización realiza un fork del upstream para tener su propio repositorio local y remoto. Los miembros de la organización van realizando sus cambios en local y haciendo push a su remoto. Cuando quieran integrar algo lo suficientemente interesante y estable al upstream realizan una pull request desde su remoto. Una vez hecha, dos miembros del grupo se encargan de revisarla, dar su aprobación, dejar feedback, o requerir cambios en la misma. Dicha pull request solo puede ser "mergeada" cuando los dos revisores han dado su aprobación, se ha hecho pull del upstream en la rama remota y resuelto los conflictos, y se han pasado con éxito los tests automáticos de TravisCI.
De esta forma se consigue mantener una frecuencia de trabajo paralela y rápida entre los miembros del grupo, una rama upstream lo más estable posible, y un control mínimo de que todo el trabajo integrado en la misma ha pasado una revisión y posee un grado de calidad aceptable.
Para la organización de los documentos y de la gestión del proyecto se han usado dos herramientas: Por un lado la plataforma de Google Drive, en la cual se ha mantenido un seguimiento de los documentos en formato pdf de las versiones finales entregables, y algunos datos que se querían mantener en privado, especialmente relacionados con la gestión. Se ha creado una organización en el directorio para que se pueda realizar una gestión adecuada del mismo siguiendo la siguiente estructura:
1_Gestión
2_Documentación producto
2.01_Informe de lanzamiento del primer sprint
2.02_Informe final del proyecto
Z_Otros
3_Documentación software
3.01_Análisis y diseño
3.01.01_Diagramas
3.02_Estándares
4_Multimedia
4.01_Logos
5_Presentaciones
Z_Cosas
Por otro lado, se ha utilizado la wiki de GitHub del repositorio principal de la organización Smart CampUZ en la cual se ha mantenido la documentación del producto constantemente actualizada por el equipo.
Esta sección permanece de forma privada, siendo interna de la organización. únicamente se incluirá en la entrega final del documento.
Como muestra el diagrama de burnup de la Figura X, durante las cuatro primeras semanas incluidas en el primer sprint no se pudieron completar ninguna de las entradas planificadas, principalmente debido al desconocimiento de algunas de las tecnologías involucradas en su funcionamiento. Además, el modelo de dominio de la aplicación también se fue discutiendo y refinando a lo largo de esas semanas, por lo que otras entradas que no requerían necesariamente de las tecnologías mencionadas también quedaron pendientes de desarrollo para semanas posteriores.
A lo largo de la quinta semana, se finalizó el Login del sistema, el cual había empezado a desarrollarse en semanas previas y se alargó debido a una de las nuevas tecnologías empleadas en su implementación y, principalmente, al refinamiento del modelo de dominio, que obligó a realizar ciertas modificaciones sobre éste. De esta forma, se completaron los primeros 13 puntos de historia del primer sprint.
En las dos semanas posteriores se finalizaron el resto de entradas pendientes, completando 13 puntos de historia más en la primera semana y los 21 restantes en la segunda, llegando así a los 47 PH totales que conformaban el sprint. Como ya se ha mencionado, la tardía finalización de estas entradas se ha debido al progresivo aprendizaje de las tecnologías necesarias que le eran desconocidas al equipo de desarrollo, así como al refinamiento del modelo de dominio. La semana final del sprint, habiendo finalizado las entradas de la pila previstas, se dedicó a realizar retrospectiva y la debida documentación.
Figura X. Diagrama de burnup del primer sprint.
Pasando a continuación al segundo y último sprint del primer lanzamiento, se puede observar en la Figura X2 que se han completado los 32 puntos de historia planificados al comienzo del sprint, dando así por finalizado el primer lanzamiento del proyecto.
Al igual que sucedió en el primer sprint, no se llegaron a completar ninguna de las entradas de la pila durante las 3 primeras semanas. No obstante, dado que esas semanas coincidieron con días no lectivos debido a la Semana Santa, se aprovechó para avanzar gran parte del trabajo previsto para el sprint y dejarlo listo para finalizarlo en unas pocas horas más.
Durante la cuarta semana se finalizaron dos de las entradas de la pila del sprint, completando así 6 puntos de historia de los 32 totales planificados. También durante esa semana se completó la integración entre el modelo y la aplicación de las entradas de pila restantes, que habían sido desarrolladas durante las tres semanas previas. No obstante, no se dieron por completadas dichas entradas de la pila debido a que faltaban los tests correspondientes a todas las funcionalidades implementadas e integradas.
Finalmente, durante la sexta semana, se completaron todos los tests de las funcionalidades mencionadas y se dieron por finalizadas las entradas de la pila, dando así por completados los 32 puntos de historia. La última semana, al igual que en el primer sprint, se empleó para redactar la documentación correspondiente al segundo sprint.
Figura X2. Diagrama de burnup del segundo sprint.
Por último, se presenta el diagrama de burnup correspondiente al primer lanzamiento del proyecto (Figura X3), el cual consta de los dos sprints ya explicados en esta misma sección. Tal y como se ha expuesto, se completaron hasta 47 puntos de historia durante el primer sprint y otros 32 más en el segundo, resultando por tanto en un total de 79 PH en el primer lanzamiento.
Figura X3. Diagrama de burnup del primer lanzamiento.
El equipo completó un total de 6 entradas de pila durante el primer sprint, lo que corresponde a 47 puntos de historia según las estimaciones realizadas durante la planificación. Por otro lado, durante el segundo sprint se completaron otras 8 entradas más de la pila, que según las estimaciones correspondían a 32 puntos de historia. En total, suman 14 entradas de pila y 79 puntos de historia para el primer lanzamiento.
Son estos datos los que se han tomado (47 y 32 PH) como velocidades del equipo para calcular la velocidad media de éste para cada sprint. Para ello, se ha calculado una distribución normal al 95% de confianza y se ha concluido que el rango de velocidades es de entre 24,5 y 54,5 puntos de historia (calculados como la media de los 2 datos +- la desviación típica [7,5]*2).
Teniendo en cuenta que la retrospectiva se realizó entre los cuatro miembros del equipo Scrum y, tomando como unidades de medida el 0, 1 y 2 (siendo el 0 un valor negativo y el 2 un valor positivo), se valoraron los siguientes aspectos del proyecto durante el primer Sprint:
- Se ha observado que el proyecto cuenta con la existencia de suficientes test unitarios automáticos. Al tener como requisito obligatorio de la asignatura la cobertura de al menos un 25% del código mediante tests unitarios automáticos, desde un principio la mayor parte del código que se ha desarrollado ha sido respaldado por sus respectivos tests, lográndo una cobertura actual del 65%. Por lo tanto, el equipo decidió valorar esta directiva con un 8/8.
- La métrica del diseño simple de la aplicación ha sido valorada con un 6/8 puesto que, aunque el equipo es consciente de que gracias a la constante refactorización que se ha ido haciendo, el diseño y estructura final del proyecto ha resultado bastante simple e intuitivo, no todos han coincidido en que se pueda seguir o entender a la perfección.
- Gracias al requisito de la asignatura que mencionaba que se debía seguir un sistema de nombrado adecuado e intuitivo, la métrica que adopta el mismo nombre ha obtenido una valoración del 6/8. El motivo por el cual no ha logrado la máxima puntuación es debido a que existe contradicción a lo largo tanto del código, como del informe sobre el término que representan los comentarios/sugerencias/incidencias que puede introducir un usuario en la aplicación; concrétamente, se emplean las palabras "feedback" o "report", ámbas refiriéndose a lo mismo.
- La métrica de una correcta y eficiente refactorización ha obtenido la máxima puntuación (8/8) puesto que se considera que globalmente, debido a las múltiples iniciativas de refactorización tanto del código como de la documentación, se han conseguido resultados satisfactorios que de otra manera no habrían sido posibles.
- Una de las métricas cuya puntuación ha resultado ser más negativa ha sido la propiedad colectiva: aunque no es un problema para el desarrollo del proyecto actual, se es consciente de que existe esta carencia en el equipo dado que cada miembro está especializado en una o varias tecnologías, sin dominar por completo todas las involucradas. Es por ello que esta métrica ha obtenido una puntuación de 1/10.
- En cuanto a la calidad de la documentación del diseño arquitectural, se ha obtenido un 7/8 puesto que los diagramas se han diseñado adecuadamente, en paralelo al desarrollo del código tanto para un mejor entendimiento del código como para detectar fallos arquitecturales.
- La métrica que indica la existencia y calidad de scripts para automatización del build ha obtenido un 5/8. Si bien es cierto que actualmente existen scripts tanto para la compilación, integración de dependencias y el despliegue de la aplicación, se carece de uno para la parte de Geoserver.
- Como la existencia y calidad de un control de versiones es requisito de la asignatura y debido a que previamente se ha trabajado en otros proyectos donde también era una parte fundamental, esta métrica ha obtenido la máxima puntuación (8/8).
- Al estar trabajando con Scrum, una métrica muy interesante es la de calidad y claridad de las historias de usuario. Se es consciente de que inicialmente se desconocía el alcance del proyecto y a consecuencia de lo anterior esta métrica ha obtenido un 6/8.
- Dado que no es requisito de la asignatura, la existencia y calidad de test de aceptación automáticos ha obtenido un 0/8.
- En cuanto a la estimación inicial de entradas de la pila, debido al desconocimiento de la tecnología relacionada con los mapas y por tanto del alcance y dedicación estimada del proyecto, esta métrica ha obtenido un 4/8. Si bien es cierto que las entradas independientes de todo lo que tuvo que ver con el mapa habían sido estimadas razonablemente bien, lo demás ha resultado en un considerable desajuste.
- Relacionada diréctamente con la métrica anterior, la estimación inicial de las tareas también ha obtenido una puntuación muy baja (3/8), por la misma razón que el punto anterior.
- La métrica referente a un ritmo de trabajo uniforme y repartido entre los integrantes ha obtenido una buena puntuación (7/8) puesto que se considera que el trabajo ha sido desarrollado de manera uniforme, siempre limitándonos a las restricciones impuestas por el desconocimiento de la tecnología relacionada con los mapas.
- La visibilidad del proyecto para todos los miembros del mismo ha sido otra métrica que ha obtenido una baja puntuación (3/8) debido a la falta de una herramienta o un proceso para la puesta en común de la visibilidad del proyecto. En muchos momentos, no todos los integrantes conocían el estado actual de la aplicación.
- En cuanto a la existencia, calidad y uso de un canal de comunicación, todos los miembros del equipo han concluído que tanto el grupo de Whatsapp del que disponía el equipo como el hecho de que los miembros del equipo coincidían físicamente todos los días en la universidad han hecho posible que la comunicación se lleve a cabo de una manera fácil y efectiva. No obstante, no se ha obtenido la máxima puntuación puesto que hubo ocasiones en las que algún miembro del equipo pasaba por alto ciertas menciones en el grupo de Whatsapp. Por ello, se ha valorado con un 7/8.
- Por último, la existencia, calidad y uso de herramientas Scrum ha sido valorada con la máxima puntuación (8/8) ya que el proceso Scrum se ha seguido rigurósamente. Además, para todas las fases del mismo se han empleado herramientas como el proyecto de Git, una aplicación móvil para estimar las tareas y entradas de la pila e incluso el uso de post-its para planificar el sprint y hacer grooming de la pila.
Teniendo en cuenta que la retrospectiva se realizó entre los cuatro miembros del equipo Scrum y utilizando el mismo sistema de autoevaluación que en el Sprint anterior, se valoraron los siguientes aspectos del proyecto durante el segundo Sprint:
- La propiedad colectiva, aunque durante este Sprint ha mejorado (pasándo del 1/8 a 3/8), sigue siendo un punto bajo para el equipo. No obstante, al igual que en el Sprint anterior, esto no resulta un problema ya que debido a la forma de trabajo autoimpuesta en el equipo, algunos integrantes conocen más algunas tecnologías y otros dominan más otras.
- Al igual que en el primer Sprint también, los test de aceptación han obtenido una valoración de 0/8 puesto que no son requisito y no se van a implementar. -Este segundo Sprint ha tenido la peculiaridad de que se ha desarrollado durante el segundo cuatrimestre del curso y por tanto la Semana Santa estaba justo en medio. Es por ello que durante esos días libres el equipo fue capaz de dedicarle mucho más tiempo al proyecto y por lo tanto la métrica de ritmo uniforme se ha visto afectada, pasándo de un 7 a un 6 sobre 8. No obstante, no es un factor negativo; el equipo fue capaz gracias a eso de terminar tareas en menos tiempo que en el Sprint anterior. Además, el ritmo del trabajo también se ha visto sesgado por la necesidad de los integrantes de avanzar con sus TFGs, al tratarse del último curso de la carrera.
- La visibilidad del proyecto pasa a valorarse en un 3 sobre 8 y viene relacionado con el punto anterior. Debido a los factores anteriormente mencionados, se mantuvieron menos reuniones que las del Sprint anterior lo que desembocó en algunas ocasiones en desconcierto acerca del estado del proyecto. No obstante, por el grupo de Whatsapp el equipo intentó actualizar más frecuentemente las tareas que se iban completando. Además, en este Sprint, se ha hecho un uso más estricto del tablero Kanban de GIT y por tanto en todo momento se veían reflejadas aquellas tareas en progreso, realizadas y por hacer.
Analizando los resultados del apartado anterior, durante la reunión de retrospectiva se decidieron las siguientes medidas para mejorar la calidad tanto del proceso Scrum como del proyecto en sí:
Nombrado:
Aunque el nombrado no ha obtenido una nota baja, sí se ha detectado un cambio necesario en algunos nombres con mismo significado, concretamente feedback y report, que se refieren a lo mismo.
Propiedad colectiva:
Se es consciente de que los miembros están especializados cada uno en una parte del proyecto y, dada la naturaleza del mismo, donde lo más adecuado es el modelo que se está siguiendo, no se proponen mejoras para solucionarlo.
Automatización del build:
Se ha detectado que falta una parte de la automatización. Concretamente, se trata de la instalación y despliegue de Geoserver. Se propone como mejora la creación de un script para la configuración automática de Geoserver.
Tests de aceptación automáticos:
El sistema no cuenta con tests de aceptación automáticos y no se proponen mejoras para incluirlos dado que no son requisito de la asignatura y no se cuenta con el tiempo necesario para realizarlos.
Estimación de entradas y tareas de la pila:
Pese a que se ha detectado que las estimaciones se han desviado del tiempo invertido en ellas, no se propone ninguna mejora dado que se deben al desconocimiento tanto de la arquitectura del sistema como de las tecnologías empleadas. Además, dada la naturaleza de la asignatura, se exige una refactorización constante durante el desarrollo del trabajo y se está obligado a seguir un ritmo de trabajo concreto puesto que los conocimientos iniciales de las tecnologías, que se han ido explicando a lo largo del sprint.
Visibilidad del proyecto:
La razón de una calificación tan baja en este apartado se debe a que en determinados momentos, no todos los miembros del equipo eran conscientes del estado actual del proyecto debido a una falta de feedback en las tareas que se iban realizando. Se propone como medida que el equipo se comprometa a actualizar periódicamente el tablero canvan del proyecto en GitHub. Además, como una medida alternativa se propone realizar una reunión semanal los lunes, presencial o por Skype, para responder preguntas del tipo: ¿Qué se ha hecho a lo largo de la semana? ¿Qué se va a hacer esta semana? ¿Alguna dificultad?
Las anteriores medidas corresponden al primer Sprint. El segundo no necesita una amplia explicación puesto que los puntos cuya valoración ha sido menor de la aceptada (tomando como un resultado razonable un 6/8) han tenido sus causas en circumstancias ajenas al equipo, debiéndose más al entorno de trabajo y las fechas en las que se ha desarrollado el proyecto. Como un posible aspecto de mejora sobre el segundo Sprint se podría considerar la realización de alguna reunión guía para dejar sentadas las bases sobre las tecnologías a usar en el proyecto y la instrucción de los integrantes en el desarrollo de prototipos con dichas tecnologías, que sirva de punto de inicio para un autoaprendizaje más fácil y sencillo.
Smart CampUZ es una aplicación web centrada en ser un "Smart Campus" del campus Río Ebro de la Universidad de Zaragoza. Se trata de un sistema de información y aplicaciones que da soporte a las distintas actividades y necesidades del campus universitario, más en específico a la gestión de reservas de aulas y la gestión de sugerencias o incidencias por parte de usuarios anónimos, profesores, personal de mantenimiento y administradores/gestores. La aplicación cuenta con un mapa interactivo del lugar, con el cual se puede interactuar para facilitar la localización/filtro de dichas funcionalidades.
En el primer sprint se han completado las seis entradas de la pila que se habían planificado, pasando todas ellas la definición de hecho establecida. Durante el segundo sprint, también se han completado las ocho entradas planificadas. Se ha llegado, por tannto, al primer lanzamiento del producto con todo el desarrollo planificado realizado. La velocidad del equipo es de entre 24.5 y 54.5 puntos de historia calculado con una distribución normal al 95%.
Se ha seguido un patrón de arquitectura hexagonal para el diseño del sistema y se han empleado numerosas tecnologías para la implementación del mismo. Se ha aplicado la técnica de Domain Driven Design pudiéndose apreciar elementos como Entidades, Objetos Valor, Servicios y Repositorios. El despliegue se hace en local de forma automática gracias al software empleado para la construcción automática de la aplicación. Para ello se ha empleado la herramienta Gradle junto con el plugin Spring-Boot-Starter. Dicho proceso incluye un cliente que se conecta con GeoServer, y paralelamente mantiene una conexión con el servidor de SpringBoot que a su vez se conecta con una base de datos PostgreSQL
Como estrategia para el control de versiones se ha decidido emplear git y su aplicación web GitHub, y se ha creado una organización específica para el proyecto. Además, se sigue un workflow de tipo "Integration-manager-workflow". Junto con esta herramienta se ha integrado otra más, en esta ocasión una de integración continua para verificar que la aplicación sigue compilándose y funcionando correctamente después de cada actualización del código. La herramienta empleada es TravisCI, y se ha hecho uso de ella también para la ejecución de tests automáticos. Para la documentación se ha empleado la wiki del repositorio de GitHub de la organización mientras se realizan los cambios en vivo y se mantiene actualizada, por otro lado también se ha empleado la herramienta de CVS Google Drive para mantener versiones entregables de la documentación en PDF de la wiki, así como algunos datos que no se quería que fuesen públicos, sobre todo los relacionados con la gestión.
Aprovechando las funcionalidades que ofrece GitHub, se ha hecho uso de su tablero para emplearlo como tablero de Scrum, junto con sus funcionalidades de issues y milestones, permitiendo una organización muy cómoda y útil del trabajo del equipo.
Durante la retrospectiva realizada tras la finalización del primer sprint, se han encontrado algunos defectos y/o carencias en el proyecto, la organización y el desarrollo del mismo que podrían mejorarse. Se han propuesto, por tanto, una serie de mejoras para aquellas carencias que se consideran importantes o que podrían suponer un problema en el futuro.
Finalmente, se ha implementado una batería de tests unitarios y de integración automáticos con las herramientas MockMVC y JUnit 5 para el código de la API y la BBDD. Dichos tests se ejecutan en TravisCI cada vez que se hacen cambios en el código y cubren un total de 71.56%.
En esta sección se va a indicar explícitamente el grado de cumplimiento de cada objetivo de los indicados en la sección de evaluación de la presentación de la asignatura.Se van a enumerar todos los puntos mínimos, de notable, y de sobresaliente, indicando si se cumplen o no para poder sacar una conclusión de la nota a la que se quiere optar.
Mínimos
- El código del proyecto se encuentran alojados en el repositorio https://github.com/UNIZAR-30249-2016-SmartCampUZ/smartCampUZ y todo el trabajo de la aplicación ha sido desarrollado sobre él pudiéndose observar en las gráficas. Para la documentación se ha ido utilizando la wiki del repositorio mencionado https://github.com/UNIZAR-30249-2016-SmartCampUZ/smartCampUZ/wiki.
- Para la compilación y gestión de dependencias se ha utilizado la herramienta Gradle, y se puede ver en el fichero https://github.com/UNIZAR-30249-2016-SmartCampUZ/smartCampUZ/blob/master/build.gradle.
- Se ha llevado un control de esfuerzos continuo en el apartado "1_Gestión" de la plataforma Google Drive y se puede ver que se han ido realizando todas las entregas mensualmente en el moodle de la asignatura.
- Como se puede ver en el apartado Pila de producto en su estado actual, la aplicación cumple adecuadamente con sus requisitos.
- La documentación arquitectural es la adecuada al momento del proyecto, refleja fielmente el sistema, e incluye las tres vistas exigidas: módulos, componentes y conectores, y despliegue del sistema. Se puede comprobar en el apartado Arquitectura del sistema y aspectos interesantes sobre la implementación y el despliegue.
- La arquitectura del sistema es hexagonal como se puede apreciar en el orden de las capas en la sección Arquitectura del sistema y aspectos interesantes sobre la implementación y el despliegue, en la cual se puede ver que, por ejemplo, la capa de infraestructura queda arriba, en medio la de aplicación y abajo la de modelo.
- Se usan adecuadamente los conceptos de entidades, objetos valor, agregados, fatorías y respositorios como se pueden ver en el apartado Arquitectura del sistema y aspectos interesantes sobre la implementación y el despliegue.
- Se ha puesto en marcha y se usa un servicio de mapas tipo WMS con los edificios disponibles del campus Río Ebro. Los mapas de este servicio se superponen en el cliente sobre el servicio externo de Open Street Map utilizando la herramienta Leaflet.js que proporciona un mapa de la zona. Esto se puede ver en la pantalla Estado actual de la aplicación.
Notable
- Se ha conseguido una cobertura de código con tests automáticos de más del 25%, en concreto un 71.56%. Esto se puede comprobar en el apartado Estrategia y herramientas usadas para tests, y además, gracias al badge de la herramienta Codecov, en el readme del repositorio: https://github.com/UNIZAR-30249-2016-SmartCampUZ/smartCampUZ.
- El modelo de dominio utiliza adecuadamente los servicios, paquetes, interfaces reveladoras, aserciones, funciones libres de efectos secundarios, y se puede comprobar en el package model del código del proyecto.
- El estilo cartográfico de los edificios en el servicio de tipo WMS refleja el tipo de uso de cada espacio pudiéndose ver en la pantalla Estado actual de la aplicación.
Sobresaliente
- La funcionalidad obligatoria elegida es la cuatro, como es puede ver en el apartado Pila de producto en su estado actual.
- La arquitectura del sistema es hexagonal como se puede apreciar en el orden de las capas en la sección Arquitectura del sistema y aspectos interesantes sobre la implementación y el despliegue, en la cual se puede ver que, por ejemplo, la capa de infraestructura queda arriba, en medio la de aplicación y abajo la de modelo.
- El servicio de mapas de WMS se ha teselado, y se usa así desde el cliente, como se puede ver durante la ejecución de la aplicación y en la página de la wiki Teselado.
El anexo I se encuentra contenido en el documento: Bocetos de GUI.