TRABAJO FIN DE GRADO

Transcripción

1 TRABAJO FIN DE GRADO Título Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi Autor/es Rubén Moral Miera Director/es Angel Luis Rubio García Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Grado en Ingeniería Informática Departamento Curso Académico

2 Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi, trabajo fin de grado de Rubén Moral Miera, dirigido por Angel Luis Rubio García (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2013 publicaciones.unirioja.es publicaciones@unirioja.es

3 FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMÁTICA TRABAJO DE FIN DE GRADO GRADO EN INGENIERÍA INFORMÁTICA Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi Aplicación Móvil Autor: Director: D. Rubén Moral Miera D. Ángel Luis Rubio García Departamento de Matemáticas y Computación Curso 2012/2013

4 Antes de comenzar quiero dar las gracias a mi director, Ángel, por su dedicación, su ayuda, sus consejos y su colaboración a lo largo de estos últimos años. II

5 III Resumen Actualmente, existen multitud de empresas que ofrecen servicios de paquetería y mensajería urgente (Correos, Seur, FedEx, UPS, DHL ). Todas ellas operan a nivel nacional o internacional; sin embargo, existen muy pocas que trabajen en el ámbito de una ciudad y sus suburbios, donde en vez de utilizar el coche o la furgoneta para repartir los paquetes se use una bicicleta. La idea del proyecto, propuesto por la empresa Digi International Spain como parte de su oferta de prácticas para Grado, ha sido desarrollar un sistema destinado a este tipo de empresas pequeñas, donde con una bicicleta y un tablet baste para realizar todas las tareas de reparto. Palabras clave: sistema multiplataforma, servicios de paquetería, reparto en bicicleta. Abstract Currently, there are many companies offering delivery and courier services (Correos, Seur, FedEx, UPS, DHL ). They all operate at national or international level; however, there are very few that work in the area of a city and its suburbs, where deliverers use a bicycle instead the car or van to deliver the packages. The idea of the project, proposed by the company Digi International Spain as part of their practices offered to Computer Engineering Degree, has been the development of a system intended for this kind of small companies, where with a bicycle and a tablet is enough to perform all delivery tasks. Keywords: cross-platform system, delivery services, bicycle messenger.

6 IV Índice general Capítulo 1. Introducción Antecedentes Objetivos Planificación Seguimiento del proyecto Capítulo 2. Desarrollo Análisis Identificación de los usuarios participantes Catálogo de requisitos del sistema Casos de uso Diseño Diseño de la interfaz de usuario Diagrama de navegación Arquitectura del sistema Almacenamiento de datos Patrones de diseño Diseño de clases Diseño del plan de pruebas Implementación Tecnologías usadas Librerías empleadas Estructura del proyecto Desarrollo de las aplicaciones Fase 1. Adaptación del código, incidencias y servicios y horas límite Fase 2. Sincronización Fase 3. Creación de las interfaces de la nueva aplicación... 46

7 V Fase 4. Funcionalidad de la aplicación para los clientes Pruebas Capítulo 3. Conclusiones Evaluación de objetivos Problemas planteados y procedimiento para su resolución Conocimientos adquiridos Mejoras del proyecto Capítulo 4. Bibliografía... 59

8 VI Índice de figuras Figura 1. Arquitectura del sistema Figura 2. Comparación entre tareas creadas y tareas resueltas Figura 3. Diagrama de estados de las tareas Figura 4. Diagrama de casos de uso para la aplicación de repartidores Figura 5. Diagrama de casos de uso para la aplicación de clientes Figura 6. Diagrama de actividad del caso de uso [Localizar pedido] Figura 7. Diagrama de actividad del caso de uso [Crear nuevo pedido] Figura 8. Diagrama de actividad del caso de uso [Iniciar sesión] Figura 9. Interfaces al comienzo del proyecto Figura 10. Evolución de la pantalla de inicio Figura 11. Evolución de la pantalla de detalles de la tarea Figura 12. Pantalla inicial Figura 13. Pantalla del primer paso de nuevo pedido Figura 14. Arquitectura en capas y niveles Figura 15. Diagrama de paquetes Figura 16. Diagrama de clases del modelo de objetos Figura 17. Diagrama de clases de la capa de lógica de negocio Figura 18. Diagrama de clases de la capa de persistencia Figura 19. Diferencia entre Java VM y Dalvik VM Figura 20. Contenido de la carpeta /src Figura 21. Contenido de /res Figura 22. Excepción que aparecía al arrancar la aplicación Figura 23. Implicaciones de ambos modos de conexión Figura 24. Estructura de los layouts de la aplicación Figura 25. Comparación de ambas vistas Figura 26. Vista de las direcciones almacenadas y la información de la empresa

9 Capítulo 1. Introducción La presente memoria trata de recoger los aspectos más importantes del trabajo realizado por Rubén Moral en el proyecto Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi Aplicación Android, realizado en el ámbito de la empresa Digi International Spain S.A.U Antecedentes Durante los últimos años y gracias a la expansión de Internet, cada vez más personas en el mundo realizan sus compras a través de la red. Debido a este hecho, las empresas de paquetería y servicio urgente están proliferando, ya que son una de las bases del comercio electrónico. La mayoría de ellas operan a nivel nacional o internacional; sin embargo, existen muy pocas que trabajen en el ámbito de una ciudad y sus suburbios, donde en vez de utilizar el coche o la furgoneta para repartir los paquetes se use una bicicleta. Por otra parte, las tecnologías móviles también crecen rápidamente. Los nuevos teléfonos inteligentes (conocidos como smartphones) son capaces de realizar actividades semejantes a las que se pueden hacer con un ordenador a muy bajo coste, con la ventaja de la gran movilidad que permiten. La idea de este proyecto ha sido unir los dos hechos anteriores, es decir, desarrollar un sistema que permita a pequeñas empresas de paquetería realizar todas las funciones necesarias sin necesidad de contar con herramientas complejas, simplemente con un smartphone o un tablet. El proyecto en sí empezó a realizarse en septiembre de 2012, en el periodo de Prácticas I. Puesto que su tamaño era demasiado grande, ya que no solo incluía la aplicación Android sino también la creación de un portal web para clientes y administradores, se decidió dividirlo en dos componentes: Web y Android 1, cada una de ellas desarrollada por un alumno de prácticas. El proyectante escogió la segunda parte, ya que sentía curiosidad por algo en lo que no había desarrollado nunca. El proyecto se planificó para ser realizado desde septiembre de 2012 hasta mayo de 2013, englobando las asignaturas de Prácticas I, Prácticas II y Trabajo de Fin de Grado. SOBRE DIGI Digi International es una empresa norteamericana centrada en la industria del hardware. Combina productos y servicios M2M (Máquina a Máquina) para gestionar de manera eficiente las empresas. Entre 1 La componente Web está formada por la aplicación web para el personal de administración de la empresa y el portal para los clientes. Mientras, la componente Android engloba la aplicación destinada a los trabajadores de la empresa y la aplicación para los clientes. 7

10 INTRODUCCIÓN Antecedentes sus productos más importantes destacan: sistemas embebidos, conectividad inalámbrica, Zero-Clients, servidores de consola, video/sensores y conectividad serie y USB. Digi además posee una nube pública para la gestión de redes de dispositivos, Etherios Device Cloud. Proporciona mensajería segura entre aplicaciones, almacenamiento de datos y gestión de dispositivos para redes cableadas y dispositivos celulares. Una red de dispositivos, también referidas en ocasiones como M2M, permite que sistemas cableados o inalámbricos se comuniquen con otros dispositivos o aplicaciones a través de diferentes tipos de red. Por ejemplo, un dispositivo (como un sensor) captura un evento (como un cambio de temperatura) y lo envía a través de una red a una aplicación, que lo traduce en información útil (como una alerta por cambio de temperatura). Gracias a este proyecto Digi podrá demostrar, a través de una aplicación real, las características y la multitud de posibilidades que ofrece su nube de dispositivos, pudiendo llevar a cabo cantidad de proyectos que hagan uso de ella. * * * En el caso que nos ocupa, la red está compuesta por dispositivos Android, que se conectan a la nube a través del Cloud Connector for Android (conjunto de librerías, plug-ins y herramientas diseñadas para facilitar el desarrollo de aplicaciones Etherios en dispositivos Android). Cada repartidor de la empresa de paquetería posee un dispositivo Android (bien un smartphone o bien un tablet), que tiene instalada la aplicación desarrollada y el Cloud Connector for Android. La aplicación sube archivos a la nube y llama a servicios web del servidor para gestionar todas las tareas requeridas. En la Figura 1 se puede observar la arquitectura global del sistema completo. Figura 1. Arquitectura del sistema. 8

11 INTRODUCCIÓN Objetivos El funcionamiento del sistema es el siguiente: cuando un cliente acceda al portal web o a su aplicación Android y solicite un envío, se generará en el servidor una tarea, que se asignará de forma automática al repartidor adecuado (según su posición y la carga de tareas en ese instante). La aplicación de este recibirá dicha tarea, que contendrá la información necesaria para poder ser llevada a cabo. Todos los cambios, tanto en el estado de la tarea como en la posición donde se encuentre el repartidor, serán actualizados en el servidor en el momento en que se produzcan. La tarea finalizará cuando el paquete se entregue al destinatario y firme en el dispositivo la recogida. Esta firma se digitalizará y se incluirá en la factura que se le envíe al cliente. La Device Cloud de Etherios permite el almacenamiento de datos en la nube (fichero con la localización de los trabajadores, firmas digitalizadas de los clientes ), la comunicación bidireccional entre ambas aplicaciones y el envío de notificaciones dese el servidor a la aplicación móvil. Durante los periodos de Prácticas I y Prácticas II (de septiembre a diciembre de 2012), el proyectante comenzó a diseñar el sistema, aprendiendo primero los fundamentos básicos de Android, y empezando más tarde a desarrollar la aplicación destinada a los trabajadores de la empresa de paquetería. Se definieron los tipos de tarea (envío y recogida) y se implementaron las actividades para mostrar tareas, para interactuar con ellas, para recibir mensajes de la empresa y para mostrar el perfil del trabajador. Se creó también un servicio de localización en tiempo real, una actividad para trazar rutas entre la posición del trabajador y el destino, una actividad para recoger la firma del usuario a la hora de entregar el paquete y una actividad para asociar un código QR a una tarea. La aplicación anteriormente mencionada está destinada a los trabajadores de la empresa, es decir, a los repartidores. Por otro lado, existe otra aplicación, esta para los clientes, a través de la cual pueden realizar un pedido, hacer el seguimiento del mismo o ver el historial de pedidos. De este modo, las tareas para este trabajo han sido terminar y re-implementar la aplicación para los repartidores (puesto que desde la empresa se dio libertad a la hora de desarrollarla y no se siguieron estrictamente las fases de desarrollo de software) y realizar la aplicación para los clientes siguiendo la metodología Scrum Objetivos El objetivo general de este proyecto es desarrollar un sistema completo y fácil de usar que se encargue de la logística necesaria para el buen funcionamiento de una empresa de paquetería a pequeña escala. Otros objetivos también importantes, relativos al sistema global, son: Comunicación bidireccional entre las dos plataformas (Web y Android), ya sea directamente entre ellas o a través de la nube de dispositivos. Demostración del funcionamiento del sistema completo al personal de la empresa Digi. 9

12 INTRODUCCIÓN Planificación Comprobación del correcto funcionamiento del sistema mediante la realización de tests, llevados a cabo por los dos alumnos y por el equipo de test de la empresa Digi. Realización de un vídeo promocional, donde se expliquen las principales características del sistema. Por otro lado, los objetivos específicos de la plataforma Android son: Terminar y mejorar determinados aspectos de la aplicación para los trabajadores. Diseñar e implementar una aplicación con la que cualquier cliente pueda: realizar un pedido, hacer el seguimiento del mismo y ver el histórico de pedidos. Las aplicaciones deben tener una interfaz de usuario intuitiva y fácil de usar, tanto para los trabajadores como para los clientes. Las aplicaciones deben estar realizadas para dispositivos que tengan al menos la versión 2.3.3, Gingebread, según los datos que se muestran en el primer informe de Las aplicaciones se deben ajustar a pantallas de entre 3,2 y 7 pulgadas, bien sean smartphones o tablets Planificación Como se ha comentado anteriormente, el sistema se empezó a diseñar en septiembre de 2012, ya que el proyecto estaba pensado para ser realizado en ocho meses. Aunque la frontera entre qué corresponde a Prácticas externas y qué al Trabajo de Fin de Grado es algo difusa, este último comenzó a desarrollarse el 21 de enero de 2013, fecha en la que comenzó el segundo cuatrimestre. En la siguiente lista se muestra la descomposición de tareas del proyecto: 1. Gestión del proyecto, 57 horas. a. Reuniones con el tutor y la empresa (22 horas). Cada último martes de mes, a partir del mes de enero, tendrá lugar una reunión en la Universidad con el tutor Ángel Luis Rubio para ir mostrándole el avance del proyecto. También habrá una reunión con la empresa cada miércoles de las semanas pares, con el mismo objetivo. b. Creación de los objetivos y redacción de la introducción (10 horas). Durante las dos primeras semanas se confeccionarán los objetivos que deberá cumplir la aplicación para los clientes. También se redactará el resumen y la introducción de la memoria. c. Elaboración de la memoria (25 horas). 2 El primer informe de 2013 realizado por Google indica que el 88,2% de los dispositivos Android utilizan como mínimo la versión (API Level 10). Es la versión más utilizada a esa fecha (47,4%), seguida por la (29,1%). 10

13 INTRODUCCIÓN Seguimiento del proyecto 2. Aplicación para los repartidores, 46 horas. a. Análisis (4 horas). Se analizará la situación de la aplicación realizada en el periodo de Prácticas y se establecerán una serie de directrices para la finalización de dicha aplicación. b. Diseño (4 horas). Se establecerán unos criterios para realizar el cambio en las interfaces de la aplicación. c. Implementación (35 horas). Se construirán los tres módulos restantes: incidencias, servicios y horas límite y sincronización. d. Pruebas (3 horas). Se realizarán pruebas unitarias de los módulos construidos y pruebas de integración. 3. Aplicación para los clientes, 192 horas. a. Análisis (15 horas). Se identificarán los participantes del sistema, se establecerá el catálogo de requisitos y se crearán los diagramas de casos de uso. b. Diseño (30 horas). Se elaborarán los prototipos de la nueva aplicación, se establecerá cómo deben almacenarse los datos, se creará el diagrama de clases y se diseñará el plan de pruebas. c. Implementación (144 horas). Se crearán las interfaces de usuario y se construirán las clases de las tres capas de la aplicación. d. Pruebas (3 horas). Se realizarán pruebas unitarias de los módulos construidos y pruebas de integración. 4. Material promocional del sistema completo, 5 horas. a. Elaboración del vídeo (5 horas). Se creará un vídeo promocional del sistema, donde se expongan todas las características del mismo. Duración total ESTIMADA: 300 horas 1.4. Seguimiento del proyecto El seguimiento del proyecto se ha realizado a través del software JIRA. Es una aplicación basada en web para el seguimiento de errores, de incidencias y para la gestión operativa de proyectos. Además, permite utilizar metodologías ágiles como Scrum (la que fue elegida para llevar a cabo este proyecto). La principal característica de Scrum es que es un proceso iterativo e incremental. Sin embargo, para este proyecto no se han seguido rigurosamente los principios y recomendaciones de Scrum, sino que esta metodología solo se ha tomado como base de la gestión. 11

14 INTRODUCCIÓN Seguimiento del proyecto Los roles para este proyecto se dividieron de la siguiente manera: ScrumMaster (director del proyecto): Diego Escalona (desarrollador en Digi). ProductOwner (dueño del producto): Pedro Pérez (responsable de Digi International Spain). Team (equipo de trabajo): César Estebas y Rubén Moral. La implementación del proyecto comenzó el 25 de febrero. Durante los dos primeros días se estableció la pila del producto y las características de los sprints. Se decidió que estos tuviesen una duración de 2 semanas, iniciándose los miércoles (coincidiendo con la reunión bisemanal en la empresa). A continuación se muestra una breve descripción del desarrollo del proyecto por cada sprint: Primer sprint (27/02/13 13/03/13), 19 horas: - Adaptación del código a la versión 4.x de Android. - Cambio en el diseño de las interfaces. - Arreglo de bugs encontrados. - Implementación del sistema de notificación de incidencias. - Implementación de los tipos de servicios. - Implementación de las horas límite. - Modificación de la lista de tareas para mostrar primero las prioritarias. Segundo sprint (13/03/13 27/03/13), 22 horas: - Diseño del layout para la sincronización. - Implementación de la sincronización offline. - Internacionalización. - Test de funcionalidad. - Prueba de la aplicación en varios dispositivos. Tercer sprint (27/03/13 10/04/13), 40 horas: - Diseño del layout para la pantalla de inicio. - Diseño del layout para la pantalla de login. - Diseño del layout para la pantalla de Seguimiento de un pedido. - Diseño del layout para la pantalla de Mis pedidos. - Diseño del layout para la pantalla de Nuevo pedido. Cuarto sprint (10/04/13 24/04/13), 82 horas: - Implementación de la pantalla de inicio. - Implementación de la pantalla de login. - Implementación de la pantalla de Seguimiento de un pedido. - Implementación de la pantalla de Mis pedidos. - Implementación de la pantalla de Nuevo pedido. 12

15 INTRODUCCIÓN Seguimiento del proyecto - Internacionalización. - Test de funcionalidad. - Pruebas en varios dispositivos. Quinto sprint (24/04/13 8/05/13), 18 horas: - Vídeo corporativo. - Prueba global del sistema. Figura 2. Comparación entre tareas creadas y tareas resueltas. Las estimaciones iniciales no fueron del todo exactas, puesto que el tiempo total de dedicación al proyecto ha sido un 2% superior al estimado. A continuación se puede observar las desviaciones en cada apartado del proyecto: Tarea Horas estimadas Horas reales Desviación Gestión del proyecto +5 en Creación de los objetivos h. Aplicación para los repartidores +3 en Implementación h. Aplicación para los clientes +8 en Análisis +6 en Diseño h. -25 en Implementación Material promocional h. TOTAL h. 13

16 Capítulo 2. Desarrollo 2.1. Análisis Esta especificación tiene como objetivo analizar y documentar las necesidades funcionales que deberán ser soportadas por el sistema a desarrollar. Para ello, se identificarán los requisitos que ha de satisfacer el nuevo sistema mediante el estudio de los problemas de las unidades afectadas y sus necesidades actuales. Además de identificar los requisitos se deberán establecer las prioridades, lo cual proporciona un punto de referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario Identificación de los usuarios participantes Los objetivos de esta tarea son identificar a los responsables de cada una de las unidades y a los principales usuarios implicados. En la organización se identificaron los siguientes usuarios: Clientes finales: Son aquellos a los que va dirigido el servicio de reparto. Pueden realizar un pedido a través del portal web o de la aplicación móvil que se desarrollará en este trabajo. Repartidores: Son los encargados de realizar las tareas de recogida y entrega de paquetes. A ellos va destinada la aplicación desarrollada en el periodo de Prácticas. Personal de administración: Son los que trabajan en la sede de la empresa y controlan las asignaciones de tareas y la posición de los repartidores Catálogo de requisitos del sistema i. Definiciones, acrónimos y abreviaturas Tarea: Unidad básica de trabajo. Es creada a petición de un usuario, y contiene la siguiente información: identificador, tipo, estado, datos del emisor, datos del receptor y detalles. En el ámbito de los clientes, tarea es sinónimo de pedido. Estado: Situación en que se encuentra una tarea en un momento determinado. Existen un total de 7 estados, que son los siguientes: New (nueva): La tarea ha sido creada pero aún no se ha iniciado. Pickup in progress (recogida en progreso): La tarea está siendo realizada; el repartidor va en camino hacia el cliente para recoger el paquete. Delivery in progress (entrega en progreso): La tarea está siendo realizada; el repartidor va en camino hacia el cliente para entregar el paquete. 14

17 DESARROLLO Análisis Paused (pausada): La tarea había sido iniciada pero se ha parado. La causa de este hecho es bien porque el repartidor ha iniciado otra tarea o porque el paquete no debe entregarse en el día de recogida y se ha guardado en el almacén. Finished (finalizada): El paquete ha sido entregado y la tarea se ha completado con éxito. Incidence (incidencia): La tarea no ha podido finalizarse correctamente debido a una incidencia. Canceled (cancelada): La tarea ha sido cancelada. Figura 3. Diagrama de estados de las tareas. Tipo: Clase de una tarea, que engloba a una serie de estados. Toda tarea, a lo largo de su vida, necesariamente tiene que tener los siguientes tipos: Pickup (recogida): Acción en la que el repartidor recoge un paquete de un cliente. Delivery (entrega): Acción en la que el repartidor entrega un paquete a un cliente. Tipo de servicio: Está asociado a la urgencia que tiene una tarea. Es elegido por el cliente a la hora de crear el pedido. Existen 4 tipos, ordenados de mayor a menor urgencia/coste: 2 horas: El paquete se entregará antes de 2 horas a contar desde el instante de la creación del pedido. 6 horas: El paquete se entregará antes de 6 horas a contar desde el instante de la creación del pedido. Madrugador: El paquete se entregará antes de las 20 horas del día en el que se haya creado. Siguiente día: El paquete se entregará antes de las 14 horas del día siguiente al de creación. Hora límite: Fecha y hora máxima que tiene un repartidor para finalizar la tarea y entregar el paquete. Se calcula en base al tipo de servicio contratado por el cliente. 15

18 DESARROLLO Análisis Número de seguimiento: Código único asociado a una tarea que permite al cliente visualizar el estado del pedido. ii. Descripción general Esta sección nos presenta una descripción general del sistema con el fin de conocer las funciones que debe soportar, los datos asociados, las restricciones impuestas y cualquier otro factor que pueda influir en la construcción del mismo. Las funciones que debe realizar el sistema se pueden agrupar de la siguiente manera: Seguimiento de un pedido: La aplicación permitirá que el usuario pueda ver dónde y en qué estado se encuentra su pedido, a través del número de seguimiento generado a la hora de crearlo. Historial de pedidos: La aplicación permitirá que el usuario pueda ver una lista con todos los pedidos creados hasta ese momento. Permitirá acceder a cada uno de ellos y ver todos sus detalles. Realización de pedidos: La aplicación permitirá que el usuario cree un nuevo pedido. Este deberá introducir sus datos si todavía no está registrado, así como los del emisor y el receptor del paquete. También deberá seleccionar el tipo de servicio y el método de pago. iii. Requisitos funcionales En esta sección se listan los requisitos funcionales de las aplicaciones. Los siguientes corresponden con los requisitos restantes de la aplicación para repartidores: A. Incidencias. Debe ser posible que el repartidor pueda notificar una incidencia o una cancelación si ocurre algún problema en el transcurso del proceso. Es posible que cuando vaya a entregar un paquete no haya nadie en el hogar de destino, o la dirección sea incorrecta. Por ello, se le facilitará una lista con una serie de incidencias predefinidas, aunque también se permitirá que él mismo redacte una. B. Servicios y horas límite. La lista de tareas del repartidor estará ordenada según el tipo de servicio y la hora límite. Hasta ahora, las tareas estaban ordenadas según su fecha de creación. Cuando la aplicación recibía una tarea nueva, la insertaba al final de la lista. Sin embargo, algunas tareas son más urgentes que otras (para ello el cliente paga más si quiere que su paquete llegue al destino a las dos horas en vez de al día siguiente). Por lo tanto, todas las tareas deberán contener el tipo de servicio y la hora límite de entrega, de modo que cuando vayan llegando nuevas tareas a la aplicación se ordenen según esos parámetros. 16

19 DESARROLLO Análisis C. Sincronización offline. Será posible que el trabajador pueda seguir usando la aplicación en zonas donde no haya 3G o WiFi. Cada vez que se produce un cambio en alguna tarea (inicio de la tarea, cambio de estado, firma del cliente), la aplicación comunica dicho cambio al servidor, por lo que es necesario que tenga conexión a Internet. De este modo, se permitirá que el repartidor llegue a lugares donde no haya cobertura (puesto que generalmente estará conectado a la red a través de 3G). La aplicación guardará todos los cambios en la memoria del dispositivo y los actualizará en el servidor web cuando se vuelva a conectar a Internet. A continuación se enumeran los requisitos de la aplicación para clientes a realizar en este trabajo, ordenados de mayor a menor importancia: A. Seguimiento de un pedido. Será posible que el usuario pueda localizar un pedido en curso, bien introduciendo el número de seguimiento o escaneando un código QR. La aplicación mostrará todos los detalles del pedido asociado a ese código, así como una tabla donde se muestren los estados por los que ha ido pasando. Si el usuario está autenticado, no hará falta que introduzca el número de seguimiento, puesto que se mostrará una lista con todos los pedidos en curso que disponga en ese instante. B. Autenticación. Debe existir la posibilidad de que el usuario se autentique antes de realizar cualquier operación. Esta función sirve para evitar que usuarios registrados tengan que introducir sus datos constantemente cada vez que realicen una operación. El sistema mostrará el formulario de acceso y realizará la autenticación. Una vez hecha, mantendrá la sesión abierta hasta que el usuario la cierre manualmente. C. Creación de un nuevo pedido. Debe ser posible que cualquier usuario pueda crear un nuevo pedido. El sistema mostrará un formulario para que este introduzca los datos de origen, de destino y el tipo de servicio. Una vez que acepte el pedido, si no se ha autenticado antes, el sistema abrirá el formulario de acceso. Tras iniciar sesión, se mostrará un resumen con los datos del pedido para que el cliente lo confirme. D. Historial de pedidos. El usuario podrá ver un listado con sus pedidos realizados. Una vez que se haya autenticado, el usuario podrá ver una tabla con todos los pedidos que haya realizado hasta ese momento, incluyendo tanto los finalizados como los que estén en progreso. Clicando sobre cada uno de ellos podrá acceder a la información concreta de ese pedido. 17

20 DESARROLLO Análisis iv. Requisitos de usuario y tecnológicos Requisitos de usuario: Existen dos tipos de usuario que van a hacer uso de estas aplicaciones: empleados de la empresa y clientes. Ambas interfaces deben ser intuitivas, fáciles de usar y amigables. El funcionamiento de la aplicación para los repartidores es más complejo, por lo que requerirá un manual de usuario detallado; sin embargo, la aplicación de los clientes está destinada a un mayor número de usuarios, con distintas habilidades y conocimientos, por lo que debe ser más intuitiva y debe cumplir los estándares de accesibilidad y usabilidad. Requisitos tecnológicos: Las aplicaciones están destinadas a smartphones o tablets Android, con una pantalla de entre 3,2 y 7, que tengan la versión o superior. Los dispositivos deberán tener cámara de fotos y conexión a Internet a través de 3G. Sería recomendable que también tuvieran GPS integrado. El sistema deberá adaptarse a la gran variedad de dispositivos móviles existentes. Más concretamente deberá tener en cuenta el área de presentación y adaptar las visualizaciones para aprovechar al máximo el tamaño disponible. El ancho de banda desde dispositivos móviles suele ser bastante reducido, por lo que hay que controlar no saturar con contenidos demasiado pesados que influyan en el tiempo de respuesta de la aplicación. Las aplicaciones se ejecutarán sobre un esquema cliente/servidor, con los procesos e interfaz de usuario ejecutándose en los clientes y estos solicitando requerimientos al servidor que cumple su proceso. v. Requisitos de interfaces externas Interfaces de usuario: La interfaz de usuario de la aplicación de clientes debe ser similar a la del portal web (en cuanto a diseño y colores). Interfaces hardware: Smartphone o tablet Android. vi. Requisitos de rendimiento El tiempo de respuesta de la aplicación a cada función solicitada por el usuario no debe ser superior a 5 segundos, exceptuando la función de crear un nuevo pedido, donde se podrá demorar como máximo hasta 10 segundos. 18