BabativaGoyenecheAngélicaMaría2017 PDF

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
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 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. 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.
1
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.
2
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?
3
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.
4
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].
5
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].
6
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.
7
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.
8
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.
9
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
10
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.
11
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

1
Tabla 1. Tarifas Recargos 2014 .
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.
12
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].
13
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].
14
 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
15
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).
16
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].
17
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
18
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].
19
 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
20
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.
21
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.
22
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,
23
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].
24
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].
25
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].
26
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.
27
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.
28
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
29
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].
30
Figura 9. Sprint Backlog.
Fuente: Elaboración Propia.
31
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.
32
Sprint Historias Planificadas
Documentación previa del desarrollo móvil.
Sprint 0 Desarrollo de un prototipo inicial de bajo nivel.
Construcción de las historias de usuario.
Sprint 1 Prototipo de las historias de usuario.
Modelo de requerimientos.
Modelo de casos de uso.
Arquitectura de la aplicación.
Sprint 2 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.
Cargar modelo de tarifa.
Sprint 3 Iniciar medición.
Contabilizar y seleccionar recargos.
Sprint 4 Calcular valor de la carrera.
Almacenar información del servicio.
Sprint 5 Generar informe con los datos del servicio.
Notificar y actualizar modelo de la tarifa.
Sprint 6 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
Se realizó una documentación previa sobre desarrollo móvil.

Se definió el entorno de desarrollo, junto a sus componentes y librerías.
ACTIVIDADES
Se desarrolló un prototipo funcional inicial.
Prototipo Inicial de bajo nivel.
ENTREGABLES
DURACIÓN 1 Semana
Tabla 5. Actividades desarrolladas en el Sprint 0. Fuente: Elaboración propia.
33
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
Permitió la comunicación de la Internet inalámbrico.

aplicación móvil con otras
tecnologías.
Lenguaje de Programación. Android versión 4.4 KitKat y Java

Standard Edition versión 8.
Herramienta para crear prototipos Justinmind versión 6.4.

Presentación
de interfaz.
Herramienta que permite crear Android Asset Studio.

componentes gráficos.
Librería utilizada para manipular y Google Maps.

utilizar los mapas de Google.
Entorno de desarrollo y Eclipse Luna Service Release 2

compilación. versión 4.4.2.
Herramienta utilizada para el Bizagi Modeler.

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

análisis y diseño de la aplicación.
Negocio
Librería que permite la Twitter4j.
interacción de una aplicación
móvil con Twitter.
Librería utilizada para administrar Android Support v7 appcompat.

la compatibilidad de las diferentes
versiones de Android.
Persistencia de Datos en la nube BackEnd Parse versión 1.7.1.

Persistencia
Persistencia de Datos local. SQLite.
Tabla 6. Herramientas utilizadas para el desarrollo del proyecto.
34
Se definieron las historias de usuario con sus respectivos prototipos.

Se elaboró el modelo de requerimientos.
ACTIVIDADES
Se diseñaron los módulos y casos de uso de la aplicación.
Diagrama de requerimientos funcionales y no funcionales.
Diagrama de contexto.
ENTREGABLES 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.
35
MÓDULO RESPONSABILIDAD
Encargado de cargar y actualizar, periódicamente, el

GESTIÓN DE TARIFAS
modelo de tarifa al inicializar el taxímetro.
Encargado de hacer las mediciones con respecto al

tiempo y a la distancia, calculando el costo total de la
MEDICIÓN carrera. Además actualiza y calcula, mediante la
asignación de coordenadas espaciales, la localización
geográfica del móvil.
Cada vez que haya un nuevo modelo de tarifa, se le

informa al usuario que el valor de la tarifa se ha
NOTIFICACIÓN
actualizado. También ocurre una notificación cuando el
usuario desea reportar en Twitter.
Encargado de verificar, mediante técnicas estadísticas,

VALIDACIÓN
el correcto funcionamiento de la aplicación.
Tabla 8. Módulos de la aplicación móvil. Fuente: Elaboración propia

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

breve, comprensiva y delimitada.
36
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: Resultado:
Comprobar que el GPS no está activo. 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.
Abrir la aplicación. Obtener las coordenadas de localización del

dispositivo móvil y mediante un círculo azul,
mostrar la posición del usuario.
37
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.
Abrir la aplicación. - 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.
La tabla de tarifa no existe.
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.
38
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).
La velocidad del vehículo es menor de Incrementar las unidades por tiempo cada 30
10Km/h. segundos.
La velocidad del vehículo es mayor de Incrementar las unidades por distancia cada
10Km/h. 100 metros.
La velocidad del vehículo incrementa y es Detener el contador de tiempo y retomar el

superior a 10km/h. valor del contador de distancia.
La velocidad del vehículo decrementa y es Detener el contador de distancia y retomar el

inferior a 10km/h. 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.
El usuario llega al lugar de destino y da click Desplegar un menú en el que el usuario podrá
en el botón detener. seleccionar los recargos a los que aplica la
carrera.
Sumar al contador monetario el valor de dicho

El servicio es pedido por teléfono/aplicación. recargo, el cual dependerá del modelo de
tarifa que se haya consultado (para el 2014
de $700).
39
El servicio de taxi es prestado desde / al Sumar al contador monetario el valor de dicho
aeropuerto. recargo, el cual dependerá del modelo de
de $3.900).
El servicio de taxi es prestado desde el Sumar al contador monetario el valor de dicho

terminal de transporte. recargo, el cual dependerá del modelo de
El servicio de taxi es prestado entre las de $500).
10:00pm y las 5:00 am.
Sumar al contador monetario el recargo
El servicio de taxi es prestado un día festivo o nocturno, (para el 2014 de $1900).
un domingo.
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.
El usuario termina de seleccionar los Sumar los recargos seleccionados al contador

recargos. 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
40
Actor: Sistema. HU Relacionadas: Hu_Med_03, Hu_Med_04,
Módulo: Medición.
Descripción: Al detener el recorrido se debe almacenar los datos del servicio.
El usuario da click en “Detener”. 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.
Al finalizar el recorrido dar click en “Datos de Generar un informe con los siguientes datos:
la carrera”. 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.
41
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.
No existe modelo de tarifa. El administrador ingresa a la aplicación, con

usuario y contraseña e importa el modelo de
tarifa a Parse.
Al abrir 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.
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á.
El modelo de tarifa no está en vigencia. El administrador ingresa a la aplicación, con

usuario y contraseña e importa el nuevo
modelo de tarifa a Parse.
42
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,

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.
Al finalizar el recorrido el usuario da click en la Publica en la red social Twitter un reporte con
opción “Reportar”. los siguientes datos: placas del taxi, empresa,
unidades de diferencia, motivo del reporte y
comentarios.
43
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].
44
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 HU_Tar_ HU_Not_
_1 2 1
Hu_Med_01 X X X
Hu_Med_02 X X
Hu_Med_03 X X X X X X
I Hu_Med_04 X X X X X
N
D Hu_Med_05 X X X X
E
P
Hu_Med_06 X X X
E
N
D Hu_Med_07 X
I
E Hu_Med_08
N
T HU_Tar_01 X X
E
S HU_Tar_02
HU_Not_1
Tabla 9. Matriz de trazabilidad.
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.
45
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.
46
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.
47
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).
custom Modelo de Requerimientos
Requisitos Funcionales
+ Notificación
+ Medición
El modelo de requisitos estructura el catálogo de + Gestión de tarifas
Requerimientos Funcionales y No Funcionales de
la aplicación.
Requerimientos No funcionales
+ Rnf_App_01_Persistencia
+ Rnf_App_02_Arquitectura
+ Rnf_App_03_Desempeño
+ Rnf_App_04_Usabilidad
+ Rnf_App_05_Disponibilidad
+ Rnf_App_06_Confiabilidad
Figura 11. Módulo de Requerimientos para la Aplicación.

48
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:
custom Requerimientos Funcionales
Medición
Gestión de tarifas
+ Rf_Med_01_IniciarAplicación
+ Rf_Tar_11_CargarModeloTarifa
+ Rf_Med_02_IniciarMedición
+ Rf_Tar_12_ActualizarModeloTarifa
+ Rf_Med_03_DetenerMedición
+ Rf_Med_04_VerificarGPS
+ Rf_Med_05_MostrarPosiciónActual
+ Rf_Med_06_Iniciar Contadores
+ Rf_Med_07_CalcularTarifaTotal
Notificación
+ Rf_Med_08_CalcularRecargosAdicionales
+ Rf_Med_09_GenerarReporte + Rf_Not_21_NotificarCambio Tarifa.
+ Rf_Not_22_NotificarQueja: Twitter
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].
49
 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
50
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.
uc Diagrama de Contexto
MÓDULOS
Cu_Med_000_Medición
Cu_Tar_100_Gestión de
tarifas
Sistema
Usuario
Cu_Not_200_Notificación
Administrador
Figura 13. Diagrama de Contexto con la estrategia de nomenclatura de los casos de uso.
51
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:
uc Medición
Notificación
Cu_Med_04_VerificarGPS
«include»
Cu_Med_01_Iniciar
Cu_Med_05_MostrarPosición
aplicación
«include» Actual
«include»
Cu_Med_06_Iniciar
Contadores
Cu_Med_02_Iniciar
Medición
Usuario
Cu_Med_08_CalcularRecargos
Adicionales
«include»
Cu_Med_03_Detener Cu_Med_07_CalcularTarifa Cu_Med_09_Generar

Medición Total «extend» Reporte
«include»
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.
52
uc Gestión de tarifas
Gestión de Tarifas
Cu_Tar_11_CargarModelo
Tarifa
Administrador Cu_Tar_12_ActualizarModelo
Tarifa
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.
53
uc Cu_Not_200_Notificación
Notificación
Cu_Not_21_NotificarCambio
Tarifa
Sistema
Cu_Not_22_NotificarQuej a
Tw iter
Usuario
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].
54
Figura 17. Modelo de procesos. Fuente: Elaboración propia
55
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.
56
uc Diagrama de Proceso de Negocio
Preparación
Datos de configuración del
dispositiv o.
Entrada
Salida Mensaj e solicitando activ ar GPS.

Abrir aplicativo Proceso: verificación y solicitud de activación GPS
Coordenadas del
Entrada
dispositiv o
Entrada
Salida Muestra la posición actual del usuario en el

Proceso: mostrar usuario en el mapa mapa.
Entrada
Medición
Salida Unidades transcurridas

Iniciar Entrada
Inicializar taximetro Calcular unidades transcurridas
aplicativo
Usuario
Calcular costos
Tarifa básica
Entrada
Entrada
Salida Costo total tarifa básica

Detener Cálculo de la tarifa básica
Tarifa del recargo nocturno,

Hora y fecha Entrada dominical y/o festiv o. Entrada
Entrada Entrada
Salida Costo del racargo nocturno, dominical y/o Entrada Suma de la tarifa básica Salida Costo total de la carrera
Cálculo automático de recargos causados. más recargos.
festiv o.
Recargos seleccionados por el Tarifa de los recargos

Entrada Entrada
usuario. seleccionados
Entrada Entrada
Salida Costo de los recargos

Cálculo manual de recargos causados. seleccionados.
Reportar
Salida Reporte exitoso

Reportar Generar formulario
Información del recorrido Placa y nombre de la

empresa del v ehículo.
Figura 18. Flujo de actividades.

57
Se diseñó el modelo arquitectónico y estructural de la aplicación.

Se elaboraron las historias de usuario: Verificar y solicitar la activación
ACTIVIDADES
del GPS, mostrar la ubicación del usuario en el mapa e iniciar aplicación.
Diagrama de clases.
Diagrama de secuencia.
ENTREGABLES 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.
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
58
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].
59
Figura 19. Arquitectura de la aplicación.
Fuente: Elaboración propia
60
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).
61
class DiagramaClases
CONT ROLADOR
NEGOCIO
Acti onBarActi vi ty M odelo::Empresa M odelo::Tarifa
Controlador::RecargoApp
~ nom bre: Stri ng - fechaVi genci a: Stri ng
~ datos: GestorDatos ~ tel efono: Stri ng - i d: i nt
+ m ostrarRecargos(): voi d + Em presa(Stri ng, Stri ng) - nom bre: Stri ng
# onCreate(Bundl e): voi d + getNom bre(): Stri ng - uni dades: i nt
+ onCreateOpti onsM enu(M enu): bool ean + getT el efono(): Stri ng - val or: i nt
+ onOpti onsItem Sel ected(M enuItem ): bool ean + setNom bre(Stri ng): voi d + getFechaVi genci a(): Stri ng
+ setT el efono(Stri ng): voi d + getId(): i nt
+ getNom bre(): Stri ng
Acti onBarActi vi ty + getUni dades(): i nt
M odelo::GestorDatos + getVal or(): i nt
Controlador::EmpresaApp
+ setFechaVi genci a(Stri ng): voi d
- datos: GestorDatos - em presas: Li st<Em presa> + setId(i nt): voi d
- parse: Servi dorParse + setNom bre(Stri ng): voi d
+ m ostrarEm presa(): voi d - recargos: Li st<T ari fa> + setUni dades(i nt): voi d SQLi teOpenHel per
# onCreate(Bundl e): voi d - sql i te: T ari faSqLi teHel per + setVal or(i nt): voi d
+ onCreateOpti onsM enu(M enu): bool ean - tari fas: Li st<T ari fa> Datos::TarifaSqLiteHelper
+ T ari fa(i nt, i nt, i nt, Stri ng, Stri ng)
+ onOpti onsItem Sel ected(M enuItem ): bool ean + T ari fa(i nt, i nt) - sql Create: Stri ng = "CREAT E T ABLE T ...
+ accessUrl T wi tter(): Stri ng
+ T ari fa(i nt, i nt, Stri ng) - sql CreateEm presa: Stri ng = "CREAT E T ABLE E...
+ actual i zarT ari fa(Li st<ParseObj ect>, Acti vi ty): bool ean
+ authori zeUrl T wi tter(): Stri ng + T ari fa()
Acti onBarActi vi ty + borrarT ari fas(): voi d
+ cal l BackUrl T wi tter(): Stri ng + contarRegi strosEm presa(): i nt
Controlador::TarifaApp + cargarEm presa(Stri ng, Stri ng): voi d + contarRegi strosT ari fa(): i nt
+ cargarT ari fa(i nt, i nt, Stri ng, Stri ng): voi d + i nsertarRegi stroEm presa(Em presa): voi d
~ datos: GestorDatos
+ consum erKeyT wi tter(): Stri ng + i nsertarRegi stroT ari fa(T ari fa): voi d
+ m ostrarT ari fas(): voi d + consum erSecretT wi tter(): Stri ng Datos::DatosTw itter
+ l i starEm presas(): Li st<Em presa>
# onCreate(Bundl e): voi d + GestorDatos() + l i starRecargos(): Li st<T ari fa>
+ ACCESS_URL: Stri ng = "https://api .tw... {readOnl y}
+ onCreateOpti onsM enu(M enu): bool ean + i ni ci al i zarParse(Acti vi ty): voi d + l i starT ari fas(): Li st<T ari fa>
+ AUT HORIZE_URL: Stri ng = "https://api .tw... {readOnl y}
+ onOpti onsItem Sel ected(M enuItem ): bool ean + i nsertarRegi stros(T ari fa): voi d + onCreate(SQLi teDatabase): voi d
+ CONSUM ER_KEY: Stri ng = "ON6Q0rSwr8Dl J2... {readOnl y}
+ i nsertarRegi stros(Em presa): voi d + onUpgrade(SQLi teDatabase, i nt, i nt): voi d
+ CONSUM ER_SECRET : Stri ng = "BHgV4s7VOCKYAe... {readOnl y}
+ l i starEm presas(Acti vi ty): Li st<Em presa> + T ari faSqLi teHel per(Context)
+ OAUT H_CALLBACK_URL: Stri ng = "m dw://twi tter" {readOnl y}
Acti onBarActi vi ty + l i starRecargos(Acti vi ty): Li st<T ari fa>
+ REQUEST _URL: Stri ng = "https://api .tw... {readOnl y}
Controlador::Tw itterApp + l i starT ari fas(Acti vi ty): Li st<T ari fa>
+ obtenerNum eroRegi stros(Acti vi ty): i nt + getAccessUrl (): Stri ng
- ACCESS_KEY: Stri ng = nul l + obtenerNum eroRegi strosEm presa(Acti vi ty): i nt + getAuthori zeUrl (): Stri ng
- ACCESS_SECRET : Stri ng = nul l + requestUrl T wi tter(): Stri ng + getConsum erKey(): Stri ng
- consum er: Com m onsHttpOAuthConsum er + getConsum erSecret(): Stri ng
- provi der: Com m onsHttpOAuthProvi der + getOauthCal l backUrl (): Stri ng
- twi tter: T wi tter + getRequestUrl (): Stri ng
+ construi rM ensaj e(): Stri ng
- envi arT weet(Stri ng): voi d
+ onCreate(Bundl e): voi d
+ onCreateOpti onsM enu(M enu): bool ean
+ onOpti onsItem Sel ected(M enuItem ): bool ean
+ onResum e(): voi d Datos::Serv idorParse
- Parse_App_Id: Stri ng = "HwB7T fj m 0ha4j Q... {readOnl y}

- Parse_Cl i ent_Key: Stri ng = "5bXnPLi XNuofLA... {readOnl y}
Acti onBarActi vi ty
+ i ni ci al i zarParse(Acti vi ty): voi d
Controlador::ResumenApp + Servi dorParse()
- consum er: Com m onsHttpOAuthConsum er
~ datos: GestorDatos
- provi der: Com m onsHttpOAuthProvi der
~ taxi m etro: GestorT axi m etro Acti onBarActi vi ty
M odelo::Localizacion
- al m acenarInform aci on(): voi d
+ cal cul artotal APagar(): voi d - l ati tud: doubl e
+ cerrarApl i caci on(Vi ew): voi d - l ongi tud: doubl e
+ m ostrarT abl aResum en(): voi d - m apa: Googl eM ap
# onCreate(Bundl e): voi d
+ onCreateOpti onsM enu(M enu): bool ean + getLati tud(): doubl e
+ onOpti onsItem Sel ected(M enuItem ): bool ean + getLongi tud(): doubl e
+ getM apa(): Googl eM ap
M odelo::GestorTaximetro + Local i zaci on(Googl eM ap)
+ m ostrarM apa(): voi d
- l ocal i zaci on: Local i zaci on + setLati tud(doubl e): voi d
Acti onBarActi vi ty ~ m apa: Googl eM ap + setLongi tud(doubl e): voi d
Controlador::RecargosServ icioApp - servi ci o: Servi ci o + setM apa(Googl eM ap): voi d
~ datos: GestorDatos + actual i zarPuntosPosi ci on(doubl e, doubl e): voi d
- recargos: Li st<T ari fa> + actual i zarVel oci dad(doubl e): voi d
~ taxi m etro: GestorT axi m etro + cal cul arVal orServi ci o(Acti vi ty): i nt
+ GestorT axi m etro(Googl eM ap) M odelo::Serv icio
+ buscarRecargo(Stri ng): i nt + GestorT axi m etro()
+ cargarVal oresRecargos(): voi d + getLocal i zaci on(): Local i zaci on - fecha: Stri ng = ""
+ l i starRecargos(): voi d + getServi ci o(): Servi ci o ~ m edi ci on: M edi ci on
+ l i stenerPagi naResum en(Vi ew): voi d + getT otal Recargos(): doubl e - ti em poT otal : Stri ng = ""
# onCreate(Bundl e): voi d - total Pagar: doubl e = 0
+ i ni ci arServi ci o(doubl e): voi d
+ onCreateOpti onsM enu(M enu): bool ean + m ostrarM apa(): voi d - total Recargos: doubl e = 0
+ onOpti onsItem Sel ected(M enuItem ): bool ean + m ostrarRegi stros(): Stri ng - uni dades: i nt = 25 Runnabl e
+ restarRecargo(T extVi ew): voi d - vel oci dad: doubl e = 0 M odelo::M edicion
+ setT otal Recargos(doubl e): voi d M odelo::Tiempo
+ sum arRecargo(T extVi ew): voi d
+ aum entarUni dad(): voi d - contadorDi stanci a: doubl e = 0
+ total i zarRecargos(): voi d - am pm : Stri ng
+ cal cul arVal orServi ci o(Acti vi ty): i nt - contadorT i em po: i nt = 0
- fechaActual : Stri ng = " "
+ conversi onVel oci dad(doubl e): doubl e - hora: Stri ng ([]) = new Stri ng[65]
- h1: T hread
+ getFecha(): Stri ng - posi ci onM edi ci on: i nt = 0
- hora: Stri ng
+ getM edi ci on(): M edi ci on ~ ti em po: T i em po
- horaCom pl eta: Stri ng = " "
Acti onBarActi vi ty + getT i em poT otal (): Stri ng - vel : doubl e ([]) = new doubl e[65]
- horaIni ci o: Stri ng = ""
Controlador::EmpresaApp::InicioApp + getT otal Pagar(): doubl e - m i nutos: Stri ng
+ cal cul arDi stanci a(doubl e, i nt): voi d
+ getT otal Recargos(): doubl e - segundos: Stri ng
- datos: GestorDatos + cal cul arT i em po(): voi d
+ getUni dades(): i nt + getContadorDi stanci a(): doubl e
+ m apa: Googl eM ap + getVel oci dad(): doubl e + getFechaActual (): Stri ng
~ m Chronom eter: Chronom eter + getContadorT i em po(): i nt
+ i ni ci arM edi ci on(doubl e): voi d + getHoraCom pl eta(): Stri ng
- taxi m etro: GestorT axi m etro + getT i em po(): T i em po
+ m ostrarRegi stros(): Stri ng + getHoraIni ci o(): Stri ng
+ i nsertarRegi stros(doubl e): voi d
+ acti onBtnIni ci arServi ci o(): voi d + Servi ci o() + obtenerFechaActual (): voi d
+ M edi ci on()
+ actual i zarPosi ci on(): voi d + setFecha(Stri ng): voi d + obtenerHoraActual (): voi d
+ m ostrarRegi stros(): Stri ng
+ actual i zarT ari fa(): voi d + setM edi ci on(M edi ci on): voi d + run(): voi d
+ retonarFecha(): Stri ng
+ setT i em poT otal (Stri ng): voi d + setHoraCom pl eta(Stri ng): voi d
+ cargarDatosParseEm presa(): voi d + setContadorDi stanci a(doubl e): voi d
+ cargarDatosParseT ari fa(): voi d + setT otal Pagar(doubl e): voi d + setHoraIni ci o(Stri ng): voi d
+ setContadorT i em po(i nt): voi d
+ i ni ci al i zarContadores(): voi d + setT otal Recargos(doubl e): voi d + T i em po()
+ l i stenerPagi naRecargos(Vi ew): voi d + setUni dades(i nt): voi d
# onCreate(Bundl e): voi d + setVel oci dad(doubl e): voi d
+ onCreateOpti onsM enu(M enu): bool ean
+ onDestroy(): voi d
+ onOpti onsItem Sel ected(M enuItem ): bool ean
# onRestart(): voi d
# onStop(): voi d
+ Veri fi carGPSActi vo(): voi d
Figura 20. Diagrama de Clases. Fuente: Elaboración Propia
62
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.
sd Iniciar Aplicación
«activity» tm:T aximetro sv:Servicio lm: LocationManager lc: Localización gm: GoogleMap sq: SQLiteOpenHelper p:Parse
InicioApp
Usuario
onCreate(Bundle)
verificarGPSActivo()
locManager=if(!locManager.isProviderEnabled)
mostrarMapa()
mostrarMapa()
getMapa()
obtenerNumeroRegistros(Activity)
cargarDatosParse()
inicializarContadores()
actualizarPosicion ()
getLatitude()
getLongitude()
actualizarPuntosPosicion(): latitud,longuitud
obtenerNumeroRegistros(Activity): numeroRegistros actualizarVelocidad(velocidad)
contarRegistrosT abla(): numeroRegistros
cargarDatosParse()
Figura 21.Diagrama de Secuencia: Iniciar Aplicación. Fuente: Elaboración Propia.
63
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.
class Persistencia del cliente
EMPRESA TARIFA
«column» «column»
*PK K_Object_Id: VARCHAR(11) *PK K_Object_Id: VARCHAR(11)
N_Nombre: VARCHAR(20) * N_Nombre: VARCHAR(15)
N_Telefono: VARCHAR(7) * Q_Unidad: NUMBER(3)
* Q_Valor: NUMBER(5)
«PK» * F_Fecha_Vigencia_Tarifa: DATE
+ PK_EMPRESA(VARCHAR)
«PK»
+ PK_TARIFA(VARCHAR)
Figura 22. Persistencia del cliente.

64
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.
dm Persistencia del serv idor
TARIFA
EMPRESA
«column»
«column» *PK K_Object_Id_Tarifa: VARCHAR(11)
*FK K_Object_Id_Empresa: VARCHAR(11) * N_Nombre: VARCHAR(15)
N_Nombre: VARCHAR(20) * Q_Unidad: NUMBER(3)
N_Telefono: VARCHAR(7) * Q_Valor: NUMBER(5)
* F_Fecha_Vigencia_Tarifa: DATE
«FK»
+ FK_EMPRESA(VARCHAR) «PK»
+ PK_TARIFA(VARCHAR)
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)
USUARIO Q_Unidades_Aplicación: NUMBER(3)
Q_Unidades_Vehiculo: NUMBER(3)
«column» Hora: VARCHAR(9)
*PK K_Object_Id: VARCHAR(50) Q_Total_Recargos: NUMBER(11,2)
N_Username: VARCHAR(10) Q_Total_Unidades: NUMBER(11,2)
N_Password: VARCHAR(15) K_Placa: NUMBER(6)
* K_Object_Id_Empresa: VARCHAR(11)
«PK» * K_Object_Id_Tarifa: VARCHAR(11)
+ PK_USUARIO(VARCHAR)
«PK»
+ PK_SERVICIO(VARCHAR)
«unique»
+ UQ_SERVICIO_K_Object_Id_Empre(VARCHAR)
Figura 23. Persistencia en el servidor. Fuente: Elaboración propia.
65
Se desarrollaron los módulos de la aplicación: iniciar sesión y cargar

ACTIVIDADES tarifa.
Diagrama proceso de negocio: cargar tarifa.
ENTREGABLES
Tabla 11. Actividades Sprint 3. Fuente: Elaboración Propia.
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.
66
Figura 24. Modelo de procesos: Cargar tarifa. Fuente: Elaboración propia.
67
Se desarrollaron los módulos de la aplicación: Calcular valor de la

ACTIVIDADES
carrera, contabilizar y seleccionar recargos adicionales.
Avance en el desarrollo del prototipo.
ENTREGABLES
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.
Se desarrollaron los módulos de la aplicación: Almacenar información del

ACTIVIDADES
servicio y generar informe con los datos del servicio.
ENTREGABLES
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.
68
Se elaboró el módulo de notificación, específicamente las historias de

usuario: Notificar y actualizar modelo de tarifa, y notificar queja en
ACTIVIDADES Twitter.
Se elaboraron los manuales de la aplicación: Móvil y web.

ENTREGABLES 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.
69
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.
70
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.
71
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:
72
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.
73
3.10 PRUEBAS
Se realizaron los casos de prueba de cada una de las historias de

ACTIVIDADES
usuario.
Cinco plantillas que describen cada caso de prueba.
ENTREGABLES
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
Subsistema o Verificar y solicitar la activación del GPS.
Función
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.
74
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 Al abrir la aplicación se despliega un mensaje: “El sistema
esperados GPS está inactivo, ¿Desea activarlo?”
Resultados Al abrir la aplicación se despliega un mensaje en el que se
Obtenidos solicita al usuario activar el GPS.
Estado de la prueba Pasó: Fecha: 17 de Julio de Falló: Fecha:
Si 2015
Comentarios La aplicación se demora en abrir de 1 a 3 segundos.
Tabla 16. Formato de caso de prueba: Activar GPS.
Subsistema o Iniciar medición.
Función
2015
2015
Nombre
Caso Prueba 002
Objetivo Verificar que se estén incrementando las unidades según el
factor que esté sucediendo más rápido: tiempo o distancia.
prueba 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.
Resultados El sistema incrementa el contador de unidades según el
esperados factor que se esté dando más rápido: distancia o tiempo.
Además se actualiza el valor de la carrera conforme van a
75
aumentando las unidades.
Resultados El contador de unidades aumenta según el factor que suceda

Obtenidos más rápido y actualiza el valor de la carrera según las
unidades que va marcando.
Estado de la prueba Pasó: Fecha: 17 de Julio de Falló: Fecha
Si 2015
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.
Subsistema o Contabilizar y seleccionar recargos
Función
2015
2015
Nombre
Caso Prueba 003
Objetivo Verificar que se despliegue un menú para que el usuario
seleccione los recargos a los que aplica la carrera.
prueba 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.
Resultados Al detener el recorrido se despliega un menú en el que el
esperados usuario puede seleccionar los recargos a los que aplica la
carrera. Una vez el usuario termina de seleccionarlos se
76
actualiza el valor total de recargos.
Resultados Al detener el recorrido se despliega un menú en el que se

Obtenidos pueden seleccionar los recargos, a medida que estos van
siendo seleccionados el total de recargos se va actualizando.
Si 2015
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.
Subsistema o Notificar y actualizar modelo de tarifa.
Función
2015
2015
Nombre
Caso Prueba 004
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.
prueba 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.
Resultados La aplicación actualiza los datos que se encuentran en Parse
esperados y los guarda en la base de datos local SQLite. El sistema
77
informa que se ha cambiado el modelo de tarifa.
Resultados Al abrir la aplicación el sistema notifica que se han cambiado

Obtenidos las tarifas y actualiza las existentes en SQLite.
Si 2015
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.
Subsistema o Notificar queja en Twitter.
Función
2015
2015
Nombre
Caso Prueba 005
Objetivo Verificar que cuando el usuario quiera reportar una situación
anómala, pueda difundirlo por medio de la red social Twitter.
prueba 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”.
Resultados La aplicación publica el reporte en la página
esperados @denunciealtaxista y @TwTaxii con los datos que ingresa el
usuario.
78
Resultados Al hacer el reporte, ingresando los datos de la carrera, queda
Obtenidos registrada la denuncia en Twitter y se despliega un mensaje
“Tu denuncia ha sido publicada correctamente”.
Si 2015
Comentarios El tiempo que tarda el sistema en publicar el reporte es del

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.
79
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.
80
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.
81
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
82
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.
83
Medida Taxi: Unidades dadas por el taxímetro.
Desviación Xi: Diferencia entre las medidas de TwTaxi y el taxímetro del vehículo.
Desviación al
Medida TwTaxi Medida Taxi Desviación Xi Desviación Media Xi- 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
84
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:
85
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:
86
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:
87
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.
88
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.
Curva Nomal del Error

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
-0,5
-1
Desviación Máxima
-1,5
-2
Desviación
-2,5
Polinómica (Desviación)
-3
-3,5
-4
-4,5
Número de Muestras
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.
89
Medida TwTaxi vs. Medida Taximetro
140
120 Medida TwTaxi

Unidades marcadas
100 Medida Taxi
80
60
40
20
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
Número de prueba
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.
90
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
Documentación previa del desarrollo móvil.
20 días 17 días
Sprint 0 Desarrollo de un prototipo inicial de bajo nivel.
Construcción de las historias de usuario.
Sprint 1 Prototipo de las historias de usuario.
20 días 20 días
Modelo de requerimientos.
Modelo de casos de uso.
Sprint 2 Diagrama de clases.
Modelo de base de datos.
31 días 35 días
Verificar y solicitar la activación del GPS.
Mostrar la ubicación del usuario en el mapa.
Iniciar aplicación.
Cargar modelo de tarifa.
30 días 30 días
Sprint 3 Iniciar medición.
Contabilizar y seleccionar recargos.
20 días 15 días
Sprint 4 Calcular valor de la carrera.
Almacenar información del servicio.
25 días 23 días
Sprint 5 Generar informe con los datos del servicio.
Notificar y actualizar modelo de la tarifa.
Sprint 6 Notificar queja en Twitter.
Manual del usuario de la aplicación móvil
30 días 34 días
TwTaxi.
Manual del usuario de la aplicación web
Administrador TwTaxi.
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.
91
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.

92
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).
93
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.
94
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.
95
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.
96
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.
97
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.
98
[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.
[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
99
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.
[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.
100
[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,
101
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.
102
[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.
103
ANEXOS
104
ANEXO A: DIAGRAMAS DE SECUENCIA
Diagrama de Secuencia: Iniciar Medición
sd Iniciar Medición
InicioApp «thread» taximetro:Taximetro servicio:Servicio medición:Medición

tt:TimerTask
Usuario
actionBtnIniciarServicio()
iniciarServicio(velocidad)
iniciarMedicion(velocidad)
aumentarUnidad()
insertarRegistros(velocidad)
Figura 34. Diagrama de Secuencia: Iniciar Medición. Fuente: Elaboración Propia.
105
Diagrama de Secuencia: Calcular Tarifa
sd Calcular Tarifa
taximetro:Taximetro sqLiteOpenHelper:SQLiteOpenHelper resumenApp:ResumenApp parse:Parse

InicioApp
Usuario
actionBtnDetenerServicio()
seleccionarRecargos()
mostrarRecargos(Activity): List <Tarifa>
listarRecargos(): List <Tarifa>
mostrarTarifa (Activity ): List<Tarifa>
listarTarifas(): List <Tarifa>
calculartotalAPagar()
guardarTablaResumen()
mostrarTablaResumen()
Figura 35. Diagrama de Secuencia: Calcular Tarifa. Fuente: Elaboración Propia.
106
Diagrama de Secuencia: Actualizar Tarifa
sd ActualizarTarifa
taximetro:Taximetro sqLiteOpenHelper:SQLiteOpenHelper parse:Parse
eliminarTarifas ()
eliminarTarifa()
cargarTarifa()
guardarTarifa()
Figura 36. Diagrama de Secuencia: Actualizar Tarifa.

107
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.

108
ANEXO C: PRUEBAS
Subsistema o Mostrar la ubicación del usuario en el mapa.
Función
2015
2015
Nombre
Caso Prueba 006
Objetivo Verificar que al abrir la aplicación el sistema le muestre al
usuario, mediante un mapa, el lugar donde se encuentra.
Precondiciones de la El usuario tiene acceso a Internet y tiene el GPS activo.
prueba
El sistema obtiene las coordenadas de localización del

dispositivo móvil y mediante un círculo azul, muestra la
Resultados
posición del usuario.
esperados
Resultados Al abrir la aplicación se le muestra al usuario el lugar donde
Obtenidos se encuentra.
Si 2015
Comentarios El tiempo que tarda el sistema en mostrar el mapa es del

Tabla 24. Formato de caso de prueba: Mostrar la ubicación del usuario.
109
Subsistema o Iniciar aplicación.
Función
2015
2015
Nombre
Caso Prueba 007
Objetivo Verificar que se inicialicen correctamente los cinco
contadores.
prueba La tabla tarifa existe y es vigente.
2. El sistema deshabilitó el botón “Siguiente”.
Resultados El sistema inicializa los contadores de: tiempo, velocidad,
esperados unidades de arranque y valor de la carrera.
Resultados Al abrir la aplicación cada uno de los contadores se inicializa
Obtenidos en su respectiva unidad.
Si 2015
Comentarios
Tabla 25. Formato de caso de prueba: Iniciar aplicación.
Subsistema o Calcular valor de la carrera.
Función
2015
110
2015
Nombre
Caso Prueba 008
Objetivo Verificar que efectivamente se suma el valor de la tarifa
básica con el valor total de recargos.
prueba 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.
Resultados El sistema suma el valor de la tarifa básica con el valor total

esperados de los recargos.
Resultados El sistema incrementa el valor total de la carrera cuando se le
Obtenidos aplican recargos al recorrido.
Si 2015
Comentarios
Tabla 26. Formato de caso de prueba: Calcular valor de la carrera.
Subsistema o Almacenar información del servicio.
Función
2015
2015
Nombre
Caso Prueba 009
Objetivo Verificar que al finalizar el servicio se almacenen los datos en
Parse.
prueba
111
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.
Resultados Una vez se detiene el recorrido el sistema almacena los datos
esperados del servicio en Parse.
Resultados Se ha consultado la base de datos del servidor y
Obtenidos efectivamente quedan registrados los datos del servicio.
Si 2015
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.
Subsistema o Generar informe con los datos del servicio.
Función
2015
2015
Nombre
Caso Prueba 0010
Objetivo Verificar que al detener el recorrido se muestre una tabla en
el que el usuario pueda ver un resumen de la carrera.
prueba
Pasos de ejecución Una vez se terminaron de seleccionar los recargos se dio
click en “Datos de la carrera”.
Resultados El sistema muestra una tabla en el que se le muestra al
esperados usuario un resumen del servicio.
Resultados Al dar click en datos de la carrera, se muestra una tabla, la
Obtenidos cual indica: fecha, hora de servicio, unidades marcadas,
duración, distancia, costo total de la tarifa básica, costo total
112
de los recargos causados y total a pagar.

Si 2015
Comentarios
Tabla 28. Formato de caso de prueba: Generar informe con los datos del servicio.
Subsistema o Cargar modelo de tarifa.
Función
2015
2015
Nombre
Caso Prueba 0011
Objetivo Verificar que al abrir la aplicación, por primera vez, se
carguen los datos de Parse a SQLite.
prueba 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.
Resultados La aplicación carga los datos que se encuentran en Parse y
esperados los guarda en la base de datos local SQLite.
Resultados Al abrir la aplicación por primera vez el sistema carga los
Obtenidos datos que se encuentran en Parse.
113
Si 2015
Comentarios El tiempo que tarda el sistema en cargar las tarifas es del

Tabla29. Formato de caso de prueba: Cargar modelo de tarifa.
114
ANEXO D: VALIDACIÓN
Figura 38. Curvas de Operación Características. Fuente: [68].
115
Tabla 30. Distribución T-Student. Fuente [68].
116

BabativaGoyenecheAngélicaMaría2017 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

BabativaGoyenecheAngélicaMaría2017 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

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

ANGÉLICA MARÍA BABATIVA GOYENECHE

PAULA DANIELA BRICEÑO NOVOA

MSc. ALBA CONSUELO NIETO LEMUS

MSc. OMAR SALAZAR MORALES

UNIVERSIDAD DISTRITAL FRANCISO JOSÈ DE CALDAS

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

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

Para ellos: Muchas gracias y que Dios los bendiga.

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.1 OBJETIVO GENERAL .................................................................................... 4

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

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

2.3.1 TAXI 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 DESARROLLO DEL SPRINT 1 ........................................................................... 35

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 DESARROLLO DEL SPRINT 2 ........................................................................... 58

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

3.5 DESARROLLO DEL SPRINT 3 ........................................................................... 66

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

3.6 DESARROLLO DEL SPRINT 4 ........................................................................... 68

3.7 DESARROLLO DEL SPRINT 5 ........................................................................... 68

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.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