Integración de tecnologías cloud, web y móvil aplicadas en ...
70
Integración de tecnologías cloud, web y móvil aplicadas en el sector del transporte público- Taxis Proyecto de grado Presentado al Departamento de Ingeniería de Sistemas y Computación Por Carlos Esteban Duque Fernando Hurtado Asesor José Tiberio Hernández Ingeniería de Sistemas y Computación Universidad de los Andes Junio de 2013
Transcript of Integración de tecnologías cloud, web y móvil aplicadas en ...
Integración de tecnologías cloud, web y móvil aplicadas en el sector del transporte público-
Taxis
Proyecto de grado
Presentado al
Departamento de Ingeniería de Sistemas y Computación
Por
Carlos Esteban Duque
Fernando Hurtado
Asesor
José Tiberio Hernández
Ingeniería de Sistemas y Computación
Universidad de los Andes
Junio de 2013
1
2
Integración de tecnologías cloud, web y móvil
aplicadas en el sector del transporte público-
Taxis
Abstract El sector de taxis en Bogotá se encuentra en un momento crítico. Los modelos de negocio tradicionales
son cada vez menos atractivos y la disminución de los costos de tecnologías cloud y móvil ha promovido
el surgimiento de nuevas empresas con propuestas tecnológicas innovadoras en busca de reemplazar a las
empresas de taxis. El texto propone una arquitectura para lograr un sistema de solicitud de taxi, despacho
y enrutamiento de llamadas eficiente. Partiendo del caso de estudio de la empresa Teleclub, se presenta
un contexto del problema general, seguido de la solución tecnológica junto con los distintos patrones
utilizados. A continuación se muestran resultados de las pruebas realizadas sobre el software
implementado, buscando garantizar los atributos de calidad requeridos por la naturaleza del negocio.
Finalmente, un plan de negocio muestra cómo a partir de la solución tecnológica planteada, puede surgir
un negocio sostenible y potencialmente escalable.
3
Introducción
Motivación
Hace alrededor de 1 año, Carlos Esteban Duque y Fernando Hurtado Cárdenas decidieron tomar un
camino alternativo. Ellos decidieron que querían crear empleo. Esto por supuesto significa innovar y
emprender, es decir crear empresa basada en innovación tecnológica.
Apasionados por el mundo de las tecnologías móviles y web se propusieron empezar un proyecto que,
utilizando dichas tecnologías, lograría formar una empresa antes de graduarse. Rápidamente y después de
un par de fracasos, se dieron cuenta que necesitaban una metodología estricta para lograr el éxito de su
emprendimiento.
La metodología que adoptaron es lo que Eric Ries propone en su libro ‘The Lean Startup’ la
cual es basada en el ‘Customer Development’ de Steve Blank y Bob Dorf. Esta metodología les permitió
fracasar más rápido lo cual significó poder aprender de sus errores de forma más rápida y estructurada.
Empezando con redes sociales basadas en imágenes, pasando por marketplaces de materiales estudiantiles
hasta CRM para pequeños retailers, finalmente encontraron un problema relevante, el cual tiene
potenciales clientes dispuestos a pagar por él.
Este texto es el resultado de los varios fracasos que Fernando y Carlos tuvieron que pasar para entablar
una relación con la empresa Distribuidora Teleclub y muestra cómo las tecnologías Cloud, Web y Móvil
pueden ser utilizadas para resolver un problema de una
empresa en el sector del transporte público.
4
Contenido Abstract ......................................................................................................................................................... 2
Introducción .................................................................................................................................................. 3
Motivación ................................................................................................................................................ 3
Planteamiento del Problema .................................................................................................................... 8
Objetivos ................................................................................................................................................... 8
Objetivo General ................................................................................................................................... 8
Objetivos específicos ............................................................................................................................ 8
Estructura del documento .................................................................................................................... 8
Contexto ........................................................................................................................................................ 9
Sector de taxis en Bogotá ......................................................................................................................... 9
Caracterización de los conductores ........................................................................................................ 10
Caracterización general....................................................................................................................... 10
Tecnologías ............................................................................................................................................. 14
Heroku ................................................................................................................................................. 14
Ruby on Rails ....................................................................................................................................... 14
Phonegap ............................................................................................................................................ 15
GCM .................................................................................................................................................... 16
Procedimiento ............................................................................................................................................. 16
Caso de Estudio: Distribuidora Teleclub S.A. .......................................................................................... 16
Yipiex ................................................................................................................................................... 16
Actores ................................................................................................................................................ 17
Propuesta de Solución ............................................................................................................................ 20
Taxi Gol ................................................................................................................................................ 20
Propuesta Tecnológica ................................................................................................................................ 20
Arquitectura de la solución ..................................................................................................................... 24
Arquitectura general del sistema ........................................................................................................ 24
Arquitectura del Taxista ...................................................................................................................... 27
Pruebas ....................................................................................................................................................... 39
Escenario de Pruebas 1 ........................................................................................................................... 39
Prueba 1: actualizar la posición de un taxi ......................................................................................... 39
Prueba 2: escalabilidad del servidor ................................................................................................... 41
5
Escenario de Pruebas 2 ........................................................................................................................... 42
Prueba 3: Carga mediana .................................................................................................................... 42
Prueba 4: Carga alta ............................................................................................................................ 43
Escenario de pruebas 3 ........................................................................................................................... 44
Prueba 4: Carga alta con puma ........................................................................................................... 44
Conclusión ........................................................................................................................................... 46
Pruebas de aceptación ............................................................................................................................ 46
Plan de negocios ......................................................................................................................................... 47
Resumen ejecutivo .................................................................................................................................. 47
Objetivos ............................................................................................................................................. 48
Misión ................................................................................................................................................. 48
Destacados .......................................................................................................................................... 48
Resumen de la compañía ........................................................................................................................ 49
Estrategia de la compañía ................................................................................................................... 49
Riesgos ................................................................................................................................................ 49
Propuesta de valor .............................................................................................................................. 49
Resumen del análisis de mercado ........................................................................................................... 50
Segmentación de mercado ................................................................................................................. 50
Competencia y patrones de compras ................................................................................................. 51
Resumen de estrategia e implementación ............................................................................................. 52
Estrategia de ventas ............................................................................................................................ 52
Estrategia de mercadeo ...................................................................................................................... 52
Alianzas estratégicas ........................................................................................................................... 52
Plan financiero ........................................................................................................................................ 52
Ingresos ............................................................................................................................................... 53
Egresos ................................................................................................................................................ 54
Estados Financieros Proyectados ........................................................................................................ 56
Discusión ..................................................................................................................................................... 62
Conclusión ............................................................................................................................................... 62
Trabajo a futuro ...................................................................................................................................... 62
Bibliografía .................................................................................................................................................. 64
Anexos ......................................................................................................................................................... 66
6
Índice de Figuras FIGURA 1. MODELO DEL PROBLEMA ..................................................................................................................................... 18
FIGURA 2. ARBOL DE UTILIDAD ............................................................................................................................................ 21
FIGURA 3. DESPLIEGUE DE LA SOLUCIÓN................................................................................................................................ 24
FIGURA 4. DIAGRAMA DE DESPLIEGUE VISUAL ........................................................................................................................ 26
FIGURA 5. EL BUS DE EVENTOS. ........................................................................................................................................... 28
FIGURA 6. PATRÓN DE SINCRONIZACIÓN PARA ANDROID .......................................................................................................... 31
FIGURA 7. DIAGRAMA GENERAL DEL SERVIDOR ....................................................................................................................... 32
FIGURA 8. DIAGRAMA DE LOS CONTROLADORES ..................................................................................................................... 33
FIGURA 9. DIAGRAMA DE LOS MODELOS DEL SERVIDOR ............................................................................................................ 34
FIGURA 10. DIAGRAMA DE COMPONENTE APLICACIÓN DEL USUARIO. ......................................................................................... 36
FIGURA 11. TIEMPO EN COLA PROMEDIO POR REQUEST POR MINUTO EN HTTP POST A /POSITIONS.JSON ........................................ 40
FIGURA 12. TIEMPO PROMEDIO DE EJECUCIÓN EN LA BASE DE DATOS DE UN HTTP POST A /POSITIONS.JSON .................................... 40
FIGURA 13. TIEMPO PROMEDIO QUE TARDA UN HTTP POST A POSITIONS.JSON EN SER EJECUTADO POR RUBY .................................. 41
FIGURA 14. TIEMPO PROMEDIO DE RESPUESTA POR NÚMERO DE THREADS. ................................................................................. 43
FIGURA 15. TIEMPO DE RESPUESTA PROMEDIO VS NÚMERO DE THREADS, CON CARGA ALTA: PUMA .................................................. 45
FIGURA 16. COMPARACIÓN ENTRE LOS SERVIDORES WEB PUMA Y UNICORN. ............................................................................... 46
FIGURA 17. MAPA APLICACIÓN DEL TAXISTA .......................................................................................................................... 67
FIGURA 18. NOTIFICACIÓN DEL BOTÓN DE PÁNICO .................................................................................................................. 68
FIGURA 19. CREACIÓN DE UN ICONO EN EL MAPA ................................................................................................................... 68
FIGURA 20. SERVICIOS DE TAXIS RECIBIDOS. ........................................................................................................................... 69
Índice de Tablas TABLA 1. DISTRIBUCIÓN DE CONDUCTORES POR ESTRATO ......................................................................................................... 10
TABLA 2. DISTRIBUCIÓN DE TAXISTAS POR NIVEL DE ESTUDIOS ................................................................................................... 10
TABLA 3. PORCENTAJE DE DISTRIBUCIÓN DE RADIOTELÉFONOS ................................................................................................... 11
TABLA 4. INGRESOS PROMEDIO POR RADIOTELÉFONO .............................................................................................................. 12
TABLA 5. VENTAJAS Y DESVENTAJAS DEL USO DE DISPOSITIVOS PARA TAXISTAS .............................................................................. 13
TABLA 6. ACTORES DEL PROBLEMA ....................................................................................................................................... 18
TABLA 7. FLUJO DE INFORMACIÓN EN EL PROCESO DE SOLICITUD DEL SERVICIO ............................................................................. 19
TABLA 8. ATRIBUTO DE CALIDAD: LATENCIA Y ESCALABILIDAD ................................................................................................... 22
TABLA 9. ATRIBUTO DE CALIDAD: DISPONIBILIDAD .................................................................................................................. 23
TABLA 10. DESCRIPCIÓN DEL DIAGRAMA DE DESPLIEGUE GENERAL DE LA SOLUCIÓN ....................................................................... 26
TABLA 11. DESCRIPCIÓN DEL DIAGRAMA DE DESPLIEGUE VISUAL ................................................................................................ 27
TABLA 12. TABLA DE DESCRIPCIÓN DEL BUS DE EVENTOS. ......................................................................................................... 28
TABLA 13. DESCRIPCIÓN DE LOS COMPONENTES DE PATRÓN. .................................................................................................... 32
TABLA 14. TABLA DE CONTROLADORES ................................................................................................................................. 34
TABLA 15. TABLA DE DESCRIPCIÓN DE LOS MODELOS. .............................................................................................................. 35
TABLA 16. DESCRIPCIÓN DEL PACKAGE PRESENTER .................................................................................................................. 37
TABLA 17. DESCRIPCIÓN DEL PACKAGE UIHANDLER ................................................................................................................ 37
TABLA 18. DESCRIPCIÓN DEL PACKAGE SERVICES .................................................................................................................... 37
TABLA 19. DESCRIPCIÓN DEL PACKAGE MODEL ....................................................................................................................... 38
TABLA 20. ESCALABILIDAD DEL SERVIDOR .............................................................................................................................. 41
7
TABLA 21. TIEMPO DE RESPUESTA PROMEDIO DE ENVÍO DE SOLICITUD. ....................................................................................... 43
TABLA 22. CAMBIOS EN TIEMPO DE RESPUESTA POR NÚMERO DE THREADS. ................................................................................. 44
TABLA 23. CARGA ALTA CON PUMA, TIEMPO DE RESPUESTA PROMEDIO ...................................................................................... 45
TABLA 24. ESTADÍSTICAS DEL TAMAÑO DE MERCADO ............................................................................................................... 50
TABLA 25. ANÁLISIS DE MERCADO ....................................................................................................................................... 51
TABLA 26. VARIABLES PROYECCIÓN VENTAS. .......................................................................................................................... 53
TABLA 27. INGRESOS ESCENARIO PESIMISTA .......................................................................................................................... 53
TABLA 28. INGRESOS ESCENARIO PROBABLE ........................................................................................................................... 54
TABLA 29. INGRESOS ESCENARIO OPTIMISTA .......................................................................................................................... 54
TABLA 30. EGRESOS ESCENARIO PESIMISTA ............................................................................................................................ 55
TABLA 31. EGRESOS ESCENARIO PROBABLE ............................................................................................................................ 55
TABLA 32. EGRESOS ESCENARIO OPTIMISTA ........................................................................................................................... 55
TABLA 33. ESTADO DE PÉRDIDAS Y GANANCIAS ESCENARIO PESIMISTA. ........................................................................................ 56
TABLA 34. ESTADO DE PÉRDIDAS Y GANANCIAS ESCENARIO PROBABLE. ........................................................................................ 57
TABLA 35 .ESTADO DE PÉRDIDAS Y GANANCIAS ESCENARIO OPTIMISTA. ....................................................................................... 57
TABLA 36 .BALANCE GENERAL ESCENARIO PESIMISTA ............................................................................................................... 58
TABLA 37. BALANCE GENERAL ESCENARIO PROBABLE ............................................................................................................... 59
TABLA 38. BALANCE GENERAL ESCENARIO OPTIMISTA .............................................................................................................. 60
TABLA 39. FLUJO DE CAJA LIBRE ESTADO PESIMISTA ................................................................................................................. 60
TABLA 40. FLUJO DE CAJA LIBRE ESTADO PROBABLE ................................................................................................................. 61
TABLA 41. FLUJO DE CAJA LIBRE ESTADO OPTIMISTA ................................................................................................................ 61
TABLA 42. TIR SEGÚN EL ESCENARIO. ................................................................................................................................... 61
8
Planteamiento del Problema
Por la naturaleza poco común de este trabajo hay dos problemas grandes que se desean resolver. El primer
problema consiste en encontrar una necesidad insatisfecha (o lo que Ramfetl, Kjellberg, & Kosnik
(2011) llaman un ‘pain’) en alguna industria y/o empresa y utilizar tecnología para proponer una solución
innovadora a dicho problema. Innovación en este sentido implica el uso de herramientas y conocimientos
de ingeniería para que la solución sea poco replicable. Implica también que la solución propuesta debe ser
práctica y debe poder resolver un problema real.
El segundo problema, o más bien la instancia del problema general pertenece a las empresas de taxi. Las
empresas de taxi obtienen ingresos principalmente de cobrarle a los taxistas una mensualidad por tener
acceso a un radio-teléfono y/o un gps. Es a través de estos dos medios que los taxistas pueden recibir las
llamadas y son una fuente de ingreso importante para ellos. Estos dispositivos son costosos y poco
eficientes. Adicionalmente, hace alrededor de 4 meses, en Bogotá han empezado a surgir empresas como
Tappsi e Easy Taxi que no solamente resuelven las falencias de los dispositivos ya mencionados sino que
están efectivamente reemplazando a las empresas de taxi. El problema entonces consiste en cómo lograr
que las empresas puedan competir ante las amenazas recientes y mejorar su propuesta tecnológica para
los taxistas.
Objetivos
Objetivo General
El objetivo general de este proyecto de tesis consiste en plantear, diseñar y desarrollar una herramienta
que pueda resolver el problema de ineficiencia e ineficacia de los sistemas de comunicación tradicional de
los taxis.
Objetivos específicos
Tomando la empresa Teleclub como caso de estudio se buscará desarrollar un sistema para resolver las
necesidades expresadas por la empresa. En particular se desea lo siguiente:
● Determinar las necesidades específicas de la empresa para poder producir un conjunto de
requerimientos funcionales.
● Producir un documento de diseño y arquitectura de la solución que muestre:
○ Las principales necesidades del negocio.
○ Los principales inconvenientes técnicos.
○ Un diseño a alto nivel donde se pueda reflejar como son satisfechas las distintas
necesidades del negocio junto con los inconvenientes técnicos.
● Los resultados de las pruebas hechas sobre el sistema para verificar que cumpla con las
necesidades planteadas con la empresa.
Estructura del documento
9
El documento se divide principalmente en 5 secciones, la primera siendo la introducción que muestra la
razón de ser del proyecto, explica en alto nivel el problema que se busca resolver y plantea objetivos
específicos sobre la solución y cómo será resuelto dicho problema.
La segunda sección, el ‘Contexto’, habla del contexto del mercado de taxis en bogotá. Muestra varias
cifras en relación al mercado y caracteriza a los distintos actores incluyendo las principales empresas que
están surgiendo como competencia para el proyecto. Finalmente se mencionan las distintas herramientas
tecnológicas que fueron utilizadas durante la implementación de los distintos prototipos y finalmente de la
primera versión del sistema.
La tercera sección explica el caso de estudio de la empresa Distribuidora Teleclub. Empieza explicando
cómo es su operación típica y los principales problemas que presenta. Describe la solución tecnológica
propuesta, relacionando los distintos elementos de negocio con los features o requerimientos funcionales
propuestos. Finalmente muestra una arquitectura a alto nivel de la solución propuesta incluyendo
resultados de la implementación del sistema.
La última sección ‘Resultados y Discusión’ muestra los resultados de las distintas pruebas hechas sobre la
infraestructura. Finalmente la sección de discusión hace una conclusión sobre el proyecto de tesis y habla
de los siguientes pasos del proyecto.
Contexto
Sector de taxis en Bogotá En la ciudad de Bogotá, D.C. hay más de 50,000 taxis, según Rodríguez & Acevedo (2012), los taxis
generan ingresos 2.4 veces más que el TransMilenio y además ocupan el 32% de la red vial Bogotana.
Según el estudio realizado por Rodríguez & Acevedo (2012), las personas se sienten indiferente a utilizar
una empresa u otra de taxi. En el mes de noviembre del 2011 una de las empresas de taxis en Bogotá
presentó un proyecto en donde se brindaban unas tabletas con tecnología Android, en donde se ofrecía el
GPS y se podían crear solicitudes directas en éste. Según el último listado de movilidad del SIM en
Bogotá hay 58 empresas de taxis constituidas (SIM, s.f) de las cuales 2 empresas cuentan con más del
50% de participación en el mercado.
El primer semestre del año 2013 ha mostrado un incremento fuerte de aplicaciones móviles para taxistas,
en particular se pueden destacar la brasileña EasyTaxi y la empresa bogotana Tappsi. Las dos
aplicaciones ofrecen el mismo servicio, la posibilidad de hacer solicitud de un servicio de taxi para los
pasajeros por medio de una aplicación móvil, y a los taxistas se les ofrece una aplicación móvil diferente
para obtener las solicitudes y aceptarlas o rechazarlas. Además el usuario-pasajero puede hacer
seguimiento desde la aplicación a los taxistas. Los taxistas a su vez pueden ubicar al futuro pasajero en un
mapa. Adicionalmente, Tappsi ofrece la posibilidad de hacer uso de las redes sociales y/o el correo para
compartir la información de los taxistas con el objetivo de aumentar la seguridad del pasajero.
10
Easy Taxi a diferencia de Tappsi se encuentra en 8 países latinoamericanos, además en el año 2012 tuvo
una inversión de serie A de R$10 millones de la empresa Rocket Internet (Remus, 2012). Lo anterior
significa que EasyTaxi tiene una potencial ventaja por tener acceso a capital.
Caracterización de los conductores Los conductores son uno de los actores más importantes dentro del sistema de taxis en Bogotá no solo
porque operan el vehículo, sino porque recaudan el dinero, atienden a los clientes, se encargan del aseo y
son la principal fuente de ingresos para el dueño del taxi o la empresa de taxis. Con base en el estudio de
Rodriguez & Acevedo (2012) en ¡Taxi! - el modo olvidado de la movilidad en Bogotá se mostrará una
caracterización de los taxistas.
Caracterización general
Tamaño del segmento: Se estima que hay alrededor de 59.000-60.000 taxistas/conductores (Rodriguez
& Acevedo, 2012)
Horas de Trabajo: El taxista promedio trabaja 13.8 horas al día
Distribución por estratos: La tabla 1 muestra la distribución de conductores por estrato socioeconómico.
Estrato %
1 2,3
2 40,5
3 50,3
4 6,0
Tabla 1. Distribución de conductores por estrato
Nivel educativo: Los taxistas son en general educados, algunos tienen estudios superiores, sin embargo
cerca al 30% no tienen bachillerato, incluso hay algunos que no saben leer ni escribir, como muestra la
Tabla 2.
Estudios %
Sin bachillerato 31,0
Bachiller 49,0
Estudios superiores 20,0
Tabla 2. Distribución de taxistas por nivel de estudios
11
Utilización de tecnología
Una de las fuentes de ingreso principales de los conductores consiste en la demanda de “despachos”. En
este segmento, los potenciales pasajeros piden taxis por 3 medios principalmente: web, teléfono fijo, y
móvil. El medio se encarga de llegar a la operadora de los taxis la cual utiliza el radio teléfono u otro
medio para comunicarse con los taxistas. A continuación se muestran los distintos medios tradicionales
por los cuales la operadora o central de taxis logra despachar el pedido de taxi.
Radioteléfono
El radioteléfono o servicio de comunicación por voz es el medio predominante. Alrededor del 57% de las
taxis utilizan por lo menos una frecuencia de radioteléfono1. Los taxistas que manejan de noche lo utilizan
en un 86,3%. Algunas empresas prohíben a los taxistas tener más de un sistema, otras les permiten tener
varios.
El uso de radioteléfono varía principalmente por dos variables: La edad y las horas en que trabajan. En
general los conductores jóvenes utilizan más radioteléfonos y la probabilidad de que un conductor tenga
por lo menos un radioteléfono disminuye a medida que avanza la edad. Esto se debe a que la utilización
de estos sistemas no es una tarea trivial, requiere de concentración y multi-tasking, sobre todo cuando hay
varios radioteléfonos.
Las empresas de comunicación, que no necesariamente son distintas a las empresas de taxis, dividen a sus
suscriptores en distintas frecuencias las cuales pueden llegar a tener entre 500 y 800 taxistas.
Número de
radioteléfonos
%
1 40,3%
2 14,2%
3 2,4%
Tabla 3. Porcentaje de distribución de radioteléfonos
Como muestra la Tabla 3 hay un gran porcentaje de taxistas que no utiliza radioteléfono, sin embargo los
estudios realizados por Rodríguez y Acevedo (2012) demuestran que hay una correlación entre los
ingresos del taxista y el número de radioteléfonos.
Número de radiotélfonos Ingreso promedio diario (COP)
0 135.061
1 Esta cifra es tomada de ¡Taxi! - el modo olvidado de la movilidad en Bogotá (Rodriguez & Acevedo, 2012). Si
bien es muy posible que el número exacto haya disminuido en los últimos años, es probable que se mantenga por encima del 50%, afirma Ernesto Sandoval, gerente de Teleclub.
12
1 145.563
2 157.500
3 182.500
Tabla 4. Ingresos promedio por radioteléfono
GPS - Satelital
El sistema de GPS, Satelital o comunicación por datos consiste en equipar al taxi con un dispositivo
electrónico a veces llamado “Sistema Automático de Localización y Despacho de Taxis basado en GPS”.
Este dispositivo cuenta con un GPS y un módem GPRS el cual es capaz de albergar una SIM. Esto le
permite al taxista no solo reportar su ubicación sino hacer transmisión de datos como el estado del taxi
(ocupado/disponible).
La principal ventaja de este servicio comparada con el servicio de voz es que cada taxista tiene un canal
dedicado y la posibilidad de reservar carreras.
Ventajas y Desventajas
Radioteléfono GPS - Satelital
● Canal público
● La frecuencia puede ser interceptada
● Genera competencia interna
● Difícil de usar, aumenta la dificultad
con la edad
● Curva de aprendizaje elevada
● Estrés, irritabilidad, molestia
● Puede incomodar al conductor
● Carece de información geográfica
● Tiempos de espera reducidos para el cliente
● No hay competencia
● Los canales no son interceptables
● No se ha demostrado, pero Acevedo y Rodríguez
afirman que el GPS puede generar ahorro en
combustible, e incrementar los ingresos de los
conductores.
● Es más seguro para el cliente dado que el canal no es
interceptable
● No existe el riesgo de la "vacunada", ni hay
competencia interna
● Costo elevado del dispositivo
● Costo de la mensualidad elevada
● Dependen de otros servicios como la red celular y el
servicio satelital (si alguno de estos se cae, el taxista
puede perder dinero)
● El concepto de turnarse: la forma como estos sistemas
detectan si un taxista está disponible es si está
moviéndose, luego los taxis deben estacionarse para
buscar un servicio.
● Cambia los procesos administrativos tradicionales de
las empresas de taxis
13
Tabla 5. Ventajas y desventajas del uso de dispositivos para taxistas
Estrategias utilizadas por los conductores
Hay varias formas en que los taxistas pueden obtener ingresos. A continuación se presentan las 5
estrategias principales que utilizan los taxistas para conseguir pasajeros.
● Caso 1:
○ El conductor deja a su actual pasajero
○ El conductor está atento al radioteléfono
○ El conductor circula en busca de pasajeros
○ El conductor entra en “competencia abierta” en la calle
○ El conductor consigue un nuevo pasajero
● Caso 2
○ Deja a su actual pasajero
○ Atento al radioteléfono
○ Se estaciona
○ Espera despacho por el radio
○ Competencia cerrada en la calle
● Caso 3
○ Deja a su actual pasajero
○ Se estaciona
○ Se pone en turno con el GPS
○ Sin competencia orden de llegada
○ Consigue su nuevo pasajero
● Caso 4
○ Deja el pasajero
○ Se estaciona
○ Hace fila en una zona amarilla, centro comercial, terminal de transportes, etc.
○ Sin competencia, orden de llegada
○ Consigue pasajero
● Caso 5
○ Deja el pasajero
○ Circula en busca de pasajeros
○ Competencia abierta en la calle
○ Consigue nuevo pasajero
Es de particular interés notar que las estrategias que hacen uso de GPS deben estacionarse, lo cual les
impide estar en ‘competencia abierta’.
Es de interés también mostrar que si bien la alternativa 5 es la más económica, los resultados de
Bohórquez y Acevedo (2012) demuestran que es inferior a otras estrategias. Sin embargo es necesario
decir que las distintas estrategias son utilizadas en distintas horas del día y en distintos días a la semana.
14
Es muy raro encontrar un taxista que utilice solamente una estrategia dado que la demanda varía mucho y
las distintas estrategias funcionan mejor en distintos momentos.
Tecnologías
A continuación se presenta una lista de las principales tecnologías utilizadas y la razón de ser de cada
una. El objetivo de esta sección es de justificar el uso de cada tecnología, explicar su uso dentro del
proyecto así como de también mostrar sus principales debilidades y cómo podrían afectar al proyecto.
Heroku
Es una plataforma como servicio (PaaS) utilizada para el despliegue de taxigol. Heroku tiene un modelo
de negocio freemium, que incluye base de datos y servidor web preconfigurado. Heroku se hace conocer
como una herramienta que ayuda a los desarrolladores a no perder el tiempo en el despliegue de la
aplicación y se concentren principalmente en el desarrollo de esta.
La importancia de Heroku en el despliegue de una aplicación es que el servicio de plataforma esta dado
por ellos, lo que significa que uno no le dedica tiempo a la configuración de la máquina para que corra la
aplicación que se está desarrollando. Toda comunicación con el servidor en donde se realiza el despliegue
y la corrida del servidor/aplicación se hace por medio de líneas de comando. Además Heroku se encarga
de ejecutar, obtener las dependencias de la aplicación, compilar y generar el producto con la
configuración requerida. El servicio de Heroku brinda un dominio público en donde se puede acceder.
Heroku, se puede comparar con otras empresas que brindan el servicio de de despliegue de aplicaciones
en la nube, tales como Amazon Web Service (AWS), pero se diferencia en el hecho de que Heroku
provee las herramientas para que no sea necesario configurar la máquina para el despliegue de la
aplicación. Un ejemplo es, supongamos que se desarrolló un servidor en el marco de Ruby on Rails, en
donde los plugins se les llama gemas, Heroku configura la máquina para correr el lenguaje de Ruby y
desplegarlo además instala las gemas requeridas de tu servidor para que funcione. Por otro lado, en AWS
esa configuración habría sido hecha manualmente por los desarrolladores, lo que significa consumo de
tiempo en otras actividades que no están brindando valor al producto.
Ruby on Rails
Es un framework (marco) open-source (código abierto) desarrollado en el lenguaje de programación de
Ruby. Ruby on Rails (RoR) se basa en patrones y principios de ingeniería reconocidos tales como el,
patrón arquitectural de active-record, el uso del patrón model-view-controller, entre otros (Hartl, 2012).
Ruby ha sido usado por varios startups y empresas grandes tales como Github, Shopify, Twitter, Scribd,
entre otras. En un estudio realizado por TechPower (2013), la latencia de RoR en comparación con otros
frameworks y lenguajes es bastante alta, lo que significa en costos más grandes para operaciones
similares. Según el mismo estudio de TechEmpower (2013), en las peticiones para una sola consulta,
RoR, sobre una base de 100, obtuvo el valor de 8.9 en desempeñó, la latencia fue de 336.7ms en
promedio mientras que el mejor de las plataformas (que no presentó errores en la consulta) fue de 33.5ms.
15
La aplicación del servidor está basado en Ruby on Rails, y hacemos uso del ambiente de desarrollo (IDE)
Rubymine. Esta aplicación es la que se expone en Heroku.
Sin embargo la usabilidad y la agilidad de Ruby on Rails es una ventaja y una razón por la que
seleccionar este marco (Ruby, Thomas, & Hansson, 2011). Como lo exponen Ruby, S., Thomas &
Hansson (2011), uno de los valores del manifiesto ágil es la “Colaboración con el cliente sobre
negociación de contratos” además de “Responder al cambio sobre seguir un plan”. Dicho esto, la relación
entre el desarrollo en el marco de rails y la metodología de Lean Startup, es más visible, porque se
mantiene un contacto con el cliente para el desarrollo del producto además un proceso de desarrollo
iterativo, con cambios (pivotes) durante el proceso, adaptando el producto a las necesidades del mercado.
Phonegap
Es un framework para el desarrollo de plataformas móviles, fue desarrollado por la empresa Nitobi y fue
adquirido por Adobe Systems en el 2011. Phonegap, brinda un marco de desarrollo multiplataforma
haciendo uso del lenguaje de Javascript, HTML y CSS para la lógica, visualización e interacción con la
aplicación. El framework permite que se haga uso de los lenguajes mencionados para que este corra en los
dispositivos como si fuera una aplicación web, y a la vez permite que se haga uso de los sensores del
dispositivo, sin embargo el código no se traduce 100% a código nativo, en cambio hace uso del lenguaje
web y para el uso de sensores se hace una comunicación con los API de estos.
● HTML5, es la quinta versión del lenguaje de marcado de HTML (HiperText Markup Languaje.
En esta versión se elimina viejos atributos que estaban depreciados, y se traen nuevos atributos
que se están viendo más frecuente en la World-wide web tales como los archivos multimedia. El
uso de API y Document Model Object es una parte fundamental de las especificaciones de esta
versión, esto es lo que permite brindar una mejor experiencia con los dispositivos móviles.
● Javascript, es un lenguaje de programación interpretado. Basado en prototipos y uso de funciones
de una sola clase. Javascript se creó con la intención de ayudar en la visualización del cliente en
los navegadores, por lo tanto Javascript está relacionado principalmente con el client-side del
despliegue, aunque este ha ganado un notorio uso en otras partes de las aplicaciones, por ejemplo
del lado del servidor (Server-side Javacsript, SSJS). El uso de javascript en los dispositivos viene
con unos problemas a tener en cuenta en el desarrollo, Javascript no es multi-thread, lo que
significa que puede tener efectos de tiempo en el procesamiento.
● CSS, Cascading Style Sheets es un lenguaje de hojas de estilos usado para describir la
presentación semántica de un documento escrito en lenguaje de marcado, como HMTL5.
La aplicación del usuario-pasajero está desarrollada sobre phonegap. Phonegap permite el despliegue de
la aplicación en diferentes sistemas operativos con el desarrollo de una sola aplicación, además de que no
requiere de obtener conocimiento de los diferentes lenguajes en los que se quiere desplegar la aplicación.
Asimismo, el actual framework brinda los recursos necesarios para brindar la propuesta de valor.
Para las pruebas de phonegap se hace uso de un framework llamado Jasmine, este marco esta basado en
Behavior-Driven development (BDD). Jasmine realiza las pruebas unitarias sobre el lenguaje de
javascript desarrollado en la lógica de la aplicación. Jasmine es un framework que se escoge porque
permite realizar pruebas unitarias sobre la lógica de negocio lo que permite evaluar si la lógica no
presenta errores y los resultados son concisos con lo esperado.
16
GCM
Google cloud messaging, es un servicio que permite enviar datos desde un servidor a usuarios que
cuenten con dispositivos con el sistema operativo de android, al igual que se realice el envió de mensaje
de manera inversa. GCM entra en la competencia con servicios tales como Parser (adquirido por
Facebook) y Pubnub. Estos últimos servicios brindan otras funcionalidades como el envío de mensajes a
dispositivos específicos, permitiendo filtrar por ubicación u otros atributos.
Procedimiento A continuación se introduce el caso de estudio de Distribuidora Teleclub S.A., una empresa de taxis en la
ciudad de Bogotá que ha servido de gran ayuda para el desarrollo del proyecto. Se hace una breve
explicación del contexto general de la empresa, sus principales problemas y preocupaciones. Finalmente,
con base en las necesidades identificadas por Teleclub, se muestra una arquitectura de alto nivel de
Taxigol - la solución de despacho y enrutamiento de llamadas de taxi.
Caso de Estudio: Distribuidora Teleclub S.A. Teleclub es una empresa de taxis con alrededor de 1500 taxistas registrados. Teleclub, como la mayoría
de las empresas de taxis en Bogotá (incluso en Colombia) obtiene sus ingresos de 2 medios. En primer
lugar, cobra un costo mensual a los taxistas por seguros contra accidentes, por ser registrados como
taxistas legalmente ante el estado y otros. La segunda fuente de ingresos proviene de proveer medios de
comunicación para obtención de servicios de taxi como son el radio teléfono y más recientemente la
aplicación móvil Yipiex.
Yipiex
Yipiex es una aplicación móvil que ha sido comercializada durante alrededor de 1 año. Se vende en
conjunto con el HUAWEI Ideos Tablet S7. Fue desarrollada ‘in-house’ por un ex-empleado de teleclub,
actualmente el fundador de Comunidad Taxi. Yipiex como la mayoría de las ‘taxi apps’, provee el
servicio de enrutamiento de llamadas a los taxistas, sin embargo como beneficio adicional, un usuario
puede comunicarse desde su teléfono fijo con el taxista para darle indicaciones adicionales o conocer el
estado del vehículo.
Algunas particularidades de YiPiEx
● En busca de expandir la línea de productos/servicios, DIstribuidora Teleclub adquirió alrededor
de 3.000 tabletas, hay por lo menos 1.000 en inventario.
● Yipiex es una aplicación solamente para el conductor y el único medio de conexión con el usuario
es a través del IVR de la empresa ubicado en el número 5.222.222.
● HUAWEI Ideos Tablet S7 es un tablet con módem GPRS, es decir soporta tanto datos como
llamadas. Esto si bien puede parecer una ventaja, ha resultado ser un costo adicional para la
empresa dado que la aplicación podría funcionar únicamente con datos.
● El Ideos S7 soporta Android hasta 2.2 (inicialmente en 2.1). La mayor limitación sobre android
2.1 es que no soporta GCM, el servicio de PUSH más utilizado y de menor costo (gratis) en el
17
mercado. Esta tecnología es necesaria para realizar los pedidos de taxi de forma eficiente y fácil
aunque existen otras formas de implementar la funcionalidad.
● Algunas especificaciones sobre el hardware:
○ Procesador de 768MHz
○ RAM: 256MB
○ Espacio en Disco: 4GB
○ Cargador propietario (aunque tiene puerto USB)
○ Conectividad: 3G, WiFi & BlueTooth.
Preocupaciones de Teleclub
Teleclub, al igual que todas las empresas grandes de taxis en Bogotá sabe que el futuro de su negocio está
en brindar medios de comunicación eficiente entre usuario y taxista. Al igual que el 80% de las empresas
de taxis, han intentado desarrollar una aplicación in-house. YiPiEx al igual que otras no ha tenido el éxito
esperado.
Para poner más presión sobre la situación, empresas como Tappsi y la multinacional EasyTaxi han
empezado a surgir con propuestas tecnológicas que pueden eventualmente reemplazar a los negocios
tradicionales de las empresas de taxi. Teleclub se ve entonces en la necesidad de lanzar una aplicación
que les permita competir e idealmente aprovechar más de 1.000 dispositivos Ideos S7 en inventario.
Modelo del Problema
Con base en el caso de estudio de la empresa Teleclub se presenta un modelo general del ecosistema de
taxis en la ciudad de Bogotá. A continuación se presentan los principales actores dentro del modelo y las
relaciones entre ellos.A
Para el modelo del problema, hay que considerar los actores, y en un principio la actividad principal de la
solicitud de un servicio de taxi en la manera tradicional.
Actores
Actor Descripción
Empresas operadoras
de taxis
Las empresas operadoras de taxis, son nuestro principal cliente. Estas
presentan problemas, en los tiempos de atención de sus clientes. Y un cambio
en el modelo de negocio, sobre la manera de brindar sus servicios
Competencia Nuevas empresas están ingresando al mercado de taxis. Entre las empresas
encontramos Tappsi e Easy Taxi, las cuales ingresan al mercado por medio de
dos aplicaciones móviles una para los usuarios-pasajeros, que hacen solicitud
del servicio de taxi por medio de una aplicación móvil y otra para los taxistas
que reciben las solicitudes de servicio por su aplicación.
Operadores Son personas o aplicaciones legado que reciben la solicitud de un servicio de
taxi cuando esta solicitud se hace por teléfono.
18
Aplicaciones móviles Como se describe en el bloque de la competencia. Las solicitudes de servicio
de taxi se hace por este medio
Taxi Son los clientes de las empresas operadoras de taxis, y uno de los clientes de
la competencia. Estos actores representan a los taxistas conductores o
propietarios y sus automóviles que prestan el servicio de taxi.
Taxi Gol2 Empresa que busca solucionar los problemas de las empresas tradicionales
operadoras de taxis, brindando herramientas para monitoreo y seguimiento de
los taxistas, además de aumento de la productividad y eficiencia de los
servicios actuales.
Tabla 6. Actores del problema
Figura 1. Modelo del problema
Se va a hacer una descripción de los flujos (las líneas), que pueden ser relacionadas con el nombre o el
número que se le asignó.
Nombre/Número Descripción del flujo
1 Los usuarios para solicitar un servicio de taxi con la competencia, lo
hacen por medio de las aplicaciones móviles de los sistemas operativos
2 No hace parte del problema sino de la solución
19
android o iOS. Esto en comparación con el servicio tradicional es que es
más eficiente porque se eliminan intermediarios en la operación
2 Las aplicaciones móviles se conectan con el servidor y este manda una
notificación de manera masiva (el flujo con línea gruesa de color rojo
representa notificación de manera masiva)
3 Un taxi acepta el servicio
placas, nombre, cel,
ubicación (mapa)
Al usuario que solicitó el servicio de taxi, se le envían los datos del
taxista tales como placas, nombre del taxista, celular y la ubicación del
taxi es representada en un mapa.
4 Representa el miedo que están teniendo las empresas de taxi con respecto
a la competencia. Además se aclara que las compañías operadoras de taxi
no son empresas que desarrollan software.
5 Solicitud de un servicio de taxi por medio llamando a un teléfono fijo.
6 Las operadoras o algún sistema de las operadoras de taxi, notifica de
manera masiva el servicio.
7 Un taxi acepta el servicio respondiendo por medio de radio o por satelital
8 Se le confirma al usuario que aún debe estar esperando por medio del
teléfono fijo
Tabla 7. Flujo de información en el proceso de solicitud del servicio
La Figura 1 modelo del problema, representa el problema que se está atendiendo, el cual se describe de la
siguiente manera:
● La competencia tiene un servicio más eficiente para atender las solicitudes de los servicios de taxi
y responder a los usuarios de manera más rápida que lo hacen las empresas tradicionales. Esto se
debe a que se eliminan los operadores. Igualmente, los usuarios hacen solicitud del servicio desde
sus teléfonos móviles, lo que significa que no deben estar presentes con el teléfono fijo para hacer
la solicitud en cambio reciben respuesta de su solicitud en su celular.
● Las empresas operadoras de taxi tienen miedo ante esta nueva competencia, esto se debe a que
están perdiendo clientela. También, hay que añadir que las empresas tradicionales no son
empresas desarrolladoras de software y a pesar de que han intentado desarrollar aplicaciones
similares a las de la competencia estas no han tenido una buena aceptación en el mercado.
Se ha evidenciado un problema en las empresas operadoras de taxi. Hay una nueva competencia que
ingreso al mercado con unas aplicaciones móviles que cada vez están teniendo mayor aceptación en el
mercado, con casi 75,000 usuarios que se habían descargado la aplicación de Tappsi para Mayo del 2013
(Rosales, 2013) , esto ha generado un miedo en las empresas tradicionales, porque, la competencia ha
demostrado brindar un servicio más eficiente (15-20 segundos promedios para responder a una solicitud),
y además las empresas han intentado ingresar al mercado con aplicaciones similares pero no lo han
podido lograr. Para esto, se desarrollo una propuesta de solución que se presenta a continuación.
20
Propuesta de Solución A continuación se presenta la solución tecnológica al problema de las empresas de taxis en Bogota.
Para atender a la creciente competencia para las operadoras de taxis, y aumentar la productividad de las
empresas operadoras de taxis actuales se ideó un producto compuesto por diferentes aplicaciones que
atienda a estos problemas y necesidades.
Taxi Gol
Taxigol hace referencia al sistema como un todo, el cual incluye el servidor de aplicaciones y la base de
datos principal así como la aplicación que utiliza el taxista y los potenciales pasajeros. A continuación se
describen los requerimientos principales que han sido acordados con Teleclub:
● Brindar una aplicación para los usuarios para pedir un servicio de taxi, y a los taxistas una
aplicación para recibir este pedido. Igualmente, se debe visualizar en los mapas al pasajero y al
taxista, y brindar la información relevante a cada uno según corresponda.
● Implantar un botón de pánico en donde los taxistas puedan solicitar ayuda en caso de encontrarse
en problemas de seguridad o algún accidente.
● Implantar un programa de puntos para los conductores, en donde las empresas den beneficios
económicos según el rendimiento de sus taxistas.
● Mantener estadísticas de los pedidos de taxi, la confirmación, cancelación y no atención de
servicios por taxista y por operadora.
Para esto se deben desarrollar 2 aplicaciones móviles, una para los pasajeros y otra para los taxistas.
Además una aplicación web para el acceso a datos del servidor, el cual es importante para las estadísticas
de rendimiento que deben manejar las empresas operadoras de taxis.
A continuación se presenta la propuesta tecnológica que busca en un periodo de 6 meses poder ser la
solución de comunicación que Teleclub espera y en un mediano a largo plazo ser un proveedor de
tecnología para empresas de taxi en Bogotá y el mundo entero.
Propuesta Tecnológica
La sección siguiente enuncia los atributos no funcionales que Taxigol debe poder satisfacer y presenta
una arquitectura que los satisface.
Árbol de utilidad
El atributo de calidad de mayor importancia es el de latencia. Cuando un usuario desea solicitar un
servicio de taxi es necesario poder atender la solicitud en el menor tiempo posible.
21
Por otro lado, para el funcionamiento del negocio, la disponibilidad del servicio debe ser tal que durante
las horas de 6am a 10pm el sistema esté siempre corriendo y atendiendo servicios. Dicho esto, se
considera, que una disponibilidad del 99.9%, con una caída de 10.1 minutos por semana estaría acorde a
las necesidades del negocio. Es necesario tener en cuenta que un servicio de taxi puede ser solicitado en
cualquier tiempo del día, y la no atención del servicio podría significar en la pérdida de un cliente.
Figura 2. Arbol de utilidad
Atributo de Calidad: Desempeño
Latencia ID Descripción Prioridad
DE_0 Se desea que un
usuario-pasajero
pueda solicitar un
servicio de taxi. El
usuario utiliza el
dispositivo móvil y
selecciona la opción
de solicitar servicio
de taxi. La petición
del servicio debe ser
menor a 2 segundos.
Alta
DE_1 El dispositivo móvil
debe estar en
capacidad de recibir
la información del
servidor por medio
Alta
22
de peticiones http y
almacenarla
localmente en
menos de 1
segundo.
DE_2 Los taxistas pueden
confirmar el servicio
de un taxi en menos
de 1 segundo
después de que este
haya recibido la
notificación
Alta
Escalabilidad
DE_3 El sistema central de
recepción de servicio
debe estar en
capacidad de
registrar hasta 300
consultas
concurrentes en
menos de 5
segundos.
Media
Tabla 8. Atributo de calidad: Latencia y Escalabilidad
Atributo de Calidad: Seguridad
Disponibilidad ID Descripción Prioridad
SE_0 Se debe garantizar
que ante la falla del
servidor central, otra
instancia pueda
continuar
respondiendo las
peticiones sin
pérdida de estado.
Se espera que el
99.99% de las
peticiones hechas al
sistema sean
atendidas (sobre una
Alta
23
base de 2,000
peticiones en 2
minutos).
Tabla 9. Atributo de calidad: Disponibilidad
24
Arquitectura de la solución La siguiente sección muestra la arquitectura de la solución. La sección se divide en cuatro partes.
Primero se hablará de la arquitectura en general, es decir del sistema como un todo. En las siguientes
secciones se centra primero en la arquitectura de la aplicación del pasajero, posteriormente se habla de
la arquitectura de la aplicación del taxista y finalmente del servidor.
Arquitectura general del sistema
A continuación se muestra una vista de alto nivel del despliegue del sistema. El Figura 3 expresa una vista
de alto nivel del despliegue de la aplicación y la Tabla 10 describe la funcionalidad de cada componente y
el ambiente de despliegue.
Es importante notar que hay dos grupos importantes de componentes dentro del despliegue. El primer
grupo corresponde a los componentes Google Cloud Messaging Server y Urban Airship Server. La
principal responsabilidad del primer grupo consiste en permitir la entrega de mensajes push a la
aplicación del taxista.
El segundo grupo contiene a los componentes de despliegue del sistema, es decir el dispositivo móvil
donde es ejecutada la aplicación del taxista, la aplicación del pasajero y finalmente el browser que utiliza
la operadora de la central de taxis.
Figura 3. Despliegue de la solución
25
Componente Descripcción
Google Cloud Messaging
Server Google Cloud Messaging (GCM) es un servicio gratuito ofrecido por google para permitir
comunicación bidireccional entre un dispositivo con android y un servidor en una
arquitectura tradicional cliente servidor.
El servicio funciona de la siguiente forma: Todo dispositivo android (> 2.1)por defecto
viene con la aplicación de Google Play Services instalada. Esta aplicación provee un socket
en modo ‘accept’ el cual utilizando el protocolo XMPP se comunica con el Google Cloud
Messaging Server y es el socket el encargado recibir los mensajes.
Una de las principales ventajas de GCM es que sin importar si la aplicación está siendo
ejecutada, puede recibir mensajes de GCM. Una posible desventaja es que para versiones
de android entre 2.2 y 4.0.4 requiere una cuenta de Google asociada al dispositivo.
Francesco Nerieri, líder del proyecto de GCM afirma en el Google I/O 2012 que el tiempo
de entrega de un mensaje promedio mundial es de 4.7 milisegundos3.
Urban Airship Server Dentro de la arquitectura de GCM es necesario de un servidor intermedio que implemente
el protocolo de autenticación y comunicación expuesto por los servidores de GCM. Urban
Airship es una empresa cuyo propósito consiste en proveer un API sencillo que permita
consumir de forma transparente el servicio de GCM.
Dentro de las responsabilidades de Urban Airship está: 1. Registrar los dispositivos para entablar conexión con el servidor 2. Pasar el mensaje que desea ser enviado a los dispositivos y especificar a cuales
desea ser enviado
Taxigol@Heroku Taxigol@Heroku es el nodo donde reside tanto la base de datos (PostgreSQL) como el
servidor web. El servidor, escrito en Ruby on Rails es ejecutado en la infraestructura de
Heroku, un proveedor de PaaS reconocido por su facilidad de uso.
Actualmente se cuenta con un nodo (dyno) de ejecución. Es probable que para soportar la
carga necesaria sea necesario de un nodo adicional. Cada dyno puede ejecutar máximo un
request a la vez (single-threaded-request-handling).
Operadora El ‘nodo operadora’ corresponde al cliente web (browser) donde la operadora de la empresa
de taxis puede ver los distintos servicios de la aplicación. Se pretende soportar únicamente
IE >= 8, Chromium y Firefox. El nodo, dado que será proveído por la empresa de taxis
tendrá capacidades variables de memoria, disco, sistema operativo, incluso conexión a
internet.
La aplicación si bien no hará uso intensivo de memoria, si requiere de HTML5 para utilizar
los componentes de localización. La conexión de internet debería ser por lo menos de 4MB
para poder coexistir con otras aplicaciones web. Un escenario ideal debería poder permitir
requests entre 100ms y 200ms.
Pasajero La aplicación del pasajero en busca de pedir un taxi. Requiere de un dispositivo con GPS y
HTML5 dado que utiliza PhoneGap.
3 http://commondatastorage.googleapis.com/io2012/presentations/live%20to%20website/100.pdf
26
Taxista La aplicación del taxista requiere de Android >=2.2, un dispositivo con GPS y una
conexión a internet por lo menos 3.5G (HSDPA).
Tabla 10. Descripción del diagrama de despliegue general de la solución
Figura 4. Diagrama de despliegue visual
Componente Descripcción
4
Este icono representa la aplicación de los dispositivos móviles, y los sistemas operativos a
los cuales puede desplegarse la aplicación.
4 Adobe. Phonegap build anywhere [imagen]. Recuperado de https://encrypted-
tbn1.gstatic.com/images?q=tbn:ANd9GcTMD0K2xf-e0ZCnTrY82XMfPXXwjucszzyb7E4-UZa_izJFm3Lu el 24 de mayo del 2013.
27
5
Este icono representa el servidor. En realidad el servidor se encuentra en la nube en la
infraestructura de Heroku.
6
El fondo de la imagen representa el mapa de Bogota. Y se quiere hacer referencia a que la
aplicación funcionaria en un principio en la ciudad de Bogotá.
7
El icono representa la aplicación de los taxistas.
Este icono representa la comunicación, en la imagen, no hay una dirección de la
comunicación, ya que la comunicación es bidireccional. Por lo tanto, las aplicaciones se
comunican con el servidor y el servidor con las aplicaciones a través de Google Cloud
Messaging.
Tabla 11. Descripción del diagrama de despliegue visual
Arquitectura del Taxista
A continuación se detalla la aplicación del servidor. Como se menciona en la sección de atributos de
calidad, la prioridad para la aplicación del taxista consiste en poder recibir de forma eficiente los servicios
de taxi.
Patrón Event Bus
Uno de los principales problemas de diseñar una aplicación móvil es la dificultad de probar los distintos
componentes. El uso de GPS, comunicación remota entre distintos dispositivos y dependencia con
componentes propios de Android, hace que emular el ambiente para realizar las pruebas sea costoso en
términos de tiempo y complejo en términos de diseño.
5 OCAL (2011). Web Virtualization Server [imagen]. Recuperado de http://www.clker.com/clipart-1826.html el 24
de mayo del 2013. 6 Bogota Turismo. Bogota [imagen], recuperado de http://www.mapadecolombia.com.co/10475_mapa-de-bogota-
colombia.html el 24 de mayo del 2013. 7 Dvarg (2011). Car with a laughing face [imagen]. Recuperado de http://www.123rf.com/photo_9892504_car-
with-a-laughing-face-taxi-illustration-on-white.html el 24 de mayo del 2013
28
Figura 5. El bus de eventos.
Componente Descripción
Activity Los Activity an android son un objeto complejo. Por un lado podrían ser interpretados
como el Controller en un MVC clásico, sin embargo también tienen acceso a todos los
componentes nativos del OS como el GPS, recursos de red, acceso al disco, etc. Siempre
que un botón (o un evento en general) es generado por el UI, el activity lo puede capturar y
en este caso crea un nuevo evento el cual es posteado en el EventBus.
Los activity también se registran en el event bus a recibir cierto tipo de eventos.
Layout.xml Android usa archivos xml para describir las vistas de la aplicación. En un MVC tradicional
un layout.xml corresponde al View. Por ser xml, no puede tener lógica y son por defecto
estáticos (similar a HTML).
EventBus El EventBus es el encargado de recibir todos los eventos y notificar a los suscriptores del
evento.
Tabla 12. Tabla de descripción del bus de eventos.
Para poder simplificar la ejecución de las pruebas y su diseño se utiliza un bus de eventos. El bus de
eventos permite desacoplar los componentes como se muestra a continuación.
EventBus bus; public void requestLogin(){ dialog.show(); CharSequence username = txtLogin.getText(); CharSequence password = txtPass.getText(); bus.post(new RequestLogin(username, password)); }
29
Fragmento de Código 1. Ejemplo del uso de un EventBus para facilitar las pruebas. En el siguiente fragmento de código el
método requestLogin(){...} es ejecutado cuando el usuario presiona el botón de iniciar sesión en la vista de ‘inicio de sesión’.
Como puede observarse en el Fragmento de Código 1, cuando el usuario inicia sesión presionando el
botón de “log in”, el método requestLogin() es ejecutado. El método obtiene el username y password de
los widgets txtLogin y txtPass y simplemente publica un evento RequestLogin al bus de eventos. El
Fragmento de Código 2 muestra el desacoplamiento y como es capturado el evento.
@Subscribe public void onRequestLogin(RequestLogin event){ final String cedula = event.getLogin(); final String password = event.getPassword();
runAsync(new DefaultTask<Driver>() { @Override public Driver execute() throws Exception { ... } @Override public void onSuccess(Driver result) { boolean login = result!=null;
bus.post(new ResponseLogin(login)); } @Override public void onFailure(Throwable throwable) { ... } }); } Fragmento de Código 2. Ejemplo de cómo un controlador captura el evento de RequestLogin y lo procesa. La anotación
@Subscribe obliga al EventBus a ejecutar onRequestLogin siempre que sea posteado un RequestLogin.
Como los métodos que acceden a recursos de red deben ser ejecutados en un thread separado (restricción
impuesta por Android OS), el método runAsync se encarga de ejecutar dicho método y de forma
asíncrona llamar el método onSuccess(Driver) y onFailure(Throwable) en caso de que se ejecute
exitosamente o en caso de que el servidor retorna un código 4xx o 5xx.
Como puede observarse, se logra un desacoplamiento grande dado que:
1. LoginActivity (Fragmento de Código 1) no conoce quién ejecuta el método.
2. LoginActivity no se preocupa por que sea un recurso de red o no que deba ser ejecutado en un
thread separado.
3. Realizar un test sobre el es muy simple y no requiere de un ambiente de ejecución complejo como
lo muestra el Fragmento de Código 3.
public void testLoginWithCorrectUsernameAndPass(){
final String usr = "fernandohur"; final String pwd = "pdaw123"; username.setText(usr); password.setText(pwd);
30
btnLogin.performClick();
RequestLogin loginEvent = (RequestLogin)bus.getEvent();
//test that fields should match login
Assert.assertEquals(usr,loginEvent.getData().first); Assert.assertEquals(pwd,loginEvent.getData().second); Assert.assertTrue(dialog.isShowing());
bus.post(new ResponseLogin(true));
// test what should happen on a successful login scenario Assert.assertTrue(!dialog.isShowing());
Assert.assertEquals(activity.getMessage(),LoginActivity.MESSAGE_LOGIN_SUCCESS);
} Fragmento de Código 3. Un ejemplo de cómo probar el LoginActivity sin necesidad de un ambiente complejo de pruebas. Se
omiten algunos fragmentos del código real por brevedad.
Como puede observarse, es posible simular el escenario completo de autenticación sin necesidad de
utilizar recursos de red ni depender de otros componentes y las pruebas pueden ser ejecutadas
eficientemente. El Fragmento de Código 3 muestra como un evento de RequestLogin puede ser validado
y retornado con un evento de ResponseLogin haciendo test del caso de uso completo de autenticación.
Patrón de Sincronización
Dado que el estado de un servicio de taxi puede ser modificado por cualquier taxista, hay una
preocupación adicional: cómo mantener sincronizado el estado local de la aplicación cliente con el estado
global. A continuación se describe el patrón arquitectural utilizado para garantizar la sincronización de
forma eficiente y permitir consistencia en los datos. El patrón es una modificación del patrón Option B
propuesto en Google I/O 2010 - Android REST client applications (Dobjanschi, 2010).
31
Figura 6. Patrón de sincronización para Android
A continuación se describen los componentes del patrón.
Componente Descripción
EventBus El bus de eventos o EventBus permite comunicación asíncrona entre componentes. Los
componentes se registran a eventos y cada vez que un evento es creado, el EventBus se encarga
de notificar a todos los componentes registrados al evento. Además de comunicación asíncrona, un event bus permite remover dependencias directas entre
componentes y hacer la comunicación únicamente mediante eventos, lo cual permite que el
código sea más fácil de probar. Actualmente se está usando el Guava Event Bus8
ContentProvider La responsabilidad del content provider es de brindar un API para acceder a la base de datos
interna del sistema operativo, en el caso de android Sqlite3
ServiceHelper Un componente singleton que permita llamar servicios de forma simple. Si bien su uso no es
estrictamente necesario ayuda DRY9
8 http://code.google.com/p/guava-libraries/wiki/EventBusExplained
32
Service Un servicio en android es un componente que tiene permisos del sistema para correr de forma
indefinida sin ser interrumpido ni apagado. Esto significa que si la aplicación está realizando un GET y esperando la respuesta, si ocurre una
llamada o el usuario decide cambiar la aplicación para escribir un mensaje de texto, el GET no
será interrumpido ni los recursos asociados serán liberados para darle lugar a otros procesos.
REST Method Es el encargado de realizar el request HTTP abriendo un socket, poniendo el contenido del
request, etc.
Processor Se encarga de obtener el resultado y procesarlo de manera adecuada. Adicionalmente se encarga
de persistir el resultado usando el API del content provider. Una vez que el contenido es
persistido, el content provider notifica al EventBus creando un nuevo evento el cual es enviado a
los que estén esperando cambios sobre el dato persistido.
La principal ventaja de esto es que en caso de que el OS necesite liberar recursos en memoria, los
datos seguirán persistidos y podrán ser accedidos después.
Tabla 13. Descripción de los componentes de patrón.
Arquitectura del Servidor
A continuación se detalla la arquitectura del servidor. En la figura del diagrama general del servidor se
presenta un diagrama de lenguaje propio, en donde se encuentra el controlador y el modelo del servidor.
Figura 7. Diagrama general del servidor
El diagrama de controladores modela los controladores del servidor y sus métodos. estos hacen uso de la
arquitectura REST. En el marco de Rails los controladores heredan del application.
9 DRY: Don’t repeat yourself. Principio de desarrollo de software. Repetir código es en general una mala idea que
puede llevar a problemas en el futuro adelante.
33
Figura 8. Diagrama de los controladores
Controlador Descripción
Users_controller Es el controlado que maneja la comunicación con el modelo de los usuarios. Por ende, es el que
hace la creación, actualización, obtención y modificación de los usuarios.
Services_controller Es el controlado que maneja la comunicación con el modelo de los servicios. La aplicación hace
uso de este controlador para pedir un servicio de taxi, cambiar el estado del servicio (confirmado,
pedido, atendido, etc) según el estado en el que se encuentra actualmente.
Positions_controller Este controlador maneja la posición de los taxis, por lo tanto mantiene el valor de las coordenadas
que los taxistas envían.
Panics_controller Este controlador se encarga de realizar la comunicación de los taxis en caso de que se encuentren
en peligro. Cuando se crea un panic, por medio del controlador, se notifica a los otros taxis sobre
34
el incidente.
Taxis_controller Este controlador, mantiene una comunicación con el modelo de taxis. Los taxis son el número de
aplicaciones que pertenecen a un carro (taxi) en específico, por eso se mantiene un installation_id,
que pertenece a un carro con una placa.
Drivers_controller Este controlador se encarga de realizar la comunicación con el modelo de taxistas.
Tabla 14. Tabla de controladores
El siguiente diagrama presenta el diagrama de los modelos en la arquitectura de la aplicación. En la tabla
de abajo se presenta una descripción de cada modelo y su nombre correspondiente.
Figura 9. Diagrama de los modelos del servidor
Modelo Descripción
35
Taxi Es el modelo que maneja la aplicación del taxista por lo tanto mantiene el installation_id de la
aplicación en el dispositivo del taxista para la realización de una comunicación hacía este
dispositivo en específico.
Position Es la posición en coordenada de un taxista. Por lo tanto, se mantienen los valores de la latitud,
longitud y el identificador del taxista.
Service Mantiene el estado de los servicios de un taxi. El usuario al solicitar un servicio, se crea una
nueva instancia, que obtiene el estado de pendiente. Este estado puede cambiar a confirmado o
cancelado, dependiendo de si un taxista confirma el servicio o el usuario lo cancela.
Driver Es el modelo que maneja las características de un taxi y el conductor, por lo tanto mantiene una
cédula, un nombre y una contraseña, para el ingreso de un taxi a la aplicación de los taxistas, y
poder hacer uso de sus servicios.
Panic Es el pánico, que se crea en momentos en que un taxista se encuentre inseguro. Esto genera una
notificación a todos los taxistas y se muestra en un mapa la posición del taxista en estado
inseguro.
User Los usuarios de la aplicación de usuarios. Se mantienen los valores de los usuarios, tales como sus
nombres, celulares, y correos.
MapObject son los objetos en el mapa de los taxistas que se crean para poder brindarle información sobre
trancones, gasolineras, huecos en las calles, a los taxistas y poder visualizarlos en el mapa.
MessageSender Es el modelo para enviar las notificaciones por medio de Google Cloud Messaging (GCM)
Tabla 15. Tabla de descripción de los modelos.
Arquitectura del usuario
En la aplicación del usuario se hace uso de Phonegap para el desarrollo de esta, lo que significa que se
hace uso del lenguaje de HTML, CSS y Javascript. A continuación se presenta el diagrama de
componentes del usuario.
36
Figura 10. Diagrama de componente aplicación del usuario.
Paquete de presenter
Componente Descripción
RegisterHandler Se presenta la interfaz para que el usuario se registre en la aplicación. Esta se debe presentar
máximo una sola vez. Esta interfaz presenta los campos de nombre, celular y correo electrónico
37
que el usuario debe agregar.
UserMap Este componente se encarga de la visualización del mapa y un icono que representa la ubicación
del usuario, además de un campo de texto el cual presenta la dirección que el usuario va a enviar a
los taxistas. Además se presenta un botón para solicitar el servicio de taxi.
Services Este componente es el encargado de la visualización de una barra de carga para los usuarios. Y se
presenta un botón para acceder al mapa del taxista.
DriverMap Después de haber recibido la confirmación por parte del taxista se le presenta al usuario un mapa
que muestra el recorrido del taxista hasta la llegada a donde el usuario. Se presenta también un
botón para solicitar un nuevo servicio.
Tabla 16. Descripción del package presenter
Paquete de UIHandler
Componente Descripción
RegisterHandler Se asegura que el usuario registre los valores de la aplicación, tales como que estos no sean vacíos
y sea el valor esperado. Por ejemplo, todos los celulares deben ser de un valor de 10 dígitos.
UserMapHandler Este componente se encarga de la visualización del mapa, haciendo uso de la librería de Google
Maps para mantener una visualización dinámica. Por otro lado, se hace uso de las funcionalidades
que brinda Google Maps, tales como la geocodificación inversa, que brinda la dirección de la
persona según su ubicación, y esta se ubica en la dirección del usuario para que se le facilite
agregar la dirección.
ServiceHandler Se encarga de hacer dinámica la visualización de la barra de carga. Además de estar esperando la
notificación por parte del servidor por si hubo un cambio en el estado del servicio.
DriverMapHandler Se encarga de hacer la visualización del mapa, haciendo uso de la librería de Google Maps,
además de agregar los iconos que representan al taxista (que está en movimiento) y al usuario,
con la posición guardada.
Tabla 17. Descripción del package UIHandler
Paquete de Services
Componente Descripción
Driver Es el modelo del conductor por lo tanto mantiene la placa, el celular y el nombre del conductor.
Position Es el modelo de la posición lo que significa que debe mantener solamente la latitud y la
coordenada.
Service El componente de service obtiene el valor del estado del servicio de taxi solicitado, cuando este es
confirmado se le notifica al usuario, cuando se crea, este se crea en el estado de pendiente.
UserServices Se encarga de hacer el registro del usuario. Al igual, que pedir el celular del usuario para obtener
el código de verificación.
Tabla 18. Descripción del package Services
38
Paquete de Model
Componente Descripción
DriversServices Este componente representa el servicio que hace la comunicación con el controlador del
conductor (driver) en el servidor, además que maneja también la comunicación con el modelo. En
este caso, es pedir los datos del conductor.
PositionsServices En este componente se obtiene el valor de la posición del conductor que confirmó la solicitud del
servicio.
ServicesServices El componente de service obtiene el valor del estado del servicio de taxi solicitado, cuando este es
confirmado se le notifica al usuario, cuando se crea, este se crea en el estado de pendiente.
UsersServices Se encarga de hacer el registro del usuario. Al igual, que pedir el celular del usuario para obtener
el código de verificación.
Tabla 19. Descripción del package model
39
Pruebas Con el objetivo de garantizar que la infraestructura permite satisfacer los requerimientos no funcionales
propuestos, en particular la escalabilidad se presentan las siguientes pruebas. Se recrean 3 escenarios de
pruebas, utilizando WEBrick10
, Unicorn y Puma11
respectivamente. Los escenarios se describen con más
detalle a continuación.
Escenario de Pruebas 1
Ambiente de desarrollo y producción
La aplicación es desarrollada en Ruby 1.9.3, Ruby on Rails 3.2.11 y PostgreSQL 9.2
Despliegue
La aplicación es desplegada en Heroku Celadon Cedar Stack, el stack por defecto de Heroku (mantiene la
versión de ruby, rails y postgres del ambiente de desarrollo). Heroku a su vez es desplegado en AWS
EC212
(East Coast). En el momento de las pruebas se logró un PING promedio de 188 ms desde el cliente
hasta el servidor.
Dyno
Para el despliegue de las pruebas se utiliza un dyno:
● Tiene un RAM máximo de 512MB. Si un proceso excede este valor empezará a hacer swap con
el disco, lo cual degrada en gran medida el desempeño.
● OS: Ubuntu 10.04
● Web Server: WeBrick
Ambiente General
Las pruebas fueron realizadas en la sede de la Fundación Santa Fé de la Universidad de los Andes. Para la
generación de carga se utilizó Apache JMeter 2.9 desde un HP corriendo Linux Lubuntu13
3.5.0 con 4GB
RAM e intel core i5.
Prueba 1: actualizar la posición de un taxi
Descripción: El escenario 1 busca verificar si el servidor actualmente soporta 20 usuarios concurrentes
actualizando su posición cada 5 segundos. Durante 30 minutos se crearán solicitudes de actualización de
ubicación, una operación relevante para el negocio. Las gráficas 1-3 muestran el tiempo promedio por
minuto en que un request toma en ser procesado medido desde el servidor.
10
WEBrick es el servidor web por defecto en ruby desde 1.9.3. Documentación oficial en ruby-doc.org 11
Servidor web basado en Mongrel: http://puma.io 12
AWS EC2: Amazon Web Services Elastic Compute Cloud: Infraestructura como servicio proveída por Amazon. 13
Lubuntu es un fork de Ubuntu que a su vez es un fork de Debian.
40
Resultados Generales
RPM14
promedio: 4390
ASRT15
: 116 m
Como puede observarse en las siguientes gráficas el tiempo promedio de ejecución en la base de datos y
en ruby es eficiente, el problema se encuentra en el tiempo promedio que cada request pasa en la cola.
Figura 11. Tiempo en cola promedio por request por minuto en HTTP POST a /positions.json
Figura 12. Tiempo promedio de ejecución en la base de datos de un HTTP POST a /positions.json
14
RPM: Requests por minuto exitosas. 15
ASRT: Average server response time medido desde el servidor utilizando la herramienta New Relic
41
Figura 13. Tiempo promedio que tarda un HTTP POST a positions.json en ser ejecutado por Ruby
Prueba 2: escalabilidad del servidor
En busca de predecir la capacidad de escalar del servidor se recrea el escenario anterior modificando el
número de threads. Los resultados se muestran a continuación en la Tabla 20 Para valores superiores los
tiempos de respuesta degradan a valores no aceptables (> 3.000 ms).
Threads RPM promedio Tiempo total
(ms)16 Ruby Time
Promedio (ms) DB Time
Promedio (ms) Queue Time
Promedio (ms) Incremento en
TT17 %
20 4390 108.40 3.40 5.00 100 -
30 2560 231.71 4.80 9.91 217 114%
40 2470 793.14 5.34 10.8 777 242%
Tabla 20. Escalabilidad del servidor
La Tabla 20 muestra el incremento en tiempos de respuesta de las 3 capas del servidor en búsqueda de
determinar el nivel de escalabilidad del servidor. Los valores son medidos directamente en el servidor
utilizando New Relic.
Utilizar más de 50 threads crea tiempos de respuesta de más de 3.000 ms, valores inaceptables para el
negocio. Adicionalmente se puede observar que el valor de RPM disminuye considerablemente.
Conclusiónes generales
Como puede observarse del incremento en TT tomado de la Tabla 20, el servidor simplemente no soporta
cargas pesadas. Esto se debe principalmente a dos razones:
16
Tiempo total: Se calcula como la suma de el tiempo promedio en ruby + el tiempo promedio de DB + el tiempo
promedio en cola. 17
Incremento en TT: Se calcula como 100%*(Tiempo Total(n+1) - TiempoTotal(n))/Tiempo Total(n)
42
● El servidor web que se está utilizando no soporta multithreading, es decir procesa todos los
requests en el mismo thread. Esto efectivamente implica que las colas se vuelven largas y
disminuye la calidad del servicio.
● Se está utilizando solamente un dyno.
Se propone entonces realizar pruebas adicionales utilizando el servidor web Unicorn, el cual soporta
concurrencia y utilizar dos dyno en vez de uno.
Escenario de Pruebas 2 El escenario de pruebas 2 es idéntico al 1 excepto por los siguientes cambios.
Dyno
Para el despliegue de las pruebas se utilizan dos dyno. Cada dyno:
● Tiene un RAM máximo de 512MB.
● OS: Ubuntu 10.04
● Web Server: Unicorn18
Prueba 3: Carga mediana
Descripción: Habiendo modificado el servidor web, se buscará medir la escalabilidad del mismo.
Variando el número de threads de 20 hasta 100 se medirá el tiempo promedio de ejecutar la operación de
actualización de posición. Para cada número de threads entre 100 y 200 se ejecutan 100 requests por
thread.
Resultados Generales
RPM Máximo: 16000
RPM Promedio: 6500
RPM Mínimo: 3500
Desviación estándar en el tiempo de respuesta promedio: 150ms
Número de Threads Tiempo de respuesta promedio (ms) Cambio en Tiempo de respuesta %
20 220 -
30 234 6.36%
40 287 22.65%
50 223 -22.30%
60 277 24.22%
70 398 24.22%
80 427 43.68%
90 463 7.29%
18
Unicorn: http://unicorn.bogomips.org/
43
100 479 8.43%
Tabla 21. Tiempo de respuesta promedio de envío de solicitud.
La Tabla 21 Muestra el resultado de tiempo de respuesta promedio medido desde el cliente ante un
número variable de usuarios concurrentes.
Como se puede observar, los cambios en tiempo de respuesta son evidentemente menores. La siguiente
gráfica muestra los datos obtenidos de la Tabla 21 en cuanto a tiempo promedio de respuesta con respecto
a número de threads.
Figura 14. Tiempo promedio de respuesta por número de threads.
Prueba 4: Carga alta
Descripción: La siguiente prueba consiste en realizar una repetición de la prueba 3 pero utilizando valores
más altos de threads, esto con el fin de simular un escenario de carga superior. A continuación, la gráfica
se muestra los resultados obtenidos.
Para cada número de threads entre 100 y 200 se ejecutan 100 requests por thread.
Desviación estándar promedio en el tiempo de respuesta: 357 ms
44
Número de threads Tiempo de respuesta promedio
(ms) Cambio de tiempo de respuesta promedio %
100 932 -
110 1026 10%
120 1159 13%
130 1177 2%
140 1313 12%
150 1299 −1%
160 1289 −1%
170 1306 1%
180 1563 20%
190 1679 7%
200 1830 9%
Tabla 22. Cambios en tiempo de respuesta por número de threads19
.
Haciendo una comparación entre el escenario 1 y el escenario 2 es claro que utilizar Unicorn contra
WeBrick y dos dynos contra un dyno representa una mejora en cuanto a tiempos de respuesta. En 180
threads se alcanzan valores de RPM promedio de por lo menos 6k.
Escenario de pruebas 3 El escenario 3 es igual al escenario 2. Simplemente se cambia el servidor web Unicorn por Puma 2.1. A
continuación se muestran los resultados obtenidos de tiempo de respuesta promedio medido desde el
cliente por número de threads.
Prueba 4: Carga alta con puma
Como se puede observar en la Figura 15 y la Tabla 23, hay una gran variación en el tiempo de respuesta
promedio para los valores de número de threads entre 100 y 150, sin embargo la tendencia se vuelve clara
de 160 en adelante. Adicionalmente, para valores de 200 threads se obtuvo valores de RPM promedio de
6000k.
Número de threads Tiempo de respuesta promedio (ms) Incremento del tiempo de respuesta
promedio %
100 530 -
19
El tiempo de respuesta promedio es medido desde el cliente (a diferencia del escenario 1)
45
110 645 22%
120 652 1%
130 574 −12%
140 630 10%
150 452 −28%
160 650 44%
170 1013 56%
180 1122 11%
190 837 −25%
200 1274 52%
Tabla 23. Carga alta con puma, tiempo de respuesta promedio
Figura 15. Tiempo de respuesta promedio vs número de threads, con carga alta: Puma
La Figura 1 Presenta Eje X: número de threads. Eje Y: tiempo de respuesta promedio medido desde el
servidor en milisegundos
46
La Figura 16 compara los resultados obtenidos por PUMA y Unicorn. Como se puede observar, Unicorn
presenta tiempos de respuesta mayores.
Figura 16. Comparación entre los servidores web Puma y Unicorn.
Conclusión
Teniendo en cuenta los resultados del escenario 1 es posible afirmar que un dyno no es suficiente para el
nivel de carga esperado. Adicionalmente, comparando los servidores web PUMA y Unicorn es evidente
que PUMA presenta tiempos de respuesta promedio menores. Sin embargo PUMA presenta un detalle
adicional: no es thread-safe, luego implica que todo el código debe ser pensado thread-safe. Unicorn en
cambio utiliza una arquitectura basada en procesos para manejar la concurrencia que proporciona un
ambiente thread-safe por defecto.
Pruebas de aceptación Las pruebas de aceptación son aquellas que se realizan para un grupo de usuarios finales o los clientes del
sistema y se asegura que el desarrollo de la aplicación cumple con los requisitos definidos.
Se van a indicar las diferentes pruebas que se van a realizar y medir cuando la aplicación esté en periodo
de prueba con un conjunto de taxis en específico, al igual que los usuarios. En cuanto al diseño y
47
usabilidad de la aplicación se planea realizar una encuesta a unas personas escogidas con anterioridad, y
se piensa enviarles por correo o presencial la encuesta la cual pueden ver en Anexos 1.
En cuanto a métricas del negocio y de la aplicación se planean tomar las siguientes:
1. Tiempo de los servicios solicitados, esta prueba hace referencia al tiempo que toma en que un taxi
confirme un servicio de taxi.
2. Estados de los servicios de taxi, esta prueba hace referencia al estado en que termina una
solicitud, es decir, si este fue confirmado y no atendido, o si fue confirmado y atendido, o si no
fue confirmado. Para esto se guarda el estado final de una solicitud.
3. Crecimiento del número de usuarios, aunque estaremos en fase de pruebas queremos crear
métricas que se asemejen a la realidad, y para esto, vamos a ver los cambios en la atención de
servicios según el crecimiento de usuarios, tanto de taxistas como de pasajeros con la aplicación.
Plan de negocios El objetivo del siguiente plan de negocio es poner en evidencia la viabilidad de Taxigol como producto y
servicio.
Resumen ejecutivo TaxiGol, subsidiaria de Bits & Bytes, cuya misión es proveer a las empresas operadoras de taxis
herramientas para brindar un mejor servicio a los pasajeros de taxis y a los taxis. Brindando, productos
tecnológicos para el monitoreo y seguimiento de los taxis, además una aplicación para usuarios y taxistas,
la cual permitiría un aumento en la eficiencia del servicio de solicitud de taxi, al eliminar el intermediario,
que es el operador en el momento de solicitar un servicio de taxi y que este sea confirmado. La compañía
va a obtener presencia en la industria, por medio de convenios que se realizarán con empresas del sector
de taxis en la ciudad de Bogotá D.C.
TaxiGol brindara el servicio, en un principio, en la ciudad de Bogotá D.C., desarrollando productos
innovadores, desarrollo en aplicaciones web, móviles y de backend para poder brindar un servicio a las
operadoras de taxis.
La estrategia de la compañía es obtener reconocimiento y posicionamiento en el mercado, por medio del
ofrecimiento de un servicio que ayudaría a las operadoras de taxis a mejorar el servicio, mantenerse a la
vanguardia en tecnologías, que aumentan la eficiencia de los servicios que actualmente proveen, y
mejorar el contacto que actualmente manejan con los taxis y los pasajeros.
La compañía se va a enfocar en mejorar la experiencia en que pasajeros de taxis obtienen del servicio
brindado por los taxistas. Al igual, proveer a los taxistas y operadores de taxis de herramientas que los
ayudarán a mejorar ese servicio, y les ayude a progresar en la industria. Los objetivos de la compañía para
el próximo año es tener convenios con 3 de las empresas más grandes del sector de taxis en Bogotá, que
sumando tengan registrados más de 10,000 taxis y que la aplicación de usuarios cuente con más de 70,000
descargas de la aplicación en las diferentes tiendas de aplicaciones móviles.
48
Compañías con los que TaxiGol esta compitiendo son Tappsi, Easy Taxi y las empresas operadoras de
taxis que están desarrollando aplicaciones para el manejo dentro de su empresa. La debilidad de las
empresas Tappsi e Easy Taxi, es que estas se están posicionando como empresas operadoras de taxis, y
están compitiendo contra las empresas ya establecidas. Y las empresas operadoras de taxis, tienen el
problema que su negocio no es el desarrollo de software lo que ha hecho que hagan productos que no han
tenido buena aceptación en el mercado.
La compañía no está buscando financiamiento, ya que los gastos de mercadeo, desarrollo y manutención
están dadas según las ventas y la actual alianza con Distribuidora Teleclub S.A. Las ventas proyectadas
para 2014, 2015 según el escenario se muestran en la sección de Plan Financiero.
Objetivos
Los objetivos de la compañía en el próximo año es realizar una campaña de mercadeo, para el
posicionamiento de la marca y la realización de convenios con operadoras de taxis de tal manera que se
obtenga un tamaño de mercado del 20% de los taxis registrados en Bogotá D.C.
Las actividades claves de la estrategia inicial son las siguientes:
● Gerencia
● Desarrollo del software
● Manejo de producto
● Desarrollo continuo
● Contacto con el cliente continuo
Misión
La misión de TaxiGol es proveer de las mejores herramientas a los operadores de taxi, para que puedan
brindar un servicio diferente, puedan realizar un monitoreo y seguimiento a sus taxis, y aumenten la
productividad y eficiencia de sus servicios, mejorando la experiencia de sus usuarios.
Destacados
Por lo que sobresale taxigol es por:
● Tecnología: la tecnología que se esta desarrollando, permitirá mantener un control y seguimiento
al taxista. Haciendo uso de dos aplicaciones móviles una para los pasajeros para que puedan
solicitar un servicio y obtener información de este y otra para los taxistas para que puedan obtener
los servicios y confirmarlos.
● Productividad y eficiencia: las operadoras de taxis se proveerán de herramientas para obtener
métricas que los ayuden a mejorar su productividad y siendo más eficientes en sus servicios.
● Integración con productos legados: La transición para pasar a nuestras tecnologías puede ser
difícil de aceptar, la idea es que esa transición sea gradual, para esto brindaremos la posibilidad
de que hagan uso de algunos de nuestras aplicaciones con los sistemas que actualmente están
manejando.
49
● Alianzas estratégicas: La compañía ha establecido y seguirá estableciendo alianzas de
cooperación mutua. Buscando un mutualismo en donde las empresas involucradas se beneficien.
Actualmente estamos manejando una alianza con la empresa de Distribuidora Teleclub.
Resumen de la compañía La compañía empezó desarrollándose el primer mes del año 2013.
Estrategia de la compañía
La estrategia de TaxiGol es saturar el mercado con nuestras aplicaciones, por medio de alianzas con las
operadoras de taxis, y gastos en mercadeo principalmente en radio y con taxistas como medio para
brindar publicidad. Las alianzas con las operadoras de taxis, igualmente brindarán promoción de la
aplicación para que estas obtengan un uso en el mercado que beneficiaría a TaxiGol y a las operadoras de
taxi.
La estrategia de la compañía es generar una reputación de una empresa que ayudara a progresar los
negocios existentes en las operadoras de taxi. Además, esperamos generar confianza con nuestros
clientes, y como una empresa que les provee servicios vanguardistas y confiables.
Riesgos
Hay riesgos a considerar de la empresa que son principalmente del mercado,
● Competencia: Actualmente hay 2 empresas de tecnologías, establecidas en el mercado en Bogotá
D.C que están teniendo cada vez una adquisición más grande de clientes. Además de que tienen
un capital mayor al que nosotros vamos a empezar.
● Alianzas: las empresas pueden estar adversas a realizar alianzas con nosotros e idear sus propios
software. Sin embargo, actualmente contamos con una operadora de taxi con la que estamos
trabajando.
Propuesta de valor
Las ventajas que nosotros brindamos a nuestros clientes son:
● Conveniencia/usabilidad: la competencia ha demostrado que el uso de aplicaciones móviles para
la solicitud de un servicio de taxi y la confirmación de este es más usable para los pasajeros.
● Eficiencia: El servicio de solicitud de un servicio de taxi, disminuirá de manera considerable,
actualmente el tiempo en pedir este servicio es mayor a 2 minutos para solicitarlo y la
confirmación de este es mayor a 2 minutos. Sin embargo, con el uso de aplicaciones móviles
donde se quite la intermediación de las operadoras para confirmar el pedido, haría de este servicio
una cuestión de segundos.
● Monitoreo y seguimiento: Se proveerá a las empresas operadoras de taxi, de herramientas para
que puedan obtener métricas de los taxistas y mejorar sus servicios y aumenten la productividad
de ellos por medio de estrategias de negocio y corporativas.
● Mejorar la calidad de vida de los taxistas: Brindar una aplicación móvil a los conductores de taxi
para que estos puedan obtener información relevante, tales como trancones y huecos en la vía. Se
50
quiere que a los taxistas, igualmente se les haga valer su rendimiento ofreciendo beneficios que
les puedan mejorar la calidad de vida, y mejoren el servicio de taxi.
Resumen del análisis de mercado Los enfoques de la compañía están en proveer servicios para mejorar la competitividad de las operadoras
de taxi. Actualmente ese mercado tiene ventas mensuales en Bogotá de aproximadamente COP $2,413
millones. El número de empresas operadoras de taxis radicadas en Bogotá al año 2009 40, donde tres de
esas tenían menos de 25 taxis y 2 de esas obtenían más del 50% del mercado (Vargas & Pulido, 2009)
según Ibáñez (2012), hay más de 50 empresas en Bogotá con el 73.8% del tamaño de mercado en 5
empresas.
Estadisticas del tamaño de mercado
Número de empresas operadoras de taxis 40 apróximadamente (apróx.)
Número de taxis 53,000 apróx.
Porcentaje de viajes en taxi del total de viajes en
Bogotá. 3.7% (Ibáñez, 2012)
20
Tabla 24. Estadísticas del tamaño de mercado
Segmentación de mercado
La segmentación de mercado de la empresa está dada por los diferentes actores y usuarios que hacen parte
del entorno en el que la compañía estaría actuando. Los principales clientes, serían las empresas
operadoras de taxis, las cuales estarían motivadas a usar este servicio, porque se les brinda una tecnología
que actualmente no le están ofreciendo, además la empresa tendría un mejor rendimiento y desempeño en
la atención de sus clientes y en mejorar el servicio que actualmente prestan. Los taxistas-conductores, son
las personas que hacen uso de la aplicación móvil para taxistas, y que además obtendrían beneficios por el
uso de esta aplicación tales como atención a los pasajeros de manera más rápida y mantener un contacto
directo con ellos, Los pasajeros-usuarios de taxis, son los usuarios de la aplicación para pasajeros, en
donde se hace la solicitud del servicio, y mantiene un contacto directo con los taxistas, lo que genera más
confianza y seguridad, al igual que es más cómodo para el usuario visualizar en un mapa el recorrido del
taxista.
Análisis de mercado
En un escenario probable, estos son los valores
Crecimiento (%) 2014 2015
Clientes
potenciales
20
Estos son datos de la Secretaría Distrital de Movilidad en la encuesta realizada en el 2005. Según la encuesta del
2011, este valor está más cerca al 3%, se puede ver resultados de esa encuesta en la bibliografía.
51
Operadores de taxis 133% 3 7
No. de Taxis 150% 1600 5000
Usuarios-pasajeros 150% 20000 50000
Tabla 25. Análisis de mercado
Competencia y patrones de compras
Amenazas de competencias hay de empresas que brinda el servicio de taxi por medio de aplicaciones
móviles en la ciudad de Bogotá D.C. Sin embargo la debilidad de estas empresas es que nada más están
brindando el servicio de taxi por medio de aplicaciones móviles, por lo tanto no están acaparando a todo
el mercado de pasajeros potenciales en la ciudad. Tappsi e Easy Taxi, las dos son conocidas como
empresas de despacho de taxi aunque nada más pueden hacer solicitud por medio de aplicaciones
móviles. Por otro lado, las compañías operadoras de taxi, también son competencia, por el hecho de que
ellas mismas pueden hacer el desarrollo de sus productos. La debilidad de estas empresas, es que el
núcleo del negocio no es el desarrollo de software.
Operadoras de taxi por aplicaciones móviles. La competencia para Taxi Gol en cuanto al uso de
tecnología innovadora, tales como el uso de aplicaciones móviles en el área de Bogotá D.C. son las
siguientes:
● Easy Taxi, es una multinacional con casa matriz en Brasil. Ha tenido inversiones cercano a los 5
millones de USD (Remus, 2012), esto es relevante por el hecho de que tienen mayor capital, y les
da ventaja en el mercado. Sin embargo, sus costos operacionales son mayores, dado que
actualmente esta empresa esta en diferentes ciudades, y deben manejar a los clientes de estas.
Además, esta empresa sólo maneja servicios solicitados por la aplicación móvil y aplicación para
los taxistas en donde reciba la solicitud.
● Tappsi, es una empresa radicada en Colombia. Tappsi, es actualmente la empresa dominante en la
solicitud de servicios de taxi por medio de aplicaciones móviles en la ciudad de Bogota D.C.
Actualmente, han tenido inversión por parte de diferentes programas del gobierno tales como la
iniciativa de Apps.co.
Operadoras de taxi, empresas tradicionales. Las empresas tradicionales, son un competidor importante,
porque estas igualmente están desarrollando productos para mejorar el servicio de taxis. Entre las más
importantes en el mercado son las siguientes:
● Radio Taxi Aeropuerto S.A.: también conocidos como los unos y taxis libres, es la empresa con
mayor participación en el mercado de operadores de taxi en la ciudad de Bogotá D.C. Además
que tiene presencia en otras ciudades de Colombia y de América Látina. Actualmente, ellos han
tratado de incursionar una aplicación móvil para la solicitud de servicios de taxi, y una aplicación
para los taxistas para la recepción de estos servicios, sin embargo, las aplicaciones no han tenido
bastante acogida, y no han penetrado bastante en el mercado.
La ventaja competitiva de Taxi Gol, esta dada porque nosotros trabajamos en conjunto con las empresas
operadoras de taxi tradicionales, en busca de aumentar la productividad de estas y de ser competitivas en
el mercado ante las amenazas de nuevas tecnologías. Por otro lado, Taxi Gol, brindaría herramientas que
actualmente no se están brindando, tales como obtención de métricas en tiempo real, y posibilidades de
52
aplicar un sistema de puntos para los usuarios, tanto conductores como pasajeros, que puedan ser
redimibles en productos o servicios de valor.
Resumen de estrategia e implementación
Estrategia de ventas
La estrategia de ventas es en alianza con las empresas operadoras de Taxis. La compañía pretende obtener
ingresos por medio de un sistema de comisión en las ventas de la aplicación de taxistas a los clientes de
las operadoras de taxis tradicionales.
Estrategia de mercadeo
Taxi Gol comercializa sus productos como una solución para las empresas operadoras de taxis como un
servicio para la mejora en la productividad de estas compañías. A los taxistas, se comercializa el producto
como una aplicación que les brindaría beneficios con las compañías con las que actualmente están
registrados, tales como brindarles un programa de puntos para redimir según su rendimiento. Y a los
usuarios, se les comercializa el producto como una aplicación con taxistas registrados, y con empresas
operadoras de taxis reconocidas en el mercado. Los principales canales de comunicación con nuestros
clientes y usuarios estarán dados por las compañías operadoras de taxis y los taxistas. Además se haría
una inversión, en un principio pequeña, en emisoras de radio y publicidad por internet.
La aplicación de un programa de mercadeo con los conductores de taxis, es esencial para el
reconocimiento de la empresa y la apropiación de sus productos. El programa consistirá en el uso de los
taxis como medios publicitarios, en donde se den incentivos monetarios a los taxistas por la divulgación
de nuestros productos a los pasajeros y a los taxistas. Esto se logrará con el uso de stickers promocionales,
hojas de productos y plantillas en los taxistas y brindado beneficios económicos en un principio.
Alianzas estratégicas
Taxi Gol, tiene una alianza estratégica con una empresa operadora de taxi que es la empresa Distribuidora
Teleclub S.A. Esta alianza es bastante importante para Taxi Gol porque permite que la compañía se
actualice en temas de negocio de taxis, además del incremento de posibles clientes y la ayuda que nos
brindaría la Distribuidora Teleclub S.A. con el mercadeo y el contacto con los taxistas.
Plan financiero Para el plan financiero se tuvieron en cuenta diferentes suposiciones que afectan a la hora de hacer la
valoración del proyecto. Los ingresos se asumen de la venta de la aplicación de taxis, donde un porcentaje
de las ventas de la aplicación son para las empresas operadoras de taxis y el otro porcentaje es para Taxi
Gol. Este porcentaje se asume del 40% para Taxi Gol.
Se presentan los diferentes escenarios para la valoración del proyecto, con un escenario pesimista,
probable y optimista.
53
Escenarios Inflación (2014) Incremento por posicionamiento Ventas (2014)
Pesimista 3.50% 2.10% 200
Probable 3.30% 2.20% 1600
Optimista 3.00% 2.30% 2000
Tabla 26. Variables proyección ventas.
Los valores de venta se obtienen según el acuerdo que se tiene con la empresa que se está trabajando. En
un principio se van a realizar pruebas para alcanzar a los 200 taxis. Si las pruebas salen bien (esperadas
por el cliente) se alcanzaría a un mercado de 1600 taxis, lo que lo vuelve un escenario probable. Por otro
lado, el escenario optimista, esta dado por una tasa de aprendizaje, que se asume del 25%, lo que significa
alcanzar un mercado de taxis de 2000. El incremento por posicionamiento de marca, esta dado por lo que
se asume que es aceptable en la industria, más la inflación tomando en cuenta valores del Banco de la
República.
Ingresos
Se van a presentar los ingresos en los 3 escenarios, dada las ventas de la aplicación para los taxistas.
Año 2013 2014 2015
Aplicación de
taxista
Unidades 100 400 700
Precio 0 COP
10,00
0
COP
10,56
0
Ingresos 0 COP
48,00
0,000
COP
88,70
4,000
Tabla 27. Ingresos escenario pesimista
Año 2013 2014 2015
Aplicación de
taxista
Unidades 600 1600 4000
Precio 0 COP COP
54
10,00
0
10,55
0
Ingresos 0 COP
192,0
00,00
0
COP
506,4
00,00
0
Tabla 28. Ingresos escenario probable
Año 2013 2014 2015
Aplicación de
taxista
Unidades 800 2000 7000
Precio 0 COP
10,00
0
COP
10,53
0
Ingresos 0 COP
240,0
00,00
0
COP
884,5
20,00
0
Tabla 29. Ingresos escenario optimista
Se asume que para el primer año en los tres escenarios no se va a cobrar por el producto, esto es para que
haya una aceptación del producto y apropiación de éste por parte de las empresas, los taxistas y se cree
una base de usuario. Además, el crecimiento del valor del producto se toma la inflación y un incremento
por posicionamiento de marca.
Egresos
Para los egresos se asume que según el escenario van a ver contratación de personal para desarrollo,
mercadeo y administrativos. Además según los escenarios, también habría una contratación de secretarias
y personal de soporte. En cuanto a los gastos de arrendamiento, la empresa se establecería en los espacios
de trabajo de start-ups reconocidas en Bogotá D.C. tales como, Atom House o Hubbog. Donde Atom
House, tiene un valor cercano a los $ COP 240,000 por persona. Hay que tener en cuenta que los costos
del año 2013, son sólo de 6 meses, además sería una nómina de 2 personas.
Gastos 2013 2014 2015
55
Nomina COP 38,400,000 COP 38,400,000 COP 40,550,400
Arrendamiento COP 5,760,000 COP 5,760,000 COP 6,082,560
Publicidad COP 1,500,000 COP 500,000 COP 800,000
Total COP 22,830,000 COP 44,660,000 COP 47,432,960
Tabla 30. Egresos escenario pesimista
Para este escenario se asume que el primer año si aun se cuenta con poca participación en el mercado y
alianza con al menos una de las empresas de taxis lo mejor es seguir trabajando con los gastos lo más
reducido posible.
Gastos 2013 2014 2015
Nomina COP 38,400,000 COP 88,800,000 COP 124,800,000
Arrendamiento COP 5,760,000 COP 11,520,000 COP 18,230,400
Publicidad COP 9,600,000 COP 19,200,000 COP 30,000,000
Total COP 26,880,000 COP 119,520,000 COP 173,030,400
Tabla 31. Egresos escenario probable
Gastos 2013 2014 2015
Nomina COP 38,400,000 COP 124,800,000 COP 187,200,000
Arrendamiento COP 5,760,000 COP 11,520,000 COP 27,293,760
Publicidad COP 9,600,000 COP 19,200,000 COP 48,000,000
Total COP 26,880,000 COP 155,520,000 COP 262,493,760
Tabla 32. Egresos escenario optimista
En las tablas de egresos de los escenarios probable y optimista, vemos cambios en los costos. En el
escenario probable, se asumen costos de personal con ingresos promedios de $ COP 2’200,000 más una
secretaria para el año 2014. En cuanto a publicidad, se asumen gastos mensuales de 1’600,00 en
publicidad para el año 2014, en inversión de canales de radio y publicidad en la red.
56
Estados Financieros Proyectados
Estados de Pérdidas y Ganancias
Se presentan los estados de pérdidas y ganancias según el escenario.
2013 2014 2015
Ventas 0 COP 48,000,000 COP 88,704,000
-gastos COP 22830000 COP 44,660,000 COP 47,432,960
gastos/ventas 93% 53%
Utilidad operacional
(ebit)
COP -22830000 COP 3,340,000 COP 41,271,040
Margen operacional 6.96% 46.53%
Impuesto renta +
reserva legal
0 0 COP 3,404,861
Utilidad del ejercicio COP -22830000 COP 3,340,000 COP 37,866,179
Utilidad neta COP -22,830,000 COP 3,340,000 COP 37,866,179
Margen neto 6.96% 42.69%
Tabla 33. Estado de pérdidas y ganancias escenario pesimista.
P&G 2013 2014 2015
Ventas 0 COP 192,000,000 COP 506,400,000
-gastos COP 26,880,000 COP 119,520,000 COP 173,030,400
gastos/ventas 62% 34%
Utilidad operacional
(ebit)
COP -26880000 COP 72,480,000 COP 333,369,600
Margen operacional 37.75% 65.83%
Impuesto renta +
reserva legal
0 0 COP 27,502,992
57
Utilidad del ejercicio COP -26880000 COP 72,480,000 COP 305,866,608
Utilidad neta COP -26,880,000 COP 72,480,000 COP 305,866,608
Margen neto 37.75% 60.40%
Tabla 34. Estado de pérdidas y ganancias escenario probable.
P&G 2013 2014 2015
Ventas COP - COP 240,000,000 COP 884,520,000
-gastos COP 26,880,000 COP 155,520,000 COP 262,493,760
gastos/ventas 65% 30%
Utilidad operacional
(ebit)
COP -26880000 COP 84,480,000 COP 622,026,240
Margen operacional 35.20% 70.32%
Impuesto renta +
reserva legal
0 0 COP 51,317,165
Utilidad del ejercicio COP -26880000 COP 84,480,000 COP 570,709,075
Utilidad neta COP -26,880,000 COP 84,480,000 COP 570,709,075
Margen neto 35.20% 64.52%
Tabla 35 .Estado de pérdidas y ganancias escenario optimista.
Las tablas de estado de pérdidas y ganancias muestran que la empresa no daría impuestos los primeros
dos años, esto se debe a que se acogería a la Ley 1429 del 2010, que aplicaría para las pequeñas empresas,
que se creen desde el 2010. Además la empresa no mantendría una reserva legal, acogiéndose de la Ley
1258 del 2009 y creando una empresa Sociedad por Acciones Simplificadas (s.a.s o sas) la cual no debe
mantener una reserva legal, a menos de que se establezca en el estatuto de la compañía.
Balance General
Se presentan los balances generales según el escenario.
2013 2014 2015
Caja COP -22,330,000 COP-19,990,000 COP 21,281,040
58
Total activos corrientes COP -22,330,000 COP-19,990,000 COP 21,281,040
Valor activos fijos
-depreciación acumulada
Activos fijos netos
Total activos COP -22,330,000 COP-19,990,000 COP 21,281,040
Cuentas por pagar
Impuestos por pagar COP 3,404,861
Pasivos corrientes COP 3,404,861
Aporte a capital COP 500,000 COP 500,000 COP 500,000
Reserva legal
Reserva acumulada
Utilidades del periodo COP -22,830,000 COP 2,340,000 COP 37,866,179
Utilidades retenidas
acumuladas COP-22,830,000 COP 2,340,000
Total patrimonio COP -22,830,000 COP-19,990,000 COP 40,706,179
Total pasivo+ patrimonio COP -22,830,000 COP-19,990,000 COP 44,111,040
Tabla 36 .Balance general escenario pesimista
2013 2014 2015
Caja COP -26,380,000 COP 46,100,000 COP 379,469,600
Total activos corrientes COP -26,380,000 COP 46,100,000 COP 379,469,600
Valor activos fijos
-depreciación acumulada
Activos fijos netos
59
Total activos COP -26,380,000 COP 46,100,000 COP 379,469,600
Cuentas por pagar
Impuestos por pagar COP 27,502,992
Pasivos corrientes COP 27,502,992
Aporte a capital COP 500,000 COP 500,000 COP 500,000
Reserva legal
Reserva acumulada
Utilidades del periodo COP -26,880,000 COP 72,480,000 COP 305,866,608
Utilidades retenidas
acumuladas COP -26,880,000 COP 72,480,000
Total patrimonio COP -26,380,000 COP 46,100,000 COP378,846,608
Total pasivo+ patrimonio COP -26,380,000 COP 46,100,000 COP 406,349,600
Tabla 37. Balance general escenario probable
2013 2014 2015
Caja COP -26,380,000 COP 58,100,000 COP 680,126,240
Total activos corrientes COP -26,380,000 COP 58,100,000 COP 680,126,240
Valor activos fijos
-depreciación acumulada
Activos fijos netos
Total activos COP -26,380,000 COP 58,100,000 COP 680,126,240
Cuentas por pagar
Impuestos por pagar COP 51,317,165
60
Pasivos corrientes COP 51,317,165
Aporte a capital COP 500,000 COP 500,000 COP 500,000
Reserva legal
Reserva acumulada
Utilidades del periodo COP -26,880,000 COP 84,480,000 COP 570,709,075
Utilidades retenidas
acumuladas COP -26,880,000 COP 57,600,000
Total patrimonio COP -26,380,000 COP 58,100,000 COP 628,809,075
Total pasivo+ patrimonio COP -26,380,000 COP 58,100,000 COP 680,126,240
Tabla 38. Balance general escenario optimista
Flujo de Caja Libre
Se presentan los flujos de caja libres según el escenario.
2013 2014 2015
+EBIT COP -22,830,000 COP 2,340,000 COP 41,271,040
-Impuestos operativos COP 3,404,861
+depreciación y
amortizaciones
+Diferencia de capital de
trabajo
+Diferencia de Capex
FCL COP -22,830,000 COP 2,340,000 COP 37,866,179
Tabla 39. Flujo de caja libre estado pesimista
2013 2014 2015
+EBIT COP -26,880,000 COP 72,480,000 COP 333,369,600
-Impuestos operativos COP 27,502,992
61
+depreciación y amortizaciones
+Diferencia de capital de
trabajo
+Diferencia de Capex
FCL COP -26,880,000 COP 72,480,000 COP 305,866,608
Tabla 40. Flujo de caja libre estado probable
2013 2014 2015
+EBIT COP -26,880,000 COP 84,480,000 COP 622,026,240
-Impuestos operativos COP 51,317,165
+depreciación y amortizaciones
+Diferencia de capital de
trabajo
+Diferencia de Capex
FCL COP -26,880,000 COP 84,480,000 COP 570,709,075
Tabla 41. Flujo de caja libre estado optimista
Según esos valores si se hace un análisis de rentabilidad se obtienen los siguientes valores sobre la
rentabilidad del proyecto con la tasa interna de retorno (TIR)
Escenario TIR %
Pesimista 34%
Probable 398%
Optimista 544%
Tabla 42. TIR según el escenario.
Dada esta TIR se ven los altos valores del proyecto. Sin embargo, para saber si el proyecto es sostenible,
hay que compararlo con la tasa de descuento, la cual se obtiene de la siguiente fórmula:
Donde,
62
Ke = es el costo del equity que se aproxima usando la fórmula del C.A.P.M.
Kd = Costo de la deuda después de impuestos
D/D+E = Estructura de apalancamiento óptima basada en el promedio de la industria.
Para el costo del equity Ke se hace uso de la fórmula de C.A.P.M la cual es la siguiente:
Donde,
Rf = es la tasa libre de riesgo, para esto se usa el valor de los TES de la bolsa de valores.
Be = es el beta del equity
E{Rm} - Rf = Es la prima de riesgo del mercado. Esta se calcula de valores históricos de los spread en el
mercado.
Rp = La ecuación del C.A.P.M cambia al añadir este valor, el cual es el riesgo del país, que se añade
cuando se calcula para mercados emergentes.
Todos estos valores se obtienen según sea necesario para la industria o para el mercado. Dada la dificultad
de encontrar los valores para el sector de servicio de taxi, o transporte público, se hace uso de la empresa
que más se asemeja a este sector o se ve afectada por los efectos que tenga este sector. Esta empresa es
Medallion Financial Corp con la información proveída por WikiWealth (s.f), se obtiene un valor de
10.7% sin embargo, en esa página no hacen uso de la tasa de riesgo del país, es por ello que se hace uso
de la tasa de riesgo del país esta se obtiene del valor dado por Chaves, M (2013) el cual se ubicaba en
107pb o 1.07%, lo que da un valor de WACC de 11.72%. Dado este valor nos damos cuenta que bajo los
3 escenarios el proyecto es viable.
Discusión Conclusión En el transcurso de 6 meses se trabajó en el desarrollo de un idea de negocio haciendo uso de la
tecnología e innovación y atendiendo a un mercado que está presentando dificultades, el cual es el
mercado de las empresas operadoras de taxis. Para el desarrollo de esta idea de negocio, se mantuvo una
comunicación continua con una empresa operadora de taxi en la ciudad de Bogotá, la cual brindó
retroalimentación a los productos desarrollados. Aplicando la metodología de Lean Startup y desarrollo
ágil de software se creó un producto con diferentes aplicaciones que para el cliente son importantes.
Dado el corto tiempo, no se han realizado las pruebas de aceptación por parte de los usuarios, y tampoco
se tiene una base de usuarios en las aplicaciones desarrolladas.
Trabajo a futuro Este trabajo es el comienzo de un proyecto empresarial. A fecha de entrega de este documento, se está en
conversaciones con la empresa Distribuidora Teleclub S.A. para realizar las pruebas de usuario, y
comenzar a adquirir una base de usuarios. La empresa, solicitó unos cambios en la aplicación del taxista,
para dar comienzo a un periodo de prueba de la aplicación.
63
Según lo que se ha hablado con el gerente de Teleclub S.A. esperamos añadir un sistema de puntos o de
lealtad a los conductores de taxis, en donde se les valore el rendimiento de la cantidad de servicios
atendidos. Aún, estamos en una etapa temprana para saber como la competencia podrá afectar la
aceptación de la aplicación. Si esta aplicación obtiene una buena aceptación, se va a proseguir a contactar
a las otras empresas operadoras de taxis para que usen de nuestro servicio.
64
Bibliografía Blank, S. (25 de Octubre de 2010). Entrepreneurship as a Science – The Business Model/Customer
Development Stack. Recuperado el 3 de Junio de 2013 from Steve Blank :
http://steveblank.com/2010/10/25/entrepreneurship-as-a-science-%E2%80%93-the-business-
modelcustomer-development-stack/
Blank, S. (2013). The Four Steps to the Epiphany: Successful Strategies for Products that Win (3 ed.).
K&S Ranch Publishing LLC.
Dobjanschi, V (27 de Mayo de 2010). Google I/O 2010 - Android REST client applications. Recuperado
el 5 de Junio de 2013.
Chaves, M. (19 de Enero de 2013). Riesgo país de Colombia se redujo 103 puntos en un año. Recuperado
el 5 de Junio de 2013 from La Republica : http://www.larepublica.co/finanzas/riesgo-pa%C3%ADs-de-
colombia-se-redujo-103-puntos-en-un-a%C3%B1o_29581
Hartl, M. (2012). Ruby on Rails Tutorial: Learn Web Development with Rails. Recuperado el 20 de Mayo
de 2013 from Ruby on Rails Tutorial: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
Ibáñez, M. P. (2012). Viabilidad Técnica y Financiera del Servicio de taxis en el Sistema Integrado de
Transporte Público. Recuperado el 31 de Mayo de 2013 from Biblioteca Digital:
http://www.bdigital.unal.edu.co/8596/1/300457.2012.pdf
North, D. (Noviembre de 2009). How to sell BDD to the business. Recuperado el 27 de Mayo de 2013
from Skills Matter:
http://skillsmatter.com/custom/presentations/sellingbddtothebusiness_bdd.pdf
Osterwalder, A., & Pigneur , Y. (2013). Business Model Generation: A Handbook for Visionaries, Game
Changers, and Challengers. John Wiley & Sons.
Ramfetl, L., Kjellberg, J., & Kosnik, T. (2011). Gear Up. Your best business idea ever. Recuperado el 3
de Junio de 2013 from Smakprov:
http://www.smakprov.se/smakprov/visa/9789197956994/partner/smakprov
Remus, D. (2012). Easy Taxi recebe aporte de R$10 milhões da Rocket Internet e inicia expansão
nacional por São Paulo. Recuperado el 20 de Mayo de 2013 from Startupi | Startup Inteligence:
http://startups.ig.com.br/2012/easy-taxi-recebe-aporte-de-r10-milhoes-da-rocket-internet-e-inicia-
expansao-nacional-por-sao-paulo/
Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses (1 ed.). Crown Business.
65
Rodriguez, A., & Acevedo, J. (2012). Taxi! El modo olvidado de la movilidad en Bogotá (Vol. 1).
Bogotá, D.C, Colombia: Uniandes.
Rosales, A. (5 de Mayo de 2013). Tappsi, el fenómeno de las 100 mil descargas. Recuperado el 5 de
Junio de 2013 from Publitag: http://publitag.blogspot.com/2013/05/tappsi-el-fenomeno-de-las-100-
mil.html
Ruby, S., Thomas, D., & Hansson, D. H. (2011). Agile Web Development with Rails. USA: The
Pragmatic Programmers.
SIM. (s.f). Listado Parque Automotor Empresas Taxi. Recuperado el 20 de Mayo de 2013 from SIM
Bogota:
http://www.simbogota.com.co:8092/simBogota/consultas/consultaEmpresaAfiliadoraTaxi.jsp?&pageNu
m=1
TechEmpower. (17 de Mayo de 2013). Web Framework Benchmarks. Recuperado el 20 de Mayo de 2013
from TechEmpower Web Site: http://www.techempower.com/benchmarks/
Vargas, J. D., & Pulido, A. M. (6 de Julio de 2009). Plan de negocio para analizar la viabilidad de
implementar el sistema de tarjeta prepago en la empresas de taxis ADLOGO, en la ciudad de Bogotá.
Recuperado el 30 de Mayo de 2013 from Universidad Javeriana:
http://www.javeriana.edu.co/biblos/tesis/economia/tesis131.pdf
WikiWealth. (s.f). Medallion Financial (Weighted Average Cost of Capital (WACC) Analysis).
Recuperado el 5 de Junio de 2013 from WikiWealth: Collaborative Research:
http://www.wikiwealth.com/wacc-analysis:taxi
66
Anexos 1. Encuesta Encuesta para las pruebas de aceptación
La siguiente encuesta es para mejorar la experiencia de los usuarios en el uso de la aplicación. Tomará tan
sólo 2-5 minutos completarla. Las preguntas subjetivas están en un valor de 1 si esta totalmente no de
acuerdo 5 totalmente de acuerdo.
La encuesta para los taxistas
1. ¿En qué dispositivo tiene su aplicación?
a. Celular
b. Tableta
Marca: _________________
2. ¿El tamaño de los botones en la aplicación le parece que son los adecuados?
a. Se brinda una línea de valor entre 1 - 5.
3. ¿Le parece que el diseño estético de la aplicación es el adecuado?
a. Se brinda una línea de valor entre 1 - 5.
4. ¿La notificación de un nuevo servicio de taxi le parece el adecuado?
a. Se brinda una línea de valor entre 1 - 5.
5. ¿La aplicación responde a las solicitudes como ud. espera?
a. Se brinda una línea de valor entre 1 - 5.
6. ¿La aplicación no le ha presentado errores?
a. si
b. no
sí respondió si, podría decirnos cómo fue su error:_________
7. Por favor, si puede diganos comentarios o sugerencias sobre la aplicación, que le gustaría que
incluya y cree que debemos añadir o mejorar
a. ________________
La encuesta para los usuarios
1. ¿En qué dispositivo tiene su aplicación?
b. Celular
c. Tableta
Marca: _________________
2. ¿El servicio de taxi se le responde en el tiempo adecuado?
a. Se brinda una línea de valor entre 1 - 5.
3. ¿Le parece que el diseño estético de la aplicación es el adecuado?
a. Se brinda una línea de valor entre 1 - 5.
4. ¿La aplicación no ha presentado errores?
d. si
e. no
sí respondió si, podría decirnos cómo fue su error:_________
67
5. Por favor, si puede diganos comentarios o sugerencias sobre la aplicación, que le gustaría que
incluya y cree que debemos añadir o mejorar
a. _______________
2. Resultados del producto
Figura 17. Mapa aplicación del taxista
68
Figura 18. Notificación del botón de pánico
Figura 19. Creación de un icono en el mapa
69
Figura 20. Servicios de taxis recibidos.
