Ampliación del sistema de comunicación interno en una empresa

Universidad de Valladolid E.T.S Ingenier´ıa Inform´atica Trabajo de Fin de Grado Grado en Ingenier´ıa Inform´atica Menci´on Ingenier´ıa de Software Ampliaci´on del sistema de comunicaci´on interno en una empresa Autor: H´ector Rogel Delgado Tutor UVA: Benjam´ın Sahelices Fern´andez Tutor empresa: Pablo Carrascal Mu˜noz Resumen Este Trabajo de Fin de Grado consiste en la rearquitectura completa de una aplicaci´on iOS cuyo uso es la gesti´on de las vacaciones de los empleados de una empresa. Esta aplicaci´on ya existente en la empresa requiere de un cambio completo de la misma: cambio de la arquitectura, interfaces, patr´on de acceso a datos y la inclusi´on de tests autom´aticos para mejorar la calidad del ”producto”. Tambi´en incluye un incremento de la funcionalidad de la aplicaci´on. 1 Abstract This Final Degree Project consists in a complete rearchitecture of an iOS application whose use is the holidays management of the company employees. This application already exists and requires a complete change of the whole application: architecture change, data access change and add automatic testing to improve the product quality. It also includes the implementation of new functionality to the application. 2 ´ Indice de Contenidos 1 Introducci´on 12 1.1 Contexto...................................... 12 1.2 Objetivos ..................................... 12 1.3 Contenidodelamemoria............................. 13 2 Entorno tecnol´ogico 14 2.1 Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Tecnolog´ıasutilizadas............................... 14 2.3 Recursoshardware ................................ 15 2.4 Scrum ....................................... 16 2.4.1 Roles.................................... 17 2.4.2 Artefactos................................. 17 2.4.3 Eventos .................................. 18 2.5 Modelo, Vista, Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6 Modelo, Vista, Vista de Modelo . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7 Patr´onrepositorio................................. 20 2.8 Patr´onobservador................................. 20 3 Gesti´on y planificaci´on del proyecto 21 3.1 Introducci´on.................................... 21 3.2 Descripci´on de la metodolog´ıa elegida . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Gesti´onderiesgos................................. 22 3.4 Estimaciones ................................... 24 3.4.1 Estimaci´on de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.2 Estimaci´on de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.3 Tiemporeal................................ 26 4 An´alisis 27 4.1 Proyectoexistente................................. 27 4.1.1 Introducci´on................................ 27 4.1.2 Descripci´on de la aplicaci´on existente . . . . . . . . . . . . . . . . . . 27 4.1.2.1 Login .............................. 27 4.1.2.2 Vista principal . . . . . . . . . . . . . . . . . . . . . . . . . 27 3 4.1.2.3 Men´ulateral .......................... 28 4.1.2.4 Perfil .............................. 28 4.1.2.5 Vacaciones ........................... 29 4.1.2.6 Tabl´on de anuncios . . . . . . . . . . . . . . . . . . . . . . . 30 4.1.2.7 Equipo ............................. 30 4.1.2.8 Empresa............................. 31 4.1.2.9 Ajustes ............................. 31 4.1.3 Dise˜no de la aplicaci´on existente . . . . . . . . . . . . . . . . . . . . . 31 4.1.3.1 Modelo de dominio . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.3.2 Arquitectura .......................... 32 4.1.3.3 Descomposici´on modular . . . . . . . . . . . . . . . . . . . . 34 4.1.4 Interfaz .................................. 35 4.1.5 Modelodedatos ............................. 35 4.1.6 Accesoadatos .............................. 35 4.2 An´alisis incremento funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3 Requisitos del proyecto (Product Backlog) . . . . . . . . . . . . . . . . . . . 36 5 Dise˜no 38 5.1 Introducci´on.................................... 38 5.2 Cambio de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.1 Finalidad ................................. 38 5.2.2 Contexto.................................. 38 5.2.3 Arquitectura................................ 39 5.2.4 Descomposici´on modular . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.5 Dise˜no modular de cada capa . . . . . . . . . . . . . . . . . . . . . . 41 5.2.5.1 Dise˜no modular ViewController . . . . . . . . . . . . . . . . 41 5.2.5.2 Dise˜no modular ViewModel . . . . . . . . . . . . . . . . . . 45 5.2.5.3 Dise˜no modular capa Model . . . . . . . . . . . . . . . . . . 48 5.2.5.4 Dise˜no modular capa Repository . . . . . . . . . . . . . . . 50 5.2.5.5 Dise˜no modular capa APIClient . . . . . . . . . . . . . . . . 50 5.2.5.6 Dise˜no modular capa Network . . . . . . . . . . . . . . . . . 51 5.3 Dise˜no incremento funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3.1 Arquitectura general . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3.2 Descomposici´on modular . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3.3 Dise˜no modular de cada capa . . . . . . . . . . . . . . . . . . . . . . 53 5.3.3.1 Dise˜no modular capa ViewController . . . . . . . . . . . . . 54 5.3.3.2 Dise˜no modular capa ViewModel . . . . . . . . . . . . . . . 55 5.3.3.3 Dise˜no modular capa Repository . . . . . . . . . . . . . . . 56 5.3.3.4 Dise˜no modular capa APIClient . . . . . . . . . . . . . . . . 57 5.3.3.5 Dise˜no modular capa Network . . . . . . . . . . . . . . . . . 58 5.3.4 Relaci´on entre capas . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.3.4.1 US25 - Ver solicitudes . . . . . . . . . . . . . . . . . . . . . 58 4 5.3.4.2 US26 - Gesti´on de vacaciones . . . . . . . . . . . . . . . . . 59 5.3.4.3 US27 - Historial usuario solicitud . . . . . . . . . . . . . . . 60 5.3.4.4 US28 - Redise˜no secci´on de Equipo . . . . . . . . . . . . . . 61 5.3.4.5 US29 - Ver vacaciones de cada usuario desde la secci´on de Equipo ............................. 62 5.3.5 Dise˜no de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.5.1 US25 - Ver solicitudes . . . . . . . . . . . . . . . . . . . . . 63 5.3.5.2 US26 - Gesti´on de vacaciones . . . . . . . . . . . . . . . . . 64 5.3.5.3 US27 - Historial usuario solicitud . . . . . . . . . . . . . . . 65 5.3.5.4 US28 - Redise˜no secci´on de Equipo . . . . . . . . . . . . . . 65 5.3.5.5 US29 - Ver historial en secci´on de vacaciones . . . . . . . . . 67 5.3.6 Sprints................................... 67 5.3.6.1 Sprint0............................. 68 5.3.6.2 Sprint1............................. 69 5.3.6.3 Sprint2............................. 71 5.3.6.4 Sprint3............................. 72 5.3.6.5 Sprint4............................. 73 5.3.6.6 Sprint5............................. 74 5.3.6.7 Sprint6............................. 74 5.3.6.8 Sprint7............................. 76 5.3.6.9 Sprint8............................. 77 5.3.6.10 Sprint9............................. 78 5.3.6.11 Sprint10 ............................ 79 5.3.6.12 Sprint11 ............................ 82 5.3.6.13 Sprint12 ............................ 83 5.3.6.14 Sprint13 ............................ 84 5.3.6.15 Sprint14 ............................ 86 6 Implementaci´on y tests 88 6.1 Cambio del software existente . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.1.1 Reestructuraci´on interfaces . . . . . . . . . . . . . . . . . . . . . . . . 88 6.1.2 Rearquitectura .............................. 88 6.1.2.1 Cambio a MVVM . . . . . . . . . . . . . . . . . . . . . . . 89 6.1.2.2 Cambio patr´on de acceso a datos . . . . . . . . . . . . . . . 89 6.2 Nuevafuncionalidad ............................... 90 6.3 Tests........................................ 91 6.3.1 Introducci´on................................ 92 6.3.2 UItests .................................. 92 6.3.3 Unittests ................................. 93 6.3.4 Networktests............................... 93 6.3.5 Librer´ıas necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.3.6 Tests autom´aticos realizados . . . . . . . . . . . . . . . . . . . . . . . 94 5 6.3.6.1 Perfil .............................. 95 6.3.6.2 Vacaciones ........................... 98 6.3.6.3 Tabl´on de anuncios . . . . . . . . . . . . . . . . . . . . . . . 99 6.3.6.4 Equipo .............................100 6.3.6.5 Informaci´on de la empresa . . . . . . . . . . . . . . . . . . . 101 6.3.6.6 Ajustes .............................102 6.3.6.7 Administraci´on . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.3.7 Tests manuales realizados . . . . . . . . . . . . . . . . . . . . . . . . 104 7 Conclusiones 106 Bibliograf´ıa 107 Appendices 109 Anexo A Manual de Usuario 110 Anexo B Manual de Instalaci´on 118 6 ´ Indice de Figuras 2.1 ArquitecturaMVC ................................ 19 2.2 ArquitecturaMVVM............................... 19 4.1 Interfaz del Men´u Lateral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 InterfazdelPerfil ................................. 29 4.3 InterfazdeVacaciones .............................. 30 4.4 Modelo de dominio de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . 32 4.5 Arquitectura MVC de la aplicaci´on existente . . . . . . . . . . . . . . . . . . 33 4.6 Descomposici´on modular de la aplicaci´on existente . . . . . . . . . . . . . . . 34 4.7 Esquema relacional de la base de datos . . . . . . . . . . . . . . . . . . . . . 35 5.1 Nueva arquitectura de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . 39 5.2 Nueva descomposici´on modular . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3 Dise˜no detallado rearquitectura, capa ViewController, secci´on de Login . . . 41 5.4 Dise˜no detallado rearquitectura, capa ViewController, secci´on Principal (twitter)......................................... 41 5.5 Dise˜no detallado rearquitectura, capa ViewController, secci´on de Perfil . . . 42 5.6 Dise˜no detallado rearquitectura, capa ViewController, secci´on de Vacaciones 43 5.7 Dise˜no detallado capa ViewController, secci´on del Tabl´on de Anuncios . . . . 43 5.8 Dise˜no detallado rearquitectura, capa ViewController, secci´on de Equipo . . 44 5.9 Dise˜no detallado rearquitectura, capa ViewController, secci´on de Empresa . 44 5.10 Dise˜no detallado rearquitectura, capa ViewController, secci´on de Settings . . 45 5.11 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Login . . . . . 45 5.12 Dise˜no detallado rearquitectura, capa ViewModel, secci´on Principal (twitter) 45 5.13 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Perfil . . . . . 46 5.14 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Vacaciones . . 46 5.15 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Tabl´on de Anuncios......................................... 47 5.16 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Equipo . . . . 47 5.17 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Empresa . . . . 47 5.18 Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Settings . . . . 48 5.19 Dise˜no detallado capa Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.20 Dise˜no detallado rearquitectura, capa Repository . . . . . . . . . . . . . . . 50 7 Cap´ıtulo 2 Entorno tecnol´ogico 2.1 Herramientas utilizadas Las herramientas utilizadas para la realizaci´on de este Trabajo de Fin de Grado son las siguientes: •XCode (versi´on 10.1): entorno o herramienta de desarrollo integrado (IDE) creado por Apple para macOS y que permite desarrollar software para macOS, iOS, watchOS y tvOS. •Simulator (vers´on 10.1): simulador integrado en XCode, permite simular las aplicaciones desarrolladas en un dispositivo virtual. •Jira Software: herramienta desarrollada por Atlassian cuya finalidad es administrar las tareas de un proyecto permitiendo el seguimiento de errores e incidencias. •Git: software de gesti´on de versiones. •Gitlab: servicio web basado en Git que permite la gesti´on de repositorios, control de versiones y desarrollo de software colaborativo. •OverLeaf: editor de LaTeX online. 2.2 Tecnolog´ıas utilizadas •Swift (versi´on 4.2): lenguaje de programaci´on creado por Apple para el desarrollo de aplicaciones iOS y macOS. •LaTeX: sistema para la composici´on de textos utilizado para la realizaci´on de este documento. 14 •CoreData: Core Data es un framework proporcionado por Apple que permite administrar los datos de nuestra capa de datos. Este framework tiene como ventajas poder agrupar, filtrar y organizar los datos y reducir el espacio de memoria de estos datos gracias al ”faulting”, que permite que cuando realizamos una ”query”, solamente obtenemos la entidad solicitada en vez de todas las entidades relacionadas a la solicitada. 2.3 Recursos hardware En este apartado se describen los dispositivos necesarios para la realizaci´on de este Trabajo de Fin de Grado. Se ha decidido a˜nadir este apartado debido a que, posteriormente, se va realizar una estimaci´on de los costes del proyecto y hemos considerado el conocimiento de los recursos hardware como algo importante para esa estimaci´on. Ordenador de sobremesa Sistema operativo Windows 10 Procesador AMD Ryzen 5 1600 3.2GHz Memoria 12GB DDR4 Disco duro 2TB Tarjeta gr´afica GeForce GTX 1050Ti Tabla 2.1: Descripci´on ordenador de sobremesa MacBook Pro Sistema operativo macOS Mojave 10.14.3 Procesador Intel Core i5 2,5GHz Memoria 16GB DDR3 Disco duro 500GB Tarjeta gr´afica Intel HD Graphics Tabla 2.2: Descripci´on ordenador port´atil 15 Iphone 6 Sistema operativo iOS 12.0 Procesador 1.5 GHz de doble n´ucleo de 64 bits Memoria 2GB LPDDR4 Disco duro 16GB Tarjeta gr´afica PowerVR GT7600 Tabla 2.3: Descripci´on Iphone 6 Iphone 6 Plus Sistema operativo iOS 12.0 Procesador 1.5 GHz de doble n´ucleo de 64 bits Memoria 2GB LPDDR4 Disco duro 32GB Tarjeta gr´afica PowerVR GT7600 Tabla 2.4: Descripci´on Iphone 6 Plus Iphone X Sistema operativo iOS 12.0 Procesador 2.4 GHz de seis n´ucleos de 64 bits Memoria 3GB LPDDR4 Disco duro 64GB Tarjeta gr´afica PowerVR GT7600 Tabla 2.5: Descripci´on Iphone X 2.4 Scrum Scrum es un modelo para el desarrollo de todo tipo de procesos ´agiles. Es una metodolog´ıa ´agil de desarrollo de software que busca flexibilizar el proceso, evitar secuenciaci´on y lograr una estrecha colaboraci´on entre el equipo de desarrollo y el cliente. Sus principios fundamentales son: •Colaboraci´on con el cliente. El cliente est´a muy presente en esta metodolog´ıa debido a que, de esta forma, el producto final ser´a m´as satisfactorio para el mismo porque puede proponer cambios en cualquier momento del desarrollo. 16 •Respuesta al cambio. Debido a que el cliente puede cambiar los requisitos en cualquier momento del desarrollo, debemos estar abiertos y preparados para cualquier cambio. •Desarrollo incremental y entregas funcionales frecuentes. El desarrollo del producto se lleva a cabo en fases peri´odicas y al final de cada fase el producto debe ser funcional. •Supresi´on de artefactos innecesarios en la gesti´on del proyecto para hacer el proceso m´as ´agil al eliminar tares poco ´utiles. •Asignaci´on de un bloque de tiempo y priorizaci´on basada en el valor. Cada tarea en una iteraci´on es priorizada. •Colaboraci´on entre los miembros del equipo y el cliente. 2.4.1 Roles En el desarrollo con esta metodolog´ıa aparecen los siguientes roles: •Product Owner. Su funci´on es definir los objetivos del proyecto y del producto, y planificar y revisar cada Sprint o iteraci´on. •Scrum Master. Es el responsable de apoyar al equipo de desarrollo, eliminar las barreras organizativas y mantener la consistencia del proyecto, haciendo que se cumplan los principios ´agiles. •Team. Grupo de personas que trabajan en el desarrollo del producto de forma conjunta. 2.4.2 Artefactos Los proyectos ´agiles usan tradicionalmente siete artefactos: •Establecimientos de la visi´on del producto. El entorno y los objetivos del producto. •User Story. Es cada uno de los requisitos del proyecto. •Product backlog. Es la lista total de los requisitos del proyecto, ordenados por prioridad. Esta lista puede crecer con cada iteraci´on. •Product roadmap. Es una vista de alto nivel de los requisitos del producto con poca precis´on sobre cuando se desarrollar´an dichos requisitos. •Plan de release. Es un calendario para el lanzamiento de software funcional. •Sprint backlog. Es una lista con las historias de usuario (requisitos) y tareas asociadas con cada iteraci´on. •Incremento. Es la funcionalidad del producto tras cada iteraci´on. 17 2.4.3 Eventos En el desarrollo ´agil existen seis tipos de eventos que se llevan a cabo: •Reuni´on inicial del proyecto. En ella se planifica a grandes rasgos el proyecto. Incluye una visi´on inicial del producto y un product roadmap. •Sprint. Es un ciclo de desarrollo corto con la finalidad de crear funcionalidad. Cada Sprint es una iteraci´on cuya duraci´on es entre una y cuatro semanas. •Sprint Planning. Una reuni´on al comenzar cada Sprint d´onde se fijan los objetivos, funcionalidad a desarrollar, posibles cambios sobre la funcionalidad de Sprints anteriores o solucionar fallos o errores encontrados durante el anterior Sprint. Tambi´en se asigna, entre todo el equipo, un valor a cada User Story que refleja el esfuerzo necesario para realizar esa User Story. •Daily. Reuni´on diaria de entre 5 o 10 minutos, que se realiza de pie, d´onde se indica lo realizado el d´ıa anterior y lo que se va a realizar durante este d´ıa. Tambi´en se pueden compartir los problemas encontrados e intentar buscar una soluci´on con los dem´as miembros del equipo. •Demo o revisi´on del Sprint. Se lleva a cabo al final de cada Sprint y tiene como objetivo mostrar las funcionalidades desarrolladas durante el Sprint y comprobar que ´este se ha cumplido con ´exito. •Retrospectiva. Reuni´on al final de cada Sprint d´onde se analiza lo qu´e funcion´o bien, qu´e se debe cambiar y c´omo llevar a cabo los cambios. 2.5 Modelo, Vista, Controlador El Modelo-Vista-Controlador es un patr´on de arquitectura software que permite separar la l´ogica de negocio de la l´ogica de la vista. Con este patr´on se busca potenciar la facilidad de mantenimiento y reutilizaci´on de c´odigo y la separaci´on de responsabilidades en la aplicaci´on. Se basa fundamentalmente en la separaci´on de estas responsabilidades en tres capas: •Modelo: representa la l´ogica de negocio. •Vista: es la representaci´on de los datos en interfaces. •Controlador: es el intermediario entre el modelo y la vista. Responde a acciones del usuario, modificando el modelo cuando sea necesario. Se comunica con la vista para que se actualice con los ´ultimos cambios del modelo. 18 Figura 2.1: Arquitectura MVC 2.6 Modelo, Vista, Vista de Modelo MVVM (del ingl´es Model - View - View Model) es un patr´on de arquitectura software que, como muchos otros, permite desacoplar la l´ogica de la aplicaci´on de la l´ogica de la vista de la aplicaci´on. Esta divisi´on de responsabilidades tiene el objetivo de simplificar las tareas de desarrollo para posibilitar tener varios desarrolladores trabajando en cada parte de c´odigo, as´ı como una mayor facilidad de reutilizaci´on de c´odigo y de mantenimiento del c´odigo. Figura 2.2: Arquitectura MVVM •Model (Modelo): representa la l´ogica de negocio. Debe ser una estructura de c´odigo 19 sencilla (class o struct) que define las propiedades de un objeto y no tiene funcionalidad. •View Controller (Vista): no debe tener l´ogica, s´olo se encarga de modificar los elementos de la vista seg´un lo que ordene el Modelo de la Vista. Incluye las interfaces. •View Model (Modelo de la Vista): es el intermediario entre el Modelo y la Vista, contiene la l´ogica de presentaci´on. 2.7 Patr´on repositorio Para el acceso a los datos necesarios por la vista de la aplicaci´on usamos el patr´on repositorio. Como definici´on, el patr´on repositorio es una fachada que abstrae el dominio de la persistencia, es decir, es una capa intermedia entre la aplicaci´on y la base de datos. Con este patr´on buscamos tener una estructura desacoplada en la que las acciones que se realizan en cada parte est´en bien definidas y separadas. Este cuenta con tres partes: Repository, APIClient y Network. •Repository: Se encarga de guardar los datos recibidos en base de datos, recuperar los datos necesarios de la base de datos y devolver dichos datos a la Vista del Modelo. •APIClient: Su funci´on es decodificar los datos que devuelve el servidor (JSON) para pasarlos al repositorio en el formato requerido para su almacenamiento. •Network: Su funci´on es lanzar la solicitud al servidor y, con la respuesta de este, recuperar el JSON con los datos solicitados para pasarlo al APIClient. 2.8 Patr´on observador El patr´on observador es un patr´on de dise˜no de software que permite ”observar” cambios en los objetos y notificar los cambios que se producen en los mismos. Cuando un objeto es modificado, se notifica a sus observadores para que realicen una acci´on concreta. Permite desacoplar la vista de la acci´on a realizar. 20 Cap´ıtulo 3 Gesti´on y planificaci´on del proyecto 3.1 Introducci´on El desarrollo de este proyecto se llevar´a a cabo con SCRUM, cuya principal caracter´ıstica es que es una metodolog´ıa ´agil de desarrollo que permite un desarrollo incremental, entre otras cosas. Se ha optado por esta metodolog´ıa debido a que, en el comienzo del proyecto, el alcance del mismo no est´a definido. 3.2 Descripci´on de la metodolog´ıa elegida Scrum es una metodolog´ıa ´agil de desarrollo software (aunque se puede usar en otros ´ambitos). Pese a que es una metodolog´ıa dise˜nada para el trabajo en grupo, se va a usar en este Trabajo de Fin de Grado debido a las ventajas que supone. Estas ventajas son: •Resultados peri´odicos: debido a que en cada sprint vamos a tener que modificar partes de la aplicaci´on, es necesario que podamos ver los resultados en cada sprint review. •Requisitos cambiantes: esto nos ofrece flexibilidad durante el desarrollo. •Contacto entre el equipo de desarrollo y el Product Owner: las reuniones peri´odicas son beneficiosas para mantener este contacto y as´ı el producto ser´a de m´as calidad y siempre adaptado a las pretensiones del cliente. Rol Nombre Product Owner Pablo Carrascal Scrum Master Pablo Carrascal y H´ector Rogel Team H´ector Rogel Tabla 3.1: Descripci´on roles del proyecto 21 3.3 Gesti´on de riesgos En esta secci´on se van a definir los riesgos potenciales que pueden aparecer durante el desarrollo del proyecto. Tambi´en se va a definir un plan de contingencia para cada riesgo para que, en caso de que se produzca el riesgo, tengamos una respuesta al mismo. Los riesgos tienen un identificador, nombre, descripci´on, nivel de impacto, probabilidad de que suceda y un plan de contingencia. El nivel de impacto puede ser de cuatro tipos: •Catastr´ofico: el proyecto fracasar´ıa. •Cr´ıtico: tanto el rendimiento del proyecto como de su desarrollo se ver´ıan seriamente afectados. •Marginal: afecta a problemas secundarios de un proyecto. •Despreciable: problemas menores que no causen un retraso considerable en el proyecto. ID 1 Nombre P´erdida documentos Descripci´on P´erdida de documentos o de c´odigo generado en la implementaci´on debido a fallo el´ectrico o similar. Impacto Cr´ıtico Probabilidad Baja Plan de contingencia Restauraci´on del trabajo de las copias de seguridad en la nube. Tabla 3.2: R01 - P´erdida de documentos ID 2 Nombre Necesidad conocimientos Descripci´on Necesidad de adquirir nuevos conocimientos sobre las tecnolog´ıas utilizadas que ocasione disminuci´on de la productividad y problemas de incorrecci´on en las estimaciones iniciales. Impacto Marginal Probabilidad Alta Plan de contingencia Formaci´on individual en los supuestos conocimientos necesarios. Tabla 3.3: R02 - Necesidad de conocimientos 22 ID 3 Nombre Baja miembro del equipo Descripci´on Alguno de los miembros del equipo est´a de baja Impacto Cr´ıtico Probabilidad Media-baja Plan de contingencia Reorganizar y planificar el proyecto. Tabla 3.4: R03 - Baja miembro del equipo ID 4 Nombre Fallo equipo Descripci´on Fallo de alguno de los equipos necesarios para el desarrollo del proyecto. Impacto Cr´ıtico Probabilidad Media Plan de contingencia Buscar nuevos equipos, ya sean prestados o comprados (como ´ultima opci´on), reorganizar y planificar el proyecto. Tabla 3.5: R04 - Fallo equipo ID 5 Nombre Retraso en sprint Descripci´on El desarrollo sufre alg´un retraso en alguno de sus sprints Impacto Cr´ıtico Probabilidad Alta Plan de contingencia Planificar el siguiente sprint para realizarlo en menos tiempo y as´ı no sufrir retrasos en el proyecto. Tabla 3.6: R05 - Retraso en sprint 23 Figura 4.3: Interfaz de Vacaciones En la pantalla de solicitud de vacaciones podemos solicitar vacaciones eligiendo un rango de fechas. 4.1.2.6 Tabl´on de anuncios En esta secci´on podemos consultar los anuncios de cambio de estado en la solicitud de vacaciones (por ejemplo, de pendiente de aprobaci´on a aprobado). El tabl´on se completa con avisos relacionados con la empresa. 4.1.2.7 Equipo En la secci´on del equipo aparecen los miembros de la empresa, con los datos que ha actualizado cada uno en su perfil: imagen, posici´on en la empresa, mail, tel´efono, twitter y linkedin. Si pulsamos el icono del tel´efono de alg´un compa˜nero (s´olo en caso de estar activo) podemos llamar por tel´efono a dicho compa˜nero. Si pulsamos el icono de twitter (en caso de estar activo) accedemos a su cuenta de twitter en el navegador web del dispositivo, de la misma forma ocurre con el icono de linkedin. 30 4.1.2.8 Empresa En la secci´on de la empresa podemos ver informaci´on relativa a la misma: nombre, tel´efono, p´agina web, direcci´on... 4.1.2.9 Ajustes La secci´on de ajustes nos permite activar o desactivar la opci´on de recibir notificaciones de la aplicaci´on. 4.1.3 Dise˜no de la aplicaci´on existente Hay que destacar que los diagramas de dise˜no de este cap´ıtulo provienen del Trabajo de Fin de Grado ”SGEmployee: Aplicaci´on iOS para la gesti´on de las vacaciones laborales”. cuyo autor es el tutor en empresa de este Trabajo de Fin de Grado. Dichos diagramas se usan con su consentimiento. 31 4.1.3.1 Modelo de dominio Figura 4.4: Modelo de dominio de la aplicaci´on 4.1.3.2 Arquitectura La arquitectura utilizada es la m´as que conocida MVC (modelo, vista controlador) y sigue el esquema que se muestra a continuaci´on. 32 Figura 4.5: Arquitectura MVC de la aplicaci´on existente Para, m´as adelante, hacer la comparaci´on con la nueva arquitectura que vamos a implementar, vamos a describir cu´al es la funcionalidad de cada una de las capas de esta arquitectura. •View y Controller: View es la interfaz, y Controller se encarga de gestionar qu´e elementos y cuando se muestran en la interfaz. Est´an muy acopladas. •Sync: En esta capa se piden datos a la capa Network y se actualizan en la base de datos. Tambi´en se encarga de avisar al Controller de que los datos han sido actualizados. •Network: Se encarga de realizar las peticiones HTTP al servidor y de devolver la respuesta a la capa Sync. 33 •Data: Esta capa est´a compuesta por los ”managers” responsables de las operaciones CRUD de la base de datos. Esta capa constituye el Modelo de este MVC. 4.1.3.3 Descomposici´on modular En esta secci´on podemos ver la descomposici´on modular de la aplicaci´on existente, con las diferentes capas que se han descrito en el apartado anterior. Figura 4.6: Descomposici´on modular de la aplicaci´on existente 34 4.1.4 Interfaz Toda la interfaz de la aplicaci´on se encontraba en un mismo storyboard. Un storyboard es una representaci´on visual de la interfaz de usuario de una aplicaci´on iOS que muestra el contenido de las diferentes pantallas que contiene la aplicaci´on y la conexi´on entre dichas pantallas mediante segues. Un segue define la transici´on entre dos controladores de vista. Esta estructura provocaba, a pesar que no es una aplicaci´on extremadamente grande, que XCode funcionara de forma lenta y dificultaba la correcci´on de bugs o la necesidad de cambio de alguna de las vistas. 4.1.5 Modelo de datos La siguiente figura muestra el esquema relacional de la base de datos interna de la aplicaci´on. Figura 4.7: Esquema relacional de la base de datos 4.1.6 Acceso a datos Para el acceso a los datos necesarios para la aplicaci´on, se usa el patr´on observador. Tambi´en se utiliza CoreData como base de datos de la aplicaci´on. Este patr´on es muy utilizado en toda la aplicaci´on, y no ´unicamente para el acceso a datos, aunque en este Trabajo de Fin de Grado la parte que nos interesa es la del acceso a datos. Dicho patr´on es implementado en la aplicaci´on con la ayuda de la clase de tipo 35 Singleton NSNotificationCenter. Para el almacenamiento de los datos de la aplicaci´on en el dispositivo, se usa Core Data, descrito con anterioridad en el Cap´ıtulo 2. 4.2 An´alisis incremento funcionalidad Para el an´alisis de esta parte de incremento de la funcionalidad, se parte del an´alisis de la otra parte de la aplicaci´on, la ya esxistente. Esto es debido a que el an´alisis es el mismo para ambas partes, por ejemplo, el modelo de dominio va a ser exactamente igual, de la misma forma con el modelo de datos... 4.3 Requisitos del proyecto (Product Backlog) En esta secci´on se van a ir a˜nadiendo las Historias de Usuario (o requisitos del proyecto) que se van a llevar a cabo. La gran mayor´ıa de las que aparecen a continuaci´on se han definido antes de comenzar con el desarrollo del proyecto, pero alguna de ellas se ha a˜nadido durante el desarrollo y otras se han modificado durante el mismo. Esto es posible gracias a la flexibilidad del proceso de desarrollo Scrum. 1. Instalaci´on de recursos. 2. Preparar documentaci´on. 3. Aprender swift. 4. Primera aplicaci´on iOS. 5. Clonaci´on repositorio. 6. Entender arquitectura. 7. Entender Modelo Vista Vista Modelo (MVVM). 8. Cambiar la vista de ”Settings” a MVVM paso por paso. 9. Cambiar la vista de ”Company” a MVVM paso por paso. 10. Cambiar la vista principal a MVVM paso por paso. 11. Cambiar la vista del equipo a MVVM paso por paso. 12. Cambiar la arquitectura de acceso a datos de la secci´on del equipo al patr´on repositorio paso por paso. 13. A˜nadir tests a la secci´on del equipo. 36 14. Rearquitectura secci´on del ”Perfil” de usuario y tests. 15. Rearquitectura de la secci´on de ”Vacaciones” y tests. 16. [BUG] P´erdida de los datos de vacaciones cuando se cambia de a˜no. 17. [BUG] En ocasiones las vacaciones m´aximas no se muestran cuando se accede a la secci´on de Vacaciones. 18. [BUG] Despu´es de a˜nadir una solicitud de vacaciones, las vacaciones del usuario se muestran duplicadas. 19. Actualizar c´odigo a Swift 4.2. 20. Rearquitectura de la secci´on de Avisos. 21. Rearquitectura de la secci´on de Login. 22. [BUG] El a˜no por defecto en la secci´on de Vacaciones debe ser el actual. 23. [BUG] Datos de vacaciones restantes y m´aximas no se recargan en el primer acceso. 24. [BUG] Despu´es de modificar la imagen de perfil, esta no se recarga en la aplicaci´on. 25. Ver solicitudes pendientes en nueva secci´on. 26. Aprobar o rechazar solicitudes de vacaciones. 27. Ver historial de vacaciones del usuario cuando se va a aceptar o rechazar la solicitud. 28. Redise˜no secci´on de Equipo. 29. Ver vacaciones de cada usuario desde la secci´on de Equipo. 37 Cap´ıtulo 5 Dise˜no 5.1 Introducci´on Como ya se ha indicado con anterioridad, este trabajo se divide en dos partes claramente diferenciadas. En primer lugar, el cambio completo de la arquitectura de la aplicaci´on iOS ya existente; y en segundo lugar, el incremento de la funcionalidad de la misma. En ambas partes est´a incluida la realizaci´on de tests autom´aticos. En este cap´ıtulo se va a describir el nuevo dise˜no de la rearquitectura y de la nueva funcionalidad. 5.2 Cambio de la arquitectura 5.2.1 Finalidad Cabe destacar que, de los objetivos expuestos en la secci´on de Objetivos del Cap´ıtulo 1 de este TFG, el m´as importante es la inclusi´on de tests a tres niveles, y que el cambio de arquitectura de la aplicaci´on es necesario para la inclusi´on de estos tests. De la misma manera ocurre con el cambio del acceso a datos. Esto se explicar´a con m´as detalle en las siguientes secciones de este Cap´ıtulo. 5.2.2 Contexto A modo de resumen de la secci´on 4.1 del cap´ıtulo anterior: •La aplicaci´on utilizaba MVC (Modelo Vista Controlador) como patr´on de arquitectura de software. •Toda la interfaz se encontraba en un mismo storyboard, lo que provocaba que XCode funcionara de forma lenta y dificultaba la correcci´on de bugs o la necesidad de cambio de alguna de las vistas. 38 •Para el acceso a los datos necesarios para la aplicaci´on, se usa el patr´on Observador con la ayuda de la clase NotificationCenter. •La aplicaci´on era completamente funcional pero se encontraba en un estado de acoplamiento que hac´ıa muy complicada la tarea de incluir tests en varios niveles, por lo que no ten´ıa ning´un tipo de test. A continuaci´on se van a explicar varios conceptos que van a ser utilizados en la rearquitectura de la aplicaci´on. 5.2.3 Arquitectura La figura 5.1 muestra la nueva arquitectura de la aplicaci´on aplicando MVVM y el patr´on repositorio. Figura 5.1: Nueva arquitectura de la aplicaci´on Model: Esta capa est´a compuesta por la l´ogica de negocio y los ”managers” responsables de las operaciones CRUD de la base de datos. 5.2.4 Descomposici´on modular En esta secci´on podemos ver c´omo ser´a la descomposici´on modular de la aplicaci´on tras la rearquitectura completa. 39 Secci´on de Perfil. Tenemos dos ViewModel debido a que uno es para la interfaz del Perfil y otro para Editar Perfil. Debe recuperar los datos del perfil y enviar nuevos datos para almacenarlos en el servidor. Figura 5.13: Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Perfil Secci´on de Vacaciones. Tenemos tres ViewModel debido a que la interfaz de Vacaciones tiene dos partes (o sub-interfaces): HolidaysVIewModel y YearHolidayViewModel. La tercera clase es para la interfaz de solicitud de Vacaciones. Deben recuperar los datos del n´umero de vacaciones m´aximas, datos de vacaciones y subir nuevas solicitudes al servidor. Figura 5.14: Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Vacaciones 46 Secci´on del Tabl´on de Anuncios. Se encarga de enviar los datos de las ”noticias”, que vienen de su Repositorio, a su ViewController. Figura 5.15: Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Tabl´on de Anuncios ViewModel secci´on Equipo. Se encarga de comunicar a su ViewController los datos de los trabajadores. Figura 5.16: Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Equipo Secci´on de informaci´on de la Empresa. Figura 5.17: Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Empresa 47 Secci´on de Settings. Debe saber cu´ales son las ”settings” iniciales que ha configurado el usuario para comunicar a su ViewController, cu´al es el estado del ”switch” que debe de mostrar y saber cu´al es el estado del ”switch” para comunicarlo a su ViewController. Figura 5.18: Dise˜no detallado rearquitectura, capa ViewModel, secci´on de Settings 5.2.5.3 Dise˜no modular capa Model En la siguiente figura podemos ver el dise˜no detallado de la capa Model. Esta capa no ha cambiado porque ya exist´ıa en la aplicaci´on. A´un as´ı se ha decidido realizar el diagrama para la mejor comprensi´on de esta capa. 48 Figura 5.19: Dise˜no detallado capa Model 49 5.2.5.4 Dise˜no modular capa Repository En la capa Repository tenemos las clases que requieren datos del servidor para almacenarlos y/o extraerlos de la Base de Datos del dispositivo (CoreData). Tambi´en se encuentran aquellas que ´unicamente requieren extraer datos, que de una u otra manera ya est´an almacenados en la Base de Datos, como es el caso de MainMenuRepository. Figura 5.20: Dise˜no detallado rearquitectura, capa Repository 5.2.5.5 Dise˜no modular capa APIClient En la capa APIClient tenemos las clases que requieren de informaci´on del servidor, que tiene que pasar por esta capa para su decodificaci´on. 50 Figura 5.21: Dise˜no detallado rearquitectura, capa APIClient 5.2.5.6 Dise˜no modular capa Network La capa Network tiene una clase general que es usada por las otras cinco para establecer la conexi´on con la librer´ıa Alamofire. Las clases restantes corresponden a las secciones de la aplicaci´on que requieren de datos del servidor. En estas se realizan las peticiones al servidor. 51 Figura 5.22: Dise˜no detallado rearquitectura, capa Network 5.3 Dise˜no incremento funcionalidad 5.3.1 Arquitectura general La arquitectura que se va a usar para el incremento de la nueva funcionalidad es la misma que se ha ultilizado al realizar la rearquitectura de la aplicaci´on existente. Es decir, utilizando los patrones MVVM y repositorio de la misma forma que se ha descrito en la Figura 5.1. 5.3.2 Descomposici´on modular En esta secci´on no se va a representar la descomposici´on modular de toda la aplicaci´on ya que ser´ıa repetitivo porque gran parte ya est´a descrito en la Figura 5.2. Se va a representar la descomposici´on modular de los nuevos elementos que son necesarios para esta nueva 52 funcionalidad, obviando aquellos ya descritos en la secci´on anterior. Las clases que aparecen son aquellas que han aparecido con las nuevas funcionalidades implementadas. En el caso de la la capa Model, no se ha a˜nadido ninguna clase. Figura 5.23: Descomposici´on modular del incremento de la funcionalidad 5.3.3 Dise˜no modular de cada capa En este apartado ´unicamente vamos a mostrar las clases de cada capa que aparecen nuevas o han sido modificadas. Al aparecer una nueva secci´on de Administraci´on, tambi´en son necesarias sus respectivas clases en cada capa para cumplir la arquitectura deseada. Al modificar la secci´on de Equipo, tambi´en se modifican sus clases de cada capa y aparecen nuevas (con la nueva interfaz). 53 5.3.3.1 Dise˜no modular capa ViewController ViewController secci´on Administraci´on. Para la interfaz de administraci´on, se comunica las vacaciones de todos los empleados y las opciones de estado de cada solicitud. Para el detalle de una solicitud pendiente (RequestDetail) comunica los datos a mostrar de la solicitud y getiona las acciones de aceptar o rechazar la solicitud, decisi´on que comunica a su respectivo ViewModel. Figura 5.24: Dise˜no detallado capa ViewController, nueva secci´on de Administraci´on ViewController Equipo. En la clase TeamViewController aparece la responsabilidad de mostrar el n´umero de trabajadores activos y mostrar las nuevas opciones al pulsar sobre un empleado. En el otro ViewController comunica los datos a mostrar en la vista: d´ıas m´aximos, historial de vacaciones, imagen del usuario... 54 Figura 5.25: Dise˜no detallado capa ViewController, nueva secci´on de Equipo 5.3.3.2 Dise˜no modular capa ViewModel En el siguiente diagrama podemos ver el dise˜no detallado de la capa ViewModel para la nueva secci´on de administraci´on. En ´el podemos ver dos ViewModel: uno es para la pantalla principal de administraci´on y el otro para el detalle de una solicitud. Se encargan de enviar los datos necesarios al ViewController: vacaciones, vacaciones m´aximas, usuario, mandar nuevo estado de una solicitud al Repositorio para su posterior guardado en el servidor... 55 Figura 5.34: Relaci´on entre capas US28 - Redise˜no secci´on de Equipo 5.3.4.5 US29 - Ver vacaciones de cada usuario desde la secci´on de Equipo En la siguiente figura podemos ver la relaci´on entre las diferentes capas para la Historia de Usuario Historial vacaciones en Equipo. 62 Figura 5.35: Relaci´on entre capas US28 - Historial vacaciones en Equipo 5.3.5 Dise˜no de la interfaz Para cada Historia de Usuario, se dise˜na un prototipo de interfaz que se utilizar´a a la hora de implementar dicha interfaz. 5.3.5.1 US25 - Ver solicitudes Para esta Historia de Usuario, se ha dise˜nando el prototipo que se muestra a continuaci´on. Aparecer´an las solicitudes de vacaciones de todos los usuarios de la forma en que se ha representado en el prototipo. En esta Historia de Usuario la interfaz es ´unicamente para consulta, no requiere ninguna interacci´on con el usuario. 63 Figura 5.36: P01 - Prototipo interfaz US25 Ver solicitudes 5.3.5.2 US26 - Gesti´on de vacaciones En el siguiente prototipo, al deslizar sobre la celda hacia la izquierda en una solicitud de Vacaciones con estado pendiente, aparecer´an en la parte derecha de la celda dos opciones: aceptar y rechazar. Si la solicitud de vacaciones de la celda est´a en estado aprobado, al deslizar hacia la derecha sobre ella aparecer´a la opci´on de cambiar el estado a pendiente. Figura 5.37: P02 - Prototipo interfaz US26 Gesti´on de Vacaciones 64 5.3.5.3 US27 - Historial usuario solicitud Para esta Historia de Usuario, si se pulsa sobre una solucitud pendiente en la pantalla de Administraci´on, aparecer´a el siguiente prototipo. Se muestra el detalle de la solicitud pendiente pulsada, as´ı como el resto de solicitudes del usuario en cuesti´on para el a˜no en curso. Hay dos botones para aceptar o rechazar la solicitud. En la parte superior izquierda hay un bot´on de cancelar para volver a la pantalla anterior. Figura 5.38: P03 - Prototipo interfaz US27 Historial usuario solicitud 5.3.5.4 US28 - Redise˜no secci´on de Equipo Para este redise˜no de la interfaz se ha optado por el prototipo que se muestra a continuaci´on. Aparecer´an todos los trabajadores con su imagen de perfil, su posici´on en la empresa y su email. Adem´as tendr´an una banda de color verde o roja en la parte izquierda de la celda para distinguir aquellos trabajadores activos en la empresa de los que no lo son. En la parte inferior vemos el n´umero de trabajadores totales y aquellos que est´an activos. 65 Figura 5.39: P04 - Prototipo interfaz US28 Redise˜no secci´on de Equipo El siguiente men´u de opciones aparecer´a al tocar sobre cualquier celda de trabajador de la interfaz anterior. Si el usuario identificado en la aplicaci´on es Administrador, aparecer´a la opci´on de las vacaciones. El resto de opciones aparecer´an para todos los usuarios independientemente del rol que tengan. Figura 5.40: P05 - Prototipo interfaz US28 Redise˜no secci´on de Equipo bis 66 5.3.5.5 US29 - Ver historial en secci´on de vacaciones El administrador tendr´a acceso a la siguiente interfaz de consulta de vacaciones del trabajador seleccionado. En ella se podr´a ver la foto del trabajador en cuesti´on junto con su nombre y posici´on. Tambi´en se podr´a navegar entre los diferentes a˜nos para ver las solicitudes de vacaciones y los d´ıas de vacaciones m´aximos en cada a˜no. Figura 5.41: P06 - Prototipo interfaz US29 Ver historial en secci´on de vacaciones 5.3.6 Sprints En esta secci´on se va a realizar un an´alisis exhaustivo de todos los Sprints del proyecto. Para cada sprint se describen las historias de usuario realizadas en cada uno de ellos con gran detalle: •Estimaci´on del esfuerzo necesario para llevar a cabo cada Historia de Usuario. •Criterios de aceptaci´on de la Historia de Usuario. •Desglose detallado de las tareas para cada una de las Historias. •Incremento del Sprint, d´onde se describe las caracter´ısticas a˜nadidas al producto (basadas en las Historias de Usuario) y los problemas encontrados. 67 Esta secci´on tiene mucha importancia debido a que muestra con mayor precisi´on y detalle el trabajo desarrollado en este Trabajo de Fin de Grado de forma peri´odica, y los problemas que han podido surgir durante el mismo. 5.3.6.1 Sprint 0 Fecha de inicio: 11/02/2019 Fecha de fin: 17/02/2019 Sprint backlog: Historia de Usuario Nombre: Instalaci´on de recursos ID: 1Usuario: Desarrollador Estimaci´on: 2 Descripci´on: Como Desarrollador quiero tener instalados todas las herramientas y tecnolog´ıas necesarias para la realizaci´on del proyecto. Criterios de Aceptaci´on: - XCode (versi´on 10.1) instalado. - Simulator (versi´on 10.1) instalado. - Jira software configurado para comenzar con su uso. - Git instalado. - Gitlab configurado y preparado para usar. - Swift (versi´on 4.2) instalado. Tabla 5.1: US01 - Instalaci´on de recursos Estimaci´on: Se ha decidido estimar esta historia con un 2 ya que s´olo implica instalaciones. Podr´ıa haber sido estimada con un 1 pero no se ha hecho debido a que puede haber alguna complicaci´on durnate la instalaci´on, como por ejemplo incompatibilidades en el software. Tareas: •Instalar XCode y Simulator •Crear cuenta en Jira software y configurarla para su uso inmediato •Instalar git •Crear cuenta en Gitlab y configurarla para su uso •Instalar Swift 68 Historia de Usuario Nombre: Preparar documentaci´on. ID: 2Usuario: Desarrollador Estimaci´on: 5 Descripci´on: Como Desarrollador quiero tener configuradas y disponibles todas las herramientas de redacci´on de la documentaci´on de este proyecto para poder completar dicha documentaci´on durante el desarrollo del mismo. Criterios de Aceptaci´on: - OverLeaf configurado y listo para su uso. - Conocer los conceptos b´ascicos de LaTeX. - La introducci´on de la documentaci´on debe estar realizada. - El entorno tecnol´ogico del proyecto debe estar redactado en la documentaci´on. Tabla 5.2: US02 - Preparar documentaci´on Estimaci´on: Se ha estimado con un 5 debido al desconocimiento de la tecnolog´ıa La- TeX. Tareas: •Crear cuenta en OverLeaf •Estudiar tutorial b´asico de LaTeX •Redactar la introducci´on del Trabajo de Fin de Grado as´ı como el entorno tecnol´ogico que se va a usar para la realizaci´on del mismo. Incremento Sprint: Todas las instalaciones han sido completadas con ´exito. Se ha comenzado con la redacci´on de la documentaci´on. A partir del siguiente Sprint las tareas de redacci´on de la documentaci´on va a estar impl´ıcito dentro del mismo sin la necesidad de incluirlas en el mismo. Como excepci´on, s´olo se incluir´an tareas de documentaci´on en el caso de que el sprint tenga ´unicamente historias de usuario de redacci´on de documentaci´on. 5.3.6.2 Sprint 1 Fecha de inicio: 18/02/2019 Fecha de fin: 24/02/2019 Sprint backlog: 69 Historia de Usuario Nombre: Aprender swift ID: 3Usuario: Desarrollador Estimaci´on: 5 Descripci´on: Como Desarrollador quiero ser capaz de dominar los aspectos b´asicos del lenguaje swift para poder programar aplicaciones iOS. Criterios de Aceptaci´on: - Dominar la mayor´ıa de estructuras de datos y tipos de swift. - Controlar las estructuras de control del lenguaje. Tabla 5.3: US03 - Aprender Swift Estimaci´on: Se ha estimado con un 5 debido a que es el primer contacto con Swift. Tareas: •Estudiar tutoriales de sintaxis b´asica de swift. •Estudiar tutoriales de tipos de datos, variables, opcionales ... •Estudiar tutoriales de estructuras de control, funciones, extensiones ... Historia de Usuario Nombre: Primera aplicaci´on iOS ID: 4Usuario: Desarrollador Estimaci´on: 5 Descripci´on: Como Desarrollador quiero ser capaz de escribir una aplicaci´on iOS b´asica. Criterios de Aceptaci´on: - Construir una aplicaci´on con un bot´on que realice alguna acci´on al ser pulsado. - La aplicaci´on construida debe seguir la arquitectura Modelo Vista Controlador. Tabla 5.4: US04 - Primera aplicaci´on iOS Estimaci´on: Se ha estimado con un 5 debido a que es la primera aplicaci´on iOS y requiere aprendizaje. Tareas: •Aprender c´omo funcionan los ViewController y los Storyboards en desarrollo iOS •Estudiar tutoriales de c´omo se aplica la arquitectura MVC en iOS. •Construir una aplicaci´on simple aplicando el modelo MVC. 70 Incremento sprint: Se han completado una cantidad considerable de tutoriales y se ha realizado una aplicaci´on con la arquitectura MVC y que est´a compuesto por una pantalla con un bot´on que al ser pulsado muestra una imagen. 5.3.6.3 Sprint 2 Fecha de inicio: 25/02/2019 Fecha de fin: 03/03/2019 Sprint backlog: Historia de Usuario Nombre: Clonaci´on repositorio ID: 5Usuario: Desarrollador Estimaci´on: 1 Descripci´on: Como Desarrollador quiero clonar el repositorio existente a mi m´aquina para poder desarrollar el proyecto. Criterios de Aceptaci´on: - Clonar el c´odigo swift de la aplicaci´on existente. - Clonar y configurar el backend ya existente. - Clonar y configurar el frontend ya existente. Tabla 5.5: US05 - Clonaci´on repositorio Estimaci´on: Se ha estimado con un 1 debido a que es una tarea sencilla. Tareas: •Clonar de Gitlab el c´odigo de la aplicaci´on existente. •Descargar las librer´ıas del proyecto y abrirlo con XCode. •Clonar de Gitlab el backend y configurarlo para su uso. •Clonar de Gitlab el frontend y configurarlo para su uso. Historia de Usuario Nombre: Entender arquitectura ID: 6Usuario: Desarrollador Estimaci´on: 8 Descripci´on: Como Desarrollador quiero entender la arquitectura de la aplicaci´on. Criterios de Aceptaci´on: - Comprender el funcionamiento de interfaz de la aplicaci´on. - Comprender la arquitectura interna de la aplicaci´on. Tabla 5.6: US06 - Entender arquitectura 71 5.3.6.10 Sprint 9 Fecha de inicio: 22/04/2019 Fecha de fin: 05/05/2019 Sprint backlog: Historia de Usuario Nombre: Rearquitectura secci´on de Vacaciones y tests ID: 15 Usuario: Desarrollador Estimaci´on: 13 Descripci´on: Como Desarrollador quiero cambiar la arquitectura de la secci´on Vacaciones y aplicar tests en tres niveles. Criterios de Aceptaci´on: - La secci´on de Vacaciones sigue funcionando correctamente despu´es del cambio a MVVM. - La secci´on de Vacaciones sigue funcionando correctamente despu´es del cambio al patr´on repositorio. - Tests de interfaz de usuario, unitarios y de red. Tabla 5.15: US15 - Rearquitectura secci´on de Vacaciones y tests Estimaci´on: Se ha estimado con un 13 debido a que esta historia de usuario se compone de lo realizado en los tres sprints anteriores (para una secci´on diferente). Tareas: •Cambiar la interfaz de la Storyboard a un archivo xib. •Cambiar la arquitectura de la secci´on (de MVC a MVVM). •Cambiar el acceso a datos a patr´on repositorio. •Realizar tests de interfaz de usuario. •Realizar tests unitarios. •Realizar tests de red. Incremento sprint: Se ha cambiado la secci´on de vacaciones a la arquitectura MVVM y al patr´on repositorio y se han realizado tests en tres niveles para esta secci´on. Este sprint tambi´en ha tenido retraso debido a la dificultad, por lo que tambi´en se ha ampliado a dos semanas. 78 5.3.6.11 Sprint 10 Fecha de inicio: 06/05/2019 Fecha de fin: 12/05/2019 Sprint backlog: Bug Nombre: P´erdida de los datos de vacaciones cuando se cambia de a˜no. ID: 16 Usuario: Desarrollador Descripci´on: En la secci´on de vacaciones, cuando se cambia de un a˜no a otro, los datos de las vacaciones se ponen en valor nulo y provoca que la aplicaci´on se cierre de forma inesperada. Tabla 5.16: BUG - P´erdida de los datos de vacaciones cuando se cambia de a˜no Bug Nombre: En ocasiones las vacaciones m´aximas no se muestran cuando se accede a la secci´on de Vacaciones. ID: 17 Usuario: Desarrollador Descripci´on: Al acceder a la secci´on de vacaciones, el n´umero de d´ıas m´aximo de vacaciones no se muestra siempre Tabla 5.17: BUG - En ocasiones las vacaciones m´aximas no se muestran cuando se accede a la secci´on de Vacaciones Bug Nombre: Despu´es de a˜nadir una solicitud de vacaciones, las vacaciones del usuario se muestran duplicadas. ID: 18 Usuario: Desarrollador Descripci´on: Despu´es de realizar una solicitud de vacaciones, cuando visualizamos nuestras vacaciones, estas se muestran duplicadas. Tabla 5.18: BUG - Despu´es de a˜nadir una solicitud de vacaciones, las vacaciones del usuario se muestran duplicadas 79 Historia de Usuario Nombre: Actualizar c´odigo a swift 4.2. ID: 19 Usuario: Desarrollador Estimaci´on: 3 Descripci´on: Como Desarrollador quiero actualizar el c´odigo a swift 4.2. Criterios de Aceptaci´on: - La aplicaci´on completa compila en swift 4.2 y su funcionalidad es la misma que antes del cambio. Tabla 5.19: US19 - Actualizar c´odigo a swift 4.2 Estimaci´on: Se ha estimado con un 3 debido a que, pese a que deber´ıa ser una tarea sencilla, puede tener incompatibilidades que retrasen la tarea. Tareas: •Actualizar las versiones de las librer´ıas de terceros utilizadas. •Actualizar el c´odigo a swift 4. •Actualizar a swift 4.2. Historia de Usuario Nombre: Rearquitectura secci´on de Avisos y tests. ID: 20 Usuario: Desarrollador Estimaci´on: 1 Descripci´on: Como Desarrollador quiero cambiar la arquitectura de la secci´on de Avisos. Criterios de Aceptaci´on: - La secci´on de Avisos sigue funcionando correctamente despu´es del cambio a MVVM. - La secci´on de Avisos sigue funcionando correctamente despu´es del cambio al patr´on repositorio. - Tests de interfaz de usuario, unitarios y de red. Tabla 5.20: US20 - Rearquitectura secci´on de Avisos y tests Estimaci´on: Se ha estimado con un 1 debido a que es una tarea sencilla. Tareas: •Cambiar la interfaz de la Storyboard a un archivo xib. •Cambiar la arquitectura de la secci´on (de MVC a MVVM). •Cambiar el acceso a datos a patr´on repositorio. •Realizar tests de interfaz de usuario. 80 •Realizar tests unitarios. •Realizar tests de red. Historia de Usuario Nombre: Rearquitectura secci´on de Login y tests. ID: 21 Usuario: Desarrollador Estimaci´on: 3 Descripci´on: Como Desarrollador quiero cambiar la arquitectura de la secci´on de Login. Criterios de Aceptaci´on: - La secci´on de Login sigue funcionando correctamente despu´es del cambio a MVVM. - La secci´on de Login sigue funcionando correctamente despu´es del cambio al patr´on repositorio. - Tests de interfaz de usuario, unitarios y de red. Tabla 5.21: US21 - Rearquitectura secci´on de Login y tests Estimaci´on: Se ha estimado con un 1 debido a que es una tarea de dificultad media - baja. Tareas: •Cambiar la interfaz de la Storyboard a un archivo xib. •Cambiar la arquitectura de la secci´on (de MVC a MVVM). •Cambiar el acceso a datos a patr´on repositorio. •Realizar tests de interfaz de usuario. •Realizar tests unitarios •Realizar tests de red Bug Nombre: El a˜no por defecto en la secci´on de vacaciones debe ser el actual. ID: 22 Usuario: Desarrollador Descripci´on: Cuando se accede a la secci´on de vacaciones, la pesta˜na por defecto para las vacaciones es 2018 y deber´ıa de mostrarse 2019 (el a˜no actual). Tabla 5.22: BUG - El a˜no por defecto en la secci´on de vacaciones debe ser el actual 81 Bug Nombre: Datos de vacaciones restantes y m´aximas no se recargan en el primer acceso. ID: 23 Usuario: Desarrollador Descripci´on: Cuando se inicia la aplicaci´on, la primera vez que se accede a la secci´on de vacaciones, no se cargan el n´umero de dias de vacaciones m´aximas y restantes. Tabla 5.23: BUG - Datos de vacaciones restantes y m´aximas no se recargan en el primer acceso Bug Nombre: Despu´es de modificar la imagen de perfil, esta no se recarga en la aplicaci´on. ID: 24 Usuario: Desarrollador Descripci´on: Cuando se accede a la secci´on de perfil y se cambia la imagen del usuario, esta nueva imagen no se recarga en el resto de la aplicaci´on. Tabla 5.24: BUG - Despu´es de modificar la imagen de perfil, esta no se recarga en la aplicaci´on Incremento sprint: Se han resuelto todos los bugs con ´exito, rearquitectura de las secciones de avisos y login con ´exito, as´ı como sus respectivos tests. El c´odigo de la aplicaci´on est´a en la versi´on 4.2 de swift y no se puede pasar a swift 5, debido a incompatibilidades con librer´ıas de terceros. 5.3.6.12 Sprint 11 Fecha de inicio: 03/06/2019 Fecha de fin: 09/06/2019 Sprint backlog: Historia de Usuario Nombre: Ver solicitudes pendientes en nueva secci´on. ID: 25 Usuario: Administrador Estimaci´on: 8 Descripci´on: Como Administrador quiero ver las solicitudes de vacaciones pendientes en una nueva secci´on. Criterios de Aceptaci´on: - La nueva secci´on de administraci´on s´olo aparece si el usuario es administrador. - S´olo aparecen las solicitudes de vacaciones pendientes. - Tests de interfaz de usuario, unitarios y de red. Tabla 5.25: US25 - Ver solicitudes pendientes en nueva secci´on 82 Estimaci´on: Se ha estimado con un 8 debido a que esta historia de usuario supone cambiar el funcionamiento interno de la aplicaci´on para a˜nadir tipos de usuarios y la nueva secci´on, a parte de la fase de dise˜no de esta secci´on. Tareas: •Hacer un prototipo de la nueva interfaz. •Cambiar el modelo para que los usuarios tengan un atributo rol. •Crear nueva secci´on en el men´u lateral. •La nueva secci´on aparece en funci´on del rol del usuario identificado. •Implementar la interfaz de la nueva secci´on. •Obtener todos los datos necesarios del servidor usando el patr´on repositorio. •Mostrar los datos en la interfaz usando MVVM. •Realizar tests de interfaz de usuario. •Realizar tests unitarios. •Realizar tests de red. Incremento sprint: S´olo los usuarios administradores pueden acceder a la nueva secci´on para consultar las solicitudes, aquellos que no tienen rol de administrador no pueden ver esta secci´on. Al acceder a la nueva secci´on, aparecen las solicitudes de vacaciones pendientes (no aparecen las aceptadas o rechazadas). 5.3.6.13 Sprint 12 Fecha de inicio: 10/06/2019 Fecha de fin: 16/06/2019 Sprint backlog: 83 Historia de Usuario Nombre: Aprobar o rechazar solicitudes de vacaciones. ID: 26 Usuario: Administrador Estimaci´on: 8 Descripci´on: Como Administrador quiero aprobar o rechazar las solicitudes de vacaciones pendientes. Criterios de Aceptaci´on: - El administrador deslizar´a sobre una solicitud hacia la izquierda para aceptar o rechazar. - El administrador deslizar´a sobre una solicitud, con estado de aceptada, hacia la derecha para cambiar el estado a pendiente. - Las solicitudes con estado cancelado no pueden volver a cambiar de estado. Tabla 5.26: US26 - Aprobar o rechazar solicitudes de vacaciones Estimaci´on: Se ha estimado con un 5 debido a que esta historia de usuario supone cambiar la interfaz del sprint anterior y a˜nadir el ”deslizamiento” en cada solicitud. Tareas: •Hacer un prototipo de la nueva interfaz. •Cambiar la interfaz de la secci´on para a˜nadir el deslizamiento. •Actualizar el cambio de estado en el servidor al aceptar o rechazar una solicitud. •Realizar tests de interfaz de usuario. •Realizar tests unitarios. •Realizar tests de red. Incremento sprint: La interfaz ha sido modificada para cumplir los nuevos requisitos. Al deslizar hacia la izquierda o la derecha en una solicitud, aparecen en la celda unas opciones: aceptar, rechazar o pasar a pendiente, seg´un el estado de la solicitud. Ese cambio de estado se guarda en el servidor y se actualiza la interfaz con el cambio. 5.3.6.14 Sprint 13 Fecha de inicio: 17/06/2019 Fecha de fin: 23/06/2019 Sprint backlog: 84 Historia de Usuario Nombre: Ver historial de vacaciones del usuario cuando se va a aceptar o rechazar la solicitud. ID: 27 Usuario: Administrador Estimaci´on: 8 Descripci´on: Como Administrador quiero ver el historial de vacaciones del usuario mientras acepto o rechazo una solicitud. Criterios de Aceptaci´on: - El administrador acceder´a a un detalle de la solicitud al pulsar sobre la misma. - El administrador ver´a todas la solicitudes acpetadas o rechazadas mientras que acepta la misma. - Aparecer´an el n´umero de d´ıas de vacaciones restantes para ese trabajador. Tabla 5.27: US27 - Ver historial de vacaciones del usuario cuando se va a aceptar o rechazar la solicitud Estimaci´on: Se ha estimado con un 8 debido a que esta historia de usuario supone a˜nadir una nueva interfaz y nueva funcionalidad. Tareas: •Hacer que las celdas de la interfaz admitan interacci´on con el usuario, crear estructura para nueva interfaz. •Hacer un prototipo de la nueva interfaz. •Implementar nueva interfaz. •Obtener datos del servidor usando el patr´on Repositorio •Mostrar los datos en la interfaz usando MVVM •Realizar tests de interfaz de usuario. •Realizar tests unitarios. •Realizar tests de red. Incremento sprint: La interfaz ha sido modificada para cumplir los nuevos requisitos. Al presionar sobre una celda ”pendiente” aparece una nueva interfaz con el detalle de la solicitud y una lista con el resto de solicitudes del trabajador en cuesti´on. Tambi´en aparecen el n´umero de d´ıas de vacaciones restantes y dos botones para aceptar o rechazar. 85 5.3.6.15 Sprint 14 Fecha de inicio: 24/06/2019 Fecha de fin: 30/06/2019 Sprint backlog: Historia de Usuario Nombre: Redise˜no secci´on de Equipo. ID: 28 Usuario: Desarrollador Estimaci´on: 3 Descripci´on: Como Desarrollador quiero implementar un nuevo dise˜no de la secci´on Equipo de acuerdo a un prototipo de este nuevo dise˜no. Criterios de Aceptaci´on: - La nueva interfaz cumple los criterios del prototipo. - La nueva interfaz mantiene la funcionalidad anterior al cambio. Tabla 5.28: US28 - Redise˜no secci´on de Equipo Estimaci´on: Se ha estimado con un 3 debido a que esta historia de usuario es sencilla y ´unicamente requiere cambiar la interfaz y mantener la funcionalidad. Tareas: •Hacer un prototipo de la nueva interfaz. •Implementar nueva interfaz. •Asegurarse de que la funcionalidad se mantiene. Historia de Usuario Nombre: Ver vacaciones de cada usuario desde la secci´on de Equipo. ID: 29 Usuario: Administrador Estimaci´on: 8 Descripci´on: Como Administrador quiero, desde la secci´on de Equipo, consultar el historial de vacaciones de cada trabajador. Criterios de Aceptaci´on: - La nueva interfaz cumple los criterios del prototipo. - Implementar nueva interfaz. - Obtener datos del servidor usando el patr´on Repositorio. Tabla 5.29: US29 - Ver vacaciones de cada usuario desde la secci´on de Equipo Estimaci´on: Se ha estimado con un 8 debido a que esta historia de usuario requiere crear una nueva interfaz y una nueva funcionalidad. 86 Tareas: •Hacer un prototipo de la nueva interfaz. •Implementar nueva interfaz. •Mostrar los datos en la interfaz usando MVVM •Realizar tests de interfaz de usuario. •Realizar tests unitarios. •Realizar tests de red. Incremento sprint: Se ha lleva a cabo el redise˜no sin ning´un problema. La nueva interfaz permite consultar el historial de vacaciones de todos los trabajadores de la empresa, incluso aquellos que no est´an activos en la empresa. 87 del servidor). De esta forma somos capaces de generar una respuesta para cada uno de los c´odigos de error del servidor que queramos. Esto permite comprobar que el comportamiento de nuestro c´odigo es el deseado para el caso de ´exito y cada uno de los mensajes y c´odigos de error que devuelve el servidor cuando algo falla. Es muy importante que el flujo de ejecuci´on de nuestra aplicaci´on no se vea interrumpido por una respuesta de error del servidor no esperada. 6.3.5 Librer´ıas necesarias En este apartado se van a describir las librer´ıas requeridas para la realizaci´on de los tests descritos anteriormente. Hay que remarcar que estos tests se pueden realizar con otras librer´ıas pero estas son las elegidas para la realizaci´on de este Trabajo de Fin de Grado debido a la calidad de la documentaci´on y a la facilidad de suso de las mismas. •XCTest: Framework de Apple que permite la realizaci´on de tests autom´aticos. En este Trabajo de Fin de Grado se va a usar para los tests unitarios, de red y para los tests de Interfaz de usuario, como veremos a continuaci´on. •KIF: Es un framework que, junto con XCTest, ayuda en la creaci´on de tests de Interfaz de Usuario autom´aticos ya que permite simular el flujo completo de la interfaz. Permite itroducir credenciales, tocar sobre una parte de la pantalla, identificar los elementos de la interfaz deslizar sobre la pantalla para que aparezcan las opciones de una celda (swipe)... y todo esto automatizado. •Hippolyte: esta librer´ıa nos permite crear el ”stub” para, con la ayuda de XCTest realizar los tests de red. 6.3.6 Tests autom´aticos realizados Los tests realizados en este Trabajo de Fin de Grado, se han realizado para cada secci´on de la aplicaci´on y en los tres niveles descritos anteriormente (unitarios, de interfaz y de red). ´ Unicamente se van a reflejar un par de tests por secci´on y tipo para no sobrecargar la secci´on con la especificaci´on de tests que pueden llegar a ser repetitivos para el lector debido al gran parecido entre ellos. Para los tests de Red (o Network) se van a describir todos los tests realizados pero solamente en una de las secciones debido a que estos tests son siempre los mismos para cada secci´on y para cada una de las conexiones con la base de datos de las secciones. La ´unica diferencia entre unos tests de red y otros son la construcci´on del ”stub” que depende de la solicitud. 94 6.3.6.1 Perfil UI tests: Estos tests de interfaz de usuario se dividen en dos partes ya que esta secci´on se compone de dos interfaces diferentes: la interfaz del perfil y la de editar en perfil. Nombre: testProfileViewWithAllTheFields ID: 1Escenario: Perfil Descripci´on: Comprobar que todos lo elementos de la interfaz se muestran en la misma. Resultados esperados: Todos los elementos de la vista mostrados en la interfaz. Resultados obtenidos: Todos los elementos son detectados. Resultado prueba: ´ Exito Tabla 6.1: T01 - UI test Perfil Nombre: testHeaderEditProfileViewWithAllTheFields ID: 2Escenario: Editar perfil Descripci´on: Comprobar que los elementos de la celda se muestran en la interfaz Resultados esperados: Todos los elementos de la celda mostrados en la interfaz. Resultados obtenidos: Todos los elementos son detectados. Resultado prueba: ´ Exito Tabla 6.2: T02 - UI test Editar Perfil Unit tests: Nombre: testGetUserShouldReturnOneUser ID: 3Escenario: Perfil y editar perfil Descripci´on: Comprobar que la funcionalidad ”getUser” devuelve un usuario pasando como argumento un JSON dado (equivalente a la respuesta del servidor). Resultados esperados: N´umero de usuarios igual a 2 Resultados obtenidos: N´umero de usuarios igual a 2 Resultado prueba: ´ Exito Tabla 6.3: T03 - Unit test Perfil 01 95 Nombre: testSetUserShouldReturnNameProperty ID: 4Escenario: Perfil Descripci´on: Comprobar que la funcionalidad ”setUser” devuelve el valor de la propiedad ”Nombre” esperado. Resultados esperados: ”nombre” = ”H´ector” Resultados obtenidos: ”nombre” = ”H´ector” Resultado prueba: ´ Exito Tabla 6.4: T04 - Unit test Perfil 02 Network tests: Nombre: testShouldReturnOkWhenGetUserHTTPCodeReturnIsSuccess ID: 5Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 200. Resultados esperados: La solicitud se realiza sin errores de red, simulando un c´odigo 200. Resultados obtenidos: La solicitud se realiza sin errores de red. Resultado prueba: ´ Exito Tabla 6.5: T05 - Network test 200 Nombre: testShouldReturnFailWhenGetUserHTTPCodeReturnInvalidRequestCode ID: 6Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 400. Resultados esperados: InvalidRequestCode Resultados obtenidos: InvalidRequestCode Resultado prueba: Fracaso Tabla 6.6: T06 - Network test 400 Nombre: testShouldReturnFailWhenGetUserHTTPCodeReturnInvalidCredentials ID: 7Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 401. Resultados esperados: InvalidCredentials Resultados obtenidos: InvalidCredentials Resultado prueba: Fracaso Tabla 6.7: T07 - Network test 401 96 Nombre: testShouldReturnFailWhenGetUserHTTPCodeReturnPropertyAlreadySet ID: 8Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 403. Resultados esperados: PropertyAlreadySet Resultados obtenidos: PropertyAlreadySet Resultado prueba: Fracaso Tabla 6.8: T08 - Network test 403 Nombre: testShouldReturnFailWhenGetUserHTTPCodeReturnNotFound ID: 9Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 404. Resultados esperados: NotFound Resultados obtenidos: NotFound Resultado prueba: Fracaso Tabla 6.9: T09 - Network test 404 Nombre: testShouldReturnFailWhenGetUserHTTPCodeReturnServerError ID: 10 Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 500. Resultados esperados: ServerError Resultados obtenidos: ServerError Resultado prueba: Fracaso Tabla 6.10: T10 - Network test 500 Nombre: testShouldReturnFailWhenGetUserHTTPCodeReturnUnknowmError ID: 11 Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error 9999999. Resultados esperados: UnknowmError Resultados obtenidos: UnknowmError Resultado prueba: Fracaso Tabla 6.11: T11 - Network test 9999999 97 Nombre: testShouldReturnFailWhenGetUserNotConnectedWithServer ID: 12 Escenario: Perfil Descripci´on: Comprobar que la respuesta de nuestra API de red es la esperada simulando que el servidor devuelve un c´odigo de error -1009. Resultados esperados: NotConnectedWithServer Resultados obtenidos: NotConnectedWithServer Resultado prueba: Fracaso Tabla 6.12: T12 - Network test -1009 La primera vez que se llevaron a cabo estos tests de Red, todos fracasaron excepto el primero, con c´odigo 200. Esto permiti´o descubrir que se estaba haciendo mal la gesti´on de los errores devueltos por parte del servidor. Este problema ha sido solucionado y estos tests no han vuelto a fallar para ninguna otra funcionalidad que requiera una petici´on al servidor. Estos tests han permitido descubir un problema en el c´odigo de la aplicaci´on antes de lanzarse a un entorno ”real” que, en determinadas situaciones, habr´ıa supuesto un cierre inesperado de la aplicaci´on. Esto es lo que se quiere evitar con estos tests autom´aticos, c´omo se ha descrito con anterioridad. 6.3.6.2 Vacaciones UI tests: Nombre: testTotalDaysEqualToExpected ID: 13 Escenario: Vacaciones Descripci´on: Comprobar que los d´ıas de vacaciones totales son los esperados. Resultados esperados: 23 Resultados obtenidos: 0 Resultado prueba: Fracaso Tabla 6.13: T13 - UI test Vacaciones 01 Este test no tuvo ´exito y nos permiti´o descubir que el JSON que se estaba usando como datos para la interfaz no estaba bien definido. Este test no permiti´o mejorar ninguna funcionalidad pero si mejorar la forma de escribir los tests. Nombre: testHolidaysViewWithAllTheFields ID: 14 Escenario: Vacaciones Descripci´on: Comprobar que todos los elementos de la interfaz se muestran en la misma. Resultados esperados: Todos los elementos de la vista se muestran en la interfaz. Resultados obtenidos: Todos los elementos son detectados. Resultado prueba: ´ Exito Tabla 6.14: T14 - UI test Vacaciones 02 98 Unit tests: Nombre: testGetUserHolidaysShouldReturnTwoElements ID: 15 Escenario: Holidays Descripci´on: La funcionalidad que permite obtener las vacaciones debe devolver dos elementos (de vacaciones). Resultados esperados: 2 Resultados obtenidos: 2 Resultado prueba: ´ Exito Tabla 6.15: T15 - Unit test Vacaciones 01 Nombre: testAskForHolidaysShouldReturnExpectedStatus ID: 16 Escenario: Vacaciones Descripci´on: La funcionalidad de pedir vacaciones devuelve una respuesta del servidor (nuestro JSON) con una solicitud de vacaciones con estado pendiente (valor: 1) Resultados esperados: 1 Resultados obtenidos: 1 Resultado prueba: ´ Exito Tabla 6.16: T16 - Unit test Vacaciones 02 6.3.6.3 Tabl´on de anuncios UI tests: Nombre: testNoticeBoardFourthCellMustHavePropertyCollection ID: 17 Escenario: Tabl´on de anuncios Descripci´on: La cuarta celda debe mostrar el mensaje esperado. Resultados esperados: ”aviso de prueba” Resultados obtenidos: ”aviso de prueba” Resultado prueba: ´ Exito Tabla 6.17: T17 - UI test Tabl´on de anuncios 01 Nombre: testNoticeBoardMustHaveFiveNotices ID: 18 Escenario: Tabl´on de anuncios Descripci´on: La vista debe mostrar cinco celdas con sus elementos correspondientes. Resultados esperados: 5 Resultados obtenidos: 5 Resultado prueba: ´ Exito Tabla 6.18: T18 - UI test Tabl´on de anuncios 02 99 Unit tests: Nombre: testGetNoticesShouldReturnZeroNotices ID: 19 Escenario: Tabl´on de anuncios Descripci´on: La funcionalidad debe devolver cero anuncios. Este test sirve para comprobar que el comportamiento de la funcionalidad es el adecuado con un JSON vac´ıo. Resultados esperados: 0 Resultados obtenidos: Error Resultado prueba: Fracaso Tabla 6.19: T19 - Unit test Tabl´on de anuncios 01 Este test permiti´o descubir que un JSON de respueta vac´ıo del servidor provocar´ıa un cierre inesperado de la aplicaci´on. Nombre: testGetNoticesShouldReturnCreatorProperty ID: 20 Escenario: Tabl´on de anuncios Descripci´on: Comprobar que la respuesta falsa (JSON) devuelve los datos esperados. Resultados esperados: [”1”, ”1”, ”1”, ”999”, ”2”] Resultados obtenidos: [”1”, ”1”, ”1”, ”999”, ”2”] Resultado prueba: ´ Exito Tabla 6.20: T20 - Unit test Tabl´on de anuncios 02 6.3.6.4 Equipo UI tests: Nombre: testPhoneButtonFirstRowEnabled ID: 21 Escenario: Equipo Descripci´on: Comprobar que la primera celda (primer trabajador) tiene el bot´on de tel´efono activado. Resultados esperados: True Resultados obtenidos: True Resultado prueba: ´ Exito Tabla 6.21: T21 - UI test Equipo 01 100 Nombre: testSecondTeamMateIsHector ID: 22 Escenario: Equipo Descripci´on: Comprobar que el nombre del trabajador que aparece en la segunda celda es el esperado. Resultados esperados: ”H´ector” Resultados obtenidos: ”default” Resultado prueba: Fracaso Tabla 6.22: T22 - UI test Equipo 02 Los datos que se muestran en la interfaz no se ordenan bajo ning´un criterio al ser solicitados a la base de datos, por lo que cada vez se colocan de una forma en la interfaz y en este caso el test ha fallado. Unit tests: Nombre: testGetTeamShouldReturnNameProperty ID: 23 Escenario: Equipo Descripci´on: Comprobar que la funcionalidad se comporta como deber´ıa, devolviendo el valor de la propiedad ”nombre” de trabajador esperada. Resultados esperados: [”hector”, ”user”, ”default”] Resultados obtenidos: [”hector”, ”user”, ”default”] Resultado prueba: ´ Exito Tabla 6.23: T23 - Unit test Equipo 01 Nombre: testGetTeamShouldReturnThirtyTwoUsers ID: 24 Escenario: Equipo Descripci´on: La funcionalidad que permite obtener todos los trabajadores debe devolver 32 elementos. Resultados esperados: 32 Resultados obtenidos: 32 Resultado prueba: ´ Exito Tabla 6.24: T24 - Unit test Equipo 02 6.3.6.5 Informaci´on de la empresa UI tests: 101 Nombre: testCompanyInfoCellWithAllTheFIelds ID: 25 Escenario: Empresa Descripci´on: Comprobar que todos los elementos de la interfaz se muestran en la misma. Resultados esperados: Todos los elementos de la vista se muestran en la interfaz. Resultados obtenidos: Todos los elementos no son detectados. Resultado prueba: ´ Exito Tabla 6.25: T25 - UI test Empresa 01 Nombre: testCompanyHeaderCellWithAllTheFIelds ID: 26 Escenario: Empresa Descripci´on: Comprobar que todos los elementos de la celda se muestran en la interfaz. Resultados esperados: Todos los elementos de la celda se muestran en la interfaz. Resultados obtenidos: Todos los elementos son detectados. Resultado prueba: Fracaso Tabla 6.26: T26 - UI test Empresa 02 Este test no se realiz´o con ´exito debido a que los elementos no estaban correctamente identificados, por lo que el test no los detect´o a pesar de que, efectivamente, estaban presentes en la intefaz. Unit tests: La secci´on de Empresa no tiene tests unitarios debido a que no necesita datos del servidor para mostrar en su interfaz. 6.3.6.6 Ajustes UI tests: Nombre: testSettingsViewWithAllTheFIelds ID: 27 Escenario: Settings Descripci´on: Comprobar que todos los elementos de la interfaz se muestran en la misma. Resultados esperados: Todos los elementos de la interfaz se muestran en la misma. Resultados obtenidos: Todos los elementos son detectados. Resultado prueba: ´ Exito Tabla 6.27: T27 - UI test Ajustes Unit tests: La secci´on de Settings no tiene tests unitarios debido a que no necesita datos del servidor para mostrar en su interfaz. 102 6.3.6.7 Administraci´on UI tests: Nombre: testChangeStatusSecondRow ID: 28 Escenario: Administraci´on Descripci´on: Comprobar que en la segunda celda, al hacer swipe aparecen las opciones para esa solicitud. Resultados esperados: Se hace el swipe (deslizamiento) autom´aticamente y aparecen las opciones. Resultados obtenidos: El swipe se realiza y aparecen las opciones esperadas. Resultado prueba: ´ Exito Tabla 6.28: T28 - UI test Administraci´on 01 Nombre: testFirstTableRowMustHavePropertyCollection ID: 29 Escenario: Administraci´on Descripci´on: Comprobar que la primera celda tiene el valor de las propiedades esperadas. Resultados esperados: Nombre: ”Hector Rogel”, fecha: ”Del 4/23/19 al 4/24/19” Resultados obtenidos: Nombre: ”Hector Rogel”, fecha: ”Del 4/23/19 al 4/24/19” Resultado prueba: ´ Exito Tabla 6.29: T29 - UI test Administraci´on 02 Unit tests: Nombre: testChangeHolidayStatusShouldReturnExpectedPropertyCollection ID: 31 Escenario: Administraci´on Descripci´on: Comprobar que la funcionalidad de cambiar el estado de una solicitud devuelve el valor de las propiedades esperadas. Resultados esperados: id: 99, userId: 999, status: 1 Resultados obtenidos: id: 99, userId: 999, status: 1 Resultado prueba: ´ Exito Tabla 6.30: T30 - Unit test Administraci´on 01 103 Anexo A Manual de Usuario Este documento detalla la forma de utilizar la aplicaci´on SGEmployee por parte de un Administrador. Un usuario con rol diferente de administrador no podr´a ver la secci´on de Administraci´on que vamos a mostrar a continuaci´on. En primer lugar, tras instalar la aplicaci´on en un dispositivo m´ovil, el usuario debe hacer login en ella. La siguiente figura muestra la pantalla de Login: Figura A.1: Pantalla de Login Una vez identificado aparecer´a la pantalla principal con los tweets de la cuenta de la empresa como se muestra a continuaci´on: 110 Figura A.2: Pantalla principal Al pulsar sobre el icono en la parte superior izquierda de la pantalla se muestra el men´u lateral: 111 Figura A.3: Men´u lateral En este men´u lateral aparece, como ´ultima secci´on, una opci´on de Administraci´on. Esta opci´on aparece ´unicamente si el usuario es administrador. Si se pulsa sobre dicha funci´on aparecer´a la pantalla de Administraci´on siguiente: 112 Figura A.4: Pantalla de Administraci´on En esta pantalla aparecen todas las solicitudes de vacaciones de todos los trabajadores sea cu´al sea su estado. Sobre las celdas de las solicitudes, podemos deslizar hacia la derecha para que aparezca la opci´on de la Figura A.5 (en caso de solicitud aprobada). Tambi´en podemos deslizar hacia la izquierda sobre una solicitud pendiente para que aparezcan las opciones de aceptar o rechazar, como se muestra en la Figura A.6: 113 Figura A.5: Deslizamiento derecha solicitud Figura A.6: Deslizamiento izquierda solicitud Otra opci´on disponible en esta secci´on es pulsar sobre una solicitud pendiente para ver en detalle esa solicitud, con un historial de solicitudes, n´umero de d´ıas de vacaciones restantes y las opciones de aceptar o rechazar, como se muestra a continuaci´on: 114 Figura A.7: Pantalla de detalle de solicitud Si volvemos a la pantalla del men´u lateral (Figura A3), otra nueva opci´on desarrollada en este Trabajo de Fin de Grado es el redise˜no de la secci´on Equipo, que queda de la forma que se muestra en el Figura A.8. Si pulsamos sobre cualquiera de los empleados, aparecer´an las opciones que se muestran el la Figura A.9. La opci´on de Ver las Vacaciones ´unicamente se muestra si el usuario es administrador. 115 Figura A.8: Pantalla Equipo Figura A.9: Opciones Equipo Al pulsar sobre la opci´on de Ver Vacaciones, aparecer´a un historial completo por a˜nos de las solicitudes del empleado seleccionado, as´ı c´omo los d´ıas de vacaciones totales o restantes, y unas pesta˜nas para navegar por cada a˜no para ver los datos del mismo, como se muestra en la figura siguiente: 116 Figura A.10: Pantalla Historial Empleado 117 Anexo B Manual de Instalaci´on Requisitos: •Equipo inform´atico con sistema operativo MacOS Mojave •XCode 10.2 o superior •Hay que tener instalado Ruby y la gema CocoaPods Instalaci´on: •Descomprimir el proyecto del CD. •Abrir el terminal y acceder a la carpeta SGEM del proyecto. •Ejecutar el siguiente comando en el terminal para instalar las librer´ıas de terceros: pod install •Abrir el fichero SGEM.xcworkspace con XCode. •Compilar y ejecutar el proyecto. 118