TFE000296

Rubn Moral Miera
Desarrollo e implementacin de una solucin completa

para empresas de mensajera/paquetera utilizando
dispositivos Android y la nube de dispositivos de Digi
Angel Luis Rubio Garca
Facultad de Ciencias, Estudios Agroalimentarios e Informtica
Grado en Ingeniera Informtica
2012-2013
Ttulo
Autor/es
Director/es
Facultad
Titulacin
Departamento
TRABAJO FIN DE GRADO
Curso Acadmico
El autor
Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
Desarrollo e implementacin de una solucin completa para empresas de
mensajera/paquetera utilizando dispositivos Android y la nube de
dispositivos de Digi, trabajo fin de grado
de Rubn Moral Miera, dirigido por Angel Luis Rubio Garca (publicado por la Universidad
de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMTICA
TRABAJO DE FIN DE GRADO
GRADO EN INGENIERA INFORMTICA

Desarrollo e implementacin de una solucin completa
para empresas de mensajera/paquetera utilizando
dispositivos Android y la nube de dispositivos de Digi
Aplicacin Mvil

Autor: Director:
D. Rubn Moral Miera D. ngel Luis Rubio Garca

Departamento de Matemticas y Computacin
Curso 2012/2013
II

Antes de comenzar quiero dar las gracias a mi director,
ngel, por su dedicacin, su ayuda, sus consejos y su
colaboracin a lo largo de estos ltimos aos.
III

Resumen
Actualmente, existen multitud de empresas que ofrecen servicios de paquetera y mensajera 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 prc-
ticas para Grado, ha sido desarrollar un sistema destinado a este tipo de empresas pequeas, donde con
una bicicleta y un tablet baste para realizar todas las tareas de reparto.

Palabras clave: sistema multiplataforma, servicios de paquetera, 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 pack-
ages.
The idea of the project, proposed by the company Digi International Spain as part of their practices of-
fered 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.
IV

ndice general

Captulo 1. Introduccin ....................................................................................................... 7
1.1. Antecedentes ................................................................................................................... 7
1.2. Objetivos .......................................................................................................................... 9
1.3. Planificacin ................................................................................................................... 10
1.4. Seguimiento del proyecto .............................................................................................. 11
Captulo 2. Desarrollo ........................................................................................................ 14
2.1. Anlisis ............................................................................................................................ 14
2.1.1. Identificacin de los usuarios participantes ........................................................... 14
2.1.2. Catlogo de requisitos del sistema ......................................................................... 14
2.1.3. Casos de uso ............................................................................................................ 19
2.2. Diseo ............................................................................................................................. 28
2.2.1. Diseo de la interfaz de usuario ............................................................................. 28
2.2.2. Diagrama de navegacin ......................................................................................... 32
2.2.3. Arquitectura del sistema ......................................................................................... 33
2.2.4. Almacenamiento de datos ...................................................................................... 33
2.2.5. Patrones de diseo ................................................................................................. 35
2.2.6. Diseo de clases ...................................................................................................... 36
2.2.7. Diseo del plan de pruebas .................................................................................... 38
2.3. Implementacin ............................................................................................................. 39
2.3.1. Tecnologas usadas ................................................................................................. 39
2.3.2. Libreras empleadas ................................................................................................ 40
2.3.3. Estructura del proyecto .......................................................................................... 40
2.3.4. Desarrollo de las aplicaciones ................................................................................. 42
Fase 1. Adaptacin del cdigo, incidencias y servicios y horas lmite ............................... 42
Fase 2. Sincronizacin ........................................................................................................ 44
Fase 3. Creacin de las interfaces de la nueva aplicacin ................................................. 46
V

Fase 4. Funcionalidad de la aplicacin para los clientes .................................................... 48
2.4. Pruebas ........................................................................................................................... 52
Captulo 3. Conclusiones .................................................................................................... 56
3.1. Evaluacin de objetivos .................................................................................................. 56
3.2. Problemas planteados y procedimiento para su resolucin ......................................... 56
3.3. Conocimientos adquiridos ............................................................................................. 57
3.4. Mejoras del proyecto ..................................................................................................... 58
Captulo 4. Bibliografa ....................................................................................................... 59

VI

ndice de figuras
Figura 1. Arquitectura del sistema. ................................................................................................. 8
Figura 2. Comparacin entre tareas creadas y tareas resueltas. ................................................. 13
Figura 3. Diagrama de estados de las tareas. ............................................................................... 15
Figura 4. Diagrama de casos de uso para la aplicacin de repartidores. ..................................... 19
Figura 5. Diagrama de casos de uso para la aplicacin de clientes. ............................................. 21
Figura 6. Diagrama de actividad del caso de uso [Localizar pedido]. ........................................... 23
Figura 7. Diagrama de actividad del caso de uso [Crear nuevo pedido]. ..................................... 25
Figura 8. Diagrama de actividad del caso de uso [Iniciar sesin]. ................................................ 27
Figura 9. Interfaces al comienzo del proyecto. ............................................................................. 28
Figura 10. Evolucin de la pantalla de inicio................................................................................. 29
Figura 11. Evolucin de la pantalla de detalles de la tarea. ......................................................... 29
Figura 12. Pantalla inicial. ............................................................................................................. 30
Figura 13. Pantalla del primer paso de nuevo pedido. ................................................................. 31
Figura 14. Arquitectura en capas y niveles. .................................................................................. 33
Figura 15. Diagrama de paquetes. ................................................................................................ 36
Figura 16. Diagrama de clases del modelo de objetos. ................................................................ 36
Figura 17. Diagrama de clases de la capa de lgica de negocio. .................................................. 37
Figura 18. Diagrama de clases de la capa de persistencia. ........................................................... 37
Figura 19. Diferencia entre Java VM y Dalvik VM. ........................................................................ 39
Figura 20. Contenido de la carpeta /src. ....................................................................................... 41
Figura 21. Contenido de /res. ....................................................................................................... 41
Figura 22. Excepcin que apareca al arrancar la aplicacin. ....................................................... 42
Figura 23. Implicaciones de ambos modos de conexin. ............................................................. 45
Figura 24. Estructura de los layouts de la aplicacin. ................................................................... 46
Figura 25. Comparacin de ambas vistas. .................................................................................... 49
Figura 26. Vista de las direcciones almacenadas y la informacin de la empresa. ...................... 51

7
Captulo 1. Introduccin
La presente memoria trata de recoger los aspectos ms importantes del trabajo realizado por Rubn
Moral en el proyecto Desarrollo e implementacin de una solucin completa para empresas de mensa-
jera/paquetera utilizando dispositivos Android y la nube de dispositivos de Digi Aplicacin Android,
realizado en el mbito de la empresa Digi International Spain S.A.U.

1.1. Antecedentes
Durante los ltimos aos y gracias a la expansin de Internet, cada vez ms personas en el mundo reali-
zan sus compras a travs de la red. Debido a este hecho, las empresas de paquetera y servicio urgente
estn proliferando, ya que son una de las bases del comercio electrnico. La mayora 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 tecnologas mviles tambin crecen rpidamente. Los nuevos telfonos inteligentes
(conocidos como smartphones) son capaces de realizar actividades semejantes a las que se pueden ha-
cer 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 pequeas empresas de paquetera 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 Prcticas I. Puesto que su
tamao era demasiado grande, ya que no solo inclua la aplicacin Android sino tambin la creacin de
un portal web para clientes y administradores, se decidi dividirlo en dos componentes: Web y An-
droid
1
, cada una de ellas desarrollada por un alumno de prcticas. El proyectante escogi la segunda
parte, ya que senta curiosidad por algo en lo que no haba desarrollado nunca.
El proyecto se planific para ser realizado desde septiembre de 2012 hasta mayo de 2013, englobando
las asignaturas de Prcticas I, Prcticas II y Trabajo de Fin de Grado.

SOBRE DIGI
Digi International es una empresa norteamericana centrada en la industria del hardware. Combina pro-
ductos y servicios M2M (Mquina a Mquina) para gestionar de manera eficiente las empresas. Entre

1
La componente Web est formada por la aplicacin web para el personal de administracin de la empresa y el
portal para los clientes. Mientras, la componente Android engloba la aplicacin destinada a los trabajadores de la
empresa y la aplicacin para los clientes.
INTRODUCCIN Antecedentes

8
sus productos ms importantes destacan: sistemas embebidos, conectividad inalmbrica, Zero-Clients,
servidores de consola, video/sensores y conectividad serie y USB.
Digi adems posee una nube pblica para la gestin de redes de dispositivos, Etherios Device Cloud.
Proporciona mensajera segura entre aplicaciones, almacenamiento de datos y gestin de dispositivos
para redes cableadas y dispositivos celulares. Una red de dispositivos, tambin referidas en ocasiones
como M2M, permite que sistemas cableados o inalmbricos se comuniquen con otros dispositivos o
aplicaciones a travs de diferentes tipos de red. Por ejemplo, un dispositivo (como un sensor) captura un
evento (como un cambio de temperatura) y lo enva a travs de una red a una aplicacin, que lo traduce
en informacin til (como una alerta por cambio de temperatura).
Gracias a este proyecto Digi podr demostrar, a travs de una aplicacin real, las caractersticas y la mul-
titud 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
travs del Cloud Connector for Android (conjunto de libreras, plug-ins y herramientas diseadas para
facilitar el desarrollo de aplicaciones Etherios en dispositivos Android).
Cada repartidor de la empresa de paquetera posee un dispositivo Android (bien un smartphone o bien
un tablet), que tiene instalada la aplicacin desarrollada y el Cloud Connector for Android. La aplicacin
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.
INTRODUCCIN Objetivos

9
El funcionamiento del sistema es el siguiente: cuando un cliente acceda al portal web o a su aplicacin
Android y solicite un envo, se generar en el servidor una tarea, que se asignar de forma automtica al
repartidor adecuado (segn su posicin y la carga de tareas en ese instante). La aplicacin de este recibi-
r dicha tarea, que contendr la informacin necesaria para poder ser llevada a cabo. Todos los cam-
bios, tanto en el estado de la tarea como en la posicin donde se encuentre el repartidor, sern actuali-
zados en el servidor en el momento en que se produzcan. La tarea finalizar cuando el paquete se en-
tregue al destinatario y firme en el dispositivo la recogida. Esta firma se digitalizar y se incluir en la
factura que se le enve al cliente.
La Device Cloud de Etherios permite el almacenamiento de datos en la nube (fichero con la localizacin
de los trabajadores, firmas digitalizadas de los clientes), la comunicacin bidireccional entre ambas
aplicaciones y el envo de notificaciones dese el servidor a la aplicacin mvil.
Durante los periodos de Prcticas I y Prcticas II (de septiembre a diciembre de 2012), el proyectante
comenz a disear el sistema, aprendiendo primero los fundamentos bsicos de Android, y empezando
ms tarde a desarrollar la aplicacin destinada a los trabajadores de la empresa de paquetera.
Se definieron los tipos de tarea (envo y recogida) y se implementaron las actividades para mostrar ta-
reas, para interactuar con ellas, para recibir mensajes de la empresa y para mostrar el perfil del trabaja-
dor. Se cre tambin un servicio de localizacin en tiempo real, una actividad para trazar rutas entre la
posicin 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 cdigo QR a una tarea.
La aplicacin anteriormente mencionada est destinada a los trabajadores de la empresa, es decir, a los
repartidores. Por otro lado, existe otra aplicacin, esta para los clientes, a travs de la cual pueden real i-
zar 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 aplicacin 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 aplicacin para los clientes siguiendo la
metodologa Scrum.

1.2. Objetivos
El objetivo general de este proyecto es desarrollar un sistema completo y fcil de usar que se encargue
de la logstica necesaria para el buen funcionamiento de una empresa de paquetera a pequea escala.
Otros objetivos tambin importantes, relativos al sistema global, son:
Comunicacin bidireccional entre las dos plataformas (Web y Android), ya sea directamente en-
tre ellas o a travs de la nube de dispositivos.
Demostracin del funcionamiento del sistema completo al personal de la empresa Digi.
INTRODUCCIN Planificacin

10
Comprobacin del correcto funcionamiento del sistema mediante la realizacin de tests, lleva-
dos a cabo por los dos alumnos y por el equipo de test de la empresa Digi.
Realizacin de un vdeo promocional, donde se expliquen las principales caractersticas del sis-
tema.

Por otro lado, los objetivos especficos de la plataforma Android son:
Terminar y mejorar determinados aspectos de la aplicacin para los trabajadores.
Disear e implementar una aplicacin con la que cualquier cliente pueda: realizar un pedido, ha-
cer el seguimiento del mismo y ver el histrico de pedidos.
Las aplicaciones deben tener una interfaz de usuario intuitiva y fcil de usar, tanto para los tra-
bajadores como para los clientes.
Las aplicaciones deben estar realizadas para dispositivos que tengan al menos la versin 2.3.3,
Gingebread, segn los datos que se muestran en el primer informe de 2013
2
.
Las aplicaciones se deben ajustar a pantallas de entre 3,2 y 7 pulgadas, bien sean smartphones o
tablets.

1.3. Planificacin
Como se ha comentado anteriormente, el sistema se empez a disear en septiembre de 2012, ya que
el proyecto estaba pensado para ser realizado en ocho meses. Aunque la frontera entre qu correspon-
de a Prcticas externas y qu al Trabajo de Fin de Grado es algo difusa, este ltimo comenz a desarro-
llarse el 21 de enero de 2013, fecha en la que comenz el segundo cuatrimestre.
En la siguiente lista se muestra la descomposicin de tareas del proyecto:
1. Gestin 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 reunin en la Universidad con el tutor ngel Luis Rubio
para ir mostrndole el avance del proyecto. Tambin habr una reunin con la empresa
cada mircoles de las semanas pares, con el mismo objetivo.
b. Creacin de los objetivos y redaccin de la introduccin (10 horas). Durante las dos pri-
meras semanas se confeccionarn los objetivos que deber cumplir la aplicacin para
los clientes. Tambin se redactar el resumen y la introduccin de la memoria.
c. Elaboracin 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
mnimo la versin 2.3.3 (API Level 10). Es la versin ms utilizada a esa fecha (47,4%), seguida por la 4.0.3 (29,1%).
INTRODUCCIN Seguimiento del proyecto

11
2. Aplicacin para los repartidores, 46 horas.
a. Anlisis (4 horas). Se analizar la situacin de la aplicacin realizada en el periodo de
Prcticas y se establecern una serie de directrices para la finalizacin de dicha aplica-
cin.
b. Diseo (4 horas). Se establecern unos criterios para realizar el cambio en las interfaces
de la aplicacin.
c. Implementacin (35 horas). Se construirn los tres mdulos restantes: incidencias, ser-
vicios y horas lmite y sincronizacin.
d. Pruebas (3 horas). Se realizarn pruebas unitarias de los mdulos construidos y pruebas
de integracin.
3. Aplicacin para los clientes, 192 horas.
a. Anlisis (15 horas). Se identificarn los participantes del sistema, se establecer el cat-
logo de requisitos y se crearn los diagramas de casos de uso.
b. Diseo (30 horas). Se elaborarn los prototipos de la nueva aplicacin, se establecer
cmo deben almacenarse los datos, se crear el diagrama de clases y se disear el plan
de pruebas.
c. Implementacin (144 horas). Se crearn las interfaces de usuario y se construirn las
clases de las tres capas de la aplicacin.
d. Pruebas (3 horas). Se realizarn pruebas unitarias de los mdulos construidos y pruebas
de integracin.
4. Material promocional del sistema completo, 5 horas.
a. Elaboracin del vdeo (5 horas). Se crear un vdeo promocional del sistema, donde se
expongan todas las caractersticas del mismo.

Duracin total ESTIMADA: 300 horas

1.4. Seguimiento del proyecto
El seguimiento del proyecto se ha realizado a travs del software JIRA. Es una aplicacin basada en web
para el seguimiento de errores, de incidencias y para la gestin operativa de proyectos. Adems, permi-
te utilizar metodologas giles como Scrum (la que fue elegida para llevar a cabo este proyecto).
La principal caracterstica 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
metodologa solo se ha tomado como base de la gestin.

12
Los roles para este proyecto se dividieron de la siguiente manera:
ScrumMaster (director del proyecto): Diego Escalona (desarrollador en Digi).
ProductOwner (dueo del producto): Pedro Prez (responsable de Digi International Spain).
Team (equipo de trabajo): Csar Estebas y Rubn Moral.

La implementacin del proyecto comenz el 25 de febrero. Durante los dos primeros das se estableci
la pila del producto y las caractersticas de los sprints. Se decidi que estos tuviesen una duracin de 2
semanas, inicindose los mircoles (coincidiendo con la reunin bisemanal en la empresa).
A continuacin se muestra una breve descripcin del desarrollo del proyecto por cada sprint:
Primer sprint (27/02/13 13/03/13), 19 horas:
- Adaptacin del cdigo a la versin 4.x de Android.
- Cambio en el diseo de las interfaces.
- Arreglo de bugs encontrados.
- Implementacin del sistema de notificacin de incidencias.
- Implementacin de los tipos de servicios.
- Implementacin de las horas lmite.
- Modificacin de la lista de tareas para mostrar primero las prioritarias.
Segundo sprint (13/03/13 27/03/13), 22 horas:
- Diseo del layout para la sincronizacin.
- Implementacin de la sincronizacin offline.
- Internacionalizacin.
- Test de funcionalidad.
- Prueba de la aplicacin en varios dispositivos.
Tercer sprint (27/03/13 10/04/13), 40 horas:
- Diseo del layout para la pantalla de inicio.
- Diseo del layout para la pantalla de login.
- Diseo del layout para la pantalla de Seguimiento de un pedido.
- Diseo del layout para la pantalla de Mis pedidos.
- Diseo del layout para la pantalla de Nuevo pedido.
Cuarto sprint (10/04/13 24/04/13), 82 horas:
- Implementacin de la pantalla de inicio.
- Implementacin de la pantalla de login.
- Implementacin de la pantalla de Seguimiento de un pedido.
- Implementacin de la pantalla de Mis pedidos.
- Implementacin de la pantalla de Nuevo pedido.

13
- Internacionalizacin.
- Test de funcionalidad.
- Pruebas en varios dispositivos.
Quinto sprint (24/04/13 8/05/13), 18 horas:
- Vdeo corporativo.
- Prueba global del sistema.

Figura 2. Comparacin entre tareas creadas y tareas resueltas.

Las estimaciones iniciales no fueron del todo exactas, puesto que el tiempo total de dedicacin al pro-
yecto ha sido un 2% superior al estimado. A continuacin se puede observar las desviaciones en cada
apartado del proyecto:
Tarea Horas estimadas Horas reales Desviacin
Gestin del proyecto
+5 en Creacin de los objetivos
57 62 +5 h.
Aplicacin para los repartidores
+3 en Implementacin
46 49 +3 h.
Aplicacin para los clientes
+8 en Anlisis
+6 en Diseo
-25 en Implementacin
192 181 -11 h.
Material promocional 5 15 +10 h.
TOTAL 300 307 +7 h.

14
Captulo 2. Desarrollo
2.1. Anlisis
Esta especificacin tiene como objetivo analizar y documentar las necesidades funcionales que debern
ser soportadas por el sistema a desarrollar. Para ello, se identificarn los requisitos que ha de satisfacer
el nuevo sistema mediante el estudio de los problemas de las unidades afectadas y sus necesidades ac-
tuales. Adems de identificar los requisitos se debern 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.

2.1.1. Identificacin de los usuarios participantes
Los objetivos de esta tarea son identificar a los responsables de cada una de las unidades y a los princi-
pales usuarios implicados. En la organizacin se identificaron los siguientes usuarios:
Clientes finales: Son aquellos a los que va dirigido el servicio de reparto. Pueden realizar un pe-
dido a travs del portal web o de la aplicacin mvil 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 aplicacin desarrollada en el periodo de Prcticas.
Personal de administracin: Son los que trabajan en la sede de la empresa y controlan las asig-
naciones de tareas y la posicin de los repartidores.

2.1.2. Catlogo de requisitos del sistema
i. Definiciones, acrnimos y abreviaturas
Tarea: Unidad bsica de trabajo. Es creada a peticin de un usuario, y contiene la siguiente informacin:
identificador, tipo, estado, datos del emisor, datos del receptor y detalles. En el mbito de los clientes,
tarea es sinnimo de pedido.
Estado: Situacin 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 an 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.
DESARROLLO Anlisis

15
Paused (pausada): La tarea haba 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
da de recogida y se ha guardado en el almacn.
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, necesa-
riamente tiene que tener los siguientes tipos:
Pickup (recogida): Accin en la que el repartidor recoge un paquete de un cliente.
Delivery (entrega): Accin 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 creacin del
pedido.
6 horas: El paquete se entregar antes de 6 horas a contar desde el instante de la creacin del
pedido.
Madrugador: El paquete se entregar antes de las 20 horas del da en el que se haya creado.
Siguiente da: El paquete se entregar antes de las 14 horas del da siguiente al de creacin.
Hora lmite: Fecha y hora mxima que tiene un repartidor para finalizar la tarea y entregar el paquete.
Se calcula en base al tipo de servicio contratado por el cliente.
DESARROLLO Anlisis

16
Nmero de seguimiento: Cdigo nico asociado a una tarea que permite al cliente visualizar el estado
del pedido.

ii. Descripcin general
Esta seccin nos presenta una descripcin 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 construccin del mismo.
Las funciones que debe realizar el sistema se pueden agrupar de la siguiente manera:
Seguimiento de un pedido: La aplicacin permitir que el usuario pueda ver dnde y en
qu estado se encuentra su pedido, a travs del nmero de seguimiento generado a la hora
de crearlo.
Historial de pedidos: La aplicacin 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.
Realizacin de pedidos: La aplicacin permitir que el usuario cree un nuevo pedido. Este
deber introducir sus datos si todava no est registrado, as como los del emisor y el recep-
tor del paquete. Tambin deber seleccionar el tipo de servicio y el mtodo de pago.

iii. Requisitos funcionales
En esta seccin se listan los requisitos funcionales de las aplicaciones. Los siguientes corresponden con
los requisitos restantes de la aplicacin para repartidores:
A. Incidencias.
Debe ser posible que el repartidor pueda notificar una incidencia o una cancelacin si ocurre algn pro-
blema en el transcurso del proceso. Es posible que cuando vaya a entregar un paquete no haya nadie en
el hogar de destino, o la direccin sea incorrecta. Por ello, se le facilitar una lista con una serie de inci-
dencias predefinidas, aunque tambin se permitir que l mismo redacte una.
B. Servicios y horas lmite.
La lista de tareas del repartidor estar ordenada segn el tipo de servicio y la hora lmite. Hasta ahora,
las tareas estaban ordenadas segn su fecha de creacin. Cuando la aplicacin reciba una tarea nueva,
la insertaba al final de la lista. Sin embargo, algunas tareas son ms urgentes que otras (para ello el
cliente paga ms si quiere que su paquete llegue al destino a las dos horas en vez de al da siguiente).
Por lo tanto, todas las tareas debern contener el tipo de servicio y la hora lmite de entrega, de modo
que cuando vayan llegando nuevas tareas a la aplicacin se ordenen segn esos parmetros.

DESARROLLO Anlisis

17
C. Sincronizacin offline.
Ser posible que el trabajador pueda seguir usando la aplicacin 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 aplicacin comunica dicho cambio al servidor, por lo que es necesario que tenga conexin 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 travs de 3G). La aplicacin guardar todos los cambios
en la memoria del dispositivo y los actualizar en el servidor web cuando se vuelva a conectar a Internet.

A continuacin se enumeran los requisitos de la aplicacin para clientes a realizar en este trabajo, orde-
nados de mayor a menor importancia:
A. Seguimiento de un pedido.
Ser posible que el usuario pueda localizar un pedido en curso, bien introduciendo el nmero de segui-
miento o escaneando un cdigo QR. La aplicacin mostrar todos los detalles del pedido asociado a ese
cdigo, 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 nmero de seguimiento, puesto que se mostrar una lista
con todos los pedidos en curso que disponga en ese instante.
B. Autenticacin.
Debe existir la posibilidad de que el usuario se autentique antes de realizar cualquier operacin. Esta
funcin sirve para evitar que usuarios registrados tengan que introducir sus datos constantemente cada
vez que realicen una operacin. El sistema mostrar el formulario de acceso y realizar la autenticacin.
Una vez hecha, mantendr la sesin abierta hasta que el usuario la cierre manualmente.
C. Creacin 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 pe-
dido, si no se ha autenticado antes, el sistema abrir el formulario de acceso. Tras iniciar sesin, se mos-
trar 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 estn en progreso. Clicando sobre cada uno de ellos podr acceder a la infor-
macin concreta de ese pedido.

DESARROLLO Anlisis

18
iv. Requisitos de usuario y tecnolgicos
Requisitos de usuario:
Existen dos tipos de usuario que van a hacer uso de estas aplicaciones: empleados de la empresa y clien-
tes. Ambas interfaces deben ser intuitivas, fciles de usar y amigables. El funcionamiento de la aplica-
cin para los repartidores es ms complejo, por lo que requerir un manual de usuario detallado; sin
embargo, la aplicacin de los clientes est destinada a un mayor nmero de usuarios, con distintas habi-
lidades y conocimientos, por lo que debe ser ms intuitiva y debe cumplir los estndares de accesibili-
dad y usabilidad.
Requisitos tecnolgicos:
Las aplicaciones estn destinadas a smartphones o tablets Android, con una pantalla de entre
3,2 y 7, que tengan la versin 2.3.3 o superior.
Los dispositivos debern tener cmara de fotos y conexin a Internet a travs de 3G. Sera re-
comendable que tambin tuvieran GPS integrado.
El sistema deber adaptarse a la gran variedad de dispositivos mviles existentes. Ms concre-
tamente deber tener en cuenta el rea de presentacin y adaptar las visualizaciones para apro-
vechar al mximo el tamao disponible.
El ancho de banda desde dispositivos mviles 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 aplicacin.
Las aplicaciones se ejecutarn sobre un esquema cliente/servidor, con los procesos e interfaz de
usuario ejecutndose 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 aplicacin de clientes debe ser similar a la del
portal web (en cuanto a diseo y colores).
Interfaces hardware: Smartphone o tablet Android.

vi. Requisitos de rendimiento
El tiempo de respuesta de la aplicacin a cada funcin solicitada por el usuario no debe ser superior a 5
segundos, exceptuando la funcin de crear un nuevo pedido, donde se podr demorar como mximo
hasta 10 segundos.

DESARROLLO Anlisis

19

vii. Requisitos de desarrollo y restricciones de diseo.
El marco de trabajo de desarrollo de software elegido para este proyecto es Scrum, cuya caracterstica
principal es que es un proceso iterativo e incremental. Para controlar los sprints y realizar la gestin
operativa del proyecto se utilizar JIRA.
En cuanto a las restricciones de diseo, los cdigos QR debern seguir el estndar ISO/IEC 18004:2006, y
contendrn una cadena de texto referente al nmero de seguimiento.

2.1.3. Casos de uso
En esta seccin se especificarn los casos de uso ms relevantes en el sistema. El resto estn incluidos
en el Anexo 1 (Casos de uso).
A continuacin se muestra el diagrama de casos de uso de la aplicacin para los repartidores, junto con
la especificacin de los dos casos de uso que restan por implementar en el sistema.

Figura 4. Diagrama de casos de uso para la aplicacin de repartidores.

DESARROLLO Anlisis

20
Caso de uso Sincronizar
Descripcin Actualizar en el servidor todos los cambios que se hayan
producido en el dispositivo cuando no estaba conectado a
Internet.
Actores Repartidor.
Precondiciones El dispositivo debe estar conectado a Internet.
Postcondiciones Todos los cambios almacenados offline en el dispositivo
son sincronizados en el servidor correctamente.
Flujo bsico
1. El repartidor pulsa el botn de sincronizar.
2. El sistema se conecta con el servidor y actualiza los cambios.
3. El sistema sube las firmas digitalizadas a la nube.
Flujos alternativos y excepciones
No hay.
Anotaciones No hay.

Caso de uso Notificar incidencia
Descripcin Reportar una incidencia al servidor para que el personal de
administracin pueda gestionarla.
Actores Repartidor.
Precondiciones El repartidor debe estar en [Ver detalles de tarea].
Postcondiciones La incidencia es notificada correctamente.
Flujo bsico
1. El repartidor pulsa el botn de incidencia.
2. El sistema muestra un dilogo con una lista de las incidencias ms
habituales y un campo de texto.
3. El repartidor selecciona una incidencia de las de la lista o escribe una
personalizada en el campo de texto, y pulsa Enviar.
No hay.
Anotaciones No hay.

DESARROLLO Anlisis

21
Por otra parte, el siguiente diagrama muestra los casos de uso de la aplicacin para los clientes. Se inclu-
yen tambin la especificacin de los casos de uso ms relevantes junto con los diagramas de actividad.

Figura 5. Diagrama de casos de uso para la aplicacin de clientes.

DESARROLLO Anlisis

22
Caso de uso Localizar pedido
Descripcin Localizar un pedido en curso introduciendo su nmero de
seguimiento o escaneando su cdigo QR.
Actores Cliente.
Precondiciones No hay.
Postcondiciones Se muestra un resumen del pedido a localizar.
Flujo bsico
1. El cliente elige la opcin Localizar pedido en la pantalla inicial.
2. El sistema muestra: un cuadro de texto para introducir el nmero de
seguimiento, un icono con una cmara y un botn de Buscar.
3. El cliente introduce el nmero de seguimiento y pulsa Buscar.
4. El sistema muestra un resumen del pedido que corresponde con el
nmero de seguimiento introducido.
Si el cliente est autenticado en el sistema, tras el punto 1 se mostrar direc-
tamente un resumen con los pedidos en curso de dicho usuario.
En el punto 3, el cliente puede llevar a cabo [Escanear cdigo QR] en vez de
introducir el nmero de seguimiento.
Tras el punto 4, el cliente puede pulsar sobre el pedido e ir a [Ver detalle pedi-
do].
Si el nmero de seguimiento o el cdigo QR no se corresponde con ningn pe-
dido se avisa al cliente del error.
Anotaciones Para escanear un cdigo QR en vez de introducir el nmero
de seguimiento, el cliente deber pulsar sobre el icono de
la cmara.

DESARROLLO Anlisis

23

Figura 6. Diagrama de actividad del caso de uso [Localizar pedido].

DESARROLLO Anlisis

24
Caso de uso Crear nuevo pedido
Descripcin Crear un pedido nuevo para que sea llevado a cabo por la
empresa de paquetera en el tiempo establecido.
Actores Cliente.
Postcondiciones El pedido se crea correctamente.
Flujo bsico
1. El cliente elige la opcin Nuevo pedido en la pantalla inicial.
2. El sistema muestra un formulario con los datos requeridos.
3. El cliente rellena el formulario, con al menos los siguientes campos:
datos de quien enva el paquete, datos de quien lo recibe, tipo de
servicio y mtodo de pago. Luego pulsa en Continuar.
4. El sistema comprueba si el cliente est autenticado en el sistema.
5. El usuario confirma el pedido.
En el punto 4, si el cliente no ha iniciado sesin se lleva a cabo [Iniciar sesin].
Hasta que el cliente no confirme el pedido en el punto 5, puede cancelarlo en
cualquier momento.
Anotaciones No hay.

DESARROLLO Anlisis

25

Figura 7. Diagrama de actividad del caso de uso [Crear nuevo pedido].

DESARROLLO Anlisis

26
Caso de uso Iniciar sesin
Descripcin Autenticarse en el sistema con nombre de usuario y contra-
sea.
Actores Cliente.
Postcondiciones La sesin del cliente queda abierta en el sistema hasta que
este la cierre.
Flujo bsico
1. El cliente elige la opcin Iniciar sesin en la pantalla inicial.
2. El sistema muestra un formulario con dos campos: nombre de usuario
y contrasea.
3. El cliente introduce sus datos y pulsa sobre el botn de Iniciar sesin.
No siempre se accede a este caso a travs del punto 1, sino que se puede llegar
desde [Ver historial de pedidos] o [Crear nuevo pedido].
Si el nombre de usuario o la contrasea no son correctos se avisar al usuario a
travs de un mensaje de error.
Anotaciones No hay.

DESARROLLO Anlisis

27

Figura 8. Diagrama de actividad del caso de uso [Iniciar sesin].

DESARROLLO Diseo

28
2.2. Diseo
En el siguiente apartado se enumeran las decisiones tomadas a lo largo de este proyecto con respecto al
diseo de las interfaces de usuario, a la arquitectura del sistema y al almacenamiento de los datos.

2.2.1. Diseo de la interfaz de usuario
1. Aplicacin para los trabajadores.
Como se ha mencionado anteriormente, al comienzo de este proyecto la aplicacin destinada a los re-
partidores de la empresa de paquetera estaba casi finalizada. Sin embargo, el diseo de la misma no era
el adecuado, puesto que las exigencias de la empresa en el periodo de prcticas se haban dirigido ms
hacia el funcionamiento y no tanto al diseo.

Figura 9. Interfaces al comienzo del proyecto.

Las decisiones tomadas respecto a la interfaz de esta aplicacin fueron las siguientes:
Cambiar el contraste general, pasando del fondo negro al blanco o gris claro.
Cambiar la barra de ttulo predeterminada de Android por una personalizada, donde apareciera
el nombre de la aplicacin y el logotipo.
Cambiar los iconos del men por otros ms significativos.
Adaptar correctamente la aplicacin a pantallas de alta resolucin, especialmente en tablets,
puesto que hasta el momento no se haba gestionado la resolucin de las pantallas.
DESARROLLO Diseo

29
Establecer una paleta de colores para la aplicacin. Inicialmente se plante una paleta de naran-
jas, pero en una de las ltimas revisiones en la empresa se decidi cambiarla junto con los colo-
res de la pgina web a una paleta de verdes, como se puede apreciar en la Figura 10 y en la Figu-
ra 11.

Figura 10. Evolucin de la pantalla de inicio.

Figura 11. Evolucin de la pantalla de detalles de la tarea.
DESARROLLO Diseo

30
2. Aplicacin para los clientes.
En este caso, al partir de cero, haba que disear unos prototipos que se aproximasen a cmo iba a ser la
aplicacin una vez finalizada, con el objetivo de realizar los cambios oportunos en la fase de diseo y no
en la de implementacin.
A continuacin se muestran los primeros prototipos realizados. Por similitud no se muestran todos, el
resto aparecen en el Anexo 2 (Mockups).

Figura 12. Pantalla inicial.

Esta es la pantalla que aparece al iniciarse la aplicacin. A travs de los botones se puede acceder a las
tres funciones principales: seguimiento, histrico y nuevo pedido. Mediante el men, el usuario puede
loguearse y ver la informacin de la empresa de paquetera.
DESARROLLO Diseo

31

Figura 13. Pantalla del primer paso de nuevo pedido.

Cuando el usuario comience un nuevo pedido ver esta pantalla. El proceso de realizacin de un nuevo
pedido se ha dividido en tres pasos:
Datos personales: el usuario deber introducir los datos del remitente y del receptor del pa-
quete.
Pago: el usuario elegir el tipo de servicio y el mtodo de pago.
Revisin y finalizacin: el sistema mostrar un resumen con todos los datos que ha introducido
el usuario, para que este los revise y decida si finalizar el pedido o cancelarlo.

En el siguiente punto se mostrar el diagrama de navegacin de la aplicacin para los clientes.
DESARROLLO Diseo

32
2.2.2. Diagrama de navegacin

Menu -> About us Menu -> Login
New order Order tracking Order tracking (logged) Order history
Order details
Full details
Next step
Next step
DESARROLLO Diseo

33
2.2.3. Arquitectura del sistema
Las aplicaciones desarrolladas poseen una arquitectura de tres capas y dos niveles (cliente/servidor), ya
que algunos procesos de negocio y gran parte de los datos provienen del servidor web y de la base de
datos almacenada all.

Figura 14. Arquitectura en capas y niveles.

La capa de presentacin es la encargada de interactuar con los usuarios de la aplicacin. Est conforma-
da por mltiples archivos XML, uno por cada vista de la aplicacin.
La capa de lgica de negocio se encarga de realizar los procesos de la aplicacin. Hace de nexo entre la
capa de presentacin y la de persistencia.
La funcin de la capa de persistencia es acceder a los datos almacenados para consultarlos o modificar-
los. El almacenamiento de datos est especificado en la seccin 2.2.4.

2.2.4. Almacenamiento de datos
Al ser este un sistema distribuido, los datos se almacenan en tres ubicaciones distintas:
1. Base de datos del servidor. Aqu se almacena la mayor parte de la informacin del sistema, in-
cluyendo tareas, trabajadores y clientes. Cada vez que cualquiera de las aplicaciones Android
necesita obtener o actualizar un determinado dato, utiliza el servicio web adecuado creado por
el otro miembro del proyecto. De esta manera, la informacin ms importante del sistema est
DESARROLLO Diseo

34
almacenada en un nico lugar (base de datos) al que todas las aplicaciones Android pueden ac-
ceder va API.
2. Device Cloud de Etherios. La nube es el medio que hace posible recibir mensajes o notificacio-
nes desde la pgina web. nicamente se almacenan los ficheros con la posicin de los trabaja-
dores en tiempo real, las firmas digitalizadas de los clientes y las fotografas de perfil de los tra-
bajadores.
3. Dispositivo Android.
En el caso de la aplicacin para los repartidores, debido a que los datos que se iban a almacenar
en la memoria del dispositivo eran mnimos y se utilizaran en contadas ocasiones, el proyectan-
te decidi guardar la informacin en ficheros XML en vez de utilizar una base de datos.
El primer fichero est destinado a guardar los cambios en las tareas, y nicamente se utiliza
cuando el dispositivo pierde la conexin a Internet. En ese instante, entra en funcionamiento el
modo offline, que permite al trabajador seguir usando la aplicacin prcticamente igual que
cuando est conectada a la red. Todos los cambios producidos durante el tiempo que el disposi-
tivo no tenga conexin se guardarn en el fichero XML, localizado en el almacenamiento privado
de la aplicacin, y se subirn al servidor una vez vuelva la conexin.

<status_changes>
<task id="" status="" date="" details="" />
</status_changes>

En el anterior cdigo XML podemos observar la estructura del fichero. Por cada cambio que se
produzca en una tarea se aadir un nodo task, cuyos atributos son el identificador de la tarea,
el estado al que ha cambiado, la fecha y hora del cambio y los detalles.
El segundo fichero es el encargado de almacenar los mensajes que se reciben desde la aplicacin
web. El cdigo sera similar al anterior; por cada mensaje se guarda un nodo message, cuyos
hijos son el contenido del mensaje, la fecha y hora de recepcin y el identificador del remitente.
<messages>
<message>
<sender></sender>
<content></content>
<time></time>
</message>
</messages>

Por ltimo, se guarda un fichero de preferencias globales, que es gestionado por el S.O. Android.
En l se almacena los datos personales del repartidor, la ltima posicin y el hash de los datos
de acceso a la aplicacin.
DESARROLLO Diseo

35
En el otro caso, el de la aplicacin para los clientes, nicamente se almacena el fichero de prefe-
rencias con el nombre del cliente y el hash de los datos de acceso.

2.2.5. Patrones de diseo
Pese a que en la documentacin oficial no se hace referencia a ningn patrn, en realidad muchos auto-
res consideran que el sistema operativo implementa el patrn Modelo-Vista-Controlador (MVC). Esto es
debido a lo siguiente:
Se definen una serie de interfaces en ficheros XML.
Se definen una serie de recursos (locales, estructuras de datos) en ficheros XML.
Se extienden diversas clases, como listas o tabs, y se instancian dentro de sus correspondientes
vistas.
Se crean tantas clases como sean necesarias para el modelo.
Existen muchas clases que facilitan el acceso a bases de datos, HTML, etc.
Es por ello que al programar en Android, implcitamente, se usa el patrn MVC.
Adems, el proyectante ha utilizado el patrn Singleton en ambas aplicaciones, que garantiza que una
clase solo tenga una instancia, proporcionando un punto de acceso global a ella.
Android no permite modificar la interfaz grfica desde hilos que no sean el principal. Acciones tan bsi-
cas como mostrar un toast (mensaje en forma de popup) nicamente se pueden lanzar desde el hilo
principal, algo que puede ser un problema. Adems, es necesario en muchas ocasiones acceder a las
clases que gestionan la persistencia (tareas y mensajes). Por ello se decidi implementar el patrn Sin-
gleton en la clase principal de las aplicaciones, de manera que desde cualquier clase se pueda acceder a
todos los mtodos bsicos sin necesidad de crear objetos de esas clases.

public class PackagingApplication extends Application {

private static PackagingApplication instance;

public void onCreate() {
super.onCreate();
instance = this;

}

public static PackagingApplication getInstance() {
return instance;
}

}
DESARROLLO Diseo

36
2.2.6. Diseo de clases
Como se ha comentado anteriormente, ambas aplicaciones poseen una arquitectura de tres capas. To-
das ellas usan el modelo de objetos que se explicar ms adelante. Los siguientes diagramas y clases
pertenecen a la aplicacin para los clientes.

Figura 15. Diagrama de paquetes.

En el siguiente diagrama se muestran las clases correspondientes al modelo de objetos. Por simplicidad,
los accesores y modificadores de los atributos (getters y setters) se han obviado.

Figura 16. Diagrama de clases del modelo de objetos.
DESARROLLO Diseo

37
Como se puede observar, la clase Order es la ms relevante. Servir para almacenar los datos de cada
pedido que tenga un usuario. Las caractersticas ms importantes de un pedido son las siguientes:
Tendr un identificador nico (idTask).
Estar relacionado con dos clientes: el emisor y el receptor del paquete.
Almacenar una lista con todos los cambios de estado que se hayan producido.
A lo largo de su ciclo de vida pasar por varios estados, pero en un instante determinado solo
tendr uno.
Tendr asignado un nico tipo de servicio.

La capa de Lgica de negocio es la encargada de gestionar todas las operaciones internas de la aplica-
cin. Generalmente, cada pantalla de una aplicacin Android corresponde con una clase que extiende
de Activity (o de subclases de ella, como ListActivity o TabActivity).

Figura 17. Diagrama de clases de la capa de lgica de negocio.

Por ltimo, en la capa de Persistencia existirn dos clases: una gestionar los pedidos y la otra las prefe-
rencias de la aplicacin.

Figura 18. Diagrama de clases de la capa de persistencia.
DESARROLLO Diseo

38
2.2.7. Diseo del plan de pruebas
En esta seccin se van a especificar las pruebas que posteriormente se ejecutarn en la ltima fase del
desarrollo. Esta definicin va a servir como gua de testeo y como medio de verificacin de que todas las
partes del sistema cumplen los requisitos iniciales con unos niveles de calidad aceptables.
Se llevarn a cabo tres tipos de pruebas:
Pruebas unitarias: aquellas que sirven para asegurar que cada mdulo funciona de la manera
correcta.
Pruebas de integracin: aquellas en las que se verifica la validez de varios mdulos en conjunto.
Pruebas de aceptacin: aquellas que determinan si se cumplen o no los requisitos iniciales.

Cada prueba que se realice deber ser documentada mediante la siguiente plantilla:
Prueba n Tarea:
Descripcin
Procedimiento
Resultado

DESARROLLO Implementacin

39
2.3. Implementacin
Esta fase tiene como objetivo poner en prctica todas las caractersticas y reglas que se han ido estable-
ciendo en las dos fases anteriores. En este captulo se describen brevemente las principales tecnologas
usadas en el proyecto, las libreras externas que se han empleado, los problemas que han surgido y cul
ha sido la manera de resolverlos.

2.3.1. Tecnologas usadas
Como ya se ha sealado en varias ocasiones a lo largo de esta memoria, el proyecto est destinado a la
obtencin de dos aplicaciones para el sistema operativo Android.
Android no utiliza Java SE, sino que usa una implementacin libre de Java llamada Apache Harmony,
que alcanza el 97% de Java SE 6. La mquina virtual de Android se llama Dalvik, cuyo ncleo est basado
en Apache Harmony. Dalvik ejecuta ficheros .dex, que son versiones optimizadas de los ficheros .class.
Desde el punto de vista del desarrollador, Java de Android es similar a Java SE, pero sin las libreras
AWT/Swing y aadiendo APIs de Android personalizadas.

Figura 19. Diferencia entre Java VM y Dalvik VM.

En la actualidad, existen al menos dos formas para desarrollar aplicaciones en Android: con la ayuda de
un framework (como Titanium, Adobe AIR o PhoneGap) o desde el lenguaje nativo Java. Pese a que los
frameworks anteriormente citados poseen ciertas ventajas con respecto al desarrollo nativo, como la
mayor simplicidad o la exportacin a varios sistemas operativos, la realidad es bastante diferente.
A diferencia del desarrollo en iOS, donde hay dos nicos modelos de dispositivos, en Android existe una
gran variedad de terminales, pantallas y resoluciones, por lo que se hace ms complicado desarrollar

40
aplicaciones que funcionen y se visualicen correctamente en todos los dispositivos con el mismo cdigo.
Desarrollando en Android nativo con Java podremos:
1. Crear aplicaciones para todos los dispositivos Android, ya que comparten la misma API base.
2. No poner lmites a nuestras aplicaciones (puesto que el uso de los frameworks anteriores aca-
rrea unas ciertas limitaciones a la hora de acceder a ciertas funciones del terminal).
Por todo lo anterior, el proyectante decidi desarrollar las aplicaciones en Android nativo con Java,
usando el Software Development Kit (SDK) de Android, Eclipse como IDE y el plugin Android Develop-
ment Tools (ADT).
Para el desarrollo de las interfaces y elementos grficos se ha usado XML, puesto que es la manera ade-
cuada para hacerlo, recomendada por Google.

2.3.2. Libreras empleadas
Con el objetivo de facilitar el desarrollo de ciertas partes del proyecto, se han usado varias libreras ex-
ternas. Algunas de ellas (las relacionadas con la gestin de la nube) han sido proporcionadas por la em-
presa Digi International Spain.
1. Cloud Connector Android. Es una librera diseada por los desarrolladores de Digi para comuni-
car las aplicaciones Android con la Device Cloud. Permite, entre otros, detectar los cambios de
estado del Cloud Connector, recibir notificaciones o enviar ficheros a la nube.
2. Etherios Client Library. Es una librera diseada por los desarrolladores de Digi que permite co-
municar las aplicaciones Java con la Device Cloud. Su funcin principal es la de gestionar la co-
nexin con la nube.
3. Dom4j. Es una librera Java open source que sirve para trabajar con XML, XPath y XSLT. Es com-
patible con los estndares DOM, SAX y JAXP. Es usada en la transmisin de datos entre el servi-
dor web y los dispositivos Android, ya que se envan en XML.
4. Joda Time. Es una librera que sirve de reemplazo de las clases Java date y time. Permite tra-
bajar con fechas de una forma ms sencilla, potente y eficiente. La inclusin de intervalos y du-
raciones a la librera ha sido muy til a la hora de calcular las horas lmite de entrega de los pa-
quetes por parte de los repartidores.

2.3.3. Estructura del proyecto
A la hora de comenzar el proyecto, el propio Eclipse se encarga de crear el rbol de directorios, con las
carpetas y ficheros necesarios para su funcionamiento. Todo proyecto en Android se divide generalmen-
te en 6 carpetas: src, gen, assets, bin, libs y res, siendo las ms relevantes la primera y la ltima:

41
/src. Aqu se almacenan las actividades y el resto de clases creadas, con sus paquetes corres-
pondientes.

Figura 20. Contenido de la carpeta /src.

/res. Es la carpeta de recursos del proyecto. Est subdividida en,
como mnimo, 4 directorios:
- drawable: contiene ficheros bitmap, formas, animacio-
nes, imgenes, botones y otros elementos de dibujo.
- layout: en ella se encuentran los ficheros XML que co-
rresponden con las interfaces de la aplicacin.
- menu: contiene los ficheros XML que definen los mens
de las actividades.
- values: en ella se encuentran los ficheros XML que con-
tienen valores simples, como colores, cadenas de texto o
estilos.
Esta ltima carpeta puede contener adems variaciones de los 4 subdirectorios mencionados,
como se puede observar en la figura de la derecha. En este caso, las imgenes que se encuen-
tren en drawable-nodpi no se escalarn dependiendo de la resolucin de la pantalla; las interfa-
ces de layout-land se mostrarn cuando el dispositivo mvil est colocado en orientacin hori-
zontal (landscape); los valores que aparezcan en values-es sern visualizados cuando el idioma
del terminal se espaol
3

Otro elemento fundamental dentro de un proyecto es el AndroidManifest. Este fichero XML se genera
automticamente y en l se declaran todas las especificaciones de la aplicacin, como actividades, servi-
cios, nombre de la aplicacin, versin, hardware necesario o permisos que usa del sistema operativo. En
el Anexo 3 (AndroidManifest.xml) se pueden ver los ficheros de ambas aplicaciones.

3
La especificacin completa se puede leer en http://developer.android.com/tools/projects/index.html
Figura 21. Contenido de /res.

42
2.3.4. Desarrollo de las aplicaciones
Como se coment al inicio de esta memoria, el proyectante escogi Scrum como metodologa de desa-
rrollo. Esto implica ir haciendo el trabajo en pequeos incrementos (o sprints), en este caso de dos se-
manas, de manera que al finalizar cada sprint se obtenga una parte funcional de la aplicacin.
Por ello, en este apartado se profundizar en lo expuesto en el punto 1.4, es decir, se ir describiendo el
desarrollo realizado por cada sprint, los problemas que aparecieron y cmo el proyectante los resolvi
(las fases 1 y 2 corresponden con la finalizacin de la aplicacin para los repartidores; las siguientes con
la nueva aplicacin para los clientes).

Fase 1. Adaptacin del cdigo, incidencias y servicios y horas lmite
Al inicio del trabajo, el proyectante se encontr con una aplicacin sin finalizar, cuyas interfaces eran
austeras y rudimentarias (Figura 9), y cuyo cdigo solo era compatible con las versiones de Android
2.3.*. Todo esto desembocaba de la primera etapa del proyecto, el semestre de prcticas, debido a que
fue una fase de aprendizaje y adaptacin a Android, con el desarrollo de pequeas porciones funciona-
les de cdigo que luego se ensamblaran para formar la aplicacin.
El primer paso fue analizar el problema ms importante, es decir, por qu la aplicacin no funcionaba
correctamente en las nuevas versiones de Android.

Figura 22. Excepcin que apareca al arrancar la aplicacin.

Tras varias bsquedas en foros, se lleg a la siguiente conclusin: a partir de la versin 3.0 de Android no
se puede realizar una operacin de red en el hilo principal de la aplicacin. Hasta ese momento, todas
las llamadas a los servicios web del servidor (autenticacin, peticin o actualizacin de tareas) se ha-
can en dicho hilo, por lo que hubo que buscar una alternativa para el correcto funcionamiento de la
aplicacin: crear tareas asncronas. Se cre una clase llamada WebConnection, que extiende de
AsyncTask (clase utilizada para ejecutar tareas simples o atmicas en un hilo aparte), de manera que
cada vez que se desea realizar una conexin web se crea un objeto de esa clase, pasando la URL de co-
nexin y los parmetros.
Se advierte al lector de que todas las porciones de cdigo que se presenten a partir de ahora pueden no
corresponderse totalmente con el cdigo de la aplicacin, puesto que son pequeas reducciones para
ilustrar mejor los ejemplos.

43
Por ejemplo, para pedir al servidor la informacin relativa a la tarea cuyo identificador es 1111, creara-
mos un objeto de la clase WebConnection, llamaramos a su mtodo execute (pasndole los par-
metros adecuados), y por ltimo recogeramos el resultado mediante el mtodo get.

WebConnection connection = new WebConnection();
connection.execute("https://bybike-delivery.appspot.com/getTask", "idTask=1111");
result = connection.get();

public class WebConnection extends AsyncTask<String, Void, String> {
protected String doInBackground(String... params) {
String data = "";
URL url = null;
HttpURLConnection connection = null;
DataOutputStream dos = null;
DataInputStream dis = null;
try {
url = new URL(params[0]);
connection = (HttpURLConnection) url.openConnection();
connection.setDoInput(true);
connection.setDoOutput(true);
connection.setRequestMethod("POST");
connection.setRequestProperty("Content-Type",
"application/x-www-form-urlencoded");
connection.setRequestProperty("charset", "UTF-8");
connection.setRequestProperty("Content-Length", ""
+ Integer.toString(params[1].getBytes().length));
dos = new DataOutputStream(connection.getOutputStream());
dos.writeBytes(params[1]);
dos.flush();
dos.close();
dis = new DataInputStream(connection.getInputStream());

String line;
while ((line = dis.readLine()) != null)
data += line;
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (dos != null)
dos.close();
if (dis != null)
dis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return data;
}
}

44
En esta fase se implementaron adems los siguientes mdulos:
Notificacin de incidencias: cuando el repartidor pulse sobre el icono
de incidencia de la tarea aparecer un dilogo con una serie de inciden-
cias predeterminadas y un cuadro de texto, donde podr dar cualquier
detalle adicional del motivo de la incidencia.
Para ello se cre la clase ReportIncidenceDialog (que extiende de Dialog). En el mo-
mento en el que se crea un objeto de la clase debemos establecer el comportamiento del dilo-
go cuando se vaya a cerrar. En este caso la aplicacin volver a la actividad que ha creado el di-
logo a travs de un Intent.

ReportIncidenceDialog incidenceDialog = new ReportIncidenceDialog(context,
task);
incidenceDialog.setDialogResult(new OnMyDialogResult() {
@Override
public void finishTask(Task task) {
Intent intent = new Intent();
intent.putExtra("task", task);
setResult(RESULT_OK, intent);
finish();
}
});
incidenceDialog.show();

Implementacin de tipos de servicio y horas lmite: se crearon cuatro tipos de servicio, repre-
sentados por la enumeracin Service (ver Figura 16). Por cada tarea se guarda el tipo de ser-
vicio y la hora de creacin de la misma, que servir para calcular la hora lmite de entrega (espe-
cificada en el punto 2.1.2). Se aadi estas horas en la lista de tareas, y se cre un mtodo que
comprueba si queda menos de una hora para que llegue la hora lmite de una tarea; si es as,
muestra una alerta para que el repartidor se d cuenta de ello.
Ordenacin de las tareas en base a su prioridad: se cre la clase SortTasksByStatu-
sAndTime, que implementa a la interfaz Comparator<>, con el objetivo de poder ordenar la
lista de tareas en base a su estado (primero las que estn en progreso, despus las que estn sin
comenzar y por ltimo las que estn finalizadas) y a su hora lmite, para que el repartidor sepa
qu tarea debe hacer en cada momento.

Fase 2. Sincronizacin
Hasta este momento, la aplicacin funcionaba siempre y cuando estuviera conectada a Internet, bien a
travs de WiFi o de datos mviles. El proyectante pens que una caracterstica que podra dar valor a la
aplicacin era que pudiera ser utilizada en aquellos lugares donde no hubiera cobertura. Para ello, ide
un sistema mediante el que el repartidor pudiera seguir utilizndola en dichas zonas.

45
El primer paso fue detectar los cambios en la red, es decir, cundo el terminal perda la conexin a In-
ternet y cundo la recuperaba. La forma de hacerlo fue comprobando el estado del Cloud Connector
4
.
Para ello se cre la clase CloudConnectorStatusReceiver, cuya misin es captar los mensajes
de broadcast emitidos por el Cloud Connector cuando hay un cambio en el estado de la red del terminal.
Cuando se pierde la conexin se activa el modo offline; cuando vuelve, se regresa al modo online o
modo normal. En la siguiente figura se pueden observar las implicaciones de cada modo:

Figura 23. Implicaciones de ambos modos de conexin.

La principal consecuencia del paso al modo sin conexin es que todos los cambios que se produzcan en
las tareas deben ser almacenados localmente. Esto incluye tanto los cambios de estado como las firmas
digitalizadas de los clientes (que se generan cuando un envo es entregado). Cuando la conexin vuelve
al dispositivo, el sistema actualiza los cambios de las tareas en el servidor y sube las firmas almacenadas
a la nube.
Uno de los mayores problemas surgi en el mtodo creado para subir las firmas a la nube. Dicho mto-
do accede al almacenamiento privado de la aplicacin, lista todos los ficheros y aquellos cuya extensin
es .png (correspondientes con las firmas digitalizadas) son enviados a la nube mediante el Cloud Con-
nector, y borrados ms tarde. La anomala apareci a la hora de subirlas, puesto que el Cloud Connector
se cerraba repentinamente.

4
El funcionamiento del Cloud Connector se explica en el punto 1.1.

46
Tras mltiples pruebas, depuraciones y cambios en el cdigo se lleg a la siguiente conclusin: el mto-
do que proporciona el Cloud Connector para subir un fichero a la nube es, por defecto, asncrono. Tal
cual estaba el cdigo hasta ese momento, se invocaba dicho mtodo y seguidamente se borraba el fi-
chero .png, por lo que apareca una excepcin en el Cloud Connector y se cerraba. La solucin fue invo-
car al mtodo sncrono, con timeout 10 segundos, para subir un fichero (que devuelve true si la opera-
cin se ha realizado con xito o false en caso contrario) y borrarlo una vez subido.
En las siguientes porciones de cdigo se puede ver el antes y el despus:

PackagingApplication.getInstance().getCloudConnectorManager().
sendFile(Constants.FOLDER + File.separator + Constants.SIGNATURES_FOLDER +
File.separator + f.getName(), directory + File.separator +
f.getName());
f.delete();

if (PackagingApplication.getInstance().getCloudConnectorManager().
sendFile(Constants.FOLDER + File.separator + Constants.SIGNATURES_FOLDER +
File.separator + f.getName(), directory + File.separator +
f.getName(), false, 10000)) {
f.delete();
}

Fase 3. Creacin de las interfaces de la nueva aplicacin
La primera tarea de la nueva aplicacin para los clientes (despus del anlisis y diseo) fue el desarrollo
de las interfaces de usuario. Fue un proceso sencillo, puesto que solo haba que copiar los prototipos
realizados en el diseo y el proyectante ya dominaba la programacin de layouts en Android.

Figura 24. Estructura de los layouts de la aplicacin.

47
Todos los layouts tienen la misma estructura: un LinearLayout vertical que contiene 3 elementos, la
cabecera (siempre la misma), la barra de ttulo y el cuerpo de la actividad.
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical" >

<include layout="@layout/header" />

<RelativeLayout
android:id="@+id/layoutTitle"
>
</RelativeLayout>

<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
>
</LinearLayout>
</LinearLayout>
La mayor dificultad que encontr el proyectante fue en el layout de Nuevo pedido,
puesto que se quera simular un proceso en varios pasos (primero introducir los datos
del remitente y el receptor, luego elegir el tipo de servicio y por ltimo ver un resumen
antes de aceptar el pedido). Adems, se quera que fuese un proceso animado, con
transiciones de entrada y salida en cada paso.
Para ello se cre el layout new_order.xml, dentro del cual se utiliz el componente ViewFlipper, que
incluye los cuatro pasos del proceso de nuevo pedido (finalmente se decidi dividir el primer paso en
dos: informacin del remitente primero y luego la del receptor).
<ViewFlipper>
<include layout="@layout/new_order_step1" />
</ViewFlipper>
La clase NewOrderActivity es la encargada de gestionar las transiciones, de manera que cuando se
pulsa el botn de siguiente la animacin cambia de paso de derecha a izquierda.
btNext.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
viewFlipper.showNext();
}
});

48
En las ltimas semanas de desarrollo, cuando el proyecto estaba prcticamente acabado, la empresa
proporcion al proyectante un nuevo tablet para que probara la aplicacin, el Nexus 7 de Google. Este
tablet, de 7 pulgadas, posee una gran resolucin (800x1280, 216ppi), por lo que se present el problema
de que las interfaces se vean muy pequeas. Este inconveniente se resolvi de la siguiente manera: se
estableci que las interfaces diseadas hasta ese momento se muestren en dispositivos con resolucin
menor a 600dp (generalmente mviles de hasta 7 pulgadas). Para el resto de dispositivos (tablets de 7
pulgadas o ms), se duplicaron y adaptaron las interfaces existentes, y se introdujeron dentro de la car-
peta res/layout-sw600dp. El propio S.O. Android detecta la resolucin de la pantalla donde se est eje-
cutando la aplicacin y decide qu interfaces mostrar.

Fase 4. Funcionalidad de la aplicacin para los clientes
Una vez implementadas las interfaces de usuario, el siguiente paso fue dotar de funcionalidad a la apli-
cacin. Primero se crearon las clases correspondientes al modelo de objetos (ver Figura 16). Posterior-
mente, las diez clases que corresponden con la lgica de negocio, explicadas a continuacin.
Se recomienda al lector ver previamente las figuras del Anexo 2 (Mockups) y el punto 2.2.2 (Diagrama
de navegacin) para que le sea ms fcil la comprensin de las siguientes clases.
MainApplication. Esta clase, que extiende de Application, es la principal de la aplica-
cin. Sirve para mantener el estado a travs de todas las actividades y partes de la aplicacin,
implementando el patrn Singleton. A travs de su nica instancia, permite el acceso a las dos
clases de la persistencia. Adems, posee un mtodo pblico para que cualquier actividad o hilo
de la aplicacin pueda mostrar un toast (mensaje por pantalla) a travs del hilo principal.
/**
* Default handler to take care of UI actions called from other threads.
*/
private Handler handler = new Handler() {
public void handleMessage(Message msg) {
switch (msg.what) {
case ACTION_SHOW_TOAST:
Toast.makeText(MainApplication.this,
msg.getData().getString("message"),
Toast.LENGTH_LONG).show();
break;
}
}
};
HomeActivity. Es la actividad inicial, aquella que aparece cuando la aplicacin es ejecutada.
Implementa el funcionamiento de los tres botones (ver Figura 12) y crea un men para acceder
al login y a la informacin de la empresa.

49
LoginActivity. Esta actividad es la encargada de loguear al usuario. Cuando se pulsa el bo-
tn de iniciar sesin, el mtodo handleSignPressed() verifica la autenticidad del usuario
llamando al servicio web /clientIdentification, al que le pasa el hash de user:password. Si la veri-
ficacin es correcta, almacena el nombre del usuario en las preferencias globales y retorna a la
actividad que haba invocado al login; si no lo es, muestra un mensaje por pantalla.
TrackingActivity. El cometido de esta actividad es localizar el o los pedidos en curso de
un cliente o un usuario no registrado en el sistema. Por ello, esta actividad cuenta con dos vis-
tas: si hay un cliente en la sesin, llama al mtodo de la persistencia getProgressOr-
ders() y muestra una lista con los pedidos en curso de dicho cliente; si no lo hay, presenta un
cuadro de texto donde el usuario puede introducir un nmero de seguimiento para ver los deta-
lles de su pedido. En ambos casos se permite escanear un cdigo QR asociado a un pedido para
ver sus detalles. Cuando el usuario pulsa sobre un pedido de la lista o hace clic sobre el botn
de localizar, la aplicacin inicia la actividad OrderDetailsActivity.

Figura 25. Comparacin de ambas vistas.

OrderDetailsActivity. Esta actividad recibe a travs del intent de llamada un objeto
de la clase Order, que contiene todos los detalles del pedido seleccionado. Muestra al usuario
una tabla con el trnsito del pedido, es decir, cada fila corresponde con un cambio de estado de
la tarea. Adems, proporciona un botn para acceder a los detalles completos de la misma.
OrderFullDetailsActivity. Una de las actividades ms simples de la aplicacin. Su ni-
ca tarea es recoger el objeto pedido del intent y mostrar al usuario todos los detalles del
mismo.
HistoryActivity. Es la actividad encargada de mostrar todos los pedidos que ha realizado
un usuario. Para ello, llama al mtodo de la persistencia getOrders(), que devuelve un obje-

50
to del tipo List<Order>. Al igual que ocurra en la actividad de tracking, cuando el usuario
pulsa sobre un pedido se inicia la actividad OrderDetailsActivity. Por ltimo, se le pro-
vee al usuario de un cuadro de texto donde poder buscar o filtrar los pedidos (a travs de su
identificador o de su estado). A medida que el usuario escribe en el cuadro, la lista de pedidos
se va actualizando. En el siguiente cdigo se puede observar cmo est implementada esta ca-
racterstica:

private void initializeUI() {

etSearch = (EditText)findViewById(R.id.etSearch);
TextWatcher fieldValidatorTextWatcher = new TextWatcher() {

@Override
public void onTextChanged(CharSequence s, int start, int before,
int count) {
updateList(etSearch.getText().toString().toLowerCase());
}
};
etSearch.addTextChangedListener(fieldValidatorTextWatcher);
}
private void updateList(String text) {
if (orders != null) {
ArrayList<Order> filter = new ArrayList<Order>();
for (Order o : orders) {
if (o.getIdTask().contains(text) ||
o.getStatus().getName().toLowerCase().contains(text))
filter.add(o);
}
ordersAdapter = new OrdersAdapter(context, R.layout.order_item,
filter, getLayoutInflater());
getListView().setAdapter(ordersAdapter);
}
}

NewOrderActivity. Actividad encargada de gestionar el proceso de un nuevo pedido. Co-
mo ya se coment anteriormente, este proceso est compuesto de cuatro pasos. En el primero
y segundo se presenta al usuario una serie de cuadros de texto para que introduzca los datos
del emisor y receptor del paquete. Las nicas comprobaciones que se hacen en ese momento es
que todos los campos excepto el telfono estn rellenados. En el tercer paso el usuario debe
elegir el tipo de servicio y mtodo de pago. Adems, puede adjuntar detalles especficos rela-
cionados con el envo. Antes de cargar este paso, el sistema comprueba en base a la hora del
dispositivo qu servicios estn disponibles en ese momento para mostrarlos en el spinner. El
cuarto y ltimo paso sirve para que el usuario verifique que toda la informacin es correcta,
mostrando todos los valores introducidos en los anteriores pasos. Cuando el usuario pulse so-

51
bre el botn de finalizar, el sistema llamar al mtodo de creacin de pedido de la persistencia y
mostrar en un dilogo el resultado de la operacin.
StoredAddressesActivity. Cada vez que un usuario realiza un nuevo pedido, interna-
mente en el servidor se almacenan los datos del remitente y del receptor como favoritos, con
el objetivo de agilizar futuros pedidos a los mismos clientes. Por ello, esta actividad obtiene esas
direcciones favoritas del servidor y las muestra en una lista, permitiendo que el usuario no ten-
ga que volver a escribir los datos. A esta actividad se accede a travs del men de NewOrde-
rActivity. La idea de crear esta actividad surgi en pleno desarrollo del proceso de nuevos
pedidos, por lo que no est contemplada en los prototipos iniciales.
AboutUsActivity. Es la actividad ms simple de la aplicacin y no tiene funcionalidad algu-
na. nicamente muestra informacin sobre la empresa y sus tipos de servicios. Estos datos es-
tn almacenados en la carpeta de recursos (res/values/strings.xml) de la aplicacin.

Figura 26. Vista de las direcciones almacenadas y la informacin de la empresa.

Por ltimo, se crearon las dos clases de la capa de persistencia: PreferencesManager y Orders-
Manager. La primera de ellas gestiona las preferencias de la aplicacin (en este caso nombre de usua-
rio y hash) en el almacenamiento interno de Android. Para ello, utiliza un objeto de la clase Sha-
redPreferences, que proporciona mtodos put y get para escribir y leer del fichero de preferen-
cias.
Por otro lado, la clase OrdersManager es la encargada de realizar las peticiones web, obtener las
respuestas en formato XML y parsearlas. En todas las llamadas a servicios web es necesario pasar el
hash como mtodo de validacin del usuario (exceptuando en el de tracking de un nico pedido).
DESARROLLO Pruebas

52
2.4. Pruebas
Como se estableci en el punto 2.2.7 Diseo del plan de pruebas, se van a realizar tres tipos de pruebas:
unitarias, de integracin y de aceptacin. Cabe destacar que, al estar utilizando una metodologa de
desarrollo gil, las pruebas unitarias se fueron haciendo a medida que se iba desarrollando la aplicacin.

1. Pruebas unitarias (solo se incluyen las ms importantes, el resto se pueden ver en el Anexo 4,
Pruebas unitarias). Las dos primeras corresponden con la aplicacin para los repartidores; las
dos ltimas a la aplicacin para los clientes.

Prueba n 1.1 Tarea: Envo de incidencia
Descripcin Reporte de una incidencia sobre una tarea no finalizada.
Procedimiento
En la actividad de detalles de tarea, el repartidor pulsa
sobre el icono de incidencia. En el dilogo que aparece
selecciona una incidencia de las que se muestran en el
spinner y, si desea, aade un comentario en el cuadro de
texto.
Resultado
CORRECTO. La incidencia es enviada correctamente y la
aplicacin regresa a la pantalla inicial, donde la tarea mar-
cada aparece ahora como incidencia.

Prueba n 1.2 Tarea: Ordenacin de tareas por prioridad
Descripcin
La lista de tareas que ve el repartidor est ordenada segn
el estado de las mismas y su hora lmite.
Procedimiento No hay ninguna accin por parte del repartidor.
Resultado
CORRECTO. Las tareas, a medida que llegan a la aplicacin,
se van ordenando segn su estado, y dentro de un mismo
estado, por la hora lmite de entrega.

DESARROLLO Pruebas

53
Prueba n 2.1 Tarea: Login
Descripcin
Identificacin en el sistema a travs de la cuenta de usua-
rio (nombre de usuario y contrasea).
Procedimiento
El usuario, desde la pantalla inicial de la aplicacin, accede
a la actividad de Login desde el men o pulsando sobre los
botones de Mis pedidos o Nuevo pedido. Despus, in-
troduce sus credenciales y pulsa el botn Iniciar sesin.
Resultado
CORRECTO. Si las credenciales son correctas, la aplicacin
loguea al usuario, guarda su nombre y hash en las prefe-
rencias de la aplicacin y regresa a la actividad de proce-
dencia. Si no, aparece un mensaje de error.

Prueba n 2.2 Tarea: Localizacin con tracking number
Descripcin
Localizacin de un pedido introduciendo su nmero de
seguimiento.
Procedimiento
El usuario, sin haber iniciado sesin, accede a la actividad
de Localizar pedido e introduce su nmero de segui-
miento. Por ltimo, pulsa sobre el botn Localizar.
Resultado
CORRECTO. Si el nmero de seguimiento coincide con un
pedido, se muestra la actividad Detalles del pedido, con
la tabla del trnsito del pedido. Si no, muestra un mensaje
avisando que no existe ningn pedido con ese cdigo.

DESARROLLO Pruebas

54
2. Pruebas de integracin.

Prueba n 1.1 Tarea: Sincronizacin
Descripcin
Actualizacin en el servidor de cambios de estado de ta-
reas y firmas digitalizadas cuando el terminal estaba en
modo sin conexin.
Procedimiento
No hay ninguna accin por parte del usuario. La aplicacin,
en el momento en el que recupera la conexin a Internet,
actualiza en el servidor los cambios de estado de las tareas
y sube a la nube las firmas digitalizadas.
Resultado
CORRECTO. Cuando la aplicacin recupera la conexin a la
red: quita el icono de modo offline, sube los cambios de
estado y las firmas y avisa mediante un mensaje al usuario
de que el proceso ha finalizado correctamente. Si no hay
ningn cambio de estado o ninguna firma, no aparece nin-
gn mensaje.

Prueba n 2.1 Tarea: Nuevo pedido
Descripcin Proceso de creacin de un nuevo pedido.
Procedimiento
El usuario, una vez ha iniciado sesin, accede desde el
inicio a Nuevo pedido. En el primer paso introduce los
datos del remitente del pedido; en el segundo, los del emi-
sor; en el tercero debe seleccionar el tipo de servicio y el
mtodo de pago; por ltimo, en el cuarto puede verificar
los datos introducidos anteriormente. Si est conforme,
pulsar sobre el botn Finalizar. Si no, sobre Cancelar.
Resultado
CORRECTO. Si hay disponibilidad de repartidores y todos
los datos introducidos son correctos, aparecer un dilogo
avisando de que el proceso se ha completado correctamen-
te. Si no la hay, se avisa de que el servicio no est disponi-
ble. Por el contrario, si el usuario decide cancelar el pedi-
do, la aplicacin regresa a la actividad inicial.

DESARROLLO Pruebas

55
3. Pruebas de aceptacin.
A lo largo del proyecto, la revisin del trabajo realizado por parte de la empresa ha sido constante, pues-
to que cada dos semanas se convocaba una reunin para exponer los avances del mismo, que tambin
serva para proponer cambios o mejoras en las aplicaciones.
Durante los meses de abril y mayo, ambas aplicaciones fueron presentadas en varias ocasiones a los
miembros responsables de la empresa, haciendo en las ltimas reuniones una demo del sistema com-
pleto (aplicaciones Android y aplicaciones web). En la ltima, se obtuvo el visto bueno de ambas aplica-
ciones, con lo que se dio por finalizado el desarrollo del proyecto.

56
Captulo 3. Conclusiones
En este ltimo apartado se resumen las conclusiones ms importantes de este proyecto. Se ha evaluado
el grado de cumplimiento de los objetivos iniciales y se exponen los problemas planteados y el mtodo
de resolucin, los conocimientos adquiridos por el proyectante en el desarrollo del mismo y las futuras
mejoras que no se han podido implementar por falta de tiempo.

3.1. Evaluacin de objetivos
En la primera parte de la memoria se mencionaron los objetivos de este proyecto. Estos se dividieron en
tres niveles: objetivo general, objetivos a nivel del sistema y objetivos a nivel de las aplicaciones An-
droid. Se analizarn de modo inverso a lo expuesto, es decir, de los ms concretos a los ms abstractos.
En cuanto a las aplicaciones Android: se ha finalizado correctamente y segn lo planificado la de los
repartidores, modificando determinados aspectos como la interfaz de usuario, y se ha desarrollado la
nueva aplicacin para los clientes, con las tres funciones bsicas. Adems, ambas aplicaciones son intui-
tivas y fciles de usar, funcionan tanto en smartphones como en tablets y son compatibles con cualquier
versin del sistema operativo superior a la 2.3.3.
Con respecto al sistema global (visto como la unin de los dos trabajos de los alumnos), se ha logrado
que ambas plataformas se comuniquen, bien a travs de la Device Cloud o de Google App Engine. El
sistema ha sido probado por varios miembros de la empresa Digi y ha contado con el visto bueno de
todos los responsables, as como el vdeo promocional, que ha causado muy buenas sensaciones.
Por ltimo, analizando el objetivo general del proyecto (desarrollar un sistema completo y fcil de usar
que se encargue de la logstica necesaria para el buen funcionamiento de una empresa de paquetera a
pequea escala), se considera que se ha cumplido casi en su totalidad. Pese a que el sistema podra im-
plantarse tal y como est en una empresa de esas caractersticas, quizs haya cuestiones que mejorar o
aadir para poder competir con los sistemas similares presentes en el mercado.

3.2. Problemas planteados y procedimiento para su resolucin
A pesar de que durante la fase de desarrollo ya se fueron mencionando los problemas que surgieron, se
ha decidido resumirlos aqu para un mejor anlisis de los mismos.
Uno de los primeros problemas que surgi en el desarrollo fue el no funcionamiento de la aplicacin
para los repartidores en versiones superiores a la 3.0 de Android. Esto se debi a que no se siguieron las
recomendaciones de Android, puesto que se llevaban a cabo operaciones de red en el hilo principal de
la aplicacin, algo que se resolvi introduciendo tareas asncronas.
CONCLUSIONES Conocimientos adquiridos

57
El cambio ha sido un constante inconveniente a lo largo de proyecto. Como se ha comentado anterior-
mente, cada dos semanas haba una reunin con los responsables de la empresa, y en muchas de ellas
se planteaban cambios y mejoras en las aplicaciones. En el caso de las mejoras no significaba tanto pro-
blema, pero hacer efectivo un cambio significaba haber perdido horas o das de trabajo. Sin embargo,
pese a todos los cambios que se han llevado a cabo, el proyecto se ha conseguido finalizar en el plazo
previsto y dentro del margen de horas estimadas.
Otro problema que surgi en el mes de marzo fue el cambio de marca corporativa de la nube de disposi-
tivos. Hasta entonces, la nube se llamaba iDigi Device Cloud, pero debido a la adquisicin de Etherios
por parte de Digi, decidieron hacer un rebranding, con lo que pas a llamarse Etherios Device Cloud.
Esto afect al proyecto ya que hubo que cambiar y refactorizar todas las clases que dependen de la nu-
be, sustituyendo tambin las libreras y el iDigi Connector por el Cloud Connector.
Por ltimo, otra complicacin que surgi en la parte final del proyecto fue la mala adaptacin de las
interfaces a pantallas con grandes resoluciones. Durante el desarrollo de las aplicaciones, los medios
para probarlas fueron un tablet de 7 pulgadas y un smartphone de 4,7. En las ltimas semanas, se insta-
laron las aplicaciones en un tablet de gran resolucin y qued de manifiesto su mala adaptacin. Esto se
resolvi acudiendo a la documentacin oficial de Android, que dio las claves al proyectante para corregir
las interfaces y que se visualizaran de manera correcta.

3.3. Conocimientos adquiridos
No cabe duda de que despus de trabajar tanto tiempo sobre la plataforma Android, una de las destre-
zas ms importantes adquiridas ha sido esa, la programacin de aplicaciones para este sistema operati-
vo. Cuando el proyectante comenz a elaborar este trabajo ya posea cierta base en esta plataforma, ya
que durante los meses de prcticas previos a este trabajo se inici la construccin del sistema, lo que
implic semanas de aprendizaje. Adentrarse en el mundo de las tecnologas mviles ha resultado una
muy buena experiencia para el proyectante, pudiendo asegurar que estas solo han sido las primeras de
muchas aplicaciones que desarrollar, tanto en Android como en otras plataformas.
Adems, las habilidades transversales adquiridas a lo largo de este trabajo han sido muy positivas.
Aprender a solucionar problemas sin la supervisin de un profesor, trabajar en equipo, guiar tu propio
proyecto o desarrollar en el mbito de una empresa son cuestiones que han ayudado al proyectante a
acercarse ms al mundo laboral que le espera.
El proyectante ha aprendido que quien manda puede cambiar de opinin, y lo que hace una semana
haba que hacerlo de una manera ahora hay que hacerlo de otra, y adems hay que hacerlo ya. Es decir,
hay que estar constantemente preparado para el cambio y es posible que todo el trabajo de das o se-
manas no valga para nada y haya que cambiarlo.
Y, aunque no se ha mejorado demasiado el nivel, este trabajo ha hecho que el proyectante se d cuenta
de la importancia que tiene el ingls en el campo de las tecnologas. Formar parte de una multinacional
CONCLUSIONES Mejoras del proyecto

58
norteamericana ha implicado escribir (documentacin, presentaciones, correos electrnicos) e incluso
exponer el proyecto en ingls ante ejecutivos de la delegacin estadounidense, por lo que queda de
manifiesto la importancia del buen manejo de este idioma.

3.4. Mejoras del proyecto
Debido a la limitacin horaria y temporal de este trabajo, ha sido imposible llevar a cabo ideas que se
propusieron antes de comenzar con l. Ejemplos de esas ideas son:
Comunicacin mediante mensajes del dispositivo mvil a la pgina web. En la aplicacin para los
repartidores solo se permite que la empresa enve mensajes a sus trabajadores. Una mejora se-
ra que estos pudieran tambin responder.
Reiniciacin de tareas marcadas como incidencia. En el estado actual de la aplicacin, una vez
que se marca una tarea como incidencia no se puede volver a iniciar. Lo ideal sera que se pudie-
ra reiniciar para entregar el paquete en otro momento.
Generacin de cdigos QR para pegatinas. Segn como est diseado el sistema, el repartidor
debe llevar pegatinas pre-impresas para pegar en los paquetes que recoge. Cada cdigo QR de
las pegatinas tiene una numeracin distinta, como medio de identificacin nica del paquete.
Podra ser mejor que el repartidor imprimiera el cdigo en el momento de recoger el paquete.
Utilizacin de la localizacin del repartidor en el seguimiento de un pedido. Algo que podra
agradar a los clientes es ver sobre un mapa dnde se encuentra su pedido. Para ello, podra uti-
lizarse la localizacin del terminal que se utiliza para controlar a los repartidores.
Implementacin de los mtodos de pago. Puesto que la aplicacin no est destinada, en princi-
pio, a venderse a una empresa real, no se implementaron los mtodos de pago. Si fuera a ser
utilizada por una compaa real habra que implementar las pasarelas de pago para poder solici-
tar un envo.

59
Captulo 4. Bibliografa
Ed Burnette (2010). Hello Android. Introducing Googles Mobile Development Platform.
Pragmatic Bookshelf.
Mark L. Murphy (2009). The Busy Coders Guide to Advanced Android Development.
CommonsWare.
Sayed Hashimi, Satya Komatineni, Dave MacLean (2010). Pro Android 2. Apress.
Project Management Institute (2008). Gua de los Fundamentos para la Direccin de
Proyectos. PMI.
http://www.android.com
http://developer.android.com
http://stackoverflow.com
Trabajo de Fin de Grado
Rubn Moral Miera
1
Anexos
Anexo 1. Casos de uso
En este anexo se enumeran el resto de casos de uso de la aplicacin para los clientes:

Caso de uso Cerrar sesin
Descripcin Finalizar la sesin abierta en [Iniciar sesin].
Actores Cliente.
Precondiciones La sesin del cliente debe estar abierta.
Postcondiciones La sesin del cliente queda cerrada.
Flujo bsico
1. El cliente elige la opcin Cerrar sesin en la pantalla inicial.
2. El sistema muestra un aviso pidiendo la confirmacin del usuario.
3. El cliente pulsa sobre aceptar.
No hay.
Anotaciones La opcin de cerrar sesin solo aparecer en el men inicial
cuando la sesin se encuentre abierta.

Caso de uso Ver detalle pedido
Descripcin Mostrar los detalles del pedido seleccionado.
Actores Cliente.
Precondiciones El cliente ha tenido que pulsar en un pedido en [Localizar
pedido] o en [Ver historial de pedidos].
Postcondiciones Se muestra en detalle el pedido, as como una lista con los
estados por los que ha ido pasando.
Flujo bsico
1. El cliente pulsa sobre el pedido.
2. El sistema muestra la informacin relativa a ese pedido.
No hay.
Anotaciones No hay.
ANEXOS Casos de uso
2
Caso de uso Ver historial de pedidos
Descripcin Mostrar una lista con los pedidos realizados de un cliente.
Actores Cliente.
Precondiciones El cliente debe estar autenticado.
Postcondiciones Se muestra una lista con todos los pedidos que ha realizado
el cliente.
Flujo bsico
1. El cliente elige la opcin Historial de pedidos en la pantalla inicial.
2. El sistema comprueba si el cliente est autenticado.
3. El sistema muestra una lista con todos los pedidos realizados por el
cliente.
En el punto 2, si el cliente no ha iniciado sesin se lleva a cabo [Iniciar sesin].
Tras el punto 3, el cliente puede pulsar sobre un pedido de la lista e ir a [Ver
detalle pedido].
Anotaciones No hay.

Caso de uso Escanear cdigo QR
Descripcin A travs de la cmara del dispositivo se escanea un cdigo
QR que lleva implcito el nmero de seguimiento.
Actores Cliente.
Precondiciones El cliente ha tenido que pulsar el icono de la cmara en
[Localizar pedido].
Postcondiciones El nmero de seguimiento implcito en el cdigo es
devuelto a [Localizar pedido].
Flujo bsico
1. El cliente sita la cmara del dispositivo sobre el cdigo QR,
quedando alineado este con el cuadro delimitado en la pantalla.
2. El sistema escanea el cdigo y avisa al usuario mediante un pitido.
3. El sistema lleva a cabo el punto 4 de [Localizar pedido].
Si lo que se est escaneando no es un cdigo QR, el sistema mantendr la
pantalla de escaneo.
Anotaciones No hay.
ANEXOS Mockups
3
Anexo 2. Mockups

Figura 1. Pantalla inicial.
ANEXOS Mockups
4

Figura 2. Men de la pantalla inicial
ANEXOS Mockups
5

Figura 3. Pantalla de informacin de la empresa.
ANEXOS Mockups
6

Figura 4. Pantalla de login y registro.
ANEXOS Mockups
7

Figura 5. Pantalla de inicio con usuario logueado.
ANEXOS Mockups
8

Figura 6. Men de la pantalla inicial con usuario logueado.
ANEXOS Mockups
9

Figura 7. Pantalla de confirmacin de cierre de sesin.
ANEXOS Mockups
10

Figura 8. Pantalla de inicio horizontal.
ANEXOS Mockups
11

Figura 9. Pantalla de seguimiento de pedidos.
ANEXOS Mockups
12

Figura 10. Pantalla de detalles del pedido.
ANEXOS Mockups
13

Figura 11. Pantalla de detalles completos.
ANEXOS Mockups
14

Figura 12. Pantalla de seguimiento si el usuario est logueado.
ANEXOS Mockups
15

Figura 13. Pantalla de histrico de pedidos.
ANEXOS Mockups
16

Figura 14. Pantalla del primer paso de un nuevo pedido.
ANEXOS Mockups
17

Figura 15. Pantalla del segundo paso de un nuevo pedido.
ANEXOS Mockups
18

Figura 16. Pantalla del tercer paso de un nuevo pedido.
ANEXOS Mockups
19

Figura 17. Pantalla de confirmacin del pedido.
ANEXOS Mockups
20

Figura 18. Pantalla de aviso del nuevo pedido.

ANEXOS AndroidManifest.xml
21
Anexo 3. AndroidManifest.xml
Aplicacin para repartidores:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.digi.android.etherios.packaging"
android:installLocation="auto"
android:versionCode="1"
android:versionName="1.0" >

<uses-sdk
android:minSdkVersion="10" />

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.VIBRATE" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.CALL_PHONE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.CAMERA" />


<uses-permission android:name="com.digi.connector.android.DATA_SERVICE" />
<uses-permission android:name="com.digi.connector.android.DEVICE_REQUEST" />

<uses-feature
android:name="android.hardware.camera"
android:required="false" />
<uses-feature
android:name="android.hardware.camera.front"
android:required="false" />

<application
android:name="com.digi.android.etherios.packaging.PackagingApplication"
android:allowBackup="true"
android:icon="@drawable/ic_launcher_icon"
android:label="@string/app_name"
android:theme="@android:style/Theme.Light.NoTitleBar" >
<activity
android:name="com.digi.android.etherios.packaging.LoginActivity"
android:screenOrientation="portrait"
android:theme="@android:style/Theme.Black.NoTitleBar" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name="com.digi.android.etherios.packaging.PackagingActivity"
android:launchMode="singleTask"
android:screenOrientation="portrait" >
</activity>
<activity
android:name="com.digi.android.etherios.packaging.HomeActivity"
22
android:label="@string/home"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.TasksActivity"
android:label="@string/tasks"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.MessagesActivity"
android:label="@string/messages"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.TaskDetailsActivity"
android:label="@string/task_details"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.FilterActivity"
android:label="@string/filter"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.MapActivity"
android:label="@string/map"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.SettingsActivity"
android:label="@string/settings"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.ProfileActivity"
android:label="@string/profile"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.RegistrationActivity"
android:label="@string/registration"
</activity>
<activity
android:name="com.digi.android.etherios.packaging.SignatureActivity"
android:label="@string/signature"
</activity>


<receiver android:name="com.digi.connector.android.library.core.DeviceRequestReceiver"
>
<intent-filter>
<action android:name="com.digi.connector.android.DEVICE_REQUEST" />
<category android:name="android.intent.category.HOME" />
</intent-filter>
</receiver>
<receiver
android:name="com.digi.connector.android.library.core.SendFileStatusReceiver" >
<intent-filter>
23
<action android:name="com.digi.connector.android.UPLOAD_FILE_STATUS" />
</intent-filter>
</receiver>
<receiver android:name="com.digi.connector.android.library.core.DeviceIDReceiver" >
<intent-filter>
<action android:name="com.digi.connector.android.DEVICE_ID" />
</intent-filter>
</receiver>
<receiver android:name="com.digi.connector.android.library.core.ServiceStatusReceiver"
>
<intent-filter>
<action android:name="com.digi.connector.android.SERVICE_STATE" />
</intent-filter>
</receiver>
<receiver
android:name="com.digi.connector.android.library.core.ServiceStatusChangeReceiver" >
<intent-filter>
<action android:name="com.digi.connector.android.SERVICE_STATE_CHANGED" />
</intent-filter>
</receiver>
<receiver
android:name="com.digi.android.etherios.packaging.receivers.CloudConnectorStatusReceiver" >
<intent-filter>
<action android:name="com.digi.connector.android.SERVICE_STATE_CHANGED" />
</intent-filter>
</receiver>

<service
android:name="com.digi.android.etherios.packaging.location.CurrentLocationService" />

<uses-library
android:name="com.google.android.maps"
android:required="true" />
</application>
</manifest>
24
Aplicacin para clientes:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.digi.android.bybike"
android:versionCode="1" android:versionName="1.0" >
<uses-sdk android:minSdkVersion="10" android:targetSdkVersion="10" />
<uses-permission android:name="android.permission.INTERNET" />
<application
android:name="com.digi.android.bybike.MainApplication"
android:allowBackup="true"
android:icon="@drawable/ic_launcher_icon"
android:theme="@android:style/Theme.Light.NoTitleBar" >
<activity
android:name="com.digi.android.bybike.HomeActivity"
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name="com.digi.android.bybike.LoginActivity"
android:label="@string/title_activity_login" >
</activity>
<activity
android:name="com.digi.android.bybike.TrackingActivity"
android:label="@string/title_activity_tracking" >
</activity>
<activity
android:name="com.digi.android.bybike.HistoryActivity"
android:configChanges="keyboardHidden|orientation"
android:label="@string/title_activity_history" >
</activity>
<activity
android:name="com.digi.android.bybike.NewOrderActivity"
android:configChanges="keyboardHidden|orientation"
android:label="@string/title_activity_new_order" >
</activity>
<activity
android:name="com.digi.android.bybike.OrderDetailsActivity"
android:label="@string/title_activity_order_details" >
</activity>
<activity
android:name="com.digi.android.bybike.OrderFullDetailsActivity"
android:label="@string/title_activity_order_full_details" >
</activity>
<activity
android:name="com.digi.android.bybike.AboutUsActivity"
android:label="@string/title_activity_about_us" >
</activity>
<activity
android:name="com.digi.android.bybike.StoredAddressesActivity"
android:label="@string/title_activity_stored_addresses" >
</activity>
</application>
</manifest>
ANEXOS Pruebas unitarias
25
Anexo 4. Pruebas unitarias
Prueba n 2.3 Tarea: Localizacin de pedidos en curso
Descripcin
Localizacin de todos los pedidos en curso de un usuario
que ha iniciado sesin anteriormente.
Procedimiento
inicio a Localizar pedido.
Resultado
CORRECTO. Se muestra una lista con todos los pedidos en
curso de dicho cliente. Si no tiene ninguno, la lista aparece
vaca.

Prueba n 2.4 Tarea: Histrico de pedidos
Descripcin
Identificacin de todos los pedidos que haya realizado un
usuario registrado.
Procedimiento
inicio a Mis pedidos.
Resultado
CORRECTO. Se muestra una lista con todos los pedidos de
dicho cliente. Si no tiene ninguno, la lista aparece vaca.

Prueba n 2.5 Tarea: Bsqueda y filtro en Mis pedidos
Descripcin
Bsqueda y filtrado de pedidos en la actividad Mis
pedidos
Procedimiento
inicio a Mis pedidos. Una vez all, escribe una cadena de
texto en el cuadro de bsqueda.
Resultado
CORRECTO. A medida que va tecleando el usuario se van
filtrando los pedidos en base a su identificador o a su
estado.

ANEXOS Pruebas unitarias
26
Prueba n 2.6 Tarea: Direcciones almacenadas
Descripcin Listado de las direcciones favoritas de un usuario.
Procedimiento
inicio a Nuevo pedido. Tanto si se encuentra en el primer
paso como en el segundo, accede al men y pulsa sobre
Direcciones almacenadas.
Resultado
CORRECTO. Si el usuario ha realizado un pedido
anteriormente se muestra una lista con todas las
direcciones empleadas. Si no, la lista aparece vaca.

TFE000296

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TFE000296

Transféré par

Droits d'auteur :

Formats disponibles

Rubn Moral Miera

Desarrollo e implementacin de una solucin completa

Vous aimerez peut-être aussi