desarrollo de un prototipo de software ...repository.udistrital.edu.co/bitstream/11349/7136/1...el...

DESARROLLO DE UN PROTOTIPO DE SOFTWARE MÓVIL PARA IMPLEMENTAR UN TAXIMETRO ENFOCADO AL CONTROL DEL SERVICIO

ANGÉLICA MARÍA BABATIVA GOYENECHE

PAULA DANIELA BRICEÑO NOVOA

UNIVERSIDAD DISTRITAL FRANCISO JOSÈ DE CALDAS

FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

BOGOTÁ D.C

DESARROLLO DE UN PROTOTIPO DE SOFTWARE MÓVIL PARA IMPLEMENTAR UN TAXIMETRO ENFOCADO AL CONTROL DEL SERVICIO

ANGÉLICA MARÍA BABATIVA GOYENECHE

PAULA DANIELA BRICEÑO NOVOA

PROYECTO DE GRADO

Directora:

MSc. ALBA CONSUELO NIETO LEMUS

Co-Director:

MSc. OMAR SALAZAR MORALES

UNIVERSIDAD DISTRITAL FRANCISO JOSÈ DE CALDAS

FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

BOGOTÁ D.C 2015

AGRADECIMIENTOS

Inicialmente, nos gustaría agradecer a Dios por bendecirnos para llegar hasta donde

hemos llegado, porque hizo realidad este sueño anhelado, y nos dio salud y vida para

poder culminar con éxito nuestra carrera profesional.

A la UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS por darnos la

oportunidad de estudiar y ser profesionales.

A nuestra directora de tesis, MSc. Alba Consuelo Nieto Lemus, por su esfuerzo y

dedicación, quien con sus conocimientos, su experiencia, su paciencia, su orientación,

su persistencia y su motivación ha logrado que podamos culminar con éxito nuestro

trabajo. Ha sido un privilegio poder contar con su guía y ayuda.

De igual manera agradecer a nuestro Codirector de Tesis de Grado, MSc. Omar

Salazar Morales por su paciencia, disponibilidad y generosidad para compartir su

experiencia y amplio conocimiento.

A nuestro Jurado, MSc. Helbert Eduardo Espitia, por el interés, motivación, apoyo y

critica, necesarios para la realización de éste trabajo.

También nos gustaría agradecer a nuestros profesores durante toda nuestra carrera

profesional, porque todos han aportado con un granito de arena a nuestra formación

como ingenieras.

Para ellos: Muchas gracias y que Dios los bendiga.

TABLA DE CONTENIDO

1. DESCRIPCIÓN DEL PROYECTO ........................................................................... 1

1.1 INTRODUCCIÓN ................................................................................................... 1

1.2 PLANTEAMIENTO DEL PROBLEMA .................................................................... 2

1.2.1 DESCRIPCIÓN DEL PROBLEMA .................................................................. 2

1.2.2 FORMULACIÓN DE LA PREGUNTA CENTRAL DEL TRABAJO .................. 3

1.3 OBJETIVOS........................................................................................................... 4

1.3.1 OBJETIVO GENERAL .................................................................................... 4

1.3.2 OBJETIVOS ESPECIFICOS ........................................................................... 4

1.4 JUSTIFICACIÓN .................................................................................................... 5

1.5 ALCANCES Y LIMITACIONES .............................................................................. 6

1.5.1 ALCANCES ..................................................................................................... 6

1.5.2 LIMITACIONES ............................................................................................... 7

2. MARCO REFERENCIAL .......................................................................................... 8

2.1 MARCO TEÓRICO ................................................................................................ 8

2.1.1 TAXIMETRO ................................................................................................... 8

2.1.1.1 CARACTERÍSTICAS .................................................................................. 8

2.1.1.2 FUNCIONAMIENTO .................................................................................. 9

2.1.2 NORMATIVA VIGENTE ................................................................................ 14

2.1.3 GPS .............................................................................................................. 17

2.2 MARCO TECNOLÓGICO .................................................................................... 19

2.2.1 TECNOLOGÍA PARA EL DESARROLLO DE SOFTWARE PARA DISPOSITIVOS MÓVILES ..................................................................................... 19

2.3 ANTECEDENTES ................................................................................................ 25

2.3.1 TAXI GPS ...................................................................................................... 25

2.3.2 TAXÍMETRO GPS ......................................................................................... 25

2.3.3 TAXIANDO .................................................................................................... 25

2.4 MARCO METODOLÓGICO ................................................................................. 26

2.4.1 SCRUM ......................................................................................................... 27

3. DESARROLLO DEL PROYECTO .......................................................................... 29

3.1 METODOLOGÍA DE DESARROLLO ................................................................... 29

3.1.1 PERSONAS Y ROLES DEL PROYECTO ..................................................... 29

3.1.2 PLAN DEL PROYECTO ................................................................................ 29

3.2 DESARROLLO DEL SPRINT 0 ........................................................................... 33

3.2.1 AMBIENTE DE DESARROLLO .................................................................... 34


3.3.1 HISTORIAS DE USUARIO............................................................................ 35

3.3.1 DEPENDENCIAS ENTRE HISTORIAS DE USUARIO ................................. 44

3.3.3 PROTOTIPOS DE LAS HISTORIAS DE USUARIO ..................................... 46

3.3.4 MODELO DE REQUERIMIENTOS ............................................................... 48

3.3.5 MODELO DE CASOS DE USO .................................................................... 50


3.4.1 ARQUITECTURA DE LA APLICACIÓN ........................................................ 58

3.4.2 DIAGRAMA DE CLASES .............................................................................. 61

3.4.3 DIAGRAMA DE SECUENCIA ....................................................................... 63

3.4.4 MODELO DE PERSISTENCIA DE DATOS .................................................. 64


MÓDULO PARA CARGAR LA TARIFA EN EL SERVIDOR .................................. 66




3.9 TECNOLOGÍAS UTILIZADAS EN EL DESARROLLO DEL PROYECTO ........... 69

3.9.1 TECNOLOGÍAS UTILIZADAS ....................................................................... 69

3.9.2 LIBRERÍAS ................................................................................................... 72

3.10 PRUEBAS.......................................................................................................... 74

3.11 VALIDACIÓN DE LOS RESULTADOS .............................................................. 79

3.11.1 IDENTIFICACIÓN Y EXPOSICIÓN DEL PROBLEMA ................................ 79

3.11.2 ELECCIÓN DE LOS FACTORES, LOS NIVELES Y LOS RANGOS ......... 79

3.11.3 SELECCIÓN DE LA VARIABLE DE RESPUESTA .................................... 80

3.11.4 ELECCIÓN DE LA TÉCNICA ESTADÍSTICA ............................................. 80

3.11.5 REALIZACIÓN DEL EXPERIMENTO ......................................................... 80

3.11.6 ANÁLISIS ESTADÍSTICO DE LOS DATOS ................................................ 89

3.11.7 CONCLUSIONES DEL ANÁLISIS ESTADÍSTICO ...................................... 90

4. RESULTADOS OBTENIDOS ................................................................................. 91

4.2 RESULTADOS DEL PROTOTIPO FUNCIONAL ................................................. 92

CONCLUSIONES

TRABAJO FUTURO

ANEXOS

ÍNDICE DE TABLAS

TABLA 1. Tarifas Recargos 2014. ................................................................................. 12 TABLA 2. Comparación De Sistemas Operativos Para Móviles ................................... 22 TABLA 3. Personas y Roles Del Proyecto. . ................................................................. 29 TABLA 4. Sprints Del Proyecto. . .................................................................................. 33 TABLA 5. Actividades Desarrolladas En El sprint 0. . ................................................. 333 TABLA 6. Herramientas Utilizadas Para El Desarrollo Del Proyecto. ........................... 34 TABLA 7. Actividades Desarrolladas En El Sprint1. ...................................................... 35 TABLA 8. Módulos De La aplicación móvil. .................................................................. 36 TABLA 9. Matriz De Trazabilidad. ................................................................................. 45 TABLA 10. Actividades Sprint 2. ................................................................................... 58 TABLA 11. Actividades Sprint 3.. .................................................................................. 66 TABLA 12. Actividades Sprint 4.. .................................................................................. 68 TABLA 13. Actividades Sprint 5.. .................................................................................. 68 TABLA 14. Actividades Sprint 6.. .................................................................................. 69 TABLA 15.Actividades Realizadas en pruebas. . .......................................................... 74 TABLA 16. Formato De Caso de Prueba: Activar gps................................................... 75 TABLA 17. Formato De Caso de Prueba: Iniciar Medición. .......................................... 76 TABLA 18. Formato De Caso de Prueba: Contabilizar y Seleccionar Recargos. .......... 77 TABLA 19. Formato De Caso de Prueba: Notificar y Actualizar Modelo De Tarifa. ...... 78 TABLA 20. Formato De caso de Prueba: Notificar Queja En Twitter.. .......................... 79 TABLA 21. Días, Zonas y Franjas En Las Que Se Tomaron Los Datos. ...................... 82 TABLA 22. Toma De Datos.. ......................................................................................... 85 TABLA 23. Cronograma De Las Actividades Desarrolladas. ........................................ 91 TABLA 24. Formato De Caso De Prueba: Mostrar La ubicación Del Usuario. ............ 109 TABLA 25. Formato De Caso De Prueba: Iniciar Aplicación. ...................................... 110 TABLA 26. Formato De Caso De Prueba: Calcular Valor De La Carrera. ................... 111 TABLA 27. Formato De Caso De Prueba: Almacenar Información Del Servicio. ........ 112 TABLA 28. Formato De Caso De Prueba: Generar Informe. ...................................... 113 TABLA 29. Formato De Caso De Prueba: Cargar Modelo De Tarifa. ......................... 114 TABLA 30. Distribución T-Student. ............................................................................. 116

ÍNDICE DE FIGURAS

FIGURA 1. Diagrama De Estado Del Taxímetro. ............................................................ 9 FIGURA 2. Escalafón Infracciones De Taxistas. ........................................................... 13 FIGURA 3. Principio De Triangulación. ......................................................................... 17 FIGURA 4. Funcionamiento AVL. . ............................................................................... 18 FIGURA 5. Arquitectura De Android.............................................................................. 20 FIGURA 6. Funcionamiento Backend As Service Parse. .............................................. 24 FIGURA 7. Pasos Para La Selección De Una Muestra. ................................................ 26 FIGURA 8. Proceso Metodología Scrum. ...................................................................... 28 FIGURA 9. Sprint Backlog. ............................................................................................ 31 FIGURA 10. Planeación De Sprints Del Proyecto. ........................................................ 32 FIGURA 11. Módulo De Requerimientos Para La Aplicación. ....................................... 48 FIGURA 12. Diagrama De Requerimientos Funcionales . ............................................ 49 FIGURA 13. Diagrama De Contexto ............................................................................ 51 FIGURA 14. Diagrama De Casos De Uso Para El Módulo De Medición. ..................... 52 FIGURA 15. Diagrama De Casos De Uso Para El Módulo De Gestión De Tarifas. ...... 53 FIGURA 16. Diagrama De Casos De Uso Para El Módulo De Notificación. ................. 54 FIGURA 17. Modelo De Procesos................................................................................. 55 FIGURA 18. Flujo De Actividades. ................................................................................ 57 FIGURA 19. Arquitectura De La Aplicación. .................................................................. 60 FIGURA 20. Diagrama De Clases. ................................................................................ 62 FIGURA 21.Diagrama De Secuencia: Iniciar Aplicación. . ............................................ 63 FIGURA 22. Persistencia Del Cliente. ........................................................................... 64 FIGURA 23. Persistencia En El Servidor. . ................................................................... 65 FIGURA 24. Modelo De Procesos: Cargar tarifa. .......................................................... 67 FIGURA 25. Icono De La Aplicación. ............................................................................ 70 FIGURA 26. Aplicación De La Librería Googlemaps. . ................................................. 72 FIGURA 27. Distribución Normal Del Error. ................................................................. 89 FIGURA 28. Medidas Twtaxi vs. Medidas Taxímetro.. .................................................. 90 FIGURA 29. Historia De Usuario: Contabilizar y Seleccionar recargos......................... 92 FIGURA 30. Historia De Usuario: Generar informe Con Los Datos Del Servicio. ......... 93 FIGURA 31. Historia De Usuario: Notificar Queja En Twitter. ...................................... 94 FIGURA 32 Tabla Recargos. . ...................................................................................... 94 FIGURA 33. Tabla Empresa. . ...................................................................................... 95 FIGURA 34. Diagrama De Secuencia: Iniciar Medición.. ............................................ 104 FIGURA 35. Diagrama De Secuencia: Calcular Tarifa. . ............................................. 106 FIGURA 36. Diagrama De Secuencia: Actualizar Tarifa. ............................................ 107 FIGURA 37. Configuración De La Librería Android Support. ...................................... 108 FIGURA 38. Curvas De Operación Características. ................................................... 115

1

1. DESCRIPCIÓN DEL PROYECTO

1.1 INTRODUCCIÓN

Un factor importante para el crecimiento de cualquier ciudad es la movilidad, ya que resulta indispensable para los ciudadanos y habitantes disminuir tiempos de desplazamiento; es por ello que el uso de taxis, como servicio público, se ha incrementado en los últimos años. Con un 42.3% [1] la población bogotana afirma preferir este servicio para desplazarse a su trabajo, sitio de estudio o lugar de vivienda, dada la comodidad, rapidez y servicio puerta a puerta que ofrece.

A medida que ha aumentado la demanda de este servicio, también se han incrementado los usuarios inconformes con el cobro de la tarifa por parte de los taxistas [2]. Esto ha generado altercados, desconfianza y zozobra en los usuarios, viéndose en riesgo la disminución en la demanda del servicio.

Dada esta situación se propone el desarrollo de una aplicación móvil para teléfonos celulares con sistema operativo Android, que controle y verifique las unidades que marca el recorrido que realiza el taxi en el que se transporta un usuario, calculando la tarifa que se debe pagar según la normatividad vigente, establecida por la Secretaria de Movilidad de Bogotá como organismo de regulación. Adicionalmente, la aplicación permitirá generar un reporte en las redes sociales como mecanismo de control social en caso de irregularidades en la marcación del taxímetro o en el cobro de la tarifa.

2

1.2 PLANTEAMIENTO DEL PROBLEMA

1.2.1 DESCRIPCIÓN DEL PROBLEMA Para el cálculo del cobro del servicio de taxi, se hace uso del taxímetro como instrumento de medición el cual le indica al pasajero la cantidad total que debe pagar según las unidades marcadas basándose en la distancia recorrida y el tiempo transcurrido. Para calcular el valor a pagar, cada una de las unidades que marca tiene un equivalente en distancia y en tiempo: se marca una unidad por cada 100 metros recorridos o por cada 30 segundos de espera [3] (Ver sección 2. Normativa Vigente).

El valor de la unidad se establece de acuerdo al decreto No. 237 de 2006 [3], donde se determina el costo del kilómetro recorrido y el valor que tendrá cada unidad en pesos. Cada una de estas variables se incrementa en Junio de cada año. La Secretaria de Tránsito y Transporte de Bogotá es la entidad encargada de regular dichos cambios y velar por su cumplimiento.

Muchas son las técnicas utilizadas para adulterar el taxímetro lo cual se ve reflejado en el cobro del servicio de taxi. A continuación se mencionan algunas de las prácticas ilegales para manipular y adulterar el funcionamiento correcto de un taxímetro.

Comúnmente llamado en Colombia “muñeco”: Consiste en alterar el taxímetro por medio de elementos externos a los cuales solo puede tener acceso el conductor, una vez que tenga algún tipo de contacto con el taxímetro este se modificará aumentando una unidad, teniendo así, el conductor el control de la tarifa [4].

Engranaje multiplicador: En esta técnica se hace que el sensor de velocidad del vehículo gire con una velocidad más rápida de lo normal, aumentando así la distancia que realmente se está recorriendo y por ende las unidades marcadas aumentarán [5].

Actualmente los usuarios de taxi que quieran manifestar una inconformidad o hacer una denuncia por el servicio prestado, pueden ir a la página oficial de la Secretaria Distrital de Movilidad y en la parte superior derecha ingresar a la pestaña Contacto [6]. Una vez diligenciado el formato, se generará un número de radicado, con este número el ciudadano puede hacer el seguimiento de su denuncia. Existe en Twitter una página llamada @DenunciealTaxista [7], en donde los usuarios pueden hacer públicas sus quejas de manera rápida. Dicha página no está gestionada por ninguna entidad oficial, pero al ser una red social popular, permite la rápida difusión de éstos reportes.

Con el desarrollo de éste proyecto se busca implementar un prototipo móvil, que le permita al usuario monitorear el recorrido y en caso de que lo considere necesario hacer un reporte con los datos de la carrera en la red social Twitter. Para llevar a cabo estas funcionalidades se integrará la tecnología GPS y la red social Twitter.

3

1.2.2 FORMULACIÓN DE LA PREGUNTA CENTRAL DEL TRABAJO ¿Cómo y con qué tecnología debe ser desarrollado el prototipo de software para dispositivos móviles con sistema operativo Android, de tal forma que funcione cómo taxímetro para el usuario, para que éste pueda llevar control del cobro del servicio de taxi, pudiendo generar una queja y hacerla pública en las redes sociales?

4

1.3 OBJETIVOS

1.3.1 OBJETIVO GENERAL Desarrollar un prototipo de software de taxímetro destinado a dispositivos móviles apoyados en el sistema operativo Android y tecnología GPS, para el control de cobro del servicio de taxi por parte de los usuarios en la ciudad de Bogotá, permitiendo hacer públicas las quejas en la red social Twitter.

1.3.2 OBJETIVOS ESPECIFICOS

Especificar los requerimientos del prototipo para el monitoreo del cobro del servicio de taxi ajustado a la normatividad vigente para la ciudad de Bogotá.

Construir un prototipo de software aplicando la metodología Scrum, utilizando estándares y buenas prácticas de desarrollo para obtener un producto que cumpla con los requerimientos funcionales y a su vez, entregue un resultado preciso en la medición.

Implementar la aplicación prototipo sobre el sistema operativo Android usando la tecnología GPS, para el cálculo de la tarifa, según los valores establecidos en el decreto No. 237 de 2006 [3].

Validar el prototipo mediante análisis estadístico, para probar el rendimiento y fiabilidad del mismo, bajo condiciones normales, confrontando el intervalo de tolerancia de las medidas (distancia y tiempo) con el recorrido real del taxi.

5

1.4 JUSTIFICACIÓN

Según la investigación realizada por la periodista Luisa Fernanda Ballén titulada Taxímetros Adulterados [4], revela que el taxímetro adulterado es la tercera denuncia más frecuente en el escalafón de infracciones impartidas para el 2013, generando a los bogotanos una pérdida anual de cerca de $200 mil millones. En vista de dichos resultados, se propone desarrollar un prototipo de software que mediante tecnología GPS monitoree los recorridos de las carreras y de esta manera, desde la comodidad de un teléfono celular, muestre las unidades transcurridas y calcule el valor de la carrera incluyendo recargos extra, en caso de que apliquen. Posteriormente se habilitará la opción para enviar un mensaje a la red social Twitter con la información del vehículo, del recorrido y de la tarifa cobrada en caso de inconformidad en el cobro del servicio.

Aunque existen aplicaciones móviles que simulan el funcionamiento de un taxímetro como Taxi GPS [8], Taxiando [9] y Taxímetro GPS [10] ninguna de ellas viene integrada con las redes sociales. Cada una de estas presenta algunos inconvenientes, los cuales se presentan a continuación:

Taxi GPS: Demora al iniciar la aplicación, las unidades corren más rápido que el taxímetro real y maneja mucha publicidad, lo cual resulta incómodo para sus usuarios [8].

Taxiando: Funciona únicamente como una calculadora de tiempo y tarifa, además solo está disponible en Costa Rica [9].

Taxímetro GPS: Gratuita para Android pero tiene un costo para iOS de 0.99 dólares [10].

El desarrollo se hará sobre el sistema operativo Android, porque:

El código de Android es abierto, ofreciendo muchas facilidades a la hora de desarrollar [11].

Actualmente existen más de 100.000 aplicaciones disponibles para dispositivos Android, la mayoría gratis [11].

El sistema operativo Android tiene la función multitarea, es decir, es capaz de hacer funcionar a la vez varias aplicaciones y además se encarga de gestionarlas, dejarlas en modo suspensión si no se utilizan e incluso cerrarlas si llevan un periodo determinado de inactividad. De esta manera se evita un consumo excesivo de batería [12].

6

1.5 ALCANCES Y LIMITACIONES

1.5.1 ALCANCES Con la finalización de éste proyecto se pretende entregar la implementación de un prototipo móvil para los usuarios de Taxi en Bogotá instalado en un celular con sistema operativo Android, que le permita al usuario llevar un control de las unidades totales recorridas dadas por distancia y tiempo.

La aplicación calculará de manera automática la tarifa básica dada por distancia y tiempo, y permitirá al usuario ingresar los servicios adicionales (Horas extras, servicio puerta a puerta) para el cálculo de la tarifa total.

La aplicación debe permitir enviar un reporte a la red social Twitter, aplicación web gratuita, que permitirá a los usuarios enviar, compartir y difundir mensajes, cada una con su correspondiente soporte. La gestión o trámite del reporte no está dentro del alcance de la aplicación.

Para que el software sea mantenible se desarrollará un módulo encargado de actualizar automáticamente el valor de las tarifas año tras año.

La implementación de la aplicación se hará sobre el sistema operativo Android, en el entorno de programación Eclipse; la aplicación estará disponible para Smartphone y Tablet, algunas de las marcas para la que estará disponible será: Samsung, Sony-Ericsson, Alcatel, Motorola, Sony, Huawei, LG, entre otras [12].

7

1.5.2 LIMITACIONES La tecnología GPS que se utilizará para monitorear el recorrido del taxi, algunas veces provee información imprecisa debido a factores externos como: precisión del dispositivo GPS, visibilidad del GPS, presencia de edificios muy altos o cambios climáticos; dichos factores hacen que la información suministrada sea poco acertada [13]. Al ser el GPS el instrumento de medida que se utilizará para calcular las unidades recorridas y para evitar ofrecer datos erróneos, se realizará el proceso de verificación del prototipo bajo condiciones normales. En [14], [15] y [16], se enuncia que el desarrollo de software es una actividad, que dada su complejidad, debe desarrollarse en grupo. Además, ésta actividad requiere de distintas capacidades, las que no se encuentran todas en una sola persona. Actualmente existen diferentes metodologías para el desarrollo de software, en donde todas tienen una característica en común, han sido diseñadas para un contexto de trabajo en equipo, planteando la interacción de diferentes tipos de roles, con funciones diferentes dentro del proyecto. La mayor parte del software no puede desarrollarse de manera individual y exige la participación de equipos de desarrollo. Se propuso Scrum [17] como metodología de desarrollo para flexibilizar el manejo del cambio debido a la curva de aprendizaje y teniendo en cuenta que las restricciones de tiempo requerían una construcción rápida, pero sin dejar de lado las buenas prácticas del desarrollo de software. En cuanto a la complejidad del proyecto, se tiene:

Tipos de contenido: La aplicación contará con un contenido dinámico, para el cual se hará un módulo de actualización para los precios de las tarifas.

Geoposicionamiento: La aplicación se basará en la información dependiente de la localización del usuario.

Integración con otros sistemas: La aplicación se integrará con la red social Twitter para poner la queja por parte de los usuarios.

Diseño Gráfico: Evidentemente no es lo mismo un diseño sencillo con menús y páginas tipo ficha informativa, que aplicaciones móviles que aporten información al usuario.

Acceso a Datos: La aplicación deberá acceder a los datos del móvil, comprobar si existe conexión a la red social Twitter con su respectivo Usuario y Contraseña.

Aplicación Nativa: La aplicación será nativa, ya que se consigue una mayor calidad y rendimiento con un coste mayor, mientras que las aplicaciones híbridas ofrecen menor rendimiento pero el coste es sensiblemente inferior.

Pruebas manuales: La aplicación deberá pasar las pruebas de funcionamiento correcto, lo cual implica hacerse en taxis reales.

8

2. MARCO REFERENCIAL

2.1 MARCO TEÓRICO

2.1.1 TAXIMETRO El taxímetro es un instrumento digital instalado en los taxis que marca las unidades usadas por un pasajero durante un recorrido, busca garantizar el cobro de las tarifas justas, indicando en todo momento el valor que debe pagar el usuario con respecto a la distancia recorrida por el vehículo y al tiempo transcurrido [17].

2.1.1.1 CARACTERÍSTICAS

Los taxímetros deben contar con las siguientes características [19]:

Pantalla Doble: La primera pantalla se utiliza para indicar el número de unidades recorridas, y la segunda pantalla muestra el costo del servicio, las cuales deben disponer de buena luminosidad.

Visibilidad: Lectura fácil a una visión normal 20/20, a una distancia mínima de 3 metros, tanto de día, como de noche.

El taxímetro es de tipo digital, y debe estar ajustado para calcular la tarifa base tomando como punto de partida la distancia recorrida y el tiempo.

Dimensiones: Los dígitos que se muestran en el taxímetro cuentan con una altura mínima de 10,0 milímetros.

Convertidor de unidades en pesos.

Está ubicado en el medio de la parte delantera interior del taxi o fijado al techo; con el objetivo de que el pasajero pueda observarlo en cualquier momento.

9

2.1.1.2 FUNCIONAMIENTO El taxímetro cuenta con un ciclo de trabajo de 5 estados: libre, servicio, pausa, pagar y control, como se indica en la figura 1. Cada uno de éstos estados presenta un comportamiento especial [18].

Figura 1. Diagrama de estado del taxímetro.

Fuente [20].

2.1.1.3 UNIDADES DE MEDIDA

Para enunciar las indicaciones aportadas por los taxímetros, se establecen las siguientes unidades de medida [18]:

El metro o el kilómetro para la distancia recorrida.

El segundo, el minuto o la hora para el tiempo.

La suma a pagar, se expresará en pesos Colombianos.

A continuación se describen cada uno de los valores básicos de los que consta una tarifa.

2.1.1.3.1 BANDERA La bandera es un dispositivo que indica el estado en el que se encuentra el taxímetro, el cual puede ser: ocupado, o libre, llamado bandera [18].

a) Libre: Taxi desocupado esperando a algún cliente, como se aprecia en la figura; en este estado el display se apaga automáticamente para ahorrar energía.

10

b) Servicio: Ésta etapa inicia cuando inicia el viaje, en dónde se va mostrando el número de unidades recorridas. En este estado no debe poder alterarse el valor acumulado por un medio diferente a la función distancia y tiempo.

c) A pagar: Tiene lugar cuando el desplazamiento ha finalizado, en dónde se muestra el número total de unidades y el valor a pagar.

d) Control: En ésta etapa se puede observar en pantalla determinada información para que el dueño del taxi esté informado acerca del servicio del taxi.

e) Pausa: Estado que inicie obligatoriamente cuando se presentan fallas mecánicas, técnicas, eléctricas, etc. Se congelan los valores correspondientes a la distancia y el tiempo, sin alterar los valores anteriormente registrados.

2.1.1.3.2 BAJADA DE BANDERA Es el momento en el que el taxi se encuentra en estado ocupado, es aquí donde el taxímetro toma una cantidad fija inicial, correspondiente a la bajada de bandera, para después comenzar a aumentar sus unidades. 2.1.1.3.2.1 CANTIDAD FIJA La cantidad fija es un valor económico acreditado legalmente por la Secretaría Distrital de Movilidad para el pago de los servicios del transporte retribuido a taxistas, la cual se compone de:

Costo inicial También llamado Banderazo, se refiere al valor en el que inicia el taxímetro al momento de ser puesto en servicio. De acuerdo a la Alcaldía Mayor de Bogotá [19] se estipuló que para el año 2014-2015, el banderazo será de 25 unidades, que corresponden a $2000 pesos.

Valor del incremento Se refiere al valor económico habitual y constante en el que va aumentando de las unidades del taxímetro a partir del costo inicial.

Costo por función tiempo Es un valor monetario que se calcula a partir de la siguiente fórmula [18]:

En donde segundos corresponde a la cantidad de tiempo en la que el taxi ha registrado una velocidad menor o igual a la velocidad de cambio de arrastre, y costo

11

por hora de servicio es el valor fijado por la Alcaldía Mayor de Bogotá. El costo por la función tiempo es sumado al acumulador interno de costo a medida que se vaya generando.

Costo por función distancia Es un valor monetario que se calcula a partir de la siguiente fórmula [18]:

En donde metros recorridos corresponde a la distancia recorrida durante el servicio, y costo por kilómetro es el resultado de la suma de los costos fijos, variables y de capital calculados por la autoridad competente. El costo por la función distancia es sumado al acumulador interno de costo a medida que se vaya generando.

2.1.1.3.3 VELOCIDAD DEL CAMBIO DE ARRASTRE Se refiere a la velocidad a la que los costos por función distancia y tiempo son equivalentes. A una velocidad menor, el taxímetro automáticamente trabaja en la función tiempo y a una velocidad mayor el taxímetro trabaja en la función distancia. Ésta velocidad se calcula a partir de la siguiente fórmula [18]:

En dónde es la distancia en kilómetros y es el tiempo en horas, ambas variables son determinadas por la Alcaldía Mayor de Bogotá.

2.1.1.3.4 EXTRAS Es un valor adicional que se le cobra al pasajero, el cual no está incluido en la tarifa del taxímetro. El caso más común es por llevar equipaje o artículos pesados. Éste valor se deja a criterio del taxista.

2.1.1.4 MODELO DE TARIFA

De acuerdo al decreto 400 de 2014 [19], la Alcaldía Mayor de Bogotá autorizó los nuevos recargos para el año 2014. En la tabla 1, se muestran dichos recargos, y se contrastan contra las del año 2013.

Valor por cada 30 segundos de espera.

12

Se considera cuando el taxi está inmóvil a causa de trancones o cuando transita a velocidades menores de 10 kilómetros por hora, éste valor aplica en horario diurno y nocturno.

Tarifa nocturna Es aquella tarifa entre las 20:00 y las 5:00 horas. Aplica para domingos y festivos todo el día.

Tarifa diurna Es aquella tarifa entre las 05:01 y las 19:59 horas.

CONCEPTO UNIDADES AÑO 2013 AÑO 2014

Valor Unidad cada 100 m. 1 $ 70 $ 78

Arranques o Banderazo 25 $ 1.800 $ 2.000

Valor por cada 30 segundos de espera 1 $ 70 $ 78

Recargo al y del aeropuerto y Puente Aéreo 50 $ 3.500 $ 3.900

Recargo nocturno dominical y festivo 24 $ 1.700 $ 1.900

Carrera mínima 50 $ 3.500 $ 3.900

Servicio por hora 225 $ 15.800 $ 17.600

Puerta a puerta 9 $ 600 $ 700

Recargo desde el terminal de transporte 7 $ 500 $ 500 Tabla 1. Tarifas Recargos 2014

1.

Elaboración propia basada en [19].

2.1.1.5 TIPOS DE FRAUDES

Un estudio realizado por la Policía de Tránsito de Bogotá arrojó que se han sancionado 345 vehículos semestralmente por tener el taxímetro adulterado, cuya consecuencia es que en promedio diariamente los bogotanos pierden 300 millones de pesos [20]. Hay distintas maneras de cometer fraude, algunas de ellas son:

El paseo Éste tipo de fraude es uno de los más populares, el cual consiste en llevar al pasajero por el camino más largo, pasar por vías congestionadas y dar vueltas sin necesidad, con el objetivo de cobrar más en la carrera.

Tarifa Anticipada

1 A la fecha, 28 de Julio de 2015, la Alcaldía Mayor de Bogotá no ha publicado las tarifas del 2015-2016.

13

La tarifa anticipada consiste en encender el taxímetro antes de que el pasajero aborde el vehículo, en muchas ocasiones el pasajero no se percata de dicha acción.

El "muñeco" El "muñeco" es un dispositivo ilegal que altera las unidades del taxímetro. Puede ser instalado en cualquier parte del vehículo: El pito, sistema de freno, freno de mano, parte posterior de la dirección o en las direccionales, etc. Consta de un botón, o de una "cuerdita" que permite que al ser presionado o halado, el taxímetro aumente más rápido.

Uso inadecuado de la tabla de precios Éste tipo de fraude consiste en cobrar más de lo que anuncia el taxímetro, normalmente es hecho a personas de tercera o edad, o jóvenes que según la experiencia del conductor, no usan éste servicio a menudo.

En la figura 2 se muestra el escalafón de las infracciones de los taxistas en Bogotá, está encabezada por el uso incorrecto de la tabla de precios con un total de 518 multas, seguido por la revisión tecnicomecánica, la cual debe hacerse anualmente para verificar el estado del vehículo y del taxímetro y en tercer puesto nuestro objetivo: el taxímetro adulterado con 345 multas.

Figura 2. Escalafón Infracciones de Taxistas. Fuente [4].

14

2.1.2 NORMATIVA VIGENTE

A continuación se presentarán las diferentes normas y reglamentos vigentes que rige actualmente al servicio de taxis, esas normas fueron emitidas por la Secretaria de Movilidad de Bogotá.

2.1.2.1 Decreto No. 172 de 2001 Conformada por cuatro títulos y 58 artículos [21].

Título I Parte general En el capítulo uno se define la intención del decreto, teniendo como objetivo principal definir los criterios básicos que debe cumplir cualquier empresa que quiera prestar servicios de trasporte público en vehículo taxi. Entendiendo un vehículo taxi como un servicio público el cual no está sujeto a horarios ni rutas predefinidas, sino que son establecidas por el usuario; dicho recorrido será pactado en mutuo acuerdo entre ambas partes. Todo taxi estará acogido a una empresa legalmente constituida y debidamente habilitada, para ello deberá solicitar la habilitación que le permita operar y así garantizar un servicio eficiente, seguro, oportuno y económico. Los organismos encargados de inspeccionar, controlar y vigilar los reglamentos estipulados serán las autoridades municipales o alcaldes de cada ciudad. Se define tarifa como el precio que se debe pagar por el servicio que se ofrece de transporte individual de pasajero, esta se cancela al llegar al lugar de destino. Se definen como autoridades de trasporte competentes:

a) Jurisdicción Nacional. b) Jurisdicción Distrital y Municipal. c) Jurisdicción del área metropolitana constituida de conformidad con la ley.

Título II Habilitación Cualquier empresa que desee prestar sus servicios y ser parte del trasporte público, deberá solicitar y diligenciar una serie de documentos que lo acrediten y de esta manera asegurar la prestación de un servicio confiable. Una vez se ha realizado la solicitud la autoridad competente tendrá máximo 90 días hábiles para responder. La empresa se someterá a ser evaluada por parte de las autoridades competentes para la confirmación y verificación de datos la cual se realizara en cualquier momento [21].

Título III Seguros Toda empresa de trasporte público deberá contar con pólizas de seguro que la amparen de posibles riesgos y/o situaciones inesperadas [21].

15

Título IV Prestación del servicio Una vez la empresa tenga los permisos y se habilite al vehículo para prestar el servicio público, deberá permanecer en este servicio como mínimo 5 años. En caso de que se solicite el servicio desde o a un terminal aéreo se debe portar la plantilla única de viaje ocasional solo si se sale del radio de acción autorizado. Por ningún motivo se debe considerar un vehículo taxi como un servicio colectivo, de ser así se tomarán sanciones pertinentes para tal situación. La fijación de tarifas del servicio público de transporte individual de pasajeros en vehículo taxi, será competencia de las autoridades distritales y municipales, dichas tarifas se determinarán de acuerdo a los costos fijados para la canasta de transporte [21].

2.1.2.2 Decreto No. 237 de 2006 Por el cual se fijan las tarifas para el servicio taxi, determinando variables y criterios que se deben tener en cuenta al momento de establecer el valor de la misma. Dicha tarifa tendrá un incremento anual el cual será calculado el mes de Junio de cada año.

Se debe incentivar el servicio de taxis por medio de llamada telefónica con el fin de ofrecer al usuario un servicio más seguro, cómodo y de calidad [3].

La tarifa técnica por unidad, entendida como el valor por unidad cada 100 metros o cada 30 segundos, se establecerá de acuerdo a las siguientes ecuación [3]:

Siendo: = Costo Kilometro = Costos Fijos Mensuales

= Costos Variables mensuales =Costos de Capital mensual = Kilómetros recorridos al mes

Dónde: = Metros de marcación = Valor de la unidad en pesos = Costos Kilometro

16

La tabla de conversiones de unidades a pesos se obtiene de multiplicar el número de unidades transcurridas por el valor de cada unidad vigente autorizada, el resultado de este producto será el valor de la tarifa básica.

Además de la tarifa básica se puede aplicar recargos extras al solicitar un servicio de taxi, como se puede observar en la tabla 1: recargo al y del aeropuerto; recargo nocturno, dominical y festivo; recargo por servicio puerta a puerta o por solicitud telefónica del usuario. Definiendo horario nocturno entre las 8:00 p.m. y las 5:00 a.m. del siguiente día.

2.1.2.3 Sanciones Ley 1383 de 2010 Estas sanciones las deberá asumir el conductor y/o propietario del vehículo que cometa las siguientes infracciones [22] :

No llevar las tarifas oficiales en condiciones de fácil lectura para los pasajeros o usar tarifas deterioradas y/o adulteradas. Vehículo inmovilizado.

Conducir un vehículo de servicio público con el taxímetro: adulterado, dañado, con etiquetas adhesivas o mal calibrado. Es decir, que no cumpla con los requisitos mínimos que garanticen la calidad y confiabilidad del servicio. Un vehículo inmovilizado tienen una multa de 15 salarios mínimos legales diarios vigentes (SMLDV).

Negarse a prestar el servicio público, sin justificación, a destinos fijados por el usuario siempre y cuando no altere el orden público. Multa de 45 salarios mínimos legales diarios vigentes (SMLDV).

17

2.1.3 GPS En 1973 el Departamento de Defensa de los Estados Unidos inició un proyecto llamado GPS por sus siglas en inglés Global Positioning System. Aunque inicialmente fue desarrollado con fines militares, en la actualidad se usa para diversos fines y se emplea en diferentes ámbitos. La figura que se muestra a continuación ilustra el principio que se emplea para localizar la posición de un dispositivo móvil llamado triangulación, éste principio mide la distancia que hay entre el dispositivo y tres satélites, una vez se obtiene la distancia de estos 3 satélites (puntos de referencia), es posible conocer la posición del dispositivo [23].

Figura 3. Principio de Triangulación.

Fuente [24].

2.1.3.1 GPS PARA LOCALIZACIÓN DE AUTOMÓVILES Algunas de las ventajas que ofrecen los receptores GPS es que se pueden instalar en una variedad de dispositivos y con diversos fines. Uno de los más conocidos es para determinar rutas y trayectorias de vehículos, para ello se instalan en automóviles permitiendo: ubicar la posición donde se encuentra, el tiempo transcurrido que lleva circulando, la velocidad que lleva en marcha, incluso se puede almacenar rutas de interés o por las que se ha pasado, de esta manera se tendrá conocimiento de los sitios por donde ha transitado [23]. Algunas aplicaciones que incorporan tecnología GPS en vehículos son:

SpeedView: Aplicativo móvil que mide la velocidad del vehículo indicando la velocidad actual, máxima y media; el tiempo trascurrido y por último la distancia total recorrida. Adicionalmente cuenta con gráficos de velocidad indicando la velocidad de los últimos minutos y con aviso de velocidad, alertando al conductor cuando exceda el límite de velocidad [25].

18

My Tracks: Aplicación Android que permite grabar: rutas de interés, velocidad, distancia y elevación a la que se encuentra, adicionalmente se pueden añadir notas y fotos a la ruta mientras se graba. Dichas rutas pueden ser compartidas y almacenadas en Google Drive [26].

2.1.3.2 SISTEMA GPS AVL El sistema de localización vehicular automatizada o conocido por sus siglas en inglés Automatic Vehicle Location (AVL), es un sistema que identifica, monitorea y localiza unidades móviles en tiempo real. Para ello hace uso de la tecnología GPS lo que le permite determinar datos específicos de un vehículo como: velocidad, aceleración, gastos excesivos en combustible, excesos en límites de velocidad, entre otros [27]. El sistema AVL está compuesto por: GPS; una unidad móvil con el receptor GPS, un servidor de almacenamiento y una aplicación que contenga una base de datos cartográfica digital [27].

Figura 4. Funcionamiento AVL. Fuente [28].

Este sistema es útil en aplicaciones administrativas de transporte, monitoreo de tráfico de camiones distribuidores de una empresa, envío de vehículos en escenas de emergencia, programación de una ruta para un vehículo autónomo, sistema de transporte público, etc. Todo esto se puede administrar desde la distancia a través de un dispositivo móvil. Una se vez se obtiene la información la central tomará las decisiones y los correctivos que considere necesarios [27].

2.1.3.3 TAXIMETRO CON GPS Una de las opciones que han surgido para el cálculo de la tarifa en taxis es el taxímetro con GPS, aunque cuenta con ciertas limitaciones pues sus cálculos presentan poco grado de precisión, esto se debe a que muchas veces la señal se debilita por la presencia de edificios altos o zonas de escasa cubertura; sin embargo los resultados se aproximan bastante a la tarifa a pagar [29].

Para calcular el valor del recorrido el GPS indica la velocidad y el tiempo trascurrido de una carrera, de esta manera el taxímetro no irá conectado a sensores de velocidad o

19

movimiento y el pasajero viajará más tranquilo, pues la probabilidad de que el taxímetro sea adulterado es mínima [29].

2.2 MARCO TECNOLÓGICO

2.2.1 TECNOLOGÍA PARA EL DESARROLLO DE SOFTWARE PARA DISPOSITIVOS MÓVILES En los últimos años los dispositivos móviles han adquirido cada vez mayor acogida y aceptación en la sociedad, convirtiéndose en elementos indispensables para realizar variedad de tareas, pues independientemente dónde se encuentre el usuario, siempre y cuando tenga conexión a internet. Le facilita: acceder a información de su interés, comunicarse de manera contínua en las redes sociales, ver contenido audio visual de alta calidad, descargar juegos, editar documentos, enviar correos, entre otra [30].

Es así como el concepto de dispositivo móvil visto como herramienta que permite comunicar, ha evolucionado a tal punto que en la actualidad también es usado con fines administrativos y considerado como una herramienta que permite aumentar índices de productividad en una empresa [31].

2.2.1.1 SISTEMAS OPERATIVOS PARA DISPOSITIVOS MÓVILES

2.2.1.1.1 ANDROID Android es un sistema operativo móvil orientado a la conexión inalámbrica, desarrollado por la Open Handset Alliance y diseñado para dispositivos móviles como Smartphone, tablets, etc. Para el desarrollo de aplicaciones utiliza Java como lenguaje de programación, junto con el entorno de desarrollo JDK y el IDE de Eclipse que facilita el desarrollo de aplicaciones. Este sistema operativo ofrece un kit de desarrollo, Android Software Development Kit, que incluye un depurador, drivers, documentación, bibliotecas y complementos necesarios para programar en Android; esta herramienta es compatible con los entornos de desarrollo: Eclipse, JDK5, Apache Ant y Android Development [32].

Algunas de las características y especificaciones con las que cuenta Android son:

SQLite: Esta base datos relacional permite el almacenamiento estructurado de datos.

Para la conexión soporta las tecnologías: Bluetooth, Wi-Fi, IDEN2, WiMAX3, CDMA4 , entre otras.

En cuanto a soporte multimedia es compatible con los medios de comunicación de audio, video y diversos formatos de imagen.

2 IDEN: Integrated Digital Enhanced Network, tecnología de conexión inalámbrica [72].

3 WiMAX: Worldwide Interoperability for Microwave Access, estándar de comunicación inalámbrica [74].

4 CDMA: Code Division Multiple Access, técnica de acceso múltiple a un medio de comunicación [73].

20

Adicionalmente da soporte a diversos dispositivos de hardware como: pantalla táctil, GPS, acelerómetros, giroscopios, magnetómetros, sensores de: proximidad, presión y luz, termómetro, etc.

Cuenta con su propia máquina virtual, Dalvik, para la compilación en tiempo de ejecución. Finalmente le facilita la tarea al programador por medio del entorno Eclipse, el cual tiene un emulador de dispositivos [32].

2.2.1.1.1.1 ARQUITECTURA DEL SISTEMA OPERATIVO ANDROID Cada uno de los sistemas operativos cuenta con una arquitectura, donde se define la estructura, funcionamiento e interacción de los componentes a nivel de software. Como se puede ver en la figura 5, Android está conformada por cuatro capas que son:

Figura 5. Arquitectura de Android.

Fuente [33].

Kernel: Android está basado en el núcleo de Linux, este núcleo le permite administrar los recursos de software sin tener que comunicarse directamente con el hardware. Dicho núcleo se encarga de cuatro principales tareas que son: ofrecer controladores de hardware, controlar la gestión de energía, gestionar los procesos que se llevan a cabo y gestionar el uso de recursos como la memoria [33].

Bibliotecas: Para ampliar el número de funcionalidades de una aplicación, Android ofrece un kit de librerías escritas en c/c++, por medio de llamadas a dichas bibliotecas se tiene acceso a rutinas de tareas que se repiten con

21

frecuencia en un sistema, como manejo de: persistencia con SQLite, multimedia, efectos gráficos con gestor de superficies, fuentes tipográficas con FreeType, entre otras [33].

Entorno de ejecución: Además de las bibliotecas mencionadas con anterioridad, Android ofrece Bibliotecas donde se encuentran especificaciones propias de Android, adicionalmente esta capa está compuesta por la máquina virtual Dalvik donde se corren los procesos [11].

Marco de aplicación: En esta capa se encuentran las componentes que consumen las aplicaciones para su funcionalidad como clases y servicios [33].

Aplicaciones: Ultima capa donde se encuentran las aplicaciones de cada uno de los dispositivos [12].

2.2.1.1.2 SYMBIAN Symbian es un sistema operativo robusto de 32 bits diseñado específicamente para dispositivos móviles, está diseñado para ejecutar aplicaciones en un entorno con recursos reducidos, lo que permite la vida útil de la batería, su principal desventaja consiste en la tardanza del equipo para responder, además el precio de los móviles con éste sistema operativo es elevado [34].

2.2.1.1.3 WINDOWS MOBILE Windows Mobile es un sistema operativo desarrollado por Microsoft exclusivo para teléfonos móviles, diseñado con el fin de ofrecer un software similar a Windows OS, por ésta razón brinda una interfaz gráfica familiar para el usuario. Windows Mobile facilita la posibilidad de usar herramientas pertenecientes a las suites Office Mobile, Outlook Mobile e Internet Explorer. Su principal desventaja es no permitir la opción de multitareas, es decir, que no permite que varios procesos se ejecuten simultáneamente compartiendo uno más procesadores [35].

2.2.1.2 COMPARACIÓN ENTRE SISTEMAS OPERATIVOS PARA MÓVILES El mercado de dispositivos móviles está en permanente movimiento: surgen nuevos sistemas operativos, desaparecen otros, algunos marcan tendencias nuevas, otros pasan desapercibidos [36]. En la tabla 2, se hace una comparación de las principales características de Symbian, Windows Phone y Android.

22

CARACTERISTICA

Variedad de Móviles

Mayor cantidad de aplicaciones disponibles

Interfaz Intuitiva

Disponibilidad del SDK

OpenSource

Multitarea

Localización GPS

Antivirus

Cortafuegos

Tabla 2. Comparación de Sistemas Operativos para móviles Fuente: Elaboración propia basada en [37].

Para el desarrollo del proyecto, se optó por usar el sistema operativo Android, debido a que presenta mayores ventajas con respecto a los demás sistemas operativos como:

El código de Android es abierto, ofreciendo muchas facilidades a la hora de desarrollar.

Actualmente existen más de 100.000 aplicaciones disponibles para dispositivos Android [32], tanto gratuitas, como de pago. Adicional a la libertad de código permite adecuar Android a otros dispositivos además de teléfonos celulares como Tablets.

El sistema Android tiene la función multitarea, es decir, es capaz de hacer funcionar a la vez varias aplicaciones y además se encarga de gestionarlas, dejarlas en modo suspensión si no se utilizan e incluso cerrarlas si llevan un periodo determinado de inactividad. De esta manera se evita un consumo excesivo de batería.

Permite realizar una aplicación portable, para una gran cantidad de usuarios.

23

2.2.1.3 ENTORNOS DE DESARROLLO PARA APLICACIONES MÓVILES

2.2.1.3.1 ECLIPSE Eclipse [11] es un entorno de desarrollo de código abierto, basado en el lenguaje de programación Java. Aunque inicialmente estaba pensado para Java en la actualidad es un entorno de software multi-lenguaje y en caso de que quiera ser utilizado para algún lenguaje en específico, brinda la posibilidad de instalar plugins y así ofrecer todas las funcionalidades. El uso de dichos plugins permite integrar varios lenguajes en un mismo IDE, adicionalmente le ofrecerle al desarrollador editores visuales para el diseño de sus proyectos por medio de la creación de diagramas UML, editores para la creación de interfaces gráficas para el usuario GUI, etc. Uno de los plugins que ofrece Eclipse para el desarrollo de aplicaciones Android es ADT Android Development Tools, este plugin permite: configurar proyectos Android, crear interfaz de usuario, depurar aplicaciones, entre otros [38]. Es por ello que eclipse es el IDE preferido a la hora de desarrollar aplicaciones sobre la plataforma Android pues ofrece herramientas que agilizan la fase de inicio en un producto de software. Por lo mencionado anteriormente el presente proyecto hizo uso de este entorno de desarrollo y de los plugins que se consideraron necesarios.

2.2.1.3.2 JAVA MICRO EDITION Java es un lenguaje de programación orientado a objetos fundado por James Gosling, Patrick Naughton, Chis Wart, Ed Frank y Mike Sheridan, miembros de la compañía Sun Microsystems en California [39]. Creado con la intencionalidad de ofrecer: un software portable, de tamaño reducido e independiente del hardware.

En 1999 Sun Microsystems da a conocer una nueva versión de Java [40], Java 2 Micro Edition, esta versión fue diseña para el desarrollo y ejecución de aplicaciones instaladas en dispositivos con memoria, pantalla y capacidad de procesamiento reducidas, como es el caso de: PDA (Personal Digital Assistant), teléfonos móviles o electrodomésticos inteligentes.

Un entorno de ejecución en Java Micro Edition, está conformado por tres componentes:

Máquina virtual: La máquina virtual de java es muy pesada para dispositivos móviles, es por eso que Java Micro Edition define dos máquinas virtuales, KMV y CVM, que se adaptan más a las limitaciones en cuanto a memoria y requerimientos computacionales [40]. KMV (Kilo Virtual Machine) dirigido a dispositivos con recursos limitados en cuanto a memoria y capacidad computacional, capacidad de memoria mínima de 128 KB, procesador entre 16 ó 32 bits. CVM (Compact Virtual Machine) dirigido a los dispositivos que cuentan con procesadores de 32 bits y con capacidad de memoria RAM de 2Mb.

Configuración: Es el conjunto de clases que permiten desarrollar aplicaciones para una gama de dispositivos. Java Micro Edition define dos configuraciones,

24

CDC y CLDC, la primera de ellas orientada a dispositivos con 512 KB de ROM, 256 de RAM, interfaz de usuario relativamente limitado y CLDC orientado a dispositivos con 192 KB A 512 KB de memoria, procesador de 16 o 32 bits, restricciones en el consumo de energía, entre otras [40].

Perfiles: Los perfiles son las clases que permitirán complementar la configuración de una aplicación, los perfiles se encargan del mantenimiento del ciclo de vida de la aplicación, de la interfaz del usuario, entre otras [40].

2.2.1.3.3 API DE GOOGLE MAPS

Es un servidor de aplicaciones de mapas online, permite localizar la ubicación de un usuario en un momento determinado, en cualquier parte del mundo. Google Maps no es un software libre, por lo que está limitado a una serie de condiciones de servicio. Puede usarse de forma gratuita, siempre que la aplicación no solicite más de 15.000 codificaciones geográficas al día [41]. 2.2.1.3.4 BACKEND AS A SERVICE PARSE

BackEnd as a Service (BaaS), es un enfoque para proporcionar servicios Web a los desarrolladores de aplicaciones móviles. Permite vincular el almacenamiento de sus aplicaciones a la nube, como se ilustra en la figura 6. El servicio que se usó para el desarrollo de la aplicación fue Parse, ya que provee un BackEnd de gestión y funciones tales como la gestión de usuarios, notificaciones push e integración con servicios de redes sociales. Además es de uso gratuito, siempre y cuando no se superen ciertos umbrales de uso [42].

Entre los principales servicios de Parse [43], se encuentran:

Modelo de datos en la nube: Permite la creación de tablas en la nube y capacidades para insertar, modificar y consultar vía API.

Notificaciones Push: Envío de notificaciones push a los usuarios de la aplicación.

Figura 6. Funcionamiento BackEnd As Service Parse.

Fuente [45].

25

2.3 ANTECEDENTES

Dado al auge y constante mejoramiento de los cálculos en GPS, se han lanzado al mercado diversas aplicaciones móviles que cuentan con sistemas de Información Geográfica orientada a móviles, como lo son:

2.3.1 TAXI GPS Esta aplicación simula el comportamiento de un taxímetro. De esta manera el pasajero podrá verificar que el taxímetro del conductor no está adulterado. Adicionalmente ofrece la opción de ingresar recargos extras como: recargos nocturnos y/o festivos; si el servicio fue realizado puerta a puerta; recargo al aeropuerto y recargo terminal [8]. Presenta inconvenientes como: las unidades corren más rápido que el taxímetro real y maneja mucha publicidad, lo cual resulta incómodo para sus usuarios.

2.3.2 TAXÍMETRO GPS Es un emulador del funcionamiento de un taxímetro, con disponibilidad gratuita para Smartphone y a 0.99 dólares para iOS. Este aplicativo permite modificar la distancia, el tiempo y la bajada de bandera. Para una aproximación más precisa verifica que el vehículo se encuentre detenido o en movimiento haciendo uso de GPS [10]. Su desventaja principal es la demora al iniciar la aplicación.

2.3.3 TAXIANDO Aplicación desarrollada sobre el sistema operativo Android, que da a conocer la velocidad del taxi, el tiempo transcurrido desde que inicia el viaje y la distancia que se ha recorrido, funciona únicamente en Costa Rica. Algunas de las desventajas que tiene es que no permite guardar datos del viaje, ni manipularlos para generar un reporte, es decir, sólo funciona como una calculadora de tiempo y tarifa [9].

26

2.4 MARCO METODOLÓGICO Hoy en día el software es inestable y cambiante por lo que las metodologías robustas como RUP no se adaptan al desarrollo, ya que considera necesario conocer desde un principio qué desea el cliente. Existe una gran variedad de metodologías para el desarrollo de software, como las metodologías ágiles, que surgen como respuesta a la necesidad de simplificar el desarrollo y la reducción del costo del proyecto, minimizando drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Estas metodologías se enfocan en las personas y en los resultados, promoviendo iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. En cada iteración se incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación [44]. Para validar el funcionamiento del prototipo se realizaron pruebas estadísticas que comprobaron el correcto funcionamiento, después de llevar a cabo las pruebas, se estimó el grado de fiabilidad operacional del sistema, estimando el porcentaje de error que se presentó en condiciones favorables.

Figura 7. Pasos para la selección de una muestra.

Fuente [45].

Las pruebas de validación permitieron probar el rendimiento y fiabilidad del aplicativo bajo ciertas condiciones. Para ello se pasó por las siguientes etapas: diseño del prototipo, parte experimental, generación de hipótesis y se finalizó con un análisis de los resultados obtenidos [46].

27

2.4.1 SCRUM Scrum es una metodología ágil y flexible desarrollada por Ken Schwaber y Jeff Sutherland, en la que se aplican un conjunto de buenas prácticas para trabajar en equipo colaborativamente, y así obtener el mejor resultado posible. Ésta metodología es ligera, fácil de entender y extremadamente fácil de implementar, basándose en la teoría de control de procesos empírica. El empirismo afirma que el conocimiento proviene de la experiencia y de tomar decisiones apoyándose en lo que se conoce [47]. La metodología Scrum es apropiada para proyectos, donde los requisitos son cambiantes y poco definidos, además se necesita obtener resultados pronto, siendo fundamental la innovación, la competitividad, la flexibilidad y la productividad, es por ello que se realizan entregas parciales y regulares del producto final [47].

2.4.1.1 PROCESO Como se ilustra en la figura 8, la metodología Scrum define un conjunto de prácticas que se recomiendan llevar a cabo en el desarrollo de un proceso. Conformada principalmente por cinco roles, cada uno de los cuales lleva a cabo tareas indispensables en el desarrollo de un proyecto, algunas de ellas son: ScrumMaster líder del equipo encargado de solucionar y eliminar cualquier distracción que retrase el desarrollo del proyecto. ProductOwner rol encargado de asegurarse que se trabaje conforme a los requerimientos del cliente y a la lógica del negocio. Team, conformado por los desarrolladores encargados de entregar el producto final. Stakeholders o clientes, interviene únicamente en las revisiones del Sprint. Administradores; personas encargadas de determinar el ambiente en el que se va a trabajar [48].

En Scrum, la etapa de desarrollo se divide en Sprints, que son ciclos cortos de trabajo que al finalizar produce un producto terminado, de duración entre un mes y como máximo seis semanas. Para el desarrollo de esta metodología es importante establecer las fechas de revisión o Sprint, donde se entregaran versiones de software [49].

A continuación se describe brevemente el proceso de desarrollo en Scrum:

1. Se inicia con los requerimientos que establece el cliente, donde hace énfasis en las prioridades que se tener en cuenta para empezar a desarrollar el aplicativo, esta lista de requisitos que define el usuario se denomina pila del producto.

2. El equipo de desarrolladores hace una estimación del esfuerzo que le llevará realizar cada una de las funcionalidades que el usuario definió previamente. En esta etapa el equipo genera una lista de los requisitos que se llevaran a cabo en el Sprint.

3. Se realiza una reunión diaria con una duración aproximada de 15 minutos, cada uno de los miembros le comparte al equipo los avances y los factores que han retrasado las tareas que se les ha asignado.

28

4. Al finalizar el Sprint se entrega parte del producto desarrollado listo para ser probado, codificado y documentado.

5. Todo el equipo de trabajo se reúne para evaluar el producto entregado para el finalizar la reunión presentar sugerencias y determinar las fechas del próximo Sprint [49].

Figura 8. Proceso Metodología Scrum.

Fuente [48].

La metodología Scrum fue la escogida para el desarrollo de este proyecto por permitir el desarrollo iterativo e incremental y por admitir avanzar en la construcción sin tener que elaborar todo el marco estructural, haciendo que se tomen acciones correctivas a tiempo.

29

3. DESARROLLO DEL PROYECTO

A continuación se describe el proceso de desarrollo del proyecto. Inicialmente se seleccionó la metodología de trabajo y se definieron los roles; luego se definió el plan del proyecto y se programaron los Sprints de desarrollo. Para elaborar el plan se priorizaron las diferentes funcionalidades y cada una de ellas fue asignada a un Sprint. Las actividades realizadas en cada uno de los Sprints se recopilaron de la sección 3.3 a la 3.8.

3.1 METODOLOGÍA DE DESARROLLO

Para el desarrollo y elaboración del proyecto "DESARROLLO DE UN PROTOTIPO DE SOFTWARE MÓVIL PARA IMPLEMENTAR UN TAXIMETRO ENFOCADO AL CONTROL DEL SERVICIO" se utilizó la metodología de trabajo Scrum, dado que permitió abordar de manera rápida cada una de las fases del proyecto y responder adecuadamente a los cambios que se presentaron a lo largo del proyecto.

3.1.1 PERSONAS Y ROLES DEL PROYECTO

Este proyecto contará con la participación de las siguientes personas:

PERSONA CONTACTO ROL

Alba Consuelo Nieto Lemus. Directora de tesis. Scrum Master1

Omar Salazar. Co-Director de tesis. Scrum Master2

Angélica María Babativa G. Estudiante. Scrum Team 1

Paula Daniela Briceño N. Estudiante. Scrum Team 2

Tabla 3. Personas Y roles del proyecto. Fuente: Elaboración propia.

Scrum Master: guía y orienta el desarrollo del proyecto, estableciendo pautas y estándares recomendables a seguir. Motiva a que los miembros del equipo sean organizados y autodidactas [50].

ScrumTeam: grupo de personas encargadas de desarrollar el producto, el equipo de trabajo debe tener dominio en diferentes áreas del conocimiento para dar cubrimiento a todas las funcionalidades y objetivos del proyecto [50].

3.1.2 PLAN DEL PROYECTO

Con el propósito de alcanzar los objetivos propuestos en el tiempo estimado, se organizaron y planificaron las diferentes actividades que se debían realizar dentro del proyecto. Para ello se hizo uso de las herramientas que ofrece IceScrum [47]. Inicialmente se construyó el Product Backlog, documento en el que se agruparon las historias de usuario funcionales y no funcionales (técnicas). Una vez se obtuvieron todas las historias de usuario, cada una de ellas fue asignada a uno de los 6 Sprint. La

30

asignación de estas historias no fue definitiva y se sometió a cambios, pues a medida que se iba avanzando en el desarrollo se encontró que algunas historias de usuarios eran redundantes y en algunas se especificó con mayor detalle la lógica de negocio.

3.1.2.1 PRODUCT BACKLOG

Documento en el que se listaron y recopilaron las historias de usuario, para cada una de ellas se definió: nombre, tipo (historias de usuario, historias predeterminadas o historias técnicas/no funcionales) y descripción. Las historias de usuario se clasificaron en 4 módulos, cada uno con un color que lo identifica: azul para gestión de tarifas, verde para medición, rosado para notificación y morado para validación. Las historias de usuario que están en color amarillo son historias técnicas.

Luego de listar todas las historias de usuario, se seleccionaron las que tuvieran un valor significativo dentro del proyecto. En el Sandbox5 se organizaron de izquierda a derecha según el orden de realización. El número que viene acompañado por la palabra Estimated indica el tiempo, estimado en semanas, para realizar cada una de las HU.

El Product Backlog se definió entre el ScrumTeam y el Scrum Master [49].

5 Sandbox: Documento en el que se incorporan todas las posibles historias de usuario que contendrá el

proyecto [49].

31

Figura 9. Sprint Backlog.

Fuente: Elaboración Propia.

32

3.1.2.1.1 PLANEACIÓN DE SPRINTS

Los Sprints son reuniones que se hacen periódicamente, cada 15 días [49], en las que el grupo de trabajo muestra lo que ha adelantado, en caso de que a algún miembro se le haya presentado dificultades, las da a conocer al equipo. Al finalizar cada Sprint se deben entregar productos terminados y se debe registrar en el Release Plan las HU que el grupo de trabajo se compromete a entregar en las próximas reuniones [47]. En el Release Plan se definieron 6 Sprints cada uno con una duración y una asignación de historias específicas.

Figura 10. Planeación de Sprints del proyecto.

Fuente: Elaboración propia.

33

Sprint Historias Planificadas

Sprint 0 Documentación previa del desarrollo móvil. Desarrollo de un prototipo inicial de bajo nivel.

Sprint 1 Construcción de las historias de usuario. Prototipo de las historias de usuario. Modelo de requerimientos. Modelo de casos de uso.

Sprint 2 Arquitectura de la aplicación. Diagrama de clases. Modelo de base de datos. Verificar y solicitar la activación del GPS. Mostrar la ubicación del usuario en el mapa. Iniciar aplicación.

Sprint 3 Cargar modelo de tarifa. Iniciar medición.

Sprint 4 Contabilizar y seleccionar recargos. Calcular valor de la carrera.

Sprint 5 Almacenar información del servicio. Generar informe con los datos del servicio.

Sprint 6 Notificar y actualizar modelo de la tarifa. Notificar queja en Twitter. Manual del usuario de la aplicación móvil: TwTaxi. Manual del usuario de la aplicación web: Administrador TwTaxi.

Tabla 4. Sprints del proyecto. Fuente: Elaboración propia.

Una vez especificados los requerimientos funcionales y no funcionales, se hará una descripción de lo que se realizó en cada uno de los Sprints. La planificación y asignación de estos requerimientos no fue definitiva pues se fueron modificando a medida que se avanzó en el proyecto o que surgieron nuevas historias.

3.2 DESARROLLO DEL SPRINT 0

ACTIVIDADES

Se realizó una documentación previa sobre desarrollo móvil. Se definió el entorno de desarrollo, junto a sus componentes y librerías. Se desarrolló un prototipo funcional inicial.

ENTREGABLES Prototipo Inicial de bajo nivel.

DURACIÓN 1 Semana Tabla 5. Actividades desarrolladas en el Sprint 0. Fuente: Elaboración propia.

34

3.2.1 AMBIENTE DE DESARROLLO

En la siguiente tabla, se muestran las herramientas utilizadas para el desarrollo del proyecto. En la sección 3.9.1, TECNOLOGÍA PARA EL DESARROLLO DE SOFTWARE PARA DISPOSITIVOS MÓVILES, se describe en detalle cada una de éstas herramientas.

CAPA CARACTERÍSTICA HERRAMIENTA UTILIZADA

Presentación

Permitió la comunicación de la aplicación móvil con otras tecnologías.

Internet inalámbrico.

Lenguaje de Programación.

Android versión 4.4 KitKat y Java Standard Edition versión 8.

Herramienta para crear prototipos de interfaz.

Justinmind versión 6.4.

Herramienta que permite crear componentes gráficos.

Android Asset Studio.

Librería utilizada para manipular y utilizar los mapas de Google.

Google Maps.

Negocio

Entorno de desarrollo y compilación.

Eclipse Luna Service Release 2 versión 4.4.2.

Herramienta utilizada para el análisis y diseño de procesos.

Bizagi Modeler.

Herramienta utilizada para el análisis y diseño de la aplicación.

Enterprise Architect.

Librería que permite la interacción de una aplicación móvil con Twitter.

Twitter4j.

Librería utilizada para administrar la compatibilidad de las diferentes versiones de Android.

Android Support v7 appcompat.

Persistencia Persistencia de Datos en la nube BackEnd Parse versión 1.7.1.

Persistencia de Datos local. SQLite. Tabla 6. Herramientas utilizadas para el desarrollo del proyecto.


35


ACTIVIDADES

Se definieron las historias de usuario con sus respectivos prototipos. Se elaboró el modelo de requerimientos. Se diseñaron los módulos y casos de uso de la aplicación.

ENTREGABLES

Diagrama de requerimientos funcionales y no funcionales. Diagrama de contexto. Modelo de procesos. Flujo de actividades.

DURACIÓN 2 Semanas Tabla 7. Actividades desarrolladas en el Sprint1.


3.3.1 HISTORIAS DE USUARIO

Se inició con la fase de planificación, en ésta fase se identificó el alcance de la aplicación, para ello se realizaron reuniones periódicas con el Scrum Master en las que se establecieron los requerimientos que suplirá el sistema, tanto funcionales como no funcionales. Estos requerimientos fueron recolectados por medio de historias de usuario. Cada una de estas historias contiene la siguiente información [51]:

Nombre: Descripción de la funcionalidad que cumple la HU.

Código: Cada tarjeta tiene un identificador único.

Historias de Usuario Relacionadas: Se establecen las dependencias y relaciones existentes entre HU.

Tipo de Historia de usuario: Descripción del tipo de historia de usuario, sea funcional o no funcional. Funcional para aquellas que definen lo que hace el aplicativo, y no funcional para las que describen la apariencia, sensación, operabilidad y mantenimiento de la aplicación [52].

Complejidad: Entre alta (A), media (M) y baja (B), se determina la dificultad para desarrollar cada historia de usuario.

Actor: Rol encargado de llevar a cabo la funcionalidad de la historia de usuario.

Descripción: Responde a las preguntas: ¿qué rol es el beneficiado?, ¿qué funcionalidad quiere del sistema? y ¿qué beneficio va a obtener?

Criterios de Aceptación: Se establecen los requisitos que se deben cumplir para que la HU sea aprobada por el cliente. Los criterios de aceptación se asemejan a un contrato, el cual es acordado entre el cliente y el equipo de desarrollo [53].

Módulo: Con el fin de facilitar la comprensión y legibilidad del aplicativo, el proyecto se dividió en 4 módulos, cada uno encargado de resolver tareas específicas.

36

.

A continuación se presentan 11 historias de usuario, cada una con una descripción breve, comprensiva y delimitada.

MÓDULO

RESPONSABILIDAD

GESTIÓN DE TARIFAS

Encargado de cargar y actualizar, periódicamente, el modelo de tarifa al inicializar el taxímetro.

MEDICIÓN

Encargado de hacer las mediciones con respecto al tiempo y a la distancia, calculando el costo total de la carrera. Además actualiza y calcula, mediante la asignación de coordenadas espaciales, la localización geográfica del móvil.

NOTIFICACIÓN

Cada vez que haya un nuevo modelo de tarifa, se le informa al usuario que el valor de la tarifa se ha actualizado. También ocurre una notificación cuando el usuario desea reportar en Twitter.

VALIDACIÓN

Encargado de verificar, mediante técnicas estadísticas, el correcto funcionamiento de la aplicación.

Tabla 8. Módulos de la aplicación móvil. Fuente: Elaboración propia

37

3.3.1.1 HU: VERIFICAR Y SOLICITAR LA ACTIVACIÓN DEL GPS

HISTORIA DE USUARIO

Código: Hu_Med_01 Nombre: Verificar y solicitar la activación del GPS.

Tipo HU: Funcional. Complejidad: M

Actor: Sistema. HU Relacionadas: Ninguna

Módulo: Medición.

Descripción: Al iniciar la aplicación se verifica que el usuario tenga el GPS activo. Se asume que el usuario tiene conexión a internet.

CRITERIOS DE ACEPTACIÓN

Condición:

Comprobar que el GPS no está activo.

Resultado:

Presentar un mensaje: “El sistema GPS está inactivo, ¿Desea activarlo?” (Redirigir a la configuración del GPS del móvil).

El usuario activa el GPS del móvil.

3.3.1.2 HU: MOSTRAR LA UBICACIÓN DEL USUARIO EN EL MAPA

HISTORIA DE USUARIO

Código: Hu_Med_02 Nombre: Mostrar la ubicación del usuario en el mapa.


Actor: Sistema. HU Relacionadas: Hu_Med_01.

Módulo: Medición.

Descripción: Guiar al usuario desde que inicia hasta que finaliza el recorrido por medio del mapa.


Condición:

Abrir la aplicación.

Resultado:

Obtener las coordenadas de localización del dispositivo móvil y mediante un círculo azul, mostrar la posición del usuario.

38

3.3.1.3 HU: INICIAR APLICACIÓN

HISTORIA DE USUARIO

Código: Hu_Med_03 Nombre: Iniciar aplicación.


Actor: Usuario. HU Relacionadas: Hu_Med_01, Hu_Med_02

Módulo: Medición.

Descripción: Permite que el usuario inicie la aplicación y así comenzar la medición del recorrido. El sistema inicializa los contadores para la medición.


Condición:

Abrir la aplicación.

La tabla de tarifa no existe.

Resultado:

- Inicializar el contador de tiempo y velocidad en: cero segundos y metros, respectivamente.

- Inicializar las unidades de arranque según el modelo de tarifa que esté en vigencia (para el 2014 de 25 unidades).

- Inicializar el valor de la carrera mínima según el modelo de tarifa que esté en vigencia, (para el 2014 en $3.900).

- Verifica que la tarifa exista y esté actualizada.

- Descargar el modelo de tarifa de Parse.

3.3.1.4 HU: INICIAR MEDICIÓN

HISTORIA DE USUARIO

Código: Hu_Med_04 Nombre: Iniciar medición.

Tipo HU: Funcional. Complejidad: A

Actor: Sistema. HU Relacionadas: Hu_Med_01, Hu_Med_02, Hu_Med_03.

39

Módulo: Medición.

Descripción: Calcular las unidades transcurridas y determinar el factor por el que debe incrementar las unidades, si por distancia o por tiempo (depende de cual esté sucediendo más rápido).


Condición:

La velocidad del vehículo es menor de 10Km/h.

La velocidad del vehículo es mayor de 10Km/h.

La velocidad del vehículo incrementa y es superior a 10km/h.

La velocidad del vehículo decrementa y es inferior a 10km/h.

Resultado:

Incrementar las unidades por tiempo cada 30 segundos.

Incrementar las unidades por distancia cada 100 metros.

Detener el contador de tiempo y retomar el valor del contador de distancia.

Detener el contador de distancia y retomar el valor del contador de tiempo.

3.3.1.5 HU: CONTABILIZAR Y SELECCIONAR RECARGOS

HISTORIA DE USUARIO

Código: Hu_Med_05 Nombre: Contabilizar y seleccionar recargos.


Actor: Usuario. HU Relacionadas: Hu_Med_05, Hu_Med_06

Módulo: Medición.

Descripción: Seleccionar los recargos que aplican al recorrido.


Condición:

El usuario llega al lugar de destino y da click en el botón detener.

El servicio es pedido por teléfono/aplicación.

Resultado:

Desplegar un menú en el que el usuario podrá seleccionar los recargos a los que aplica la carrera.

Sumar al contador monetario el valor de dicho recargo, el cual dependerá del modelo de tarifa que se haya consultado (para el 2014 de $700).

40

El servicio de taxi es prestado desde / al aeropuerto.

El servicio de taxi es prestado desde el terminal de transporte.

El servicio de taxi es prestado entre las 10:00pm y las 5:00 am.

El servicio de taxi es prestado un día festivo o un domingo.

Sumar al contador monetario el valor de dicho recargo, el cual dependerá del modelo de tarifa que se haya consultado (para el 2014 de $3.900).

Sumar al contador monetario el valor de dicho recargo, el cual dependerá del modelo de tarifa que se haya consultado (para el 2014 de $500).

Sumar al contador monetario el recargo nocturno, (para el 2014 de $1900).

Sumar al contador monetario el recargo de día dominical o festivo, (para el 2014 de $1900).

3.3.1.6 HU: CALCULAR VALOR DE LA CARRERA

HISTORIA DE USUARIO

Código: Hu_Med_06 Nombre: Calcular valor de la carrera.

Tipo HU: Funcional. Complejidad: B

Actor: Sistema. HU Relacionadas: Hu_Med_03, Hu_Med_04, Hu_Med_05.

Módulo: Medición.

Descripción: Sumar el valor de la tarifa básica y los recargos causados.


Condición:

El usuario termina de seleccionar los recargos.

Resultado:

Sumar los recargos seleccionados al contador monetario (tarifa básica).

3.3.1.7 HU: ALMACENAR INFORMACIÓN DELSERVICIO

HISTORIA DE USUARIO

Código: Hu_Med_07 Nombre: Almacenar información del servicio.

Tipo HU: No funcional. Complejidad: M

41

Actor: Sistema. HU Relacionadas: Hu_Med_03, Hu_Med_04, Hu_Med_05, Hu_Med_06.

Módulo: Medición.

Descripción: Al detener el recorrido se debe almacenar los datos del servicio.


Condición:

El usuario da click en “Detener”.

Resultado:

Almacenar en un repositorio central (Parse) los datos del servicio (Ver historia de usuario Hu_Med_08).

3.3.1.8 HU: GENERAR INFORME CON LOS DATOS DEL SERVICIO

HISTORIA DE USUARIO

Código: Hu_Med_08 Nombre: Generar informe con los datos del servicio.


Actor: Usuario HU Relacionadas: Hu_Med_03, Hu_Med_04, Hu_Med_05, Hu_Med_06, Hu_Med_07.

Módulo: Medición.

Descripción: Generar un informe con los datos del servicio, para que posteriormente sirva como soporte en caso de que el usuario desee hacer una denuncia social o para futuros estudios estadísticos.


Condición:

Al finalizar el recorrido dar click en “Datos de la carrera”.

Resultado:

Generar un informe con los siguientes datos: fecha, hora de servicio, unidades, costo total de la tarifa básica, costo total de los recargos causados, duración, distancia y total a pagar.

42

3.3.1.9 CARGAR MODELO DE TARIFA

HISTORIA DE USUARIO

Código: Hu_Tar_01. Nombre: Cargar modelo de tarifa.

Tipo HU: No funcional. Complejidad: M

Actor: Sistema, Administrador. HU Relacionadas: Hu_Med_03.

Módulo: Tarifa.

Descripción: Se carga en el servidor el modelo de tarifa.


Condición:

No existe modelo de tarifa.

Al abrir la aplicación móvil TwTaxi.

Resultado:

El administrador ingresa a la aplicación, con usuario y contraseña e importa el modelo de tarifa a Parse.

La aplicación carga los datos que se encuentran en Parse y los guarda en la base de datos local SQLite.

3.3.1.10 HU: NOTIFICAR Y ACTUALIZAR MODELO DE TARIFA

HISTORIA DE USUARIO

Código: Hu_Tar_02. Nombre: Notificar y actualizar modelo de tarifa.

Tipo HU: No Funcional. Complejidad: M

Actor: Administrador. HU Relacionadas: Hu_Tar_01.

Módulo: Tarifa.

Descripción: Para que los valores a cobrar sean vigentes, se debe actualizar en el servidor el modelo de tarifa según lo reglamentado por la Alcaldía Mayor de Bogotá.


Condición:

El modelo de tarifa no está en vigencia.

Resultado:

El administrador ingresa a la aplicación, con usuario y contraseña e importa el nuevo modelo de tarifa a Parse.

43

Al abrir la aplicación móvil TwTaxi.

La aplicación detecta que las tarifas han sido actualizadas. Automáticamente, actualiza las tarifas en la aplicación:

- Borra las tarifas que se encuentran en la base de datos local.

- Carga la base de datos que se encuentra en Parse y los guarda en la base de datos local SQLite.

- Notifica con un mensaje al usuario: Las tarifas han sido actualizadas.

3.3.1.11HU: NOTIFICAR QUEJA EN TWITTER

HISTORIA DE USUARIO

Código: Hu_Not_01 Nombre: Notificar queja en Twitter.

Tipo HU: Funcional Complejidad: A

Actor: Usuario. HU Relacionadas: Hu_Med_03, Hu_Med_04, Hu_Med_05, Hu_Med_06.

Módulo: Notificación.

Descripción: Si el usuario quiere reportar una situación anómala, puede difundirlo por medio de la red social Twitter.


Condición:

Al finalizar el recorrido el usuario da click en la opción “Reportar”.

Resultado:

Publica en la red social Twitter un reporte con los siguientes datos: placas del taxi, empresa, unidades de diferencia, motivo del reporte y comentarios.

44

3.3.1 DEPENDENCIAS ENTRE HISTORIAS DE USUARIO

La matriz de trazabilidad es una técnica bastante útil en el proceso de desarrollo de software, permite gestionar de manera adecuada los cambios que se pueden presentar a lo largo de un proyecto. Es decir al momento de querer hacer una modificación, la gestión de cambios debe tener conocimiento previo de los requerimientos que pueden verse afectados directa e indirectamente. De esta manera se evita que las historias de usuario queden inconsistentes y ambiguas a la hora de hacer un cambio. Es por ello que se usó la matriz de trazabilidad, ya que le permitió al equipo de trabajo hacer modificaciones de manera controlada [54].

En la tabla 9, se muestra la matriz de trazabilidad, en ésta matriz las Historias de Usuario (A) representan las HU que dependen de otras y las historias de usuario verticales son las que generan dichas dependencias [55].

45

Tabla 9. Matriz de trazabilidad. Fuente: Elaboración propia.

De la anterior matriz se puede observar que la historia de usuario HU_Med_003, HU_Med_004 y HU_Med_005 son las que más generan dependencias.

HISTORIAS DE USUARIO (A) DEPENDIENTES

HU Vs. HU Med_1 Med_2 Med_3 Med_4 Med_5 Med_6 Med_7 Med_8 HU_Tar_1

HU_Tar_2

HU_Not_1

I NDEPEND I ENTE S

Hu_Med_01 X X X

Hu_Med_02 X X

Hu_Med_03 X X X X X X

Hu_Med_04 X X X X X

Hu_Med_05 X X X X

Hu_Med_06 X X X

Hu_Med_07 X

Hu_Med_08

HU_Tar_01 X X

HU_Tar_02

HU_Not_1

46

3.3.3 PROTOTIPOS DE LAS HISTORIAS DE USUARIO

Los prototipos que se muestran a continuación ilustran las historias de usuario, la elaboración de estos prototipos permitió aclara la interacción del usuario con el sistema, los cuales se diseñaron con la herramienta JustInMind Prototyper Free.

PROTOTIPO DESCRIPCIÓN

En ésta pantalla se representa las historias de usuario Hu_Med_01, Hu_Med_02 y Hu_Med_03. Las cuales se encargan de: verificar que el GPS esté activo, mostrar en el mapa la ubicación actual del usuario e iniciar los contadores en cero.

Luego de dar click en el botón iniciar, arrancan los contadores de: Unidades, Valor a pagar, distancia y tiempo, además cada vez que el usuario registre movimiento, tendrá que actualizarse la posición en el mapa, de acuerdo a Hu_Med_02.

47

En ésta pantalla se muestran la historia de usuario Hu_Med_05. Ésta interfaz, muestra los recargos adicionales que se causaron al finalizar el recorrido.

Luego de hacer click en el botón "Datos de la carrera", se genera un informe con los datos de la carrera (Ver Hu_Med_08). Estos datos se almacenan en la base de datos Parse.

Una vez se finaliza el recorrido se habilita la opción de reportar en Twitter, donde el usuario ingresa: el número de la placa, nombre de la empresa, número de unidades y el motivo del reporte, posteriormente, el usuario da click en “Publicar”, para que su reporte quede registrado en la red social, de acuerdo a Hu_Not_01.

48

Finalmente, se le muestra un mensaje de notificación al usuario, informando: “Tu denuncia ha sido publicado correctamente”.

3.3.4 MODELO DE REQUERIMIENTOS

El primero de los objetivos del análisis en la lógica de negocio a incorporar, tiene que ver con la organización en módulos de trabajo de las ideas, necesidades, servicios y/o componentes que ha de tener el aplicativo, de acuerdo con la definición de las historias de usuario. Implementando los principios de abstracción, se optó por definir paquetes de trabajo más generales que puedan dar ventaja en dos casos: la interpretación adecuada de los procesos y la simplificación de trabajo, conociendo qué características son comunes en los servicios finales del software. En la figura 11, se presenta el modelo final de requerimientos, el cual incluye los requerimientos funcionales (necesidades propias para la aplicación) y los requerimientos no funcionales (necesidades para soportar los requerimientos funcionales).

Figura 11. Módulo de Requerimientos para la Aplicación.


custom Modelo de Requerimientos

Requerimientos No funcionales

+ Rnf_App_01_Persistencia

+ Rnf_App_02_Arquitectura

+ Rnf_App_03_Desempeño

+ Rnf_App_04_Usabilidad

+ Rnf_App_05_Disponibil idad

+ Rnf_App_06_Confiabilidad

Requisitos Funcionales

+ Notificación

+ Medición

+ Gestión de tarifasEl modelo de requisitos estructura el catálogo de

Requerimientos Funcionales y No Funcionales de

la aplicación.

49

3.3.4.1 REQUERIMIENTOS FUNCIONALES

A continuación se listan los requerimientos de cada uno de los módulos de la aplicación. Dichos requerimientos son el resultado de las propuestas que el Scrum Team produjo junto con el Scrum Master. En éste diagrama se podrían incluir requerimientos adicionales si el alcance del proyecto crece.

El siguiente diagrama muestra los requerimientos de los 3 módulos principales:

Figura 12. Diagrama de Requerimientos funcionales para los módulos principales de la Aplicación.


3.3.4.2 REQUERIMIENTOS NO FUNCIONALES

En el proyecto, se consideraron los siguientes requerimientos no funcionales:

PERSISTENCIA: Para la administración y gestión de la información, los datos se

almacenaron en dos tipos de bases de datos, una de ellas local (SQLite) y la otra en la nube (Parse). En Parse se guardaron los datos del servicio, como: fecha, distancia recorrida, duración del recorrido, valor total, unidades que marcó el taxi y unidades que marcó la aplicación. También se almacenaron datos del vehículo como: nombre del conductor, número de placa y nombre de la empresa del vehículo. La tecnología de BD escogida por el Scrum Team, fue SQLite.

ARQUITECTURA: La aplicación se construyó sobre un modelo de arquitectura de tres capas: presentación, aplicación, datos. La capa de presentación es la responsable de presentar la información al usuario, la capa de aplicación es la encargada de controlar la lógica de negocio y la capa de datos es la responsable de gestionar todas las posibles operaciones que se pueden hacer sobre la base de datos [52].

custom Requerimientos Funcionales

Notificación

+ Rf_Not_21_NotificarCambio Tarifa.

+ Rf_Not_22_NotificarQueja: Twitter

Gestión de tarifas

+ Rf_Tar_11_CargarModeloTarifa

+ Rf_Tar_12_ActualizarModeloTarifa

Medición

+ Rf_Med_01_IniciarAplicación

+ Rf_Med_02_IniciarMedición

+ Rf_Med_03_DetenerMedición

+ Rf_Med_04_VerificarGPS

+ Rf_Med_05_MostrarPosiciónActual

+ Rf_Med_06_Iniciar Contadores

+ Rf_Med_07_CalcularTarifaTotal

+ Rf_Med_08_CalcularRecargosAdicionales

+ Rf_Med_09_GenerarReporte

50

DESEMPEÑO: Para evitar desfases en la medición, el tiempo de respuesta al iniciar la aplicación será en fracciones de milisegundos. De esta manera tanto el taxímetro del móvil como el de la aplicación empezarán al mismo tiempo.

USABILIDAD: Se le presentará al usuario una interfaz amigable e intuitiva de modo que el usuario pueda acceder a todas las funcionalidades del sistema con facilidad.

DISPONIBILIDAD: La aplicación funcionará las 24 horas del día los 7 días de la semana.

CONFIABILIDAD: El sistema debe asegurar el correcto funcionamiento, es por ello que mediante técnicas estadísticas se estimara un margen de confiablidad de la aplicación (Ver sección Pruebas).

3.3.5 MODELO DE CASOS DE USO

Uno de los objetivos más importantes a la hora de diseñar una solución, es conocer el ¿Qué? de la aplicación, es decir, asegurar que el ScrumTeam sepa cuáles son los servicios que debe prestar la aplicación y para ello es que se vale de: las historias de usuario y del Product Backlog. Ya con plasmar los requerimientos funcionales existe una idea general de esta pregunta, sin embargo es a través de los casos de uso que se logra interpretar adecuadamente las necesidades propias del cliente. Dado que se siguió una metodología ágil no se utilizó el formato extendido de casos de uso, sino que se sólo se modeló la interacción entre actor-sistema; las HU fueron utilizadas para complementar los escenarios en cada interacción.

3.3.5.1 NOMENCLATURA PARA LOS CASOS DE USO

Antes de entrar en los diagramas y como parte de las estrategias en la creación de los casos de uso, se propuso que la nomenclatura de los diferentes módulos estuviera regida por un número de identificación que indicaría a qué servicio corresponde cada caso de uso, de tal manera que los requerimientos asociados a estos diagramas serían nombrados de la siguiente manera:

1) Diagrama de casos de uso de Gestión de Medición representado con la serie "000"

Cu_Med_000_Medición

Uno de los casos de uso en este paquete es iniciar la aplicación, que se identifica así: Cu_Med_01_Iniciar aplicación.

2) Diagrama de casos de uso de Gestión de Tarifas representado con la serie "100"

Cu_Tar_100_GestiondeTarifas

51

Uno de los casos de uso en este paquete es cargar el modelo de la tarifa, que se identifica así: Cu_Tar_11_CargarModelo Tarifa.

3) Diagrama de casos de uso de Notificación representado con la serie "200"

Cu_Not_200_GestiondeTarifas

Uno de los casos de uso en este paquete es notificar al usuario el cambio de la tarifa, que se identifica así: Cu_Not_21_NotificarCambioTarifa.

Con éste sistema fue más sencillo implementar recursividad en los casos de uso y demarcar aquellos servicios secundarios sin perder de vista su punto de inicio, módulo al que pertenecen y los responsables de su ejecución.

3.3.5.2 DIAGRAMA DE CONTEXTO

En el siguiente gráfico se resume la estrategia de nomenclatura para los casos de uso realizados en el Sprint 1, cada uno con sus respectivas funcionalidades y responsabilidades. En este diagrama intervienen: el usuario de la aplicación, el administrador y el sistema.

Figura 13. Diagrama de Contexto con la estrategia de nomenclatura de los casos de uso.


uc Diagrama de Contexto

MÓDULOS

Sistema

Usuario

Cu_Med_000_Medición

Cu_Tar_100_Gestión de

tarifas

Cu_Not_200_Notificación

Administrador

52

3.3.5.3 DIAGRAMAS DE CASOS DE USO

El primer diagrama presentado se relaciona con las tareas que se deben ejecutar desde el módulo de Medición. Allí se incluyen los usuarios (actores) responsables y sus posibilidades dentro del aplicativo:

Figura 14. Diagrama de casos de uso para el módulo de medición.


En el módulo de gestión de tarifas, el administrador puede realizar dos tareas: cargar y actualizar tarifa de manera remota. El primero se realizará cada año, mientras que el segundo se ejecutará cada vez que el usuario tenga desactualizado el modelo de tarifa.

uc Medición

Notificación

Usuario

Cu_Med_09_Generar

Reporte

Cu_Med_01_Iniciar

aplicación

Cu_Med_02_Iniciar

Medición

Cu_Med_03_Detener

Medición

Cu_Med_07_CalcularTarifa

Total

Cu_Med_04_VerificarGPS

Cu_Med_05_MostrarPosición

Actual

Cu_Med_06_Iniciar

Contadores

Cu_Med_08_CalcularRecargos

Adicionales

«include»

«extend»

«include»

«include»

«include»

«include»

53

Figura 15. Diagrama de casos de uso para el módulo de gestión de tarifas.


Por otro lado, en la figura 15, se muestran los casos de uso del módulo de notificación, módulo encargado de gestionar todos los mensajes que le llegan al usuario. El envío de estos mensajes se puede presentar ante dos situaciones: el modelo de tarifa se actualizó ó para notificar que el reporte vía Twitter se realizó correctamente.

uc Gestión de tarifas

Gestión de Tarifas

Administrador

Cu_Tar_11_CargarModelo

Tarifa

Cu_Tar_12_ActualizarModelo

Tarifa

54

Figura 16. Diagrama de casos de uso para el módulo de notificación.


3.3.5.4 MODELO DE PROCESOS

El modelo de procesos representa el flujo de tareas de la aplicación (Ver figura 17). Antes de contabilizar las unidades que marca el dispositivo móvil, es necesario iniciar actividades previas como: activar el GPS e iniciar aplicación. Una vez se ha preparado el sistema y se han calculado las unidades, se debe detener la aplicación, calcular recargos y tarifa básica; finalmente con el costo total de la carrera el usuario decide, mediante un punto de bifurcación, si desea reportar o no en Twitter alguna situación anómala que se haya presentado durante el recorrido. Para elaborar el diagrama de actividades se utilizó la notación BPMN, por sus siglas en inglés, Business Process Modeling Notation, pues permitió modelar las actividades de una manera unificada y estandarizada, facilitando así la comprensión del entorno del negocio a los miembros del equipo [56].

uc Cu_Not_200_Notificación

Notificación

Cu_Not_21_NotificarCambio

Tarifa

Cu_Not_22_NotificarQueja

Twiter

Usuario

Sistema

55

Figura 17. Modelo de procesos. Fuente: Elaboración propia

56

3.3.5.5 FLUJO DE ACTIVIDADES

En la figura 18, se muestra el flujo de actividades, éste diagrama se divide en 4 secciones:

Preparación: Antes de inicializar el taxímetro, el usuario debe tener el GPS activo y conocer la ubicación geográfica donde se encuentra. De esta manera el taxímetro del vehículo, como el del móvil, iniciarán al mismo tiempo, lo que evitará desfases y retardos de tiempo al iniciar la aplicación.

Medición: Una vez el usuario esté listo para utilizar el taxímetro, se calculan las unidades transcurridas, dicho cálculo se puede dar por distancia o tiempo.

Calcular costos: Una vez el usuario de click en detener, deben parar los contadores y se debe calcular el valor de la tarifa básica, evaluando el equivalente, entre unidades marcadas y precio por cada unidad. Dependiendo de la hora y la fecha, se incrementará al contador los recargos que se hayan causado.

Reportar: Al finalizar el recorrido el usuario podrá hacer un reporte dando a conocer: motivo del reporte, número de unidades que marcó el taxímetro del taxi, placa y empresa del vehículo.

57

Figura 18. Flujo de actividades.


uc Diagrama de Proceso de Negocio

Reportar

Calcular costos

Medición

Abrir aplicativo Proceso: verificación y solicitud de activación GPS

Usuario

Proceso: mostrar usuario en el mapa

Coordenadas del

dispositiv o

Muestra la posición actual del usuario en el

mapa.

Mensaje solicitando activ ar GPS.

Calcular unidades transcurridas

Unidades transcurridas

Cálculo automático de recargos causados.

Hora y fecha

Costo del racargo nocturno, dominical y/o

festiv o.

Cálculo manual de recargos causados.

Recargos seleccionados por el

usuario.

Detener

Costo de los recargos

seleccionados.

Suma de la tarifa básica

más recargos.

Costo total de la carrera

Reportar Generar formulario

Placa y nombre de la

empresa del v ehículo.Información del recorrido

Iniciar

aplicativoInicializar taximetro

Datos de configuración del

dispositiv o.

Cálculo de la tarifa básica

Tarifa básica

Tarifa del recargo nocturno,

dominical y/o festiv o.

Preparación

Costo total tarifa básica

Tarifa de los recargos

seleccionados

Reporte exitoso

Entrada

Entrada

Salida

Salida

Entrada

Salida

Entrada

Salida

Entrada

Entrada

Entrada

Salida

Salida

Entrada

Entrada

Entrada

Entrada

Entrada

Entrada

Salida

Entrada

Entrada

Entrada

Salida

58


ACTIVIDADES

Se diseñó el modelo arquitectónico y estructural de la aplicación. Se elaboraron las historias de usuario: Verificar y solicitar la activación del GPS, mostrar la ubicación del usuario en el mapa e iniciar aplicación.

ENTREGABLES

Arquitectura de la aplicación. Diagrama de clases. Diagrama de secuencia. Modelo de base de datos. Prototipo de las historias de usuario Hu_Med_01, Hu_Med_02 y Hu_Med_03.

DURACIÓN 2 Semanas. Tabla 10. Actividades Sprint 2. Fuente: Elaboración Propia.

Luego de finalizar el Sprint 1, se observó que algunas de las historias de usuario eran inconsistentes y redundantes como es el caso de las historias de usuario: actualizar mapa y mostrar ubicación del usuario, se dejó la segunda y se especificó qué a medida que el usuario cambiara de posición se debía actualizar el mapa. Igualmente sucedió con las historias de usuario: notificar y actualizar tarifa, las cuales se unieron en una sola historia. Inicialmente se había considerado la historia notificar, para que el usuario otorgará permisos de su dispositivo móvil, en el momento de descargar la tarifa, pero gracias al BackEnd Parse y la sincronización con la base de datos SQLite, se pudo actualizar las tarifas sin intervención del usuario, de esta manera se automatizó el proceso y se garantizó que las tarifas a cobrar fueran vigentes.

3.4.1 ARQUITECTURA DE LA APLICACIÓN

Se desarrolló el prototipo sobre el lenguaje de programación java, soportado por una arquitectura de tres capas. La aplicación hizo uso de las librerías: Google Play Services, Parse y Twitter4j para tener acceso a la API de GoogleMaps, al BackEnd Parse y a la red social Twitter, respectivamente.

Modelo Vista Controlador (MVC) es un patrón de diseño que separa la interfaz de usuario, la lógica de negocio y los datos de la aplicación. Este patrón establece que un sistema de software debe estar compuesto por 3 capas [57]: modelo, vista y controlador. Cada una de las capas cumple una funcionalidad dentro del proyecto, las cuales se nombran a continuación:

Vista: Es la responsable de presentar la información al usuario y de controlar cómo se da la interacción usuario/sistema. Para ello se diseñaron 7 interfaces gráficas en formato xml.

Controlador: Contiene toda la logica de la aplicación. Se comunica con la capa de presentación (para capturar las solicitudes del usuario o enviar respuestas al usuario) y con la capa de acceso a los datos (para almacenar o recuperar datos

59

específicos).La funcionalidad de la aplicación está compuesta por dos procesos: calcular tarifa basica y reportar en Twitter.

Modelo: Encargada de suministrar todos los datos de la aplicación y de acceder a los mismos. Los datos se almacenaron en dos bases de datos: SQLite Local y BackEnd Parse, la primera es la base de datos del dispositivo móvil, en la que se guardó unicamente los datos de la tarifa, mientras que en el BackEnd Parse se almacenó la información de todos los servicios realizados a la fecha.

Dicha segmentación de tareas permitió que la aplicación fuera mucho más modular e independiente. Sin embargo éstas capas constantemente se comunicaron e interactuaron entre sí para realizar tareas especificas.

El flujo de comunicación entre éstas tres capas se da de la siguiente manera: el usuario realiza una acción sobre la interfaz; el controlador recibe la petición, ejecuta la acción asociada a dicho evento y accede a la capa de modelo, la capa de modelo le suministra los datos que éste necesite. Una vez el controlador tiene los datos los envía a la capa de presentación [58].

Este patrón reduce la dependencia entre los módulos del sistema y minimiza el impacto que puede generar un cambio [58].

60

Figura 19. Arquitectura de la aplicación.

Fuente: Elaboración propia

61

3.4.2 DIAGRAMA DE CLASES

A continuación se muestran las clases que se utilizaron para desarrollar la aplicación, cada una con sus respectivos atributos, métodos y relaciones. Se utilizó el patrón facade con el fin de proporcionar interfaces de alto nivel que minimizaran la comunicación y dependencia entre las clases del sistema [59]. De esta manera el usuario solo tuvo acceso a las fachadas que necesitó.

En la figura 20 se muestra el diagrama de clases el cual fue diseñado bajo el estándar UML 2.0 y elaborado con la herramienta Enterprise Architect.

A continuación, se describen las principales clases de la aplicación:

GestiónTaximetro: Clase facade, conoce todas las operaciones relacionadas con el servicio. Permite la comunicación de las interfaces con las clases de la capa de lógica.

GestiónDatos: Clase facade, conoce todas las operaciones relacionadas con el manejo de los datos (Tarifas, Recargos) tanto del BackEnd Parse, como de la base de datos SQLite.

InicioApp: Clase llamada al iniciar la aplicación. Es la responsable de inicializar y cargar todos los elementos necesarios para correr la aplicación. Verifica que el usuario tenga el GPS activo, muestra la posición del usuario en el mapa, carga la tabla tarifa de SQLite o Parse (dependiendo donde se encuentre la tarifa) e inicializa los contadores.

Servidor Parse: Establece e inicializa la conexión con BackEnd Parse.

Tarifa: Clase que representa una tarifa. Contiene los elementos de una tarifa: unidades, valor, fecha de vigencia y nombre del recargo, en caso de que aplique.

Tarifas SQLiteHelper: Almacena todos los datos de la tarifa.

Localización: Clase encargada de capturar la longitud y latitud del dispositivo para luego mostrarla en el mapa. Actualiza el mapa cada vez que el dispositivo cambia de posición (latitud y longitud).

62

Figura 20. Diagrama de Clases. Fuente: Elaboración Propia

class DiagramaClases

CONTROLADOR

Modelo::GestorDatos

- empresas: List<Empresa>

- parse: ServidorParse

- recargos: List<Tarifa>

- sqlite: TarifaSqLiteHelper

- tarifas: List<Tarifa>

+ accessUrlTwitter(): String

+ actualizarTarifa(List<ParseObject>, Activity): boolean

+ authorizeUrlTwitter(): String

+ callBackUrlTwitter(): String

+ cargarEmpresa(String, String): void

+ cargarTarifa(int, int, String, String): void

+ consumerKeyTwitter(): String

+ consumerSecretTwitter(): String

+ GestorDatos()

+ inicializarParse(Activity): void

+ insertarRegistros(Tarifa): void

+ insertarRegistros(Empresa): void

+ listarEmpresas(Activity): List<Empresa>

+ listarRecargos(Activity): List<Tarifa>

+ listarTarifas(Activity): List<Tarifa>

+ obtenerNumeroRegistros(Activity): int

+ obtenerNumeroRegistrosEmpresa(Activity): int

+ requestUrlTwitter(): String

Modelo::GestorTaximetro

- localizacion: Localizacion

~ mapa: GoogleMap

- servicio: Servicio

+ actualizarPuntosPosicion(double, double): void

+ actualizarVelocidad(double): void

+ calcularValorServicio(Activity): int

+ GestorTaximetro(GoogleMap)

+ GestorTaximetro()

+ getLocalizacion(): Localizacion

+ getServicio(): Servicio

+ getTotalRecargos(): double

+ iniciarServicio(double): void

+ mostrarMapa(): void

+ mostrarRegistros(): String

+ setTotalRecargos(double): void

Datos::DatosTwitter

+ ACCESS_URL: String = "https://api.tw... {readOnly}

+ AUTHORIZE_URL: String = "https://api.tw... {readOnly}

+ CONSUMER_KEY: String = "ON6Q0rSwr8DlJ2... {readOnly}

+ CONSUMER_SECRET: String = "BHgV4s7VOCKYAe... {readOnly}

+ OAUTH_CALLBACK_URL: String = "mdw://twitter" {readOnly}

+ REQUEST_URL: String = "https://api.tw... {readOnly}

+ getAccessUrl(): String

+ getAuthorizeUrl(): String

+ getConsumerKey(): String

+ getConsumerSecret(): String

+ getOauthCallbackUrl(): String

+ getRequestUrl(): String

Datos::Serv idorParse

- Parse_App_Id: String = "HwB7Tfjm0ha4jQ... {readOnly}

- Parse_Client_Key: String = "5bXnPLiXNuofLA... {readOnly}

+ inicializarParse(Activity): void

+ ServidorParse()

SQLiteOpenHelper

Datos::TarifaSqLiteHelper

- sqlCreate: String = "CREATE TABLE T...

- sqlCreateEmpresa: String = "CREATE TABLE E...

+ borrarTarifas(): void

+ contarRegistrosEmpresa(): int

+ contarRegistrosTarifa(): int

+ insertarRegistroEmpresa(Empresa): void

+ insertarRegistroTarifa(Tarifa): void

+ listarEmpresas(): List<Empresa>

+ listarRecargos(): List<Tarifa>

+ listarTarifas(): List<Tarifa>

+ onCreate(SQLiteDatabase): void

+ onUpgrade(SQLiteDatabase, int, int): void

+ TarifaSqLiteHelper(Context)

Modelo::Empresa

~ nombre: String

~ telefono: String

+ Empresa(String, String)

+ getNombre(): String

+ getTelefono(): String

+ setNombre(String): void

+ setTelefono(String): void

ActionBarActivity

Modelo::Localizacion

- latitud: double

- longitud: double

- mapa: GoogleMap

+ getLatitud(): double

+ getLongitud(): double

+ getMapa(): GoogleMap

+ Localizacion(GoogleMap)

+ mostrarMapa(): void

+ setLatitud(double): void

+ setLongitud(double): void

+ setMapa(GoogleMap): void

Modelo::Medicion

- contadorDistancia: double = 0

- contadorTiempo: int = 0

- hora: String ([]) = new String[65]

- posicionMedicion: int = 0

~ tiempo: Tiempo

- vel: double ([]) = new double[65]

+ calcularDistancia(double, int): void

+ calcularTiempo(): void

+ getContadorDistancia(): double

+ getContadorTiempo(): int

+ getTiempo(): Tiempo

+ insertarRegistros(double): void

+ Medicion()


+ retonarFecha(): String

+ setContadorDistancia(double): void

+ setContadorTiempo(int): void

Modelo::Serv icio

- fecha: String = ""

~ medicion: Medicion

- tiempoTotal: String = ""

- totalPagar: double = 0

- totalRecargos: double = 0

- unidades: int = 25

- velocidad: double = 0

+ aumentarUnidad(): void

+ calcularValorServicio(Activity): int

+ conversionVelocidad(double): double

+ getFecha(): String

+ getMedicion(): Medicion

+ getTiempoTotal(): String

+ getTotalPagar(): double

+ getTotalRecargos(): double

+ getUnidades(): int

+ getVelocidad(): double

+ iniciarMedicion(double): void


+ Servicio()

+ setFecha(String): void

+ setMedicion(Medicion): void

+ setTiempoTotal(String): void

+ setTotalPagar(double): void

+ setTotalRecargos(double): void

+ setUnidades(int): void

+ setVelocidad(double): void

Modelo::Tarifa

- fechaVigencia: String

- id: int

- nombre: String

- unidades: int

- valor: int

+ getFechaVigencia(): String

+ getId(): int

+ getNombre(): String

+ getUnidades(): int

+ getValor(): int

+ setFechaVigencia(String): void

+ setId(int): void

+ setNombre(String): void

+ setUnidades(int): void

+ setValor(int): void

+ Tarifa(int, int, int, String, String)

+ Tarifa(int, int)

+ Tarifa(int, int, String)

+ Tarifa()

Runnable

Modelo::Tiempo

- ampm: String

- fechaActual: String = " "

- h1: Thread

- hora: String

- horaCompleta: String = " "

- horaInicio: String = ""

- minutos: String

- segundos: String

+ getFechaActual(): String

+ getHoraCompleta(): String

+ getHoraInicio(): String

+ obtenerFechaActual(): void

+ obtenerHoraActual(): void

+ run(): void

+ setHoraCompleta(String): void

+ setHoraInicio(String): void

+ Tiempo()

ActionBarActivity

Controlador::EmpresaApp

- datos: GestorDatos

+ mostrarEmpresa(): void

# onCreate(Bundle): void

+ onCreateOptionsMenu(Menu): boolean

+ onOptionsItemSelected(MenuItem): boolean

ActionBarActivity

Controlador::EmpresaApp::InicioApp

- datos: GestorDatos

+ mapa: GoogleMap

~ mChronometer: Chronometer

- taximetro: GestorTaximetro

+ actionBtnIniciarServicio(): void

+ actualizarPosicion(): void

+ actualizarTarifa(): void

+ cargarDatosParseEmpresa(): void

+ cargarDatosParseTarifa(): void

+ inicializarContadores(): void

+ listenerPaginaRecargos(View): void



+ onDestroy(): void


# onRestart(): void

# onStop(): void

+ VerificarGPSActivo(): void

ActionBarActivity

Controlador::RecargoApp

~ datos: GestorDatos

+ mostrarRecargos(): void




ActionBarActivity

Controlador::RecargosServ icioApp


- recargos: List<Tarifa>

~ taximetro: GestorTaximetro

+ buscarRecargo(String): int

+ cargarValoresRecargos(): void

+ listarRecargos(): void

+ listenerPaginaResumen(View): void




+ restarRecargo(TextView): void

+ sumarRecargo(TextView): void

+ totalizarRecargos(): void

ActionBarActivity

Controlador::ResumenApp

- consumer: CommonsHttpOAuthConsumer


- provider: CommonsHttpOAuthProvider

~ taximetro: GestorTaximetro

- almacenarInformacion(): void

+ calculartotalAPagar(): void

+ cerrarAplicacion(View): void

+ mostrarTablaResumen(): void




ActionBarActivity

Controlador::TarifaApp


+ mostrarTarifas(): void




ActionBarActivity

Controlador::TwitterApp

- ACCESS_KEY: String = null

- ACCESS_SECRET: String = null

- consumer: CommonsHttpOAuthConsumer

- provider: CommonsHttpOAuthProvider

- twitter: Twitter

+ construirMensaje(): String

- enviarTweet(String): void

+ onCreate(Bundle): void



+ onResume(): void

NEGOCIO

63

3.4.3 DIAGRAMA DE SECUENCIA

La figura 21, ilustra la secuencia de mensajes entre objetos al iniciar la aplicación. Los diagramas de secuencia de los demás casos de uso se encuentran el anexo A.

Figura 21.Diagrama de Secuencia: Iniciar Aplicación. Fuente: Elaboración Propia.

sd Iniciar Aplicación

Usuario

«activity»

InicioApp

tm:Taximetro p:Parsesv:Servicio lc: Localización sq: SQLiteOpenHelpergm: GoogleMaplm: LocationManager

actualizarPosicion ()

contarRegistrosTabla(): numeroRegistros

mostrarMapa()

inicializarContadores()

actualizarVelocidad(velocidad)

getMapa()

cargarDatosParse()

getLongitude()

getLatitude()

onCreate(Bundle)

cargarDatosParse()

obtenerNumeroRegistros(Activity): numeroRegistros

obtenerNumeroRegistros(Activity)

actualizarPuntosPosicion(): latitud,longuitud

locManager=if(!locManager.isProviderEnabled)

mostrarMapa()

verificarGPSActivo()

64

3.4.4 MODELO DE PERSISTENCIA DE DATOS

La arquitectura cliente servidor se caracteriza por que se distribuyen las tareas del sistema: el servidor se encarga de gestionar el acceso a los datos, controlar la concurrencia, recuperarse de errores y de optimizar los tiempos de consultas. Mientras que el cliente se encarga de manejar la parte visible de la aplicación (interfaz de usuario). La interacción cliente servidor se da de la siguiente manera: el cliente solicita determinado servicio al servidor, el servidor recibe la solicitud y envía uno o más mensajes con la respuesta [52].

Estas son algunas de las ventajas que ofrece ésta arquitectura [60]:

Independencia de los datos: La aplicación no se ve afectada ante cambios que suceden en la base de datos (cambio de formato de los datos).

Portabilidad: La base de datos puede ser ejecutada en diferentes sistemas operativos.

Escalabilidad: La escalabilidad se puede dar horizontalmente, aumentando el número de clientes o verticalmente, cambiando la configuración para que el sistema sea más grande y eficiente.

Las ventajas mencionadas anteriormente hacen que las transacciones y consultas en la base de datos sean más eficientes [52].

3.4.4.1 PERSISTENCIA DEL LADO DEL CLIENTE

En la base de datos local, se almacenaron únicamente las tablas tarifa y empresa, ya que el usuario no tiene que preocuparse por gestionar los datos del recorrido, solamente los debe enviar.

Figura 22. Persistencia del cliente.


class Persistencia del cliente

TARIFA

«column»

*PK K_Object_Id: VARCHAR(11)

* N_Nombre: VARCHAR(15)

* Q_Unidad: NUMBER(3)

* Q_Valor: NUMBER(5)

* F_Fecha_Vigencia_Tarifa: DATE

«PK»

+ PK_TARIFA(VARCHAR)

EMPRESA

«column»


N_Nombre: VARCHAR(20)

N_Telefono: VARCHAR(7)

«PK»

+ PK_EMPRESA(VARCHAR)

65

3.4.4.2 PERSISTENCIA DEL LADO DEL SERVIDOR

Como se mencionó anteriormente, se utilizó Parse para la persistencia remota de los datos de la aplicación. Estos datos fueron gestionados de manera remota vía internet, resultando así bastante eficiente y práctico él envió de la información tanto del lado del cliente, enviando datos del recorrido, como del servidor, enviando actualizaciones periódicas del modelo de tarifa. Del lado del servidor se utilizó principalmente para:

Gestión de usuarios: Gracias a la clase User que ofrece Parse [61], es posible autenticarse y registrarse desde la aplicación web AdministradorTwTaxi, controlando así el acceso a la aplicación.

Gestión de servicios: Una vez que el usuario finalizó el recorrido, los datos del servicio fueron enviados a Parse. Esto datos pueden ser usados, posteriormente, para análisis estadísticos en los que se pueda determinar las situaciones en las que más se presentan adulteración del taxímetro.

Gestión de tarifa: La clase tarifa se utilizó para cargar y actualizar las tarifas, de tal manera que las tarifas a cobrar siempre fueran vigentes.

Figura 23. Persistencia en el servidor. Fuente: Elaboración propia.

dm Persistencia del serv idor

SERVICIO

«column»

*PK K_Object_Id_Servicio: VARCHAR(11)

* K_Fecha: DATE

V_Distancia: NUMBER(10,2)

V_Duracion: NUMBER(2,2)

Q_Total_Pagar: NUMBER(11,2)

Q_Unidades_Aplicación: NUMBER(3)

Q_Unidades_Vehiculo: NUMBER(3)

Hora: VARCHAR(9)

Q_Total_Recargos: NUMBER(11,2)

Q_Total_Unidades: NUMBER(11,2)

K_Placa: NUMBER(6)

* K_Object_Id_Empresa: VARCHAR(11)

* K_Object_Id_Tarifa: VARCHAR(11)

«PK»

+ PK_SERVICIO(VARCHAR)

«unique»

+ UQ_SERVICIO_K_Object_Id_Empre(VARCHAR)

TARIFA

«column»

*PK K_Object_Id_Tarifa: VARCHAR(11)

* N_Nombre: VARCHAR(15)

* Q_Unidad: NUMBER(3)

* Q_Valor: NUMBER(5)

* F_Fecha_Vigencia_Tarifa: DATE

«PK»

+ PK_TARIFA(VARCHAR)

EMPRESA

«column»

*FK K_Object_Id_Empresa: VARCHAR(11)

N_Nombre: VARCHAR(20)

N_Telefono: VARCHAR(7)

«FK»

+ FK_EMPRESA(VARCHAR)

USUARIO

«column»


N_Username: VARCHAR(10)

N_Password: VARCHAR(15)

«PK»

+ PK_USUARIO(VARCHAR)

66


ACTIVIDADES Se desarrollaron los módulos de la aplicación: iniciar sesión y cargar tarifa.

ENTREGABLES Diagrama proceso de negocio: cargar tarifa.


MÓDULO PARA CARGAR LA TARIFA EN EL SERVIDOR

El modelo de proceso que se muestra en la figura 24 ilustra el flujo de tareas que sigue el administrador cuando desea cargar las tarifas al servidor. En este proceso intervienen: el usuario, el administrador y el sistema. El usuario inicia el proceso ingresando los datos de la tarifa en un archivo Excel, estos datos son publicados previamente por la Secretaria Distrital de Movilidad, luego de que el usuario ingresa los datos, los debe guardar en formato CSV. Una vez se tienen las tarifas en dicho formato el administrador debe ingresar a la aplicación AdministradorTwTaxi y seleccionar el archivo .csv para empezar a importar los datos al servidor Parse. Enviada ésta información el sistema eliminará las tarifas existentes y cargará las nuevas al servidor. El proceso finalizará cuando se despliegue un mensaje en la aplicación informándole al usuario que las tarifas se han importado con éxito.

67

Figura 24. Modelo de procesos: Cargar tarifa. Fuente: Elaboración propia.

68


ACTIVIDADES Se desarrollaron los módulos de la aplicación: Calcular valor de la carrera, contabilizar y seleccionar recargos adicionales.

ENTREGABLES Avance en el desarrollo del prototipo.


Calcular valor de la carrera: Se integraron las historias de usuario: iniciar medición y cargar tarifa. Una vez el usuario finalizó la carrera, se capturó el número de unidades que marcó la aplicación y se buscó su equivalente en pesos, con esta información se le mostró al usuario el costo de la tarifa básica.

Contabilizar y seleccionar recargos: Aunque inicialmente se propuso que el recargo nocturno y el recargo por día dominical se seleccionaran automáticamente, el equipo de trabajo llego a la conclusión que sería mejor si todos los recargos se marcaran manualmente, de esta manera se evitaría que, erróneamente, se seleccionaran algunos de los recargos producto de información desactualizada.


ACTIVIDADES Se desarrollaron los módulos de la aplicación: Almacenar información del servicio y generar informe con los datos del servicio.

ENTREGABLES Avance en el desarrollo del prototipo.


Almacenar información del servicio: Inmediatamente el usuario finaliza el recorrido los datos del servicio son enviados al servidor, sin importar si el usuario desea o no reportar el recorrido. Esto permitirá que se tenga gran cantidad de información en caso de que se desee realizar un análisis estadístico.

Generar informe con los datos: Al finalizar el recorrido, al usuario se le presenta un resumen de la carrera, en el que se le informa: fecha, hora de servicio, unidades, total unidades, total recargos, duración y distancia.

69


ACTIVIDADES

Se elaboró el módulo de notificación, específicamente las historias de usuario: Notificar y actualizar modelo de tarifa, y notificar queja en Twitter.

Se elaboraron los manuales de la aplicación: Móvil y web.

ENTREGABLES Avance en el desarrollo del prototipo. Manuales para el Administrador y para el usuario final de TwTaxi.


En ésta etapa del proyecto la aplicación ya generaba el costo total del servicio y se guardaban los datos del recorrido en el servidor. Con ésta información el pasajero ya contaba con los soportes necesarios para hacer un reporte en Twitter. Inicialmente se propuso que el reporte tuviera gran cantidad de información como: fecha, hora de servicio, unidades, costo total de la tarifa básica, costo total de los recargos causados, duración, distancia y valor total a pagar; al enviar estos datos a Twitter no fue posible, ya que ésta red social restringe el número de caracteres por publicación a 140. De tal manera que se publicaron los datos más relevantes del reporte: placa del taxi, empresa, unidades de diferencia, motivo de reporte y comentarios. Al final de éste Sprint se corrigieron y mejoraron aspectos de la aplicación gráficos, permitiendo ser desplegaba en diferentes tamaños de pantalla.

3.9 TECNOLOGÍAS UTILIZADAS EN EL DESARROLLO DEL PROYECTO

Una vez se realizó el análisis de requerimientos, diseño del sistema y modelo de la base de datos, se inició la fase de implementación. En ésta sección se hace un breve resumen de los principales recursos tecnológicos que facilitaron y agilizaron la etapa de desarrollo, tales como librerías y frameworks.

3.9.1 TECNOLOGÍAS UTILIZADAS

Como se mencionó en apartados anteriores se escogió Android versión 4.4 Kit kat como sistema operativo y Eclipse Luna Service Release 2 versión 4.4.2 como IDE. Para el desarrollo y pruebas de la aplicación se utilizó: un portátil DELL procesador intel core i5, una Tablet Samsung Galaxy Tab 4, Android 4.4.2 y un celular Huawei Y511 Android 4.4.

Esta aplicación estará disponible para dispositivos móviles con sistema operativo Android 4.0, hasta la última versión disponible 5.0.1.

70

3.9.1.1 CAPA DE PRESENTACIÓN

Para desarrollar la capa de presentación se utilizaron las siguientes tecnologías:

Internet inalámbrico

Dado que la API de Android soporta la tecnología 4.4 (Ver sección 2. Marco tecnológico) para localizar dispositivos móviles, fue necesario que el usuario tuviera acceso a internet, una vez que éste se conectó, la API de Android identificó la posición del móvil y con base en ésta localización mostró el mapa que se utilizaría durante el recorrido.

SDK Android y Java

Para la codificación de la aplicación se escogió el SDK de Android para eclipse y Java como lenguaje de programación. Como se ha mencionado en Sprints anteriores, el SDK proporciona un conjunto de herramientas que le permiten al desarrollador no solo acceder al sistema operativo de Android y manipular algunos componentes, sino que además incluye: documentación, un depurador y un emulador para correr aplicaciones móviles [32].

Justinmind versión 6.4

Para hacer un bosquejo de cómo quedarían las interfaces se utilizó la herramienta Justinmind versión 6.4. Ésta herramienta le permite al usuario no solo crear prototipos de la aplicación, sino que además el usuario podrá crear interfaces funcionales, es decir, se puede simular acciones que tendrá la aplicación. En caso de que el usuario lo desee, también ofrece plantillas para aplicaciones móviles y web [62].

Android Asset Studio

Esta herramienta permite crear componentes gráficos para aplicaciones móviles [32], como launcher icons, notification icons, generic icons (Ver figura 25), tab icons, menu icons y action bar [11].

Figura 25. Icono de la Aplicación.

Fuente: Elaboración propia, usando Android Asset Studio.

71

3.9.1.2 CAPA DE NEGOCIO

Para diseñar la solución del problema que se planteó, se utilizaron las herramientas Enterprise Architect Spark versión 11 y Bizagi Modeler versión 2.9.0.4. Estas dos herramientas se utilizaron en las etapas de análisis y diseño.

Bizagi Modeler

Herramienta que permite representar de manera gráfica todas las actividades y decisiones por las que pasa un proceso. Ésta herramienta ofrece una variedad de componentes visuales, que permiten identificar los diferentes conceptos que interviene en un diagrama, tales como: conectores, cajas, eventos, actividades, compuertas lógicas y artefactos. Una vez que el usuario a terminado de graficar el diagrama lo podrá exportar en un archivo en formato: PNG, JPG o PDF [56].

Enterprise Architect

Herramienta basada en UML (Unified Modeling Language) que permite modelar y diseñar el ciclo de vida de un proceso. Con esta herramienta es posible: administrar la complejidad de grandes procesos, generar código a partir de ingeniería inversa, controlar las versiones de un documento, generar documentación, etc. Además de soportar una gran variedad de lenguajes como: PHP, Java, C#, C++, etc. Es compatible con los siguientes motores de bases de datos: MySql, Oracle, PostgreSQL, MS Access, entre otros [63].

3.9.1.3 CAPA DE PERSISTENCIA

BackEnd Parse

Para la configuración, administración y gestión de la base de datos se utilizó el BackEnd Parse [42], ya que proporcionó una variedad de herramientas que permitieron desarrollar el proyecto. Éste BackEnd funcionó como un servidor web, principalmente se utilizó para: almacenamiento de las tarifas y datos de los usuarios que se registraron en la aplicación del administrador.

SQLite

Ésta base de datos relacional, se usó para almacenar en el dispositivo móvil las tarifas vigentes. Permitió la sincronización con el BackEnd [64], para que la información que se brinda al usuario, esté actualizada.

72

3.9.2 LIBRERÍAS

3.9.2.1 CAPA DE PRESENTACIÓN

Google Maps

Una de las librerías de mayor utilidad dentro del proyecto fue Google Maps. Permitió manipular y utilizar los mapas que ofrece el navegador web Google, como se muestra en la siguiente figura. A continuación se nombran algunas funcionalidades que ofrece esta herramienta: manipulación de mapas vectoriales, integración con los servicios de Google Play, creación de mapas, geolocalización, búsquedas localizadas, creación de itinerarios de viajes, entre otras [65].

Figura 26. Aplicación de la librería GoogleMaps. Fuente: Elaboración propia.

3.9.2.2 CAPA DE NEGOCIO

Librería de Twitter

Para que la aplicación pudiera tener conexión con Twitter, fue necesario descargar la librería Twitter4j [66] la cual permitió que se compartiera contenido en Twitter automáticamente desde la aplicación. Esto fue posible gracias a la API de Twitter (Application Programming Interface) que ofrece un conjunto de métodos y funciones que permiten la interacción de una aplicación móvil con la red social. Para incluir estas funcionalidades en la aplicación fue necesario:

73

1. Crear una cuenta en Twitter.

2. Crear una aplicación desde Twitter y obtener las claves que permitirán la comunicación entre estas dos tecnologías. Para el proyecto se descargaron las claves: CONSUMER_KEY, CONSUMER_SECRET, REQUEST_URL y ACCESS_URL, AUTHORIZE_URL [66].

3. Descargar la librería Twitter4j de la página http://twitter4j.org/.

4. Una vez se descargaron las librerías, la aplicación ya estaba lista para llamar y utilizar las funciones que ofrecía la librería Twitter4.

Librería Android Support v7 appcompat

Al existir una gran variedad de versiones del sistema operativo Android, con el tiempo surgió el problema de que las versiones antiguas no eran compatibles con las nuevas funcionalidades que ofrecía éste sistema operativo [67]. Como respuesta a este problema se crearon las bibliotecas de compatibilidad, Librería Android Support, las cuales permitían incorporar nuevas funcionalidades en diferentes versiones de Android. En la actualidad existen cinco versiones: v4, v7, v8, v13 y v17 [67]. Para el desarrollo de éste proyecto se escogió la versión siete, ya que soporta una amplia gama de versiones de Android. Para usar estas librerías se tuvo que configurar el entorno de desarrollo. Los pasos que se siguieron se pueden consultar en el anexo B:

3.9.2.3 CAPA DE PERSISTENCIA

Librería Parse

Permite la comunicación y conexión de una aplicación Android con un servidor en Parse [42]. Para establecer dicha conexión fue necesario:

1. Registrarse en Parse, ingresando nombre y correo electrónico.

2. Crear una nueva aplicación en la que serían almacenados los datos.

3. Ir a la aplicación y capturar las claves que permitirán la integración de la aplicación con el servidor. Se tomaron las claves Client Key y Application ID.

4. Finalmente se importó la librería Parse-1.9.1.jar y se pusieron las claves en el código Java.

Una vez se realizaron estos pasos, la aplicación ya tenía acceso a los datos que estaban almacenados en el servidor. De esta manera no solo fue posible consultar los datos sino que también se pudieron enviar, como es el caso de las historias de usuario: Cargar tarifa y Almacenar información del servicio, respectivamente.

http://twitter4j.org/

74

3.10 PRUEBAS

ACTIVIDADES Se realizaron los casos de prueba de cada una de las historias de usuario.

ENTREGABLES Cinco plantillas que describen cada caso de prueba.

DURACIÓN 2 Semanas. Tabla 15.Actividades realizadas en pruebas. Fuente: Elaboración Propia.

Una vez se terminó el desarrollo de la aplicación, se realizaron un conjunto de pruebas en las que se verificó que el sistema cumpliera con los requerimientos funcionales y no funcionales especificados. Somerville [54] define dos tipos de pruebas: pruebas de componentes y pruebas del sistema. En las pruebas de componentes se evalúa cada módulo o cada HU de forma individual, mientras que en las pruebas del sistema se evalúa el sistema como un todo, es decir todas las HU se comprueban a la vez [52]. Somerville también establece que las pruebas cumplen dos objetivos:

1. Comprobar al equipo de trabajo, incluido el cliente, que se cumplen y satisfacen los objetivos propuestos.

2. Identificar comportamientos no deseables del sistema, tales como fallas o incumplimiento en las HU.

A continuación se presentan los formularios de pruebas de las 5 HU más importantes de la aplicación; las demás se pueden consultar en el anexo C.

Identificador

CP_001

Proyecto PROTOTIPO DE SOFTWARE MÓVIL PARA IMPLEMENTAR UN TAXIMETRO ENFOCADO AL CONTROL DEL SERVICIO

Subsistema o Función

Verificar y solicitar la activación del GPS.

Preparado Por Angélica María Babativa Fecha 15 de Julio de 2015

Probado Por Paula Daniela Briceño Fecha 17 de Julio de 2015

Nombre Caso Prueba 001

Objetivo Verificar que al iniciar la aplicación el sistema solicite la activación del GPS.

Precondiciones de la El usuario tiene acceso a Internet.

75

prueba El usuario abre la aplicación pero no tiene el GPS activo.

Pasos de ejecución Se realizaron los siguientes pasos: 1. Se inhabilitaron las fuentes de ubicación (GPS) del dispositivo. 2. Se abrió la aplicación.

Resultados esperados

Al abrir la aplicación se despliega un mensaje: “El sistema GPS está inactivo, ¿Desea activarlo?”

Resultados Obtenidos

Al abrir la aplicación se despliega un mensaje en el que se solicita al usuario activar el GPS.

Estado de la prueba Pasó: Si

Fecha: 17 de Julio de 2015

Falló: Fecha:

Comentarios La aplicación se demora en abrir de 1 a 3 segundos.

Tabla 16. Formato de caso de prueba: Activar GPS.

Identificador

CP_002



Iniciar medición.




Objetivo Verificar que se estén incrementando las unidades según el factor que esté sucediendo más rápido: tiempo o distancia.

Precondiciones de la prueba

El usuario tiene acceso a Internet. El usuario inicia el recorrido.

Pasos de ejecución 1. Se abrió la aplicación. 2. Se empezó el recorrido, con el botón Iniciar. 3. El sistema deshabilitó el botón “Siguiente”. 4. Se recorrieron diferentes zonas de Bogotá para evaluar el comportamiento del contador de unidades.


El sistema incrementa el contador de unidades según el factor que se esté dando más rápido: distancia o tiempo. Además se actualiza el valor de la carrera conforme van a

76

aumentando las unidades.


El contador de unidades aumenta según el factor que suceda más rápido y actualiza el valor de la carrera según las unidades que va marcando.



Falló: Fecha

Comentarios El desfase entre las unidades que marca el taxi y el que marca la aplicación oscila de 0 a 2 unidades. Esto se puede presentar por la inexactitud del GPS ya que en el momento que se realizaron las pruebas se recorrieron diferentes lugares de Bogotá donde la señal de GPS era baja.

Tabla 17. Formato de caso de prueba: Iniciar medición.

Identificador

CP_003



Contabilizar y seleccionar recargos




Objetivo Verificar que se despliegue un menú para que el usuario seleccione los recargos a los que aplica la carrera.


El usuario tiene acceso a Internet. La tabla tarifa existe y es vigente.

Pasos de ejecución 1. Se detuvo el recorrido con el botón detener. 2. El sistema habilitó el botón “Siguiente” y deshabilitó el botón “Iniciar”. 3. Se dio click en el botón siguiente. 4. Se seleccionó más de un recargo.


Al detener el recorrido se despliega un menú en el que el usuario puede seleccionar los recargos a los que aplica la carrera. Una vez el usuario termina de seleccionarlos se

77

actualiza el valor total de recargos.


Al detener el recorrido se despliega un menú en el que se pueden seleccionar los recargos, a medida que estos van siendo seleccionados el total de recargos se va actualizando.



Falló: Fecha

Comentarios La interfaz es amigable e intuitiva.

Es posible seleccionar y deseleccionar los recargos.

Tabla 18. Formato de caso de prueba: Contabilizar y seleccionar recargos.

Identificador

CP_004



Notificar y actualizar modelo de tarifa.




Objetivo Verificar que al actualizar la tarifa desde la aplicación web se actualice tanto el BackEnd, Parse, como la base de datos local, SQLite.


El usuario tiene acceso a Internet. El administrador tiene el archivo en formato CSV con los datos de la tarifa que desea actualizar. El administrador está registrado en la aplicación y en Parse.

Pasos de ejecución 1. Se ingresó a la aplicación web, con usuario y contraseña. 2. Se seleccionó el archivo que contenía los datos de la tarifa que se quería actualizar. 3. Se consultó la base de datos en Parse. 4. Se verificó que al abrir la aplicación móvil TwTaxi cambiaran los valores de la tarifa.


La aplicación actualiza los datos que se encuentran en Parse y los guarda en la base de datos local SQLite. El sistema

78

informa que se ha cambiado el modelo de tarifa.


Al abrir la aplicación el sistema notifica que se han cambiado las tarifas y actualiza las existentes en SQLite.



Falló: Fecha

Comentarios El tiempo que tarda el sistema en actualizar las tarifas es del orden de milisegundos.

Tabla 19. Formato de caso de prueba: Notificar y actualizar modelo de tarifa.

Identificador

CP_005



Notificar queja en Twitter.




Objetivo Verificar que cuando el usuario quiera reportar una situación anómala, pueda difundirlo por medio de la red social Twitter.


El usuario tiene acceso a Internet. El usuario tiene cuenta en Twitter. El usuario autoriza para que TwTaxi tenga acceso a información de su cuenta en Twitter.

Pasos de ejecución 1. Al finalizar la carrera se dio click en el botón “Reportar”. 2. Se dio autorización a Twiiter para que usará la aplicación. 3. Se ingresaron los datos de la carrera: placas del taxi, unidades de diferencia, motivo de reporte y comentarios. 4. Se seleccionó la empresa del taxi. 5. Se dio click en “Publicar”.


La aplicación publica el reporte en la página @denunciealtaxista y @TwTaxii con los datos que ingresa el usuario.

79


Al hacer el reporte, ingresando los datos de la carrera, queda registrada la denuncia en Twitter y se despliega un mensaje “Tu denuncia ha sido publicada correctamente”.



Falló: Fecha

Comentarios El tiempo que tarda el sistema en publicar el reporte es del orden de milisegundos.

Tabla 20. Formato de caso de prueba: Notificar y actualizar modelo de tarifa.

3.11 VALIDACIÓN DE LOS RESULTADOS

Para la verificación y validación de la aplicación se siguieron las pautas que propone Montgomery [70], las cuales proporcionan una adecuada planificación en el diseño de experimentos. Las etapas que se mencionan a continuación se ejecutaron de forma secuencial.

3.11.1 IDENTIFICACIÓN Y EXPOSICIÓN DEL PROBLEMA

El GPS como instrumento de medida, en algunas ocasiones, suministra datos imprecisos e inexactos, en la mayoría de los casos estas situaciones se presentan por interrupciones en el envío y recepción de señales entre el GPS del móvil y el satélite encargado de recibir las coordenadas del dispositivo móvil [23]. Luego de analizar el comportamiento de los datos y el tamaño de la muestra, se determinó que la distribución Normal, sería la técnica adecuada para estimar el grado de fiabilidad operacional del sistema (Ver sección 3.11.4).

3.11.2 ELECCIÓN DE LOS FACTORES, LOS NIVELES Y LOS RANGOS

A continuación se identificaron los factores que pudieron alterar e influir en el desempeño del sistema, los cuales se clasificaron en:

3.11.2.1 FACTORES POTENCIALES DEL DISEÑO: Factores que se pueden variar durante el experimento a petición del experimentador. Los factores de diseño se pueden clasificar en factores constantes y variables [68].

- Factor constante: Factor que se mantuvo fijo durante el proyecto. Para realizar las medidas se tomó de referencia siempre el mismo taxímetro como instrumento de referencia y como instrumento de medida siempre se tomó el mismo teléfono celular.

- Factor variable: Los días y zonas fueron los factores que se permitieron variar durante el experimento. En el mes de Julio se tomaron los datos los días comprendidos entre el 13 y el 24 de Julio, en el mes de Agosto se tomaron los datos entre el 11 y 19 de Agosto.

80

3.11.2.2 FACTORES PERTURBADORES: Estos factores se clasifican en: controlables, no controlables o de ruido. Los factores controlables pueden ser ajustados por el experimentador, los factores de ruido son los que varían de manera natural y no controlada, cuando en un experimento se presenta éste factor de varianza, se ajustan y adecuan los factores controlables, de tal manera que se reduzca la variabilidad producida por factores de ruido [68]. Durante el desarrollo del experimento se encontró que las condiciones atmosféricas se comportaban como factores de ruido, ya que la aplicación era sensible cuando se variaba éste factor.

Además de la elección de los factores, se fijaron los rangos en los que se variaría cada factor. Uno de los rangos que es de común interés es el espacial, para efectos del experimento se escogió como región de interés la ciudad de Bogotá.

3.11.3 SELECCIÓN DE LA VARIABLE DE RESPUESTA

Variable establecida por el experimentador: El experimentador selecciona aquella variable que proporciona información significativa y relevante para el caso de estudio [68]. Como variable de respuesta se escogió la desviación estándar, pues a partir de ésta medida se definió el tamaño de la muestra. La exactitud y la precisión fueron otras de las variables de interés en el experimento, pues al no ser exacto el instrumento de medición fue necesario saber si la diferencia entre las unidades que marcaba el taxi y las unidades que marcaba la aplicación eran considerablemente diferentes.

3.11.4 ELECCIÓN DE LA TÉCNICA ESTADÍSTICA

DISTRIBUCIÓN NORMAL: Ésta distribución representada por una campana, modela diversos fenómenos que suceden en la naturaleza, en la investigación y en la industria. Una de las aplicaciones que más se asemejan al comportamiento de esta distribución, es el tratamiento de errores en la toma de medidas, es por ello que se escogió esta técnica para validar el prototipo [68]. En este proyecto la campana refleja el área de confianza de la medida tomada por el GPS.

3.11.5 REALIZACIÓN DEL EXPERIMENTO

Las pruebas se realizaron en los meses de Julio y Agosto, por las estudiantes Angélica Babativa y Paula Briceño. Los datos se tomaron con un celular Huawei Y511 Android 4.4 con capacidad de 4GB de Internet.

Para tomar los datos se siguieron los siguientes pasos:

1. Se verificó que el dispositivo móvil tuviera conexión a Internet. 2. Se abrió la aplicación segundos antes de subir al taxi, para que el sistema

ubicara el dispositivo y cargara el mapa. 3. Luego de estar en el taxi, se iniciaron al mismo tiempo: el instrumento de

referencia (Taxímetro) y el instrumento experimental (Aplicación). 4. Al llegar al lugar de destino se detuvieron al mismo tiempo: el taxímetro y la

aplicación.

81

5. Una vez se finalizó el recorrido se registraron las unidades que marcaba la aplicación y las que marcaba el taxímetro.

Las localidades, zonas y franjas horarias en las que se realizaron las pruebas fueron las siguientes:

DÍA LOCALIDAD FRANJA HORARIA

Lunes 13 de Julio Suba 8:00 a.m – 10:00 a.m

Lunes 13 de Julio Barrios Unidos 1:00 p.m – 2:00 p.m

Martes 14 de Julio Mártires 2:00 p.m – 4:00 p.m

Martes 14 de Julio Puente Aranda 7:00 p.m – 8:00 p.m

Miércoles 15 de Julio Kennedy 2:00 p.m – 4:00 p.m

Viernes 17 de Julio Engativá 4:00 p.m – 6:00 p.m

Domingo 19 de Julio Engativá 12:00 m – 2:00 p.m

Lunes 20 de Julio Suba 2:00 p.m – 4:00 p.m

Martes 21 de Julio Barrios Unidos 7:00 p.m – 9:00 p.m

Jueves 23 de Julio Suba 11:00 a.m – 01:00 p.m

Viernes 24 de Julio Engativá 7:00 p.m – 9:00 p.m

Martes 11 de Agosto Barrios Unidos 8:00 a.m – 10:00 a.m

Martes 11 de Agosto Teusaquillo 2:00 p.m – 4:00 p.m

Miércoles 12 de Agosto Engativá 11:00 a.m – 02:00 p.m

Jueves 13 de Agosto Fontibón 10:00 a.m – 12:00 m

Jueves 13 de Agosto Engativá 2:00 p.m – 4:30 p.m

Viernes 14 de Agosto Chapinero 7:00 a.m – 9:00 a.m

Sábado 15 de Agosto Engativá 10:00 a.m – 12:00 m

Lunes 17 de Agosto La Candelaria 8:00 a.m – 10:00 a.m

Martes 18 de Agosto Barrios Unidos 7:00 a.m – 9:00 a.m

Miércoles 19 de Agosto Engativá 2:00 p.m – 4:00 p.m Tabla 21. Días, zonas y franjas en las que se tomaron los datos.

82

MUESTRA: Para realizar el estudio estadístico, se determinó un número de pruebas finitas aleatorias, las cuales permitieron recolectar información relevante y significativa para el estudio en curso.

POBLACIÓN: conjunto de elementos que poseen características comunes [68]. La población que se escogió para realizar éste estudio fue la ciudadanía en general, es decir toda aquella persona que hiciera uso del servicio de transporte público individual de pasajeros en vehículos clase taxi.

TAMAÑO DE LA MUESTRA: Resulta difícil estudiar toda la población por cuestiones de tiempo y de recursos, es por ello que se estudió una pequeña parte de la población bogotana, denominada muestra. Para la selección del tamaño de la muestra se utilizaron las curvas de operación característica (Ver anexo D figura 38). Se escogió ésta técnica dado que no es necesario conocer con anticipación datos que se van a saber, solo al final del experimento.

Luego de realizar 35 muestras se encontró que las medidas tomadas por la aplicación vs. las tomadas por el taxímetro eran diferentes en 2 unidades promedio. También se encontró que la desviación estándar era aproximadamente 1,5. Al remplazar estos

valores en la ecuación 6, se obtuvo que el parámetro tenía un valor de:

Entonces al tener , y luego de establecer una seguridad en la medición del 95%, se obtiene que =50 (por la curva de operación). Ahora para saber el tamaño de la muestra, se remplaza los valores en la siguiente ecuación:

Obteniendo así un tamaño de la muestra igual a 26. Éste tamaño se considera aceptable, desde el punto de vista económico y logístico, sin embargo para que las unidades sean lo más precisas y exactas posibles se tomara un tamaño de muestra igual a 50.

GRADOS DE LIBERTAD

83

MEDIA: Valor que indica el promedio en un conjunto de datos. Matemáticamente se define como la suma de los datos observados dividido entre el tamaño de la muestra [68].

El experimento se realizó 50 veces, cada una de las medidas se tomó en tiempos y lugares diferentes. En cada una de las muestras que se tomó, se calculó la diferencia entre: las unidades que marcaba la aplicación y las que marcaba el taxímetro (Ver tabla 22). Estas diferencias se sumaron y se dividieron entre el tamaño de la muestra. Remplazando los valores en la ecuación 9 se obtuvo que:

DESVIACIÓN ESTÁNDAR: Medida que indica la dispersión de una muestra, ésta medida se toma con respecto al valor promedio [68]. Es decir mide que tan dispersos están unos valores respecto al promedio.

Remplazando los datos que se obtuvieron en la tabla 22 en la ecuación 10, se obtuvo una desviación estándar de 1,36262052.

La siguiente tabla muestra los resultados que se obtuvieron al realizar las pruebas de validación: Medida TwTaxi: Unidades dadas por la aplicación.

84

Medida Taxi: Unidades dadas por el taxímetro. Desviación Xi: Diferencia entre las medidas de TwTaxi y el taxímetro del vehículo.

Medida TwTaxi Medida Taxi Desviación Xi Desviación Media Xi- Desviación al

cuadrado (Xi- )^2

33 33 0 2,02 4,0804

37 40 -3 -0,98 0,9604

84 87 -3 -0,98 0,9604

74 74 0 2,02 4,0804

43 43 0 2,02 4,0804

97 100 -3 -0,98 0,9604

46 50 -4 -1,98 3,9204

111 111 0 2,02 4,0804

93 96 -3 -0,98 0,9604

85 87 -2 0,02 0,0004

84 84 0 2,02 4,0804

43 46 -3 -0,98 0,9604

68 71 -3 -0,98 0,9604

64 66 -2 0,02 0,0004

83 83 0 2,02 4,0804

84 86 -2 0,02 0,0004

73 76 -3 -0,98 0,9604

85 88 -3 -0,98 0,9604

67 67 0 2,02 4,0804

74 76 -2 0,02 0,0004

85 87 -2 0,02 0,0004

74 74 0 2,02 4,0804

67 68 -1 1,02 1,0404

47 51 -4 -1,98 3,9204

114 115 -1 1,02 1,0404

120 123 -3 -0,98 0,9604

67 71 -4 -1,98 3,9204

89 93 -4 -1,98 3,9204

74 77 -3 -0,98 0,9604

98 102 -4 -1,98 3,9204

41 41 0 2,02 4,0804

66 67 -1 1,02 1,0404

84 87 -3 -0,98 0,9604

83 87 -4 -1,98 3,9204

67 68 -1 1,02 1,0404

96 99 -3 -0,98 0,9604

85

100 103 -3 -0,98 0,9604

77 79 -2 0,02 0,0004

95 95 0 2,02 4,0804

60 62 -2 0,02 0,0004

55 58 -3 -0,98 0,9604

92 93 -1 1,02 1,0404

61 64 -3 -0,98 0,9604

38 38 -1 1,02 1,0404

52 54 -2 0,02 0,0004

40 43 -3 -0,98 0,9604

55 57 -2 0,02 0,0004

79 82 -3 -0,98 0,9604

33 35 -2 0,02 0,0004

72 72 0 2,02 4,0804

72,1800000 74,1800000 -2,0200000

90,9800000 Tabla 12. Toma de datos. Fuente: Elaboración propia.

VALOR MÁXIMO: Del tamaño muestral se obtiene el valor más alto . La desviación máxima de unidades en el experimento fue de 4 unidades.

VALOR MÍNIMO: Del tamaño muestral se obtiene el valor más cercano a cero . La desviación mínima de unidades en el experimento fue de 0 unidades.

RANGO: Diferencia entre el valor máximo y el valor mínimo.

INTERVALO DE CONFIANZA: El intervalo de confianza de un instrumento ésta determinado por: la media, la desviación estándar y por una constante de cobertura llamado T-Student. Ésta constante se saca a partir de: el nivel de confianza que se quiere en el experimento, por lo general del 95%, y el número de grados de libertad. Dado que el tamaño de la muestra es 50, el grado de libertad es de 49 y el nivel de confianza es del 95%, Remplazando estos valores en la tabla 30, ver anexo D, se obtuvo una constante de cobertura igual a: 1,676.

Remplazando: la constante T-Student, la media, la desviación estándar y el tamaño de la muestra en la ecuación 12 se tiene que:

86

El intervalo de confianza es de -2,342971305 a -1,697028695. Es decir, para una seguridad del 95%, se obtuvo que la aplicación marca entre 2,34 a 1,69 unidades promedio menos que el taxímetro real.

TEST F: Este test indica si la desviación de dos muestras, independientes, son significativamente diferentes o si no lo son. En este caso evaluaremos si es significativa la diferencia de la desviación estándar de la aplicación contra la del taxímetro.

Donde:

= Desviación entre los datos tomados.

= Valor que se obtiene a partir de los grados de libertad de las dos medidas.

Tabulando los grados de libertad de las dos medidas, ambas de 49, se obtuvo que

=1.63 aproximadamente.

Remplazando en la ecuación 13 se obtuvo que:

Si la diferencia entre las medidas no es significativa.

Cómo <1.63, la diferencia entre las medidas no es significativa.

3.11.5.1 EXACTITUD

Diferencia entre el valor verdadero y el valor medido. Algunas veces el valor verdadero no se conoce con certeza[68]. Matemáticamente se expresa como:

DESVIACIÓN:

87

DESVIACIÓN RELATIVA:

La desviación relativa indica la inexactitud del instrumento de medida, ésta inexactitud debe ser tan pequeña como sea posible, lo más alejada del 100% [68].

Como se puede afirmar que el grado de exactitud del instrumento es alto.

RECUPERACIÓN:

Lo ideal es que un instrumento de medición tenga una recuperación del 100% [68],

como se acerca al 100%, se puede afirmar que el instrumento se acerca al

valor real.

TOB:

88

Como Tob es mucho menor que T-Student tabulado, , la exactitud requerida para una seguridad del 95% es aceptable.

3.11.5.2 PRECISIÓN

Grado de repetitividad de una medición alrededor de un valor. Esta medida evalúa que tanto varían los datos muéstrales con respecto a su valor promedio [68]. Es decir un instrumento es preciso cuando al hacer una muestra todos los valores son similares entre sí. Matemáticamente se expresa como:

COEFICIENTE DE VARIANZA:

Los valores no son dispersos ya que 1.73%es significativamente menor que 100%.

ERROR ESTÁNDAR:

Se encontró que el error estándar es de 2* , es decir para 50 muestras se presenta un error del 0,385407285.

89

3.11.6 ANÁLISIS ESTADÍSTICO DE LOS DATOS

Al realizar el experimento se observó que el comportamiento de los datos se asemejaba a la distribución Normal. Este comportamiento se ve reflejado en la figura 27, el eje de las abscisas ilustra el número de muestras que fueron tomadas y el eje de las ordenadas muestra la desviación máxima que se encontró, es decir el desfase máximo entre las unidades que marcó la aplicación vs. las que marcó el taxímetro, que fue de 4 unidades. La campana refleja el área de confianza de la medida tomada por el GPS.

Figura 27. Distribución Normal del Error. Fuente: Elaboración propia.

Para evaluar la fiabilidad de la aplicación, se comparó las unidades que marcaba el taxi vs. las que había marcado TwTaxi, obteniendo como resultado la gráfica que se muestra a continuación.

-4,5

-4

-3,5

-3

-2,5

-2

-1,5

-1

-0,5

0

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

De

svia

ció

n M

áxim

a

Número de Muestras

Curva Nomal del Error

Desviación

Polinómica (Desviación)

90

Figura 28. Medidas TwTaxi Vs. Medidas Taxímetro. Fuente: Elaboración propia.

3.11.7 CONCLUSIONES DEL ANÁLISIS ESTADÍSTICO

Con base en los resultados de este experimento se concluye que:

En promedio la aplicación tiene un desfase de dos unidades, con un margen de error del 0,385407285 y una confianza del 95%.

El desfase se presentó por diferentes motivos: condiciones atmosféricas desfavorables, presencia de edificios muy altos que obstaculizaban la señal del GPS y capacidad de la tarjeta de red del dispositivo móvil.

La precisión de la aplicación estuvo determinada por el ancho de banda de internet, pues el realizar las pruebas se encontró que entre más capacidad tenía el dispositivo más precisa era la aplicación, con un ancho de banda de 3GB las medidas no eran tan precisas cómo cuando se utilizaba 4GB. Es por ello que la precisión y exactitud dependen considerablemente de los factores de ruido mencionados anteriormente.

0

20

40

60

80

100

120

140

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

Un

idad

es m

arca

das

Número de prueba

Medida TwTaxi vs. Medida Taximetro

Medida TwTaxi

Medida Taxi

91

4. RESULTADOS OBTENIDOS

4.1 RESULTADOS DE LA METODOLOGÍA

La tabla 23 muestra un resumen del desarrollo que tuvo el proyecto, para cada uno de los Sprints se describe las historias que se realizaron y el tiempo en el que se desarrollaron. El proyecto se planeó en 176 días y se realizó en 174 días.

Sprint Historias Planificadas Tiempo

Estimado Real

Sprint 0 Documentación previa del desarrollo móvil. Desarrollo de un prototipo inicial de bajo nivel.

20 días 17 días

Sprint 1 Construcción de las historias de usuario. Prototipo de las historias de usuario. Modelo de requerimientos. Modelo de casos de uso.

20 días 20 días

Sprint 2 Arquitectura de la aplicación. Diagrama de clases. Modelo de base de datos. Verificar y solicitar la activación del GPS. Mostrar la ubicación del usuario en el mapa. Iniciar aplicación.

31 días 35 días

Sprint 3 Cargar modelo de tarifa. Iniciar medición.

30 días 30 días

Sprint 4 Contabilizar y seleccionar recargos. Calcular valor de la carrera.

20 días 15 días

Sprint 5 Almacenar información del servicio. Generar informe con los datos del servicio.

25 días 23 días

Sprint 6 Notificar y actualizar modelo de la tarifa. Notificar queja en Twitter. Manual del usuario de la aplicación móvil TwTaxi. Manual del usuario de la aplicación web Administrador TwTaxi.

30 días 34 días

176 174

Tabla 23. Cronograma de las actividades desarrolladas. Fuente: Elaboración propia.

Como se puede observar en la tabla 23, el tiempo de desarrollo del proyecto se ajustó

según lo planeado, gracias a las reuniones periódicas que se hicieron con los Scrum

Master. Sin embargo en los Sprints 2 y 3 se presentó un desfase de 4 días, ya que el

grupo de trabajo se enfrentó a una curva de aprendizaje, pues no tenía conocimiento ni

experiencia en desarrollo para Android. En términos generales el proyecto se realizó en

menos tiempo del que se esperaba esto se debe a que los Scrum Team 1 y 2 tuvieron

una dedicación de tiempo completo, 6 horas de dedicación 5 días a la semana.

92

4.2 RESULTADOS DEL PROTOTIPO FUNCIONAL

Como se mencionó en secciones anteriores se realizaron dos aplicaciones: una móvil que controla el cobro de la tarifa y otra web encargada de actualizar periódicamente el modelo de tarifa. A continuación se muestran algunas de las historias de usuario que se realizaron, las demás se pueden consultar en el manual del usuario.

Una diferencia significativa obtenida del prototipo elaborado, a diferencia de las otras aplicaciones existentes en el mercado fue: permitir que TwTaxi, siga ejecutándose de manera correcta estando inclusive en segundo plano, evitando de ésta manera, bloqueos en el dispositivo móvil.

La figura 29 ilustra la historia de usuario: contabilizar y selecciona recargos. Una vez que el usuario finaliza el recorrido deberá seleccionar los recargos que se causaron durante la carrera.

Figura 29. Historia de usuario: Contabilizar y seleccionar recargos.


93

Luego de que el usuario selecciona los recargos, la aplicación despliega una pantalla

con un resumen del servicio, en la parte inferior se le indica al pasajero el total a pagar.

Figura 30. Historia de usuario: Generar informe con los datos del servicio.


En caso de que el pasajero esté inconforme con el cobro de la tarifa, puede reportarlo en la red social Twitter. Para ello deberá ingresar: las placas del taxi, el nombre de la empresa, motivo del reporte y comentario (se recomienda no excederse de 15 caracteres).

94

Figura 31. Historia de usuario: Notificar queja en Twitter. Fuente: Elaboración propia.

En caso de que el usuario quiera ver el modelo de tarifa con el que está funcionando TwTaxi, puede dirigirse a la parte superior izquierda en el icono “Tarifas”, en ésta tabla podrá encontrar: unidad y valor.

Figura 32 Tabla recargos. Fuente: Elaboración propia.

95

Si el usuario desea saber más información de las empresas de trasporte público taxi, podrá consultar en la parte superior izquierda de la aplicación donde se encuentran 3 iconos: tarifas, recargo y empresas, al dar click en esta última podrá obtener el nombre y teléfono de la empresa que desee consultar.

Figura 33. Tabla empresa. Fuente: Elaboración propia.

96

CONCLUSIONES

El uso de la metodología Scrum permitió que el desarrollo del proyecto no se viera afectado ante los cambios que se presentaron en las historias de usuario, ya que algunas de ellas se modificaron, otras se crearon, incluso hubo algunas que se eliminaron. Esta metodología además facilitó el desarrollo iterativo e incremental, pues gracias a las reuniones periódicas que se realizaron con el Scrum Team se mejoró la calidad del proyecto y aumento la productividad de trabajo, ya que en cada reunión se entregaban módulos concretos de la aplicación.

Dados los diferentes avances tecnológicos, las personas y las empresas dependen cada día más de las tecnologías de información. El número de usuarios de teléfonos inteligentes "Smartphones" incrementa día a día, es por esto que el desarrollo de aplicaciones móviles utilizando software libre, permiten poner la tecnología al servicio de la comunidad. Se observó que la realización de la aplicación TwTaxi, sea un aporte valioso para los usuarios de Taxi por dos razones: transmita confianza y seguridad a la hora de utilizar el taxi como medio de transporte público y muestre los beneficios que traen las redes sociales al usarlas como mecanismo de difusión de información.

Las pruebas de verificación y validación comprobaron que la aplicación era fiable un 95% en condiciones normales, pero con la presencia de factores de ruido (condiciones atmosféricas desfavorables, presencia de edificios muy altos y capacidad limitada de la tarjeta de red del dispositivo móvil) se encontró que la señal de GPS era baja reduciendo así la exactitud y precisión de la aplicación.

La implementación del algoritmo afecta el resultado porque inicialmente se implementaron las formulas (Ver sección 2.1.1.3) usando hilos, los cuales se actualizaban en el orden de milisegundos, pero los resultados no eran exactos, finalmente se optó por actualizar los contadores con el tiempo mínimo de registro que ofrece el GPS, obteniendo resultados próximos a los reales.

Cabe resaltar que la aplicación TwTaxi, fue puesta a disposición del usuario mediante la tienda de aplicaciones Aptoide, en donde se observa que en tan poco tiempo desde la publicación de la aplicación (15 días), se ha descargado 22 veces con 10 comentarios positivos. La acogida de la aplicación se debe en gran medida a que no se maneja publicidad, no se presentan demoras al iniciar la aplicación, lo que sucedía en otras aplicaciones, y es la única aplicación que viene integrada con Twitter, permitiendo así que el usuario haga públicas sus inconformidades en caso de que se presenten situaciones anómalas.

97

TRABAJO FUTURO

Con el desarrollo de ésta tesis se ha logrado desarrollar un prototipo de software funcional que controla el cobro de servicio de Taxi. Sin embargo se puede extender para agregar nuevas funcionalidades al sistema como:

Aumentar la gama de sistemas operativos móviles en la que estará disponible: es decir que no solo esté disponible en Android sino que además se encuentre en: iOS, Windows Phone, Black Berry6, Symbian, Firefox O.S y Ubuntu Touch.

Buscar tecnologías alternativas al GPS: Las medidas que se obtuvieron con el GPS algunas veces presentaban variaciones con respecto a las del taxímetro real, dado que las condiciones atmosféricas no siempre fueron favorables, aunque esta diferencia no fue significativa, se pueden buscar otras tecnologías que se acerquen más al 100% en la precisión de las medidas.

Casos de estudio: A partir de la información recolectada en el servidor Parse se puede evaluar el grado de satisfacción y conformidad por parte del usuario con relación al servicio prestado.

98

BIBLIOGRAFÍA

[1] A. Cardenas, «Hay cerca de 675 taxis por cada mil habitantes,» Diario ADN, p. 1, 9 Agosto 2012.

[2] M. Reyes, «Noticias Radio Ver,» p. 1, 14 Agosto 2014.

[3] Decreto No. 237 de 2006, Bogotá D.C: Registro Distrital 3567 de Julio 4 de 2006. , 2006.

[4] L. F. B. Pachón, «La fiebre amarilla en Bogotá. Los taximetros fuera de control.,» Universidad del Rosario, Bogotá, 2013.

[5] M. León, Diccionario de Tecnología Ferroviaria, Madrid: Babel S.A, 2000.

[6] C. Malaver, «Denuncie a los taxistas de Bogotá que no lo quieran llevar,» EL TIEMPO, p. 1., 23 Diciembre 2011.

[7] El tiempo Zona, «Así surgió la idea de denunciar taxistas a través de redes sociales,» El tiempo., 26 Julio 2012.

[8] Play, Google, «Taximetro GPS,» [En línea]. Available: https://play.google.com/store/apps/details?id=com.seeit.android.taximeter. [Último acceso: 6 Agosto 2014].

[9] Creativería, «El taximetro más preciso,» [En línea]. Available: http://www.taxiandocr.com/. [Último acceso: 29 Agosto 2014].

[10] R. Silva, «Desarrollador Chileno presenta una aplicación para evitar cobros de más en taxis,» Emol. Ciencia y Tecnología, 23 Enero 2013.

[11] F. David Robledo, de Desarrollo de Aplicaciones para Android II, Ministerio de Educacion, Cultura y Deporte, 2012, pp. 11,12,13.

[12] Android, «Official Site Android,» [En línea]. Available: http://www.android.com/. [Último acceso: 29 Agosto 2014].

[13] J. C. Olmedillas, de Introducción a los sistemas de navegación por satélite , Barcelona, UOC , 2012.

[14] M. Arozamena, «¿Cómo armar un equipo de desarrollo de software?,» Nuevo León, Mexico, 2014.

99

[15] P. Letelier, M. C. Penadés y J. Sánchez, «Trabajo en equipo en proyectos de desarrollo de Software: Estrategía docente e infraestructura sofware,» Departamento de Sistemas Informáticos y Computación. Universidad Politecnica de Valencia, 2012.

[16] J. Mogollo Afanador y L. A. Esteban Villamizar, «Individual work development of software projects: A reality without method,» Revista Colombiana de Tecnologías Avanzadas, p. 17, 2010.

[17] Agencia Nacional de Transito , Reglamento de aplicación para el uso de dispositivos de control y seguridad para pasajeros de los vehículos que prestan el servicio de transporte en taxis convencionales y ejecutivos., Quito , 2011.

[18] «Norma Técnica Colombiana NTC 3679,» Instituto Colombiano de Normas Técnicas y Certificación , Bogotá, 2002.

[19] Secretaria Distrital de Movilidad, «DECRETO 400 DE 2014,» de Registro Distrital 5439 de 2014, Bogotá, 2014.

[20] J. Lastra, «Concejales denuncian que mitad de taxímetros están adulterados en Bogotá,» El Tiempo, 14 Enero 2009.

[21] Ministerio de Transporte, Decreto 172 de 2001, Bogotá, 2001.

[22] República, Congreso de la, «Secretaria Senado,» 16 Marzo 2010. [En línea]. Available: http://www.secretariasenado.gov.co/senado/basedoc/ley_1383_2010.html#3. [Último acceso: 4 Agosto 2014].

[23] T. Canal, Compositor, Así funciona: el GPS. [Grabación de sonido]. 2013.

[24] S. Arnalich y J. Urruela, «GPS y Google Earth en Cooperación: Cómo crear, compartir y colaborar con mapas en la red.,» arnalich , 2012, pp. 31,32.

[25] Jon, «El androide libre,» 11 Diciembre 2010. [En línea]. Available: http://www.elandroidelibre.com/2010/12/mide-la-velocidad-de-tu-coche-con-speedview-y-your-speed-lite.html. [Último acceso: 6 Agosto 2014].

[26] Google maps para móviles , «My Tracks,» [En línea]. Available: https://support.google.com/gmm/answer/2391538?hl=es. [Último acceso: 6 Agosto 2014].

[27] V. M. Cano, «Desarrollo de una aplicación de localización automática de vehículos (AVL) basada en el sistema de información geográfica ArcView,» Escuela Técnica

100

Superior de Ingeniería de Telecomunicación Universidad Politécnica de Cartagena , Cartagena, 2006.

[28] R. F. H. Rosado, «GPS aplicado a la ubicación de vehículos de transporte terrestre y sus alternativas de su gestión,» 2011. [En línea]. Available: http://www.oocities.org/es/ccarbo/yacambu/egmrt/asignaturas/epps/tf/nt.htm. [Último acceso: 6 Agosto 2014].

[29] D. Cuadrado, «Las pruebas del nuevo taxímetro con GPS obtienen buenas notas,» Autopista.es, 11 Diciembre 2000.

[30] L. A. Llamo, «Importancia de los dispositivos móviles y uso en las USS,» Universidad Señor de SIPAN, Chiclayo, 2013.

[31] El Espectador.com, «Dispositivos móviles son claves para las empresas,» El espectador, p. 1, 5 Marzo 2012.

[32] J. T. Gironés, de El gran libro de Android, 2da Edición, Barcelona, MARCOMBO, 20113, p. 55.

[33] J. Prieto , R. Ramírez, J. D. Morillo y M. Domingo, «Tecnología y desarrollo en dispositivos móviles,» Universitat Oberta de Catalunya, Barcelona, 2011.

[34] Y. E. Vasquéz, «All About Symbian,» 13 Diciembre 2012. [En línea]. Available: http://www.allaboutsymbian.com/. [Último acceso: 6 Septiembre 2014].

[35] K. Nahrstedt, «CS 423 – Operating Systems Design,» 2011.

[36] C. C. Valero, M. Roura Redondo y A. Sánchez Palacín, «Tendencias actuales en el uso de dispositivos móviles en educación.,» La educ@cion digital Magazine, nº 147, Junio 2012.

[37] MobileToday, «Comparativa: Windows Phone 7 vs iOS, Android, Symbian y Maemo,» [En línea]. Available: http://moviltoday.com/comparativa-windows-phone-7-vs-ios-android-symbian-y-maemo/. [Último acceso: 6 Septiembre 2014].

[38] Android.com. [En línea]. Available: http://developer.android.com/tools/sdk/eclipse-adt.html. [Último acceso: 31 Agosto 2014].

[39] S. A. Cardona, «Introducción a la programación en Java,» Quindio, Ediciones Elizcom, 2008, p. 22.

[40] S. GÁLVEZ ROJAS y L. ORTEGA DÍAZ, «JAVA 2 MICRO EDITION,» Málaga, 2003.

101

[41] U. P. d. Valencia, «Diploma de especialización en desarrollo de aplicaciones para Android,» [En línea]. Available: http://www.androidcurso.com/. [Último acceso: 5 Marzo 2015].

[42] K. Lane, «BackEnd As a Service,» [En línea]. Available: http://baas.apievangelist.com/. [Último acceso: 5 Marzo 2015].

[43] «The complete Mobile App Plataform Parse,» [En línea]. Available: https://parse.com/docs. [Último acceso: 03 Marzo 2015].

[44] P. Blanco, J. Camarero, A. Fumero, A. Werterski y P. Rodriguez, «Metodología de desarrollo ágil para sistemas Móviles,» Universidad Politecnica de Madrid, Mayo 2012.

[45] E. R. Gonzales, de Estadistica Aplicada, Bogotá, pp. 6,7,8.

[46] R. Walpole, R. Myers y S. Myers, de Probabilidad y estadística para ingenieros, Sexta ed., PEARSON EDUCACIÓN, 1999, pp. 445,447,448.

[47] K. Schwaber y J. Sutherland, «La Guia de Scrum,» Creative Commons, 2013.

[48] F. Toro, «Administración de Proyectos de informática,» Primera ed., Bogotá, ECOE Ediciones, 2013, pp. 218,219.

[49] J. Palacio, «Gestión de proyectos Scrum Manager,» Version 2.5, Abril 2014.

[50] F. T. López, Administración de proyectos de informática, Bogotá: ECOE EDICIONES, 2013, pp. 218-222.

[51] K. V. Suaza, «Definición de equivalencias entre historias de usuario y especificaciones en UN-LENCEP para el desarrollo ágil de software.,» Universidad Nacional de Colombia. , Medellín, 2013.

[52] I. Sommerville., INGENIERÍA DE SOFTWARE, Madrid: PEARSON EDUCACIÓN, 2005.

[53] J. T. Cifuentes, «Prácticas ágiles para el desarrollo de software en semilleros de investigación.,» Universidad Pontifica Bolivariana, Medellín, 2013.

[54] M. Silvia Tabares, A. F. Barrera, J. . D. Arroyave y J. D. Pineda, «UN MÉTODO PARA LA TRAZABILIDAD DE REQUISITOS EN EL PROCESO UNIFICADO DE DESARROLLO,» EIA, nº 8, pp. 69-82, 2007.

[55] J. Conejero y J. Hernández , «Analysis of Crosscutting Features,» ACM, pp. 3-10,

102

2008.

[56] Bizagi, «Bizagi Suite BPMN 2.0,» 2014.

[57] F. A. Amo, L. Martínez Normand y F. J. Segovia Pérez, Introducción a la ingeniería del software, Madrid: DELTA, 2005.

[58] F. Xhafa, Aplicaciones distribuidas en Java con tecnología RMI, DELTA, 2007.

[59] E. Gamma, R. Helm, R. Johnson y J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Pearson , 2009.

[60] B. C. Falgueras, Ingeniería del Software, Barcelona: UOC, 2003.

[61] W. F. Stephan Alber, Beginning App Development with Parse and PhoneGap, New York: Apress, 2015.

[62] «Justinmind,» [En línea]. Available: http://www.justinmind.com/. [Último acceso: 15 Julio 2015].

[63] J. R. I. J. Grady Booch, El lenguaje unificado de modelado:guía del usuario, Pearson, 2006.

[64] S. Haldar, SQLite Database System Design and Implementation, Self, 2015.

[65] M. Miller, Using Google Maps and Google Earth, Pearson , 2011.

[66] Twitter, «Twitter4j,» [En línea]. Available: http://twitter4j.org/en/index.html. [Último acceso: 18 Julio 2015].

[67] Developer Android, «Support Library Features,» [En línea]. Available: https://developer.android.com/tools/support-library/features.html. [Último acceso: 19 Julio 2015].

[68] D. C. Montgomery, Diseño y análisis de experimentos, México: LIMUSA WILEY, 2004.

[69] Decreto No. 122, Palmira: Alcaldia de Palmira, 2012.

[70] D. Salvi, «Aprueban un aumento del 21% en la tarifa de Taxis,» La voz de Tandil, 10 Junio 2011.

[71] «TAXIMETRO, CONDICIONES TÉCNICAS Y METROLÓGICAS DEL TAXIMETRO ACTIVO,» Barranquilla, 2015.

103

[72] I. Pellejero, F. Andreu y A. Lesta, Fundamentos y aplicaciones de seguridad en redes WLAN: de la teoría a la práctica, Barcelona: Marcombo, 2006.

[73] D. L. Rodríguez, Sistemas inalámbricos de comunicación personal, Mexico : Marcombo, 2001.

[74] J. G. Voinea, Redes de Comunicaciones. Administración y gestión., Almería: Fired, 2011.

104

ANEXOS

105

ANEXO A: DIAGRAMAS DE SECUENCIA

Diagrama de Secuencia: Iniciar Medición

Figura 34. Diagrama de Secuencia: Iniciar Medición. Fuente: Elaboración Propia.

sd Iniciar Medición

Usuario

InicioApptaximetro:Taximetro servicio:Servicio medición:Medición«thread»

tt:TimerTask

aumentarUnidad()

iniciarServicio(velocidad)

actionBtnIniciarServicio()

insertarRegistros(velocidad)

iniciarMedicion(velocidad)

106

Diagrama de Secuencia: Calcular Tarifa

Figura 35. Diagrama de Secuencia: Calcular Tarifa. Fuente: Elaboración Propia.

sd Calcular Tarifa

Usuario

InicioAppsqLiteOpenHelper:SQLiteOpenHelpertaximetro:Taximetro parse:ParseresumenApp:ResumenApp

mostrarTablaResumen()

listarTarifas(): List <Tarifa>

listarRecargos(): List <Tarifa>

seleccionarRecargos()

guardarTablaResumen()

calculartotalAPagar()

mostrarTarifa (Activity ): List<Tarifa>

mostrarRecargos(Activity): List <Tarifa>

actionBtnDetenerServicio()

107

Diagrama de Secuencia: Actualizar Tarifa

Figura 36. Diagrama de Secuencia: Actualizar Tarifa.


sd ActualizarTarifa

taximetro:Taximetro sqLiteOpenHelper:SQLiteOpenHelper parse:Parse

cargarTarifa()

eliminarTarifas ()

guardarTarifa()

eliminarTarifa()

108

ANEXO B: INSTALACIÓN DE LA LIBRERÍA

ANDROID SUPPORT V7 APPCOMPAT Para la instalación y configuración de ésta librería se siguieron los siguientes pasos: 1. Se inició el Android SDK Manager en la pestaña “Window” de Eclipse. 2. Una vez en el administrador del SDK ubicarse en la carpeta Extras, seleccionar “Android Support Library” y dar click en instalar paquetes.

Figura 37. Configuración de la librería Android Support.


109

ANEXO C: PRUEBAS

Identificador

CP_006



Mostrar la ubicación del usuario en el mapa.




Objetivo Verificar que al abrir la aplicación el sistema le muestre al usuario, mediante un mapa, el lugar donde se encuentra.


El usuario tiene acceso a Internet y tiene el GPS activo.

Pasos de ejecución 1. Se abrió la aplicación.


El sistema obtiene las coordenadas de localización del dispositivo móvil y mediante un círculo azul, muestra la posición del usuario.


Al abrir la aplicación se le muestra al usuario el lugar donde se encuentra.



Falló: Fecha

Comentarios El tiempo que tarda el sistema en mostrar el mapa es del orden de milisegundos.

Tabla 24. Formato de caso de prueba: Mostrar la ubicación del usuario.

110

Identificador

CP_007



Iniciar aplicación.




Objetivo Verificar que se inicialicen correctamente los cinco contadores.


El usuario tiene acceso a Internet. La tabla tarifa existe y es vigente.

Pasos de ejecución 1. Se abrió la aplicación. 2. El sistema deshabilitó el botón “Siguiente”.


El sistema inicializa los contadores de: tiempo, velocidad, unidades de arranque y valor de la carrera.


Al abrir la aplicación cada uno de los contadores se inicializa en su respectiva unidad.



Falló: Fecha

Comentarios

Tabla 25. Formato de caso de prueba: Iniciar aplicación.

Identificador

CP_008



Calcular valor de la carrera.


111



Objetivo Verificar que efectivamente se suma el valor de la tarifa básica con el valor total de recargos.


El usuario tiene acceso a Internet. El usuario ha seleccionado más de un recargo.

Pasos de ejecución 1. Se dio click en el botón datos de la carrera.


El sistema suma el valor de la tarifa básica con el valor total de los recargos.


El sistema incrementa el valor total de la carrera cuando se le aplican recargos al recorrido.



Falló: Fecha

Comentarios

Tabla 26. Formato de caso de prueba: Calcular valor de la carrera.

Identificador

CP_009



Almacenar información del servicio.




Objetivo Verificar que al finalizar el servicio se almacenen los datos en Parse.


El usuario tiene acceso a Internet.

112

Pasos de ejecución 1. Se finalizó el servicio dando click en el botón "Datos Carrera" 2. Se verifico que en el BackEnd Parse quedaran registrados los datos del servicio.


Una vez se detiene el recorrido el sistema almacena los datos del servicio en Parse.


Se ha consultado la base de datos del servidor y efectivamente quedan registrados los datos del servicio.



Falló: Fecha

Comentarios El tiempo que tarda el sistema en enviar los datos al servidor es del orden de milisegundos.

Tabla 27. Formato de caso de prueba: Almacenar información del servicio.

Identificador

CP_0010



Generar informe con los datos del servicio.




Objetivo Verificar que al detener el recorrido se muestre una tabla en el que el usuario pueda ver un resumen de la carrera.


El usuario tiene acceso a Internet.

Pasos de ejecución Una vez se terminaron de seleccionar los recargos se dio click en “Datos de la carrera”.


El sistema muestra una tabla en el que se le muestra al usuario un resumen del servicio.


Al dar click en datos de la carrera, se muestra una tabla, la cual indica: fecha, hora de servicio, unidades marcadas, duración, distancia, costo total de la tarifa básica, costo total

113

de los recargos causados y total a pagar.



Falló: Fecha

Comentarios

Tabla 28. Formato de caso de prueba: Generar informe con los datos del servicio.

Identificador

CP_0011



Cargar modelo de tarifa.




Objetivo Verificar que al abrir la aplicación, por primera vez, se carguen los datos de Parse a SQLite.


El usuario tiene acceso a Internet. El administrador tiene el archivo en formato CSV con los datos de la tarifa que desea cargar. El administrador está registrado en la aplicación y en Parse.

Pasos de ejecución 1. Se ingresó a la aplicación web, con usuario y contraseña. 2. Se seleccionó el archivo que contenía los datos de la tarifa que se quería cargar. 3. Se consultó la base de datos en Parse. 4. Se verifico que existiera la tabla tarifa en la aplicación móvil TwTaxi.


La aplicación carga los datos que se encuentran en Parse y los guarda en la base de datos local SQLite.


Al abrir la aplicación por primera vez el sistema carga los datos que se encuentran en Parse.

114



Falló: Fecha

Comentarios El tiempo que tarda el sistema en cargar las tarifas es del orden de milisegundos.

Tabla29. Formato de caso de prueba: Cargar modelo de tarifa.

115

ANEXO D: VALIDACIÓN

Figura 38. Curvas de Operación Características. Fuente: [68].

116

Tabla 30. Distribución T-Student. Fuente [68].

desarrollo de un prototipo de software ...repository.udistrital.edu.co/bitstream/11349/7136/1...el...

Documents