web con microservicios
Ingeniería del Software Trabajo final de Grado
Pablo Cebollada Hernández
Director: Lluís Grau Turigas Ponente: Marc Alier Forment Tutor GEP: Joan Subirats Soler
18/10/2021
Resumen
El propósito del proyecto Creación de una aplicación web con microservicios es crear una aplicación web para la empresa Telespazio con el objetivo de: crear un entorno donde encontrar las aplicaciones corporativas que desarrolle la empresa en un futuro, hacer una migración del frontend a Angular de una aplicación llamada Conthora, crear una aplicación Marcajes con la que los trabajadores puedan fichar de una manera más fácil a la que hay ahora y gestionar la seguridad de la aplicación con un sistema de inicio de sesión con contraseña.
El propòsit del projecte Creació d'una aplicació web amb microserveis és crear una aplicació web per a l'empresa Telespazio amb l'objectiu de: crear un entorn on trobar les aplicacions corporatives que desenvolupi l'empresa en un futur, fer el port del frontend a Angular d’una aplicació anomenada Conthora, crear una aplicació Marcatges amb la qual els treballadors puguin fitxar d'una manera més fàcil a la qual hi ha ara i gestionar la seguretat de l'aplicació amb un sistema d'inici de sessió amb contrasenya.
The purpose of the project Creation of a web application with microservices is to create a web application for the company Telespazio with the aim of: creating an environment where to find the corporate applications that the company will develop in the future, make a migration of the frontend to Angular of an application called Conthora, creating a marking application with which workers can sign in in an easier way than the current one and managing the security of the application with a password login system.
Índice General
1. Contexto del proyecto 10
1.1. Contextualización general 10
1.2. Terminología 10
1.3. Identificación del problema 11
1.4. Stakeholders 11
2. Justificación 13
2.1. Unificación tecnologías 13
2.2. Creación de Aplicaciones Corporativas 13
2.3. Aplicación Marcajes 14
2.4. Conclusiones 14
3. Alcance 15
3.1. Objetivos 15
3.2. Obstáculos y riesgos 15
3.2.1. Tiempo 15
3.2.2. Pérdida de contenido 16
3.2.3. Bugs 16
4. Metodología 17
4.1 Git 18
4.2 Microsoft Planner 18
5. Planificación temporal 19
5.1. Tareas 19
5.1.1 Gestión del proyecto 19
5.1.2 Desarrollo 19
5.1.3 Documentación 20
5.2 Recursos 20
6. Estimación y Gantt 22
7. Gestión de riesgos 24
7.1 Bug 24
7.2 Riesgos externos 24
7.3 Nuevas funcionalidades 24
8. Presupuesto 25
8.1. Identificacion y estimacion de costes 25
8.1.1. Recursos humanos 25
8.1.2. Recursos Materiales 27
8.1.3. Recursos generales 27
8.1.4. Costes de contingencia 28
8.1.5. Costes de imprevistos 28
8.1.6. Presupuesto final 29
8.1.7. Control de gestión 29
9. Sostenibilidad 30
9.1. Autoevaluación 30
9.2. Dimensión ambiental 30
9.3. Dimensión económica 30
9.4. Dimensión social 30
10. Leyes y regulaciones 32
11. Integración de conocimientos 33
12. Especificación de requisitos 34
12.1 Requisitos funcionales 34
12.1.1 Listado de requisitos funcionales 34
12.1.2 Diagrama de casos de uso 35
12.1.3 Casos de uso 37
12.2 Requisitos no funcionales 42
12.3 Modelo de datos 43
12.3.1 Acceso y credenciales 43
12.3.2 Marcajes API 45
12.3.3 Conthora API 46
13 Arquitectura del sistema 47
13.1 Arquitectura de microservicios 47
13.1.1 Despliegue 48
13.2 Arquitectura física 48
13.3 Arquitectura lógica 49
13.3.1 Frontend 49
13.3.2 Backend 51
13.3.3 Base de datos 54
13.4 Pantallas 55
13.4.1 Pantalla inicio de sesión 55
13.4.2 Establecer contraseña 57
13.4.3 Página principal 58
13.4.4 Entrada de datos 60
13.4.5 Consulta de datos (Conthora) 61
13.4.6 Marcaje Diario 62
13.4.7 Marcando Jornada 63
13.4.8 Fin Jornada 64
13.4.10 Consulta Marcajes Totales 66
13.5 Patrones de diseño utilizados 66
14. Implementación 67
14.1 Tecnologías, lenguajes y herramientas 67
14.1.1 Tecnologías y lenguajes 67
14.1.2 Herramientas 69
14.2 Aspectos relevantes de la aplicación 72
14.2.1 Endpoints 72
14.2.2 Inicio de sesión, Token y autorización 73
14.2.3 Tokens expirados 75
15. Conclusiones 76
15.1 Conclusiones del proyecto 76
15.2 Análisis de las competencias técnicas del TFG 77
16. Referencias 78
Índice de figuras y tablas
1. Contexto del proyecto 10
2. Justificación 13
3. Alcance 15
4. Metodología 17
Figura 4.1: Esquema de la metodología Agile. (Fuente: Google Images) 17
5. Planificación temporal 19
6. Estimación y Gantt 22
Figura 6.1: Tabla con las tareas totales 22
Figura 6.2: Diagrama de Gantt 23
7. Gestión de riesgos 24
Figura 7.1: Tabla con los riesgos 24
8. Presupuesto 25
Figura 8.1: Tabla con sueldos de los trabajadores 25
Figura 8.2: Tabla con los precios por horas 26
Figura 8.3: Tabla con los precios de los materiales 27
Figura 8.4: Tabla con los precios de los recursos generales 27
Figura 8.5: Tabla con los costes de contingencia 28
Figura 8.6: Tabla con los costes imprevistos 28
Figura 8.7: Tabla con el presupuesto final 29
9. Sostenibilidad 30
10. Leyes y regulaciones 32
11. Integración de conocimientos 33
12. Especificación de requisitos 34
Figura 12.1: Diagrama casos de uso Acceso y credenciales 35
Figura 12.2: Diagrama casos de uso Marcajes 36
Figura 12.3: Diagrama de casos de uso Conthora 36
Figura 12.4: Caso de uso Iniciar sesión 37
Figura 12.5: Caso de uso Cerrar Sesión 37
Figura 12.6: Caso de uso Establecer contraseña 38
Figura 12.7: Caso de uso Cambiar contraseña 38
Figura 12.8: Caso de uso Empezar jornada 39
Figura 12.9: Caso de uso Hacer descanso 39
Figura 12.10: Caso de uso Acabar descanso 39
Figura 12.11: Caso de uso Acabar jornada 40
Figura 12.12: Caso de uso Consultar marcajes 40
Figura 12.13: Caso de uso Consultar marcajes totales 40
Figura 12.14: Caso de uso Imputar horas 41
Figura 12.15: Caso de uso Eliminar registro de la tabla 41
Figura 12.16: Caso de uso Guardar en BD 41
Figura 12.17: Caso de uso Consultar horas imputadas 42
Figura 12.18: Diagrama de clases usadas en Acceso y credenciales 43
Figura 12.19: Diagrama de clases usadas en Marcajes API 45
13 Arquitectura del sistema 47
Figura 13.1: Esquema de la arquitectura microservicios 47
Figura 13.2: Esquema arquitectura física 48
Figura 13.3: Esquema arquitectura lógica 49
Figura 13.4: Ejemplo de contenido de un archivo interface 50
Figura 13.5: Ejemplo de una clase controlador 51
Figura 13.6: Ejemplo de una clase servicio 52
Figura 13.7: Ejemplo de una clase DAO 52
Figura 13.8: Ejemplo de una clase Entity 1 53
Figura 13.9: Ejemplo de una clase Entity 2 53
Figura 13.10: Ejemplo de una clase EntityPK 1 54
Figura 13.11: Ejemplo de una clase EntityPK 2 54
Figura 13.12: Inicio de sesión sin datos 55
Figura 13.13: Inicio de sesión con datos 56
Figura 13.14: Inicio de sesión con datos erróneos 56
Figura 13.15: Cambio de contraseña sin datos 57
Figura 13.16: Cambio de contraseña con datos 57
Figura 13.17: Cambio de contraseña campos con error 58
Figura 13.18: Página principal 58
Figura 13.19: Desplegable usuario 59
Figura 13.20: Entrada de datos 60
Figura 13.21: Entrada de datos por otro usuario 60
Figura 13.22: Tabla con entradas 61
Figura 13.23: Confirmación eliminar 61
Figura 13.24: Ejemplo error horas 61
Figura 13.25: Ventana Consulta de Datos 61
Figura 13.26: Ventana Consulta de Datos con Datos 62
Figura 13.27: Ventana Marcaje Diario 62
Figura 13.28: Ventana Marcando Jornada 63
Figura 13.29: Confirmación finalizar jornada 63
Figura 13.30: Ventana con un descanso activo 64
Figura 13.31: Notificación recordatorio descanso 64
Figura 13.32: Ventana Fin Jornada 64
Figura 13.33: Ventana Consulta Marcajes Online sin búsqueda 65 Figura 13.34: Ventana Consulta Marcajes Online con búsqueda 65
Figura 13.35: Ventana Consulta Marcajes Totales 66
14. Implementación 67
Figura 14.1: Logo Java 66
Figura 14.2: Logo Spring Boot 66
Figura 14.3: Logo Angular 67
Figura 14.4: Logo Typescript 67
Figura 14.5: Logo HTML 67
Figura 14.6: Logo CSS 68
Figura 14.7: Logo IntelliJ IDEA Ultimate 68
Figura 14.8: Logo Webstorm 69
Figura 14.9: Logo SQL Server Management Studio 69
Figura 14.10: Logo Postman 69
Figura 14.11: Logo Git 70
Figura 14.12: Logo Redmine 70
Figura 14.13: Tabla endpoints 71
Figura 14.14: Función configure para Acceso y credenciales 72
Figura 14.15: Función commence 73
Figura 14.16: Función deleteExpiredTokens 74
15. Conclusiones 76
16. Referencias 78
1. Contexto del proyecto
1.1. Contextualización general
Este documento es la memoria del Trabajo de Fin de Grado hecho por Pablo Cebollada Hernández como parte del Grado de Ingeniería Informática de la Facultad de Informática de Barcelona (FIB, UPC) de la especialidad de Software. El proyecto se ha realizado en la empresa Telespazio Ibérica, SLU bajo la supervisión de Lluís Grau Turigas, el director del proyecto, y por parte de la FIB bajo la supervisión de Marc Alier Forment, el ponente del proyecto y Joan Subirats Soler mi tutor de GEP.
Telespazio Ibérica es una empresa de referencia a nivel europeo en el sector de Nuevas Tecnologías aplicadas al Territorio, ofrecen servicios que cubren el ciclo completo desde la generación del dato cartográfico con las últimas tecnologías, hasta el desarrollo de soluciones informáticas combinando Sistemas de Información Geográficos (SIG), telecomunicaciones y dispositivos móviles [1].
Telespazio Ibérica forma parte del Grupo Telespazio, compañía líder en Europa en provisión de servicios de tecnología satélite y aplicaciones de geoinformación. El Grupo con sede en Roma, cuenta con más de 2.500 empleados, oficinas en 25 países, 4 centros espaciales y una facturación de 546 M€ en 2018. Telespazio participa en programas europeos de referencia en el ámbito espacial como son GALILEO, EGNOS, Copernicus y COSMO-SkyMed [1].
1.2. Terminología
● Angular: Es una plataforma de desarrollo construida sobre TypeScript y desarrollada por Google y la propia comunidad [2]. Para este proyecto se ha utilizado la versión 11.
● React: Es una biblioteca JavaScript para crear interfaces de usuario, desarrollado por Facebook y por la comunidad [3].
● Frontend: Llamamos frontend a la parte del sitio web con la que el usuario interactúa. Es lo que algunos suelen llamar “el lado del cliente” [4].
● Backend: se encarga de la comunicación con la BBDD y securiza los datos para que no sean consumidos directamente. Ofrece servicios consumidos por el frontend para mostrar contenido dinámico.
● Spring: es un framework para el desarrollo de aplicaciones y contenedor de inversión de control, de código abierto para la plataforma Java [5].
1.3. Identificación del problema
La idea para este TFG surge mientras estaba dentro de un proyecto de migración de una aplicación desarrollada para otro TFG del alumno Arnau Comellas. Dicha aplicación recibe el nombre de Conthora y sirve para visualizar y contabilizar las horas que un empleado le dedicaba a un proyecto, estaba en React y debía de migrar a Angular y era de uso exclusivo de la empresa.
A Telespazio se le ocurrió la idea de crear una aplicación web que contuviese en un mismo espacio las aplicaciones que se usan día a día y así el empleado de la empresa pudiese encontrar tanto esta aplicación, como otras que se desarrollen en un futuro para la empresa. Actualmente, estas aplicaciones están separadas en sus respectivos programas y cada vez que deseas acceder a una de ellas debes de iniciar sesión con tus credenciales, además estas aplicaciones están desarrolladas en Microsoft Access, un gestor de bases de datos.
Para completar más el proyecto, desde el departamento de Recursos Humanos pidieron que se desarrollará una nueva aplicación para ellos y que se encontrase dentro del nuevo espacio que se había de implementar. Esta aplicación se llamará Marcajes y servirá para visualizar y contabilizar los marcajes de los empleados, horas de entrada y salida y también para los casos que descanso donde se encontrarán el desayuno, la comida y una categoría para otros. Esta idea surge de la necesidad de una aplicación propia para los marcajes especialmente de aquellos que teletrabajan.
1.4. Stakeholders
Recursos humanos
Uno de los principales clientes de la aplicación, se encarga de supervisar la parte de la Aplicación de Marcajes. Buscan que el proyecto sea un éxito para facilitar una correcta contabilización de las horas y ofrecer a su vez un buen sistema para todos aquellos que teletrabajan.
Departamento TI
Otro de los principales clientes de la Aplicación, en este caso se encarga de supervisar la parte de la Aplicación de Conthora. Desean que su aplicación Conthora se encuentre operativa en el nuevo espacio.
Telespazio Ibérica
El interés de contar con una aplicación que pueda englobar unas de más pequeñas bajo un mismo sitio es lo que hace que la empresa cuente como un stakeholder, ya que cuando se acabe el proyecto tendrán a su disposición un lugar donde desplegar otras aplicaciones corporativas.
Yo, como estudiante
Pablo Cebollada Hernández es un cliente directo de este proyecto, ya que por su éxito, él conseguirá tanto experiencia laboral para el futuro como la obtención del título universitario que acredita que se ha graduado de la carrera de Informática.
Ponente y tutor de GEP
Tanto Marc Alier como Joan Subirats son personas externas al proyecto de la empresa, pero igualmente tienen el propósito que el proyecto tenga éxito.
2. Justificación
Como se ha detallado anteriormente y habiendo analizado el contexto del problema, la empresa Telespazio necesita la implementación de esta aplicación web por diferentes motivos. Por una parte, es verdad que la empresa cuenta con algunas aplicaciones ya creadas, pero estas son independientes entre ellas, esto quiere decir que debes registrarte en cada aplicación que desees acceder con tu cuenta. Por otra parte, estas aplicaciones están programadas en Microsoft Access lo que hace que estén directamente atacando a las bases de datos por cada interacción que hacen con las aplicaciones es decir no hay ninguna capa entre la aplicación y la base de datos. Por otra parte, una aplicación como la que pide Recursos Humanos de Marcajes no existe actualmente, lo más parecido con lo que se cuenta son las instancias de comisión de trabajo, pero es un procedimiento un tanto engorroso. Finalmente, es necesario unificar bajo unas mismas directrices las tecnologías que se usarán en cada parte del proyecto, para que así todo el proyecto tenga cohesión entre él y conseguir la máxima eficiencia, además de asegurarse que si en algún momento falla algo o hay que añadir nuevas funcionalidades sea más sencillo.
2.1. Unificación tecnologías
Telespazio escogió las tecnologías de Angular para el frontend y Spring para el backend para implementar las aplicaciones corporativas. Esta elección se debe a que tanto en sus respectivos campos, Angular y Spring están siendo utilizados cada vez más por muchos usuarios y empresas lo que se traduce a que tendrán una gran disponibilidad por años y seguirán sacando y corrigiendo versiones haciendo que Telespazio no se tenga que preocupar en hacer otra aplicación como esta en un largo tiempo.
2.2. Creación de Aplicaciones Corporativas
Con el planteamiento de la creación de Aplicaciones Corporativas se busca tener tanto las aplicaciones que la empresa dispone actualmente como las que se pueden desarrollar en un futuro y así que sea más sencillo para los usuarios disponer de ellas, además con la nueva implementación se soluciona el problema que hay con las actuales añadiendo capas entre la aplicación y la base de datos. Todo ello gestionado por un inicio de sesión con nombre de usuario y contraseña para realizar las peticiones bajo un perfil.
2.3. Aplicación Marcajes
La necesidad por la cual Recursos Humanos ha encargado este tipo de aplicación es por qué actualmente no existe nada específico para fichar si estás teletrabajando (el problema no está si asistes presencialmente, ya que hay una máquina, en cualquier caso también se podría utilizar la aplicación). Actualmente, la forma por la cual se ficha si teletrabajas es a través de las instancias, pero esta opción presenta algunas desventajas, como que cada vez que quieres fichar o hacer un descanso tienes que mandar una, que te la aprueben manualmente y luego que, manualmente también, inserten esos datos en la base de datos. Con la nueva aplicación estos procesos se simplificarán, ya que el usuario solo tendría que iniciar mediante un click la jornada y en el caso de querer hacer un descanso solo seleccionar el tipo. De este modo se eliminará el proceso de aprobación e inserción manual y la inserción será automática.
2.4. Conclusiones
Una vez explicadas las necesidades que tiene Telespazio de disponer de una aplicación con las características comentadas inicialmente y después de haber expuesto las tres soluciones propuestas para cubrir estas necesidades se puede llegar a la conclusión que estas cubren las necesidades esenciales de Telespazio y que por eso necesaria la realización de este proyecto para Telespazio.
3. Alcance
En este apartado se explicará con detalle los principales objetivos del TFG y los posibles obstáculos y riesgos que pueden ocurrir.
3.1. Objetivos
Para poder desarrollar con éxito la aplicación web Aplicaciones Corporativas es necesario cumplir los siguientes objetivos:
● Marcajes:
○ Crear la funcionalidad de Marcar, donde el usuario podrá empezar un turno y acabarlo, empezar y acabar un tipo de descanso (Almuerzo, Comida u Otro) o en el caso que ya haya acabado y tiene que volver, podrá reanudar la jornada laboral donde la dejó. Adicionalmente por pantalla se podrá visualizar todas las acciones realizadas en ese día.
○ Crear la funcionalidad de Consultar Marcajes. En ella se diferenciarán dos opciones, marcajes propios de la Aplicación, donde sólo se visualizarán los marcajes realizados desde la aplicación, o Marcajes Totales, donde se podrán visualizar todos los marcajes realizados por el usuario, los de la aplicación y los presenciales en la oficina.
● Aplicaciones Corporativas:
○ Diseñar la arquitectura de la aplicación.
● Acceso y credenciales:
○ Crear una API que gestione la seguridad. Esta debe generar y comprobar tokens para acceder a las demás API y también gestionar el tema de usuarios y contraseñas (crear contraseña, cambiar contraseña, comprobar si existe el usuario, etc).
Si al finalizar el proyecto principal sobra tiempo, se intentará cumplir con el siguiente objetivo:
● Conthora:
○ Añadir la aplicación Conthora a Aplicaciones Corporativas.
3.2. Obstáculos y riesgos
Existen varios riesgos inherentes a todo proyecto de software. En esta sección voy a identificarlos y sugerir diferentes formas de evitar o mitigar estas posibles debilidades.
3.2.1. Tiempo
Como en todo proyecto, el tiempo suele ser un problema que prevalece. Para minimizar este riesgo lo máximo posible se pretende hacer reuniones periódicas en las que se comprobará el estado del proyecto, se hablara de los objetivos que se han cumplido, los que no se han podido resolver y por qué, si durante el proceso han aparecido problemas y el estado de ellos (solucionados o siguen) y se plantean nuevos objetivos con fecha para alcanzar.
3.2.2. Pérdida de contenido
Perder parte del proyecto ya sea código o documentación, según el tamaño, puede llegar a ser un gran problema. En tema de código, todo el código estará guardado en un repositorio de GitLab de la empresa, esto se debe a que el uso de GitLab no solo permite almacenar el código en la nube, también nos permite tener un control de versiones, esto quiere decir que en el caso que necesitemos restaurar el código en algún punto de su desarrollo sea posible. Para documentación se hará uso de Drive, de esta forma la documentación estará almacenada en la nube y será accesible desde cualquier dispositivo.
3.2.3. Bugs
Los errores en el código que aparecen cuando se está produciendo son inherentes al desarrollo de software. Hay dos tipos principales de errores:
- Aquellos que se detectan durante el desarrollo del producto.
- Aquellos que se detectan en el producto final.
Si bien los primeros son bastante fáciles de corregir, los errores en el producto final a veces complican la fase de mantenimiento. Además, teniendo en cuenta la cantidad de tiempo dedicado a revisarerrores durante el desarrollo de un producto, es crucial configurar un entorno de antemano para evitar un sprint de desarrollo lento debido a que solo se enfoca en corregir errores. Para mitigar este riesgo, se establecerá un entorno de prueba para garantizar que el software se produzca con un determinado estándar de calidad.
4. Metodología
El desarrollo del proyecto se hará siguiendo una metodología Agile, en este caso en concreto se utilizará Scrum[6]. Esta es una metodología que intenta reducir la complejidad a la hora de desarrollar un producto. Sprint es una metodología iterativa que destaca por su flexibilidad a la hora de añadir nuevos cambios al proyecto una vez comenzado. Se centra en la colaboración entre los diferentes integrantes del equipo.
Una de las bases de la metodología es el backlog. Se llama backlog al listado de tareas a realizar durante el desarrollo. También se indica el tiempo esperado para completar cada tarea.
En Scrum cada integrante del equipo tiene un rol determinado:
● Scrum Master: encargado de garantizar que se sigue la metodología sin problemas. Se encarga de resolver los diferentes problemas que pueden seguir durante un sprint.
● Product Owner: es la persona responsable de asegurar que el equipo aporte valor al negocio.
Representa las partes interesadas internas y externas, por lo que debe comprender y apoyar las necesidades de todos los usuarios en el negocio, así como también las necesidades y el funcionamiento del Equipo Scrum.
● Desarrolladores: encargados de realizar las diferentes tareas asignadas por el Product Owner.
También se tienen que tener en cuenta los diferentes hitos durante el proceso de desarrollo. Estas giran en torno al sprint. El sprint es una unidad de tiempo relativamente pequeña (no dura más de un mes) durante la cual se han de desarrollar una ciertas funcionalidades.
Los hitos son los siguientes:
● Sprint Planning: reunión en la cual se definirán las tareas a realizar durante el próximo sprint.
● Daily meeting: reuniones diarias en las que cada integrante informa al resto de como va su trabajo respecto al día anterior, si hay errores se abordan.
● Sprint review: reunión en la que se evalúa el producto desarrollado durante el sprint y sus funcionalidades.
● Sprint retrospective: se evalúa la manera en la que se ha implementado la metodología una vez acabado. Se intentan hacer cambios para poder mejorar en el siguiente.
Figura 4.1: Esquema de la metodología Agile. (Fuente: Google Images)
Para el correcto desarrollado se usarán dos herramientas:
4.1 Git
Git [7] es un sistema de control de versiones de código abierto diseñado para mantener de manera cooperativa las versiones de aplicaciones de software. En el caso del proyecto se usará un repositorio. Este tendrá una rama master donde estará la versión unificada y funcional actual. Por otra parte, todo cambio y adición de nueva funcionalidad se hará en una rama llamada “develop”.
Una vez que los cambios son funcionales se llevan a la rama master.
4.2 Microsoft Planner
Microsoft Planner [8] es una aplicación que permite administrar planes de trabajo, de tal forma que facilita asignar de manera organizada diferentes actividades que se tendrán que realizar para cumplir con un plan, la fecha de entrega, así como el o los responsables de llevarla a cabo. Servirá para gestionar todo lo relacionado con la metodología Scrum: backlog, tareas asignadas, fechas, incidencias…
5. Planificación temporal
El proyecto dividirá las diferentes tareas en tres grandes grupos: gestión del proyecto, desarrollo y documentación. Como que este TFG se realiza en modalidad de prácticas con la empresa, el desarrollo corresponderá a las horas de trabajo diarias. Los otros dos bloques contarán con horas no pertenecientes a ella. Como punto de partida del proyecto tomaremos el inicio de las prácticas curriculares 12 de julio de 2021 y como final, el día de entrega de la documentación (enero 2022). La estimación de este proyecto es de 641 h aproximadamente.
5.1. Tareas
A continuación se describen las diferentes tareas a realizar en el proyecto.
5.1.1 Gestión del proyecto
● GP1 - Contextualización y alcance: Definición del alcance del proyecto en el contexto de su estudio. Se debe indicar el objetivo general del TFG, la contextualización, el porqué de la temática (relevancia y justificación), cómo se desarrollará y con qué medios. Se estiman un total de 25 horas.
● GP2 - Planificación: Planificación temporal para la ejecución total del TFG. Se debe proporcionar también una descripción de las diferentes fases del proyecto y los recursos y requerimientos asociados a cada una de las fases. Se estiman un total de 10 horas.
● GP3 - Gestión económica y sostenibilidad: elaboración del documento correspondiente a la tercera entrega con los presupuestos y un informe de sostenibilidad. Se estiman un total de 10 horas.
● GP4 - Documento final GEP: Documento final con la síntesis del proyecto. Agrega los entregables 1, 2 y 3 teniendo en cuenta el feedback de los profesores. Se estiman un total de 20 horas.
5.1.2 Desarrollo
Antes de empezar se definirán algunos conceptos que se repiten a lo largo de este punto:
● Maquetación: cuando se habla de maquetación nos referimos al proceso por el cual se crea, mediante los componentes, la vista de la ventana mediante el fichero html.
● Funcionalidad: desarrollo de la funcionalidad de la ventana a nivel de frontend, es decir, navegación por la ventana (pestañas, desplegables, datos intercambiados, …), validación de los formularios, estructura de código para cargar la ventana inicialmente y funciones preparadas para realizar funcionalidades (botones que activan peticiones REST).
● Carga inicial datos: carga de los datos en la aplicación frontend desde la llamada al backend.
● Flujo completo: interacción completa con los datos cargados del backend con el frontend.
● Servicios API: creaciones de las llamadas REST y de las clases necesarias para la API del backend.
También hace falta añadir que todas las horas de esta categoría (menos CD) al final se le añadirán un 10% de su total debido al tiempo que el jefe del proyecto le dedicara para comprobar que todo esté correcto.
Tareas del Proyecto
● DES1 - Familiarizarse con las tecnologías: en el proyecto se usarán tecnologías con las que no estoy familiarizado. Se calculan alrededor de 20 horas.
● DES2 - Definición arquitectura: definición de la arquitectura que se implementará tanto en el frontend como en el backend y en los contenedores Docker. Se calculan alrededor de 45 horas.
● DES3 - Integración plantilla: Hacer uso de los componentes de la plantilla para aplicar el diseño. Se calculan alrededor de 30 horas.
● DES4 - Securización del acceso: habilitar el acceso a la aplicación solo a aquellos que estén registrados. Se calculan alrededor de 40 horas.
● DES5 - Definición menú: creación de un menú donde alojar las distintas aplicaciones disponibles. Se calculan alrededor de 20 horas
● DES6 - Definición best practices: definición de unas best practices para el desarrollo del proyecto. Se calculan alrededor de 25 horas.
Aplicación Marcajes
● DES7 - Maquetación Marcajes: Se calculan alrededor de 25 horas.
● DES8 - Funcionalidad Marcajes: Se calculan alrededor de 30 horas.
● DES9 - Carga inicial de datos Marcajes: Se calculan alrededor de 30 horas.
● DES10 - Flujo completo Marcajes: Se calculan alrededor de 40 horas.
● DES11 - Servicios API Marcajes: Se calculan alrededor de 25 horas.
Acceso y credenciales
● DES12 - Servicios API Acceso y credenciales: Se calculan alrededor de 45 horas.
Docker
● DES13 - Configuración Docker: creación del contenedor docker. Se calculan alrededor de 30 horas.
5.1.3 Documentación
● DOC1 - Documentación: documentación del desarrollo y redacción de la memoria final. Se calculan alrededor de 90 horas.
● DOC2 - Preparación presentación: preparación de la defensa del trabajo. Se calculan alrededor de 30 horas.
● DOC3 - Reuniones: diferentes reuniones con el tutor y con el ponente del trabajo durante todo el proyecto.
5.2 Recursos
A continuación se nombran los recursos necesarios para un correcto desarrollo del proyecto, tanto humanos como materiales:
● Recursos humanos: en el proyecto participan diferentes personas. Por una parte yo, como realizador del trabajo, cubriré el rol de becario Fullstack en el proyecto. Por la otra el tutor y el ponente del TFG se aseguran de un correcto desarrollo. También contaré con el apoyo de algún trabajador de Telespazio en algún campo.
● Recursos materiales: diferentes materiales con los que contará para realizar el proyecto.
○ Webstorm: IDE para el desarrollo del frontend.
○ IntelliJ: IDE para el desarrollo del backend.
○ Git: herramienta de control de versiones.
○ Microsoft SQL Server: herramienta para la gestión de la base de datos.
○ Drive: herramienta para almacenar la documentación del proyecto.
○ Google Docs: herramienta para redactar la documentación.
○ Docker: herramienta para automatizar el despliegue de aplicaciones.
○ Google Chrome: herramienta con la que visualizará la aplicación.
○ Atenea: lugar de acceso para la asignatura de GEP.
6. Estimación y Gantt
A continuación se mostrara todas las tareas con sus dependencias y horas:
ID tarea Tarea Tiempo (h) Dependencias
GP1 Contextualización y alcance 25 -
GP2 Planificación 10 GP1
GP3 Gestión económica y sostenibilidad 10 GP2
GP4 Documento final GEP 20 GP3
DES1** Familiarizarse con las tecnologías 22 -
DES2** Definición Arquitectura 50 -
DES3** Integración plantilla 33 FP
DES4** Securización del acceso 44 SASA
DES5** Definición menú 22 IP
DES6** Definición best practices 28 -
DES7** Maquetación Marcajes 28 DA, DBP, FP
DES8** Funcionalidad Marcajes 33 MM
DES9** Carga inicial de datos Marcajes 33 FM, SAM
DES10** Flujo completo Marcajes 44 CM
DES11** Servicios API Marcajes 39 DA, DBP
DES12** Servicios API Acceso y credenciales 50 DA, DBP
DES13 Configuración Docker 30 DA
DOC1 Documentación 90 -
DOC2 Preparación presentación 30 D1
DOC3 Reuniones * -
TOTAL HORAS 641
* Periódicas durante todo el desarrollo.
**Añadido el 10% antes comentado
Figura 6.1: Tabla con las tareas totales
Figura 6.2: Diagrama de Gantt
7. Gestión de riesgos
En apartados anteriores ya se han comentado la posibilidad de algunos riesgos que pueden aparecer durante el desarrollo del proyecto. La aparición de estos riesgos puede suponer que en la mayoría de casos aumente el número de horas de desarrollo y en otros casos cambiar la complejidad del proyecto. En este apartado se analizarán los posibles riesgos. En la siguiente tabla se pueden ver por cada riesgo, la probabilidad de que aparezca y su impacto en el proyecto.
Riesgo Probabilidad Impacto
Bug Alta Medio
Riesgos externos Baja Medio
Nuevas funcionalidades Alta Alta
Figura 7.1: Tabla con los riesgos
7.1 Bug
Como en cualquier proyecto de desarrollo de software la aparición de bugs durante la implementación estará presente en algún momento u otro. Estos bugs pueden causar que el proyecto acabe ralentizando o incluso estancarse en algún punto antes de la entrega, o incluso una vez que se lance la aplicación aparezcan algunos que no se han detectado durante la implementación, haciendo que dependiendo de la gravedad se haya que darles más prioridad sobre otras cosas. Para evitar estos problemas se intentará revisar el código lo máximo posible.
7.2 Riesgos externos
Cuando hablo de riesgos externos me refiero a aquellos riesgos que están fuera de mi alcance y que no puedo controlar ni solucionar, como por ejemplo ahora que estamos teletrabajando que en mi casa o en la oficina haya un corte del suministro eléctrico, que dependiendo de la duración puede hacer peligrar el trabajo de un día.
7.3 Nuevas funcionalidades
Durante el periodo de desarrollo, los clientes pueden llegar a pedir cambios en funcionalidades pactadas o incluso añadir de nuevas. Esto seguramente provocaría un incremento en el tiempo necesario para desarrollar el proyecto, pero también se podría ver como un aumento de la complejidad.
8. Presupuesto
8.1. Identificacion y estimacion de costes
Para poder analizar los diferentes costes económicos que supondría el proyecto, el primer paso es identificarlos. Para este proyecto de software, el coste vendrá dado por una banda por los recursos humanos y por la otra el material para desarrollar el software (hardware/software, energía…).
8.1.1. Recursos humanos
Para saber el precio que tendría contratar los recursos humanos he utilizado Glassdoor[9], una plataforma con datos empresariales y económicos. Me he centrado en los salarios medios en el área de Barcelona para ser más exactos.
Rol (Salario bruto)/hora (Salario bruto)/hora +
Seguridad Social
Jefe de proyecto 23,42€/h 30,44€/h
Becario FullStack 9€/h 11,7€/h
*Datos actualizados el 7 oct 2021
Figura 8.1: Tabla con sueldos de los trabajadores
ID Tarea Tiempo (h)
Horas Rol
Coste (€) Jefe de
proyecto
Becario FullStack
GP1 25 25 761
GP2 10 10 304,4
GP3 10 10 304,4
GP4 20 20 608,8
DES1 22 2 20 294,88
DES2 50 5 45 678,7
DES3 33 3 30 351
DES4 44 4 40 589,76
DES5 22 2 20 298,88
DES6 28 3 25 383,82
DES7 28 3 25 383,82
DES8 33 3 30 442,32
DES9 33 3 30 442,32
DES10 44 4 40 589,76
DES11 39 4 35 414,26
DES12 50 5 45 678,7
DES13 30 30 913,2
DOC1 90 90 2.739,6
DOC2 30 30 913,2
TOTAL 641 256 385 12.093
Figura 8.2: Tabla con los precios por horas
8.1.2. Recursos Materiales
Para poder llevar a cabo el desarrollo del proyecto además de recursos humanos serán necesarios unos recursos materiales. Podemos diferenciar dos tipos: hardware y software. Para lo primero contaremos con un ordenador, no será necesario un ordenador muy potente. Para lo segundo contaremos con programario Open Source y para aquellos que no lo sean o necesitemos la versión de pago usaremos las licencias de estudiante por lo que podremos disfrutar de las versiones de pago pero gratis, por lo tanto el coste del software será nulo. Hay que tener en cuenta que los recursos hardware cuentan con una vida útil y, por lo tanto, hay que calcular la amortización teniendo en cuenta la duración del proyecto (600 horas) y una dedicación de 5 horas al día. La fórmula de la amortización es la siguiente:
𝐶𝑜𝑠𝑡e (𝑒𝑢𝑟𝑜𝑠) * 𝑑𝑢𝑟ación 𝑝𝑟𝑜y𝑒𝑐𝑡o (ℎ𝑜𝑟a𝑠)
____________________________________________________________
𝑉𝑖𝑑𝑎 ú𝑡𝑖𝑙 (𝑎ño𝑠) * 220 (𝑑ias trabajados/𝑎ño) * 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖ón/𝑑𝑖𝑎 (ℎ𝑜𝑟a𝑠)
Recurso Precio (€) Vida útil Amortización (€)
Ordenador 800 4 109,06
Figura 8.3: Tabla con los precios de los materiales
8.1.3. Recursos generales
En el caso de la situación actual de la pandemia, el proyecto se realiza totalmente online, es por esta razón que no se perciben costes de transporte, pero sí que siguen existiendo los costes de espacio de la oficina, el consumo eléctrico e internet. Para lo primero buscaremos una oficina que esté por la misma zona que Telespazio Ibérica en la calle Marquès de Sentmenat[10], para la electricidad tomaré el precio medio del día 11/10/2021 [11] y un consumo de 300 W/h del ordenador; y finalmente para la internet cogeré una oferta con solo fibra [12].
Recurso Precio Cantidad Total (€/mes)
Oficina 12.01 €/m2 130 m2 1.561
Electricidad 0.248 €/kWh 22 días laborables x 24h* x 300W
158,4
Internet 29.75 €/mes - 29,75
Total 1.750
* El ordenador debe permanecer encendido para poder acceder al día siguiente.
Figura 8.4: Tabla con los precios de los recursos generales
Como el proyecto durará 7 meses el total del importe asciende a 12.250 €.
8.1.4. Costes de contingencia
Para calcular las contingencias se establece un porcentaje del 20% para disponer de un margen adecuado para posibles emergencias e incidentes adicionales.
Tipo de coste Coste (€) Coste final (€)
Recursos humanos 12.093 14.512
Recursos materiales 800 960
Recursos generales 12.250 14.700
Figura 8.5: Tabla con los costes de contingencia
8.1.5. Costes de imprevistos
A continuación se especifican los posibles imprevistos que pueden surgir durante el desarrollo del proyecto y su coste estimado.
Riesgo Probabilidad Tiempo (h) Coste estimado (€)
Coste final (€)
Bug 75% 30 270 202.5
Riesgos externos 25% 15 135 33.75
Nuevas funcionalidades
75% 30 270 202.5
Total 439
Figura 8.6: Tabla con los costes imprevistos
Tanto los costes de contingencia como los de imprevisto que no se lleguen a utilizar se destinarán a futuros proyectos.
8.1.6. Presupuesto final
Una vez definido el coste de las diferentes áreas, podemos juntar todos los apartados anteriores en la siguiente tabla.
Recurso Coste (€)
Humano 12.093
Material 800
Generales 12.250
Contingencia 5.029
Imprevistos 439
TOTALES 30.611
Figura 8.7: Tabla con el presupuesto final
8.1.7. Control de gestión
Para conseguir mantenerse en el presupuesto planteado y no salirse de él, es necesario un control sobre el tiempo y los costes del proyecto. Este proyecto se basa principalmente en el desarrollo de software, por lo tanto, la gran amenaza que se puede sufrir es la falta de tiempo. Es por ello que tanto los costes de recursos humanos, material y general no deberían sufrir una gran variación en su valor inicial; en cambio, aquellos que sí están sujetos a una variación son los de contingencia e imprevistos. Para esto se establecen unos mecanismos de control, que se deben calcular periódicamente, para saber en cualquier momento si los cálculos hechos anteriormente se están siguiendo o hay variaciones de ellos.
● Desviación del coste = (CosteEstimado - CosteReal) * Horas
● Desviación de la eficien día = (HorasEstimadas - HorasReales) * CosteEstimado
9. Sostenibilidad
9.1. Autoevaluación
Durante el transcurso de la carrera de Ingeniería Informática se tratan temas de sostenibilidad tanto en el ámbito medioambiental, el económico y también el social. Reflexionando sobre los conocimientos adquiridos durante estos 4 años y medio en el grado, creo que tengo unos conocimientos básicos en estas tres dimensiones. Durante el grado se le da mucho énfasis al impacto de la informática en la dimensión medioambiental, sobre todo con el impacto de los componentes hardware y sus residuos en el medio ambiente. Por otra parte, en otras asignaturas, se introducen también gestiones económicas de proyectos de software y se trata el impacto que puede tener el desarrollo software para la sociedad.
Eso sí, a la hora de realizar proyectos para la empresa y sobre todo hacer la documentación para este TFG me he dado cuenta de que es en el ámbito económico donde tengo menos experiencia, esto hace que, por ejemplo, tenga alguna dificultad en adquirir algunos datos para poder realizar el análisis económico inicial para este proyecto, pero en cambio, me resulte más fácil identificar tanto el impacto medioambiental como el social del proyecto y potenciarlos para obtener un mayor impacto aplicando los conocimientos de la carrera.
9.2. Dimensión ambiental
En el aspecto medioambiental mi proyecto al ser esencialmente desarrollo software esta parte no es excesivamente alta. De hecho este impacto corresponde al impacto que generan los diferentes recursos utilizados, como las herramientas de desarrollo utilizadas y el consumo energético de las instalaciones.
9.3. Dimensión económica
Respecto a la dimensión económica dada a la poca experiencia que tengo en este sector creo que he estimado bastante bien el presupuesto. Puede ser que coger un 20% para el plan de contingencia haya sido demasiado elevado, pero dado que este es mi primer proyecto prefería tener un presupuesto más elevado para cubrir posibles desviaciones que pudiesen surgir durante el transcurso de él.
9.4. Dimensión social
Por último tenemos la parte de la dimensión social, personalmente creo que la realización de este proyecto me aporta muchos conocimientos diversos. Por una parte, aprenderé nuevas tecnologías, métodos y desarrollo que hasta el momento no había utilizado en ningún otro proyecto. Por otra parte, realizando el proyecto con la modalidad de prácticas en una empresa, aprenderé a trabajar en un entorno laboral y ganar conocimiento para el futuro.
Este proyecto tiene como objetivo tanto mejorar el proceso de fichar haciéndolo más automático, como ya se ha explicado en otros apartados, como también ofrecer un entorno donde los empleados puedan disponer de todas las aplicaciones de gestiones corporativas en un mismo sitio. Por lo tanto, se puede decir que este proyecto mejorará la vida de los empleados y era necesaria su realización.
10. Leyes y regulaciones
Todos los datos de BD de datos pertenecen a la empresa Telespazio y han dado autorización para hacer uso de ellos en la aplicación. El código correspondiente al backend de Conthora fue desarrollado por Arnau Comellas Belmonte para la empresa Telespazio, dicha empresa da su consentimiento para su uso.
Respecto a la tecnología y frameworks utilizados, todos son gratuitos, casos como la licencia de JetBrains se hace uso de la licencia estudiantil.
11. Integración de conocimientos
Durante el transcurso del grado de ingeniería informática he ido adquiriendo, de las asignaturas cursadas, una serie de conocimientos, lenguajes de programación, técnicas y métodos, etc, que me han sido útiles para el correcto desarrollo de este proyecto. Principalmente, podemos destacar las siguientes asignaturas, principalmente de la especialidad de software:
● ASW: Esta asignatura me ha sido útil a la hora de programar el frontend de la aplicación. En ella pude aprender distintos conceptos orientados a la web, la interacción entre frontend y backend a través de las peticiones REST Api y los lenguajes y tecnologías orientadas a web.
● PES: Gracias a esta asignatura de proyectos pude aprender y poner en práctica la metodología Agile, metodología que Telespazio es propensa a utilizar para sus proyectos, incluidos este. Además, en el proyecto me encargué del backend lo cual me resultó útil a la hora de programar el backend de la aplicación.
● PROP: En esta asignatura tuve mi primer contacto con JAVA y aprendí las posibilidades de la orientación a objetos.
● GPS: El conocimiento adquirido en esta asignatura de gestión me ha sido útil a la hora de realizar esta memoria.
● AS: Gracias a la arquitectura del software obtuve conocimiento de técnicas para desarrollar el proyecto de una forma flexible, limpia y escalable.
● ER: De esta asignatura he adquirido los conocimientos para especificar los requisitos tantos los requisitos funcionales como los no funcionales de esta aplicación.
12. Especificación de requisitos
En este apartado se nombrarán y definirán todos los aspectos relacionados con las funcionalidades desarrolladas para un desarrollo óptimo del proyecto.
12.1 Requisitos funcionales
A continuación se describirán los diferentes requisitos funcionales de la aplicación, diferenciándolos por las diferentes APIs con las que cuenta el sistema. Se incluirá para ello las diferentes funcionalidades desarrolladas con sus casos de uso correspondientes, añadiéndoles un diagrama de casos de uso para cada funcionalidad.
12.1.1 Listado de requisitos funcionales
● Acceso y credenciales:
○ Inicio de sesión: La aplicación debe permitir iniciar sesión con las credenciales dadas por el usuario.
○ Establecer contraseña: Si el usuario no tiene contraseña, la aplicación le debe permitir establecer una.
○ Cambiar contraseña: Si el usuario olvida la contraseña, la aplicación le debe permitir volver a establecer una.
○ Cerrar sesión: La aplicación debe permitir cerrar la sesión activa.
● Marcajes:
○ Empezar la jornada: La aplicación debe permitir empezar la jornada del día o en el caso de haberla finalizado, retomarla.
○ Hacer un descanso: La aplicación debe permitir al usuario dejar constancia de uno de los descansos que el usuario puede realizar.
○ Acabar descanso: La aplicación debe permitir al usuario dejar constancia que ha acabado el descanso y vuelve a trabajar.
○ Acabar la jornada: La aplicación debe permitir al usuario dejar constancia que ha acabado de trabajar por el día de hoy.
○ Consultar Marcajes: La aplicación debe permitir, dado un rango de fechas, mostrar los marcajes del usuario hechos desde la aplicación, en ese rango de fechas.
○ Consultar Marcajes Totales: La aplicación debe permitir, dado un rango de fechas, mostrar los marcajes del usuario totales, en ese rango de fechas. Un Marcaje Total es el resultado de computar los marcajes diarios con las reglas aplicadas al horario de cada trabajador.
● Conthora:
○ Imputar horas: una vez que el usuario rellena todos los campos y pulsa el botón
“Añadir Datos”, la aplicación junta la información y crea un registro en una tabla.
○ Eliminar registro de la tabla: el usuario debe ser capaz de eliminar un registro de los que se muestran en la tabla si así lo desea.
○ Guardar en BD: Una vez que el usuario desea guardar la información aportada, la aplicación se lo debe permitir.
○ Consultas horas imputadas: La aplicación debe permitir, dado un rango de fechas, mostrar todas las horas imputadas en proyectos, en ese rango de fechas.
12.1.2 Diagrama de casos de uso
● Acceso y credenciales:
Figura 12.1 Diagrama casos de uso Acceso y credenciales
● Marcajes
Figura 12.2 Diagrama casos de uso Marcajes
● Conthora:
Figura 12.3 Diagrama casos de uso Conthora
12.1.3 Casos de uso
A continuación se definirán y explicarán los diferentes casos de uso, con los que cuenta la aplicación, con los requisitos funcionales desarrollados.
Acceso y credenciales
Caso de uso Iniciar sesión
Actor Actor
Precondición -
Disparador El Actor quiere acceder a la aplicación
Escenario de éxito 1. El actor introduce su nombre de usuario y contraseña.
2. El actor aprieta al botón de “Inicio de sesión”
3. El sistema comprueba los datos.
4. El sistema redirige al actor a la página principal de la aplicación.
Extensiones I. El sistema detecta que los datos introducidos no corresponden a ningún usuario en la BD y avisa al usuario.
Figura 12.4 Caso de uso Iniciar sesión
Caso de uso Cerrar sesión
Actor Actor
Precondición El Actor debe tener una sesión iniciada Disparador El Actor quiere cerrar sesión en la aplicación Escenario de éxito 1. El actor aprieta el botón “Cerrar sesión”.
2. El sistema borra las credenciales y devuelve al actor a la página de Iniciar sesión.
Extensiones -
Figura 12.5 Caso de uso Cerrar sesión
Caso de uso Establecer contraseña
Actor Actor
Precondición -
Disparador Es la primera vez que el actor accede a la aplicación.
Escenario de éxito 1. El actor introduce su nombre de usuario y rellena el campo de contraseña con un valor al azar.
2. El sistema detecta que ese usuario no tiene una contraseña asociada y redirige al actor a la ventana de establecer contraseña.
3. El actor introduce dos veces la contraseña deseada y le da a continuar.
4. El sistema asocia al nombre de usuario con la contraseña dada y redirige al usuario a la ventana de “Inicio de sesión”.
Extensiones I. La nueva contraseña no cumple los estándares del sistema.
Figura 12.6 Caso de uso Establecer contraseña
Caso de uso Cambiar contraseña
Actor Actor
Precondición El actor debe tener una sesión iniciada
Disparador El actor desea cambiar la contraseña asociada a su usuario.
Escenario de éxito 1. El actor pulsa el botón “Cambiar contraseña”.
2. El sistema redirige al actor a la ventana de “Cambiar contraseña”.
3. El actor rellena los campos de nueva contraseña y pulsa el botón “Cambiar contraseña”.
4. El sistema guarda la nueva contraseña y redirige al actor a la ventana de “Inicio de sesión”.
Extensiones I. La nueva contraseña no cumple los estándares del sistema.
Figura 12.7 Caso de uso Cambiar contraseña
Marcajes
Caso de uso Empezar jornada
Actor Actor
Precondición -
Disparador El Actor quiere empezar una jornada o retomarla.
Escenario de éxito 1. EL actor pulsa el botón para empezar la jornada.
2. El sistema registra la hora y redirige al usuario a la ventana
“Contar marcaje”.
Extensiones -
Figura 12.8 Caso de uso Empezar jornada
Caso de uso Hacer un descanso
Actor Actor
Precondición EL actor ha empezado un marcaje, acabado otro descanso o retomando una jornada.
Disparador El Actor desea empezar un descanso de cualquier tipo.
Escenario de éxito 1. El actor selecciona el tipo de descanso que desea realizar.
2. El actor pulsa el botón de iniciar descanso.
3. El sistema registra la hora del descanso y bloquea el botón de
“Finalizar jornada”.
Extensiones -
Figura 12.9 Caso de uso Hacer un descanso
Caso de uso Acabar descanso
Actor Actor
Precondición El actor ha empezado un descanso.
Disparador El Actor desea acabar el descanso que está en curso.
Escenario de éxito 1. El actor aprieta el botón de “Finalizar descanso”.
2. El sistema registra la hora final del descanso y habilita el botón de “Finalizar jornada”.
Extensiones -
Figura 12.10 Caso de uso Acabar descanso
Caso de uso Acabar Jornada
Actor Actor
Precondición El actor ha empezado una jornada, acabado otro descanso o retomando una jornada.
Disparador El Actor desea acabar la jornada.
Escenario de éxito 1. El usuario pulsa el botón de “Finalizar jornada”.
2. El sistema registra la hora final de la jornada y redirige a la ventana de “Fin Jornada”.
Extensiones -
Figura 12.11 Caso de uso Acabar jornada
Caso de uso Consultar marcajes
Actor Actor
Precondición -
Disparador El Actor desea consultar los marcajes hechos con la app.
Escenario de éxito 1. El actor selecciona un rango de fechas para consultar.
2. El sistema muestra en una tabla todos los marcajes, hechos con la aplicación, que cumplen el rango de fechas.
Extensiones -
Figura 12.12 Caso de uso Consultar marcajes
Caso de uso Consultar marcajes totales
Actor Actor
Precondición -
Disparador El Actor desea consultar los marcajes totales hechos con todos los sistemas.
Escenario de éxito 1. El actor selecciona un rango de fechas para consultar.
2. El sistema muestra en una tabla todos los marcajes que cumplen el rango de fechas.
Extensiones -
Figura 12.13 Caso de uso Consultar marcajes totales
Conthora
Caso de uso Imputar horas
Actor Actor
Precondición -
Disparador El Actor desea introducir las horas correspondientes a un proyecto.
Escenario de éxito 1. El actor selecciona: la persona, el día, las horas, el módulo y el proyecto para imputar y pulsa “Guardar”.
2. El sistema muestra los datos en una tabla.
Extensiones I. No se han rellenado todos los campos, el sistema avisa con un mensaje al actor sobre el problema.
Figura 12.14 Caso de uso Imputar horas
Caso de uso Eliminar registro de la tabla
Actor Actor
Precondición Hay entradas en la tabla.
Disparador El Actor desea eliminar un registro de la tabla.
Escenario de éxito 1. El actor pulsa el botón “Eliminar” referente al registro deseado.
2. El sistema elimina de la tabla el registro seleccionado.
Extensiones -
Figura 12.15 Caso de uso Eliminar registro de la tabla
Caso de uso Guardar en BD
Actor Actor
Precondición Hay entradas en la tabla.
Disparador El Actor desea guardar las horas seleccionadas.
Escenario de éxito 1. El actor pulsa el botón “Confirmar”.
2. El sistema guarda todos los registros en la BD.
Extensiones I. Se ha detectado un error a la hora de guardar en BD, el sistema avisa mediante un popover del error.
Figura 12.16 Caso de uso Guardar en BD.
Caso de uso Consultar horas imputadas
Actor Actor
Precondición -
Disparador El Actor desea consultar datos de Conthora.
Escenario de éxito 1. El actor introduce un rango de fechas y pulsa el botón “Buscar''.
2. El sistema busca los registros que estén dentro de ese rango de fechas y los muestra.
Extensiones -
Figura 12.17 Caso de uso Consultar horas imputadas
12.2 Requisitos no funcionales
Además de los requisitos funcionales, dentro de la especificación de requisitos existen los requisitos no funcionales o atributos de calidad, dichos requisitos se alejan del objetivo principal de la aplicación y se centran en su desarrollo.
Para el proyecto hemos seleccionado los siguientes:
● Usabilidad: la aplicación debe de ser fácil de utilizar para todos los posibles usuarios y no debe llevar a confusión.
● Disponibilidad: la aplicación debe de estar operativa en cualquier momento.
● Seguridad y privacidad: el sistema tiene que ser seguro, solo gente autorizada puede hacer uso de las distintas funcionalidades.
● Aspecto: la aplicación debe tener un diseño sútil y unificado siguiendo los estándares de la empresa.
● Fiabilidad: los datos que se generan mediante la aplicación y se guardan en el sistema deben de ser correctos en todo momento.
● Escalable: el sistema debe de estar preparado para en un futuro implementar nuevas funcionalidades sin causar problemas a las antiguas.
● Mantenible: con la documentación en mano debe ser sencillo arreglar bugs y mantener la aplicación desplegada.
● Portable: la aplicación se podrá desplegar en cualquier SO.
● Durabilidad: está previsto que la aplicación tenga una vida útil de 10 años
12.3 Modelo de datos
En esta parte definiremos todos los diagramas UML correspondientes a las clases UML que han sido utilizadas para el desarrollo de la aplicación. Se representarán los diagramas separados según qué API utiliza qué clases, en algunos casos se puede encontrar una clase en más de una API.
12.3.1 Acceso y credenciales
Figura 12.18 Diagrama Clases usadas en Acceso y credenciales
Usuarios
El conjunto (codPersona + codCambio) forma tanto la PK de la tabla como las claves externas para las demás tablas.
En esta tabla encontramos toda la información relacionada con un trabajador: delegación, permisos, jornada… según el codCambio que tuviese en ese momento.
UsuarioWeb
La PK de esta tabla es codUsuariosWeb un identificador que se le asigna al registro a la hora de su creación.
En esta tabla además de la PK, encontramos el identificador del usuario que ha iniciado sesión en la aplicación, identificado con una FK de la tabla Usuarios y la contraseña que ha establecido para iniciar sesión.
UsuarioToken
La PK de esta tabla es codUsuariosToken un identificador que se le asigna al registro a la hora de su creación.
En esta tabla además de la PK, encontramos el identificador del usuario al que se le ha asignado el token en cuestión, identificado con una FK de la tabla Usuarios y dicho token generado en Acceso y credenciales.
12.3.2 Marcajes API
Figura 12.19 Diagrama Clases usadas en Marcajes API
Usuarios
El conjunto (codPersona + codCambio) forma tanto la PK de la tabla como las claves externas para las demás tablas.
En esta tabla encontramos toda la información relacionada con un trabajador: delegación, permisos, jornada… según el codCambio que tuviese en ese momento.
UsuarioWeb
La PK de esta tabla es codUsuariosWeb un identificador que se le asigna al registro a la hora de su creación.
Esta tabla en este ámbito tendrá un uso exclusivo de consulta, dicha consulta se realizará en cada petición que reciba la API, pero antes de resolver dicha petición, para comprobar si el token que recibe la API del frontend está ligado a un usuario que haya iniciado sesión en la aplicación por lo menos una vez
UsuarioToken
La PK de esta tabla es codUsuariosToken un identificador que se le asigna al registro a la hora de su creación.
Esta tabla como la anterior, será de uso exclusivo de consulta. La consulta como en el caso anterior se realizará en cada petición, pero antes de resolver dicha petición, con la diferencia que en este caso se comprueba si el token recibido desde el frontend corresponde con el usuario al que se le ha asignado.
PersonalPresencia
La PK de esta tabla es codPersona (FK de Usuario) junto con fecha.
Esta tabla almacena todos los marcajes hechos por un usuario en una fecha presencialmente, dicho de otro modo el usuario ha debido de asistir personalmente en la oficina y hacer uso de la máquina de fichaje. Además también almacena otros datos como las horas totales que ha trabajado (desde inicio hasta el final de la jornada) o las horas reales que es la resta de las totales con los descansos realizados.
MarcajesWeb
La PK de esta tabla es codMarcajes un identificador que se le asigna al registro a la hora de su creación.
En esta tabla se almacenan todos los marcajes hechos desde la aplicación Marcajes por un usuario.
TipoMarcajesWeb
La PK de esta tabla es codTipoMarcajes un identificador que se le asigna al registro a la hora de su creación y la FK es tipoMarcaje.
En esta tabla se almacenan todos los tipos de marcajes que pueden haber en la aplicación como lo son “Entrada” y “Salida''.
CodigosMarcajesWeb
La PK de esta tabla es ID_TiposMarcaje que hace la función de identificador y la FK es descripción.
En esta tabla se almacenan los códigos y descripción de los descansos disponibles. Estos códigos vienen dados por RR.HH. y cada uno tiene su significado, por ejemplo el código 60 tiene como descripción “Almuerzo/Merienda”.
12.3.3 Conthora API
La parte del backend no ha sido implementada completamente por mi, yo solo hice la nueva implementación de tokens, por ese motivo no incluye el diagrama de clases correspondiente a Conthora.
13 Arquitectura del sistema
Durante el transcurso de este apartado se explicará el tipo de arquitectura que se sigue en Apps Corporativas. Además, también se describirán los componentes relacionados con la base de datos.
13.1 Arquitectura de microservicios
Apps Corporativas adopta el modelo de arquitectura de tres niveles. Este modelo es una especialización de otra arquitectura, la de cliente-servidor, donde el software reparte el trabajo entre tres componentes independientes: una parte para la capa de presentación, otra para el cálculo y la última para el almacenamiento de datos.
Figura 13.1 Esquema de la arquitectura microservicios
Capa presentación
● Navegador: necesario ya que como se ha descrito en los primeros capítulos, la aplicación será accesible vía web.
● Frontend: capa de presentación de la aplicación, en él se encuentra el código de las llamadas a las APIs y toda la funcionalidad de las ventanas.
Capa de calculo
Esta capa tiene la característica que está formada por los distintos microservicios creados para el proyecto:
● Acceso y credenciales: API de seguridad, se encuentra toda la lógica correspondiente a los usuarios y sus sesiones en la aplicación.
● Marcajes: API de Marcajes, interactúa con las tablas relacionadas con Marcajes en la BD, también comprueba los tokens de acceso.
● Conthora: API de Conthora, interactúa con las tablas relacionadas con Conthora en la BD, también comprueba los tokens de acceso.
Capa de almacenamiento
● BD: Base de datos de Telespazio Ibérica.
13.1.1 Despliegue
Como se ha explicado en apartados anteriores la idea era realizar el despliegue de la aplicación mediante Docker. El proyecto actualmente se contenerizada y despliega utilizando Docker compose.
Hay un contenedor por API, y uno para el frontend y nginx, que se encarga de la escucha de peticiones, de retornar los ficheros estáticos del frontend, y de la redirección al contenedor correspondiente. Al final por falta de tiempo el despliegue ha sido realizado por otra persona.
13.2 Arquitectura física
Respecto a la arquitectura física que dispondrá el proyecto tenemos:
● Un servidor donde estará desplegada la BD que contendrá entre otras cosas las tablas necesarias para el funcionamiento de la aplicación.
● Un servidor para el despliegue de las APIs del backend, de dicho servidor serán necesarios 3 puertos, uno para cada API desarrollada.
● Un servidor en el que se desplegará el frontend de la aplicación.
Para aumentar la seguridad del sistema, el acceso a esta aplicación estará habilitado solo para las máquinas conectadas a la red de la empresa, ya sea físicamente en la oficina o mediante la conexión por VPN.
Figura 13.2 Esquema arquitectura física
13.3 Arquitectura lógica
Para este apartado se mostrará la arquitectura que se ha utilizado para organizar el código, tanto la parte del frontend como la del backend. Se describirán las diferentes clases que hay en cada parte con su principal funcionamiento y cómo interactúan con las demás.
Figura 13.3 Esquema arquitectura lógica
13.3.1 Frontend
Como ya se ha nombrado, la parte correspondiente al desarrollo del Frontend está realizada en Angular y como template se hace uso Nebular [14], una template de uso gratuito. En ella podemos diferenciar dos tipos de clases, los componentes y los servicios.
Componentes
Los componentes de Angular están compuestos por 4 archivos que, si se usa el comando “ng generate component <nombre>”, se generan y se enlazan unos con otros automáticamente. Dichos archivos son:
● 1 archivo HTML: en este archivo se almacena tanto la visualización de la ventana: el texto, los componentes, el menú lateral, etc. como la interacción que tiene el usuario con ella: hacer click, rellenar un campo, seleccionar un valor, etc.
● 1 archivo CSS: en él se especifica la presentación de la ventana de la aplicación en lenguaje CSS, en él se crean clases y se declaran sus características (apariencia, color, fuente y otros detalles) para su uso en el HTML. El documento HTML hace uso del CSS implantando las clases, antes descritas, en los componentes individuales o en el conjunto de componentes que en los cuales se desea obtener las especificaciones de dicha clase.
● 1 archivo spec.ts: en este archivo es donde se implementan los test unitarios de los componentes asociados, pero para el desarrollo de la aplicación no se implementará ninguno.
● 1 archivo .ts: este archivo se encarga de la lógica de la ventana, en él se tratan los diferentes datos que se reciben desde el backend para ser utilizados en el frontend y también los datos que se reciben desde los componentes del fichero HTML.
Servicios
Los servicios de Angular están compuestos por 2 archivos que se generan y se enlazan automáticamente si se ejecuta el siguiente comando: “ng generate service <nombre>”. Los archivos generados son los siguientes:
● 1 archivo spec.ts: este archivo hace la misma función que en el componente, por lo tanto, tampoco se le aplicará ningún uso.
● 1 archivo .ts: este archivo tendrá dos funciones. La primera, hacer las llamadas a las diferentes peticiones al backend de la aplicación, separando las clases del backend, y pasar los datos al componente que los ha pedido. En esta acción no hay ninguna lógica más allá de la conexión a los endpoints y llamadas. La segunda función es conectar a distintos componentes entre ellos para compartir datos, disminuyendo el acoplamiento del sistema.
Para poder trabajar con los datos que devuelven las APIs, se han creado unas clases extras llamadas Interface.
Interface
Los archivos denominados Interface, son simples archivos TypeScript que contienen una interfaz del modelo de datos que recibe de la API.
export interface ServerTime { year: number;
month: number;
day: number;
hour: number;
minute: number;
seconds: number;
dateTime: string;
time: string;
}
Figura 13.4 Ejemplo del contenido de un archivo interface
