Desarrollo de un prototipo de aplicación web y móvil para la gestión de obras de instalación de fibra óptica : parte 2

Desarrollo de un prototipo de aplicación web y móvil para la gestión de obras de instalación de fibra óptica - Parte 2. Grado en Ingeniería Informática Trabajo de fin de grado Julio de 2017, Las Palmas de Gran Canaria Autor: Álvaro Romero Perdomo y Tutores: Dr. Alexis Quesada Arencibia y D. Jonathan Alemán Alemán Álvaro Romero Perdomo | 2 Álvaro Romero Perdomo | 3 Resumen Este proyecto surge bajo la necesidad de resolución de un problema real, en un contexto real, donde se pretende dar soporte a la gestión de obras de instalación de fibra óptica, permitiendo así comunicación bidireccional eficiente entre los diferentes intervinientes de la misma. El objetivo de este proyecto es el análisis, diseño e implementación de un panel de administración que permita la creación y edición de las obras, así como la asignación de empleados a la misma que lleven a cabo las tareas pertenecientes a ella. Como objetivo secundario se nos presenta la posibilidad de experimentar en el campo del desarrollo híbrido de aplicaciones para móviles, así como el estudio de diferentes tecnologías totalmente novedosas para el autor de este trabajo. Abstract This project raises under the necessity of a real problem resolution, in a real context, to give support to optical fiber installation works, thus allowing an efficient and bidirectional communication between all participants. The main objective of this project is an administration panel analysis, design and implementation that allows the works creation and editing, as well as the employees allocation to it that perform it tasks. The secondary project objective is the experimenting possibility inside the hybrid mobile applications development, as well as the study of different technologies totally novel for the author of this work. Álvaro Romero Perdomo | 4 Índice Resumen ............................................................................................................................. 3 Abstract .............................................................................................................................. 3 Índice de ilustraciones ......................................................................................................... 6 Índice de tablas ................................................................................................................... 7 Estructura del documento .................................................................................................... 9 1. Bloque 1. Introducción y Contextualización ................................................................. 10 1.1. Introducción ....................................................................................................... 10 1.2. Estado actual ...................................................................................................... 11 1.3. Objetivos ............................................................................................................ 12 1.3.1. Objetivos generales ............................................................................................. 12 1.3.2. Objetivos académicos ......................................................................................... 12 1.4. Normativa y legislación ....................................................................................... 13 1.4.1. Ley de protección de Datos de Carácter Personal .............................................. 13 1.5. Justificación de las competencias específicas cubiertas ........................................ 15 1.5.1. Competencias comunes a la Ingeniería Informática ........................................... 15 1.6. Aportaciones ...................................................................................................... 17 1.7. Recursos ............................................................................................................. 18 1.7.1. Recursos software ............................................................................................... 18 1.7.2. Recursos hardware .............................................................................................. 24 1.8. Planificación temporal ........................................................................................ 26 2. Bloque 2. Desarrollo del Proyecto ............................................................................... 28 2.1. Análisis ............................................................................................................... 28 2.1.1. Primera reunión y contextualización del problema ............................................ 28 2.1.2. Glosario de lenguaje propio del contexto del problema .................................... 29 2.1.3. Generación del prototipo .................................................................................... 29 2.1.4. Segunda reunión, validación y acotación de requisitos ...................................... 30 2.1.5. Especificación final de requisitos y acotación del proyecto ................................ 31 2.1.6. Identificación de actores principales del sistema ............................................... 32 2.1.7. Especificación y diagramas de casos de uso ....................................................... 33 2.2. Diseño ................................................................................................................ 35 2.2.1. Componentes del sistema ................................................................................... 35 2.2.2. Utilización del patrón de diseño Modelo – Vista – Controlador (MVC) .............. 36 2.2.3. Desarrollo híbrido con Ionic ................................................................................ 36 2.2.4. Estructura y entidades de la base de datos ........................................................ 37 2.2.5. Arquitectura del portal de administración en AngularJS .................................... 37 Álvaro Romero Perdomo | 5 2.3. Implementación .................................................................................................. 39 2.3.1. Desarrollo de la API Rest en NodeJS y MongoDB ................................................ 40 2.3.2. Desarrollo del portal de administración .............................................................. 43 2.4. Pruebas .............................................................................................................. 46 3. Bloque 3. Conclusiones y Trabajos Futuros .................................................................. 48 3.1. Conclusiones y trabajos futuros ........................................................................... 48 3.1.1. Conclusiones sobre el desarrollo del proyecto ................................................... 48 3.1.2. Trabajos futuros .................................................................................................. 50 4. Bloque 4. Fuentes de Información ............................................................................... 51 4.1. Fuentes de información del Bloque 1. Introducción y contextualización ............... 51 4.2. Fuentes de información del Bloque 2. Desarrollo del proyecto ............................. 51 5. Bloque 5. Anexos ....................................................................................................... 52 5.1. Anexo 1. Casos de uso ......................................................................................... 52 5.2. Anexo 2. Manual de usuario del panel de administración ..................................... 84 5.3. Anexo 3. Pantallazos completos de la demo no funcional ..................................... 89 5.4. Anexo 4. Esquemas completos MongoDB ............................................................ 91 5.5. Anexo 5. Documentación de la API REST .............................................................. 93 Álvaro Romero Perdomo | 6 Índice de ilustraciones Ilustración 1. Pantallas principales del prototipo no funcional ............................................. 30 Ilustración 2. Representación gráfica de una arquitectura cliente-servidor .......................... 35 Ilustración 3. Interacción de componentes con AngularJS ................................................... 36 Ilustración 4. Diagrama de entidades de la base de datos ................................................... 37 Ilustración 5. Jearquía de ficheros de una aplicación en AngularJS ...................................... 38 Ilustración 6. Versión inicial del fichero package.json .......................................................... 40 Ilustración 7. Petición GET al servidor en el puerto 3000 ..................................................... 41 Ilustración 8. Fichero resumido del esquema de Mongoose para el modelado de las obras . 41 Ilustración 9. Jerarquía de ficheros de la API REST siguiendo patrón MVC ............................ 42 Ilustración 10. Jerarquía de ficheros del portal de administración ....................................... 43 Ilustración 11. Fichero works-service .................................................................................. 44 Ilustración 12. Fichero dashboard-controller ...................................................................... 45 Ilustración 13. Fichero de test para usuarios ....................................................................... 46 Ilustración 14. Tests de operaciones con usuarios ............................................................... 47 Ilustración 15. Diagrama de casos de uso completo ............................................................ 52 Ilustración 16. Pantalla de inicio del panel de administración .............................................. 84 Ilustración 17. Pantalla de login del panel de administración .............................................. 84 Ilustración 18. Dashboard del panel de administración ....................................................... 85 Ilustración 19. Creación de una obra en el panel de administración ..................................... 85 Ilustración 20. Creación de una obra en el panel de administración (materiales) ................. 86 Ilustración 21. Creación de una obra en el panel de administración (añadiendo una tarea) .. 86 Ilustración 22. Creación de una obra en el panel de administración (añadiendo archivos adjuntos) ........................................................................................................................... 87 Ilustración 23. Vista de la pantalla users ............................................................................. 87 Ilustración 24. Vista de la pantalla materials ....................................................................... 88 Ilustración 25. Vista de edición de una obra ....................................................................... 88 Ilustración 26. Primeras pantallas de la demo no funcional ................................................. 89 Ilustración 27. Información de la obra en la demo no funcional ........................................... 90 Ilustración 28. Acciones disponibles en una tarea en la demo no funcional ......................... 90 Álvaro Romero Perdomo | 7 Índice de tablas Tabla 1. Planificación inicial ............................................................................................... 26 Tabla 2. Dedicación final .................................................................................................... 26 Tabla 3. Glosario de lenguaje propio del contexto del problema ......................................... 29 Tabla 4. Actores principales del sistema ............................................................................. 32 Tabla 5. Tabla de especificación de los casos de uso............................................................ 33 Tabla 6. Tabla de especificación del caso de uso "Gestionar empleados" ............................. 34 Tabla 7. Caso de uso: Iniciar sesión en el panel de administración ....................................... 53 Tabla 8. Caso de uso: Crear obra ........................................................................................ 54 Tabla 9. Caso de uso: Gestionar obra .................................................................................. 55 Tabla 10. Gestionar tareas ................................................................................................. 56 Tabla 11. Caso de uso: Añadir tarea .................................................................................... 57 Tabla 12. Caso de uso: Eliminar tarea ................................................................................. 58 Tabla 13. Caso de uso: Editar tarea ..................................................................................... 59 Tabla 14. Caso de uso: Añadir subtarea .............................................................................. 60 Tabla 15. Caso de uso: Importar tareas ............................................................................... 61 Tabla 16. Caso de uso: Gestionar material .......................................................................... 62 Tabla 17. Caso de uso: Añadir material ............................................................................... 63 Tabla 18. Caso de uso: Editar material ................................................................................ 64 Tabla 19. Caso de uso: Importar material ........................................................................... 65 Tabla 20. Caso de uso: Gestionar adjuntos .......................................................................... 66 Tabla 21. Caso de uso: Añadir adjunto ................................................................................ 67 Tabla 22. Caso de uso: Eliminar adjunto ............................................................................. 68 Tabla 23. Caso de uso: Cambiar estado de una obra ............................................................ 69 Tabla 24. Caso de uso: Certificar obra ................................................................................. 70 Tabla 25. Caso de uso: Registrar empleados ....................................................................... 71 Tabla 26. Caso de uso: Gestionar empleados ...................................................................... 72 Tabla 27. Caso de uso: Editar empleado ............................................................................. 73 Tabla 28. Caso de uso: Eliminar empleado .......................................................................... 74 Tabla 29. Caso de uso: Notificar empleado ......................................................................... 75 Tabla 30. Caso de uso: Visualizar empleado ........................................................................ 76 Tabla 31. Caso de uso: Iniciar sesión en la APP .................................................................... 77 Tabla 32. Caso de uso: Visualizar obra ................................................................................ 78 Tabla 33. Caso de uso: Gestionar archivos adjuntos a tarea................................................. 79 Tabla 34. Caso de uso: Adjuntar archivo ............................................................................. 80 Álvaro Romero Perdomo | 8 Tabla 35. Caso de uso: Eliminar archivos de una tarea ........................................................ 81 Tabla 36. Caso de uso: Añadir tareas a obra (empleado) ..................................................... 82 Tabla 37. Caso de uso: Notificar incidencia ......................................................................... 83 Tabla 38. Especificación de la entidad Obras en la base de datos ......................................... 91 Tabla 39. Especificación de la entidad Tareas en la base de datos........................................ 92 Tabla 40. Especificación de la entidad Material en la base de datos..................................... 92 Tabla 41. Especificación de la entidad Usuarios en la base de datos .................................... 92 Tabla 42. Documentación de acceso a la entidad Autenticación .......................................... 93 Tabla 43. Documentación de acceso a la entidad Obras ...................................................... 93 Tabla 44. Documentación de acceso a la entidad Materiales ............................................... 93 Tabla 45. Documentación de acceso a la entidad Usuarios .................................................. 94 Tabla 46. Documentación de acceso a la entidad Subidas en la API REST ............................. 94 Álvaro Romero Perdomo | 9 Estructura del documento Durante el desarrollo de la memoria, hemos decidido dividirla en cinco grandes bloques que abarcan la totalidad del proyecto. 1. Bloque 1. Introducción y Contextualización: En este bloque presentaremos el problema que pretende resolver el proyecto y su contexto. Además, se presentan las soluciones actuales que utilizan los usuarios, qué aporta este proyecto y qué competencias cubre. 2. Bloque 2. Desarrollo del proyecto: En este bloque se recogen las diferentes fases por las que hemos pasado durante el desarrollo del proyecto. Los problemas con los que nos hemos ido encontrando durante su desarrollo y qué decisiones hemos tomado. 3. Bloque 3. Conclusiones y Trabajos Futuros: A lo largo de este bloque concluiremos la memoria reflexionando acerca de qué nos ha aportado este proyecto y sugeriremos qué podría incluir futuras versiones del desarrollo. 4. Bloque 4. Fuentes de Información: Aquí recogeremos las fuentes de información utilizadas durante el desarrollo del proyecto. 5. Bloque 5. Anexos: Completaremos la memoria a través de los anexos que aportarán información adicional a consultar si el lector lo desea. Como comentaremos en la introducción, debemos adelantar que este proyecto ha sido dividido desde el principio en tres grandes partes, una conjunta y dos desarrolladas por diferentes alumnos. Por lo que ambas memorias siguen una estructura muy similar y comparten grandes similitudes en su desarrollo a excepción del apartado de implementación, trabajos futuros y aquellos intrínsecamente personales como las conclusiones. Álvaro Romero Perdomo | 16 Esta competencia queda cubierta por parte del alumno porque en este proyecto: • Se ha garantizado la persistencia de los datos introducidos en la misma mediante la utilización de una base de datos no relacional MongoDB, que permite el acceso a los datos de manera rápida, sencilla y segura. CII16 Conocimiento y aplicación de los principios, metodologías y ciclos de vida de la ingeniería de software. Esta competencia queda cubierta por parte del alumno porque en este proyecto: • Se han aplicado principios de la ingeniería del software tales como la modularidad en la arquitectura y el código que permiten la ampliación de la herramienta en futuras iteraciones y la refactorización del código para facilitar su mantenimiento. CII17 Capacidad para diseñar y evaluar interfaces persona computador que garanticen la accesibilidad y usabilidad a los sistemas, servicios y aplicaciones informáticas. Esta competencia queda cubierta por parte del alumno porque en este proyecto: • Se ha hecho uso de librerías como AngularJS Material basadas en Google Material, cuyo objetivo es la accesibilidad de la interfaz y su usabilidad. TFG01 Ejercicio original a realizar individualmente y presentar y defender ante un tribunal universitario, consistente en un proyecto en el ámbito de las tecnologías específicas de la Ingeniería en Informática de naturaleza profesional en el que se sinteticen integren las competencias adquiridas en las enseñanzas. Álvaro Romero Perdomo | 17 1.6. Aportaciones Este proyecto trata de resolver un problema real a través del desarrollo de un portal web de administración, una API Rest y una aplicación móvil funcionales, intentando además realizar una aportación tecnológica, económica y social. En el plano tecnológico intentamos dar un enfoque más innovador y actual a la gestión de obras por parte de la empresa instaladora aportando un software capaz de, prácticamente, abstraer tanto al empleado como al administrador de complicados y poco ortodoxos métodos de traspaso de información, convirtiendo este proceso en algo más simple y a la misma vez más robusto. Para conseguir este fin se ha hecho uso de tecnologías actuales en el campo del desarrollo web tales como el Stack MEAN. Además, la interfaz de usuario tanto del portal de administración como de la aplicación móvil está basada en estándares actuales como el Material Design. Desde el punto de vista económico, este proyecto permite a las empresas instaladoras de fibra óptica facturar a las proveedoras de internet de manera eficiente e intachable evitando así pérdidas reales de dinero para ellas derivadas de la pérdida de información necesaria para la certificación y facturación de una obra debida a la forma en que ésta era gestionada. En el ámbito social la aplicación trata de facilitar el trabajo a los empleados que, a la hora de generar información necesaria para la certificación, debían utilizar varias aplicaciones en su dispositivo para intercambiarla con el encargado de la obra. Ahora disponen de una aplicación centralizada y específica para el control de la información que les permite ahorrar tiempo y realizar las mismas tareas de una manera mucho más sencilla. Desde el punto de vista del encargado de la obra se ha facilitado en gran medida el trabajo organizativo que éste debía hacer tanto a la hora de comenzar una nueva obra, como a la hora de certificar la misma. Álvaro Romero Perdomo | 18 1.7. Recursos 1.7.1. Recursos software A continuación, se exponen las herramientas software utilizadas para el desarrollo del proyecto. Sistemas operativos El proyecto ha sido realizado en tres entornos diferentes como son Windows 10, Ubuntu 16.04 y Mac OS. En un principio se decidió trabajar en Windows 10 y en Mac Os paralelamente, pero la instalación de MongoDB en Linux era mucho más directa y presentaba menos problemas en comparación con su versión en Windows. Sistema de control de versiones del código, GIT Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Git se ha convertido en un sistema de control de versiones con funcionalidad plena. Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux. Dentro de Git hemos utilizado la metodología de trabajo, git-flow. Sus características principales son las siguientes. El trabajo se organiza en dos ramas principales: • Rama master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción • Rama develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto Cada vez que se incorpora código a master, tenemos una nueva versión. Además de estas dos ramas, Se proponen las siguientes ramas auxiliares: • Feature. • Release. • Hotfix. Álvaro Romero Perdomo | 19 Editor de texto/código, Atom Atom es un editor de código para macOS, Linux, y Windows con soporte para plugins escrito en NodeJS, incrustando Git Control, desarrollado por GitHub. Atom es una aplicación de escritorio construida utilizando tecnologías web. La mayor parte de los paquetes tienen licencias de software libre y es construido y mantenido por su comunidad. Atom está basado en Electrón (Anteriormente conocido como Atom Shell), un framework que permite aplicaciones de escritorio multiplataforma usando Chromium y Node.js. Está escrito en CoffeeScript y Less. También puede ser utilizado como un entorno de desarrollo integrado (IDE). Los lenguajes soportados por Atom son los siguientes: HTML, CSS, Menos, Sass, GitHub Sazonó Markdown, C/C++, C#, Va, Java, Objetivo-C, Javascript, JSON, CoffeeScript, Python, PHP, Ruby, Ruby en Raíles, Shell Script, Clojure, Perl, Git, Marca, Property List(Apple), TOML, XML, YAML, Mustache, Julia & SQL. Lenguaje de programación, JavaScript JavaScript (abreviado comúnmente JS) es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. Se utiliza principalmente en su forma del lado del cliente (client-side), implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas, aunque existe una forma de JavaScript del lado del servidor (Server-side JavaScript o SSJS). Su uso en aplicaciones externas a la web, por ejemplo, en documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también significativo. Las características principales de JavaScript son las siguientes: • JavaScript es un lenguaje de secuencias de comandos basado en objetos e interpretado. • Aunque tiene menos capacidades que los lenguajes orientados a objetos de altas prestaciones como C++ y Java, JavaScript es más que suficientemente eficiente para los propósitos para los que está creado. • JavaScript no es una versión reducida de cualquier otro lenguaje (sólo está relacionado, distante e indirectamente, con Java, por ejemplo), ni es una simplificación de ningún lenguaje. • JavaScript es un lenguaje limitado. Por ejemplo, no es posible escribir aplicaciones independientes en JavaScript y la capacidad de lectura y escritura de archivos es mínima. • Las secuencias de comandos de JavaScript sólo pueden ejecutarse con un intérprete, que bien puede estar en un servidor Web o en un explorador de Web. • JavaScript es un lenguaje en el que no necesita declarar los tipos de datos. Esto significa que no es necesario declarar explícitamente los tipos de datos de las variables. De hecho, no es posible declarar explícitamente los tipos de datos en JavaScript. Más aún, en muchos casos JavaScript realiza conversiones, automáticamente, cuando son Álvaro Romero Perdomo | 20 necesarias. Por ejemplo, si intenta agregar un número a un elemento que contiene texto (una cadena), el número se convierte en texto. NodeJS Node.js es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor (pero no limitándose a ello) basado en el lenguaje de programación ECMAScript, asíncrono, con I/O de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google. Fue creado con el enfoque de ser útil en la creación de programas de red altamente escalables, como, por ejemplo, servidores web. Fue creado por Ryan Dahl en 2009 y su evolución está apadrinada por la empresa Joyent, que además tiene contratado a Dahl en plantilla. Node.js es una forma de ejecutar JavaScript en el servidor, además de mucho más. Además de la alta velocidad de ejecución de Javascript, la verdadera magia detrás de Node.js es algo que se llama Bucle de Eventos (Event Loop). Para escalar grandes volúmenes de clientes, todas las operaciones intensivas I/O en Node.js se llevan a cabo de forma asíncrona. El enfoque tradicional para generar código asíncrono es engorroso y crea un espacio en memoria no trivial para un gran número de clientes (cada cliente genera un hilo, y el uso de memoria de cada uno se suma). Para evitar esta ineficiencia, así como la dificultad conocida de las aplicaciones basadas en hilos, (programming threaded applications), Node.js mantiene un event loop que gestiona todas las operaciones asíncronas. AngularJS AngularJS (comunalmente llamado "Angular" o "Angular.js"), es un framework de JavaScript de código abierto, mantenido por Google, que se utiliza para crear y mantener aplicaciones web de una sola página. Su objetivo es aumentar las aplicaciones basadas en navegador con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean más fáciles. La biblioteca lee el HTML que contiene atributos de las etiquetas personalizadas adicionales, entonces obedece a las directivas de los atributos personalizados, y une las piezas de entrada o salida de la página a un modelo representado por las variables estándar de JavaScript. Los valores de las variables de JavaScript se pueden configurar manualmente, o recuperados de los recursos JSON estáticos o dinámicos. AngularJS se puede combinar con el entorno en tiempo de ejecución Node.js, el framework para servidor Express.js y la base de datos MongoDB para formar el conjunto MEAN. Álvaro Romero Perdomo | 21 MongoDB MongoDB (de la palabra en inglés “humongous” que significa enorme) es un sistema de base de datos NoSQL orientado a documentos, desarrollado bajo el concepto de código abierto. MongoDB forma parte de la nueva familia de sistemas de base de datos NoSQL. En lugar de guardar los datos en tablas como se hace en las bases de datos relacionales, MongoDB guarda estructuras de datos en documentos similares a JSON con un esquema dinámico (MongoDB utiliza una especificación llamada BSON), haciendo que la integración de los datos en ciertas aplicaciones sea más fácil y rápida. Las características principales de MongoDB son: • De propósito general, casi tan rápida como las bases de datos NoSQL de tipo clave:valor, y con casi todas las funcionalidades de las bases de datos relacionales. • Alta disponibilidad. • Escalabilidad, desde un servidor aislado a arquitecturas distribuidas de grandes clusters. • Aggregation Framework, procesamiento batch de datos para cálculos agrupados utilizando operaciones nativas de MongoDB. • Auto balanceado de carga, a través de distintos shards. • Replicación nativa, sincronización de datos entre servidores. • Seguridad, autenticación, autorización, etc. • Gestión avanzada de usuarios. • Automatic failover. • Se actualiza sin dejar de dar servicio. • No tiene los cuellos de botella que se producen en las bases de datos relacionales (RDBMS). • Utiliza objetos JSON para guardar y transmitir la información. En el desarrollo de la aplicación utilizamos Mongoose como driver de Mongo, lo que nos permitió crear esquemas que luego se verían reflejados en la base de datos de manera mucho más clara y directa. ExpressJS ExpressJS o simplemente Express, es un framework para el desarrollo de aplicaciones web para NodeJS distribuido de manera libre y gratuita bajo licencia MIT. Está diseñado para construir aplicaciones web y APIs. Se le considera el framework del lado del servidor estándar para NodeJS. Por lo tanto, podríamos decir que ExpressJS es una infraestructura de aplicaciones web Node.js mínima y flexible que proporciona un conjunto sólido de características para las aplicaciones web y móviles. Álvaro Romero Perdomo | 22 JSON JSON, acrónimo de JavaScript Object Notation, es un formato de texto ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de Javascript aunque hoy, debido a su amplia adopción como alternativa a XML, se considera un formato de lenguaje independiente. Una de las ventajas de JSON sobre XML como formato de intercambio de datos es que es mucho más sencillo escribir un analizador sintáctico (parser) de JSON. En JavaScript, un texto JSON se puede analizar fácilmente usando la función eval, lo cual ha sido fundamental para que JSON haya sido aceptado por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad de JavaScript en casi cualquier navegador web. Ionic Ionic es un framework open source para el desarrollo de aplicaciones híbridas que permite crear aplicaciones multiplataforma utilizando HTML5 optimizado para móvil, CSS3, componentes JavaScript, gestos y herramientas para la construcción de aplicaciones altamente interactivas. Construido con Sass y optimizado para AngularJS permite asegurar aplicaciones robustas, rápidas y escalables. Las aplicaciones son híbridas, ¿Qué quiere decir eso? Que puedes desarrollar una misma aplicación y ejecutarla en Android, iOS y Windows Phone sin tener que desarrollarla en el correspondiente lenguaje nativo de cada plataforma. Una de las características de Ionic Framework es que está construido para ser rápido debido a la mínima manipulación del DOM, sin utilizar jQuery y con aceleraciones de transiciones por hardware. HTML HTML, sigla en inglés de HyperText Markup Language (lenguaje de marcas de hipertexto), hace referencia al lenguaje de marcado para la elaboración de páginas web. Es un estándar que sirve de referencia del software que conecta con la elaboración de páginas web en sus diferentes versiones, define una estructura básica y un código (denominado código HTML) para la definición de contenido de una página web, como texto, imágenes, videos, juegos, entre otros. Es un estándar a cargo del World Wide Web Consortium (W3C) o Consorcio WWW, organización dedicada a la estandarización de casi todas las tecnologías ligadas a la web, sobre todo en lo referente a su escritura e interpretación. Se considera el lenguaje web más importante siendo su invención crucial en la aparición, desarrollo y expansión de la World Wide Web (WWW). Es el estándar que se ha impuesto en la visualización de páginas web y es el que todos los navegadores actuales han adoptado. El lenguaje HTML basa su filosofía de desarrollo en la diferenciación. Para añadir un elemento externo a la página (imagen, vídeo, script, entre otros.), este no se incrusta directamente en el código de la página, sino que se hace una referencia a la ubicación de dicho Álvaro Romero Perdomo | 23 elemento mediante texto. De este modo, la página web contiene solamente texto mientras que recae en el navegador web (interpretador del código) la tarea de unir todos los elementos y visualizar la página final. Al ser un estándar, HTML busca ser un lenguaje que permita que cualquier página web escrita en una determinada versión, pueda ser interpretada de la misma forma (estándar) por cualquier navegador web actualizado. GitHub GitHub es una forja (plataforma de desarrollo colaborativo) para alojar proyectos utilizando el sistema de control de versiones Git. Utiliza el framework Ruby on Rails por GitHub, Inc. (anteriormente conocida como Logical Awesome). Desde enero de 2010, GitHub opera bajo el nombre de GitHub, Inc. El código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago. CSS Hojas de estilo en cascada (o CSS, siglas en inglés de Cascading Stylesheets) es un lenguaje de diseño gráfico para definir y crear la presentación de un documento estructurado escrito en un lenguaje de marcado. Es muy usado para establecer el diseño visual de las páginas web, e interfaces de usuario escritas en HTML o XHTML; el lenguaje puede ser aplicado a cualquier documento XML, incluyendo XHTML, SVG, XUL, RSS, etcétera. También permite aplicar estilos no visuales, como las hojas de estilo auditivas. Junto con HTML y JavaScript, CSS es una tecnología usada por muchos sitios web para crear páginas visualmente atractivas, interfaces de usuario para aplicaciones web, y GUIs para muchas aplicaciones móviles (como Firefox OS). CSS está diseñado principalmente para marcar la separación del contenido del documento y la forma de presentación de este, características tales como las capas, los colores y las fuentes. Esta separación busca mejorar la accesibilidad del documento, proveer más flexibilidad y control en la especificación de características, permitir que varios documentos HTML compartan un mismo estilo usando una sola hoja de estilos separada en un archivo .css, y reducir la complejidad y la repetición de código en la estructura del documento. Librerías utilizadas En informática, una librería (del inglés library) es un conjunto de implementaciones funcionales, codificadas en un lenguaje de programación, que ofrece una interfaz bien definida para la funcionalidad que se invoca. A diferencia de un programa ejecutable, el comportamiento que implementa una librería no espera ser utilizada de forma autónoma (un programa sí: tiene un punto de entrada principal), sino que su fin es ser utilizada por otros programas, independientes y de forma simultánea. Por otra parte, el comportamiento de una librería no tiene por qué diferenciarse en demasía del que pudiera especificarse en un programa. Es más, unas librerías pueden requerir Álvaro Romero Perdomo | 24 de otras para funcionar, pues el comportamiento que definen refina, o altera, el comportamiento de la biblioteca original; o bien la hace disponible para otra tecnología o lenguaje de programación. Las librerías utilizadas para el desarrollo tanto front-end como back-end de la aplicación han sido: • MaterializeCss: Es un moderno framework para CSS basado en el Material Design de Google. Esta librería facilita en gran medida el trabajo de maquetación y colocación de elementos en HTML gracias a módulos ya implementados que siguen el estándar responsive. • AngularJS Material: Angular JS Material es un framework de interfaces de usuario. Este proyecto proporciona un conjunto de componentes de interfaz de usuario reutilizables, probados y accesibles basados en material design. Pencil Project Software libre de creación drag n’ drop de prototipos no funcionales. Permite la generación de interfaces de usuario complejas. UML El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el Object Management Group (OMG). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados. Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. StarUML Software de modelado bajo el estándar UML utilizado para el diseño de los diagramas de casos de uso. 1.7.2. Recursos hardware Álvaro Romero Perdomo | 25 Durante el desarrollo del proyecto se utilizaron diferentes equipos (con diferentes sistemas operativos) para comprobar el comportamiento del portal de administración en diferentes navegadores. Estos equipos utilizados fueron tres fundamentalmente: • Portátil HP Pavilion g6 con sistema operativo Ubuntu 16.04 y navegadores Mozilla Firefox y Google Chrome. • Ordenador de sobremesa con sistema operativo Windows 10 y navegadores Mozilla Firefox y Google Chrome. • Portátil Macbook pro 15' con sistema operativo MacOS Sierra y navegador Google Chrome. Álvaro Romero Perdomo | 32 Asimismo, se desea el desarrollo de una aplicación móvil para los empleados que debe darles la posibilidad de: • Iniciar sesión en ella y tener acceso a las obras que tengan asignadas. • Consultar el estado de realización de la misma mediante la lista de tareas pendientes. • Cambiar el estado de una tarea perteneciente a la obra. • Adjuntar información relativa a la realización de una tarea dentro de la obra que permita la certificación de la misma. • Crear nuevas tareas. • Gestión de incidencias relativas a la obra que permitan la comunicación bidireccional entre administrador y empleado. • La aplicación debe ser multiplataforma. Posteriormente a la segunda reunión y debido al gran número de requisitos ya especificados, decidimos acotar qué aspectos abarcaría nuestro proyecto. Para ello priorizamos en los requisitos y casos de uso más importantes, decidimos generar un diagrama de casos de uso, así como un documento asociado que nos permitiera visualizarlos de manera más sencilla y nos garantizara una visión global del proyecto. 2.1.6. Identificación de actores principales del sistema Durante el proceso de análisis identificamos los siguientes actores que interactuarían con el sistema. Actor Descripción Administrador Usuario principal del sistema es capaz de crear obras y asignar empleados a ella, además puede certificar las obras. También puede dar de alta a empleados dentro del sistema a través del panel de administración. Empleado Usuario principal de la aplicación móvil del proyecto dónde podrá actualizar el estado de una obra mediante la realización de tareas que tenga asignadas. Tabla 4. Actores principales del sistema Álvaro Romero Perdomo | 33 2.1.7. Especificación y diagramas de casos de uso A continuación, mostramos la tabla de especificación de los casos de uso que, a través de la etapa de análisis creemos que deberían cumplir las aplicaciones del proyecto para resolver el problema en su totalidad. Actor principal Casos de uso Administrador 1. Iniciar sesión en panel de administración Administrador 2. Crear obra Administrador 3. Gestionar obra 3.1. Gestionar tareas 3.1.1. Añadir tarea 3.1.2. Eliminar tarea 3.1.3. Editar tarea 3.1.3.1. Añadir subtarea 3.2. Importar tarea 3.3. Gestionar material 3.3.1. Añadir material 3.3.2. Eliminar material 3.4. Importar material 3.5. Gestionar adjuntos 3.5.1. Añadir adjunto 3.5.2. Eliminar adjunto 3.6. Cambiar estado (obra) 3.7. Certificar obra Administrador 4. Registrar empleados Administrador 5. Gestionar empleados 5.1. Editar empleado 5.2. Eliminar empleado 5.3. Notificar empleado 5.4. Visualizar empleado Empleado 6. Iniciar sesión en la app Empleado 7. Visualizar obra Empleado 8. Gestionar archivos adjuntos a tarea 8.1. Adjuntar archivo adjunto a tarea 8.2. Eliminar archivo adjunto a tarea Empleado 9. Añadir tarea a obra Empleado 10. Cambiar estado (tarea) Empleado 11. Notificar incidencia Tabla 5. Tabla de especificación de los casos de uso Como hemos dicho anteriormente, por cuestión de limitación en el número de horas del TFT, debimos acotar qué casos de uso no se iban a implementar durante el desarrollo del proyecto, estando estos subrayados en la tabla 2.1.3. A modo de ilustración también hemos querido añadir el caso de uso del administrador, Gestionar empleados, aunque la especificación y diagrama completos puede encontrarse en el anexo I. Álvaro Romero Perdomo | 34 Nombre Gestionar empleados ID 5 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder editar/borrar empleados del sistema. Descripción: El ADMINISTRADOR puede editar la información de un empleado ya existente, así como eliminar el mismo si fuera necesario. Precondición: El ADMINISTRADOR debe estar autenticado y existir al menos un empleado a editar/borrar en el sistema. Postcondición: 1. La información del empleado queda actualizada. 2. El empleado queda eliminado del sistema. Flujo normal: 1. El ADMINISTRADOR accede al portal de administración. 2. El ADMINISTRADOR accede a la vista de los empleados. 3. El ADMINISTRADOR selecciona el empleado que desea gestionar. a. Editar empleado (5.1). b. Borrar empleado (5.2). c. Notificar empleado (5.3). d. Visualizar empleado (5.4). Flujo alternativo: Tabla 6. Tabla de especificación del caso de uso "Gestionar empleados" Álvaro Romero Perdomo | 35 2.2. Diseño La etapa de diseño se describe como el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistemas con los suficientes detalles como para permitir su desarrollo. El objetivo del diseñador es producir un modelo o representación de una entidad que será construida más adelante. 2.2.1. Componentes del sistema Durante la fase de análisis identificamos dos grandes módulos software que comprenderían el proyecto, por un lado, el portal de administración y por otro lado una aplicación móvil. Estos dos módulos estarían alimentados de una única base de datos y ambos harían labores de lectura y escritura sobre la misma, por lo que decidimos que se hacía necesaria la creación de una API REST utilizando para ello el stack MEAN. De este modo también cubriríamos la necesidad de aprendizaje de nuevas tecnologías de desarrollo web que teníamos para este proyecto. De esta manera definimos para el proyecto una arquitectura cliente-servidor. Esta arquitectura se divide en dos partes claramente diferenciadas, la primera es la parte del servidor y la segunda la de un conjunto de clientes (siendo dos los clientes en este caso: portal de administración y aplicación para empleados). Normalmente el servidor es una máquina bastante potente que actúa de depósito de datos y funciona como un sistema gestor de base de datos (SGBD). Por otro lado, los clientes suelen ser estaciones de trabajo que solicitan varios servicios al servidor. Ambas partes deben estar conectadas entre sí mediante una red. En la ilustración 2 se muestra una representación gráfica de este tipo de arquitectura: Ilustración 2. Representación gráfica de una arquitectura cliente-servidor El cliente realiza peticiones a un servidor y éste le responde ofreciéndole un determinado servicio. Álvaro Romero Perdomo | 36 2.2.2. Utilización del patrón de diseño Modelo – Vista – Controlador (MVC) Desde el principio de la etapa de diseño decidimos que íbamos a construir tanto el portal de administración como la aplicación destinada a los empleados. Para ello, se haría uso del stack MEAN, por lo que para el lado del cliente construiríamos las aplicaciones en AngularJS implementando éste el patrón de diseño Model View Controller (MVC) en el desarrollo de aplicaciones web. En el siguiente diagrama podemos observar la interacción entre los diferentes componentes. Ilustración 3. Interacción de componentes con AngularJS 2.2.3. Desarrollo híbrido con Ionic Para el desarrollo de la aplicación móvil decidimos optar por un desarrollo híbrido porque, aparte de permitirnos cumplir los requisitos del proyecto (compatibilidad en varios dispositivos), cubríamos así la necesidad de aprendizaje del desarrollo de aplicaciones móviles. Además, consideramos que el aprendizaje de las tecnologías web sería mucho más rápido que el aprendizaje de tecnologías necesarias para el desarrollo nativo de las aplicaciones, por lo que éste fue un motivo más que nos hizo decidirnos por un desarrollo híbrido para la aplicación móvil. Álvaro Romero Perdomo | 37 2.2.4. Estructura y entidades de la base de datos Las bases de datos en MongoDB están formadas por esquemas en lugar de por tablas como en una base de datos relacional común como puede ser MySQL. Siguiendo esta nomenclatura y a través del siguiente diagrama, nuestra base de datos está formada por los siguientes esquemas. Ilustración 4. Diagrama de entidades de la base de datos Aunque en un principio no nos lo habíamos planteado, decidimos incluir en la base de datos el esquema Equipment, de manera que el sistema pudiera almacenar el material que se iba añadiendo a las diferentes obras y éste podría ser reutilizado, ya que se repetía con bastante frecuencia entre las diferentes obras. Debemos añadir que el driver Mongoose para NodeJS facilitó en gran medida la labor de conexión con la base de datos, permitiéndonos trabajar en un entorno mucho más cercano a la orientación de objetos y haciendo que la traducción en la base de datos fuera instantánea. 2.2.5. Arquitectura del portal de administración en AngularJS Como hemos comentado anteriormente, decidimos desarrollar el proyecto bajo MEAN Stack por lo que implementamos el panel de administración como una aplicación en AngularJS que se conectaba a una API construida en NodeJS. Álvaro Romero Perdomo | 38 Antes de comenzar a trabajar con Angular, decidimos cómo íbamos a organizar la aplicación y qué responsabilidades iba a tener cada fichero. Para ello, consultamos las formas más comunes en las que se suelen dividir las aplicaciones en AngularJS y escogimos el Patrón Específico, que se puede observar a continuación y que se caracteriza por separar los servicios y los controladores de un mismo elemento en distintas carpetas, consiguiendo así una separación a su vez de las responsabilidades de cada fichero. Ilustración 5. Jerarquía de ficheros de una aplicación en AngularJS Álvaro Romero Perdomo | 39 2.3. Implementación Es el proceso de instalar equipos o software nuevo, como resultado de un análisis y diseño previo como resultado de la situación o mejoramiento de la forma de llevar a cabo un proceso automatizado. Al implementar un sistema lo primero que debemos hacer es asegurarnos qué el sistema sea operacional o que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios puedan operarlos. Antes de comenzar la etapa de implementación decidimos dividirla en tres grandes módulos: 1. Desarrollo de API REST en MongoDB y NodeJS que permita el almacenamiento de los datos y el intercambio de información entre las diferentes aplicaciones. 2. Desarrollo de un panel de administración que permita la generación de obras, tareas, empleados y material asociado. 3. Desarrollo de una aplicación móvil que permita a los empleados la consulta de la obra que tengan asignada, así como el envío de información relativa a las tareas. En este módulo vamos a tratar, sobre todo, el desarrollo de la API Rest y el panel de administración. Habiendo sido el primero de los dos desarrollado de manera conjunta y el segundo de manera individual. En la primera etapa del desarrollo comenzamos con la configuración del servidor de NodeJS para la API REST y la creación de la base de datos. Veremos cómo generamos las entidades y sus campos en MongoDB a través de su driver para NodeJS, Mongoose. También mostraremos la respuesta de nuestra API REST siendo sometida a interrogaciones HTTP. En la segunda etapa del desarrollo y ya con la API REST desarrollada, pasamos a la implementación del portal de administración, dividida, fundamentalmente, en tres partes: 1. Sistema de control de usuarios (signup, login y logout). 2. Visualización de contenido de la base de datos (obras, empleados, tareas). 3. Gestión del contenido en la base de datos (creación, edición y eliminación). Álvaro Romero Perdomo | 40 2.3.1. Desarrollo de la API Rest en NodeJS y MongoDB La primera etapa de la implementación del proyecto consistió en el desarrollo de una API Rest que ofreciera un servicio web a ser consumido tanto por un panel de administración como por una aplicación móvil. A continuación, explicaremos en qué consistió dicho proceso de desarrollo. Primeros pasos del desarrollo de la API Rest (instalación de dependencias y configuración del servidor NodeJS) Como todas estas tecnologías eran nuevas para nosotros, decidimos empezar desde abajo hacia arriba, por lo que una vez generado el directorio del proyecto y habiendo iniciado el repositorio Git, nos dispusimos a instalar NodeJS. Ya finalizada la instalación de NodeJS en nuestro ordenador nos dispusimos a generar el fichero package.json, que recoge la metainformación relacionada con el proyecto así como las dependencias que irán siendo necesarias a lo largo del desarrollo. A continuación podemos ver la versión inicial del fichero package.json. Ilustración 6. Versión inicial del fichero package.json Una vez especificadas las dependencias a través del fichero package.json procedimos a ejecutar el gestor de paquetes de NodeJS, npm (node package manager). Ya instaladas las dependencias de la versión inicial de nuestro proyecto podíamos empezar a configurar el servidor NodeJS a través del fichero server.js importando las dependencias necesarias para el arranque del mismo, definiendo las rutas de acceso HTTP que va a tener nuestro servidor e indicándole un puerto por el que escuchará la aplicación, en nuestro caso el tres mil. Una vez lanzado el servidor NodeJS podríamos observar el siguiente mensaje haciendo una petición GET al servidor a través del puerto tres mil. Álvaro Romero Perdomo | 41 Ilustración 7. Petición GET al servidor en el puerto 3000 Creando los modelos de nuestra API REST A la hora de realizar nuestro modelado de datos para la API REST hemos utilizando el driver de MongoDB para NodeJS, Mongoose. Hemos decidido usarlo porque aparte de estructurar de mejor manera el acceso a la base de datos por parte del servidor, también nos permite una mejora en el código y una mayor modularización del mismo. A continuación, podemos observar el fichero resumido del esquema de Mongoose propuesto para el modelado de las obras. Ilustración 8. Fichero resumido del esquema de Mongoose para el modelado de las obras Estos ficheros asociados al modelo de la aplicación decidimos introducirlos en un nuevo directorio para el proyecto, models. Por lo que pronto nos dimos cuenta de que debíamos optar Álvaro Romero Perdomo | 48 3. Bloque 3. Conclusiones y Trabajos Futuros 3.1. Conclusiones y trabajos futuros Como colofón, en este bloque comentaremos, qué ha supuesto para nosotros el desarrollo del proyecto, si hemos cumplido nuestras expectativas formativas, y qué conclusiones extraemos del trabajo en equipo derivado de la compartición del proyecto entre dos alumnos. Finalmente, indicaremos qué funcionalidades han quedado pendientes de desarrollar a causa de la limitación temporal y una batería de propuestas de mejora a tener en cuenta en futuras iteraciones del desarrollo. 3.1.1. Conclusiones sobre el desarrollo del proyecto Este proyecto, en primero lugar, ha supuesto un reto a nivel personal de mayor nivel al esperado en el primer momento, ya que es, bajo mi punto de vista, el entorno más próximo al profesional en el que se puede encontrar un alumno de universidad, puesto que debe él mismo realizar el desarrollo completo de un proyecto desde la etapa de análisis hasta la etapa de documentación y donde he podido comprobar todas las etapas que forman el desarrollo de software. Por otro lado, desde el punto de vista formativo, me ha permitido la adquisición de nuevos conocimientos relacionados con las tecnologías de desarrollo de aplicaciones web, tales como el stack MEAN basado en Javascript y utilizar librerías punteras en el desarrollo de interfaces de usuario como AngularJS Material. No obstante, para el desarrollo del proyecto he puesto en práctica gran parte del amplio conocimiento adquirido dentro de la titulación universitaria, como: • Diseño y creación de bases de datos. • Análisis, diseño e implementación de aplicaciones web. • Conocimiento de las distintas etapas del desarrollo de software propuestas por la Ingeniería del Sofware. • Protección y seguridad de entornos web. • Diseño de interfaces de usuario. • Arquitectura del software. Este proyecto, además, nos ha permitido tener contacto con un problema real y nos ha permitido aprender diferentes estrategias eficaces de resolución ante ellos, convirtiéndonos así en futuros profesionales más preparados de cara al entorno laboral y profesional. Álvaro Romero Perdomo | 49 Conclusiones derivadas de la compartición del trabajo fin de título Con respecto al trabajo en equipo derivado del desarrollo del proyecto, debo añadir que me ha permitido experimentar cómo funciona el intercambio de información entre diferentes miembros de un equipo de desarrollo y qué herramientas de organización y mantenimiento del código existen actualmente en el mercado, tales como GitHub, que nos resultó de inmensa ayuda y nos permitió, aparte de un mantenimiento eficiente de nuestro propio código, trabajar de manera individual durante el desarrollo. Terminada la fase de análisis y diseño definimos perfectamente las tareas que iba a llevar cada uno durante el desarrollo y esto nos permitió trabajar de manera independiente durante toda la segunda mitad de la duración del proyecto. No obstante, siempre pude contar con el apoyo de mi compañero, así como de los tutores que se disponían a resolver cualquier problema que se me presentara. Dicho esto, el proyecto ha permitido poner en práctica nociones adquiridas durante la carrera acerca del trabajo en equipo y me ha acercado a un posible entorno laboral, donde compartir un proyecto con un equipo profesional. Resultados obtenidos En este apartado haremos un breve recorrido por los objetivos propuestos para este proyecto y veremos si estos se han visto cubiertos de manera satisfactoria. Como citamos en el apartado de objetivos del proyecto, la comunicación entre los empleados de las obras y el administrador de las mismas se realizaba de manera poco ortodoxa, resultando, en muchos casos en errores en la transmisión de la información o en la pérdida de la misma. Con la creación de la aplicación para los empleados de las obras, este objetivo se ha visto cubierto ya que permite al empleado guardar información de las tareas que vaya realizando en una obra de manera inmediata y eficaz. Además, mediante la creación de un panel de administración, el encargado de la obra puede visualizar en todo momento el estado actual de la obra y asignar de manera efectiva empleados a una determinada obra. Todo esto ha supuesto un avance para la empresa encargada de la instalación de la fibra óptica, tanto en la manera de comunicarse internamente con sus empleados, como en la capacidad de certificación de las obras una vez éstas han finalizado, no dando lugar a pérdidas de información que perjudicaran la certificación de la obra. Álvaro Romero Perdomo | 50 3.1.2. Trabajos futuros A pesar de que creemos que los requisitos principales para resolver el problema propuesto han quedado satisfechos a través de la realización del proyecto, es cierto que, con motivo de la limitación temporal que supone el trabajo fin de grado, han quedado algunos flecos sueltos a realizar en futuras iteraciones del proyecto. A continuación, hacemos referencia a ellos: • Automatización del proceso de certificación a través del panel de administración. • Importación de tareas a través de un Excel dado. • Importación de material a través de un Excel dado. • Auto acotación y trazado de planos dados. • Chat o comunicación directa entre empleado y administrador a través de ambas aplicaciones. • Cálculo de estadísticas relacionadas con el rendimiento del empleado. • Sistema de almacenamiento temporal en la aplicación móvil para la actualización de la base de datos con posterioridad. • Mejora del diseño de algunas vistas. • Publicar el servicio en un entorno web accesible externamente. • Envío a los empleados de la geolocalización de las obras a través de la API de Google Maps. Asimismo, queríamos expresar una serie de propuestas de mejora que se podrían incluir también en sucesivas iteraciones del proyecto, pero que son accesorias a la resolución del problema principal propuesto para éste: • Abstracción que permita la vinculación de la aplicación a varias empresas instaladoras simultáneamente. • Actualizar el portal de administración a Angular 2. • Implementación de estadísticas relacionadas con el volumen de datos manejado por la aplicación. • Envío de emails de notificación a través del panel de administración a otras compañías para notificar incidencias. • Implementación de estadísticas relacionadas al flujo económico derivado de la certificación de las obras. Álvaro Romero Perdomo | 51 4. Bloque 4. Fuentes de Información 4.1. Fuentes de información del Bloque 1. Introducción y contextualización • https://www.adslzone.net/2016/04/01/asi-queda-la-cobertura-despliegue-actual-lafibra-optica-espana/ • https://es.wikipedia.org/wiki/Atom_(editor_de_textos) • https://es.wikipedia.org/wiki/JavaScript • http://edumatica.ing.ula.ve/edumatica/Teleclases/Tecniweb/Ingenieria%20Web/Telec lase/Ejecucion/Practicas/JavaScript/Paginas/CaracteristicasGenerales.htm • https://es.wikipedia.org/wiki/Node.js • https://es.wikipedia.org/wiki/AngularJS • https://es.wikipedia.org/wiki/Biblioteca_(inform%C3%A1tica) • https://es.wikipedia.org/wiki/MongoDB • http://materializecss.com/ • https://en.wikipedia.org/wiki/Express.js • http://expressjs.com/es/ • http://www.mongodbspain.com/es/2014/08/17/mongodb-characteristics-future/ • https://es.wikipedia.org/wiki/JSON • https://es.wikipedia.org/wiki/Git • http://aprendegit.com/que-es-git-flow/ • https://es.wikipedia.org/wiki/HTML • https://es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada • https://es.wikipedia.org/wiki/GitHub • https://es.wikipedia.org/wiki/Ley_Org%C3%A1nica_de_Protecci%C3%B3n_de_Datos_ de_Car%C3%A1cter_Personal_(Espa%C3%B1a) • https://material.angularjs.org/latest/ 4.2. Fuentes de información del Bloque 2. Desarrollo del proyecto • http://vilmarygalindez.blogspot.com.es/2011/02/fases-del-diseno.html • https://silkeguabylopez20.wordpress.com/2013/05/01/desarrollo-de-prototipos/ • http://equipo.altran.es/desarrollo-aplicaciones-hibridas-moviles-ionic-framework/ • https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador • https://carlosazaustre.es/blog/como-crear-una-api-rest-usando-node-js/ • https://desarrolloweb.com/articulos/uso-bower-gestor-dependencias.html • https://desarrolloweb.com/articulos/arquitectura-cliente-servidor.html • https://www.genbetadev.com/desarrollo-web/angular-js-modulos-y-arquitectura Álvaro Romero Perdomo | 52 5. Bloque 5. Anexos 5.1. Anexo 1. Casos de uso A continuación, presentamos el diagrama completo de casos de uso del proyecto donde se muestran todas las interacciones que pueden realizar los diferentes actores con las aplicaciones, así como el documento de especificación de todos los casos de uso del proyecto. Ilustración 15. Diagrama de casos de uso completo Álvaro Romero Perdomo | 53 Nombre Iniciar sesión en el panel de administración ID 1 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere acceder al panel de administración. Descripción: El ADMINISTRADOR, en el panel de administración, accede al sistema haciendo uso de sus credenciales. Precondición: El ADMINISTRADOR debe estar registrado en el sistema previamente. Postcondición: El ADMINISTRADOR es redirigido al panel de administración. Flujo normal: 1. El ADMINISTRADOR abre el panel de administración web. 2. El ADMINISTRADOR introduce sus credenciales (usuario y contraseña). 3. El ADMINISTRADOR es conducido al panel principal de administración. Flujo alternativo: 2.a. Credenciales no válidas: 2.a.1. El sistema muestra un mensaje de error. Tabla 7. Caso de uso: Iniciar sesión en el panel de administración Álvaro Romero Perdomo | 54 Nombre Crear obra ID 2 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder crear obras. Descripción: El ADMINISTRADOR crea una obra para asignarla, al menos, a un empleado. Precondición: 1. El ADMINISTRADOR debe estar autenticado, acceder al panel de administración y debe pulsar el botón “Crear obra”. Postcondición: La obra se guarda en la base de datos y es accesible para el EMPLEADO desde el panel de trabajo de la aplicación móvil y para el ADMINISTRADOR desde el panel de principal. Extensiones: 1. Añadir tarea (3.1.1) 2. Importar tarea (3.2) 3. Añadir material (3.3.1) 4. Importar material (3.4) 5. Añadir adjunto (3.5.1) 6. Cambiar estado de la obra (3.6) Flujo normal: 1. El ADMINISTRADOR accede al formulario de creación de obras a través de la interfaz. 2. El ADMINISTRADOR introduce los datos requeridos en el formulario básico de creación de una obra y al terminar pulsa en “Continuar”. 3. El sistema guarda esa información básica en la base de datos. 4. El ADMINISTRADOR es redirigido a la gestión/edición de la obra. Esta acción involucra los siguientes casos de uso: a. Añadir tarea (3.1.1) b. Importar tareas (3.2) c. Añadir material (3.3.1) d. Importar material (3.4) e. Añadir adjunto (3.5.1) f. Cambiar estado de la obra (3.6) 5. El ADMINISTRADOR pulsa el botón “Finalizar”. Flujo alternativo: Tabla 8. Caso de uso: Crear obra Álvaro Romero Perdomo | 55 Nombre Gestionar obra ID 3 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder gestionar las obras. Descripción: El ADMINISTRADOR edita una obra ya creada. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente. Postcondición: La información de la obra es modificada. Flujo normal: 1. El ADMINISTRADOR accede al portal web y pulsa sobre una de las obras del listado. 2. El ADMINISTRADOR es conducido a la vista de los detalles de la obra. 3. El ADMINISTRADOR pulsa el botón “Modificar obra” que aparece en esta vista y accede al formulario de edición de obras a través de la interfaz. 4. El ADMINISTRADOR modifica/añade los datos requeridos en el formulario de edición de obras. Esta acción involucra los siguientes casos de uso: a. Gestionar tareas (3.1) b. Importar tareas (3.2) c. Gestionar material (3.3) d. Importar material (3.4) e. Gestionar adjuntos (3.5) f. Cambiar estado (3.6) g. Añadir subtarea (3.7) 5. El ADMINISTRADOR pulsa el botón “Guardar”. Flujo alternativo: 4.a. Errores de validación de campos: 4.a.1. Se muestra un mensaje de error al ADMINISTRADOR a través de la interfaz. Tabla 9. Caso de uso: Gestionar obra Álvaro Romero Perdomo | 56 Nombre Gestionar tareas ID 3.1 Creado por Álvaro Romero Perdomo Fecha 27/01/2017 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder gestionar las tareas de una obra. Descripción: El ADMINISTRADOR puede crear, editar o eliminar tareas pertenecientes a una obra a través del diálogo de gestionar tarea o en el momento de creación de la obra. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación de obras. Postcondición: La información de la obra relativa a la tarea se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación/edición de obras. 2. El ADMINISTRADOR pulsa sobre el botón “Añadir tarea”. 3. El ADMINISTRADOR completa los campos del formulario requeridos. 4. El ADMINISTRADOR pulsa el botón “Aceptar” y la tarea es añadida a la lista de tareas. a. Los pasos 2-4 pueden repetirse tantas veces como tareas necesite añadir el ADMINISTRADOR. 5. El ADMINISTRADOR puede editar esa tarea si lo desea, eliminarla o continuar si lo prefiere. 6. El ADMINISTRADOR pulsa el botón “Siguiente” y es dirigido al siguiente paso del formulario de creación de obras. Flujo alternativo: 3.a. Errores de validación de campos: 3.a.1. Se muestra un mensaje de error al ADMINISTRADOR a través de la interfaz. Tabla 10. Gestionar tareas Álvaro Romero Perdomo | 57 Nombre Añadir tarea ID 3.1.1 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere añadir tareas a una obra. Descripción: El ADMINISTRADOR mediante el formulario de creación/edición de obras añade tareas a la misma. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación de obras. Postcondición: La tarea se añade a la obra y se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación de obras o en el de edición de obras. 2. El ADMINISTRADOR pulsa sobre el botón “Añadir tarea”. 3. El ADMINISTRADOR completa los campos del formulario requeridos. 4. El ADMINISTRADOR pulsa el botón “Aceptar” y la tarea es añadida a la lista de tareas. a. Los pasos 2-4 pueden repetirse tantas veces como tareas necesite añadir el ADMINISTRADOR. 5. El ADMINISTRADOR pulsa el botón “Siguiente” y es dirigido al siguiente paso del formulario de creación de obras. Flujo alternativo: 3.a. Errores de validación de campos: 3.a.1. Se muestra un mensaje de error al ADMINISTRADOR a través de la interfaz. Tabla 11. Caso de uso: Añadir tarea Álvaro Romero Perdomo | 64 Nombre Eliminar material ID 3.3.2 Creado por Álvaro Romero Perdomo Fecha 27/01/2017 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere eliminar material de una obra. Descripción: El ADMINISTRADOR mediante el formulario de creación o edición de obras elimina material asociado a la misma. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación o edición de obras. Postcondición: La información de la obra se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación o edición de obras. 2. El ADMINISTRADOR pulsa sobre el botón “Eliminar material”. 3. El ADMINISTRADOR pulsa el botón “Finalizar” y el material asociado a la obra se elimina de la base de datos. Flujo alternativo: Tabla 18. Caso de uso: Editar material Álvaro Romero Perdomo | 65 Nombre Importar material ID 3.4 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 09/02/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere importar material a una obra. Descripción: El ADMINISTRADOR mediante el formulario de creación o edición de obras importa materiales a la misma. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación de obras. Postcondición: La información de la obra se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación de obras. 2. El ADMINISTRADOR pulsa sobre el botón “Importar material”. 3. El ADMINISTRADOR selecciona un archivo Excel (.xls o .csv) de su equipo donde se encuentran los materiales que quiere importar. 4. El sistema analiza el archivo y automáticamente añade los materiales encontrados a la lista de materiales. 5. El ADMINISTRADOR puede seguir añadiendo material como se describe en el caso de uso “3.3.1. Añadir material”. 6. El ADMINISTRADOR pulsa el botón “Siguiente” y es dirigido al siguiente paso del formulario de creación/edición de obras. Flujo alternativo: Tabla 19. Caso de uso: Importar material Álvaro Romero Perdomo | 66 Nombre Gestionar adjuntos ID 3.5 Creado por Alejandro Pérez Martín Fecha 27/01/2017 Modif. por Alejandro Pérez Martín Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere gestionar archivos adjuntos a una obra. Descripción: El ADMINISTRADOR mediante el formulario de creación o edición de obras gestiona los archivos adjuntos a la misma. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación o edición de obras. Postcondición: La información de la obra se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación o edición de obras. 2. El ADMINISTRADOR accede al módulo de edición de adjuntos de una obra donde puede añadir un nuevo archivo o eliminar los existentes. 3. El ADMINISTRADOR pulsa el botón “Finalizar” y la información de la obra se almacena en la base de datos. Flujo alternativo: Tabla 20. Caso de uso: Gestionar adjuntos Álvaro Romero Perdomo | 67 Nombre Añadir adjunto ID 3.5.1 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere añadir archivos adjuntos a una obra. Descripción: El ADMINISTRADOR mediante el formulario de creación o edición de obras añade archivos adjuntos a la misma. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación o edición de obras. Postcondición: La información de la obra se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación o edición de obras. 2. El ADMINISTRADOR pulsa sobre el botón “Añadir adjunto”. 3. El ADMINISTRADOR selecciona un archivo de su equipo que quiera adjuntar a la obra. 4. El sistema adjunta el archivo si es de un formato válido. a. Los pasos 2-4 pueden repetirse tantas veces como archivos adjuntos necesite añadir el ADMINISTRADOR. 5. El ADMINISTRADOR pulsa el botón “Siguiente” y es dirigido al siguiente paso del formulario de creación/edición de obras. Flujo alternativo: Tabla 21. Caso de uso: Añadir adjunto Álvaro Romero Perdomo | 68 Nombre Eliminar adjunto ID 3.5.2 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Alejandro Pérez Martín Fecha modif. 27/01/2017 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere eliminar archivos adjuntos de una obra. Descripción: El ADMINISTRADOR mediante el formulario de creación o edición de obras elimina archivos adjuntos a la misma. Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente o estar el ADMINISTRADOR en el formulario de creación de obras. Postcondición: La información de la obra se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el formulario de creación o edición de obras. 2. El ADMINISTRADOR accede a la pestaña de edición de adjuntos a esa obra. 3. El ADMINISTRADOR pulsa sobre el botón “Eliminar adjunto”. a. El paso 3 se puede repetir tantas veces como archivos adjuntos necesite eliminar el ADMINISTRADOR. 4. El ADMINISTRADOR pulsa el botón “Finalizar” y la información de la obra se actualiza en la base de datos. Flujo alternativo: Tabla 22. Caso de uso: Eliminar adjunto Álvaro Romero Perdomo | 69 Nombre Cambiar estado de una obra ID 3.6 Creado por Alejandro Pérez Martín Fecha 22/10/2016 Modif. por Alejandro Pérez Martín Fecha modif. 22/10/2016 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere cambiar el estado de una obra. Descripción: El ADMINISTRADOR mediante un desplegable tendrá la opción de cambiar el estado en que se encuentra una obra (Pendiente, En curso y Finalizada). Precondición: El ADMINISTRADOR debe estar autenticado y la obra debe estar creada previamente. Postcondición: La información de la obra se modifica en la base de datos. Flujo normal: 1. El ADMINISTRADOR se encuentra en el listado de obras. 2. El ADMINISTRADOR pulsa el campo desplegable “Estado” de una obra. 3. El ADMINISTRADOR selecciona uno de los estados de la obra. 4. El SISTEMA automáticamente cambia el valor del estado de la obra en la base de datos Flujo alternativo: 3.a. Si el estado seleccionado es “Finalizada” la obra se moverá automáticamente al listado de obras terminadas. Tabla 23. Caso de uso: Cambiar estado de una obra Álvaro Romero Perdomo | 70 Nombre Certificar obra ID 3.7 Creado por Alejandro Pérez Martín Fecha 13/12/2016 Modif. por Alejandro Pérez Martín Fecha modif. 13/12/2016 Actor principal: ADMINISTRADOR Personal involucrado o intereses: ADMINISTRADOR: quiere poder certificar una obra. Descripción: El ADMINISTRADOR a través de la vista de la obra tendrá acceso a la certificación por medio de un botón. Precondición: El ADMINISTRADOR debe estar autenticado, la obra debe estar creada y finalizada previamente. Postcondición: Se genera un fichero de certificación. Flujo normal: 1. El ADMINISTRADOR se encuentra en el listado de obras. 2. El ADMINISTRADOR selecciona una obra que desee certificar. 3. El ADMINISTRADOR pulsa el botón de certificar obra. 4. El SISTEMA genera los ficheros asociados a la certificación. Flujo alternativo: 3.a. Si el estado seleccionado no es “Finalizada”, se le mostrará un mensaje al usuario indicando que no puede certificar la obra. Tabla 24. Caso de uso: Certificar obra Álvaro Romero Perdomo | 71 Nombre Registrar empleados ID 4 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder registrar empleados en el sistema. 2. EMPLEADO: quiere que el ADMINISTRADOR pueda darle de alta en el sistema y así poder registrar su actividad como EMPLEADO. Descripción: El ADMINISTRADOR puede registrar empleados de distintos perfiles de empleado que posteriormente podrá editar o eliminar. Estos empleados podrán ser asignados a obras por parte del administrador y éste podrá asimismo realizar un seguimiento profesional del empleado. Precondición: El ADMINISTRADOR debe estar autenticado. Postcondición: El usuario queda insertado en el sistema. Flujo normal: 1. El ADMINISTRADOR accede al portal de administración. 2. El ADMINISTRADOR accede al formulario de registro de empleado a través de la interfaz. 3. El ADMINISTRADOR introduce los datos requeridos en el formulario de registro de empleado. 4. El ADMINISTRADOR introduce, entre los datos requeridos, el rol del empleado. 5. El empleado queda registrado en el sistema. Flujo alternativo: 3.a. Errores de validación de campos: 3.a.1. Se muestra un mensaje de error al ADMINISTRADOR a través de la interfaz. 3.a.2. Se permite al ADMINISTRADOR volver a rellenar los campos erróneos. Tabla 25. Caso de uso: Registrar empleados Álvaro Romero Perdomo | 72 Nombre Gestionar empleados ID 5 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: ADMINISTRADOR Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder editar/borrar empleados del sistema. Descripción: El ADMINISTRADOR puede editar la información de un empleado ya existente, así como eliminar el mismo si fuera necesario. Precondición: El ADMINISTRADOR debe estar autenticado y existir al menos un empleado a editar/borrar en el sistema. Postcondición: 1. La información del empleado queda actualizada. 2. El empleado queda eliminado del sistema. Flujo normal: 1. El ADMINISTRADOR accede al portal de administración. 2. El ADMINISTRADOR accede a la vista de los empleados. 3. El ADMINISTRADOR selecciona el empleado que desea gestionar. a. Editar empleado (5.1). b. Borrar empleado (5.2). c. Notificar empleado (5.3). d. Visualizar empleado (5.4). Flujo alternativo: Tabla 26. Caso de uso: Gestionar empleados Álvaro Romero Perdomo | 73 Nombre Editar empleado ID 5.1 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: ADMINISTRADOR Personal involucrado o intereses: ADMINISTRADOR: quiere poder editar empleados del sistema. Descripción: El ADMINISTRADOR puede editar la información de un empleado ya existente. Precondición: El ADMINISTRADOR debe estar autenticado y existir al menos un empleado en el sistema. Postcondición: 1. La información del empleado queda actualizada. Flujo normal: 1. El ADMINISTRADOR accede al portal de administración. 2. El ADMINISTRADOR accede a la vista de los empleados. 3. El ADMINISTRADOR selecciona el empleado que desea editar. 4. El ADMINISTRADOR accede al formulario de edición del empleado a través de la interfaz. 5. El ADMINISTRADOR introduce los campos que desea editar del empleado. 6. El ADMINISTRADOR finaliza la edición de la información del empleado. 7. La información queda actualizada en el sistema. Flujo alternativo: 5.1. Errores de validación de campos: 5.1.a. Se muestra un mensaje de error al ADMINISTRADOR a través de la interfaz. 5.1.b. Se permite al ADMINISTRADOR volver a rellenar los campos erróneos. Tabla 27. Caso de uso: Editar empleado Álvaro Romero Perdomo | 80 Nombre Adjuntar archivo ID 8.1 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: EMPLEADO Personal involucrado o intereses: 1. ADMINISTRADOR: quiere poder disponer de información de respaldo de la realización de las tareas por parte de los empleados. 2. EMPLEADO: quiere poder adjuntar información de respaldo de la realización de sus tareas. Descripción: El EMPLEADO puede adjuntar información de respaldo de la realización de sus tareas a través de la aplicación. Precondición: El sistema debe tener un empleado, una obra y ésta debe estar asignada a dicho empleado. Además, la obra debe tener al menos una tarea de la que se quiera adjuntar información de respaldo. Postcondición: 1. La información queda registrada en el sistema. Flujo normal: 1. El EMPLEADO accede a la aplicación móvil. 2. El EMPLEADO accede a la pantalla principal de la aplicación (dashboard). 3. Al EMPLEADO se le presentan las obras que tiene asignadas. 4. El EMPLEADO accede a la obra que elija a través de la interfaz. 5. El EMPLEADO accede al módulo correspondiente a las tareas de dicha obra. 6. El EMPLEADO accede a la tarea que desea. 7. El EMPLEADO selecciona adjuntar archivo a tarea. 8. El EMPLEADO selecciona el archivo a adjuntar de su sistema operativo desde el diálogo de adjuntar archivo. 9. El archivo adjunto asociado a la tarea queda registrado en el sistema. Flujo alternativo: Tabla 34. Caso de uso: Adjuntar archivo Álvaro Romero Perdomo | 81 Nombre Eliminar archivo de una tarea ID 8.2 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: EMPLEADO Personal involucrado o intereses: 1. EMPLEADO: quiere poder eliminar archivos adjuntos a una tarea. Descripción: El EMPLEADO puede eliminar archivos adjuntos a una tarea. Precondición: El EMPLEADO debe estar autenticado y existir una obra asignada a dicho empleado. Además, la obra debe tener al menos una tarea con información adjunta que eliminar. Postcondición: 1. La información queda eliminada. Flujo normal: 1. El EMPLEADO accede a la aplicación móvil. 2. El EMPLEADO accede a la pantalla principal de la aplicación (dashboard). 3. Al EMPLEADO se le presentan las obras que tiene asignadas. 4. El EMPLEADO accede a la obra que elija a través de la interfaz. 5. El EMPLEADO accede al módulo correspondiente a las tareas de dicha obra. 6. El EMPLEADO accede a la tarea que desea. 7. El EMPLEADO selecciona ver archivos adjuntos. 8. El EMPLEADO selecciona el archivo a eliminar. 9. El archivo adjunto asociado a la tarea va a ser eliminado. 10. El EMPLEADO confirma la acción de eliminar el archivo adjunto. 11. El archivo se elimina del sistema. Flujo alternativo: 10.1. El EMPLEADO no confirma la acción de eliminar el archivo adjunto. 10.1.a. El sistema devuelve al EMPLEADO a la pantalla de visualización de archivos adjuntos. Tabla 35. Caso de uso: Eliminar archivos de una tarea Álvaro Romero Perdomo | 82 Nombre Añadir tareas a obra (empleado) ID 9 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: EMPLEADO Personal involucrado o intereses: 1. EMPLEADO: quiere añadir tareas a una obra. Descripción: El EMPLEADO puede añadir tareas desde la aplicación móvil a la obra que tiene asignada si fuera necesario. Precondición: El EMPLEADO debe estar autenticado y tener una obra asignada a la que añadirle una nueva tarea. Postcondición: La información de la obra se modifica en la base de datos con la tarea añadida. Flujo normal: 1. El EMPLEADO accede a la aplicación móvil. 2. El EMPLEADO accede a la pantalla principal de la aplicación (dashboard). 3. Al EMPLEADO se le presentan las obras que tiene asignadas. 4. El EMPLEADO accede a la obra que elija a través de la interfaz. 5. El EMPLEADO accede al formulario de añadir una nueva tarea a través de la interfaz. 6. El EMPLEADO especifica información relativa a la tarea a través de los campos indicados. 7. El EMPLEADO finaliza la creación de la tarea mediante el botón “finalizar”. 8. La tarea queda registrada en el sistema. Flujo alternativo: 6.1. Errores de validación de campos: 6.1.a. Se muestra un mensaje de error al EMPLEADO a través de la interfaz. 6.1.b. Se permite al EMPLEADO volver a rellenar los campos erróneos. Tabla 36. Caso de uso: Añadir tareas a obra (empleado) Álvaro Romero Perdomo | 83 Nombre Notificar incidencia ID 11 Creado por Álvaro Romero Perdomo Fecha 22/10/2016 Modif. por Álvaro Romero Perdomo Fecha modif. 22/10/2016 Actor principal: EMPLEADO Personal involucrado o intereses: 1. EMPLEADO: quiere poder notificar incidencias de la obra al administrador. Descripción: El EMPLEADO puede notificar incidencias de una obra al administrador. Precondición: El sistema debe contener una obra asignada a dicho empleado. Postcondición: La notificación queda registrada por el EMPLEADO en la base de datos. Flujo normal: 1. El EMPLEADO accede a la aplicación móvil. 2. El EMPLEADO accede a la pantalla principal de la aplicación móvil (dashboard). 3. Al EMPLEADO se le presentan las obras que tiene asignadas. 4. El EMPLEADO accede a la obra que elija a través de la interfaz. 5. El EMPLEADO accede a la vista de la lista de tareas. 6. El EMPLEADO accede al diálogo de cambio de estado de la tarea a través de la interfaz. 7. El EMPLEADO especifica el estado que desea asignar a la tarea. 8. El EMPLEADO finaliza la edición del estado mediante el botón “guardar tarea”. 9. La tarea queda registrada en el sistema. Flujo alternativo: Tabla 37. Caso de uso: Notificar incidencia Álvaro Romero Perdomo | 84 5.2. Anexo 2. Manual de usuario del panel de administración En este manual se pretende dar al usuario una visión general acerca de cómo utilizar el panel de administración y mostrarle sus principales funcionalidades. A continuación, se muestra la pantalla de inicio o presentación de la aplicación al acceder a ella. Ilustración 16. Pantalla de inicio del panel de administración El siguiente paso consistiría en hacer login en la aplicación siempre que tuviéramos una cuenta como administrador en ella. Ilustración 17. Pantalla de login del panel de administración Álvaro Romero Perdomo | 85 A continuación, se le presenta al usuario la pantalla principal del panel de administración, el dashboard donde se muestran las obras presentes en el sistema, pudiendo editarlas o crear una nueva. También en esta pantalla el usuario puede ver los usuarios y materiales del sistema. Ilustración 18. Dashboard del panel de administración A través del botón CREATE WORK de la anterior pantalla, accederíamos a la vista de creación de obra. En este punto deberíamos rellenar los campos que se nos presentan a través de las pestañas podríamos añadir también los materiales, las tareas y los archivos adjuntos de relevancia para dicha obra. Ilustración 19. Creación de una obra en el panel de administración Álvaro Romero Perdomo | 86 Ilustración 20. Creación de una obra en el panel de administración (materiales) Ilustración 21. Creación de una obra en el panel de administración (añadiendo una tarea) Álvaro Romero Perdomo | 87 Ilustración 22. Creación de una obra en el panel de administración (añadiendo archivos adjuntos) En la pantalla users podemos consultar los usuarios actuales del sistema y hacer búsquedas a través del buscador de un usuario en concreto. A través de esta pantalla también podemos editar los usuarios actuales del sistema. Ilustración 23. Vista de la pantalla users Álvaro Romero Perdomo | 88 En la pantalla materials podemos consultar los materiales actuales del sistema. A través de esta pantalla también podemos editar los usuarios materiales del sistema y añadir nuevos al sistema. Ilustración 24. Vista de la pantalla materials A través del dashboard podemos acceder a la pantalla de edición de una obra seleccionándola a través del toolbar a la derecha de cada una. En esta vista podemos volver a rellenar los campos que quedaron incompletos en el momento de creación de la obra o cambiarlos a nuestro antojo, para ello sólo tenemos que recordar guardar la obra antes de salir mediante el icono flotante de abajo derecha. Ilustración 25. Vista de edición de una obra Álvaro Romero Perdomo | 89 5.3. Anexo 3. Pantallazos completos de la demo no funcional A continuación, mostramos capturas de pantallas que muestran la demo no funcional completa presentada en la segunda reunión durante la etapa de análisis. Las primeras pantallas corresponden al inicio de sesión por parte del empleado dentro de la aplicación un desglose de las obras que tiene asignadas ordenadas por fecha. Una vez ha seleccionado una pasaríamos a la tercera pantalla, donde puede obtener información relativa a las tareas de la obra (consideramos las tareas como aquello que desea ver primero un empleado al acceder a una obra). Ilustración 26. Primeras pantallas de la demo no funcional