LestonOtero_Laura_TFG_2022

Vista previa del material en texto

Facultade de Informática
TRABALLO FIN DE GRAO
GRAO EN ENXEÑARÍA INFORMÁTICA
MENCIÓN EN ENXEÑARÍA DO SOFTWARE
Plataforma software para el mantenimiento
de rutas
Estudante: Laura Lestón Otero
Dirección: Fernando Bellas Permuy
Sergio Rodríguez Ezquerra
A Coruña, febreiro de 2022.
A mis trapecios
Agradecimientos
Gracias a mi familia por creer en mí y a mis amigos de la facultad por haber sido un apoyo
tan grande estos años.
Resumen
Este proyecto tiene por objetivo el diseño e implementación de una plataforma software
para una empresa de mantenimiento de rutas y naturalización del paisaje.
Para ello se pretende desarrollar una aplicación móvil que permita a los trabajadores de
la empresa registrar las rutas que van a realizar sobre los lugares que precisen un manteni-
miento, y reportar incidencias a medida que las recorren en aquellos puntos que necesiten
posterior supervisión. Esta aplicación deberá estar preparada para funcionar en entornos sin
conexión a Internet.
Además, se desarrollará una aplicación web moderna Single Page Application (SPA) con
fines administrativos, que permita gestionar las rutas creadas anteriormente, así como los
elementos sobre los que se realizará un mantenimiento y las posibles categorías de las inci-
dencias.
En cualquiera de las dos aplicaciones se permitirá la generación de un archivo PDF con la
información de la ruta recorrida y las incidencias registradas.
Ambas aplicaciones compartirán un mismo backend, que consistirá en una API REST im-
plementada en lenguaje Java, utilizando SpringBoot junto con Hibernate y JPA, yMySQL para
la persistencia de datos.
Para la parte frontend, en aplicación web se hará uso del framework Angular con TypeScript
como lenguaje, y para la aplicación móvil se utilizará esto mismo junto con el framework
Ionic.
Abstract
This project aims to implement and design a software platform for a route and landscape
maintenance company.
To achieve this, we will develop a mobile application that will allow the workers of the
company to register the routes through the places that they are going to maintain, and report
issues at the points that will need later supervision. This application must work in offline
environments.
Additionally, we will develop a modern Single Page Application (SPA) web application
with administrative purposes, that will allow us to manage the routes created previously, as
well as the elements that need maintenance and the categories for the issues.
In either one of them it will be possible to generate a PDF file with the route information and
the reported issues.
Both applications will share one backend, whichwill consist on anAPI REST implemented
in Java language, using the SpringBoot framework along with Hibernate, and MySQL for data
persistence.
Regarding the frontend, for the web application we will use Angular as a framework, and for
the mobile app we will use both Angular and Ionic. The two of them will use TypeScript as
programming language.
Palabras clave:
• Ruta
• Ruta de entidad
• Ruta de punto-a-punto
• Evento
• Entidad de mantenimiento
• Tipo de entidad
• Single Page Application
• API REST
• Java
• SpringBoot
• MySQL
• Angular
• Ionic
• Framework
• Capacitor
Keywords:
• Route
• Entity route
• From-to-route
• Event
• Entity item
• Entity type
• Single Page Application
• API REST
• Java
• SpringBoot
• MySQL
• Angular
• Ionic
• Framework
• Capacitor
2
Índice general
1 Introducción 1
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Visión global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Metodología 5
2.1 Metodología ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Qué es Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Roles en Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4 Eventos Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Adaptación de Scrum para el proyecto . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Análisis global de requisitos 11
3.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Funcionalidades de la aplicación web . . . . . . . . . . . . . . . . . . . 14
3.2.3 Funcionalidades de la aplicación móvil . . . . . . . . . . . . . . . . . . 18
4 Planificación 21
4.1 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Sprint 0 - Creación de la estructura base del proyecto . . . . . . . . . . 21
4.1.2 Sprint 1 - Creación de rutas en la aplicación móvil . . . . . . . . . . . 21
i
Índice general
4.1.3 Sprint 2 - Integración del mapa y gestión de eventos en la aplicación
móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.4 Sprint 3 - Gestión de rutas e informes en la aplicación web . . . . . . . 22
4.1.5 Sprint 4 - Visualización de rutas y generación de informes en la apli-
cación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.6 Sprint 5 - Análisis del soporte offline en la aplicación móvil . . . . . . 23
4.1.7 Sprint 6 - Desarrollo del soporte offline para incidencias . . . . . . . . 23
4.1.8 Sprint 7 - Visualización de elementos de mantenimiento . . . . . . . . 23
4.1.9 Sprint 8 - Gestión de elementos de mantenimiento en la aplicación
web y visualización de un evento en la aplicación móvil . . . . . . . . 23
4.1.10 Sprint 9 - Desarrollo del soporte offline para rutas . . . . . . . . . . . . 24
4.1.11 Sprint 10 - Creación de rutas con eventos en la aplicación web . . . . . 24
4.1.12 Sprint 11 - Gestión de categorías de eventos en la aplicación web . . . 24
4.1.13 Sprint 12 - Redacción de la memoria . . . . . . . . . . . . . . . . . . . 24
4.2 Planificación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Cálculo de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Fundamentos tecnológicos 27
5.1 Tecnologías utilizadas en el backend . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.3 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.4 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.5 SpringBoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.6 Hibernate y JPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.7 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Tecnologías utilizadas en el frontend . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.2 Single Page Application (SPA) . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.3 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.4 Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.5 Capacitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.6 NodePackage Manager (npm) . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.7 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Tecnologías adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.2 Git Kraken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.3 AzureDevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
ii
ÍNDICE GENERAL
5.3.4 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 Desarrollo 33
6.1 Modelo y persistencia de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.1 Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.2 Persistencia de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Iteración 0. Creación de la estructura base del proyecto . . . . . . . . . . . . . 35
6.2.1 Creación del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.2 Creación de la aplicación web . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.3 Creación de la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . 38
6.3 Iteración 1. Creación de rutas en la aplicación móvil . . . . . . . . . . . . . . . 40
6.3.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4 Iteración 2. Integración del mapa y gestión de eventos en la aplicación móvil . 44
6.4.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.5 Iteración 3. Gestión de rutas e informes en la aplicación web . . . . . . . . . . 50
6.5.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.5.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6 Iteración 4. Visualización de rutas y generación de informes en la aplicación
móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.6.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.6.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.7 Iteración 5. Análisis del soporte offline en la aplicación móvil . . . . . . . . . . 57
6.8 Iteración 6. Desarrollo del soporte offline para incidencias . . . . . . . . . . . . 58
6.8.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.8.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.9 Iteración 7. Visualización de elementos de mantenimiento . . . . . . . . . . . 60
6.9.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.9.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.10 Iteración 8. Gestión de elementos de mantenimiento en la aplicación web y
visualización de un evento en la aplicación móvil . . . . . . . . . . . . . . . . 62
6.10.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.10.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.11 Iteración 9. Desarrollo del soporte offline para rutas . . . . . . . . . . . . . . . 64
6.11.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.11.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.12 Iteración 10. Creación de rutas con eventos en la aplicación web . . . . . . . . 66
iii
Índice general
6.12.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.12.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.13 Iteración 11. Gestión de categorías de eventos en la aplicación web . . . . . . . 67
6.13.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.13.2 Implementación y diseño . . . . . . . . . . . . . . . . . . . . . . . . . 68
7 Conclusiones y trabajo futuro 69
7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Lista de acrónimos 73
Glosario 75
Bibliografía 77
iv
Índice de figuras
1.1 Arquitectura de la plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Azure Boards Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Azure Boards Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Mockup del listado de rutas en la aplicación web . . . . . . . . . . . . . . . . . 15
3.2 Mockup del formulario de rutas en la aplicación web . . . . . . . . . . . . . . 16
3.3 Mockup del listado de rutas en la aplicación móvil . . . . . . . . . . . . . . . . 18
3.4 Mockup del listado de rutas en la aplicación móvil . . . . . . . . . . . . . . . . 19
3.5 Mockup de la sincronización de rutas en la aplicación móvil . . . . . . . . . . 20
5.1 Arquitectura de Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1 Diagrama de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Estructura de la aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3 Estructura de la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4 Vista login de la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5 Menú de la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.6 Diagrama de clases para los EntityTypes . . . . . . . . . . . . . . . . . . . . . . 42
6.7 Diagrama de clases para las Routes . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.8 Elección del tipo de ruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.9 Creación de una ruta de entidad . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.10 Selector dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.11 Diagrama de clases para los Events . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.12 Vista del mapa en la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . 48
6.13 Vista para crear un evento en la aplicación móvil . . . . . . . . . . . . . . . . . 48
6.14 Detalle de un evento creado sobre el mapa en la aplicación móvil . . . . . . . . 49
6.15 Capas del mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
v
Índice de figuras
6.16 Tabla de rutas de entidad en la aplicación web . . . . . . . . . . . . . . . . . . 53
6.17 Footer del componente tabla en la aplicación web . . . . . . . . . . . . . . . . 53
6.18 Ejemplo de uso de los filtros para rutas en la aplicación web . . . . . . . . . . 54
6.19 Diálogo de confirmación en la aplicación web . . . . . . . . . . . . . . . . . . 55
6.20 Detalle de un evento en la aplicación web . . . . . . . . . . . . . . . . . . . . . 55
6.21 Lista de rutas de entidad en la aplicación móvil . . . . . . . . . . . . . . . . . . 57
6.22 Vista para sincronizar eventos en la aplicación móvil . . . . . . . . . . . . . . 59
6.23 Detalle del número de eventos almacenados en la aplicación móvil . . . . . . . 60
6.24 Cabecera de la vista del mapa en la aplicación móvil . . . . . . . . . . . . . . . 60
6.25 Filtro para las entidades en la aplicación web . . . . . . . . . . . . . . . . . . . 61
6.26 Formulario para crear nuevas entidades en la aplicación web . . . . . . . . . . 63
6.27 Información de un evento en la aplicación móvil . . . . . . . . . . . . . . . . . 64
6.28 Rutas guardadas localmente en la aplicación móvil . . . . . . . . . . . . . . . . 66
vi
Índice de tablas
3.1 Requisitos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 25
6.1 Iteración 1: Creación de rutas en la aplicación móvil . . . . . . . . . . . . . . . 41
6.2 Iteración 1: Llamadas de la API involucradas en la creación de una ruta . . . . 42
6.3 Iteración 2: Integración del mapa y visualización de eventos en la aplicación
móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4 Iteración 2: Creación de eventos en la aplicación móvil . . . . . . . . . . . . . 45
6.5 Iteración 2: Selección de capas para el mapa en la aplicación móvil . . . . . . . 45
6.6 Iteración 2: Parar ruta en la aplicación móvil . . . . . . . . . . . . . . . . . . . 45
6.7 Iteración 2: Llamadas de la API involucradas en la creación de eventos . . . . 46
6.8 Iteración 3: Visualización de rutas por tipo en la aplicación web . . . . . . . . 50
6.9 Iteración 3: Buscar rutas en la aplicación web . . . . . . . . . . . . . . . . . . . 50
6.10 Iteración 3: Buscar rutas por filtros en la aplicación web . . . . . . . . . . . . . 51
6.11 Iteración 3: Edición de una ruta en la aplicación web . . . . . . . . . . . . . . . 51
6.12 Iteración 3: Borrado de rutas en la aplicación web . . . . . . . . . . . . . . . . 51
6.13 Iteración 3: Generar el informe de una ruta en la aplicación web . . . . . . . . 51
6.14 Iteración 3: Llamadas de la API involucradas en la gestión y búsqueda de rutas 52
6.15 Iteración 4: Listado de rutas en la aplicación móvil . . . . . . . . . . . . . . . . 55
6.16 Iteración 4: Búsqueda de rutas en la aplicación móvil . . . . . . . . . . . . . . 56
6.17 Iteración 4: Generar el informe de una ruta en la aplicación móvil . . . . . . . 56
6.18 Iteración 6: Almacenamiento de eventos y categorías de eventos localmente
en la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.19 Iteración 6: Sincronización de eventos locales con el servidor en la aplicación
móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.20 Iteración 7: Visualización de las entidades de mantenimiento en la aplicación
web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
vii
Índice de tablas
6.21 Iteración 7: Búsqueda de entidades de mantenimiento en la aplicación web . . 60
6.22 Iteración 7: Búsqueda avanzada de entidades de mantenimiento en la aplica-
ción web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.23 Iteración 8: Creación de entidades de mantenimiento en la aplicación web . . 62
6.24 Iteración 8: Borrado de entidades de mantenimiento en la aplicación web . . . 62
6.25 Iteración 8: Visualización del detalle de un evento en la aplicación móvil . . . 62
6.26 Iteración 8: Llamadas de la API involucradas en la gestión de entidades de
mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.27 Iteración 9: Almacenamiento de información con SQLite en la aplicación móvil 64
6.28 Iteración 9: Sincronización de rutas y eventos locales con el servidor en la
aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.29 Iteración 9: Creación de rutas con eventos en la aplicación web . . . . . . . . . 66
6.30 Iteración 11: Visualización de las categorías de los eventos en la aplicación web 67
6.31 Iteración 11: Búsqueda de categorías de eventos en la aplicación web . . . . . 67
6.32 Iteración 11: Creación de categorías de eventos en la aplicación web . . . . . . 68
6.33 Iteración 11: Borrado de categorías de eventos en la aplicación web . . . . . . 68
6.34 Iteración 11: Llamadas de la API involucradas en la gestión de categorías . . . 68
viii
Capítulo 1
Introducción
1.1 Contexto
En estos últimos años hemos podido observar cómo cada vez la preocupación social por
el medio ambiente ha ido creciendo, especialmente en Europa. Los gobiernos de países como
Suiza, Alemania o Austria invierten cada vez más en iniciativas medioambientales, tales como
el reciclaje de residuos, la reducción de emisiones de gases o la conservación del medio.
La empresa Gabriel, localizada en Austria, tiene este como uno de sus principales objeti-
vos. Además de limpieza de alcantarillados y movimiento de tierras, se dedica al cuidado y la
renaturalización del paisaje. Sus empleados inspeccionan zonas que necesiten ser mantenidas
en busca de incidencias que supervisar (como zonas inundadas, caminos bloqueados, plantas
invasoras o malas hierbas, etc.). Todos estos posibles sucesos son anotados por el operario, y
luego con esa información el personal responsable se encargará de solventarlos.
Este proyecto nace con el objetivo de facilitar las labores de mantenimiento de esta empre-
sa, mediante la informatización y automatización de su sistema de reporte de incidencias. De
esta forma, serán capaces de llevar un seguimiento más preciso y de una forma más sencilla
de las rutas que realicen los operarios, con un menor esfuerzo y ahorrando tiempo y costes.
Cabe destacar que el proceso de resolución de las incidencias no entra en el alcance de este
proyecto.
1.2 Objetivos
El objetivo principal de este proyecto es crear una aplicación móvil (orientada principal-
mente a tablet) sencilla e intuitiva, con la que los operarios demantenimiento puedan registrar
fácilmente las rutas que realicen durante su jornada. Durante el recorrido de una de estas ru-
1
1.3. Visión global
tas, podrán dejar constancia de cualquier punto que necesite ser posteriormente supervisado,
o sobre el que se precise realizar cualquier tipo de acción (la limpieza de un arroyo, un camino
bloqueado, un lago desbordado, etc.). Es importante que esta aplicación pueda ser utilizada
en entornos sin conexión a Internet, dado que una ruta puede transcurrir por zonas con mala
cobertura (e.g. una zona montañosa).
También se pretende facilitar una aplicación web orientada al personal de administración.
En ella, los usuarios podrán llevar un control de las rutas que han completado los operarios,
pudiendo corregir datos que no fuesen bien introducidos por el trabajador o añadir infor-
mación adicional para cada una de las incidencias reportadas. Además, podrán gestionar los
elementos para los que realizan las supervisiones (entidades de mantenimiento) y las catego-
rías que se asignan a las incidencias.
Ambas aplicaciones permitirán descargar un informe en formato PDF que contenga la in-
formación de una ruta y de sus incidencias.
Por último, otro objetivo que se pretende alcanzar con este proyecto es el de adquirir
conocimientos y experiencia en el uso de nuevas tecnologías y herramientas con las que no
se ha trabajado previamente.
1.3 Visión global
El sistema consistirá en una aplicación móvil implementada haciendo uso de los frame-
works Angular e Ionic y una aplicación web desarrollada con Angular, utilizando para ambas
TypeScript como lenguaje de programación.
Ambas harán uso de un API REST implementado en Java que se encargará de gestionar la
lógica de negocio de las aplicaciones. Se utilizarán Spring e Hibernate con JPA para facilitar
su desarrollo.
Por último, para la persistencia de datos se utilizará una base de datos relacional, en este caso
gestionada con MySQL.
En la imagen 1.1 se puede ver un esquema de la arquitectura que seguirá este software.
2
CAPÍTULO 1. INTRODUCCIÓN
Figura 1.1: Arquitectura de la plataforma
3
1.3. Visión global
4
Capítulo 2
Metodología
MetodologÍa es un término que, en el ámbito del desarrollo software, se utiliza para defi-nir un conjunto de técnicas y métodos organizativos que tienen por objetivo planificar
el desarrollo de un producto software.
Para la realización de este proyecto se ha utilizado una metodología ágil basada en Scrum.
2.1 Metodología ágil
Una metodología ágil es aquella que permite adaptar la forma de trabajo a las condiciones
del proyecto, consiguiendo flexibilidad e inmediatez ante cambios durante el desarrollo de un
producto.
Algunas de las principales ventajas que ofrecen estas metodologías son:
• Mejora de la calidad del producto: Mediantela integración, comprobación y revisión
continúa de las propiedades del producto.
• Trabajo colaborativo: La división del trabajo por distintos equipos y roles junto al
desarrollo de reuniones frecuentes, permite una mejor organización del trabajo.
• Mayor capacidad de predicción: Mediante la revisión del producto a lo largo del pro-
ceso ágil, lo que permite a la empresa ahorrar tiempo y costes.
• Acelera el retorno de inversión: El cliente puede ver cómo el producto va evolucio-
nando sin tener que esperar a que se haya finalizado por completo. Es una forma de ir
rentabilizando el producto durante la creación del mismo.
5
2.2. Scrum
2.2 Scrum
2.2.1 Qué es Scrum
Scrum [1] es un marco de trabajo basado en el aprendizaje continuo y la adaptación a los
factores fluctuantes de un proyecto (como la especificación de requisitos o la actualización de
prioridades en las tareas).
2.2.2 Artefactos
Scrum distingue tres artefactos que lo conforman:
• Product backlog : Consiste en una lista de nuevos requisitos, funciones, correcciones
de errores y mejoras que el Product Owner va actualizando a medida que cambian las
prioridades en su desarrollo. Es una lista de ”cosas por hacer”.
• Sprint backlog: Se trata de una lista de historias de usuario y correcciones de errores
que el equipo de desarrollo selecciona del Product backlog para resolver a lo largo de un
Sprint. Esta lista puede variar a lo largo del Sprint, pero no puede perder los objetivos
principales de lo que se pretende resolver.
• Incremento del producto: Es el producto final utilizable de un Sprint. Aunque es algo
que depende de la organización de cada equipo, este se suele presentar en la Sprint
Review, una sesión colaborativa entre el equipo Scrum y stakeholders.
2.2.3 Roles en Scrum
• Scrum team: Equipo formado por el Product owner, el Scrum master y el equipo de
desarrollo.
• Product owner: Es el encargado de maximizar el valor del producto resultado del tra-
bajo del Scrum team. Es el representante del cliente dentro del equipo, representa a
las partes interesadas internas y es responsable de entregar el valor más alto posible al
negocio.
• Scrummaster: Un Scrum Master es el líder del equipo de Scrum. Está a cargo de esta-
blecer esta metodología y mantener a los miembros del equipo enfocados en los princi-
pios y las prácticas de Scrum.
• Equipo de desarrollo: Son los encargados de completar las historias de usuario que
conforman un Sprint.
6
CAPÍTULO 2. METODOLOGÍA
2.2.4 Eventos Scrum
Se trata del conjunto de protocolos o reuniones que los equipos Scrum realizan de forma
periódica. Siguen el siguiente flujo:
• Sprints: Un Sprint es un contenedor para el resto de eventos de Scrum. Es un período
breve de tiempo fijo en el que un equipo Scrum trabaja para completar una cantidad
de trabajo establecida previamente. El Sprint es continuo, es decir, su duración no debe
cambiar mientras está en marcha el desarrollo del producto. Suelen estar comprendidos
entre 1 y 4 semanas (ver figura ⁇).
• Sprint Planning: Dirigida por el ScrumMaster, es una reunión que se da al principio de
un Sprint en la que el equipo de desarrollo selecciona del Product backlog los elementos
que se van a resolver a lo largo de este, y los añade al Sprint backlog.
• Daily Scrum: Es una reunión diaria en la que cada miembro del equipo de desarrollo
comenta el trabajo realizado el día anterior, en lo que está trabajando en este momento
así como los problemas que le hayan podido surgir.
• Sprint Review: Es la reunión que ocurre al final del Sprint, donde el Product owner
y el equipo de desarrollo presentan a los stakeholders el incremento terminado para su
inspección y adaptación correspondientes.
• Sprint Retrospective: Ocurre también al final del Sprint, justo después del Sprint Re-
view. El objetivo de esa reunión es hacer de reflexión sobre el último Sprint e identificar
posibles mejoras para el próximo.
• Sprint Refinement o Backlog Refinement: Se trata de una reunión entre el Pro-
duct owner y el equipo de desarrollo cuyo objetivo es aclarar cualquier duda sobre los
requisitos impuestos en las historias de usuario.
2.3 Adaptación de Scrum para el proyecto
En este proyecto, se ha aplicado la metodología descrita anteriormente de la siguiente
forma:
2.3.1 Artefactos
La gestión de los artefactos se ha llevado a cabo a través de la herramienta Azure De-
vOps, concretamente a través del módulo Azure Boards. Haciendo uso de esta herramienta,
se gestionará el Product backlog y se planificará cada Sprint del proyecto.
7
2.3. Adaptación de Scrum para el proyecto
• Product backlog: A través de una lista dinámica de Product backlog items y bugs, se
irán añadiendo los nuevos requisitos de la plataforma y gestionando la resolución de
errores (figura 2.1).
Figura 2.1: Azure Boards Product Backlog
• Sprint backlog: Desde la vista ”Sprints” se llevará un control del estado de cada histo-
ria de usuario que se haya incluído en un Sprint. Esto se hará mediante una tabla con 4
columnas: en la primera columna se mostrarán las historias de usuario y en las tres res-
tantes se distribuirán las tareas que forman cada historia según su estado de resolución:
To do, In progress o Done (figura 2.2).
Figura 2.2: Azure Boards Sprint
8
CAPÍTULO 2. METODOLOGÍA
2.3.2 Roles
Debido a que este proyecto se ha llevado a cabo para una empresa real, la distribución de
los roles Scrum es bastante acorde con la especificación de este marco de trabajo:
• Product owner: Este rol ha sido asumido por uno de los empleados de la empresa, cuyo
cometido se basa en encontrar clientes potenciales a los que ofrecer un producto soft-
ware así como atender sus necesidades (modificaciones del producto o incluir nuevas
funcionalidades).
• Scrum master: El rol de Scrum master lo ha tomado el Project manager, haciendo
de portavoz del equipo de desarrollo con el Product owner y gestionando la carga de
trabajo de cada Sprint.
• Equipo de desarrollo: Debido al uso de este proyecto como TFG, el equipo de desa-
rrollo está formado únicamente por la alumna.
2.3.3 Eventos
Se han empleado Sprints de 2 semanas de duración, con reuniones diarias entre la alumna
y el Scrum master. Al final de cada uno, se realizó un Sprint Review con el Scrum Master y el
Product owner, seguido de una retrospectiva y la planificación del Sprint siguiente. A mitad
de cada Sprint tuvo lugar un Backlog refinement entre el equipo Scrum y el Product owner
para aclarar dudas sobre los requisitos.
9
2.3. Adaptación de Scrum para el proyecto
10
Capítulo 3
Análisis global de requisitos
PaRa empezar a profundizar en el desarrollo de la plataforma, en este capítulo se explicaránlos roles de los usuarios que emplearán la aplicación, así como la especificación de los
requisitos del sistema.
3.1 Roles
Según el nivel de jerarquía y el puesto de trabajo que el usuario tenga en la empresa,
se distinguirán 3 roles principales. Cada uno de estos roles podrá acceder y modificar unos
recursos u otros en función de los permisos que posea. Se distinguen:
• Administrador: Es el usuario con mayor número de permisos del sistema. Este rol será
utilizado por los usuarios encargados de gestionar la información del sistema, utilizando
la aplicación web. Tienen la responsabilidad de administrar las categorías de los eventos
y las entidades de mantenimiento (un lago, una carretera, un río, etc.). Además, podrán
tener acceso a los mismos recursos que los demás roles.
• Manager o Gerente: Este rol lo ocupará el personal de oficina de la empresa. Al igual
que los usuarios administradores, estos también trabajarán utilizando la aplicación web.
Los gerentes gestionarán las rutas y las incidencias creadas por los empleados de man-
tenimiento, pudiendo modificar la información de cada una o borrar las que considere.
Además podrán crear rutas desde la aplicación web. Por último, podrán generar un PDF
para cada ruta, con la información y las incidencias de cada una.
• Empleado: Los usuarios con este rol serán los empleados de mantenimientode la em-
presa. Son los que acudirán a las zonas que se vayan a supervisar y, utilizando la aplica-
ción móvil, crearán una ruta con las características de esa zona y reportarán incidencias
en los puntos que necesiten supervisión según la recorren.
11
3.2. Requisitos
3.2 Requisitos
En este apartado se detallarán los requisitos de este proyecto, incluyendo una visión es-
quemática del Product Backlog y un desglose posterior de cada una de las historias de usuario
definidas.
3.2.1 Product Backlog
ID Historia Descripción App
H01 Ver rutas por tipo Como gerente quiero ver las rutas de entidad
y de punto-a-punto de forma separada y or-
denarlas por varios parámetros
Web
H02 Búsqueda de rutas Como gerente quiero buscar rutas por pala-
bras clave
Web
H03 Búsqueda avanzada de
rutas
Como gerente quiero buscar rutas filtrando
por distintos parámetros
Web
H04 Crear ruta con eventos Como gerente quiero crear rutas tanto de en-
tidad como de punto-a-punto desde el portal
web
Web
H05 Editar ruta Como gerente quiero editar la información de
una ruta
Web
H06 Borrar ruta Como gerente quiero borrar una o varias ru-
tas a la vez
Web
H07 Ver entidades de man-
tenimiento
Como administrador quiero visualizar todas
las entidades de mantenimiento y ordenarlas
por varios parámetros
Web
H08 Búsqueda de entidades
de mantenimiento
Como administrador quiero buscar entidades
de mantenimiento por palabras clave
Web
H09 Búsqueda avanzada de
entidades de manteni-
miento
Como administrador quiero filtrar las entida-
des de mantenimiento por su tipo
Web
H10 Crear entidades de
mantenimiento
Como administrador quiero poder crear enti-
dades de mantenimiento
Web
H11 Borrar entidades de
mantenimiento
Como administrador quiero borrar una o va-
rias entidades de mantenimiento a la vez
Web
Continúa en la página siguiente
12
CAPÍTULO 3. ANÁLISIS GLOBAL DE REQUISITOS
Tabla 3.1 – continuado desde la página anterior
ID Historia Descripción App
H12 Ver categorías de even-
tos
Como administrador quiero visualizar todas
las categorías de los eventos y ordenarlas por
varios parámetros
Web
H13 Búsqueda de categorías
de eventos
Como administrador quiero buscar catego-
rías de eventos por palabras clave
Web
H14 Crear categorías de
eventos
Como administrador quiero poder crear cate-
gorías para los eventos
Web
H15 Borrar categorías de
eventos
Como administrador quiero borrar una o va-
rias categorías de eventos simultáneamente
Web
H16 Generar informe de
una ruta
Como gerente quiero generar un informe en
PDF con la información de una ruta
Web
H17 Ver rutas por tipo Como empleado quiero ver las rutas de enti-
dad y de punto-a-punto de forma separada
Móvil
H18 Buscar rutas Como empleado quiero buscar rutas por pa-
labras clave
Móvil
H19 Crear ruta Como empleado quiero crear rutas tanto de
entidad como de punto-a-punto desde la apli-
cación móvil
Móvil
H20 Ver eventos de una ruta Como empleado quiero ver los eventos que se
han creado para una ruta como marcadores
sobre un mapa
Móvil
H21 Ver evento de una ruta Como empleado quiero ver los detalles de un
evento en el mapa
Móvil
H22 Añadir evento a una
ruta
Como empleado quiero añadir eventos a una
ruta creada
Móvil
H23 Añadir capas Como empleado quiero elegir entre varias ca-
pas que aplicar sobre el mapa
Móvil
H24 Parar de registrar ruta Como empleado quiero dar por finalizada
una ruta cuando haya terminado de registrar
todos sus eventos
Móvil
H25 Generar informe de
una ruta
Como empleado quiero descargar el informe
en PDF de una ruta finalizada
Móvil
Continúa en la página siguiente
13
3.2. Requisitos
Tabla 3.1 – continuado desde la página anterior
ID Historia Descripción App
H26 Soporte sin conexión Como empleado quiero poder crear rutas y
eventos sin conexión a internet y almacenar-
los localmente
Móvil
H27 Sincronización de da-
tos
Como empleado quiero poder enviar al servi-
dor bajo demanda las rutas y eventos creados
localmente
Móvil
Tabla 3.1: Requisitos del proyecto
3.2.2 Funcionalidades de la aplicación web
• H01 - Ver rutas por tipo
Existen dos tipos de rutas, las rutas de entidad y las rutas punto-a-punto. Las rutas de
entidad son aquellas que se realizan sobre una entidad de mantenimiento concreta (por
ejemplo una ruta que recorra el río Sil). En cambio las rutas punto-a-punto son aquellas
que se realizan desde un punto kilométrico de una municipalidad a otro (por ejemplo
desde el kilómetro 10 al 30 de un camino en Outes). Los usuarios podrán ver una tabla
de rutas de entidad y otra de rutas punto-a-punto haciendo clic en entradas diferenciadas
del menú. Para ambos tipos de rutas en la tabla se mostrará:
1. El identificador de la ruta (será un identificador externo para que los usuarios
puedan referenciar una ruta fácilmente).
2. El cliente para el que se ha hecho el trabajo.
3. El usuario que creó la ruta.
4. La fecha de creación.
5. La fecha de finalización (si la tiene).
6. Las categorías de los eventos reportados representados con acrónimos.
Para las rutas de entidad, a mayores se mostrará:
1. La entidad de mantenimiento de la ruta.
2. La municipalidad donde se ha realizado.
Y para las rutas punto-a-punto:
1. La municipalidad donde comenzó la ruta.
14
CAPÍTULO 3. ANÁLISIS GLOBAL DE REQUISITOS
2. El punto kilométrico en el que comenzó.
3. La municipalidad donde acabó la ruta.
4. El punto kilométrico en el que finalizó.
A continuación se muestra un mockup de la lista de rutas en la aplicación web (figura
3.1).
Figura 3.1: Mockup del listado de rutas en la aplicación web
• H02 - Búsqueda de rutas
Para poder encontrar una ruta fácilmente, se añadirá un campo de búsqueda por pala-
bras clave, en el que se podrá buscar por identificador, entidad, municipalidad y cliente.
• H03 - Búsqueda avanzada de rutas
A mayores, en la búsqueda de rutas se permitirá filtrar por tipo de entidad, municipali-
dad, categorías de sus eventos, entidades de mantenimiento y usuario creador de la ruta.
• H04 - Crear ruta con eventos
Mediante un botón situado en la misma pantalla que la tabla de rutas, se permitirá al
usuario crear una a través de un formulario en el que se cubrirá la siguiente información:
1. Tipo de ruta: Dependiendo de si la ruta se va a crear a partir de la tabla de rutas de
entidad o rutas punto-a-punto, este campo tendrá un valor u otro y no se podrá
modificar.
2. Tipo de entidad.
3. Cliente.
4. Fecha de fin.
15
3.2. Requisitos
5. Entidad de mantenimiento (en caso de que se trate de una ruta de entidad).
6. Municipalidad en el caso de una ruta de entidad, y municipalidad de inicio y de
fin en caso de una ruta punto-a-punto.
7. Punto de inicio y punto de fin, en el caso de una ruta punto-a-punto.
8. Lista de eventos: Se mostrará un campo para subir varias imágenes y por cada
una de estas imágenes se generará un evento (que puede ser un camino cortado,
una especie de planta invasora, un árbol caído, etc.). Para cada evento el usuario
cubrirá una descripción y seleccionará una categoría. Además, podrá editar la lista
de eventos eliminándolos o creando otros nuevos mediante un botón.
En la imagen 3.2 se puede ver un mockup de la vista de este formulario para una ruta
de entidad.
Figura 3.2: Mockup del formulario de rutas en la aplicación web
• H05 - Editar ruta
Para editar una ruta existente se reutilizará la misma pantalla que para la crearla.
• H06 - Borrar ruta
Para borrar rutas el usuario tendrá dos opciones: Desde la tabla, seleccionando las que
desee y dándole a un botón de borrar, o bien desde la pantalla de creación/edición, bo-
rrando esa ruta concreta. Para ambas opciones se mostrará un diálogo de confirmación
antes de eliminarlas.
• H07 - Ver entidades de mantenimiento
Los usuarios podrán ver una tabla con todas las entidades de mantenimiento existentes.
Para cada una de ellas se mostrará su nombre y el tipo de entidad. El diseño de esta vista
será muy similar al de la imagen 3.1.
16
CAPÍTULO 3. ANÁLISIS GLOBAL DE REQUISITOS
• H08 - Búsqueda de entidadesde mantenimiento
Se añadirá un campo de búsqueda a la tabla de entidades, permitiendo al usuario buscar
una entidad por su nombre.
• H09 - Búsqueda avanzada de entidades de mantenimiento
Se añadirá un filtro a la tabla de entidades en el que el usuario seleccionará el tipo de
entidad por el que quiere filtrar.
• H10 - Crear entidades de mantenimiento
El usuario podrá crear una nueva entidad a través de un botón encima de la tabla que
le redirigirá a una nueva pantalla con un formulario. En este formulario el usuario in-
troducirá el nombre y seleccionará el tipo de la nueva entidad y posteriormente le dará
a un botón de guardar. El diseño de este formulario será similar al de la imagen 3.2.
• H11 - Borrar entidades de mantenimiento
El usuario podrá borrar entidades seleccionándolas de la tabla y pulsando sobre un
botón de borrado.
• H12 - Ver categorías de eventos
El usuario podrá ver una tabla con todas las categorías posibles para los eventos. Para
cada una de ellas se mostrará su nombre y su acrónimo asociado. El diseño de esta vista
será parecido al de la imagen 3.1.
• H13 - Búsqueda de categorías de eventos
Se añadirá un campo de búsqueda a la tabla de categorías, permitiendo al usuario buscar
una categoría por su nombre.
• H14 - Crear categorías de eventos
El usuario podrá crear una nueva categoría a través de un botón situado encima de la
tabla que le redirigirá a una nueva pantalla con un formulario. En este formulario el
usuario introducirá el nombre y el acrónimo de la categoría, y posteriormente le dará a
un botón de guardar. El diseño de esta vista será muy similar al del mockup 3.2.
• H15 - Borrar categorías de eventos
El usuario podrá borrar categorías seleccionándolas de la tabla y pulsando sobre un
botón de borrado.
• H16 - Generar informe de una ruta
Al lado de cada ruta de la tabla de rutas, habrá un botón de descarga que, si el usuario
pulsa, generará un PDF con la información de esa ruta y sus eventos.
17
3.2. Requisitos
3.2.3 Funcionalidades de la aplicación móvil
• H17 - Ver rutas por tipo
A través de una entrada nueva en el menú el usuario podrá ver una lista de las rutas que
se han creado, pudiendo filtrarlas por tipo mediante un botón y mostrando para cada
una la siguiente información:
1. La entidad de mantenimiento de la ruta (si es una ruta de entidad).
2. La municipalidad donde se ha realizado (si es una ruta de entidad).
3. La municipalidad de inicio y de fin (si es una ruta de punto-a-punto)
4. Los puntos kilométricos de inicio y de fin (si es una ruta de punto-a-punto)
5. La fecha de creación.
6. La fecha de finalización (si la tiene).
7. El estado de la ruta (completada o en progreso).
En la imagen 3.3 se puede ver un mockup de la vista del listado de rutas de entidad en
la aplicación móvil.
Figura 3.3: Mockup del listado de rutas en la aplicación móvil
• H18 - Buscar rutas
El usuario podrá filtrar las rutas de la lista por palabras clave, buscando por su identi-
ficador, entidad, municipalidad o cliente.
• H19 - Crear ruta
Para crear una ruta, existirá una entrada en el menú que redirigirá al usuario a una
pantalla en la que elegirá entre ruta de entidad o ruta punto-a-punto, dependiendo de
la que quiera crear. Después el usuario deberá de completar la información de la ruta:
1. Tipo de entidad.
18
CAPÍTULO 3. ANÁLISIS GLOBAL DE REQUISITOS
2. Entidad de mantenimiento (en caso de que se trate de una ruta de entidad).
3. Municipalidad en el caso de una ruta de entidad, y municipalidad de inicio y de
fin en caso de una ruta punto-a-punto.
4. Punto de inicio y punto de fin, en el caso de una ruta punto-a-punto.
5. Nombre del cliente.
• H20 - Ver eventos de una ruta
Tanto al pulsar sobre una ruta de la lista como después de crearla, el usuario será re-
dirigido a una pantalla con un mapa en la que podrá visualizar los eventos existentes
para esa ruta mediante marcadores. En la imagen 3.4 se muestra el diseño inicial para
esta pantalla.
Figura 3.4: Mockup del listado de rutas en la aplicación móvil
• H21 - Ver evento de una ruta
Al pulsar sobre cualquier marcador del mapa, se desplegará un bocadillo con la infor-
mación de ese evento.
• H22 - Añadir evento a una ruta
En la parte inferior de la pantalla del mapa, habrá un botón que al pulsarlo abrirá la
cámara del dispositivo. El usuario sacará una foto de la incidencia y posteriormente se
abrirá una ventana modal con la imagen y con las coordenadas GPS del usuario en ese
momento. Además, en el modal habrá un campo para introducir una descripción para el
evento y un selector de categorías. Una vez pulsado el botón de confirmación, el modal
se cerrará y aparecerá un nuevo marcador en el mapa representando el evento creado.
• H23 - Añadir capas
El usuario podrá seleccionar entre varias capas que aplicar sobre el mapa. Estas capas
serán:
19
3.2. Requisitos
1. Ríos: Se marcarán en azul todos los ríos registrados sobre el mapa.
2. Reservas naturales: Se marcarán con puntos las zonas que sean consideradas
reservas naturales.
3. Designación de tierra: Distingue en cuadrantes de diferentes colores las áreas
donde trabaja la empresa.
4. Zonas peligrosas: Marca en el mapa las zonas que suponen algún riesgo en dis-
tintos colores dependo de su peligrosidad.
• H24 - Parar de registrar ruta
En la parte inferior de la pantalla del mapa habrá otro botón que permitirá al usuario
dar por finalizada una ruta (registrando ese instante como fecha de fin para la ruta).
• H25 - Generar informe de una ruta
En cada ruta de la lista, habrá un botón que permitirá al usuario descargar un PDF con
la información y eventos de esa ruta.
• H26 - Soporte sin conexión
La aplicación deberá permitir almacenar información localmente para poder funcionar
sin conexión. El usuario podrá crear nuevas rutas y registrar eventos que serán almace-
nados en el dispositivo. Existirá una nueva entrada del menú en la que el usuario podrá
ver las rutas con sus eventos almacenados localmente.
• H27 - Sincronización de datos
Cuando el usuario tenga rutas almacenadas localmente y tenga conexión, podrá en-
viarlas al servidor junto con sus eventos correspondientes y borrarlas del dispositivo
pulsando un botón (figura 3.5).
Figura 3.5: Mockup de la sincronización de rutas en la aplicación móvil
20
Capítulo 4
Planificación
En este capítulo se abordará la planificación de este proyecto, siguiendo la metodologíaScrum [1]. Para ello, se incluirá una especificación del trabajo realizado iterativamente
en cada Sprint, así como una planificación temporal y un cálculo de costes del proyecto.
4.1 Sprints
A continuación se detalla el trabajo realizado en cada Sprint. Cabe mencionar que durante
el desarrollo de algunos de los Sprints del proyecto, la alumna colaboraba simultáneamente
en otros proyectos de la empresa, por lo que se pueden ver ligeramente desbalanceados.
4.1.1 Sprint 0 - Creación de la estructura base del proyecto
La empresa con la que se colaboró para realizar este proyecto cuenta con una estructura
base tanto para el servicio como para la interfaz de usuario, para la creación de nuevos pro-
yectos de una forma más rápida y sencilla. Por lo que este Sprint se dedicó a incorporar esa
estructura básica y adaptarla a este proyecto.
4.1.2 Sprint 1 - Creación de rutas en la aplicación móvil
Durante este Sprint se añadió el soporte para crear rutas de ambos tipos desde la aplicación
móvil. La historia de usuario abordada fue:
• H19 - Crear ruta
4.1.3 Sprint 2 - Integración del mapa y gestión de eventos en la aplicación
móvil
Durante este Sprint, se investigaron posibles APIs que utilizar para mostrar un mapa di-
námico en la aplicación. las historias de usuario que se abordaron fueron:
21
4.1. Sprints
• H20 - Ver eventos
• H22 - Añadir evento
• H23 - Añadir capas
• H24 - Parar ruta
4.1.4 Sprint 3 - Gestión de rutas e informes en la aplicación web
En este Sprint se llevó a cabo la gestión de rutas en la aplicación web, a excepción de su
creación ya que el cliente únicamente requería la creación de rutasa través de la app móvil.
Tampoco se incluyó la edición de la lista de eventos asociados a una ruta, por el mismomotivo.
Se implementaron las siguientes historias de usuario:
• H01 - Ver rutas por tipo
• H02 - Búsqueda de rutas
• H03 - Búsqueda avanzada de rutas
• H05 - Editar ruta
• H06 - Borrar ruta
• H16 - Generar informe
4.1.5 Sprint 4 - Visualización de rutas y generación de informes en la apli-
cación móvil
Durante este Sprint se incluyó el soporte para poder visualizar la lista de rutas creadas
desde la aplicación móvil. Antes de esto únicamente se podían ver a través de la aplicación
web, y se consideró un requisito de gran utilidad para los empleados de mantenimiento. De
esta forma, los empleados son conscientes también de las rutas existentes, y adicionalmente
pueden descargar ellos mismos los informes de cada ruta. Las historias de usuario implemen-
tadas en este caso fueron:
• H17 - Ver rutas por tipo
• H18 - Buscar rutas
• H25 - Generar informe
22
CAPÍTULO 4. PLANIFICACIÓN
4.1.6 Sprint 5 - Análisis del soporte offline en la aplicación móvil
Este Sprint se dedicó a la investigación de tecnologías que utilizar para poder desarrollar
el soporte sin conexión a Internet.
4.1.7 Sprint 6 - Desarrollo del soporte offline para incidencias
El cliente pidió que como primer paso se incluyese el soporte sin conexión únicamente
para almacenar eventos, por lo que en este caso en las historias de usuario H26 y H27 sólo se
abordó la gestión de los eventos.
• H26 - Soporte sin conexión
• H27 - Sincronización de datos
4.1.8 Sprint 7 - Visualización de elementos de mantenimiento
Debido a lo que se comentó al principio de esta sección (la alumna trabajó simultáneamen-
te en varios proyectos), en este Sprint únicamente se abarcó la visualización de los entidades
de mantenimiento, dejando para el siguiente Sprint su gestión. Las historias de usuario que se
abordaron fueron:
• H07 - Ver entidades
• H08 - Búsqueda de entidades
• H09 - Búsqueda avanzada de entidades
4.1.9 Sprint 8 - Gestión de elementos demantenimiento en la aplicaciónweb
y visualización de un evento en la aplicación móvil
Durante este Sprint se finalizó la gestión de elementos de mantenimiento, añadiendo so-
porte para crearlos y eliminarlos. Además, se realizó la tarea que permite ver los detalles de
un evento tocando su marcador en el mapa. Se abordaron las siguientes historias de usuario:
• H10 - Crear entidades
• H11 - Borrar entidades
• H21 - Ver evento
23
4.2. Planificación temporal
4.1.10 Sprint 9 - Desarrollo del soporte offline para rutas
Como se mencionó anteriormente en el Sprint 6, el soporte sin conexión para almacenar
rutas no fue requerido hasta este momento, por lo que fue necesario completar la implemen-
tación de las historias de usuario H26 y H27 para cubrir este nuevo requisito.
• H26 - Soporte sin conexión
• H27 - Sincronización de datos
4.1.11 Sprint 10 - Creación de rutas con eventos en la aplicación web
En este punto, el cliente pidió que las rutas también se pudiesen crear desde la aplicación
web, pudiendo modificar su lista de eventos asociados. Se implementó por lo tanto la historia
de usuario:
• H04 - Crear ruta con eventos
4.1.12 Sprint 11 - Gestión de categorías de eventos en la aplicación web
Como último requisito, el cliente quiso poder gestionar las categorías de los eventos desde
la aplicación web. Por lo tanto, las historias de usuario abordadas fueron:
• H12 - Ver categorías
• H13 - Búsqueda de categorías
• H14 - Crear categorías
• H15 - Borrar categorías
4.1.13 Sprint 12 - Redacción de la memoria
Para terminar, se tuvo en cuenta la redacción de esta memoria explicando el proceso que
siguió el proyecto, así como la metodología y herramientas utilizadas durante el proceso.
4.2 Planificación temporal
Para el desarrollo de este proyecto, se utilizaron Sprints de 2 semanas de duración. Las
historias de usuario que se incluyen en cada uno se decidieron durante el Sprint Planning, tal
y como indica Scrum. Al final de cada Sprint se hizo una demo de las nuevas funcionalidades
implementadas ante el Product Owner, y tras esto si alguna de las que se planificó no se pudo
24
CAPÍTULO 4. PLANIFICACIÓN
completar, se pospuso al Sprint siguiente.
A partir del Sprint 8 se paró el desarrollo del proyecto porque la empresa requería invertir
más recursos en otros proyectos, por lo que los 3 últimos Sprints no fueron realizados hasta
finales del mismo año. A continuación se incluye una tabla de la planificación temporal por
Sprint del proyecto:
Sprint Comienzo Fin Horas esti-
madas
Horas
reales
Sprint 0 12/04/2021 23/04/2021 80 72
Sprint 1 26/04/2021 07/05/2021 56 95.9
Sprint 2 10/05/2021 21/05/2021 64 150.2
Sprint 3 24/05/2021 04/06/2021 80 114.4
Sprint 4 07/06/2021 18/06/2021 16 17.4
Sprint 5 21/06/2021 02/07/2021 24 20
Sprint 6 05/07/2021 16/07/2021 64 63.7
Sprint 7 19/07/2021 30/07/2021 24 19.2
Sprint 8 02/08/2021 13/08/2021 32 34.5
Sprint 9 20/12/2022 31/12/2022 40 56
Sprint 10 11/01/2022 21/01/2022 24 43.2
Sprint 11 24/01/2022 04/02/2021 24 12
Sprint 12 20/01/2022 13/02/2021 72 80
Total 600 horas 778.5 horas
Tabla 4.1: Planificación del proyecto
Como se puede apreciar en la tabla 4.1, en el desarrollo de los cuatro primeros Sprints la ca-
pacidad de trabajo estimada fue mayor, ya que el equipo se dedicó a tiempo completo a este
proyecto.
Es interesante observar que para estos primeros Sprints, las horas reales con respecto a las es-
timadas son bastante superiores. Esto se debe a que las horas estimadas fueron decididas entre
el Scrum Master y el Product Owner en base a su experiencia. Al no tener en cuenta la expe-
riencia del equipo de desarrollo, el resultado fue una subestimación en la capacidad del Sprint.
No obstante, esto fue corregido para los Sprints siguientes, en los que se puede ver como
las estimaciones comienzan a ser un poco más precisas con respecto a las horas reales. Duran-
te algunos de estos Sprints, y como se mencionó anteriormente, el equipo trabajó a su vez en
25
4.2. Planificación temporal
otros proyectos, por lo que se puede ver como la capacidad en horas es notablemente menor.
4.2.1 Cálculo de costes
En este apartado se abordará el cálculo del coste del proyecto. Dado que este proyecto se
ha desarrollado en una empresa, el coste real del proyecto no será desvelado, puesto que es
un dato confidencial.
Por lo tanto, el cálculo realizado fue en base a las siguientes suposiciones:
• El proyecto fue realizado únicamente por la alumna.
• La alumna trabajó a tiempo completo (40 horas por semana).
• El coste por hora trabajada es de 25€/hora.
• Fue necesario imputar los siguientes costes adicionales:
1. Ordenador: 500€
2. Teclado: 30€
3. Ratón: 15€
4. Pantalla: 150€
5. Disco duro externo: 100€
6. Alquiler de un sitio individual en un espacio de co-working: 120€/mes
La duración total del proyecto fueron 778.5 horas, que a tiempo completo (160 horas/mes)
suponen aproximadamente 5 meses de trabajo. En cuanto al coste del material se estimó una
vida útil de 4 años para cada componente. A continuación se muestran los cálculos realizados
para el coste total del proyecto:
Coste_material = 795€ ∗ (5 meses /12 meses ∗ 4 años) = 83€
Coste_adicional = coste_material + 120€/mes ∗ 5 meses = 683€
Coste_total = 778, 5 horas ∗ 25€/hora+ coste_adicional = 20.145,50€
26
Capítulo 5
Fundamentos tecnológicos
En este capítulo se profundizará en las tecnologías y herramientas utilizadas para la rea-lización del proyecto. Se explicarán de forma separada las herramientas dedicadas al
backend y al frontend, así como las herramientas adicionales utilizadas.
5.1 Tecnologías utilizadas en el backend
Ambas aplicaciones (tanto la web como la móvil), comparten un mismo backend. Este
consiste en una API REST implementada utilizando tecnologías Java Enterprise Edition (JEE)
[2]. Para la presistencia de datos, se ha utilizado MySQL.
5.1.1 MySQL
MySQL[3] es un Sistema de Gestión de Bases de Datos (SGDB) de código abierto que
trabaja con basesde datos relacionales, es decir, utiliza tablas múltiples que se interconectan
entre sí para almacenar la información y organizarla.
Está basado en un modelo cliente-servidor, en el que el programador que se conecta al SGDB
y envía peticiones actúa como cliente, mientras que el SGDB recibe, procesa estas peticiones
y envía una respuesta, actuando como servidor.
5.1.2 Java
Java[4] es uno de los lenguajes de programación más ampliamente utilizados. Está orien-
tado a objetos y es fuertemente tipado, por lo que mejora la detección de errores en tiempo de
compilación. Además es multiplataforma, lo cual quiere decir que es capaz de ejecutarse en
la mayoría de sistemas operativos y dispositivos. Esto lo consigue gracias a una Java Virtual
Machine (JVM) que existe en cualquier sistema que sea capaz de ejecutar Java. La aplicación
compila el código a bytecode, y la JVM lo ejecuta.
27
5.1. Tecnologías utilizadas en el backend
5.1.3 Eclipse
Eclipse[5] es un Integrated Development Environment (IDE) que comprende un espacio de
trabajo y un sistema extensible de plug-ins para personalizar el entorno. Uno de los plug-ins
más utilizados de Eclipse es JDT. Este plug-in es el encargado de dar soporte para el lenguaje
Java a este IDE.
5.1.4 Maven
Maven[6] es una herramienta de gestión de dependencias y automatización de empaque-
tado software orientado a plug-ins. Además de esto, provee la posibilidad de construir pro-
yectos multimódulo, establece una estructura de proyecto consistente y permite la generación
de websites para los proyectos. La estructura de un proyecto software que utiliza Maven gira
entorno al Parent Object Model (POM). Este consiste en un fichero XML que lo describe. En él
se definen los archivos de configuración, dependencias, información de la organización, etc.
5.1.5 SpringBoot
Spring Boot[7] es uno de los proyectos más utilizados de Spring, debido a que ofrece
grandes ventajas a la hora de configurar y desplegar una aplicación:
• Contenedor de aplicaciones integrado: Permite compilar una aplicación Web co-
mo un archivo .jar que puede ser ejecutado como una aplicación Java normal. Esto lo
consigue mediante un servidor de aplicaciones embebido (Tomcat, Jetty o Undertow).
• Inversión de control e inyección de dependencias: Spring Boot proporciona una
serie de dependencias, llamadas starters, que se pueden añadir al proyecto dependiendo
de lo que se necesite: crear un controlador REST, acceder a una base de datos usando
JDBC, etc.
• Arquitectura REST: Con Spring Boot se pueden crear APIs propias y desplegar ser-
vicios REST que interactúen con otros servicios.
5.1.6 Hibernate y JPA
Hibernate[8] es una herramienta de Object-Relational Mapping (ORM) que maneja el ma-
peo relacional de objetos para el lenguaje de programación Java. Esto consiste en la persis-
tencia automatizada y transparente de los objetos de una aplicación en una base de datos
relacional, utilizando metadatos que describen el ”mapeo” entre los objetos y la base de datos.
28
CAPÍTULO 5. FUNDAMENTOS TECNOLÓGICOS
Hibernate implementa como parte de su código la especificación de JPA[9]. Esto quiere
decir que se puede usar Hibernate para construir una capa de persistencia apoyándose en
las definiciones y reglas que especifica el estándar JPA, que es lo que se ha hecho para este
proyecto.
5.1.7 JUnit
JUnit[10] es un conjunto de bibliotecas utilizadas para hacer pruebas unitarias de aplica-
ciones Java. Define un conjunto de clases que permite realizar la ejecución de clases Java de
manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la
clase se comporta como se espera.
5.2 Tecnologías utilizadas en el frontend
En esta sección se explicarán las herramientas y tecnologías utilizadas en la parte frontend.
Debido a que no todas, pero algunas de estas tecnologías son comunes para ambas aplicacio-
nes, se explicarán de forma conjunta.
5.2.1 TypeScript
TypeScript[11] es el lenguaje que se ha utilizado para desarrollar la parte frontend de
ambas aplicaciones de este TFG. Es un superconjunto de JavaScript, al que se añade tipado
estático y objetos basados en clases. Se trata de un lenguaje fuertemente tipado, capaz de
funcionar en cualquier programa que ejecute JavaScript.
5.2.2 Single Page Application (SPA)
Una Single Page Application (SPA), es un tipo de aplicación web donde todas las pantallas
se muestran en la misma página, sin necesidad de recargar el navegador. En una SPA, como
el propio nombre indica, existe una única página, generalmente el archivo index.html, y toda
la acción se produce dentro de esta.
5.2.3 Angular
Angular[12] es un framework de código abierto construido sobre TypeScript. Es multipla-
taforma, por lo que puede ser utilizado tanto para desarrollar aplicaciones web, como servi-
dores, como aplicaciones móvil nativas. Está basado en componentes y sigue un patrónModel
View Controller (MVC) asegurando un desarrollo rápido y fluido, evitando escribir código re-
petitivo y manteniéndolo ordenado.
29
5.2. Tecnologías utilizadas en el frontend
Angular usa enlace bidireccional:
• Enlace de eventos o event binding: Responden a la interacción del usuario al modi-
ficar alguna entrada en la vista, actualizando el modelo.
• Enlace de propiedades o property binding: Permite agregar valores modificados del
modelo a la vista.
Arquitectura
Angular genera plantillas con HTML y controla esas plantillas con la lógica contenida en
los componentes. Así mismo, se define la lógica de los servicios para manejar los datos de la
aplicación y finalmente se encapsulan estos componentes y servicios enmódulos oNgModules.
En la imagen 5.1 se puede observar un esquema de esta arquitectura.
Figura 5.1: Arquitectura de Angular
• Módulos: Un módulo declara un contexto de compilación para un conjunto de com-
ponentes. Puede asociar sus componentes con código relacionado, como servicios, para
formar unidades funcionales. Cada aplicación generada con Angular cuenta con unmo-
dulo raíz llamado AppModule, el cual se encarga de arrancar la aplicación.
• Componentes: Al igual que el módulo raíz, existe un componente raíz AppComponent
que conecta una jerarquía de componentes con el DOM. Cada componente define una
clase que contiene datos y lógica, y está vinculada a una plantilla.
• Plantillas: Una plantilla es una combinación entre el marcado Angular con HTML para
modificar los elementos HTML y el DOM antes de que se muestren, lo cual hace me-
diante directivas que enlazan la lógica del componente con la vista.
• Servicios: Los servicios sirven para compartir información entre componentes o inclu-
so hacer peticiones. Básicamente contienen la lógica de un componente que no afecta
a la vista.
30
CAPÍTULO 5. FUNDAMENTOS TECNOLÓGICOS
• Inyección de dependencias: Permite manejar las clases de los componentes de for-
ma eficiente, y delegan la obtención de datos a los servicios. Cada servicio cuenta con
la notación @Injectable() que provee metadatos que le permiten ser inyectado en un
componente como dependencia.
5.2.4 Ionic
Ionic[13] es un framework de código abierto que permite desarrollar aplicaciones web
orientadas a móvil, basado en JavaScript, HTML y CSS. En otras palabras, es una herramienta
que facilita y acelera la creación de componentes web específicos para el móvil.
5.2.5 Capacitor
Capacitor[14] es un framework creado por Ionic que permite el desarrollo de aplicaciones
híbridas, es decir, que con una única base de código se pueda obtener tanto una aplicación web
como una nativa. Además, ofrece una serie de plug-ins que permiten acceder e interactuar con
las funciones nativas del dispositivo (por ejemplo abrir la cámara).
5.2.6 Node Package Manager (npm)
Npm[15] es el sistema de gestión de paquetes por defecto para Node.js. Los paquetes del
proyecto se almacenan en una carpeta llamada node_modules. La configuración de cada uno
de estos paquetes se define en un archivo llamado package.json.
5.2.7 Visual Studio Code
Visual Studio Code (VS Code)[16] es un editorde código fuente que cuenta con una amplia
variedad de extensiones, que hacen que sea altamente configurable (soporte para multitud de
lenguajes, apariencias, etc.). Además permite ser integrado con Git, soporte para depuración
y otras funcionalidades útiles a la hora de programar como resaltado y finalización inteligente
de código.
5.3 Tecnologías adicionales
5.3.1 Git
Git[17] es un sistema de control de versiones distribuido diseñado principalmente para
poder gestionar ágilmente el versionado de aplicaciones con un gran número de archivos de
código fuente. Al ser distribuido, permite al equipo de desarrollo generar copias locales del
repositorio sobre las que se trabaja directamente.
31
5.3. Tecnologías adicionales
5.3.2 Git Kraken
Git Kraken[18] es una herramienta multiplataforma que permite manejar Git de manera
sencilla. Cuenta con una interfaz de usuario muy lograda e intuitiva, lo que agiliza las tareas
de control de versiones en un proyecto, aumentando la productividad del programador.
5.3.3 AzureDevOps
Azure DevOps[19] es un conjunto de herramientas y servicios que ayudan a la administra-
ción del ciclo de vida de los proyectos de desarrollo de software. Es independiente del lenguaje
de programación y plataforma en la que se desarrolle el proyecto. Azure DevOps se puede in-
tegrar con una gran variedad de plataformas, como GitHub, Docker o Slack. Está compuesto
por varios módulos:
• Azure Boards: Permite administrar los esfuerzos de desarrollo de uno o varios proyec-
tos a través de listas de tareas, backlogs, gestión de Sprints de Scrum, etc.
• Azure Repos: Es un servicio para el almacenamiento de repositorios de código fuente.
Soporta dos sistemas de control de versiones: Git y Team Foundation Version Control.
• Azure Pipelines: Es un servicio de integración y despliegue continuos que permite
definir pipelines, automatizar las fases de desarrollo, compilación, pruebas y despliegue
de proyectos software.
• Azure Test Plans: Permite hacer definiciones de pruebas como pruebas de carga o de
aceptación y llevar un seguimiento de la ejecución de esos tests mediante gráficas.
• Azure Artifacts: Este servicio es un sistema de almacenamiento de componentes que
permite a los desarrolladores compartir y consumir paquetes de diferentes fuentes.
• 7space Timetracker: Es una herramienta integrada en Azure DevOps para registrar
el tiempo dedicado a cada tarea y llevar un control de las horas reales trabajadas por
cada miembro del equipo de desarrollo.
5.3.4 Docker
Docker[20] es una plataforma de software que permite crear, probar e implementar apli-
caciones de una forma sencilla, así como copiarlas o trasladarlas de un entorno a otro. Esto lo
consigue mediante el empaquetado del software en unidades estandarizadas llamadas conte-
nedores que incluyen todo lo necesario para que el software se ejecute, incluyendo bibliote-
cas, herramientas de sistema, código y tiempo de ejecución.
32
Capítulo 6
Desarrollo
En este capítulo se explicará el desarrollo iterativo del trabajo realizado en cada Sprint delproyecto. Para ello, se argumentará detalladamente el proceso técnico y funcional que
se ha seguido.
6.1 Modelo y persistencia de datos
6.1.1 Modelo de datos
Ambas aplicaciones comparten un mismo modelo de datos, que se puede ver en la imagen
6.1. Este modelo gira entorno a la entidad Route. Una ruta puede ser de dos tipos, una ruta de
entidad (Entity route) o una ruta punto-a-punto (FromToRoute).
Las rutas de entidad tienen un elemento de mantenimiento o EntityItem y una municipa-
lidad (Municipality) asociadas, que ayudan a distinguir una ruta según el elemento sobre el
que se va a trabajar (por ejemplo un río o lago concreto) y el lugar en el que se va a recorrer.
Cada EntityItem pertenece a un Entity Type, que no es más que un tipo que clasifica los Entity
Items.
Las rutas punto-a-punto tienen un punto o Waypoint de inicio, que representa el lugar
en donde comienza la ruta, y un punto final, que representa el lugar donde acaba la ruta. Un
Waypoint consiste en un conjunto formado por un número y una municipalidad, y represen-
tan un punto concreto en un mapa.
Los usuarios (User) crean rutas, y cada ruta puede contener varios eventos (Events). Cada
uno de los eventos que se creen para una ruta tendrá una categoría (EventCategory) asociada,
y podrá contener una imagen (RegularFile).
33
6.1. Modelo y persistencia de datos
Figura 6.1: Diagrama de entidades
Hay que destacar que por adaptación a las normas de la empresa se reutilizaron algunas
entidades ya existentes para este modelo de datos. Es el caso de las entidades User y Regular-
File.
6.1.2 Persistencia de datos
Para abordar la persistencia de datos de las aplicaciones, se optó una base de datos tradi-
cional ejecutada en un contenedor Docker. Se optó por esta opción ya que como se ha visto
anteriormente (sección 5.3.4), Docker supone una gran ventaja a la hora de copiar, trasladar y
ejecutar entornos. De esta forma es más sencillo para los miembros de la empresa compartir
bases de datos ya configuradas sin necesidad de instalar software adicional (a excepción del
propio Docker).
Se utilizó MySQL como SGDB ya que se decidió que una base de datos relacional era más
adecuada para el desarrollo de este proyecto.
Para la ejecución de los test del backend se utilizó una base de datos en memoria llamada
h2. Una de sus grandes ventajas es que puede trabajar como una base de datos embebida en
aplicaciones Java. Su integración se define en el pom.xml de la siguiente forma:
1 <dependency>
2 <groupId>com.h2database</groupId>
3 <artifactId>h2</artifactId>
4 <scope>test</scope>
5 </dependency>
34
CAPÍTULO 6. DESARROLLO
6.2 Iteración 0. Creación de la estructura base del proyecto
Como ya se comentó en la sección 4.1, la empresa cuenta con estructuras base para la
creación de nuevos proyectos. Estas estructuras funcionan como un ”código plantilla” que se
puede instalar fácilmente e ir adaptando a las necesidades de cada proyecto.
6.2.1 Creación del servicio
El backend de la empresa sigue una arquitectura de microservicios, en la que cada micro-
servicio abarca unas funcionalidades concretas de la aplicación independientes del resto (por
ejemplo, existe un servicio para gestionar los usuarios, otro para gestionar las rutas, etc.).
Funcionan como pequeños módulos de software independientes que se comunican a través
de una API. De esta forma, si uno de los microservicios falla, el resto no se verán afectados.
Otras ventajas que tiene este tipo de arquitectura son el desarrollo escalable del software, la
libertad de diseño para cada servicio, y la reutilización de código que supone.
Para la creación de este nuevo servicio se utilizó un arquetipoMaven propio de la empresa,
que pudo ser generado mediante el comando:
mvn archetype:generate -DarchetypeGroupId=es.streamnow
-DarchetypeArtifactId=service-archetype
-DarchetypeVersion=0.0.0-SNAPSHOT -DgroupId=com.smarsol
-DartifactId=contacts -Dversion=0.0.0-SNAPSHOT
-Dpackage=com.smarsol.contacts -DaldeaVersion=7.0.0
Este proyecto maven, sigue la siguiente estructura:
• src/main/java: En esta carpeta se encuentra el código fuente del servicio, estructurado
en paquetes. En el paquete raíz se encuentra el archivo Application.java, que contiene
la clase Application:
1 @SpringBootApplication
2 public class Application extends DefaultApplication {
3
4 public static void main(String[] args) {
5 SpringApplication.run(Application.class, args);
6 }
7 }
8
Mediante la notación @SpringBootApplication, se invocará a la herramienta SpringBoot
(sección 5.1.5) que se encargará de arrancar la aplicación en un servidor Tomcat embe-
bido.
35
6.2. Iteración 0. Creación de la estructura base del proyecto
• src/main/resources: Contiene los scripts de la base de datos donde se declaran las sen-
tencias que se quieren ejecutar en ella, como la creación o modificación de tablas. Ade-
más contiene archivos de configuración, en los que se gestionan aspectos como la co-
nexión con la base de datos.• src/test/java: En esta carpeta se incluyen los test de la aplicación, organizados en pa-
quetes. En la declaración de cada test, se utilizará la notación@RunWith(SpringRunner.class)
Mediante esta configuración le decimos a JUnit que utilice la herramienta de testing de
Spring. Se distinguen principalmente 3 tipos de test:
– Test de clases: Siguen la convención de nombrado XXXDaoTest.java. Son los test
para los DAOs del servicio. Para poder ejecutarlos con Spring, se incluirá la si-
guiente notación:
1 @RunWith(SpringRunner.class)
2 @DataJpaTest(showSql = false)
3 public class RouteDAOTest {
4 ...
5 }
6
Mediante @DataJpaTest(showSql = false) se indica que se aplique sólo la configu-
ración de test para DAOs (repositorios JPA) y que no se muestren las queries SQL.
– Test de servicios: Se utilizan para probar los servicios del backend, que son las
clases con la notación@Service. Para ejecutarlos se especificará la misma configu-
ración que para los test de clases. Se nombran de la forma XXXServiceTest.java.
– Test de controladores: Estos test siguen la convención de nombrado XXXCon-
trollerTest.java. Se utilizará una herramienta llamadaMockito, que ayudará a crear
objetos simulados para poder probar los controladores de la aplicación. Cada uno
de estos test tendrá un aspecto similar al siguiente:
1 @RunWith(SpringRunner.class)
2 @WebMvcTest(RoutesController.class)
3 public class RoutesControllerTest {
4
5 @MockBean
6 RouteService routeService;
7 ...
8 }
9
Mediante la notación @WebMvcTest se establece la configuración de los test ne-
cesaria para probar elementos @Controller, entre otros. Y mediante @MockBean,
36
CAPÍTULO 6. DESARROLLO
se invoca a Mockito para generar una instancia simulada en este caso del servicio
RouteService.
6.2.2 Creación de la aplicación web
Para la creación de la web, se partió de un proyecto básico ya existente en un repositorio de
la empresa, que se utilizó como plantilla. Esta aplicación base contiene la siguiente estructura
(figura 6.2):
(a) Estructura de la apli-
cación web
(b) Detalle de la carpeta
src de la aplicación web
Figura 6.2: Estructura de la aplicación web
• src/app: Contiene el código fuente de la aplicación, diferenciado por directorios según
los elementos vistos en la sección 5.2.3.
• app-routing-module.ts: En este archivo se configuran las rutas por las que el usuario
navegará en la aplicación.
• app.component.ts: En él se encuentra el AppComponent, que es el componente raíz del
proyecto, dentro del cual se mostrarán todos los demás componentes que se creen en la
aplicación.
• app.module.ts: En él se encuentra el AppModule, que es el módulo donde se definen
los componentes que utiliza la aplicación.
37
6.2. Iteración 0. Creación de la estructura base del proyecto
• index.html: Es la única página de una SPA. En este archivo HTML se incluirá un tag
personalizado por Angular llamado <app-root>, que representa el AppComponent.
• main.ts: Es el archivo donde se especifica el punto de arranque de la aplicación, con-
cretamente en este fragmento:
1 import { platformBrowserDynamic } from
'@angular/platform-browser-dynamic';
2 import { AppModule } from './app/app.module';
3
4 platformBrowserDynamic().bootstrapModule(AppModule)
5
• package.json: En este fichero se define el nombre de la aplicación, el número de versión,
scripts para arrancarla y sus dependencias.
6.2.3 Creación de la aplicación móvil
Para crear una aplicación móvil nueva se utilizó Lerna, que es una herramienta utilizada
para crear aplicaciones monorepo invocado un comando. Una aplicación monorepo permite
que en el mismo repositorio, puedan coexistir varias aplicaciones, lo que supone una gran
ventaja a la hora de reutilizar código.
Debido a las normas de desarrollo de la empresa, esta aplicación se creó dentro de unmo-
norepo, en el que en el futuro podrán existir otras aplicaciones que compartan funcionalidades
o dependencias con ella. Para crear el monorepo se utilizó el comando:
lerna init
A continuación se generó un directorio /apps, en el que se crearán las aplicaciones del
monorepo. Una vez en este directorio, creamos la aplicación Ionic Framework Angular mediante
el comando:
ionic start fiestra-wega sidemenu --type=angular
Este comando genera una aplicación Ionic integrada con Angular y Capacitor, con un menú
incorporado. La aplicación en su estado inicial presenta la estructura mostrada en la imagen
6.3.
38
CAPÍTULO 6. DESARROLLO
Figura 6.3: Estructura de la aplicación móvil
Algunos aspectos que caben destacar de esta estructura son:
• apps/ : Es el directorio en el que se alojarán las aplicaciones de este monorepositorio.
fiestra-wega es la única existente por el momento, y es la aplicación que se desarrollará
en este TFG.
• lib/src: Este directorio tiene una estructura similar al directorio /src de la aplicación
web, explicado en la sección 6.2.2.
• lerna.json: En él se especifican los directorios clave del monorepo y su versión.
Por último, cabe destacar que durante este Sprint inicial, se incorporó para la aplicación
móvil un componente existente en otras aplicaciones relativo a las vistas de login y logout de
usuarios. Cuando el usuario no está autenticado, se muestra la pantalla de login (figura 6.4).
Figura 6.4: Vista login de la aplicación móvil
Una vez se autentica, se muestra el sidemenu que se creó automáticamente con Ionic, con
la entrada logout (figura 6.5).
39
6.3. Iteración 1. Creación de rutas en la aplicación móvil
Figura 6.5: Menú de la aplicación móvil
De la misma forma, en la aplicación web se incorporaron módulos existentes en otros
proyectos accesibles mediante entradas diferenciadas del menú principal. Estos módulos co-
rresponden a:
• Gestión de usuarios
• Integración con plataformas externas
• Gestión de plantillas de correo para notificaciones
• Gestión de términos y condiciones legales
• Gestión de menús para las aplicaciones
Cada uno de estos módulos se corresponde con un microservicio del backend. Fueron
incorporados con previsión de futuro, aunque actualmente el único que se utiliza para esta
plataforma es la gestión de usuarios. Esta es la razón por la que se excluye esta funcionalidad
del proceso de desarrollo del proyecto.
6.3 Iteración 1. Creación de rutas en la aplicación móvil
6.3.1 Análisis
En este Sprint se abordó el caso de uso referente a la creación de rutas en la aplicación mó-
vil. A continuación se muestra una tabla con la historia de usuario resuelta para esta iteración
y su descomposición en tareas (tabla 6.1).
40
CAPÍTULO 6. DESARROLLO
H19 - Crear ruta
Como empleado quiero crear rutas de entidad y punto-a-punto desde la aplicación móvil
Tareas
[BACKEND] Añadir soporte en el backend para crear una ruta
[BACKEND] Añadir soporte en el backend para recuperar los entityTypes.
[BACKEND] Añadir soporte en el backend para recuperar los entityItems de un entityType
[BACKEND] Añadir soporte en el backend para recuperar las municipalidades
[BACKEND] Añadir soporte en el backend para recuperar los waypoints de una municipa-
lidad
[APP] Crear módulo para el registro de rutas
[APP] Crear pantalla para elegir un tipo de ruta
[APP] Crear pantalla para crear una ruta de entidad
[APP] Crear pantalla para crear una ruta punto-a-punto
Tabla 6.1: Iteración 1: Creación de rutas en la aplicación móvil
6.3.2 Implementación y diseño
Al ser el primer Sprint de desarrollo como tal del proyecto, se requerirá más implementa-
ción en el backend que en Sprints futuros.
Todas las tareas de backend se requieren para el formulario de creación de la ruta. Esto
se debe a que en este formulario, el usuario escogerá por medio de selectores algunos de los
atributos de una ruta. Por lo que, a excepción de la primera tarea, será necesario que el API
devuelva todas las opciones disponibles de cada entidad para que el usuario elija.
En la figura 6.6 se puede observar la estructura desarrollada para la creación de estas enti-
dades, en este caso de los EntityTypes. En cada una, existe un controlador REST XXXController,