Gestor y localizador de oposiciones de la Administración General del Estado

Universidad de Valladolid ESCUELA DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA Mención en Ingeniería del Software Gestor y localizador de oposiciones de la Administración General del Estado Autor: D. Javier Moro García Tutores: D. Joaquín Nicolas Adiego Rodríguez Dña. Natalia Martín Cruz 2 Agradecimientos Quiero a agradecer a mi familia por haber confiado en mis capacidades y haberme apoyado durante los años de universidad. Por el esfuerzo y empeño en que reciba la mejor formación para la vida adulta y darme unos valores morales para afrontarla como una buena persona. A mi hermano pequeño, porque sin él no sería la persona que soy. A mis amigos, que han hecho todo este proceso más ameno, por estar tanto en los momentos tristes como los alegres, por apoyarme y porque siempre habéis estado ahí donde os necesitaba. A mis dos tutores, Joaquín y Natalia, porque sin su ayuda no habría sido posible este proyecto. A todos aquellos que me han ayudado a obtener los conocimientos necesarios para formarme como profesional. 3 4 Resumen Las oposiciones de la Administración General del Estado son emitidas diariamente en el Boletín Oficial del Estado. El acceso a estas oposiciones puede llegar a ser una acción bastante compleja y tediosa. Por este motivo, se ha visto la oportunidad de desarrollar una aplicación que permita al usuario localizar y gestionar las oposiciones desde una forma más accesible. El objetivo de este Trabajo de Fin de Grado es desarrollar una aplicación multiplataforma que contenga las oposiciones emitidas en el BOE, que permita al usuario filtrar las oposiciones según distintos criterios y que se pueda utilizar tanto en un dispositivo móvil como en un ordenador. Para este objetivo, se ha desarrollado una aplicación web PWA (Aplicación Web Progresiva) que pueda ser usada tanto para un dispositivo de escritorio como para un dispositivo móvil. Se ha contado con un Script que recoge los datos que utiliza la aplicación desde la página oficial, utilizando los datos abiertos que ofrece el BOE. Para el acceso a los datos, se ha contado con una API REST que se comunica con la base de datos. El trabajo ha sido desarrollado usando distintas herramientas para cada parte de la aplicación. En la parte Backend, se ha utilizado el lenguaje Java en el Script de recogida de datos y en la API REST. En el Frontend, se ha utilizado TypeScript como lenguaje principal y los frameworks de Ionic y Angular para el desarrollo de la PWA. Dentro del marco de trabajo, se ha utilizado una versión adaptada del proceso de gestión SCRUM para el desarrollo ágil del proyecto. 5 6 Abstract Civil service examinations are published daily in the Official State Gazette (Boletín Oficial del Estado). The access to these oppositions can become a quite complex and tedious action. For this reason, we have seen the opportunity to develop an application that allows the user to locate and manage the oppositions in an accessible manner. The objective of this Final Degree Project is to develop a multiplatform application that contains the competitive examinations issued in the BOE, which allows the user to filter the competitions according to different criteria and that can be used both on a mobile device and on a computer. For this objective, a PWA (Progressive Web Application) web application has been developed that can be used both for a desktop device and for a mobile device. A Script has been used to collect the data used by the application from the official website, using the open data provided by the BOE. To access the data, a REST API has been used to communicate with the database. The work has been developed using different tools for each part of the application. In the Backend part, Java language has been used in the data collection Script and in the REST API. In the Frontend, TypeScript has been used as the main language and the Ionic and Angular frameworks for the development of the PWA. Within the framework, an adapted version of the SCRUM management process has been used for the agile development of the project. 7 8 TABLA DE CONTENIDO Tabla de Contenido Agradecimientos 3 Resumen 5 Abstract 7 1. Introducción 17 1.1. Contexto ...................................... 17 1.2. Motivación ..................................... 19 1.3. IntroducciónalasPWA .............................. 19 1.4. Introducción a los Datos Abiertos . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.5. Introducción al Desarrollo Ágil (SCRUM) . . . . . . . . . . . . . . . . . . . . 21 1.5.1. Eventos ................................... 22 1.5.2. Roles .................................... 22 1.5.3. Artefactos.................................. 23 1.6. APIREST ..................................... 23 1.6.1. Características de los Servicios REST . . . . . . . . . . . . . . . . . . 24 1.7. Objetivos ...................................... 25 1.8. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2. Tecnologías utilizadas 27 2.1. IDE’s ........................................ 27 9 LISTA DE TABLAS 7.5. Sprint5 ....................................... 77 7.6. Épocadeprácticas................................. 77 7.7. Sprint6 ....................................... 78 7.8. Sprint7 ....................................... 79 7.9. Sprint8 ....................................... 80 7.10. Segunda Época de Prácticas y Exámenes . . . . . . . . . . . . . . . . . . . . 80 7.11.Sprint9 ....................................... 81 7.12.Sprint10 ...................................... 83 7.13.SprintFinal..................................... 83 7.14.CalendarioFinal .................................. 84 7.15.CalendarioFinal .................................. 85 16 CAPÍTULO 1. INTRODUCCIÓN Capítulo 1 Introducción 1.1. Contexto El Boletín Oficial del Estado (BOE) es el diario nacional del Reino de España donde se publica diariamente leyes, disposiciones y actos de inserción obligatoria. Aquí es donde se publican las oposiciones y concursos que las distintas Administraciones Públicas emiten diariamente. Al año se publican miles de oposiciones en el BOE. Estas quedan registradas en la web y el acceso a ellas es bastante complejo. Si un usuario desea ver las oposiciones que se generan al día, deberá acceder al BOE emitido en esa fecha y allí localizar la sección que las contiene. No es un proceso difícil, pero si luego quiere ver más oposiciones, deberá reproducir esta serie de acciones para cada día. Adicionalmente, si el usuario solo desea ver las oposiciones que ha generado un departamento específico, deberá repetir este proceso hasta que encuentre lo que desee. Tampoco es que la web oficial no tenga medios para que este usuario hipotético pueda encontrar lo que busca, la misma página oficial dispone de varios métodos de búsqueda, pero esta tiene bastantes problemas que la convierte en un servicio ineficiente. Figura 1.1 La página oficial posee un método de búsqueda principal. Esta se denomina búsqueda rápida y ofrece la posibilidad de búsqueda por palabra entre 4 opciones: Legislación, Todo el BOE, Notificaciones y Edictos. Estos cuatro términos son bastante generales y no ofrecen una clara visión de lo que representan, además son términos bastante burocráticos y los posibles usuarios puede que no sepan lo que significan. Asimismo, la página de búsqueda dispone de varios enlaces que nos llevan a otro tipo de búsqueda más avanzada, dependiendo qué acceso hayamos seleccionado podemos encontrar diferencias entre páginas, pero normalmente comparten bastantes campos. Cabe recalcar, que no hay ningún sitio donde diga al usuario que estos enlaces llevan a sistemas de búsqueda más eficientes. Figura 1.2 17 1.1. CONTEXTO Figura 1.1: Opciones de búsqueda del sistema de búsqueda principal [11] Figura 1.2: Sistema de Búsqueda del BOE [15] Este tipo de búsqueda puede ofrecer al usuario una experiencia de filtrado bastante completa. El problema es que tantos campos de búsqueda pueden abrumar al usuario, además de que varios de ellos necesitan de información previa sobre lo que significan. Por ejemplo, en 18 CAPÍTULO 1. INTRODUCCIÓN el campo rango, el usuario deberá conocer la diferencia entre real decreto, orden, resolución, etc. La misma página parece saber de este contratiempo, y dispone al usuario de un botón de ayuda donde se explica el significado de los distintos campos. Este hecho ya implica un escalón más de dificultad por parte de la página. Resumiendo, si un usuario desea ver unas oposiciones en concreto tiene dos posibilidades: ir de boletín en boletín o usar el buscador. Si opta por utilizar el buscador deberá conocer en qué apartado se encuentran las oposiciones (Personal) y después allí ingresar los datos en los apartados y rezar para que encuentre lo que busque. 1.2. Motivación Como ya se ha comentado, utilizar el buscador oficial es bastante engorroso y puede llegar a abrumar al usuario, ya sea por el número de campos que aparece o por los términos tan técnicos que aparecen. El número de usuarios que están interesados en las oposiciones dispuestas por la Administración Pública es bastante notorio. Solo hace falta ver la cantidad de oposiciones que salen a diario y la cantidad de gente que solicita acceder a ellas. Toda esta gente tendrá que acceder a un sistema de búsqueda complejo, teniendo que ir de página en página intentando ver las oposiciones que más les interesan. Al ver esto, hemos visto la posibilidad de ofrecer al usuario que esté interesado en las oposiciones de la Administración Pública una opción para poder navegar entre ellas sin estos inconvenientes. Una opción multiplataforma que ofrezca al usuario una buena experiencia desde el ordenador y desde su dispositivo móvil. 1.3. Introducción a las PWA Las aplicaciones web progresivas (Progressive Web Application) son un tipo de software de aplicación entregado a través de la web, construido utilizando tecnologías web comunes que incluyen HTML, CSS y JavaScript . Está diseñado para funcionar en cualquier plataforma que utilice un navegador compatible con los estándares, incluidos dispositivos móviles y de escritorio. Se podría resumir como una página web que se aprovecha de las tecnologías webs a las cuales tiene acceso para proponer una experiencia móvil similar a una aplicación nativa.[29] La ventaja que tiene frente a una aplicación nativa es que no es necesario realizar ningún tipo de instalación en el dispositivo, ya que se aloja en el servidor web. Las tecnologías que utilizan las aplicaciones progresivas hacen que el usuario móvil tenga una experiencia completa, ya que estas se adaptan para al dispositivo que se esté usando. 19 1.4. INTRODUCCIÓN A LOS DATOS ABIERTOS En una aplicación PWA nos podemos encontrar las siguientes características: Adaptabilidad: Estas aplicaciones se adaptan automáticamente a cualquier formato, navegador o dispositivo, ya sea móvil u ordenador. Multiplataforma: Las aplicaciones web progresivas contemplan la ejecución en diversos dispositivos, sistemas operativos y navegadores. Esto, además de ser clave a la hora de ofrecer una experiencia de usuario satisfactoria, supone facilidades para los desarrolladores y permite abaratar costes, puesto que no se requieren programaciones diferenciadas. Esta es una de las características clave que se han valorado para su elección en este proyecto. Apariencia nativa: La interfaz de usuario y, en general, la apariencia de una PWA es muy similar a la de las Apps nativas, tanto en estética como en la manera de interactuar y navegar por ella. Rapidez: Las aplicaciones PWA tiene, por lo general, una velocidad de carga y de navegación bastante optimizada. Esto permite que los contenidos se muestren al usuario prácticamente al instante, ya que se apoyan en el almacenamiento en la caché, permitiendo al usuario tener una experiencia grata, al menos en ese aspecto. Indexable y enlazable: Al estar basadas en una aplicación web, el contenido de una PWA es rastreable e indexable, de forma que pueda aparecer como resultado en un buscador. Además, esta se puede compartir mediante una URL, con la posibilidad de que la otra persona la utilice sin necesidad de instalarlo. Esta es otra de las ventajas de uso respecto a una aplicación nativa 100 %. Funcionalidades propias de una App nativa: Las Progressive Web App pueden, por ejemplo, acceder a la geolocalización del dispositivo, al Bluetooth, sincronizarse en segundo plano o enviar notificaciones push. Estas notificaciones son una potente herramienta de comunicación que permite informar al usuario. Más información en: [22] 1.4. Introducción a los Datos Abiertos Según la Junta de Castilla y León, «Datos abiertos es una filosofía y práctica que persigue que determinados datos estén disponibles de forma libre a todo el mundo, sin restricciones de copyright , patentes u otros mecanismos de control. Los datos deben publicarse en bruto (sin procesar), bien estructurados y en formatos conocidos que faciliten la reutilización.»[10] La filosofía detrás de los datos abiertos es el método científico que se basa en la investigación existente para desarrollar avances cuyo fin último es ayudar a las personas y al planeta que compartimos [32]. 20 CAPÍTULO 1. INTRODUCCIÓN Todos los Datos Abiertos deben cumplir estos principios básicos: Los Datos Abiertos deben ser completos. Los datos públicos son datos que no están sujetos a limitaciones de privacidad, seguridad o privilegios válidos. Los Datos Abiertos deben tener gran nivel de detalle, deben presentarse exactamente igual que como surgieron de la fuente primitiva y se debe poder comprobarse su origen y las referencias que contienen, de forma que cualquiera pueda verificar su validez. Los Datos Abiertos se deberán poner a disposición tan pronto como sea necesario para preservar el valor de los mismos. Los Datos Abiertos deben de estar disponibles para toda la población, sin necesidad de registro alguno. Los Datos Abiertos se deberán estructurar para permitir procesamiento automatizado. Los Datos Abiertos deberán estar disponibles en un formato sobre el cual ninguna entidad tiene le control exclusivo. Información más en detalle acerca de estos principios: [4] En este proyecto, los datos abiertos que se van a utilizar son los dispuestos en el Boletín Oficial del Estado, y más concretamente los datos referidos a las oposiciones. Más información acerca de los datos abiertos en la Comunidad de Castilla y León: [9] 1.5. Introducción al Desarrollo Ágil (SCRUM) Debido a la importancia del proyecto, es necesario seguir un marco de trabajo en el que apoyarnos para que la aplicación se lleve a cabo. Para esto, el concepto de Desarrollo Ágil siguiendo la metodología SCRUM se adapta bastante bien a lo que se quiere. Una Figura 1.3: SCRUM característica fundamental de SCRUM es el poder dividir el trabajo en distintas partes, denominados sprints. Estos sprints dan la capacidad de poder reaccionar rápidamente a los distintos cambios que puedan aparecer a lo largo del proyecto. 21 1.5. INTRODUCCIÓN AL DESARROLLO ÁGIL (SCRUM) SCRUM también permite la adopción de una estrategia incremental, en lugar de otra más centrada en la planificación y ejecución completa del producto. [37] 1.5.1. Eventos Para llevar un proyecto SCRUM correctamente es necesario conocer los distintos eventos que van a aparecer. Hay eventos cuyo objetivo es favorecer la comunicación y relación entre los distintos equipos de desarrollo que pueden haber en un proyecto. Este proyecto, solo existe un equipo de desarrollo formado por una sola persona, la cual es el alumno. Aún así, es interesante el introducir estos eventos: Sprint El Sprint es la base del Scrum. Es un periodo de tiempo de 1 mes, 3 o 2 semanas, durante el cual se crea un incremento de producto, utilizable y potencialmente liberable. Lo ideal es que siempre tengan la misma duración. Sprint Planning El trabajo que se realizará en el Sprint está planificado en Sprint Planning, mediante la colaboración de todo el equipo de Scrum. Esta reunión se planificará al inicio del proyecto. Daily Scrum Es una reunión diaria que sirve para inspeccionar el progreso hacia el objetivo del sprint y cómo avanza el progreso. Para ello, se inspecciona el trabajo realizado en el último día y se comenta el trabajo que se va a realizar ese día. Sprint Review La reunión se lleva a cabo al final del Sprint con el objetivo de inspeccionar el incremento y adaptar el Product Backlog (lista con todos los requerimientos iniciales del producto que se va a desarrollar) si es necesario. Sprint Retrospective Esta reunión se realiza en medio del sprint, antes del Sprint Planning siguiente y después del Sprint Review actual. Sirve para que el Scrum Team se inspeccione a sí mismo y cree un plan para mejorar en aquellas áreas que lo necesiten. Información más detallada acerca de estos eventos en: [30] [31] En posteriores capítulos, se hablará de cómo estos eventos serán adaptados al proyecto actual. 1.5.2. Roles Antes de hablar de los documentos que hay dentro de la estrategia SCRUM, es imprescindible introducir los distintos miembros que forman el proyecto. Product Owner El objetivo de este rol es garantizar la calidad del producto. Es el encargado de comunicar las ideas del cliente, siendo una especie de representante de él. Tiene la capacidad de realizar cambios y tomar decisiones sobre el producto final. 22 CAPÍTULO 1. INTRODUCCIÓN SCRUM Master Es el encargado de gestionar el proceso de trabajo dentro del proyecto. Entre sus obligaciones está la gestión de los sprints (incrementos) y maximizar la productividad del equipo de desarrollo. Equipo de desarrollo El número de integrantes dentro de este equipo es variable, pero siempre dentro de unos límites. Son los encargados del mismo desarrollo del proyecto. 1.5.3. Artefactos Los artefactos son todos los elementos que garantizan la transparencia y registro de la información fundamental del proceso SCRUM. [33] Product Backlog Como anteriormente se ha comentado, el Product Backlog es una lista que contiene todos los requirimientos iniciales del producto que se va a desarrollar. El responsable de este documento es el Product Owner. Sprint Backlog Es un subconjunto del Product Owner destinado a recopilar las tareas y requisitos dentro de un sprint dado. Incremento Es el resultado del sprint. El sprint debe estar terminado y ser funcional para poderse crear el Incremento asociado. Este puede ser entregado y puede cumplir la función de prototipo para que los clientes puedan usarlo. 1.6. API REST Una de las partes fundamentales de la aplicación es cómo el usuario puede acceder a los datos. Para este proyecto se ha decidido que el mecanismo de acceso a los datos sea a través de una API REST. Para entender el concepto de los Servicios REST, primero habrá que presentar lo que es un Servicio WEB. A nivel conceptual, un servicio web es un componente software proporcionado a través de un endpoint (ordenador, móvil, etc) accesible a través de la red. Los servicios productores y consumidores utilizan mensajes para intercambiar información de invocaciones de petición y respuesta en forma de documentos auto-contenidos que hacen muy pocas asunciones sobre las capacidades tecnológicas de cada uno de los receptores [17]. Dentro de estos servicios, se encuentran los Servicios Web RESTful. Estos permiten intercambiar mensajes escritos en diferentes formatos, y no requieren el publicar una descripción de las operaciones que proporcionan, por lo que requieren una menor ”infraestructura” para su implementación. 23 1.6. API REST Figura 1.4: REST API - Author: Seobility - License: CC BY-SA 4.0 1.6.1. Características de los Servicios REST El término REST proviene de la tesis doctoral de Roy Fielding y significa REpresentational State Transfer. Este servicio tiene una serie de caraterísticas [23]: Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite no tener que mantener información acerca del estado de ninguno de los procesos. Existen 4 tipos de operación relacionadas con los datos que son: •POST: Permite crear datos en la aplicación •PUT: Permite modificar datos de la aplicación •GET: Permite consultar y leer datos de la aplicación •DELETE: Permite eliminar datos de la aplicación. La existencia de estos tipos de operación definidos, permite mantener en el servicio una interfaz uniforme, ya permite sistematizar el proceso con la información. Los objetos en REST se manipulan a partir de la URI: La URI sirve de identificador único para cada recurso. Esto permite acceder a la información para su modificación o consulta. Este servicio ofrece la capacidad de separar el cliente y servidor, al separar la interfaz de usuario y el almacenamiento de datos. Esto implica la ventaja de poder tener un servicio escalable sin excesivos tipos de problema. Una ventaja considerable de este servicio, y de la que se ha hecho utilidad en el proyecto, es la independencia del servicio del lenguaje que se usa. Esto es lo que permite al proyecto usar TypeScript en la capa de presentación, mientras que el servicio REST está basado en el lenguaje Java. 24 CAPÍTULO 1. INTRODUCCIÓN 1.7. Objetivos El objetivo de este proyecto es la creación de un servicio de búsqueda de oposiciones que permita al usuario ver el histórico de las oposiciones existentes, así como poder filtrar oposiciones mediante diferentes criterios de búsqueda. El servicio constará de una página web a la que puedan acceder los usuarios y que esta tenga soporte para móviles como si fuera una aplicación nativa. La idea de la aplicación reside en su sencillez, que no abrume al usuario con opciones que no sabe qué significan, que ofrezca la posibilidad de acceder a las oposiciones desde una sencilla búsqueda por directorio, y también que ofrezca una búsqueda avanzada. 1.8. Estructura de la memoria La memoria del proyecto está estructurada de la siguiente manera: Capítulo 2: Tecnologías utilizadas Enumeración de las herramientas utilizadas en el desarrollo de la aplicación y de la gestión del mismo. Capítulo 3: Planificación y Requisitos Descripción de la adaptación al Desarrollo Ágil y el público objetivo del que se espera que use la aplicación, así como la serie de riesgos que se han descubierto en el proyecto. Capítulo 4: Análisis Explicación de la etapa de análisis que ha tenido el proyecto, así como una descripción del Boletín Oficial del Estado y de sus datos. Capítulo 5: Diseño Etapa de diseño software que contiene los diagramas y diseños basados en en la etapa de análisis. Capítulo 6: Implementación y Pruebas Descripción del proceso de implementación y de las pruebas realizadas a la aplicación. Capítulo 7: Seguimiento Describe el desarrollo del proyecto dividido en sprints siguiendo un desarrollo ágil basado en una adaptación de SCRUM. Capítulo 8: Conclusiones Anexo A: Manual Contiene una breve explicación de la instalación de las herramientas, instalación del proyecto y una breve introducción a las funcionalidades de la aplicación. Dentro del contenido de la memoria, se utilizarán indistintamente los términos de ”epígrafe” y ”especialidad, ya que estos se refieren al mismo concepto y, dependiendo el contexto, es necesario utilizar un término u otro. El término epígrafe aparece dentro de los datos que ofrece el boletín y se sustituye dentro de la aplicación por el término especialidad, ya que este ofrece una visión más clara de lo que representa. Se usará epígrafe para referirse a la parte técnica de la aplicación y el término especialidad cuando este involucre de alguna forma al usuario final. 25 2.6. TESTING 32 CAPÍTULO 3. PLANIFICACIÓN Y REQUISITOS Capítulo 3 Planificación y requisitos 3.1. Desarrollo Ágil (SCRUM) adaptado al proyecto Habiendo explicado en capítulos anteriores el concepto de Desarrollo Ágil, y en particular la estrategia SCRUM, podemos empezar a explicar cómo se va a adaptar para el proyecto. El proyecto contiene diferentes particularidades que le hace tener un tratamiento especial acerca de la estrategia SCRUM: El primero, es el número de miembros del Equipo de Desarrollo. Obviamente, este está formado por una sola persona, la cual es el alumno. Si nos ceñimos a los límites dispuestos por la estrategia SCRUM acerca del número de miembros (de 3 a 9 miembros por equipo de desarrolo), este requisito no se cumple. Esta particularidad hace que simplifiquemos en gran medida esta estrategia. Las reuniones destinadas a monitorizar el trabajo de los distintos miembros del equipo se eliminarán, ya que todo el peso del proyecto irá a una misma persona. El resto de reuniones se reducirá y la comunicación entre los roles del proyecto se hará por correo electrónico. El proyecto está destinado a hacerse durante el curso. Esto dificulta el poder planificar reuniones y sprints con mucha antelación, debido a la existencia de otras variables, como lo son las prácticas curriculares, las otras asignaturas, junto con sus exármenes y prácticas. Debido a esto, la fecha de los sprints podrá variar de la estipulada en la planificación. Así mismo, la posibilidad de hacer reuniones periódicas tampoco es una opción posible por la misma razón. Habiendo aclarado estos detalles, comencemos con la asignación de roles en el proyecto. Los tutores del proyeto representarán dos roles: El de Product Owner al ser los responsables de garantizar la calidad del producto, así como los encargados de realizar cambios y modificar los requisitos en el producto final. 33 3.2. PÚBLICO OBJETIVO También, son responsables de gestionar todo el proceso de trabajo, gestionar los incrementos y las reuniones. Estos deberes están asociados al rol de SCRUM Master. El alumno será el único miembro del Equipo de Desarrollo. Será el encargado de cumplir los objetivos del proyecto y de acudir a las reuniones organizadas por los tutores para ver el desarrollo del mismo. Al principio del proyecto, se realizó una reunión explicativa que actuaría como Sprint Planning, donde se habló de los objetivos del proyecto y los requisitos que tendría este. Posteriormente, se realizarían comunicaciones escritas donde ambas partes comentarían el progreso del proyecto. Estas comunicaciones solían tener documentación visual de la aplicación que funcionaba como demostración de lo que se había hecho durante el sprint. Estas comunicaciones actuarían como Sprint Planning, Sprint Review y Sprint Retrospective. Tanto las historias de usuario como el Product Backlog Final se confeccionaron a medida que el proyecto fue desarrollándose. 3.2. Público objetivo Una de las peculiaridades de este proyecto es la amplitud del público objetivo, debido al gran número de variedad que hay en las oposiciones. Hay oposiciones que exigen un número de requisitos y hay oposiciones que no exigen prácticamente nada. La característica común que tienen los miembros del público objetivo es que están interesados en una oposición en particular o en un grupo de ellas. Por esto, la aplicación deberá tener unos requisitos mínimos que sepan satisfacer las necesidades de cada tipo de usuario. Según los datos recabados por la aplicación, al año se producen de media 18000 documentos referentes a oposiciones, entre ellos están las mismas oposiciones y correcciones. Para cada oposición, hay un público objetivo que está interesado en estas. Estas oposiciones son muy variadas, tanto en requisitos como en los puestos que ofrecen. Las personas que estén interesadas en las oposiciones no tienen por qué saber de informática. Por este motivo, la aplicación deberá mantener un diseño sencillo, con funcionalidades sencillas que ayuden a este usuario a llegar a su objetivo. También se ha tenido en cuenta a los usuarios más experimentados dentro del ámbito de internet. La aplicación cuenta con un sistema de búsqueda por directorio, el cual está centrado en una experiencia más técnica por parte de los usuarios. Adicionalmente, la aplicación cuenta con un histórico de cambios dento de las oposiciones, que permite a los usuarios interesados en una única oposición ver los cambios que ha tenido esta. 34 CAPÍTULO 3. PLANIFICACIÓN Y REQUISITOS 3.3. Riesgos Los riesgos son un evento que, si sucede, tiene un efecto negativo en uno o varios de los objetivos dispuestos del proyecto. A continuación, se dispondrán varios de estos riesgos que pueden suceder a lo largo del proyecto: Riesgo 1: Modificación del formato del BOE Tipo Técnico Probabilidad Muy baja Impacto Medio Descripción La base de datos depende mucho de la forma en la que se disponen los datos en el Boletín Oficial del Estado, y en detalle la forma en la que dispone la información referente a las oposiciones. Mitigación Depender lo mínimo de estos datos. Guardar solo lo indispensable en la base de datos. Contingencia Evitar mostrar al usuario datos erróneos correspondientes a este fallo, y mostrar un mensaje de error en su lugar para evitar confusiones. Tabla 3.1: Riesgo de modificación del formato del BOE Riesgo 2: Modificación del formato de las Oposiciones Tipo Técnico Probabilidad Muy baja Impacto Medio Descripción La base de datos depende mucho de la forma en la que se disponen los datos de las oposiciones, así como en la forma en la que se accede a ellos (el formato de la dirección). Mitigación Depender lo mínimo de estos datos. Guardar solo lo indispensable en la base de datos. Contingencia Evitar mostrar al usuario datos erróneos correspondientes a este fallo, y mostrar un mensaje de error en su lugar para evitar confusiones y para que los técnicos conozcan este fallo. Tabla 3.2: Riesgo de modificación del formato de las Oposiciones 35 3.3. RIESGOS Riesgo 3: Falta de tiempo Tipo Personal Probabilidad Alta Impacto Medio Descripción Este proyecto está destinado a hacerse en el segundo cuatrimestre. El alumno está desarrollando este Trabajo de Fin de Grado junto a 2 asignaturas y las prácticas de empresa. Debido a esto, habrá ocasiones en las que la carga de trabajo no permita desarrollar como se quisiera este proyecto. Mitigación Realizar un plan de trabajo teniendo en cuenta los espacios de tiempo que tenga poco margen de trabajo. Por ejemplo: viendo en la planificación de las asignaturas los posibles picos de trabajo (entregas, exámenes, etc.) Contingencia Replanificar la carga de trabajo destinada al TFG en las zonas de más descanso. Tabla 3.3: Riesgo de falta de tiempo Riesgo 4: Pandemia Tipo Global Probabilidad Alta Impacto Medio Descripción Debido a la situación en la que nos encontramos, no extraño pensar en la aparición de una nueva variante o del incremento del número de casos de COVID-19 que conlleven medidas excepcionales del gobierno que alteren la forma de trabajo. Mitigación Mantener las medidas de seguridad que el gobierno comunique a lo largo del proyecto. Utilizar entornos de trabajo online. Contingencia Realizar reuniones de forma telemática. Reorganizar la carga de trabajo si se ha impedido trabajar en el proyecto por causas relacionadas con la pandemia. Tabla 3.4: Riesgo de pandemia 36 CAPÍTULO 3. PLANIFICACIÓN Y REQUISITOS Riesgo 5: Interfaz mal elegida Tipo Técnico Probabilidad Media Impacto Alto Descripción Problemas relacionados con la disposición de los componentes de la interfaz que provoquen una mala experiencia por parte del usuario. Mitigación Seguir estándares y guías en la construcción de la interfaz. Tener pruebas de usabilidad con usuarios reales y tener en cuenta sus opiniones. Contingencia Seguir las recomendaciones de los usuarios y comprobar si se sigue la metodología recomendada por parte de guías y estándares actuales. Realizar pruebas de usabilidad antes de volver a reanudar la aplicación Tabla 3.5: Riesgo de interfaz mal elegida Riesgo 6: Errores en la disposición de los datos Tipo Técnico Probabilidad Media Impacto Alto Descripción Problemas relacionados con los datos que reciba el usuario en la propia página. Mitigación Pruebas de caja negra en la parte Backend. Contingencia Poner en mantenimiento la aplicación e intentar localizar la raíz del problema y actualizar las pruebas para que den los resultados correctos. Tabla 3.6: Riesgo de errores en la disposición de los datos Riesgo 7: Modificación de los requisitos Tipo Contractual Probabilidad Media Impacto Medio Descripción Durante el desarrollo de la aplicación es posible que haya cambios en el concepto del proyecto y que estos impliquen la modificación de los requisitos del trabajo. Por ejemplo: acotar el público objetivo a uno con más nivel informático y ampliar los métodos de búsqueda, así como la propia interfaz Mitigación Flexibilizar las partes de la aplicación con mayor posibilidad de cambio. Postergar las partes con mayor posibilidad de cambio en la planificación para que estos cambios no penalicen lo ya hecho en la aplicación. Contingencia Replanificar la carga de trabajo Tabla 3.7: Riesgo de modificación de los requisitos 37 3.3. RIESGOS 38 CAPÍTULO 4. ANÁLISIS Capítulo 4 Análisis 4.1. Análisis del BOE De acuerdo con el Real Decreto 181/2008, de 8 de febrero el ”Boletín Oficial del Estado”, diario oficial del Estado español, es el medio de publicación de las leyes, disposiciones y actos de inserción obligatoria. En el ”Boletín Oficial del Estado” se publican: 1. Las disposiciones generales de los órganos del Estado y los tratados o convenios internacionales. 2. Las disposiciones generales de las Comunidades Autónomas, de acuerdo con lo establecido en los Estatutos de Autonomía y en las normas con rango de ley dictadas para el desarrollo de los mismos. 3. Las resoluciones y actos de los órganos constitucionales del Estado, de acuerdo con lo establecido en sus respectivas leyes orgánicas. 4. Las disposiciones que no sean de carácter general, las resoluciones y actos de los departamentos ministeriales y de otros órganos del Estado y Administraciones públicas, cuando una ley o un real decreto así lo establezcan. 5. Las convocatorias, citaciones, requisitorias y anuncios cuando una ley o un real decreto así lo establezcan. La publicación del boletín oficial del estado se realiza en la página web oficial todos los días, menos los domingos. La página ofrece dos formatos de lectura: PDF y XML. El acceso a estos formatos está estandarizado, y se puede acceder a distintas boletines siguiendo un 39 4.1. ANÁLISIS DEL BOE https://boe.es/diario_boe/xml.php?id=BOE-S-YYYYYMMDD simple formato. Por ejemplo, el tipo de archivo de lectura utilizado en el proyecto sigue este formato: Siendo YYYY, MM y DD el año mes y día en formato ISO. Gracias a este formato, podemos automatizar la recogida de boletines diariamente, simplemente añadiendo el día deseado. Dentro del boletín nos lo encontramos divididos en secciones: I. Disposiciones generales: se publican las leyes orgánicas, leyes, reales decretos legislativos y reales decretos-leyes; los tratados y convenios Internacionales; las normas con rango de ley de las Comunidades Autónomas; los reglamentos y demás disposiciones de carácter general estatales; los autos y providencias del Tribunal Constitucional en procedimientos relativos a disposiciones de carácter general así como las decisiones del Tribunal Supremo que anulan o afectan a disposiciones estatales de carácter general. II. Autoridades y personal: Dividida por dos subsecciones a)Nombramientos, situaciones e incidencias: se publican los nombramientos y ceses de altos cargos y del personal de la Administración. b)Oposiciones y concursos: se publican las convocatorias de oposiciones y concursos para ingreso en la Administración y para la provisión de puestos de trabajo. III. Otras disposiciones: se publican las disposiciones que no tengan carácter general ni correspondan a las demás secciones: bases reguladoras de la concesión de becas, premios y otras ayudas y subvenciones; cartas de servicios; convenios colectivos de ámbito general; planes de estudio, declaraciones de impacto ambiental, convenios entre Administraciones, etc. IV. Administración de Justicia: se publican los edictos, notificaciones, requisitorias y anuncios de los Juzgados y Tribunales. V. Anuncios: Dividida por tres subsecciones: a)Contratación del Sector Público: Se publican los anuncios de contratación. b)Otros anuncios oficiales: Se publican los extractos de convocatorias de becas, premios y otras ayudas y subvenciones, los trámites de información pública, las concesiones administrativas, etc c)Anuncios particulares. Más información de las secciones del boletín en: [14] Dentro de estas secciones nos interesa la sección II.b donde se publican las oposiciones y concursos que se van a utilizar como datos en la aplicación. 40 CAPÍTULO 4. ANÁLISIS 4.2. Oposiciones y concursos En esta sección del boletín se enumeran las oposiciones y concursos que los distintos organismos emiten. En ambos formatos (PDF y XML) aparece el nombre de los departamentos que emiten las disposiciones, así como los ”epígrafes” (especialidad) en los que entra cada oposición. A continuación, aparecen las oposiciones que esta pareja Departamento-Epígrafe ha emitido. Aparece el título de la oposición, así como el identificador de esta. El identificador de la oposición está formado por una serie de caracteres compuestos por el año de la disposición de la oposición y del número de oposición total de ese año. Entre ambos formatos de archivo existen varias diferencias que hace al formato XML un formato más completo. En el formato XML aparece el identificador de los departamentos que nos servirá de ayuda para guardarlos. También, otro de los puntos a favor de este tipo de archivo, es que aparecen los enlaces a las páginas donde reside la información más detallada de cada oposición (un enlace para su formato XML y otro para PDF). Figura 4.1 Figura 4.1: Ejemplo real de dos oposiciones con un mismo par Departamento-Epígrafe [13] 4.3. Oposición En esta sección se hablará solo acerca del formato XML, porque como ya se ha comentado, ofrece una gran variedad de información que el formato PDF no posee. Además, este formato será el que va a ser utilizado posteriormente en el desarrollo de la aplicación, debido a las ventajas anteriormente comentadas y al propio formato del archivo que es uno de los estándares de lenguajes para intercambio de datos estructurados. Dentro del fichero XML podemos encontrar que la información está divida dentro de 3 subsecciones: Metadatos: Aquí hay información muy diversa. Dentro de este apartado nos podemos encontrar el identificador de la oposición, el título de la oposición, el departamento junto a su identificador y la página que nos dirigirá al formato PDF. Análisis: Dentro de esta subsección podemos encontrar diversos datos, entre estos el más destacado son las referencias. Para esta parte hay que explicar un detalle. Hay disposiciones que pueden referirse a correcciones o continuaciones de alguna oposición anterior. Para este propósito están las referencias. Estas referencias sirven para conocer 41 5.1. DIAGRAMA DE CASOS DE USO A continuación, se realizará una descripción detallada de estos casos de uso: Caso de Uso Explorar Oposiciones Descripción Permite al usuario navegar por las oposiciones de la aplicación Autor Usuario Precondiciones Ninguna Flujo de Eventos El usuario selecciona dentro del menú la opción Oposiciones Se le muestra al usuario todas las oposiciones ordenadas de más recientes a más antiguas. Post-condiciones Ninguna Tabla 5.1: Descripción del Caso de Uso Explorar Oposiciones Caso de Uso Explorar Departamentos Descripción Permite al usuario navegar por las departamentos de la aplicación Autor Usuario Precondiciones Ninguna Flujo de Eventos El usuario selecciona dentro del menú la opción Departamentos Se le muestra al usuario todos los departamentos ordenados alfabéticamente. Post-condiciones Ninguna Tabla 5.2: Descripción del Caso de Uso Explorar Departamentos Caso de Uso Explorar Epígrafes Descripción Permite al usuario navegar por epígrafes/especialidades de la aplicación Autor Usuario Precondiciones Ninguna Flujo de Eventos El usuario selecciona dentro del menú la opción Especialidades Se le muestra al usuario todos los epígrafes ordenados alfabéticamente. Post-condiciones Ninguna Tabla 5.3: Descripción del Caso de Uso Explorar Epígrafes 48 CAPÍTULO 5. DISEÑO Caso de Uso Buscar mediante búsqueda avanzada Descripción Permite al usuario filtrar las oposiciones por una búsqueda avanzada Autor Usuario Precondiciones Ninguna Flujo de Eventos El usuario selecciona dentro del menú la opción Oposiciones El usuario rellena las opciones que desee filtrar dentro de las oposiciones. Se le muestra al usuario una lista con las oposiciones que cumplan los requisitos del usuario de más recientes a más antiguas. Postcondiciones Las oposiciones mostradas cumplen los filtros dispuestos por el usuario Tabla 5.4: Descripción del Caso de Uso Buscar mediante búsqueda avanzada Caso de Uso Buscar por directorio Descripción Permite al usuario buscar las oposiciones por un sistema de directorios Autor Usuario Precondiciones El usuario debe estar en la vista de Departamentos o Epígrafes Flujo de Eventos El usuario selecciona un Departamento o un Epígrafe (dependiendo de la vista en la que esté) Se le muestra al usuario todos los elementos relacionados al dato seleccionado. El usuario selecciona un elemento relacionado. Se le muestra al usuario una lista con las oposiciones que cumplan el par Departamento-Epígrafe. Post-condiciones Las oposiciones mostradas cumplen el par DepartamentoEpígrafe Tabla 5.5: Descripción del Caso de Uso Buscar por directorio 49 5.2. DIAGRAMA DE CLASES Caso de Uso Ver Oposición Descripción Permite al usuario acceder al documento original de la oposición Autor Usuario Precondiciones El usuario tiene que estar en una vista con una serie de oposiciones Flujo de Eventos El usuario selecciona una oposición Se le muestra en detalle la oposición seleccionada. El usuario selecciona el botón PDF. El sistema lleva al usuario a la página oficial de la oposición. Post-condiciones Ninguna Tabla 5.6: Descripción del Caso de Uso Ver Oposición 5.2. Diagrama de clases Este diagrama permite tener una estructura de las clases que hay en la aplicación. Están Figura 5.2: Diagrama de Clases las 3 clases principales de la aplicación: Oposición, Epígrafe y Departamento. Hay dos clases soporte: DetalleOposición que permite a la aplicación navegar entre los departamentos y los epígrafes para acceder a las oposiciones, y Referencia cuya finalidad es tener un historial de los cambios que tienen las oposiciones. 50 CAPÍTULO 5. DISEÑO 5.3. Recursos REST Este diagrama ilustra los servicios REST que tiene la aplicación. La información de las clases hace referencia al modelo de dominio que se presentaba en la anterior sección. Figura 5.3: Diagrama de Recursos REST 51 5.4. DESPLIEGUE 5.4. Despliegue Para tener una idea visual de cómo está hecho el despliegue del servicio REST, se ha creado este diagrama. Aquí reside la información de qué herramienta se va a utilizar para desplegar la aplicación, así como los entornos donde residen los servicios REST. Las herramientas utilizadas se han explicado en capítulos anteriores. Figura 5.4: Diagrama de Despliegue 5.5. Diseño de la Página El diseño de la página es una parte fundamental de la aplicación. Una mala interfaz puede echar todo el proyecto por tierra. Hay muchos ejemplos de proyectos que tienen buena 52 CAPÍTULO 5. DISEÑO funcionalidad, pero tienen una mala interfaz que provoca que los usuarios no usen esa aplicación. También se da el caso contrario, un proyecto con una funcionalidad mala con una buena interfaz que ”encandila” a los usuarios y estos se decantan por esta aplicación. Un aspecto importante dentro del diseño de la página es la gama cromática. La idea de la página es que tenga una paleta de colores definida, evitando sobrecargar la aplicación con colores que no combinen. Finalmente, el color elegido es un verde pastel que recuerde al color de las típicas mesas y sillas que hay en la mayoría de los institutos de España, y que son usados con normalidad en los exámenes presentes en las oposiciones. Recapitulando de capítulos anteriores, se ha dicho que la aplicación necesita: Una ventana de inicio, de donde puedan partir los usuarios y que contenga una lista con las oposiciones de la semana, así como una explicación de los tipos de datos que se van a presentar. Una vista en la que se puedan disponer la lista de las oposiciones junto a un sistema de búsqueda complejo. Este sistema de búsqueda contendrá un tipo de entrada para cada campo, permitiendo así tener un tipo de entrada personalizado si el campo se trata de una fecha o de seleccionar un tipo de estado.x z Si se había dicho que se necesitaba una lista con las oposiciones, también se necesitará una vista que disponga una lista con todos los departamentos y otra vista con los epígrafes. Ambas vistas tendrán en común un simple sistema de búsqueda que permita filtrarlas por el nombre. Y una última ventana donde se presente en detalle la oposición, junto al hilo de cambios que ha tenido la misma, y un botón que permita al usuario ver el documento desde la página oficial. El contenido de la información de cada documento será distinto dependiendo de si es una oposición o si es un documento de corrección. 5.5.1. Ventana de Inicio Esta es la primera vista que tendrán los usuarios al entrar a la página. Esta vista tiene bastantes cosas en común con las demás. Lo primero es la cabecera. Esta aparecerá en todas las demás vistas y contendrá los cuatro enlaces que permitan al usuario moverse por la aplicación, simplemente seleccionando la vista a la que quiera acceder. Esta funcionalidad es indispensable en la aplicación, ya que el usuario querrá moverse por la página sin tener que introducir una nueva dirección. Otro aspecto importante es la presentación de las vistas que aparece justo al principio. Esta explicación contendrá una imagen que sea fácil de asociar al dato que esté asociado, ya que para una persona es más fácil asociar un término a una imagen que a una simple palabra. Una imagen vale más que mil palabras 53 5.5. DISEÑO DE LA PÁGINA Adicionalmente, habrá una breve explicación de la vista a la que esté asociado el dato. Si la presentación está basada en la vista de las oposiciones, se explicará lo que es una oposición, lo que tendrá la página y cómo puede interactuar el usuario con esta página. Si solo apareciese la presentación, la vista quedaría muy vacía. Por eso, es interesante añadir la posibilidad al usuario de ver las oposiciones más novedosas de la semana sin tener que indagar más en la página, simplemente interactuando con la página principal. Para ver el boceto del dispositivo móvil vea la figura 5.5. Para ver el boceto del escritorio vea la figura 5.6. Para ver el menú vea la figura 5.7. Figura 5.5: Boceto de la ventana de inicio del dispositivo móvil 54 CAPÍTULO 5. DISEÑO Figura 5.6: Boceto de la ventana de inicio del escritorio 5.5.2. Lista de Oposiciones Esta es la vista con la principal funcionalidad de la aplicación. El principal objetivo del proyecto es permitir al usuario visualizar las oposiciones que desee, según varios criterios. La elección de estos criterios ya se ha explicado en capítulos anteriores, y ahora queda desarrollar la forma en la que el usuario pueda introducir estos criterios a la hora de realizar una búsqueda. La primera entrada corresponde al campo del título de la oposición. Se le distingue entre los otros campos, debido a que la información que hay en el título abarca contiene información de los epígrafes, departamentos y de la misma fecha de la oposición. Esto permite al usuario filtrar con gran detalle introduciendo solo información en un solo campo. Los dos campos siguientes corresponden al Departamento y a la Especialidad de la oposición. Se ha cambiado el término del Epígrafe por Especialidad en la presentación del usuario, ya que se puede encontrar al Epígrafe como un término demasiado poco explicativo para el usuario, aunque la propia fuente oficial se refiera a este campo por Epígrafe. Los campos ”Desde” y ”Hasta” permiten al usuario introducir un rango de fechas para poder filtrar oposiciones que estén comprendidas en ese rango. Si el usuario solo introduce el primer campo ”Desde”, se entenderá que solo quiere ver las oposiciones con la misma fecha que ese campo. Y si el usuario solo introduce el segundo campo ”Hasta”, la aplicación entenderá que quiere ver las oposiciones se hayan dispuesto, como máximo, hasta esa fecha. 55 5.5. DISEÑO DE LA PÁGINA Para poder permitir al usuario filtrar las oposiciones según el estado en el que esté, se ha decidido por desplegable que de la posibilidad al usuario de seleccionar el tipo de estado en el que se puede encontrar la oposición, sin que este tenga que saberlo de memoria. Finalmente, aparece un botón que servirá para realizar la búsqueda, redirigiendo al usuario a la nueva ventana con las oposiciones que desee. Las oposiciones aparecerán ordenadas según la fecha de disposición, apareciendo como primera la más nueva. La información que aparecerá en esta ventana, será par departamentoepígrafe, así como la fecha de disposición y el estado de esta. La idea de la lista de las oposiciones es que se vaya cargando a medida que el usuario navegue por la vista. Así, evitamos que la página espere para recibir todas las oposiciones, las cuales son muy numerosas, lo cual sería un proceso extremadamente lento. Para ver el boceto del dispositivo móvil 5.8. Para ver el boceto del escritorio vea la figura 5.9. 5.5.3. Lista de Departamentos/Epígrafes Al haber una gran cantidad de departamentos y de epígrafes (especialidades), es imperativo ofrecer al usuario una forma de ver qué tipos de departamentos y de epígrafes hay. Para ayudar al usuario, aparecerá un sistema de búsqueda, bastante simple, con el que pueda filtrar y seleccionar el dato que quiera. Las vistas de los departamentos y los epígrafes son similares, lo único que se diferencian es el título que aparece debajo del buscador. También, esta vista se asemeja a la disposición de los datos que referencian los departamentos y epígrafes (los departamentos que están relacionados con un cierto epígrafe, o los epígrafes que se relacionan con un cierto departamento). Igualmente, para esta vista se cambiará de título, para mostrar al usuario que está en una especie de detalle del departamento/epígrafe seleccionado (Departamento/Nombre del departamento/Epígrafes o Epígrafes/Nombre del epígrafe/Departamento). Para ver el boceto del dispositivo móvil 5.10. Para ver el boceto del escritorio vea la figura 5.11. 5.5.4. Detalle de la Oposición Para facilitar al usuario, se ha elegido que esta sea una ventana emergente. Esta decisión de diseño facilita al usuario la posibilidad de ir de oposición en oposición, sin tener que moverse de la ventana. Dentro del diseño, la ventana tendrá información de la oposición, así como un hilo de los cambios que ha tenido, o que esta haciendo ese documento. El diseño de esta información pretende asemejarse al formato que Twitter que con la creación de hilos, permitiendo ver el 56 CAPÍTULO 5. DISEÑO histórico de cambios, con tan solo moverse por la pantalla, sin tener que navegar entre otras vistas. Sobre la información del documento seleccionado, aparecerá el título, la fecha, el par Departamento-Epígrafe y el identificador. Dentro de las referencias, aparecerá también el par Depatamento-Epígrafe y el ”título” de la referencia (en realidad es el conjunto del atributo palabra y texto que aparece en el documento oficial). Debido a la decisión de diseño de tener una base de datos ligera, con poca información. Es indispensable ofrecer al usuario la posibilidad de acceder al documento con la información completa. En la ventana, aparecerá un botón con un Icono que se asocie fácilmente a un documento, y este te llevará a la dirección del documento oficial en formato PDF. Para ver el boceto del dispositivo móvil 5.12. Para ver el boceto del escritorio vea la figura 5.13. 57 5.5. DISEÑO DE LA PÁGINA Figura 5.13: Boceto de la ventana con el detalle de la oposición del escritorio 64 CAPÍTULO 6. IMPLEMENTACIÓN Y PRUEBAS Capítulo 6 Implementación y Pruebas 6.1. Backend La aplicación se divide entre la Capa de Presentación (Frontend) y Capa de Acceso a Datos (Backend). Cada capa está implementada de forma distinta. La parte Backend conforma la parte de la aplicación donde residen los datos y donde accede el Frontend para acceder a ellos. Dentro de esta parte, podemos distinguir dos procesos necesarios dentro del Backend. El primero es el Script de recopilación de datos y el segundo es el Servicio REST. 6.1.1. Script de Recopilación de Datos Este Script permite a la aplicación tener una base de datos actualizada. Este accede al Boletín Oficial del Estado diariamente en busca de oposiciones o documentos que realicen cambios. El Script se ha hecho utilizando el Entorno de Desarrollo Integrado (IDE) de NetBeans. El lenguaje en el que está basado el programa es Java. Este lenguaje tiene diversas bibliotecas que nos permite comunicarnos con la base de datos y acceder a documentos de internet. El funcionamiento es simple: El Script en estado normal está esperando hasta que se publique el BOE de ese día. Normalmente, la fecha de publicación ronda entre las 9 a.m. y las 10 a.m.. Otro detalle referente a la publicación del BOE es que no publica los domingos. Con todos estos datos, el Script se lanza las 11 a.m. de lunes a sábado. Cuando el Script accede al boletín, este busca los documentos referentes a las oposiciones en la sección 2.B Oposiciones y Concursos. En este documento recopila los datos referentes a los Departamentos y Epígrafes (posteriormente este término pasará a llamarse Especialidades). Por cada documento referente a una oposición, hay un acceso al documento detallado 65 6.1. BACKEND de este. Aquí, el Script recopila el resto de datos importantes que tiene la oposición y comprueba si el documento es una corrección o una oposición normal. Si el documento es una corrección, se comprobará si la corrección tiene un carácter modificador del estado de la oposición a la que se refiere, es decir, si el documento aprueba o cancela una oposición. Si es así, la oposición a la que se refiere el documento cambiará de estado dependiendo del carácter del documento modificador. Si se ejecuta el Script sin argumentos, se recopilarán las oposiciones del día actual. Esto está hecho así para que un programador de tareas (como el de Windows) pueda ejecutar la aplicación diariamente. Se puede añadir como argumento una fecha, del formato DD MM YYYY, haciendo que se recopilen las oposiciones desde ese día hasta el actual. Este argumento es bastante útil si la base de datos está vacía y se busca rellenarla de datos. Ya habiendo rellenado la base de datos con los Departamentos, Especialidades, Oposiciones y demás clases soporte, todavía nos queda ver cómo se puede acceder a estos datos. 6.1.2. Servicio REST La API REST se ha construido con el lenguaje Java utilizando NetBeans como entorno de desarrollo. Como ya se ha comentado, este servicio implementa un acceso definido a los datos. La aplicación NetBeans cuenta con un sistema automatizado de creación de modelo usando la base de datos de referencia. Esto, permite tener una representación exacta del modelo dentro de la API. Adicionalmente, con NetBeans se puede generar automáticamente un sistema de Persistencia JPA (Java Persistence API) que nos permite tener una serie de clases que implementan la funcionalidad de acceso a la base de datos. En el capítulo referente al diseño, se explica en más detalle cómo está organizado este servicio. La funcionalidad se reparte en 3 recursos: Recurso Oposiciones, Recurso Departamentos y Recurso Epígrafe/Especialidad. Las 3 permite acceder a un único recurso del mismo tipo y al conjunto de ellos. En el Recurso Oposiciones está la funcionalidad referente a las oposiciones y a las referencias de estas. Mediante el identificador, se puede acceder a las referencias anteriores y a las referencias posteriores, permitiendo al usuario ver el historial de cambios que ha habido en un mismo documento. La funcionalidad para ver los departamentos que tiene una especialidad y viceversa, la tienen el Recurso Departamento y el Recurso Especialidad/Epígrafe. Estos recursos tienen la funcionalidad básica de acceso a los datos mediante el identificador y el acceso al conjunto de datos, y a mayores tienen esta funcionalidad. 66 CAPÍTULO 6. IMPLEMENTACIÓN Y PRUEBAS 6.2. Frontend Dentro del Frontend, se encuentra la capa de presentación, es decir, donde el usuario va a interactuar con la aplicación. El proceso de creación del proyecto fue automático, ya que la misma aplicación Visual Studio Code implementa un sistema de generación automática de proyectos, incluyendo soporte para el Framework de Ionic. El servidor donde se despliega la aplicación web lo implementa la misma aplicación de Visual Studio Code. La generación de vistas y de componentes también la hace automáticamente la aplicación usando los comandos correspondientes. En total, la aplicación cuenta con cuatro páginas: Página Inicial, Lista de Oposiciones, Lista de Departamentos o Especialidades, Detalle de los Departamentos y Especialidades, y Detalle de la Oposición. Todas estas páginas contienen la cabecera de la página que contiene el menú que permite al usuario navegar entre todas estas vistas. El componente Detalle de la Oposición es una ventana emergente y está disponible dentro de la página principal y en el listado de las oposiciones. Las páginas se han basado en los bocetos que se hicieron en la etapa de Diseño. Durante la implementación, hubieron algunos cambios, como la decisión de poner un fondo de pantalla en vez de el color plano que había antes. 6.3. Pruebas 6.3.1. Pruebas Automatizadas Servicio REST El proceso de prueba del servicio REST se realizó utilizando la herramienta Postman. Esta herramienta ya ha sido introducida en capítulos anteriores. Con Postman se puede crear una serie de peticiones automatizadas con las que probar los servicios REST. Para realizar las pruebas es necesario tener una serie de datos en la aplicación. Debido a que los datos dependen del boletín y que estos pueden verse modificados a lo largo del tiempo, es necesario crear una serie de datos que imiten el proceso real. Una vez con los datos dispuestos, se creó una serie de casos de uso en los que se tendría que probar la aplicación. 67 6.3. PRUEBAS Nombre de la prueba Descripción Estado Salida Get Oposición Petición de una oposición existente en la aplicación Correcto Objeto de la oposición pedida Get Oposición Inexistente Petición de una oposición inexistente en la aplicación Fallo Resultado vacío Get Epígrafe Petición de un epígrafe existente en la aplicación Correcto Objeto del epígrafe pedido Get Epígrafe Vacío Petición de un epígrafe inexistente en la aplicación Fallo Resultado vacío Get Departamento Petición de un departamento existente en la aplicación Aceptado Objeto del departamento pedido Get Departamento Inexistente Petición de una departamento inexistente en la aplicación Fallo Resultado vacío Get Epígrafes Departamento Petición para ver los epígrafes que tiene asociado un departamento Aceptado Lista de epígrafes Get Departamentos Epígrafes Petición para ver los departamentos que tiene asociado un departamento Aceptado Lista de departamentos Get Oposiciones Departamento Epígrafe Petición para ver las oposiciones con el mismo par Departamento-Epígrafe Aceptado Lista de oposiciones Get Oposición Búsqueda Petición de búsqueda completa en la que se rellenan todas las opciones Aceptado Lista de oposiciones Get Oposición Búsqueda Rango Fechas Petición de búsqueda en la que se rellenan los campos de fecha Aceptado Lista de oposiciones Tabla 6.1: Tabla con las pruebas de caja negra del servicio REST A continuación, se muestra una imagen de los resultados dentro de la aplicación Postman: 68 CAPÍTULO 6. IMPLEMENTACIÓN Y PRUEBAS Figura 6.1: Ejemplo de una prueba en la aplicación Postman Figura 6.2: Captura de la aplicación Postman con las pruebas automatizadas 69 6.3. PRUEBAS 6.3.2. Pruebas E2E Habiendo probado el funcionamiento de los servicios REST, ya tenemos asegurado el acceso a los datos. Debido a diversos imprevistos, se ha visto necesario sustituir los métodos de testeo automáticos por un modo manual. A continuación, se ha descrito el procedimiento que se ha seguido para probar la aplicación. En la vista de la presentación, solo hay dos elementos que se puedan testear: uno es las redirecciones del menú y de la presentación, y el otro es el listado de oposiciones de la semana. Se probó que los elementos de la interfaz que sirvan para permitir al usuario moverse por las vistas funcione y redirija correctamente a la vista deseada. Para las oposiciones de la semana, se comprobó que el listado no sale de los límites de la fecha, y que al seleccionar una oposición, se abría la ventana emergente con su información detallada. En la vista del listado de oposiciones, se comprobó que la disposición de las oposiciones aparecen primero las más recientes. Dentro de estas oposiciones se comprobó que al acceder a una, se abría la ventana emergente con su información detallada. Esta vista tiene el sistema de búsqueda avanzado, para esto se realizó una serie de peticiones comprobando que cada entrada de búsqueda funciona correctamente y en combinación con las demás. Con esto, comprobamos correctamente el sistema de búsqueda avanzado, ya que podía haber algún requisito en algún campo que no se hubiese detectado. Para comprobar que al acceder al Figura 6.3: Ejemplo de búsqueda con fechas, estado y especialidad rellenada detalle de la oposición se recogen las referencias anteriores y posteriores, se hizo una búsqueda para obtener las oposiciones que han sufrido algún cambio, es decir, las oposiciones con el estado Aprobado o Cancelado. Aquí, se comprobó que al acceder a su detalle, aparecían los documentos que realizaban dichos cambios. Para comprobar las referencias anteriores, se siguió el mismo método pero al revés, buscando las oposiciones que tengan el estado de ”Corrección”, ya que estas al hacer cambios en oposiciones anteriores, se asegura tener mínimo una referencia anterior. Dentro del listado de Especialidades y Departamentos, se comprobó se listaran correctamente por orden alfabético que el sistema de búsqueda funcionaba correctamente. Para comprobar el funcionamiento de la búsqueda por directorio, se seleccionó el mismo par 70 CAPÍTULO 6. IMPLEMENTACIÓN Y PRUEBAS Departamento-Especialidad, ya que las oposiciones resultantes serían las mismas. 71 6.3. PRUEBAS 72 CAPÍTULO 7. SEGUIMIENTO Capítulo 7 Seguimiento Durante finales del mes de enero y de febrero comenzaron las primeras reuniones explicativas del proyecto. Se realizó una reunión que sirvió como Sprint Planning, donde se introdujeron los objetivos del proyecto, así como los requisitos que se querían abarcar. Esta reunión dio comienzo al proyecto en sí. 7.1. Sprint 1 (31/01/2021 - 7/02/2021) Tarea Estado Tiempo estimado Tiempo invertido Estudiar la disposición de los datos abiertos en el BOE Completado 12 horas 10 horas Estudiar la forma en la que se va a abordar el proyecto Completado 10 horas 8 horas Hacer documentación para la memoria En proceso 4 horas 7 horas Total 3/2 tareas 25 horas 26 horas Tabla 7.1: Sprint 1 Este sprint tenía como objetivo estudiar la forma en la que se presentan los datos en el BOE. Esta parte es fundamental, ya que todo el proyecto depende de ello. Si no existe una forma en la que se puedan acceder a los datos, no tiene sentido hacer un gestor de oposiciones. Se encontró la forma de acceder a estos datos en la página oficial del BOE. Este se presenta a diario en formato XML, y en la sección 2B se encuentran alojados las oposiciones. Dentro de las oposiciones, se vio un gran problema: los datos que nos interesaban no estaban puestos en ningún formato, ya que la mayoría de datos importantes aparecen dentro 73 7.10. ÉPOCA DE PRÁCTICAS (17/05/2021 - 30/05/2021) Tarea Estado Tiempo estimado Tiempo invertido Estudio de los datos de las oposiciones Completado 4 horas 4 horas Modificación de los bocetos y del modelo para implementar el sistema de búsqueda Completado 8 horas 6 horas Implementación del sistema de búsqueda en el Frontend Completado 12 horas 15 horas Hacer documentación para la memoria Completado 4 horas 5 horas Total Completado 28 horas 30 horas Tabla 7.9: Sprint 8 Después, empezó la implementación del sistema de búsqueda avanzado de las oposiciones. Al principio se creó un servicio REST por cada petición, pero al haber tantas combinaciones en la aplicación se cambió por un único servicio REST que tenía como parámetros todos los términos de búsqueda, imitando la forma en la que páginas implementan estas funcionalidades. Como siempre, se testeo el servicio REST, y después de haber comprobado su validez se empezó a implementar su contraparte en el Frontend. Con el servicio REST validado y funcional, se empezó a diseñar la funcionalidad dentro de la aplicación. Para las oposiciones se añadió el sistema de búsqueda complejo, y para las especialidades y departamentos se añadió un sistema simple de búsqueda por palabra que permitía al usuario encontrar el resultado deseado. 7.10. Época de prácticas (17/05/2021 - 30/05/2021) Tarea Estado Tiempo estimado Tiempo invertido Mejorar estética de la aplicación Completado 4 horas 4 horas Seguir estudiando los datos de las oposiciones Completado 2 horas 6 horas Hacer documentación para la memoria En proceso 4 horas 2 horas Total 3/2 tareas 10 horas 14 horas Tabla 7.10: Segunda Época de Prácticas y Exámenes Este fue el segundo periodo en el que se juntaron prácticas de otras asignaturas y demás 80 CAPÍTULO 7. SEGUIMIENTO exámenes, los cuales impidieron realizar con normalidad el desarrollo. Esto no impidió que se dedicara cierto tiempo para mejorar el diseño de la aplicación. Fue en esta etapa en la que se cambió el fondo básico verde por un fondo de pantalla que seguía el mismo tono cromático. El fondo seguía un patrón geométrico que ayuda a transmitir la sensación de estar en una clase, además se buscó una imagen libre de derechos y de marcas de agua que empeoraran la estética de la aplicación. En este periodo también se avanzó en la memoria de la aplicación, debido a que este proceso no implicaba dedicar largas sesiones de tiempo. Por el mismo motivo, se incentivó el estudio de las oposiciones en busca de datos que pudieran ser relevantes para el usuario. Se creó una versión del Script para realizar pruebas y se encontró que había ciertos documentos que realizaban cambios para ciertas oposiciones. El Script ayudó para ver la importancia de estos datos, ya que se pudo ver la cantidad de documentos que no eran oposiciones, sino actualizaciones de las mismas. 7.11. Sprint 9 (31/05/2021 - 07/06/2021) Tarea Estado Tiempo estimado Tiempo invertido Creación del boceto para la página principal Completado 4 horas 4 horas Modificación del boceto del listado de oposiciones para implementar el nuevo sistema de búsqueda Completado 2 horas 2 horas Modificación del servicio rest para implementar el nuevo sistema de búsqueda completado 6 horas 6 horas Implementación de las nuevas características en el Frontend completado 6 horas 5 horas Hacer documentación para la memoria Completado 6 horas 6 horas Total Completado 24 horas 23 horas Tabla 7.11: Sprint 9 Para este tiempo se realizó una reunión en la que se pidieron añadir más campos de búsqueda en los que el usuario pudiera introducir los datos. También, se vio la necesidad de añadir una ventana de inicio en la que los usuarios pudieran entrar por primera vez y conocer las funcionalidades que tenía la página. 81 7.12. SPRINT 10 (08/06/2021 - 15/06/2021) En esta vista podías encontrar una presentación de los datos que había en la página, así como una breve explicación de las funcionalidades que prestaba al usuario. Adicionalmente, gracias al proceso de investigación de las oposiciones, se encontró que ciertas documentos que incluíamos junto a las oposiciones eran documentos de corrección. Estos documentos referenciaban a las oposiciones y añadían cambios, ofrecían una lista con los aprobados o cancelaban la oposición. Al ver esto, se vio la necesidad de meter estos datos en la aplicación y de presentarlos en forma de un hilo, parecido al concepto de hilo de twitter, en el cual los usuarios pudieran ver el historial de cambios de la oposición. Este sprint se focalizó en las funcionalidades de la página de inicio y del nuevo sistema de búsqueda. Para esto, se modificaron los bocetos existentes para añadir soporte a estas nuevas funcionalidades. Ahora se podían filtrar las oposiciones según las especialidades, el departamento y el estado de la oposición junto a la búsqueda por rango de fechas y por el título de la oposición. Para la ventana de presentación también se tuvieron que crear los bocetos correspondientes. La página debía contener una parte destinada a la explicación de los datos, y como después se vio que la página estaría vacía, se decidió añadir una lista con las oposiciones más recientes del BOE. Se modificó el modelo de la aplicación, así como los servicios REST existentes para dar soporte a los cambios, y se añadieron los nuevos servicios REST correspondientes al nuevo sistema de búsqueda. Se trasladaron los conceptos de las interfaces desde los bocetos a la aplicación y se añadió la funcionalidad requerida. 7.12. Sprint 10 (08/06/2021 - 15/06/2021) Este sprint tenía como objetivo seguir con la implementación de los nuevos requisitos faltantes, así como el análisis de los mismos . Se modificó el boceto del Detalle de la Oposición para que hubiese espacio para las referencias que tenga el documento seleccionado. El objetivo era que estas referencias se parecieran al concepto de hilo que aparece en la red social Twitter, el cual sirve para mostrar un histórico de cambios en las oposiciones. Estas modificaciones tendrán un botón que permita al usuario ver el documento oficial en la página del Boletín Oficial del Estado. Dentro de la implementación, se tuvo que modificar el Script de recolección de datos para implementar la extracción de estas nuevas referencias, y también modificar las oposiciones a las que se referencien los nuevos cambios. Esto implica añadir más accesos a la base de datos, lo que implica que el proceso de recolección tarde ahora más tiempo. Esto no es problema ya que el tiempo de recolección de datos no tiene como objetivo ser el más rápido, sino ofrecer un servicio completo y fiable. 82 CAPÍTULO 7. SEGUIMIENTO Tarea Estado Tiempo estimado Tiempo invertido Modificación del boceto del detalle de la oposición Completado 2 horas 2 horas Modificación del Script para implementar la nueva funcionalidad Completado 5 horas 4 horas Implementación del servicio REST de la nueva funcionalidad Completado 4 horas 2 horas Rediseñar la vista de detalle de la oposición Completado 1 horas 1 horas Implementar nueva funcionalidad en el Frontend Completado 8 horas 4 horas Desarrollo de tests automatizados del servicio REST Completado 10 horas 10 horas Hacer documentación para la memoria Completado 6 horas 5 horas Total Completado 36 horas 28 horas Tabla 7.12: Sprint 10 Para el servicio REST se añadió esta nueva funcionalidad dentro del servicio de Oposiciones. Este permitía al usuario consultar si un documento se ha referenciado en el pasado y ver estas referencias, así como también permitir ver las oposiciones a las que referencia el documento. Usando de guía los bocetos, se editó la vista de detalles de la oposición para añadir la funcionalidad. Dentro de cada documento, se podía consultar si este había sido referenciado por otro documento, o si este documento estaba referenciando a otros. 7.13. Spint Final (18/06/2021 - Entrega del proyecto) Tarea Estado Tiempo estimado Tiempo invertido Rematar documentación la memoria del TFG Completado 20 horas 18 horas Limpieza del código Completado 4 horas 2 horas Total Completado 20 horas 18 horas Tabla 7.13: Sprint Final 83 7.14. RECAPITULACIÓN El objetivo del sprint era acabar la memoria y depurar el código en busca de imperfecciones. La memoria a estas alturas estaba inacabada y faltaban temas que tratar. Había que añadir la documentación pertinente referente a las pruebas y la implementación del código. También, había que hacer un resumen del documento y traducirlo al inglés. Adicionalmente, había que añadir las referencias que se habían usado durante el desarrollo de la memoria en la sección de Bibliografía. También, se buscó mejorar la estética de la memoria añadiendo imágenes en las herramientas, así como capturas del código. En al depuración del código, se eliminaron los comentarios que se iban haciendo durante el desarrollo sobre las partes que faltaban, etc. También, se hicieron unas últimas pruebas en las que se buscaba eliminar el código sobrante que no se utilizaba. 7.14. Recapitulación 7.14.1. Calendario final Durante el desarrollo del proyecto, y debido al horario caótico que tenía el estudiante con las asignaturas y exámenes, el calendario final quedaría de esta forma: Nombre del Sprint Duración del sprint Sprint 1 31/01/2021 - 7/02/2021 Sprint 2 08/02/2021 - 15/02/2021 Sprint 3 15/02/2021 - 23/02/2021 Sprint 4 23/02/2021 - 02/03/2021 Sprint 5 04/03/2021 - 14/04/2021 Época de prácticas 14/03/2021 - 10/04/2021 Sprint 6 12/04/2021 - 25/04/2021 Sprint 7 26/04/2021 - 02/05/2021 Sprint 8 04/05/2021 - 12/05/2021 Época de prácticas 17/05/2021 - 30/05/2021 Sprint 9 31/05/2021 - 07/06/2021 Sprint 10 08/06/2021 - 15/06/2021 Sprint Final 15/06/2021 - Entrega Proyecto Tabla 7.14: Calendario Final 7.14.2. Trabajo Total A continuación, se presentará una tabla con el trabajo total acumulado durante todos los sprints, junto al trabajo estimado que en un principio se pensaba que iba a durar. 84 CAPÍTULO 7. SEGUIMIENTO Nombre del Sprint Trabajo Estimado Trabajo Real Sprint 1 25 horas 26 horas Sprint 2 28 horas 28 horas Sprint 3 30 horas 32 horas Sprint 4 34 horas 30 horas Sprint 5 22 horas 22 horas Época de prácticas 10 horas 12 horas Sprint 6 32 horas 30 horas Sprint 7 21 horas 20 horas Sprint 8 28 horas 30 horas Época de prácticas 10 horas 14 horas Sprint 9 24 horas 23 horas Sprint 10 36 horas 28 horas Sprint Final 25 horas 26 horas Total 300 horas 295 horas Tabla 7.15: Calendario Final 85 7.14. RECAPITULACIÓN 86 CAPÍTULO 8. CONCLUSIONES Capítulo 8 Conclusiones Acabada el proyecto, se han visto cumplidos gran parte de los objetivos planteados. Gracias al Framework de Ionic, hemos podido convertir la aplicación en una PWA (Aplicación Web Progresiva), lo que permite tener soporte para ordenadores y para dispositivos móviles. Contamos con un Script que permite tener acceder al Boletín Oficial del Estado y crear un registro de las oposiciones que se emiten diariamente. Dentro de la funcionalidad del usuario, contamos con un sistema de búsqueda que permite filtrar las oposiciones según distintos criterios. También, permitimos al usuario poder navegar con facilidad a los documentos oficiales que emite el BOE, presentando una vista con un historial de cambios que ha ido teniendo la oposición. El proyecto comenzó a finales de Enero durante el inicio del segundo cuatrimestre y realizándose en paralelo junto con 2 asignaturas y las prácticas curriculares. Esto repercutió en el plan de trabajo, ya que había ocasiones en las que el desarrollo se tenía que ver detenido debido a la aparición de exámenes y prácticas. El plan de trabajo se dividió en sprints en los que se establecieron objetivos y tareas a realizar. Durante el proyecto, hubieron dos grandes parones en los que el alumno tuvo que dedicar tiempo a las demás asignaturas, aunque en todo momento hubo un mínimo contacto con el desarrollo. Durante la primera etapa del proyecto se focalizó en la manera de recoger los datos del Boletín Oficial del Estado. Las oposiciones las emiten los departamentos dividiendo el propósito de estas en epígrafes (el término puede asociarse con la especialidad de la oferta de la oposición). Con esta información, se desarrollo una serie de diagramas de diseño y un Script para recoger los datos de las oposiciones. El objetivo del Script era doble: tener un mecanismo por el cual poder estudiar las oposiciones y la disposición de los datos en el BOE, y también la de rellenar la base de datos que después se utilizaría en la aplicación. En la segunda etapa, se desarrolló una API REST para implementar un mecanismo de acceso a los datos para la capa de presentación. Los servicios se construyeron en base a los diagramas que se crearon en la anterior etapa. La fase de prueba de estos servicios se hizo con el programa Postman, donde se creó una serie de pruebas automatizadas. Esta etapa fue dividida en dos, ya que se produjo el primer parón del proyecto. Aun así, se realizó la etapa 87 8.1. TRABAJO FUTURO con éxito. La última etapa se caracterizó por la construcción de la capa de presentación. Para esta etapa se creó una serie de bocetos para tener una guía visual a la hora de implementar las páginas. Se definió un estilo visual y con ello ya empezó la implementación. Durante esta etapa, se dedicó un tiempo al aprendizaje de Ionic, ya que este no había sido utilizado nunca por el alumno. Aún con este contratiempo y el parón que se produjo durante el desarrollo de esta etapa, se consiguió desarrollar una página web en la que los usuarios pudieran consultar las oposiciones del Boletín Oficial del Estado. El problema más grande que se ha tenido a lo largo del proyecto, ha sido la falta de datos con un formato definido en las oposiciones. Los datos más importantes estaban en el apartado ”texto”. Esto no sería problema si, aun así, hubiera un formato mínimo, ya que con un simple proceso de data mining se podrían haber recogido los datos. El problema es que no había un formato definido, ya que dependiendo el formato dependía del departamento en el que se emitiera la oposición. Como se comentó a lo largo de la memoria, se estudiaron los boletines de otras comunidades para ver si estas cumplían un formato, y lo que se sacó en claro es que había oposiciones que sí cumplían un formato definido y otras que no. Debido a este problema, y a la escasa formación en data mining del estudiante, no se pudieron cumplir algunas funcionalidades deseadas. 8.1. Trabajo Futuro El proyecto ofrece un servicio completo en el que el usuario pueda consultar las oposiciones usando diversas funcionalidades, pero aun con todo esto, el proyecto no es perfecto y hay detalles que se pueden añadir: Mejora del aspecto visual. Debido a la aparición de improvistos que implicaron tener parado el proyecto durante varias semanas, este aspecto de la aplicación tuvo que verse mermado. El aspecto visual no es del todo malo, pero puede mejorarse mucho. Implementación de data mining en la recogida de los datos. El mayor problema que se ha tenido a la hora de recoger los datos de las oposiciones, es la falta de un formato claro dentro del BOE. La información más importante (numero de plazas que ofrece la oposición, la fecha de recogida de solicitud, etc) no siguen un formato claro. Esto puede arreglarse mediante un complejo sistema de data mining. Esta solución no ha podido hacerse en este proyecto, ya que el alumno no tenía conocimientos acerca de estos métodos, por lo cual, el proyecto se ha tenido que hacer con la poca información formateada. Guardar los datos del PDF en la base de datos. Actualmente, la base de datos es bastante ligera en términos de memoria. Esto se puede cambiar, guardando la información de las oposiciones en la base de datos, para poder acceder a su PDF, independientemente de si su versión dentro del boletín está disponible. Con esto, podemos aumentar la independencia de la página oficial. 88 CAPÍTULO 8. CONCLUSIONES Cambiar el sistema de búsqueda con los nuevos datos. Este aspecto va de la mano con el proceso anterior. Como se ha dicho antes, es muy interesante por parte del usuario poder conocer el número de plazas y la fecha de solicitud de una oposición dada, entre otros datos. Para esto, se podría ofrecer al usuario la posibilidad de conocer las oposiciones que tengan abierto el plazo de solicitud, pudiendo eliminar otros métodos de búsqueda que sean menos usados. Mejorar captura de errores. El programa ha sido testeado en busca de fallos, pero no se han podido crear métodos automáticos de testeo. Esta parte puede ser de gran utilidad a la hora de añadir funcionalidad, ya que se podría probar que no se cometiera ningún fallo en la funcionalidad actual. 89 A.3. MANUAL DE USO DE LA APLICACIÓN Figura A.4: Vista del listado de las oposiciones junto al nombre del elemento y el tipo de elemento al que se está refiriendo. Si se selecciona Figura A.5: Vista del detalle de un Departamento uno de estos elementos, volveremos a la vista de las oposiciones con el par DepartamentoEspecialidad definido. Seleccionando cualquiera de estas oposiciones, aparecerá una ventana emergente con el detalle de la oposición y documentos a los que está relacionado. 96 APÉNDICE A. MANUAL Figura A.6: Vista en detalle de una oposición 97 A.3. MANUAL DE USO DE LA APLICACIÓN 98 BIBLIOGRAFÍA Bibliografía [1] Apache. Apache derby. https://db.apache.org/derby/, 2021. Último acceso: 08-052021. [2] Astah. Astah professional. https://astah.net/products/astah-professional/, 2021. Último acceso: 16-04-2021. [3] Autograndad. Glassfish. https://amp.es.autograndad.com/1014314/1/glassfish .html, 2020. Último acceso: 08-05-2021. [4] Azahara Benito. Los 8 principios básicos de los datos abiertos. https://www.ogoov. com/es/blog/los-8-principios-basicos-de-los-datos-abiertos/, 2019. Último acceso: 26-04-2021. [5] brunocascio. Resumen ingeniería de software 2 (diseño, pruebas y mantenimiento). https://gist.github.com/brunocascio/5e89fafa7fd86bdd1a715d2f6f0432d1, 2016. Último acceso: 01-05-2021. [6] Capterra. Pencil project. https://www.capterra.es/software/176481/pencilproject, 2018. Último acceso: 12-04-2021. [7] Víctor Cuervo. ¿qué es apache derby? https://www.oracle.com/middleware/techno logies/glassfish-server.html, 2016. Último acceso: 08-05-2021. [8] Junta de Andalucía. Netbeans. http://www.juntadeandalucia.es/servicios/made ja/contenido/recurso/888, 2019. Último acceso: 03-05-2021. [9] Junta de Castilla y León. Datos abiertos de castilla y leÓn. https://datosabier tos.jcyl.es/web/es/datos-abiertos-castilla-leon.html, 2021. Último acceso: 26-04-2021. [10] Junta de Castilla y León. ¿quÉ son los datos abiertos? https://datosabiertos.jc yl.es/web/es/iniciativa-datos-abiertos/datos-abiertos.html, 2021. Último acceso: 26-04-2021. [11] Agencia Estatal Boletín Oficial del Estado. Buscar. https://www.boe.es/buscar/, 2021. Último acceso: 22-04-2021. 99 BIBLIOGRAFÍA [12] Agencia Estatal Boletín Oficial del Estado. Documento xml de la oposición boe-a-20209967. https://boe.es/diario_boe/xml.php?id=BOE-A-2020-9967, 2020. Último acceso: 23-04-2021. [13] Agencia Estatal Boletín Oficial del Estado. Documento xml del documento boe-s20200201. https://boe.es/diario_boe/xml.php?id=BOE-S-20200201, 2020. Último acceso: 23-04-2021. [14] Agencia Estatal Boletín Oficial del Estado. Personal: ayuda y contenido. https: //www.boe.es/buscar/ayudas/personal_ayuda.php, 2021. Último acceso: 22-042021. [15] Agencia Estatal Boletín Oficial del Estado. Personal: Oposiciones, nombramientos... https://www.boe.es/buscar/personal.php, 2021. Último acceso: 22-04-2021. [16] Evolus. Pencil project. https://pencil.evolus.vn, 2021. Último acceso: 07-05-2021. [17] María Isabel Alfonso Galipienso. Servicios rest. http://expertojava.ua.es/expert o/restringido/2014-15/rest/rest.html, 2014. Último acceso: 23-05-2021. [18] Google. Angularjs. https://angularjs.org, 2021. Último acceso: 07-05-2021. [19] Ionic. Ionic. https://ionicframework.com, 2021. Último acceso: 07-05-2021. [20] Krama. ¿qué es ionic? https://www.krama.es/blog-20-04-29-que-es-ionic.html, 2020. Último acceso: 07-05-2021. [21] Alejandro López. ¿qué es postman? https://openwebinars.net/blog/que-espostman/, 2019. Último acceso: 13-04-2021. [22] Sara López. Aplicaciones web progresivas: qué son, cómo funcionan y qué tienes que saber. https://www.digital55.com/desarrollo-tecnologia/que-es-pwa-ventaj as-desventajas/#:~:text=Funcionalidades%20propias%20de%20una%20App%20na tiva&text=Las%20Progressive%20Web%20App%20pueden,no%20está%20abierta%20 la%20PWA)., 2020. Último acceso: 01-06-2021. [23] BBVA API Market. Api rest: qué es y cuáles son sus ventajas en el desarrollo de proyectos. , 2016. Último acceso: 23-05-2021. [24] Microsoft. Visual studio code. https://code.visualstudio.com, 2021. Último acceso: 03-05-2021. [25] Mozilla. Mozilla firefox. https://www.mozilla.org/es-ES/firefox/new/, 2021. Último acceso: 13-04-2021. [26] Apache NetBeans. Netbeans. https://netbeans.apache.org, 2021. Último acceso: 03-05-2021. [27] Oracle. Glassfish server. https://www.oracle.com/middleware/technologies/gla ssfish-server.html, 2021. Último acceso: 08-05-2021. [28] Postman. Postman. https://www.postman.com, 2021. Último acceso: 02-06-2021. 100 BIBLIOGRAFÍA [29] Juan Ranchal. Aplicaciones web progresivas: qué son, cómo funcionan y qué tienes que saber. https://www.muycomputerpro.com/2019/09/26/aplicaciones-webprogresivas-que-son-como-funcionan-y-que-tienes-que-saber, 2019. Último acceso: 01-06-2021. [30] Sara Serrano. Eventos en scrum i. https://www.saraclip.com/eventos-en-scrum/, 2017. Último acceso: 21-05-2021. [31] Sara Serrano. Eventos en scrum ii. https://www.saraclip.com/eventos-en-scrumii/, 2017. Último acceso: 21-05-2021. [32] Team. ¿qué son los datos abiertos? https://www.opendatasoft.com/es/blog/2017/ 05/09/que-son-los-datos-abiertos, 2017. Último acceso: 26-04-2021. [33] ViewNext. Artefactos scrum ¿qué son y para qué sirven? https://www.viewnext.com /artefactos-scrum/, 2019. Último acceso: 22-05-2021. [34] Change Vision. astah* professional. https://software.com.ar/p/astah-profession al#product-description, 2019. Último acceso: 16-04-2021. [35] Wikipedia. Angular (framework). https://es.wikipedia.org/wiki/Angular_(fram ework), 2021. Último acceso: 07-05-2021. [36] Wikipedia. Mozilla firefox. https://es.wikipedia.org/wiki/Mozilla_Firefox, 2021. Último acceso: 13-04-2021. [37] Wikipedia. Scrum (desarrollo de software). https://es.wikipedia.org/wiki/Scru m_(desarrollo_de_software), 2021. Último acceso: 21-05-2021. [38] Wikipedia. Visual studio code. https://es.wikipedia.org/wiki/Visual_Studio_C ode, 2021. Último acceso: 03-05-2021. 101