Espitia Paz Harold Stevens 2017

Aplicación Móvil Para Informar Ubicación y
Nivel de Congestión de Buses y Estaciones

del Sistema Transmilenio
Especialización en ingenierı́a de Software
FACULTAD DE INGENIERÍA
Sergio Gutiérrez, Duban Herrera, Harold Espitia
Director: Joaquı́n Javier Meza

Revisor: Lilian Bejarano
14 de noviembre de 2016
2
Índice general
0.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I Contextualización de la Investigación 15
1. Descripción de la investigación 17
1.1. Estudio del problema . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . 17
1.1.2. Formulación del problema . . . . . . . . . . . . . . . . . . 18
1.1.3. Sistematización del problema . . . . . . . . . . . . . . . . 18
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . 19
1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1. Justificación práctica . . . . . . . . . . . . . . . . . . . . . 19
1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5. Marco de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5.1. Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5.2. Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . 26
1.6. Aspectos metodológicos . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.2. Método de investigación . . . . . . . . . . . . . . . . . . . 28
1.6.3. Fuentes y técnicas para la recolección de la información . 29
1.6.4. Tratamiento de la información . . . . . . . . . . . . . . . 29
1.7. Organización del trabajo de grado . . . . . . . . . . . . . . . . . 29
1.8. Estudio de sistemas previos . . . . . . . . . . . . . . . . . . . . . 29
1.8.1. Waze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.8.2. Moovit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
II Desarrollo de la Investigación 31
2. Gestión del Proyecto 33
2.1. Gestión Técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.1. Metodologı́a de Desarrollo . . . . . . . . . . . . . . . . . . 33
3
4 ÍNDICE GENERAL
2.1.2. Gestión de Ambientes . . . . . . . . . . . . . . . . . . . . 33

2.1.3. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . 34
2.1.4. Mensajes de Error, Informativos y de advertencia . . . . . 88
2.1.5. Definición de estructuras de datos . . . . . . . . . . . . . 89
2.1.6. Definición de estructura del servicio web . . . . . . . . . . 93
2.2. Gestión de Comunicaciones . . . . . . . . . . . . . . . . . . . . . 97
3. Arquitectura Funcional 99
3.1. Vista Motivacional . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.1.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.1.2. Vista Motivacional iTransAgilApp . . . . . . . . . . . . . 100
3.2. Vista Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . . 100
3.2.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.2.2. Vista Proceso de Negocio iTransAgilApp . . . . . . . . . 101
4. Arquitectura Técnica 103

4.1. Vista Comportamiento de Aplicación . . . . . . . . . . . . . . . . 103
4.1.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.1.2. Vista Comportamiento de Aplicación iTransAgilApp . . . 104
4.2. Vista Cooperación de Aplicación . . . . . . . . . . . . . . . . . . 105
4.2.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2.2. Vista Cooperación de Aplicación iTransAgilApp . . . . . 105
4.3. Vista Estructura de Aplicación . . . . . . . . . . . . . . . . . . . 106
4.3.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.3.2. Vista Estructura de Aplicación iTransAgilApp . . . . . . 106
4.4. Vista Uso de Aplicación . . . . . . . . . . . . . . . . . . . . . . . 107
4.4.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.4.2. Vista Uso de Aplicación iTransAgilApp . . . . . . . . . . 108
4.5. Vista Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.5.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.5.2. Vista Infraestructura iTransAgilApp . . . . . . . . . . . . 109
4.6. Vista Uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . 109
4.6.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.6.2. Vista Infraestructura iTransAgilApp . . . . . . . . . . . . 110
III Cierre de la Investigación 111

5. Resultados y discusión 113
6. Conclusiones 115
6.1. Verificación, contraste y evaluación de los objetivos . . . . . . . . 115
6.2. Sı́ntesis del modelo propuesto . . . . . . . . . . . . . . . . . . . . 116
6.3. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.4. Trabajos o publicaciones derivadas . . . . . . . . . . . . . . . . . 117
ÍNDICE GENERAL 5
7. Prospectiva del trabajo de Grado 119

7.1. Lı́neas de investigación futuras . . . . . . . . . . . . . . . . . . . 119
7.2. Trabajos de investigación futuros . . . . . . . . . . . . . . . . . . 119
6 ÍNDICE GENERAL
Índice de figuras
1.1. Arquitectura del sistema operativo Android . . . . . . . . . . . . 25

1.2. ArquitecturaClienteServidor [24] . . . . . . . . . . . . . . . . . . 27
2.1. Evidencias Historia de Usuario 0-001-1 [fuente: los autores] . . . 35

2.4. Evidencias Historia de Usuario 0-002-3a-b [fuente: los autores] . . 38
2.5. Evidencias Historia de Usuario 0-002-3c [fuente: los autores] . . . 39
2.22. Evidencias Historia de Usuario 1-001-1c-d [fuente: los autores] . . 55
2.23. Evidencias Historia de Usuario 1-001-1c-d [fuente: los autores] . . 56
7
8 ÍNDICE DE FIGURAS

2.33. Evidencias Historia de Usuario 3-003-3[fuente: los autores] . . . . 67
2.39. Evidencias Historia de Usuario 3-004-4c[fuente: los autores] . . . 72
2.47. Evidencias Historia de Usuario 4-001-1a[fuente: los autores] . . . 80
2.48. Evidencias Historia de Usuario 4-001-1b[fuente: los autores] . . . 80
2.50. Evidencias Historia de Usuario 4-001-1d[fuente: los autores] . . . 81
2.55. Evidencias Historia de Usuario 4-001-2e[fuente: los autores] . . . 84
3.1. Metamodelo Vista Motivacional [28] . . . . . . . . . . . . . . . . 99

3.2. Vista Motivacional iTransAgilApp [fuente: los autores] . . . . . . 100
3.3. Metamodelo Vista Proceso de Negocio [28] . . . . . . . . . . . . . 101
3.4. Vista Proceso de Negocio iTransAgilApp [fuente: los autores] . . 101
4.1. Metamodelo Vista Comportamiento de Aplicación [28] . . . . . . 103

4.2. Vista Comportamiento de Aplicación iTransAgilApp [fuente: los
autores] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3. Metamodelo Vista Cooperación de Aplicación [28] . . . . . . . . 105
4.4. Vista Cooperación de Aplicación iTransAgilApp [fuente: los au-
tores] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.5. Metamodelo Vista Estructura de Aplicación [28] . . . . . . . . . 106
4.6. Vista Estructura de Aplicación iTransAgilApp [fuente: los autores]107
ÍNDICE DE FIGURAS 9
4.7. Metamodelo Vista Uso de Aplicación [28] . . . . . . . . . . . . . 107

4.8. Vista Uso de Aplicación iTransAgilApp [fuente: los autores] . . . 108
4.9. Metamodelo Vista Infraestructura [28] . . . . . . . . . . . . . . . 108
4.10. Vista Infraestructura iTransAgilApp [fuente: los autores] . . . . . 109
4.11. Metamodelo Vista Uso de Infraestructura [28] . . . . . . . . . . . 109
4.12. Vista Uso de Infraestructura iTransAgilApp [fuente: los autores] 110
10 ÍNDICE DE FIGURAS
Índice de cuadros
2.1. MENSAJES INFORMATIVOS . . . . . . . . . . . . . . . . . . . 88

2.2. MENSAJES DE ADVERTENCIA . . . . . . . . . . . . . . . . . 89
2.3. MENSAJES DE ERROR . . . . . . . . . . . . . . . . . . . . . . 89
2.4. Tabla Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.5. Tabla ResponseCodes . . . . . . . . . . . . . . . . . . . . . . . . 90
2.6. Tabla Troncals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.7. Tabla Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.8. Tabla Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.9. Tabla RouteStatation . . . . . . . . . . . . . . . . . . . . . . . . 91
2.10. Tabla RouteStationQualification . . . . . . . . . . . . . . . . . . 92
2.11. Tabla BusRouteQualification . . . . . . . . . . . . . . . . . . . . 92
2.12. Tabla Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.13. Tabla BusPosition . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.14. Método OpRegisterUser . . . . . . . . . . . . . . . . . . . . . . . 93
2.15. Método OpLoginSession . . . . . . . . . . . . . . . . . . . . . . . 93
2.16. Método OpGetStations . . . . . . . . . . . . . . . . . . . . . . . . 94
2.17. Método OpChangePassword . . . . . . . . . . . . . . . . . . . . . 94
2.18. Método OpSetRouteStationQualification . . . . . . . . . . . . . . 94
2.19. Método OpGetStationQualification . . . . . . . . . . . . . . . . . 95
2.20. Método OpGetRoutesStations . . . . . . . . . . . . . . . . . . . . 95
2.21. Método OpGetRouteStationQualification . . . . . . . . . . . . . 95
2.22. Método OpSetQualificationBusRoute . . . . . . . . . . . . . . . . 96
2.23. Método OpGetRouteQualification . . . . . . . . . . . . . . . . . . 96
2.24. Método OpGetBus . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.25. Método OpSetBusPosition . . . . . . . . . . . . . . . . . . . . . . 97
2.26. Método OpCreateBus . . . . . . . . . . . . . . . . . . . . . . . . 97
11
12 ÍNDICE DE CUADROS
0.1. Introducción
Los usuarios del sistema de transporte masivo de Bogotá(Colombia) ST,
diariamente se enfrentan a la congestión en estaciones y buses de las diferentes
rutas, lo cual genera retrasos en la llegada a sus destinos e incomodidad en su
desplazamiento. Actualmente un usuario del ST no cuenta con una fuente de
información que presente el nivel de congestión real de buses y estaciones, por
lo cual se puede dirigir a una estación congestionada e invierte tiempo simple-
mente para poder ingresar, el cual puede emplear para dirigirse a otra estación
con una cantidad de usuarios menor, definir otra ruta o medio de transporte
diferente y posiblemente reducir el tiempo de llegada a su destino.
Por otro lado en algunos “Publics” o letreros de estaciones y portales, se in-

forma un tiempo estimado de llegada del próximo bus que lleva determinada
ruta, que normalmente no es acorde a la realidad, adicionalmente se desconoce
totalmente el nivel de gestión de los buses próximos a arribar.
Es normal ver personas esperando una ruta especı́fica que corren hacia otro
vagón en la misma estación ’persiguiendo’ a un bus que lleva una ruta diferente
a la esperada pero que también les permite llegar a su destino. El motivo de
esto puede ser que la ruta esperada llevaba mucho tiempo sin pasar, puede ser
porque el bus perseguido tenia mas espacio del que creı́an iban a encontrar en
el bus de la ruta esperada inicialmente, o una combinación de las dos causas.
Buscando reducir ese nivel de incertidumbre generado por el desconocimien-

to de los usuarios y por falta de una herramienta que permita a los mismos
conocer el nivel de congestión y ubicación de buses y estaciones del sistema
transmilenio, se propone el desarrollo de una aplicación Android que ataque es-
te problema y de manera colaborativa entre los usuarios, les permita compartir
la información de una manera fácil, práctica y eficiente.
La investigación descrita en este documento tiene como objetivo primordial

informar la ubicación y nivel de congestión de estaciones y buses a partir del
cálculo de la cantidad aproximada de usuarios. Dicha cantidad es calculada a
partir de datos recolectados por otros usuarios, haciendo uso de un sistema de
información que contará con un método de recolección de datos por medio de
los dispositivos móviles con sistema operativo Android.
A pesar de que el fin principal del proyecto es dar la información al usua-

rio, también podrı́a ser usado por la administración distrital o administración
del sistema directamente para tomar decisiones sobre posibles cambios en la
operación.
0.1. INTRODUCCIÓN 13
Palabras clave: sistema de información, usuario final, aplicaciones móviles,

Android, rutas, estaciones, buses, WBS
Abreviaturas:
ST (Sistema Transmilenio)
SITP (Sistema Integrado de Transporte Público)

WBS (Work Breakdown Structure)
XP (eXtreme Programming)
14 ÍNDICE DE CUADROS
Parte I
Contextualización de la
Investigación
15
Capı́tulo 1
Descripción de la
investigación
1.1. Estudio del problema

1.1.1. Planteamiento del problema
A lo largo de los últimos diez años, con el crecimiento de la economı́a na-
cional, se han incrementado diferentes sectores de la misma, ocasionando que
la capital se convierta en una central generadora de empleo en el paı́s; lo que a
su vez produce que el ı́ndice de Colombianos que se movilizan hacia la ciudad
crezca drásticamente. Este y algunos otros motivos, como la alta cantidad de
competencia, sobre población, y sobre todo la necesidad de organizar el trans-
porte, han sido causantes de la creación de un sistema masivo de transporte.
La creación del ST, proporcionó una solución paulatina al problema, sin em-
bargo con el paso del tiempo la idea de unificar el transporte público, con el
SITP, ha hecho que el sector movilidad a nivel distrital, se convierta en uno de
los problemas principales de la administración capitalina, pues el sistema que
actualmente opera presenta diferentes incógnitas, dentro de las que resaltan la
optimización del servicio, la seguridad dentro del sistema, comodidad, costos,
etc. Generalmente durante las horas pico se presenta congestión en estaciones
y paraderos del SITP, ası́ como en los del ST. Para el caso de las estaciones, el
tiempo de espera tan solo para el ingreso puede superar los diez minutos. En
cuanto a los paraderos del SITP las filas que conducen al lugar donde el bus
abrirá las puertas pueden extenderse a más de quince metros.
Se evidencia que algunos puntos de abordaje (estaciones o paraderos) presentan

mayor congestión que otros. El tiempo que una persona pierde intentando en-
trar o acercarse al punto de abordaje, puede ser invertido en el desplazamiento
a otro punto o en la búsqueda de otro medio de transporte. Los usuarios no
17
18 CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN
cuentan con una herramienta o medio que les permita identificar los puntos que
son realmente crı́ticos para poder abordar un auto bus del ST o aquellos puntos
que comparados con otros presentan una cantidad menor de usuarios.
Por otro lado los usuarios desconocen totalmente el nivel de congestión pun-
tual del sistema, tiempo estimado de llegada o cantidad de usuarios aproximada
del siguiente bus que arribará al punto de abordaje en el que se encuentra. En
algunas situaciones cuando el usuario se encuentra a la espera de un autobús
en el punto de abordar, el que esté más cerca puede llevar en el momento más
usuarios que otro aunque se encuentre más lejos. Para ese caso vale la pena
esperar unos minutos más para poder transportarse en un bus más desocupado
y ası́ poder viajar más cómodo.
Si los usuarios no cuentan con una fuente de información actualizada y coheren-

te con el nivel de congestión en tiempo real del ST, se mantendrá la dificultad
planteada y las personas que se transportan a diario en el mismo, aumentaran
su inconformismo a medida que pasa el tiempo.
Las siguientes son preguntas que serán objeto de estudio a lo largo de este
proyecto, pues se busca agilizar desde un punto de vista tecnológico, el sistema
de transporte a nivel distrital.
1.1.2. Formulación del problema
¿Como podrı́an los usuarios del ST de la ciudad de Bogotá, enterarse de la

ubicación y nivel de congestión de buses y estaciones del mismo para apoyar la
toma de decisiones en el uso de las rutas?
1.1.3. Sistematización del problema
¿Es importante para el usuario del ST enterarse del nivel de congestión de

las estaciones y buses del mismo, en tiempo real al tomar decisiones sobre
el uso de las rutas?
¿Es útil para la administración del ST enterarse del nivel de congestión

de estaciones y buses del mismo, en tiempo real al tomar decisiones sobre
el diseño de las rutas?
¿Es viable invertir en un método para optimizar el sistema de transporte

público, a través del análisis de información obtenida en tiempo real sobre
el nivel de congestión de estaciones y buses del ST?
1.2. OBJETIVOS 19
1.2. Objetivos
1.2.1. Objetivo general
Implementar una aplicación móvil Android que se integre con un sistema de
información basado en la cantidad aproximada de usuarios del ST capturando
datos en tiempo real, permitiendo a los mismos enviar y consultar la información
que verán los demás usuarios, para lograr identificar el nivel de congestión y
ubicación de los buses y estaciones del mismo.
1.2.2. Objetivos especı́ficos

Implementar el módulo de administración por medio de aplicaciones WEB
para permitir gestionar la información de estaciones y buses (rutas) que
componen el ST.
Implementar en la aplicación Android el módulo de recolección de datos
en tiempo real, suministrados por los usuarios con los cuales se podrá
determinar la ubicación y nivel de congestión de buses y estaciones.
Implementar en la aplicación Android el módulo de consulta que permita
al usuario enterarse de la ubicación y nivel de congestión de los buses y
estaciones del ST procesando los datos recopilados en tiempo real, sumi-
nistrados por los usuarios, para dar a los mismos la información solicitada.
1.3. Justificacion
1.3.1. Justificación práctica
Teniendo en cuenta la problemática presentada previamente, el proyecto tie-
ne su razón de ser principalmente en el hecho de realizar un estudio preliminar
del comportamiento del sistema de transporte masivo, teniendo en cuenta las
diferentes variables que lo afectan. El estudio permitirá obtener una apreciación
directa de la gestión del sistema y la interacción con el usuario que este presenta.
En segundo plano se plantea establecer un mecanismo de organización de la

información recolectada durante el proceso de estudio investigativo del ambien-
te, con el fin de presentar una alternativa que permita informar al usuario sobre
la ubicación y nivel de congestión de estaciones y buses del ST, por medio de
un canal directo y efectivo, que permita también la centralización de un flujo
de información constante que funcione como punto de referencia para toma de
decisiones.
Concretamente el proyecto busca dar una alternativa de fuente de información

pública para los usuarios del ST, por medio de un sistema que funcione como
centralizador de información, y que facilite el proceso de toma de decisiones.
Lo anterior es un medio para enterarse de la ubicación y nivel de congestión de
buses y estaciones del ST en tiempo real, para establecer un punto de partida

al posterior proceso de toma de decisiones desde diferentes perspectivas.
En la sección ’Estudio de sistemas previos’ se habla un poco de MOOVIT

que es una aplicación que se acerca un poco a la solución de este inconveniente,
sin embargo, desde el punto de vista de los autores tiene dificultades en algu-
nos aspectos como su facilidad de uso y la exactitud de la información brindada.
Por todo lo anteriormente mencionado, se plantea la creación e implementación

de una aplicación móvil Android que se integre con un sistema de información,
de fácil acceso a los usuarios del ST y que puedan consultar/enviar información
en lı́nea y en el momento en que lo requieran de una forma muy práctica, ágil y
rápida comprendiendo que actualmente el ST tiene una alta demanda de usua-
rios y en las estaciones y buses del mismo no se dispone de tiempo y paciencia
para el uso de una aplicación de este tipo.
1.4. Hipótesis
La implementación de una aplicación Android constituirá, para el usuario,
un medio de consulta inmediata sobre la ubicación y nivel de congestión de buses
y estaciones del ST permitiéndoles enterarse de ciertas variables en tiempo real
para tomar decisiones basados en esa información.
1.5. Marco de referencia

1.5.1. Marco teórico
En el año 2000, se inauguró la primera ruta del primer sistema de transporte
masivo de Bogotá-Colombia, operando entre la autopista norte, avenida caracas
y la calle 80. La idea nace como el planteamiento de una solución al problema
que se presentaba ante la fuerte y agresiva competencia generada por las dife-
rentes empresas de transportes privados a nivel distrital y como una respuesta
a la creciente demanda de ciudadanos en la capital Colombiana.[4]
Sin embargo un éxito prematuro del sistema presentó durante sus primeras fases
de funcionamiento, generó un crecimiento no controlado, que a su vez desarrolló
una sobre demanda de los usuarios, hasta el punto de un 12.8 % en los últimos
13 años. (Revista semana, 2014) [1]
Actualmente en la ciudad de Bogotá, más exactamente a partir del año 2012

operan 147 estaciones del ST, divididas en las siguientes troncales:
A – Caracas
B – Autopista norte
1.5. MARCO DE REFERENCIA 21
C – Suba
D – Calle 80
E – NQS Central
F – Américas
G – NQS Sur
H – Caracas sur
J – Eje ambiental
K – Avenida el dorado
L – Carrera 10
M – Carrera séptima central
Ası́ mismo se proyecta la creación de 62 nuevas estaciones que plantean una

extensión de las lı́neas “G” (NQS sur), “K” (Avenida el Dorado) y “M” (Carrera
séptima central) ası́ como la implementación de nuevas troncales:
N – Boyacá sur
P – Boyacá central
R – Boyacá norte
S – Carrera séptima norte [6]
Sobrecostos en el mantenimiento del sistema, sobrecupo en los buses que

atienden las rutas planteadas, retardos considerables en la llegada y salida de
los buses, descompensación en la cantidad de usuarios en la llegada de los buses
(buses que arriban a las estaciones muy llenos o muy vacı́os), demasiada deman-
da y pocos medios para suplirla, alto nivel de delincuencia e inseguridad, son los
principales problemas a los que ha tenido que enfrentarse el sistema, durante su
proceso de evolución.
Desde el punto de vista del usuario final, el principal problema que presenta
el sistema es la ineficiencia en cuanto al flujo cotidiano del mismo, particu-
larmente en las llamadas horas pico (segmentos del dı́a en los que el flujo de
usuarios es especialmente crı́tico), pues el ST presenta descompensaciones cla-
ramente visibles durante su cotidiano funcionamiento.
A partir del 15 de Marzo de 2014, se instalaron dispositivos de tipo módem

que permiten al usuario acceder a un internet con capacidad de 10Mb, en 15
estaciones de las principales troncales del ST en la ciudad con un alcance de
alrededor de 400 metros, ası́ se instalaron dispositivos que permitirán acceder a
internet en los principales portales de la ciudad: Usme, Tunal, Américas, Calle
80 y Suba. [5]
El presente proyecto busca por medio de una solución tecnológica, brindar una
fuente de información a los usuarios, que permita a los mismos tener conocimien-
to en tiempo real sobre el comportamiento del sistema, especı́ficamente sobre el
nivel de congestión de buses y estaciones.
Desde un punto de vista administrativo o de gestión, con el fin de obtener

una visión holı́stica del proyecto, se implementaran algunas fases del ADM (Ar-
chitecture Development Method) del marco de trabajo arquitectural planteado
por TOGAF.
TOGAF (The Open Group Architecture Framework), es un marco de traba-

jo arquitectural que busca presentar un enfoque de diseño, implementación y
gestión del gobierno de arquitectura de las organizaciones. Creado por el Open
Group, TOGAF, tiene como principales objetivos describir una metodologı́a
para la construcción de sistemas de información orientada a componentes, con-
tener un conjunto de herramientas que faciliten el proceso de integración y/o
migración de tecnologı́as a nivel interno de la organización, proveer un lenguaje
unificado e incluir una lista de estándares que coordinen las diferentes áreas de
la compañı́a. [1]
Para llevar a cabo el cumplimiento de los objetivos que se plantea la arqui-

tectura TOGAF en sı́ misma, ası́ como de la organización que aplica el marco
de trabajo, se hace referencia a 5 dimensiones fundamentales: Arquitectura mo-
tivacional, Arquitectura de negocios, Arquitectura de aplicaciones, Arquitectura
de Datos y Arquitectura de tecnologı́a. Para uso puntual del proyecto, se hará
énfasis directamente en las tres últimas dimensiones. [2]
Dado que para el proyecto no es objeto de estudio analizar el proceso de diseño

arquitectural de una organización, solamente se tomará como foco de estudio la
vista arquitectural de la aplicación.
Para dar más claridad respecto a la vista arquitectural de la aplicación den-

tro del marco de referencia de diseño arquitectural, en este se busca presentar
un diseño de cómo funcionará la aplicación en relación a los objetivos que se
plantearon para ella. Dentro de la vista de aplicación, se detallan las funciones
de la misma, actores que intervienen directa e indirectamente en la misma, in-
terfaces de comunicación, y mecanismo de despliegue.
A nivel técnico, se busca el desarrollo de un proyecto tecnológico, que más allá de

dar solución a la problemática previamente mencionada, presente una implemen-
tación de las metodologı́as que más se adecúen al desarrollo del mismo. Siendo
ası́ y teniendo en cuenta el cronograma (que será presentado posteriormente),
se realizará el uso de metodologı́as ágiles, más especı́ficamente metodologı́a XP,
para el desarrollo del proyecto en general.
La metodologı́a XP o programación extrema es un tipo de metodologı́a ágil,

utilizada principalmente para el desarrollo de software. Propuesta en 1999 por
Kent Beck, consiste en un marco de trabajo diseñado principalmente para el
desarrollo de software, el cual a diferencia de otras metodologı́as, hace princi-
palmente énfasis en la adaptabilidad que en la previsibilidad. La metodologı́a
XP, propone un proceso de desarrollo evolutivo orientado a la simplicidad y
agilidad, el cual a diferencia de las metodologı́as clásicas evita presentar tanta
burocracia en las diferentes etapas, reduciendo el número de las mismas, con el
fin de concentrar esfuerzos en aquellos procesos que realmente son vitales dentro
del ciclo de vida del software.
En su libro, Beck, centra el desarrollo de la metodologı́a basado en cinco valores

principales (comunicación, simplicidad, retroalimentación, coraje y respeto), ası́
como una serie de principios (inversiones, economı́a, diversificación, entre otros).
A diferencia de las metodologı́as convencionales, XP se desarrolla bajo cuatro
fases principales, planeación del proyecto, diseño, codificación y pruebas, las
cuales se encuentran dentro de ciclos repetitivos conocidos como “sprints”. Su
sistema de recolección de requerimientos ejecutado de manera evolutiva, para
cada una de las fases liberables, conocido como historias de usuario permite
ejecución conjunta de la mano del cliente, del desarrollo general del proyecto.
En términos generales, dados los pormenores del proyecto, la implementación de

una metodologı́a ágil, para el desarrollo del proyecto, toma vital importancia,
dado que permitirá realizar la construcción de los requerimientos (historias de
usuario) de forma evolutiva para cada una de las fases de desarrollo del proyec-
to. [3] [4] [5]
En una capa de más bajo nivel, del desarrollo de la aplicación, es necesario

mencionar acerca del patrón arquitectural MVC (Modelo Vista Controlador),
cuyo principal objetivo dentro del desarrollo de un sistema tecnológico, es di-
vidir responsabilidades a través de la declaración de capas: modelo: en la que
se encuentran los elementos relacionados directamente con las reglas y/o lógica
de negocio; el controlador: encargado de recibir desde las vistas y enrutar las
peticiones hasta el módulo de negocio; finalmente, está la capa de la vista: encar-
gada como su nombre lo indica, su principal responsabilidad es la presentación,
captura y modificación de los datos. [6]
Finalmente, dando cierre a la contextualización del marco teórico, es impor-

tante tratar directamente las tecnologı́as que serán utilizadas para el desarrollo
de la solución (para este caso una aplicación móvil), a la problemática que se
plantea. Puntualmente se tratarán temas relacionados con la tecnologı́a An-
droid, y la implementación de la arquitectura REST.
El proceso de implementación de la solución, será llevado a cabo a partir del

trabajo en conjunto de dos tecnologı́as; en primer lugar como foco fundamental
del desarrollo de la aplicación, se implementará una aplicación móvil basada en

el sistema operativo Android, el cual está diseñado originalmente para teléfo-
nos móviles (evolucionado posteriormente para diferentes dispositivos móviles).
Basado en el de Linux, el sistema operativo Android, fue desarrollado en la
compañı́a de nombre homónimo (liderada por Rich Miner, Chris White y Nick
Sears), en el año de 2003. En el año 2005 la multinacional norteamericana (que
previamente realizaba apoyos económicos a la compañı́a), realiza la compra to-
tal de Android Inc. Actualmente el sistema operativo ofrece cobertura para las
grandes marcas de dispositivos móviles, estando ası́ en su versión 7.0, cuyo nom-
bre es Nugat. [7] [8]
El sistema operativo Android, presenta una estructura descrita de la siguiente

manera: en primer lugar se encuentra el módulo de aplicaciones: correspondiente
al conjunto de aplicaciones implementadas por la comunidad de desarrollado-
res, que buscan atender funcionalidades puntuales, dando soluciones directas
a problemas cotidianos para los usuarios de los dispositivos móviles, ejemplos
de este tipo son videojuegos, contactos, exploradores o navegadores, escritorios,
herramientas de personalización, etc. Las aplicaciones que son instaladas en el
sistema operativo, se dividen en tres diferentes tipos:, nativas, hı́bridas y We-
bApps.
En el segundo escalón de la arquitectura propuesta por el sistema operativo

Android, se encuentra el Armazón de aplicaciones, el cual busca realizar una
administración de las diferentes propiedades con las que cuenta el sistema ope-
rativo en relación con el dispositivo en el que se encuentra alojado, se compone
de administradores de ventanas, administrador de actividades, administrador de
contenidos, vistas del sistema entre otros. Más adelante se encuentra el módulo
de librerı́as, que permitirá establecer acceso a propiedades locales del sistema
operativo, tales como bases de datos librerı́as de seguridad, y administrador de
superficies. Finalmente se encuentra el núcleo del sistema operativo el cual co-
mo se mencionó previamente está desarrollado con base al Kernel de Linux; este
será el encargado de administrar recursos de memoria, mantener disponibles los
dispositivos de hardware del teléfono, entre otros. [9] [10]
Dado que uno de los objetivos especı́ficos del proyecto es realizar la creación
de una aplicación móvil, el core del proyecto centrará sus esfuerzos en la prime-
ra capa del esquema de aplicaciones del sistema operativo Android, realizando
el despliegue de una aplicación desarrollada en lenguaje Java, cuyo soporte de
información fundamental está radicado en un servicio web que implementará la
tecnologı́a REST.
Un servicio web, es una aplicación desarrollada bajo la arquitectura cliente-

servidor, que se comunican mediante mensajerı́a que tı́picamente sigue el esque-
ma XML; son sistemas de software concebidos, para soportar una interacción
entre diferentes nodos de una red; un servicio web, puede también definirse co-
mo una API, que permite ejecutar diferentes operaciones en la máquina en la
Figura 1.1: Arquitectura del sistema operativo Android

[9] [10]
que se aloja. [11]
Durante los últimos años, el desarrollo de sistemas de información se ha orien-

tado al desarrollo de arquitecturas orientadas a servicios, permitiendo una alta
modularidad de servicios y facilitando la separación en componentes, de los ele-
mentos que intervienen dentro del sistema. La arquitectura REST (REpresen-
tation State Transfer), consiste en un diseño arquitectónico, basado en sistemas
en red, principalmente aplicaciones web, que implementa el protocolo HTTP,
sin embargo para el caso puntual de REST, se realiza una limitación de las
operaciones del protocolo (GET, PUT, etc.). El principal objetivo de una arqui-
tectura REST, es realizar el intercambio de peticiones utilizando la arquitectura
cliente-servidor previamente mencionada, aunque si bien el objetivo es realizar
el intercambio de mensajes, para llegar a ello se establece un sistema de capas,
en el que no es posible pasar de una capa a otra sin que la previa se haya com-
pletado en su totalidad. [11] [12]
Para realizar el desarrollo de la aplicación, se realizará la implementación de

un arquitectura que está pensada en combinar la tecnologı́a Android, permi-
tiendo ası́ llegar a un amplio espectro de usuarios. Por otra parte a manera de
complemento, se plantea la construcción de un servicio web que realice el consu-
mo de una base de datos relacional, diseñada con el fin de cubrir los diferentes
aspectos que se desean tener en cuenta dentro de la solución planteada. Gra-

cias a la implementación de la vista de aplicación del marco TOGAF, se puede
verificar el despliegue arquitectónico de la aplicación.
1.5.2. Marco conceptual

Con el fin de establecer un contexto de los conceptos que serán frecuentados
a lo largo del documento, tanto para la parte técnica, como para la parte de
contextualización del problema, en esta sección, se realizará una aproximación
de los elementos que serán tratados a lo largo del desarrollo del proyecto.
CONTEXTUALIZACIÓN DEL PROBLEMA:

En primer lugar se mencionarán los conceptos más importantes que son men-
cionados durante el desarrollo del proyecto, y que son parte principal del mismo:
Sistema Transmilenio: El sistema transmilenio (ST) Es un sistema de trans-

porte masivo, implantado en la ciudad capital de Colombia, a partir del año
2000. Opera a lo largo de Bogotá distribuido por las principales troncales de la
ciudad. [13]
Sistema masivo de transporte: También llamado autobús de transito rápi-

do, es una modalidad de transporte de ciudadanos a gran volumen, pensado
principalmente como un medio alternativo, con el fin de agilizar la movilidad
general del entorno, bajo el cual es desarrollado. Regularmente es implementado
en grandes ciudades y de diferentes modalidades (metros, trenes, etc.). [14]
ASPECTOS TÉCNICOS:
Dado que el foco de la solución planteada para el desarrollo del proyecto
consiste en el desarrollo de una aplicación móvil desarrollada bajo el sistema
operativo Android, a continuación se presentan los conceptos más importantes
en cuanto a los aspectos técnicos que se tendrán en cuenta:
Aplicaciones móviles: Son un tipo de software desarrollado principalmen-

te para dispositivos móviles, como teléfonos inteligentes, tablets, computadoras
de bolsillo, entre otros. Presentan un conjunto de ventajas como portabilidad
y disponibilidad que son superiores a las aplicaciones de computadora conven-
cionales. Las aplicaciones móviles permiten sacar un mayor provecho de las
caracterı́sticas de hardware del dispositivo, ası́ como información proporcionada
directamente por el usuario, con fines de alimentación de sistemas de informa-
ción. [15]
Android: Es un sistema operativo, desarrollado para operar principalmente en
dispositivos móviles con pantalla táctil. Está desarrollado bajo tecnologı́a Linux.
Debido a la alta demanda de teléfonos inteligentes de distintos fabricantes es
uno de los sistemas operativos mas usado en este tipo de dispositivos. [16]
Algoritmo: Un algoritmo, es una secuencia de instrucciones, que representan

un método de solución para un problema determinado. [17]
Búsqueda de ruta más corta/óptima: En informática, dentro de la teorı́a
de grafos, se define el algoritmo de la ruta más corta, como el mecanismo que
resuelve el proceso de búsqueda de la distancia de menor longitud entre dos
puntos, ubicados dentro de un grafo. El proceso de búsqueda, debe realizar el
procesamiento de todos los nodos y aristas del grafo, para de esta manera en-
contrar el camino más óptimo. Para resolver este problema se han planteado
principalmente tres tipos de algoritmos: Dijkstra, Warsahall y Floyd. [18] [19]
Búsqueda por proximidad: Teniendo en cuenta el objetivo del proyecto, pa-
ra este caso se propone una definición de proximidad, orientada a un tipo de
algoritmo que es implementado, para realizar la búsqueda del nodo más cercano
a un punto preestablecido. El proceso de búsqueda se debe realizar a todos los
nodos y aristas del grafo. [20]
Kernel Linux: El kernel de Linux, es considerado el corazón de todo sistema
operativo basado en tecnologı́a Unix o Linux; es el encargado de que el hard-
ware y software de cualquier dispositivo (computadoras, teléfonos inteligentes,
tablets, etc.), puedan trabajar juntos. Se encuentra licenciado bajo la licencia
GPLV2, lo que indica que su uso es libre, y el fuente del mismo se encuentra
construido por una comunidad de desarrolladores que constantemente realizan
contribuciones al mismo. [21]
Aplicaciones nativas: Corresponden a un tipo de aplicaciones desarrolladas
principalmente para el núcleo de Android, tı́picamente son programas escritos
en código java, utilizando el esquema XML, para el proceso de la capa de pre-
sentación, aplicaciones hı́bridas. [22]
Arquitectura cliente-servidor: La arquitectura cliente servidor, es una ma-
nera de diseccionar y especializar programas y equipos de cómputo, de manera
que la tarea que cada cual ejecuta sea realizada de manera eficaz y eficiente, se-
parando responsabilidades, y facilitando un mayor y más sencillo mantenimiento
del sistema en general. [23]
Figura 1.2: ArquitecturaClienteServidor [24]

La figura 1.2 representa gráficamente el despliegue de una arquitectura clien-

te–servidor, en la cual intervienen equipos enviando peticiones directamente a
un servidor, el cual se encarga de recibirlas, procesarlas y contestarlas.
Para el caso del producto de software que se desarrolla en el proyecto, se pro-
pone la implementación de una arquitectura cliente servidor, en la que los roles
de nodos, serán representados por equipos móviles de cada uno de los usuarios.
XML: El Extensible Markup Language, es un tipo tipo de formato de texto
simple y muy flexible, derivado del SGML, utilizado fundamentalmente para
el almacenamiento y transporte de información. XML, está diseñado bajo un
esquema de etiquetas, en las que se define la estructura del documento, y se
especifican las configuraciones que este debe tener. [25]
1.6. Aspectos metodológicos

1.6.1. Tipo de estudio
Mediante la implementación de un sistema de información que permita re-
copilar datos suministrados por los usuarios del ST y posteriormente presentar
información actualizada de la cantidad de usuarios aproximada en estaciones y
buses en tiempo real, la presente investigación seguirá un tipo de estudio expli-
cativo, al ofrecer una fuente pública y un mecanismo de recopilación de datos
hasta el momento no implementados, para poder identificar elementos, causas,
variables, caracterı́sticas etc., relacionados directa e indirectamente con la alta
congestión del ST, los cuales pueden servir para: la realización de nuevas inves-
tigaciones , toma de decisiones operativas en el ST y principalmente mantener
a la ciudadanı́a informada.
1.6.2. Método de investigación

La información para calcular la cantidad aproximada de usuarios en estacio-
nes y buses determinados del ST, es generada a partir de los datos suministrados
por los usuarios, de esta manera la investigación seguirá el método inductivo.
Dado que no es objeto primordial de esta investigación el estudio de los di-

ferentes algoritmos de búsqueda de ruta más óptima o búsqueda de proximidad;
con fines netamente académicos, para el proyecto se realizará el cálculo de califi-
cación del estado de una ruta o una estación, a través de una media aritmética de
las calificaciones proporcionadas por cada usuario. Es importante resaltar que el
uso de la media aritmética, como principal medio de verificación de construcción
de un diagnóstico acerca del estado puntual del sistema, es una alternativa uti-
lizada estrictamente para el ejercicio académico, dado que, en futuras versiones
del producto final, [tal y como se concluye en la investigación (revisar apartado
de conclusiones)], se realizará la implementación de diferentes algoritmos que
permitan alcanzar mayor precisión en los cálculos que se realizarán dentro del
sistema en general.
1.7. ORGANIZACIÓN DEL TRABAJO DE GRADO 29
1.6.3. Fuentes y técnicas para la recolección de la infor-

mación
Fuentes Primarias: Para calcular la cantidad aproximada de usuarios en
estaciones y buses, se recopilará la información de los usuarios por medio de
una aplicación que se ejecuta en dispositivos móviles. Fuentes Secundarias:
Documentos y planos públicos del ST, con el fin de obtener la información de
estaciones y rutas.
1.6.4. Tratamiento de la información

Para determinar el nivel de congestión de una estación o bus, se requiere una
cantidad mı́nima de datos suministrados por usuarios, con los cuales se podrá
calcular una cantidad aproximada de personas y compararla con la cantidad
máxima que la estación o bus tenga capacidad. La información será presentada
al usuario gráficamente he indicando la ubicación y nivel de congestión general
de un bus o estación, por medio de una aplicación instalada en su dispositivo
móvil Android.
1.7. Organización del trabajo de grado

El proyecto inició con base a algunas ideas de los integrantes del equipo, los
cuales propusieron distintas ideas para luego combinarlas en una sola y llegar a
definir un alcance y objetivos sobre los módulos a desarrollar.
Haciendo uso de la experiencia en desarrollo, administración de plataformas

y calidad de software que tienen los miembros del equipo del proyecto, se esco-
gieron las tecnologı́as a utilizar y se instalaron los ambientes necesarios para el
correcto desarrollo del mismo.
A medida que se avanza con la ejecución del proyecto no se presentan grandes

problemas que impacten directa y drásticamente el correcto avance del mismo.
La principal dificultad encontrada es la falta de tiempo disponible debido a obli-
gaciones laborales y académicas de los integrantes.
1.8. Estudio de sistemas previos

Dentro de la investigación realizada no se encontraron aplicaciones que tu-
vieran las mismas funcionalidades que las propuestas en este proyecto para
atacar el problema mencionado. Sin embargo, en su generalidad se encuentran
similitudes con la filosofı́a que manejan dos aplicaciones muy conocidas por la
comunidad respecto a información sobre el transporte y trafico. Estas aplicacio-
nes son WAZE y MOOVIT las cuales se describirán breve y resumidamente a
continuación.
1.8.1. Waze
De acuerdo a lo descrito en la página de ayuda de WAZE (ahora propiedad
de Google), es una aplicación de navegación GPS, aunque para muchas personas
es considerada una red social que permite a sus usuarios compartir información
sobre el estado del tráfico, controles policiales, accidentes, entre otros eventos
que puedan afectar la velocidad y calidad de desplazamiento de vehı́culos en las
calles.
WAZE es usada por conductores de vehı́culos públicos y privados, brindando

información del estado de las vı́as. Esto es posible con la participación de una
comunidad de conductores o también llamada red social o red “Geosocial” [26],
quienes comparten y evalúan en tiempo real, mediante una aplicación móvil, el
estado de las vı́as transitadas durante un trayecto. Adicionalmente con base en
la información recolectada, presenta una ruta óptima. La diferencia principal
que tendrá el sistema de información desarrollado en esta investigación respecto
a WAZE, es que se brindará una fuente de información actualizada de estaciones
y buses del ST. Por otro lado, ambos tienen en común la participación de los
usuarios, como fuente primordial de los datos.
Un ı́tem muy importante y que es la principal similitud que se encontró con

la aplicación de software propuesta, es que depende directamente del buen uso
que se le dé a la aplicación por parte de los usuarios para que a los mismos se les
brinde una información de alta calidad y coherente con la realidad del momento
en que se consulte. Para mayor detalle de cómo funciona WAZE se puede visitar
la página de soporte oficial referenciada en la bibliografı́a. [27]
1.8.2. Moovit
MOOVIT Es una aplicación móvil que permite a los usuarios consultar infor-
mación sobre el transporte público como rutas, paradas, tiempo de espera para
la llegada de una ruta, etc. Lo anterior para facilitar la movilidad en el sistema
de transporte de cada ciudad; SITP/Transmilenio en el caso de Bogotá que es la
ciudad en la cual se desarrollará nuestro proyecto. MOOVIT tiene varias funcio-
nalidades muy importantes y útiles, las cuales se pueden consultar en su página
oficial moovitapp.com/es/. Sin embargo, la navegación y facilidad de uso no
favorecen mucho a la misma, teniendo en cuenta que realmente un usuario del
ST, SITP o cualquier sistema de transporte masivo espera de una herramienta
para llevar a cabo su recorrido, la simplicidad de uso y calidad de la información.
En cuanto a la implementación de MOOVIT en el ST de Bogotá, a pesar de

que presenta a los usuarios información de tiempo estimado de trayectos y no-
tificaciones del estado del mismo, no permite enterase del nivel de congestión
de estaciones y buses, ni tampoco una ubicación aproximada de estos últimos.
Esta caracterı́stica diferencia a MOOVIT del sistema de información propuesto
a desarrollar en el presente documento.
Parte II
Desarrollo de la
Investigación
31
Capı́tulo 2
Gestión del Proyecto
2.1. Gestión Técnica

2.1.1. Metodologı́a de Desarrollo
La metodologı́a de desarrollo a utilizar dentro del proyecto es XP (eXtreming
Programing) o Programación Extrema teniendo en cuenta la descomposición
modular que tendrá la aplicación (ver capitulo Arquitectura Técnica) y buscan-
do aprovechar las ventajas que tienen las metodologı́as ágiles de desarrollo.
Después de definidas las historias de usuario y especificada la cantidad de his-

torias de usuario dentro de cada Sprint próximo a desarrollar, se realizará el
desarrollo del mismo.
Una vez finalizado el desarrollo se liberará el Sprint para que se realice la fase
de pruebas, mientras se avanza en el desarrollo de los demás Sprint, y en caso
de existir errores serán corregidos y entregados con el desarrollo del siguiente
Sprint.
El detalle de las historias de usuario se encuentra en la sección Historias de

Usuario al igual que las evidencias de las pruebas ejecutadas.
2.1.2. Gestión de Ambientes

Como se verá en mayor detalle en el capitulo de arquitectura técnica, la
funcionalidad de la aplicación depende de tres componentes que son la base de
datos, el servicio web y la aplicación Android como tal.
Para mantener separados e independientes los ambientes de desarrollo, prue-
bas y producción, se instalarán tres instancias del motor de base de datos, tres
instancias del servidor de aplicaciones para el web service y se generara el ins-
talador de la aplicación Android apuntando a la instancia del web service según
33
34 CAPÍTULO 2. GESTIÓN DEL PROYECTO
corresponda.
El repositorio de los desarrollos de la aplicación Android, del Servicio Web y los

Scripts de creación de objetos de Base de Datos sera un servidor SVN al cual
podrán acceder todos los integrantes del equipo del proyecto desde la Internet.
2.1.3. Historias de Usuario

Como técnica de levantamiento de requerimientos dentro de la metodologı́a
XP se utilizaron las historias de usuario. Mediante éstas, se definieron los com-
portamientos funcionales que debe tener la aplicación, dando de esta manera la
definición del alcance funcional que se espera lograr con la misma.
Cada escenario de las historias de usuario se tomo como un caso de prueba

en la ejecución de las pruebas de caja negra y con base a ello se registran las
evidencias de cada caso de prueba a continuación de cada descripción del esce-
nario correspondiente.
1. Especificación Interfaz Gráfica de Usuario
Identificador (ID) de la Historia: 0-001

Rol: Usuario final
Caracterı́stica/Funcionalidad: Especificación Interfaz Grafica de
Usuario
Razón/Resultado: Especificación visual de la ventana de inicio de
sesión/registro.
Escenarios:
• 1. Cumplimiento de especificación gráfica.
Contexto: Pantalla inicial al abrir la aplicación
Evento: Inicio de la aplicación. El usuario ingresa a la apli-

cación, y esta presenta la pantalla de inicio de sesión/registro.
Resultado/Comportamiento esperado: Se espera que la pan-

talla cumpla con las siguientes caracterı́sticas:
- Presentación del logotipo de la aplicación en la parte central y

superior de la pantalla.
- Campo de email.
- Campo de contraseña.
- Botón para iniciar sesión.
- Botón para registrarse.
- Enlace que permitirá realizar el envı́o de contraseña a un correo
2.1. GESTIÓN TÉCNICA 35
electronico, en caso de olvido de la misma.
Evidencias:
Figura 2.1: Evidencias Historia de Usuario 0-001-1 [fuente: los autores]
2. Registro de usuario
Identificador (ID) de la Historia:0-002
Rol: Usuario final
Caracterı́stica/Funcionalidad:Registro de usuario
Razón/Resultado:Registrar usuario final para que pueda usar la
aplicación
Escenarios:
• 1. Usuario no registrado diligencia correctamente el cam-
po de email y contraseña
Contexto: Pantalla inicial al abrir aplicación
Evento: Usuario abre aplicación y muestra formulario con dos

campos: - Email - Contraseña Los diligencia y presiona el boton
Registrar
Resultado/Comportamiento esperado: Aplicacion envı́a da-

tos a servidor y se realiza el registro del usuario en el sistema.
Servidor responde codigo [00100] que indica que la operación se

realizó exitosamente.
Aplicacion muestra mensaje [Mensaje código INF-1] y Continua
en historia de usuario 1-001
Evidencias:
(a) 0-002-1a (b) 0-002-1b
• 2. Usuario registrado diligencia correctamente el campo

de email y contraseña

Registrar

tos a servidor y el servidor responde codigo 00101 indicando que
el Email ya esta registrado.
Aplicación muestra mensaje [Mensaje código ERR-1] y muestra
nuevamente formulario inicial.
Evidencias:
• 3. Usuario no registrado diligencia incorrectamente el

campo de email

Registrar
Resultado/Comportamiento esperado: Aplicacion no envı́a

datos a servidor.
Validaciones campo Email:

- Debe tener caracter ’@’ después de otros caracteres ASCII
- Debe contener ’.com’, ’.co’, ’.org’, u otro tipo de dominio des-
pues de ’@nombredominio’
Evidencias:
(a) 0-002-3a (b) 0-002-3b
Figura 2.4: Evidencias Historia de Usuario 0-002-3a-b [fuente: los autores]

Figura 2.5: Evidencias Historia de Usuario 0-002-3c [fuente: los autores]
• 4. Usuario no registrado diligencia incorrectamente el

campo de contraseña

Registrar

datos a servidor.
Validaciones campo Contraseña (polı́ticas):

- Debe tener minimo 6 caracteres
Evidencias:
(a) 0-002-4a (b) 0-002-4a
3. Inicio de sesión

Rol: Usuario final
Caracterı́stica/Funcionalidad:Inicio de sesión
Razón/Resultado:Iniciar sesión en la aplicación para poder acceder
a las funcionalidades disponibles
Escenarios:
de email y contraseña que corresponde a ese Email en
el sistema


Ingresar

tos a servidor y se realiza la validación del usuario y clave en el
sistema.
Servidor responde código 00000 que indica que la operación se
realizó exitosamente.
Continua en historia de usuario 1-001

Evidencias:

de email y contraseña pero la contraseña no corresponde
a la registrada en el sistema para ese Email


Ingresar

tos a servidor y el servidor responde codigo [00102] indicando que
la contraseña del usuario es incorrecta.
Evidencias:
• 3. Usuario no registrado diligencia correctamente el cam-

po de email y contraseña


Ingresar

tos a servidor y el servidor responde codigo [00102] indicando que
el Email no esta registrado.
Evidencias:
(a) 0-003-3a (b) 0-003-3a
• 4. Usuario registrado diligencia incorrectamente el cam-

po de email


Ingresar

datos a servidor.
Validaciones campo Email:

- Debe tener caracter ’@’ después de otros caracteres ASCII
- Debe contener ’.com’, ’.co’, ’.org’, u otro tipo de dominio des-
pues de ’@nombredominio’
Evidencias:
(a) 0-003-4a (b) 0-003-4a

• 5. Usuario registrado diligencia incorrectamente el cam-

po de contraseña

Ingresar

datos a servidor.
Validaciones campo Contraseña (polı́ticas):

- Debe tener minimo 6 caracteres
Evidencias:
4. Olvido de contraseña
Identificador (ID) de la Historia: 0-004
Rol: Usuario final
Caracterı́stica/Funcionalidad: Olvido de contraseña
Razón/Resultado: Reiniciar contraseña y enviarla al e-mail del
usuario
Escenarios:
• 1. Usuario registrado selecciona link de olvido de con-
traseña
Contexto: Pantalla inicial al abrir la aplicación
Evento: Inicio de la aplicación. El usuario ingresa a la apli-

cación, y esta presenta la pantalla de inicio de sesión/registro.
Resultado/Comportamiento esperado: Aplicación envı́a so-

licitud a servidor para que envı́e contraseña al e-mail del usuario
registrado. Se envı́a contraseña y muestra mensaje [INF-7] indi-

cando que se envı́o contraseña a su e-mail.
Evidencias:
5. Vista principal después de iniciar sesión

Rol: Usuario final
Caracterı́stica/Funcionalidad:Vista principal después de iniciar
sesión
Razón/Resultado:Definir los elementos que se mostraran despues
de iniciar sesión
Escenarios:
• 1. Cumplimiento de especificación gráfica.
Contexto: Pantalla despues de iniciar sesión
Evento: Usuario inicia sesión exitosamente

Resultado/Comportamiento esperado: Una vez el usuario

inicia sesión en la aplicación, se debe presentar una ventana con
el siguiente contenido:
En área de trabajo central, ubicada en la parte central de la

pantalla:
- Campo de texto para realizar filtro de estaciones.
- Listado de estaciones.
En area de trabajo Opciones. Menú ubicado en la parte superior

derecha de la ventana, representado por el ı́cono de tres puntos
verticales, consta de:
- Ordenar por troncal.
- Ordenar alfabéticamente.
En área de trabajo Menú principal. Menú ubicado en la par-

te superior izquierda, representado por tres lı́neas horizontales,
que despliega un menú lateral, consta de:
- Cambiar contraseña.
- Cerrar sesión.
Evidencias:
(a) 1-001-1a (b) 1-001-1b

6. Área de trabajo central

Rol: Usuario final
Caracterı́stica/Funcionalidad:Área de trabajo central
Razón/Resultado:Definir los elementos del área central y su fun-
cionalidad
Escenarios:
• 1. Listado de estaciones existentes en la base de datos.
Contexto: Presentación del área central de trabajo, en la ven-

tana principal.
Evento: Listado de estaciones
Resultado/Comportamiento esperado: Se debe presentar

un listado de las estaciones que acutalmente se encuentran re-
gistradas en el sistema (base de datos central), presentando el
nombre y troncal de cada una.
Evidencias:
• 2. Mensaje informativo. Fallo de listado de estaciones.
Contexto:
Evento: Listado de estaciones
Resultado/Comportamiento esperado: Para el caso en el

que el consumo del servicio web, que retorna el listado de las
estaciones, no sea exitoso, se debe presentar en la pantalla cen-
tral, un mensaje de notificación de la incidencia, indicando que
la información no está disponible.
La aplicación presenta el mensaje [Mensaje código INF-2], indi-
cando la novedad, y se presenta un botón que permtie recargar la
información, enviando nuevamente la petición al servidor central.
Evidencias:
• 3. Funcionalidad del campo de filtro ubicado dentro del

área central de trabajo.
Contexto:
Evento: Campo de texto para filtrar estaciones por su nom-

bre
Resultado/Comportamiento esperado: Se presenta el cam-

po de texto para buscar una estación por su nombre, al introducir
cualquier texto, el listado de las estaciones deberá modficarse, te-
niendo en cuenta las estaciones en las cuales exista coincidencias
en el nombre con el texto ingresado.
En el caso de que el texto ingresado no coincida con el nombre de
alguna estación, se presentará el mensaje [Mensaje código INF-3].
Evidencias:
(a) 1-002-3a (b) 1-002-3b
7. Área de trabajo Opciones

Rol: Usuario final
Caracterı́stica/Funcionalidad:Área de trabajo Opciones
Razón/Resultado:Definir los elementos del área de trabajo de op-
ciones y su funcionalidad
Escenarios:
• 1. Ordenamiento y agrupación de las estaciones por tron-
cal.
Contexto: Presentación del área de trabajo de opciones
Evento: Ordenar por troncal
Resultado/Comportamiento esperado: El usuario desplie-

ga el menú de opciones, y al seleccionar la opción Ordenar por
troncal, la aplicación realiza un ordenamiento del listado de las
estaciones presentadas, agrupandolas por la troncal respectiva a
cada una de ellas.
Evidencias:
• 2. Ordenamiento alfabéticamente de las estaciones
Contexto:
Evento: Ordenar alfábeticamente
Resultado/Comportamiento esperado: El usuario desplie-

ga el menú de opciones, y al seleccionar la opción Ordenar al-
fabéticamente, la aplicación realiza un ordenamiento alfábetico,
tomando como item de ordenamiento el nombre de la estación.
Evidencias:

8. Área de trabajo Menú principal

Rol: Usuario final
Caracterı́stica/Funcionalidad:Área de trabajo Menú principal
Razón/Resultado:Definir los elemenos del área de trabajo Menú
principal y su funcionalidad.
Escenarios:
• 1. Realizar el cambio de contraseña
Contexto: Presentación del área de trabajo Menú principal
Evento: Selección del menú cambio de contraseña.
Resultado/Comportamiento esperado: La aplicación pre-

senta una pantalla, en la que se muestra el email del usuario, que
está logueado actualmente, ası́ como tres campos de texto, que
constan de: contraseña actual, nueva contraseña, confirmación
de nueva contraseña. A continuación de los campos, se muestra
un botón que realizará el envı́o de la verificación de la informa-
ción suministrada. Las diferentes respuestas que puede tomar la
ejecución de este botón son:
- El usuario no ingresa ningún valor. Para este caso la aplica-

ción presenta el mensaje [Mensaje código ERR-5].- Los valores
suministrados por el usuario en los campos, no coinciden con
las validaciones indicadas para el campo de contraseña, es decir,
longitud mı́nima de 6 caracteres). Para este caso la aplicación
presenta el mensaje [Mensaje código ERR-3].
- Los valores de los campos nueva contraña y confirmación de
nueva contraseña proporcionados por el usuario, no coinciden.
La aplicación presenta el mensaje [Mensaje código ERR-6].
- El valor de la contraseña actual ingresada por el usuario, no
conicide con la que actualmente se encuentra registrada en la ba-
se de datos. La aplicación presenta el mensaje [Mensaje código
ERR-7].Si el proceso de validación es exitoso, para los criterios
mencionados anteriormente, la aplicación realizará el cambio de
contraseña en la base de datos del sistema central, presentará
el mensaje [Mensaje código INF-4], y presentará nuevamente la
ventana principal de la aplicación. (historia de usuario 1-001).
Evidencias:
(a) 1-004-1a (b) 1-004-1b
(a) 1-004-1c (b) 1-004-1d
Figura 2.22: Evidencias Historia de Usuario 1-001-1c-d [fuente: los autores]

(a) 1-004-1e (b) 1-004-1f
Figura 2.23: Evidencias Historia de Usuario 1-001-1c-d [fuente: los autores]
• 2. Funcionamiento submenú Cerrar Sesión
Contexto:
Evento: EL usuario selecciona la opción Cerrar Sesión del menú

principal.
Resultado/Comportamiento esperado: La aplicación deberá

destruir la información que actualmente conserva en memoria
(email y constraseña del usuario logueado), y presentar la pan-
talla principal.
9. Presentación ventana principal módulo buses/rutas

Rol: Usuario final
Caracterı́stica/Funcionalidad:Presentación ventana principal módu-
lo buses/rutas
Razón/Resultado:Definir el comportamiento de la aplicación, cuan-
do se presenta la pantalla principal de los buses/rutas.
Escenarios:
• 1. Usuario logueado selecciona estación y se despliega el
listado de los buses
Contexto: Pantalla despues de seleccionar estación.

Evento: Usuario selecciona estación.
Resultado/Comportamiento esperado: Al seleccionar la es-

tación, la aplicación deberá presentar una nueva pantalla con las
siguientes caracterı́sticas:
Menú de opciones en la parte superior derecha, con las siguientes
opciones:
- Ordenar por nombre
- Ordenar por troncal
Menú lateral ubicado en la parte superior izquierda, que desplie-
ga las mismas opciones presentadas en la pantalla anterior (ver
sprint 2).
Campo de texto que permitirá realizar el filtro de las rutas que
actualmente se presentan.
Barra de color en la parte superior de la pantalla que lista las
rutas de una estación, representando el nivel de congestión de la
estación. Siendo rojo el máximo nivel de congestión y verde el
mı́nimo. (Amarillo y naranja, se presentan como colores de nive-
les intermedios).
Listado de rutas o buses que paran en la estación seleccionada.
Evidencias:
(a) 2-001-1a (b) 2-001-1b

Evento: Usuario selecciona ruta o bus.
Resultado/Comportamiento esperado: Cuando el usuario,

selecciona una ruta o bus, la aplicación deberá presentar una
pantalla emergente que permita realizar la calificación del nivel
de congestión de la parada de la ruta en la estación, y presentar
la pantalla descrita en las historias de usuario 3-xxx. La pantalla
de calificación de la estación debe contar con las siguientes ca-
racterı́sticas:
Nombre de la ruta o bus, estación y troncal de la misma.
Barra slide, que permita establecer la calificación de la parada
de la ruta en la estación.
Botón que permita enviar la información con la calificación de la
parada de la ruta en la estación.
Evidencias:
(a) 2-001-2a (b) 2-001-2b

Evento: Usuario selecciona estación, pero se pierde conexión

con el servicio.
Resultado/Comportamiento esperado: Para este caso la

aplicación deberá retornar código de error ERR-008, y presentar
nuvamente la pantalla del módulo de estaciones.
• 4. Ordenamientos por nombre
Contexto: Usuario selecciona los ordenamientos del panel de

opciones.
Evento: Usuario selecciona ordenamiento por nombre

alterar la lista de buses, teniendo en cuenta el orden alfabético
del nombre de cada ruta.
Evidencias:
• 5. Ordenamiento por troncal destino
Contexto: Usuario selecciona los ordenamientos del panel de

opciones.
Evento: Usuario selecciona ordenamiento por troncal de des-

tino

alterar la lista de buses, teniendo en cuenta el orden alfabético
de la troncal de destino de cada ruta.
Evidencias:

• 6. Búsqueda filtrada
Contexto: Usuario ingresa información dentro del campo de tex-

to de filtro por nombre
Evento: Usuario ingresa información al filtro de buses.

alterar la lista de buses, presentando únicamente los que tengan
coincidencias por el nombre , con la información suministada en
el campo de texto.
Evidencias:
10. Validar el funcionamiento del GPS

Rol: Usuario final
Caracterı́stica/Funcionalidad:Validar el funcionamiento del GPS
Razón/Resultado:Presentar el mensaje acorde a la inconsistencia..
Escenarios:
• 1. Mensaje indicando que el GPS no está activo.
Contexto: Una vez el usuario seleccionó y calificó una ruta,

se valida que el GPS del dispositivo esté activo.
Evento: GPS Inactivo
Resultado/Comportamiento esperado: Si el dispositivo no

tiene habilitado el GPS, se presenta mensaje del código ERR-9 y
re-direcciona la aplicación a la pantalla de la historia de usuario
1-001.
Evidencias:
• 2. Se valida que el GPS esté activo.

se valida que el GPS del dispositivo esté activo.
Evento: GPS Activo
Resultado/Comportamiento esperado: Ejecución de la his-

toria de usuario 3-002.
Evidencias: Ver evidencias en historia de usuario 3-002

11. Visualizar la ubicación aproximada de los buses que transitan en
la ruta seleccionada.

Rol: Usuario final
Caracterı́stica/Funcionalidad:Visualizar la ubicación aproxima-
da de los buses que transitan en la ruta seleccionada.
Razón/Resultado:Se presenta correctamente los componentes gráfi-
cos en la pantalla, posterior a la selección de una ruta
Escenarios:
• 1. Presentación correcta de los componentes definidos
en la pantalla para la ubicación de buses

se presentará en un mapa, la ubicación y nivel de congestión de
los buses que transitan bajo la misma.
Evento: Usuario calificó una ruta en una estación
Resultado/Comportamiento esperado: La pantalla para la

ubicación de buses, estará conformada por los siguientes compo-
nentes gráficos:
1. Menú ubicado en la parte superior derecha, con las siguientes

opciones:
1.1 Ubicar bus menos congestionado
1.2 Ubicar todos los buses
1.4 Abordar Bus XX. Indicando la ruta seleccionada. Ejemplo
B10
1.5 Abordar Bus vacı́o.
2. Menú lateral ubicado en la parte superior izquierda, el cuál

contiene las mismas opciones presentadas la história de usuario
1-001.
3. El área central está compuesta por:

3.1 Botón ubicado en la parte superior, empleado para consultar
de nuevo la información de los buses que transitan en la ruta.
Permanecerá oculto, se describe en el escenario 2 de esta misma
historia de usuario. (Consultar de Nuevo).
3.2 Mapa en el que se mostrará los buses de la ruta seleccionada
y el nivel de congestión. Dibujar bus con color segun nivel de

congestion actual. Se debe emplear Google Maps.
Evidencias:
(a) 3-002-1a (b) 3-002-1b
• 2. Mensaje informando la inconsistencia.
Contexto: Después de calificar la ruta, se presenta un error en

la conexión
Evento: Se presenta un error de conexión, después de calificar

una ruta
Resultado/Comportamiento esperado: Al presentarse un

error de conexión en el consumo del servicio diseñado para la
consulta de los buses que transitan en una ruta o en la genera-
ción del mapa, se presentará el mensaje del código de ERR-8.
Posteriormente se habilitará el botón: (Consultar de Nuevo), y
se repetirá el escenario 1 de la presente historia de usuario.
Evidencias:
Contexto: No se encuentra buses en la ruta calificada.
Evento: Usuario calificó una ruta en una estación
Resultado/Comportamiento esperado: No se encuentran

buses en la ruta calificada, se presenta el mensaje del código
INF-5. Se habilita el botón (Consultar de Nuevo), descrito en el
escenario 2.
Evidencias:
12. Usuario puede ubicar el bus más cercano o el menos congestio-

nado.

Rol: Usuario final
Caracterı́stica/Funcionalidad:Usuario puede ubicar el bus más
cercano o el menos congestionado.
Razón/Resultado:Ubicar un bus en el mapa, acorde al criterio se-
leccionado.
Escenarios:
• 1. Ubicar el bus menos congestionado.
Contexto: El usuario selecciona la opción (Ubicar bus menos

congestionado), del menú superior derecho.
Evento: Seleccionar opción: Ubicar bus menos congestionado.
Resultado/Comportamiento esperado: Se ubicará en el ma-

pa el bus menos congestionado de la ruta calificada y su nivel de
congestión. Dibujar bus con color segun nivel de congestion ac-
tual.
Evidencias:
• 2. Error de conexión al consultar buses de ruta

Evento: Se presenta un error de conexión.

error de conexión en el consumo del servicio diseñado para la

consulta del bus menos congestionado en una ruta, se presen-
tará el mensaje del código ERR-8. Posteriormente se habilitará
el botón: (Consultar de Nuevo), descrito en el escenario 2 de la
historia de usuario 3-002.
Evidencias:
• 3. Seleccionar ruta que no tenga buses registrados en el
momento de la consulta

Evento: No se encuentra buses en la ruta seleccionada.
Resultado/Comportamiento esperado: Si no se encuentra

información de buses que transitan en la ruta seleccionada, se
presenta el mensaje del código INF-5. Posteriormente se habili-
tará el botón: (Consultar de Nuevo), descrito en el escenario 2
de la historia de usuario 3-002.
Evidencias:
Figura 2.33: Evidencias Historia de Usuario 3-003-3[fuente: los autores]

• 4. Ubicar todos los buses.
Contexto: El usuario selecciona la opción (Ubicar todos los bu-

ses), del menú superior derecho.
Evento: Seleccionar opción: Ubicar todos los buses.
Resultado/Comportamiento esperado: Se ejecutará el es-

cenario 1 de la historia de usuario 3-002.
Evidencias:
13. Se requiere abordar Bus y calificar nivel de congestión del mis-

mo.

Rol: Usuario final
Caracterı́stica/Funcionalidad:Se requiere abordar Bus y calificar
nivel de congestión del mismo.
Razón/Resultado:Calificar el nivel de congestión de un bus
Escenarios:
Contexto: Al seleccionar la opción (Abordar Bus), del menú

superior derecho, se validará las condiciones básicas.
Evento: Validación de GPS Inactivo.
Resultado/Comportamiento esperado: Si el dispotivo no

tiene habilitado el GPS, se presenta mensaje del código WAR-
3 y se redirecciona la aplicación a la pantalla de la historia de
usuario 1-001.
Evidencias:
• 2. Valida la distancia entre la estación y el usuario

Evento: Distancia entre usuario y estación no es válida
Resultado/Comportamiento esperado: Si la distancia en-

tre la ubicación actual del usuario y de la estación es mayor a

un valor determinado, se presenta el mensaje del código WAR-2
y se ejecuta la historia de usuario 3-002.
Evidencias:
• 3. Valida la distancia entre el usuario y el bus que lleva

la ruta determinada

Evento: Distancia entre usuario y bus no es válida.
Resultado/Comportamiento esperado: Si la distancia en-

tre la ubicación actual del usuario y de un bus es mayor a un
valor determinado, se presenta el mensaje del código WAR-5 y
se ejecuta la historia de usuario 3-002.
Evidencias:

en la pantalla para el abordaje de bus.

superior derecho.
Evento: Al seleccionar la opción (Abordar Bus)
Resultado/Comportamiento esperado: La pantalla para el

abordaje de un bus está compuesta por los siguientes componen-
tes (El comportamiento de cada uno se describe en las siguientes
historias de usuario):
1. Menú lateral ubicado en la parte superior izquierda, el cuál

contiene las mismas opciones presentadas la historia de usuario
1-001.
2. Menú ubicado en la parte superior derecha, con las siguientes

opciones:
2.1 Ubicar buses de ruta.
3. El área central está compuesta por:

3.1 Barra de calificación en la que se indica el nivel de congestión
del bus que será abordado. La barra presentará un formato de
color (degradado desde verde (indicando que no hay congestión
dentro del bus) hasta rojo (indicando un nivel alto de congestión
dentro del bus)). Una vez se realice la calificación, se ocultará.
Inicialmente el indicador de la barra está en la mitad.
3.2 Botón Calificar Bus.
3.3 Mensaje de código INF-6. Sólo será visible cuando se haya
calificado exitosamente el nivel de congestión del bus.
3.4 Botón para finalizar viaje (Finalizar Viaje). Sólo será visible
cuando se haya calificado exitosamente el nivel de congestión del
bus.
Evidencias:
(a) 3-004-4a (b) 3-004-4b
Figura 2.39: Evidencias Historia de Usuario 3-004-4c[fuente: los autores]

• 5. Ubicar todos los buses.
Contexto: El usuario selecciona la opción (Ubicar todos los bu-

ses), del menú superior derecho en la pantalla para el abordaje
de bus.
Evento: Seleccionar opción: Ubicar todos los buses.
Resultado/Comportamiento esperado: Se ejecuta la histo-

ria de usuario 3-002.
Evidencias:
(a) 3-004-5a (b) 3-004-5b

• 6. Mensaje de confirmación.
Contexto: El usuario califica el nivel de congestión del bus.
Evento: Al seleccionar el botón calificar bus.
Resultado/Comportamiento esperado: Al seleccionar el botón,

se presenta un mensaje de confirmación con las opciones si o nó.
El mensaje corresponde al código WAR-4. Al seleccionar No, se
direccionará a la pantalla descrita en el escenario 4 de la presen-
te historia de usuario (3-004). Al seleccionar Si, continua el flujo
hacia el siguiente escenario.
Evidencias:
Evento: Se presenta un error de conexión.

error de conexión en el consumo del servicio diseñado para califi-

car el nivel de congestión de un bus, se presentará el mensaje del
código ERR-8. Posteriormente se presentará de nuevo los com-
ponentes descritos en el escenario 1.
Evidencias:
durante el viaje del usuario en el bus.
Evento: Calificación de nivel de congestión de bus
Resultado/Comportamiento esperado: Después de calificar

el nivel de congestión de bus, se habilita los siguientes compo-
nentes: 3.3 y 3.4 descritos en el escenario 4 de la presente historia
de usuario(3-004).
Evidencias:
14. Se requiere abordar Bus vacı́o.

Rol: Usuario final

Caracterı́stica/Funcionalidad:Se requiere abordar Bus vacı́o.
Razón/Resultado: Abordar un bus vacı́o para que pueda ser vi-
sualizado por los usuarios
Escenarios:
• 1. Abordar bus vacı́o
Contexto: El usuario aborda un que no tiene pasajeros, por

lo cual tampoco se muestra en la lista de buses consultados en
una ruta especifica
Evento: Seleccionar opción Abordar Bus vacı́o
Resultado/Comportamiento esperado: El comportamiento

debe ser el mismo de la historia de usuario 3-004. La única ex-
cepción es que no debe validar la distancia entre el usuario y el
bus, ya que el bus se creará por primera vez con esta acción.
Evidencias:

15. Se requiere enviar la ubicación actual del usuario durante el

viaje.
Rol: Usuario final
Caracterı́stica/Funcionalidad:Se requiere enviar la ubicación ac-
tual del usuario durante el viaje.
Razón/Resultado: Enviar a un servicio la ubicación de un usuario.
Escenarios:
• 1. Actualización de la ubicación actual del usuario.
Contexto: Enviar periodicamente la ubicación actual del usua-

rio durante el viaje en el bus.
Evento: Enviar ubicación del usuario
Resultado/Comportamiento esperado: Posterior a la califi-

cación del nivel de congestión del bus, la aplicación enviará en un
cierto periodo de tiempo (parametrizado en un archivo de confi-
guración, inicializado en 30 segundos) a un servicio, la ubicación
actual del usuario durante el viaje en el bus. De esta manera, con
la información enviada desde cada dispositivo de los usuarios que
viajan en un determinado bus, se podrá establecer una ubicación
aproximada del mismo.
Evidencias:
Esta ejecución se realiza en segundo plano, por lo cual no es
posible tomar una evidencia de la aplicación móvil. Al realizar la
prueba se verificó que llegara la solicitud al WS y que se guardará
correctamente la información en la base de datos.
16. Finalizar Viaje
Rol: Usuario final
Caracterı́stica/Funcionalidad:Finalizar Viaje
Razón/Resultado:Enviar una notificación al servicio, que se encar-
ga de detener el proceso de actualización de la ubicación actual del
usuario.
Escenarios:
• 1. Finalización de viaje
Contexto: El usuario ha seleccionado la ruta que abordará, ca-

lificado el estado de la misma, y se encuentra próximo a terminar
su recorrido.
Evento: Se finaliza el viaje, y se presenta nuevamente la panta-

lla que lista las estaciones.
Resultado/Comportamiento esperado: Una vez el usuario

ha seleccionado y calificado la ruta que desea; se presenta el ma-
pa los diferentes buses que están actualmente en servicio. En el
mapa se deberá mostrar un botón flotante que permite finalizar
el viaje. Para el proceso de finalización del viaje, se deberá dete-
ner el proceso de actualización de ubicación actual del usuario y
presentar la pantalla que lista las estaciones. Historia de usuario
1-001.
Evidencias:
Después de presionar el botón de finalizar sesión se mostró nue-
vamente el listado de estaciones como se esperaba.
17. Portal de Administración

Rol: Usuario administrador
Caracterı́stica/Funcionalidad: Administrar Información del Sis-

tema de Información
Razón/Resultado: Realizar la gestión (Crear, Leer, Actualizar, Bo-
rrar) de la información de Troncales, Estaciones, Rutas y relación
Ruta-Estación.
Escenarios:
• 1. Gestión de Troncales
Contexto: El usuario administrador ingresa a la opción de Ges-

tión de Troncales
Evento: Se realizan las distintas operaciones de gestión permi-

tidas al usuario administrador sobre las troncales
Resultado/Comportamiento esperado: Se realiza la crea-

ción, modificación, lectura y borrado de Troncales de manera
exitosa.
Evidencias:
VISTA PRINCIPAL DE PORTAL DE ADMINISTRACIÓN

CREACIÓN DE TRONCAL
Figura 2.47: Evidencias Historia de Usuario 4-001-1a[fuente: los autores]
EDICIÓN DE TRONCAL
Figura 2.48: Evidencias Historia de Usuario 4-001-1b[fuente: los autores]

CONSULTA DE TRONCAL
ELIMINACIÓN DE TRONCAL
Figura 2.50: Evidencias Historia de Usuario 4-001-1d[fuente: los autores]
• 2. Gestión de Estaciones

tión de Estaciones

tidas al usuario administrador sobre las Estaciones

ción, modificación, lectura y borrado de Estaciones de manera
exitosa.
Evidencias:
LISTADO DE ESTACIONES
CREACIÓN DE ESTACIÓN

EDICIÓN DE ESTACIÓN
CONSULTA DE ESTACIÓN

ELIMINACIÓN DE ESTACIÓN
Figura 2.55: Evidencias Historia de Usuario 4-001-2e[fuente: los autores]
• 3. Gestión de Rutas

tión de Rutas

tidas al usuario administrador sobre las Rutas

ción, modificación, lectura y borrado de Rutas de manera exitosa.
Evidencias:
LISTADO DE RUTAS

CREACIÓN DE RUTA
EDICIÓN DE RUTA

CONSULTA DE RUTA
• 4. Gestión de Rutas por Estación

tión de Rutas por Estación

tidas al usuario administrador sobre las Rutas por Estación

ción, modificación, lectura y borrado de Rutas por Estación de
manera exitosa.
Evidencias:
LISTADO DE RUTAS POR ESTACIÓN (PARADA)

EDICIÓN DE RUTA POR ESTACIÓN (PARADA)
CONSULTA DE RUTA POR ESTACIÓN (PARADA)

ELIMINACIÓN DE RUTA POR ESTACIÓN (PARADA)
2.1.4. Mensajes de Error, Informativos y de advertencia

Dentro de las historias de usuario se mencionan algunos mensaje que deben
aparecer en la aplicación, los cuales se listan a continuación:
1. TABLA DE MENSAJES INFORMATIVOS
Cuadro 2.1: MENSAJES INFORMATIVOS
MENSAJES INFORMATIVOS
Numeral Mensaje
INF-1 Usuario registrado exitosamente.
INF-2 Infomación no disponible. Intentelo de nuevo.
INF-3 No se encontró nombre de estación con el texto ingresado.
INF-4 Cambio de contraseña exitoso.
INF-5 No se encontró información de buses en la ruta seleccionada.
INF-6 Usted abordó un bus de la ruta XXX.
2. TABLA DE MENSAJES DE ADVERTENCIA
Cuadro 2.2: MENSAJES DE ADVERTENCIA
Numeral Mensaje
WAR-1 Email inválido.
WAR-2 No es posible abordar un bus estando lejos de una estación.
WAR-3 El GPS del dispositivo no está activo.
WAR-4 Está seguro que desea calificar el nivel de congestión del bus?
WAR-5 No es posible abordar un bus si no se ha registrado uno cerca a la estación.
3. TABLA DE MENSAJES DE ERROR
Cuadro 2.3: MENSAJES DE ERROR
Numeral Mensaje
ERR-1 Email ya registrado.
ERR-2 Email inválido.
ERR-3 Contraseña inválida.
ERR-4 Credenciales inválidas.
ERR-5 Debe diligenciar los campos.
ERR-6 La nueva contraseña y la confirmación deben ser iguales.
ERR-7 La contraseña actual es incorrecta.
ERR-8 No se pudo establecer conexión con el servidor central.
2.1.5. Definición de estructuras de datos

Con base en las definiciones funcionales generadas con las historias de usua-
rio en cada sprint, se inicia la definición técnica de los componentes de software
necesarios para lograr la funcionalidad esperada.
A continuación la definición de las estructuras de datos (tablas de base de datos)

especificadas en cada sprint de desarrollo:
1. Tabla Users
Cuadro 2.4: Tabla Users
Nombre de Campo Tipo de Dato Llave

idUser int (identity) PK
email varchar(100)
password varchar(1000)
registserDate DateTime
lastModificationDate DateTime
2. Tabla ResponseCodes
Cuadro 2.5: Tabla ResponseCodes

code varchar(5) PK
type varchar(3) PK
description varchar(200)
3. Tabla Troncals
Cuadro 2.6: Tabla Troncals

code int (autoincrement) PK
identificator char(1) PK
name varhcar(100
color varchar(7)
4. Tabla Routes
Cuadro 2.7: Tabla Routes

routeCode int(identity) PK
name varchar(5)
5. Tabla Stations
Cuadro 2.8: Tabla Stations

stationCode int (identity) PK
name varchar(100)
troncal int FK
registserDate DateTime
lastModificationDate DateTime
latitude numeric(3,15)
long numeric(3,15)
6. Tabla RouteStatation
Cuadro 2.9: Tabla RouteStatation

routeStationCode int(identity) PK
stationCode int FK
routeCode int FK
stationIndicator int
7. Tabla RouteStationQualification
Cuadro 2.10: Tabla RouteStationQualification

routeStationQualificationCode int(identity) PK
qualification int
routeStationCode int FK
dateQualification dateTime()
userId int FK
8. Tabla BusRouteQualification
Cuadro 2.11: Tabla BusRouteQualification

busRouteQualificationCode int(identity) PK
qualification int
routeCode int FK
idBus int FK
dateQualification dateTime()
userId int FK
9. Tabla Bus
Cuadro 2.12: Tabla Bus

idBus int(identity) PK
initialLatitude decimal(9,6)
initialLongitude decimal(9,6)
qualification int
routeCode int FK
lastUpdateDate dateTime()
10. Tabla BusPosition
Cuadro 2.13: Tabla BusPosition

idBusPosition int(identity) PK
actualLatitude decimal(9,6)
actualLongitude decimal(9,6)
dateTimePosition dateTIme()
idBus int FK
2.1.6. Definición de estructura del servicio web

1. Método OpRegisterUser
Cuadro 2.14: Método OpRegisterUser
OpRegisterUser
Request Response
Nombre Tipo Longitud Longitud Nombre Tipo Longitud Longitud
Campo Dato Mı́nima Máxima Campo Dato Mı́nima Máxima
email string 5 NA resposeCode string 9 NA
password string 6 NA message string 10 NA
2. Método OpLoginSession
Cuadro 2.15: Método OpLoginSession
OpLoginSession
Request Response
email string 5 NA resposeCode string 9 9
3. Método OpGetStations
Cuadro 2.16: Método OpGetStations
OpGetStations
Request Response
NA NA NA NA stationCode int 1 NA
NA NA NA NA name string 3 50
NA NA NA NA idTroncal int 1 NA
NA NA NA NA troncal string 4 13
NA NA NA NA identificatorTroncal char 1 1
NA NA NA NA colorTroncal string 7 7
4. Método OpChangePassword
Cuadro 2.17: Método OpChangePassword
OpChangePassword
Request Response
email string 5 NA resposeCode string 9 9
newPassword string 6 NA
5. Método OpSetRouteStationQualification
Cuadro 2.18: Método OpSetRouteStationQualification
OpSetRouteStationQualification
Request Response
routeStationCode int 1 NA resposeCode string 9 9
qualification int 1 NA message string 10 NA
user String 1 NA
6. Método OpGetStationQualification
Cuadro 2.19: Método OpGetStationQualification
OpGetStationQualification
Request Response
stationCode int 1 NA responseCode string 1 NA
stationCode int 1 NA qualification int 1 NA
7. Método OpGetRoutesStations
Cuadro 2.20: Método OpGetRoutesStations
OpGetRoutesStations
Request Response
stationCode int 1 NA routeCode int 1 NA
stationCode int 1 NA name string 1 5
stationCode int 1 NA stationName string 1 100
stationCode int 1 NA nameStartStation string 1 100
stationCode int 1 NA troncalName string 1 100
stationCode int 1 NA nameFinishStation string 1 100
stationCode int 1 NA troncalColor string 1 7
stationCode int 1 NA routeStationCode int 1 NA
8. Método OpGetRouteStationQualification
Cuadro 2.21: Método OpGetRouteStationQualification
OpGetRouteStationQualification
Request Response
stationCode int 1 NA responseCode string 1 NA
9. Método OpSetQualificationBusRoute
Cuadro 2.22: Método OpSetQualificationBusRoute
OpSetQualificationBusRoute
Request Response
routeCode int 1 NA responseCode string 1 NA
idBus int 1 NA qualification int 1 NA
qualification int 1 NA
10. Método OpGetRouteQualification
Cuadro 2.23: Método OpGetRouteQualification
OpGetRouteQualification
Request Response
routeCode int 1 NA responseCode string 1 NA
11. Método OpGetBus
Cuadro 2.24: Método OpGetBus
OpGetBus
Request Response
routeCode int 1 NA idBus int(identity) 1 NA
routeCode int 1 NA latitudInitial numeric 1 NA
routeCode int 1 NA longitudeInitial numeric 1 NA
routeCode int 1 NA qualification int 1 NA
routeCode int 1 NA routeCode int 1 NA
routeCode int 1 NA lastUpdateDate dateTime() NA NA
2.2. GESTIÓN DE COMUNICACIONES 97
12. Método OpSetBusPosition
Cuadro 2.25: Método OpSetBusPosition
OpGetBus
Request Response
idBus int 1 NA responseCode int 1 NA
latitudeActual int 1 NA messageResponse string 1 NA
longitudeActual int 1 NA
13. Método OpCreateBus
Cuadro 2.26: Método OpCreateBus
OpCreateBus
Request Response
routeCode int 1 NA responseCode int 1 NA
qualification int 1 NA messageResponse string 1 NA
initialLatitude int 1 NA idBus int 1 NA
initialLongitude int 1 NA idBus int 1 NA
2.2. Gestión de Comunicaciones

A nivel general dentro del proyecto se maneja una comunicación personal
en el horario de clase que se dispone para la especialización cursada. Las de-
finiciones funcionales, técnicas, de documentación, etc., son realizadas usando
video-llamadas de Hangouts.
Las historias de usuario, definiciones de estructura de base de datos y estructura
de servicio web son guardadas en hojas de calculo de Google Drive en una car-
peta a la cual tienen permiso de acceso todos los integrantes del equipo, tanto
para consulta como para modificación.
Capı́tulo 3
Arquitectura Funcional
Para representar los distintos puntos de vista de la arquitectura funcional

se utilizara el lenguaje Archimate 2.0 en cada una de las secciones que se
presentan a continuación.
3.1. Vista Motivacional

La vista motivacional representa las razones por las cuales se llega a pensar en
un cambio de arquitectura empresarial, o en nuestro caso, las motivaciones que
llevan al equipo del proyecto a realizar una propuesta para atacar el problema
especifico planteado en capı́tulos anteriores. [28]
3.1.1. Metamodelo
Figura 3.1: Metamodelo Vista Motivacional [28]
99
100 CAPÍTULO 3. ARQUITECTURA FUNCIONAL
3.1.2. Vista Motivacional iTransAgilApp
Figura 3.2: Vista Motivacional iTransAgilApp [fuente: los autores]
La vista motivacional del proyecto muestra que los stakeholders, quienes

somos los mismos integrantes del equipo del proyecto, basados en un Driver es-
pecifico que es las decisiones que toman los usuarios en el momento de abordar
una u otra ruta. Con base en ello se identifica una debilidad que tiene el ST que
es la falta de información sobre el estado del ST en tiempo real y que pueda ser
consultada por el usuario; ası́ mismo nos enfocamos en tres ı́tem especı́ficos de
esa falta de información.
Con base en el assessment identificado y sus agregaciones, se plantea el ob-

jetivo de brindar esa información a los usuarios del ST, basado en esos objetivos
se generan unos requerimientos especı́ficos para buscar cumplir mismos.
3.2. Vista Proceso de Negocio

La vista de proceso de negocio muestra la estructura de alto nivel de y la
composición de uno o mas procesos de negocio. [28]
3.2. VISTA PROCESO DE NEGOCIO 101
3.2.1. Metamodelo
Figura 3.3: Metamodelo Vista Proceso de Negocio [28]
3.2.2. Vista Proceso de Negocio iTransAgilApp
Figura 3.4: Vista Proceso de Negocio iTransAgilApp [fuente: los autores]
La vista de proceso de negocio de iTransAgilApp identifica el actor principal

que es el usuario del ST que cumple el rol de usuario del dispositivo móvil.
Los servicios que permiten resolver los requerimientos identificados en la vista
anterior, son accedidos por el usuario a través de la interfaz (aplicación Android).
Dichos servicios son realizados por una serie de procesos internos que permi-
ten cumplir el objetivo de brindar esa información especifica a los usuarios del
ST.
102 CAPÍTULO 3. ARQUITECTURA FUNCIONAL
Capı́tulo 4
Arquitectura Técnica
En esta sección se empleará el lenguaje Archimate versión 2.0, para presentar

gráficamente la descripción y relación de los diferentes componentes técnicos di-
señados para el desarrollo del sistema de información propuesto. Para lo anterior
se realizaran las diferentes vistas de la capa de aplicación:
4.1. Vista Comportamiento de Aplicación

Esta vista describe el comportamiento de una aplicación, definiendo sus ser-
vicios, funciones y sus interrelaciones. [28]
4.1.1. Metamodelo
Figura 4.1: Metamodelo Vista Comportamiento de Aplicación [28]
103
104 CAPÍTULO 4. ARQUITECTURA TÉCNICA
4.1.2. Vista Comportamiento de Aplicación iTransAgilApp
Figura 4.2: Vista Comportamiento de Aplicación iTransAgilApp [fuente: los

autores]
Mediante la vista de comportamiento de aplicación, se describen los 3 prin-

cipales componentes del sistema de información: Aplicación Android iTransAgi-
lApp, Aplicación Web y Servicio Rest
A continuación, se describen los componentes y funciones del servicio autenti-

cación, calificación de estaciones, calificaciones de buses, creación de estaciones
y creación de rutas:
ITransAgilApp es una aplicación móvil para dispositivos con sistema operativo

4.2. VISTA COOPERACIÓN DE APLICACIÓN 105
Android, mediante la cual el usuario podrá autenticarse para poder consultar

y/o calificar estaciones y buses.
Aplicación Web permite la creación y actualización de estaciones y rutas.
Finalmente, todas las funciones son accesibles mediante operaciones publicadas

en servicios rest, con los cuales toda la información es almacenada, consultada
y actualizada en la base de datos.
4.2. Vista Cooperación de Aplicación

Describe las relaciones y flujos de información existentes entre los diferentes
componentes de aplicación. Adicionalmente permite modelar la cooperación in-
terna entre los servicios que soportan la ejecución de los procesos de negocio.
[28]
4.2.1. Metamodelo
Figura 4.3: Metamodelo Vista Cooperación de Aplicación [28]
4.2.2. Vista Cooperación de Aplicación iTransAgilApp

En el diagrama, se describe gráficamente que los componentes iTransAgi-
lApp y Aplicación Web usan el componente Servicio Rest, el cual tiene acceso
directo a la base de datos, haciendo uso de otro componente denominado Motor
de base de datos SQLSever.
Figura 4.4: Vista Cooperación de Aplicación iTransAgilApp [fuente: los autores]
4.3. Vista Estructura de Aplicación

Este punto de vista muestra la estructura de una o varias aplicaciones o com-
ponentes. Presenta una herramienta útil para entender la estructura de compo-
nentes o aplicaciones. [28]
4.3.1. Metamodelo
Figura 4.5: Metamodelo Vista Estructura de Aplicación [28]
4.3.2. Vista Estructura de Aplicación iTransAgilApp

iTransAgilApp
La vista describe las interfaces publicadas por el componente Servicio Rest.
Estas interfaces son representadas como operaciones, las cuales son usadas por el
4.4. VISTA USO DE APLICACIÓN 107
Figura 4.6: Vista Estructura de Aplicación iTransAgilApp [fuente: los autores]
componente iTransAgilApp y Aplicaciones Web. Ver figura 4.6 Vista Estructura

de Aplicación
4.4. Vista Uso de Aplicación

Este punto de vista permite describir como los componentes de aplicación
soportan o son usados por los procesos de negocio. Permite el diseño de una
aplicación al identificar los servicios necesarios por los procesos de negocio y
otras aplicaciones. [28]
4.4.1. Metamodelo
Figura 4.7: Metamodelo Vista Uso de Aplicación [28]

4.4.2. Vista Uso de Aplicación iTransAgilApp
Figura 4.8: Vista Uso de Aplicación iTransAgilApp [fuente: los autores]
En el diagrama propuesto para presentar el punto de vista uso de aplicación,

se relaciona los servicios definidos en la vista de comportamiento, con los pro-
cesos planteados en la arquitectura funcional. De esta manera se describe cómo
la capa de aplicación ofrece y expone servicios para suplir las necesidades de la
capa de negocio. Ver figura 4.8: Vista Uso de Aplicación iTransAgilApp
4.5. Vista Infraestructura

Este punto de vista permite especificar los elementos de infraestructura,
tanto hardware como software de plataforma que soportan toda la capa de
aplicación. [28]
4.5.1. Metamodelo
Figura 4.9: Metamodelo Vista Infraestructura [28]

4.6. VISTA USO DE INFRAESTRUCTURA 109
4.5.2. Vista Infraestructura iTransAgilApp
Figura 4.10: Vista Infraestructura iTransAgilApp [fuente: los autores]
4.6. Vista Uso de Infraestructura

Este punto de vista relaciona la capa fı́sica de la infraestructura con la capa
lógica de aplicación, especificando de que manera son soportadas dichas aplica-
ciones en las plataformas de Hardware/Software respectivas. [28]
4.6.1. Metamodelo
Figura 4.11: Metamodelo Vista Uso de Infraestructura [28]

4.6.2. Vista Infraestructura iTransAgilApp
Figura 4.12: Vista Uso de Infraestructura iTransAgilApp [fuente: los autores]

Parte III
Cierre de la Investigación
111
Capı́tulo 5
Resultados y discusión
El objetivo general ası́ como cada uno de los objetivos especı́ficos se lograron
en su totalidad ya que se genero un producto de alta calidad, tanto en el sistema
de información compuesto por la base de datos y el servicio REST que la con-
sulta/alimenta, como en la aplicación móvil Android que utiliza dicho sistema
de información.
Se desarrollo exitosamente el módulo de administración WEB que permitirá

realizar la gestión de estaciones, rutas, y relación de ruta/estación (paradas de
cada ruta en determinadas estaciones).
De la misma manera los módulos de recolección de información y consulta de
la misma dentro de la aplicación Android que permitirá mostrar la información
en los Smartphone de los usuarios del sistema transmilenio.
Se tuvo como premisa la simplicidad en la aplicación y la facilidad de uso para

que los viajeros en el sistema transmilenio no inviertan mucho tiempo ni esfuerzo
en obtener la información y en calificar estaciones/buses.
113
114 CAPÍTULO 5. RESULTADOS Y DISCUSIÓN
Capı́tulo 6
Conclusiones
6.1. Verificación, contraste y evaluación de los

objetivos
Debido a que el ST está sometido a cambios constantes para satisfacer las

necesidades de los usuarios, se requiere la implementación de un módulo
de administración que permita almacenar y actualizar la información de
estaciones y rutas, de esta manera se podrá contar con información real
y actualizada en la base de datos. Este módulo de administración será
publicado en un ambiente web, siendo accesible para una cantidad limitada
de usuarios, asociados a un rol especı́fico.
El éxito de la implementación del sistema de información propuesto en esta

investigación, depende 100 por ciento de la recolección de información de la
fuente primaria, en este caso la suministrada por los usuarios. Se requiere
una participación de una gran cantidad de usuarios, para poder determinar
un nivel de congestión, al igual que la ubicación geográfica de estaciones
y buses, que sean lo más aproximado posible a la realidad, con el objetivo
de presentar a los mismos una herramienta útil de apoyo para la toma de
decisiones.
A pesar de que existen limitaciones como seguridad, acceso a internet por

medio de redes móviles, uso de dispositivos e incluso la aceptación de los
usuarios, sabemos que esta idea, puede influir en la mejora de la calidad del
servicio de transporte, siempre y cuando una comunidad entera sea quien
suministre los datos necesarios, para poder generar información precisa y
coherente.
115
116 CAPÍTULO 6. CONCLUSIONES
6.2. Sı́ntesis del modelo propuesto

Teniendo en cuenta que el objetivo principal de la investigación, constituı́a la
construcción de una aplicación móvil, basada en tecnologı́a Android, para llegar
a la solución del problema que en principio se desea atacar, se inició un proceso
de investigación de diferentes alternativas, dentro de las cuales resaltan portales
web, modificaciones a nivel interno del sistema Transmilenio, entre otras.
No obstante, por diferentes motivos presentados previamente (a lo largo del

documento), la alternativa tomada para solucionar el problema planteado, fue
el desarrollo de una aplicación móvil, que sirva como herramienta principal para
la toma de decisiones al momento del uso del sistema transmilenio.
Para llevar a cabo el proceso de construcción del prototipo, inicialmente se

debieron establecer unos alcances preliminares del mismo, teniendo en cuenta el
tiempo del que se disponı́a para el desarrollo de la investigación, los recursos en
tiempo y dinero y los conocimientos con los que contaba el equipo de trabajo.
Una vez definidos los alcances de la aplicación se procedió a iniciar el proceso
de diseño de la aplicación ası́ como un análisis motivacional y/o de viabilidad
del proyecto.
Durante la etapa de concepción y planeación del proyecto, como parte del méto-
do que se abordó para el proceso investigativo, se realizó la creación de un crono-
grama general, dentro del cual posteriormente y en conjunto con la concepción
de la EDT (Estructura de Desglose de Trabajo) se detallaron las actividades
que deberı́an ser ejecutadas, teniendo en cuenta su espacio en el cronograma.
El planteamiento de la metodologı́a de desarrollo (metodologı́a de desarrollo

XP), mecanismos de levantamiento de requerimientos (historias de usuario), se-
lección de tecnologı́as (Android para el desarrollo del prototipo de aplicación
móvil, tecnologı́a REST para el desarrollo del servicio que será consumido por
la aplicación, SQLSERVER como motor de base de datos), fueron los siguien-
tes pasos a seguir para el modelo de investigación del proyecto. Teniendo en
cuenta que se utilizó una metodologı́a de desarrollo incremental, se realizó el
planteamiento, ejecución y cierre de cada etapa realizando una retroalimenta-
ción, dentro del equipo, de cada ciclo o sprint.
Durante todo el proceso se realizó un seguimiento al cumplimiento de las activi-

dades establecidas en el sprint que se estuviera ejecutando, teniendo en cuenta
el seguimiento del desarrollo, diseño de pruebas y ejecución de las mismas. Fi-
nalmente, se realiza el cierre de la investigación, ajustando pormenores finales
de la aplicación, cerrando las fases de planeación, cronograma y presupuesto.
En resumen, el método usado para desarrollar el proyecto, presentó bastantes

beneficios en particular a la hora del desarrollo de la aplicación (objetivo prin-
cipal del proyecto), facilitando el desarrollo modular del proyecto optimizando
6.3. APORTES ORIGINALES 117
la cantidad de recursos invertidos, y permitiendo alcanzar el objetivo dentro del

plazo especificado. Las principales ventajas que se perciben del método usado
para el desarrollo del proyecto, es la adecuada planificación de las tareas y la
optimización del uso de los recursos disponibles, principalmente el tiempo. Te-
niendo en cuenta los diferentes aportes que el equipo de trabajo recibió durante
el transcurso del postgrado, representaron una ayuda sustancial no solo en el
progreso del proyecto sino en la organización del mismo.
Como lecciones aprendidas y oportunidades de mejora se tiene una planeación

más puntual de los requerimientos y de los alcances del proyecto, esto evitará
tener que hacer cambios inesperados sobre la marcha. El método usado para
comunicar decisiones, cambios, ajustes, planeaciones, entre otros, puede mejo-
rarse con el crecimiento del proyecto, dado que en determinadas ocasiones se
tendrán alcances diferentes, e ı́tems que requerirán de una precisión y atención
más puntual; luego el equipo de trabajo debe estar cohesionado y actuar en pro
del cumplimiento de las diferentes obligaciones.
6.3. Aportes originales

Tomando como punto inicial para este segmento los alcances de la aplicación
y teniendo en cuenta que se presentan limitaciones de acuerdo al desarrollo de
la aplicación, principalmente los aportes que se plantean para el uso de la inves-
tigación son esencialmente para el área administrativa del ST; la cual a partir
de la información capturada por la aplicación podrı́a implementar un modelo de
administración de recursos (buses y diseño de rutas) que permitiera optimizar el
diseño de las rutas y velocidad de respuesta ante represamientos en el Sistema
Transmilenio.
La arquitectura pensada para el proyecto permitirá el uso del sistema de in-

formación (principalmente la base de datos), como un punto de partida de un
análisis inteligente acerca del funcionamiento cotidiano del sistema de Transmi-
lenio, pero más importante aún, de cómo los usuarios intervienen tı́picamente
en el mismo y como perciben el funcionamiento general del mismo.
El principal aporte que arroja el proyecto, es el uso sustancial de la información

que será recolectada por la aplicación; dado que ésta es enviada directamente
por los usuarios del ST, y consolidada de manera tal que se facilita un acceso
sencillo y directo a la misma, que puede ser usada como fuente en propuestas
de modelos para la optimización del diseño de rutas del Sistema Transmilenio.
6.4. Trabajos o publicaciones derivadas

El desarrollo del proyecto permitió crear una herramienta que con el pasar
del tiempo y el uso correcto por parte de los usuarios puede ser fuente para
118 CAPÍTULO 6. CONCLUSIONES
otros proyectos o artı́culos relacionados con el sistema de transporte masivo

Transmilenio de Bogotá-Colombia. El aporte en temas como las causas de la alta
congestión, comportamiento de los usuarios ante ciertos eventos en el sistema,
medición de capacidad de reacción por parte de la administración del sistema
Transmilenio, y otros temas que puedan usar la información procesada por la
aplicación desarrollada en el proyecto.
Capı́tulo 7
Prospectiva del trabajo de

Grado
7.1. Lı́neas de investigación futuras

Las lı́neas de investigación futuras identificadas en el desarrollo del proyecto
son:
Administración de Sistemas de transporte masivo basados en la informa-

ción suministrada por los usuarios
Análisis de comportamiento de los usuarios en un sistema de transporte
masivo en el uso del mismo
Correcto diseño de rutas en un sistema de transporte masivo

Implementación de algoritmos de búsqueda de ruta mas rápida en el sis-
temas de transporte masivo
7.2. Trabajos de investigación futuros

Ası́ mismo, los trabajos de investigación futuros se encuentran en los mismos
enfoques:
Implementación de algoritmos de búsqueda de ruta más rápida para los

usuarios en el uso del Sistema Transmilenio
Análisis y diseño de rutas del Sistema Transmilenio basadas en la infor-
mación suministrada por los usuarios
119
120 CAPÍTULO 7. PROSPECTIVA DEL TRABAJO DE GRADO
Bibliografı́a
[1] Togaf R 9.1 - part ii: Architecture development method (adm), 1999.
[2] The open group ¿togaf R 9.1, 1999.
[3] Kent. Fowler Martin Beck. Extreme programming explained: Embrace
change, oct 2000.
[4] Borja López Yolanda. Metodologı́a Ágil de desarrollo de software – xp. feb
2011.
[5] Joskowicz José. Reglas y prácticas en extreme programming. feb 2008.
[6] Cordero Jorge y otros. Báez Manuel, Borreo Álvaro. Introducción a an-
droid. jan 2010.
[7] Jesús Tomás Gironés. El gran libro de android (segunda edición), may
2005.
[8] Android.com, 2014.
[9] Software de comunicaciones - arquitectura android, 2012.
[10] Android os, 2012.
[11] Arquitectura mulñtinivel para la construcción de servicios web restful, 2011.
[12] Capitulo 5. representational state transfer (rest), 2000.
[13] Historia de transmilenio, 2016.
[14] Sistema masivo de transporte, 2014.
[15] José Vittone Javier ’Simón’ Cuello. Diseñando apps para móviles, 2013.
[16] Android, 2016.
[17] Algoritmos defnición, 2016.
[18] Algoritmos para la ruta mas corta en un grafo, 2016.
[19] Ruta mas corta en grafos, 2016.
121
122 BIBLIOGRAFÍA
[20] Algoritmos de aproximación, 2016.

[21] kernellinux, 2016.
[22] Android - desarrolladores, 2014.
[23] Morató Daniel. Paradigma cliente-servidor. oct 2010.
[24] Arquirtectura cliente-servidor, 2016.

[25] Extensible markup language (xml), 2013.
[26] Michael Fire, Dima Kagan, Rami Puzis, Lior Rokach, and Yuval Elovici.
Data mining opportunities in geosocial networks for improving road sa-
fety. 2012 IEEE 27th Convention of Electrical and Electronics Engineers
in Israel, IEEEI 2012, pages 1–4, 2012.
[27] Sobre Waze - ayuda de waze, 2016.
[28] The Open Group. ArchiMate 2.1 Specification, 2013.

Espitia Paz Harold Stevens 2017

Cargado por

Copyright:

Formatos disponibles

Espitia Paz Harold Stevens 2017

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Espitia Paz Harold Stevens 2017

Cargado por

Copyright:

Formatos disponibles

Aplicación Móvil Para Informar Ubicación y

Nivel de Congestión de Buses y Estaciones

Especialización en ingenierı́a de Software

Sergio Gutiérrez, Duban Herrera, Harold Espitia

Director: Joaquı́n Javier Meza

2.1.2. Gestión de Ambientes . . . . . . . . . . . . . . . . . . . . 33

4. Arquitectura Técnica 103

III Cierre de la Investigación 111

7. Prospectiva del trabajo de Grado 119

1.1. Arquitectura del sistema operativo Android . . . . . . . . . . . . 25

2.1. Evidencias Historia de Usuario 0-001-1 [fuente: los autores] . . . 35

2.32. Evidencias Historia de Usuario 3-003-1 [fuente: los autores] . . . 66

3.1. Metamodelo Vista Motivacional [28] . . . . . . . . . . . . . . . . 99

4.1. Metamodelo Vista Comportamiento de Aplicación [28] . . . . . . 103

4.7. Metamodelo Vista Uso de Aplicación [28] . . . . . . . . . . . . . 107

2.1. MENSAJES INFORMATIVOS . . . . . . . . . . . . . . . . . . . 88

Por otro lado en algunos “Publics” o letreros de estaciones y portales, se in-

Buscando reducir ese nivel de incertidumbre generado por el desconocimien-

La investigación descrita en este documento tiene como objetivo primordial

A pesar de que el fin principal del proyecto es dar la información al usua-

Palabras clave: sistema de información, usuario final, aplicaciones móviles,

SITP (Sistema Integrado de Transporte Público)

1.1. Estudio del problema

Se evidencia que algunos puntos de abordaje (estaciones o paraderos) presentan

Si los usuarios no cuentan con una fuente de información actualizada y coheren-

1.1.2. Formulación del problema

¿Como podrı́an los usuarios del ST de la ciudad de Bogotá, enterarse de la

1.1.3. Sistematización del problema

¿Es importante para el usuario del ST enterarse del nivel de congestión de

¿Es útil para la administración del ST enterarse del nivel de congestión

¿Es viable invertir en un método para optimizar el sistema de transporte

1.2.2. Objetivos especı́ficos

En segundo plano se plantea establecer un mecanismo de organización de la

Concretamente el proyecto busca dar una alternativa de fuente de información

buses y estaciones del ST en tiempo real, para establecer un punto de partida

En la sección ’Estudio de sistemas previos’ se habla un poco de MOOVIT

Por todo lo anteriormente mencionado, se plantea la creación e implementación

1.5. Marco de referencia

Actualmente en la ciudad de Bogotá, más exactamente a partir del año 2012

Ası́ mismo se proyecta la creación de 62 nuevas estaciones que plantean una

Sobrecostos en el mantenimiento del sistema, sobrecupo en los buses que

A partir del 15 de Marzo de 2014, se instalaron dispositivos de tipo módem

Desde un punto de vista administrativo o de gestión, con el fin de obtener

TOGAF (The Open Group Architecture Framework), es un marco de traba-

Para llevar a cabo el cumplimiento de los objetivos que se plantea la arqui-

Dado que para el proyecto no es objeto de estudio analizar el proceso de diseño

Para dar más claridad respecto a la vista arquitectural de la aplicación den-

A nivel técnico, se busca el desarrollo de un proyecto tecnológico, que más allá de

La metodologı́a XP o programación extrema es un tipo de metodologı́a ágil,

En su libro, Beck, centra el desarrollo de la metodologı́a basado en cinco valores

En términos generales, dados los pormenores del proyecto, la implementación de

En una capa de más bajo nivel, del desarrollo de la aplicación, es necesario

Finalmente, dando cierre a la contextualización del marco teórico, es impor-

El proceso de implementación de la solución, será llevado a cabo a partir del

del desarrollo de la aplicación, se implementará una aplicación móvil basada en

El sistema operativo Android, presenta una estructura descrita de la siguiente

En el segundo escalón de la arquitectura propuesta por el sistema operativo

Un servicio web, es una aplicación desarrollada bajo la arquitectura cliente-

Figura 1.1: Arquitectura del sistema operativo Android