facultad de ingenier ia - francisco josé de caldas...

Aplicacion Movil Para Informar Ubicacion yNivel de Congestion de Buses y Estaciones

del Sistema Transmilenio

Especializacion en ingenierıa de Software

FACULTAD DE INGENIERIA

Sergio Gutierrez, Duban Herrera, Harold Espitia

Director: Joaquın Javier MezaRevisor: Lilian Bejarano

14 de noviembre de 2016

Indice general

0.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

I Contextualizacion de la Investigacion 15

1. Descripcion de la investigacion 171.1. Estudio del problema . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . 171.1.2. Formulacion del problema . . . . . . . . . . . . . . . . . . 181.1.3. Sistematizacion del problema . . . . . . . . . . . . . . . . 18

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . 191.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . 19

1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3.1. Justificacion practica . . . . . . . . . . . . . . . . . . . . . 19

1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.5. Marco de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.5.1. Marco teorico . . . . . . . . . . . . . . . . . . . . . . . . . 201.5.2. Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . 26

1.6. Aspectos metodologicos . . . . . . . . . . . . . . . . . . . . . . . 281.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . 281.6.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . 281.6.3. Fuentes y tecnicas para la recoleccion de la informacion . 291.6.4. Tratamiento de la informacion . . . . . . . . . . . . . . . 29

1.7. Organizacion del trabajo de grado . . . . . . . . . . . . . . . . . 291.8. Estudio de sistemas previos . . . . . . . . . . . . . . . . . . . . . 29

1.8.1. Waze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.8.2. Moovit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

II Desarrollo de la Investigacion 31

2. Gestion del Proyecto 332.1. Gestion Tecnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1.1. Metodologıa de Desarrollo . . . . . . . . . . . . . . . . . . 33

3

4 INDICE GENERAL

2.1.2. Gestion de Ambientes . . . . . . . . . . . . . . . . . . . . 33

2.1.3. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . 34

2.1.4. Mensajes de Error, Informativos y de advertencia . . . . . 88

2.1.5. Definicion de estructuras de datos . . . . . . . . . . . . . 89

2.1.6. Definicion de estructura del servicio web . . . . . . . . . . 93

2.2. Gestion 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 Tecnica 103

4.1. Vista Comportamiento de Aplicacion . . . . . . . . . . . . . . . . 103

4.1.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.1.2. Vista Comportamiento de Aplicacion iTransAgilApp . . . 104

4.2. Vista Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . . 105

4.2.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.2.2. Vista Cooperacion de Aplicacion iTransAgilApp . . . . . 105

4.3. Vista Estructura de Aplicacion . . . . . . . . . . . . . . . . . . . 106

4.3.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.3.2. Vista Estructura de Aplicacion iTransAgilApp . . . . . . 106

4.4. Vista Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . 107

4.4.1. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.4.2. Vista Uso de Aplicacion 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 Investigacion 111

5. Resultados y discusion 113

6. Conclusiones 115

6.1. Verificacion, contraste y evaluacion de los objetivos . . . . . . . . 115

6.2. Sıntesis del modelo propuesto . . . . . . . . . . . . . . . . . . . . 116

6.3. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.4. Trabajos o publicaciones derivadas . . . . . . . . . . . . . . . . . 117

INDICE GENERAL 5

7. Prospectiva del trabajo de Grado 1197.1. Lıneas de investigacion futuras . . . . . . . . . . . . . . . . . . . 1197.2. Trabajos de investigacion futuros . . . . . . . . . . . . . . . . . . 119

6 INDICE GENERAL

Indice de figuras

1.1. Arquitectura del sistema operativo Android . . . . . . . . . . . . 251.2. ArquitecturaClienteServidor [24] . . . . . . . . . . . . . . . . . . 27

2.1. Evidencias Historia de Usuario 0-001-1 [fuente: los autores] . . . 352.2. Evidencias Historia de Usuario 0-002-1 [fuente: los autores] . . . 362.3. Evidencias Historia de Usuario 0-002-2 [fuente: los autores] . . . 372.4. Evidencias Historia de Usuario 0-002-3a-b [fuente: los autores] . . 382.5. Evidencias Historia de Usuario 0-002-3c [fuente: los autores] . . . 392.6. Evidencias Historia de Usuario 0-002-4 [fuente: los autores] . . . 402.7. Evidencias Historia de Usuario 0-003-1 [fuente: los autores] . . . 412.8. Evidencias Historia de Usuario 0-003-2 [fuente: los autores] . . . 422.9. Evidencias Historia de Usuario 0-003-3 [fuente: los autores] . . . 432.10. Evidencias Historia de Usuario 0-003-4a-b [fuente: los autores] . . 442.11. Evidencias Historia de Usuario 0-003-4c [fuente: los autores] . . . 452.12. Evidencias Historia de Usuario 0-003-5 [fuente: los autores] . . . 462.13. Evidencias Historia de Usuario 0-004-1 [fuente: los autores] . . . 472.14. Evidencias Historia de Usuario 1-001-1a-b [fuente: los autores] . . 482.15. Evidencias Historia de Usuario 1-001-1c [fuente: los autores] . . . 492.16. Evidencias Historia de Usuario 1-002-1 [fuente: los autores] . . . 502.17. Evidencias Historia de Usuario 1-002-2 [fuente: los autores] . . . 512.18. Evidencias Historia de Usuario 1-002-3 [fuente: los autores] . . . 522.19. Evidencias Historia de Usuario 1-003-1 [fuente: los autores] . . . 532.20. Evidencias Historia de Usuario 1-003-1 [fuente: los autores] . . . 532.21. Evidencias Historia de Usuario 1-001-1a-b [fuente: los autores] . . 552.22. Evidencias Historia de Usuario 1-001-1c-d [fuente: los autores] . . 552.23. Evidencias Historia de Usuario 1-001-1c-d [fuente: los autores] . . 562.24. Evidencias Historia de Usuario 2-001-1a-b [fuente: los autores] . . 582.25. Evidencias Historia de Usuario 2-001-2a-b [fuente: los autores] . . 592.26. Evidencias Historia de Usuario 2-001-4 [fuente: los autores] . . . 602.27. Evidencias Historia de Usuario 2-001-5 [fuente: los autores] . . . 602.28. Evidencias Historia de Usuario 2-001-6 [fuente: los autores] . . . 612.29. Evidencias Historia de Usuario 3-001-1 [fuente: los autores] . . . 622.30. Evidencias Historia de Usuario 3-002-1a-b [fuente: los autores] . . 642.31. Evidencias Historia de Usuario 3-002-3 [fuente: los autores] . . . 65

7

8 INDICE DE FIGURAS

2.32. Evidencias Historia de Usuario 3-003-1 [fuente: los autores] . . . 662.33. Evidencias Historia de Usuario 3-003-3[fuente: los autores] . . . . 672.34. Evidencias Historia de Usuario 3-003-4[fuente: los autores] . . . . 682.35. Evidencias Historia de Usuario 3-004-1[fuente: los autores] . . . . 692.36. Evidencias Historia de Usuario 3-004-2[fuente: los autores] . . . . 702.37. Evidencias Historia de Usuario 3-004-3[fuente: los autores] . . . . 712.38. Evidencias Historia de Usuario 3-004-4a-b [fuente: los autores] . . 722.39. Evidencias Historia de Usuario 3-004-4c[fuente: los autores] . . . 722.40. Evidencias Historia de Usuario 3-004-5a-b [fuente: los autores] . . 732.41. Evidencias Historia de Usuario 3-004-5c[fuente: los autores] . . . 732.42. Evidencias Historia de Usuario 3-004-6[fuente: los autores] . . . . 742.43. Evidencias Historia de Usuario 3-004-8[fuente: los autores] . . . . 752.44. Evidencias Historia de Usuario 3-005-1[fuente: los autores] . . . . 762.45. Evidencias Historia de Usuario 3-007-1[fuente: los autores] . . . . 782.46. Evidencias Historia de Usuario 4-001-0[fuente: los autores] . . . . 792.47. Evidencias Historia de Usuario 4-001-1a[fuente: los autores] . . . 802.48. Evidencias Historia de Usuario 4-001-1b[fuente: los autores] . . . 802.49. Evidencias Historia de Usuario 4-001-1c[fuente: los autores] . . . 812.50. Evidencias Historia de Usuario 4-001-1d[fuente: los autores] . . . 812.51. Evidencias Historia de Usuario 4-001-2a[fuente: los autores] . . . 822.52. Evidencias Historia de Usuario 4-001-2b[fuente: los autores] . . . 822.53. Evidencias Historia de Usuario 4-001-2c[fuente: los autores] . . . 832.54. Evidencias Historia de Usuario 4-001-2d[fuente: los autores] . . . 832.55. Evidencias Historia de Usuario 4-001-2e[fuente: los autores] . . . 842.56. Evidencias Historia de Usuario 4-001-3a[fuente: los autores] . . . 842.57. Evidencias Historia de Usuario 4-001-3b[fuente: los autores] . . . 852.58. Evidencias Historia de Usuario 4-001-3c[fuente: los autores] . . . 852.59. Evidencias Historia de Usuario 4-001-3d[fuente: los autores] . . . 862.60. Evidencias Historia de Usuario 4-001-4a[fuente: los autores] . . . 862.61. Evidencias Historia de Usuario 4-001-4b[fuente: los autores] . . . 872.62. Evidencias Historia de Usuario 4-001-4c[fuente: los autores] . . . 872.63. Evidencias Historia de Usuario 4-001-4d[fuente: los autores] . . . 88

3.1. Metamodelo Vista Motivacional [28] . . . . . . . . . . . . . . . . 993.2. Vista Motivacional iTransAgilApp [fuente: los autores] . . . . . . 1003.3. Metamodelo Vista Proceso de Negocio [28] . . . . . . . . . . . . . 1013.4. Vista Proceso de Negocio iTransAgilApp [fuente: los autores] . . 101

4.1. Metamodelo Vista Comportamiento de Aplicacion [28] . . . . . . 1034.2. Vista Comportamiento de Aplicacion iTransAgilApp [fuente: los

autores] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.3. Metamodelo Vista Cooperacion de Aplicacion [28] . . . . . . . . 1054.4. Vista Cooperacion de Aplicacion iTransAgilApp [fuente: los au-

tores] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.5. Metamodelo Vista Estructura de Aplicacion [28] . . . . . . . . . 1064.6. Vista Estructura de Aplicacion iTransAgilApp [fuente: los autores]107

INDICE DE FIGURAS 9

4.7. Metamodelo Vista Uso de Aplicacion [28] . . . . . . . . . . . . . 1074.8. Vista Uso de Aplicacion iTransAgilApp [fuente: los autores] . . . 1084.9. Metamodelo Vista Infraestructura [28] . . . . . . . . . . . . . . . 1084.10. Vista Infraestructura iTransAgilApp [fuente: los autores] . . . . . 1094.11. Metamodelo Vista Uso de Infraestructura [28] . . . . . . . . . . . 1094.12. Vista Uso de Infraestructura iTransAgilApp [fuente: los autores] 110

10 INDICE DE FIGURAS

Indice de cuadros

2.1. MENSAJES INFORMATIVOS . . . . . . . . . . . . . . . . . . . 882.2. MENSAJES DE ADVERTENCIA . . . . . . . . . . . . . . . . . 892.3. MENSAJES DE ERROR . . . . . . . . . . . . . . . . . . . . . . 892.4. Tabla Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902.5. Tabla ResponseCodes . . . . . . . . . . . . . . . . . . . . . . . . 902.6. Tabla Troncals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902.7. Tabla Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912.8. Tabla Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912.9. Tabla RouteStatation . . . . . . . . . . . . . . . . . . . . . . . . 912.10. Tabla RouteStationQualification . . . . . . . . . . . . . . . . . . 922.11. Tabla BusRouteQualification . . . . . . . . . . . . . . . . . . . . 922.12. Tabla Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922.13. Tabla BusPosition . . . . . . . . . . . . . . . . . . . . . . . . . . 932.14. Metodo OpRegisterUser . . . . . . . . . . . . . . . . . . . . . . . 932.15. Metodo OpLoginSession . . . . . . . . . . . . . . . . . . . . . . . 932.16. Metodo OpGetStations . . . . . . . . . . . . . . . . . . . . . . . . 942.17. Metodo OpChangePassword . . . . . . . . . . . . . . . . . . . . . 942.18. Metodo OpSetRouteStationQualification . . . . . . . . . . . . . . 942.19. Metodo OpGetStationQualification . . . . . . . . . . . . . . . . . 952.20. Metodo OpGetRoutesStations . . . . . . . . . . . . . . . . . . . . 952.21. Metodo OpGetRouteStationQualification . . . . . . . . . . . . . 952.22. Metodo OpSetQualificationBusRoute . . . . . . . . . . . . . . . . 962.23. Metodo OpGetRouteQualification . . . . . . . . . . . . . . . . . . 962.24. Metodo OpGetBus . . . . . . . . . . . . . . . . . . . . . . . . . . 962.25. Metodo OpSetBusPosition . . . . . . . . . . . . . . . . . . . . . . 972.26. Metodo OpCreateBus . . . . . . . . . . . . . . . . . . . . . . . . 97

11

12 INDICE DE CUADROS

0.1. Introduccion

Los usuarios del sistema de transporte masivo de Bogota(Colombia) ST,diariamente se enfrentan a la congestion en estaciones y buses de las diferentesrutas, lo cual genera retrasos en la llegada a sus destinos e incomodidad en sudesplazamiento. Actualmente un usuario del ST no cuenta con una fuente deinformacion que presente el nivel de congestion real de buses y estaciones, porlo cual se puede dirigir a una estacion congestionada e invierte tiempo simple-mente para poder ingresar, el cual puede emplear para dirigirse a otra estacioncon una cantidad de usuarios menor, definir otra ruta o medio de transportediferente 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 proximo bus que lleva determinadaruta, que normalmente no es acorde a la realidad, adicionalmente se desconocetotalmente el nivel de gestion de los buses proximos a arribar.

Es normal ver personas esperando una ruta especıfica que corren hacia otrovagon en la misma estacion ’persiguiendo’ a un bus que lleva una ruta diferentea la esperada pero que tambien les permite llegar a su destino. El motivo deesto puede ser que la ruta esperada llevaba mucho tiempo sin pasar, puede serporque el bus perseguido tenia mas espacio del que creıan iban a encontrar enel bus de la ruta esperada inicialmente, o una combinacion 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 mismosconocer el nivel de congestion y ubicacion de buses y estaciones del sistematransmilenio, se propone el desarrollo de una aplicacion Android que ataque es-te problema y de manera colaborativa entre los usuarios, les permita compartirla informacion de una manera facil, practica y eficiente.

La investigacion descrita en este documento tiene como objetivo primordialinformar la ubicacion y nivel de congestion de estaciones y buses a partir delcalculo de la cantidad aproximada de usuarios. Dicha cantidad es calculada apartir de datos recolectados por otros usuarios, haciendo uso de un sistema deinformacion que contara con un metodo de recoleccion de datos por medio delos dispositivos moviles con sistema operativo Android.

A pesar de que el fin principal del proyecto es dar la informacion al usua-rio, tambien podrıa ser usado por la administracion distrital o administraciondel sistema directamente para tomar decisiones sobre posibles cambios en laoperacion.

0.1. INTRODUCCION 13

Palabras clave: sistema de informacion, usuario final, aplicaciones moviles,Android, rutas, estaciones, buses, WBSAbreviaturas:

ST (Sistema Transmilenio)

SITP (Sistema Integrado de Transporte Publico)

WBS (Work Breakdown Structure)

XP (eXtreme Programming)

14 INDICE DE CUADROS

Parte I

Contextualizacion de laInvestigacion

15

Capıtulo 1

Descripcion de lainvestigacion

1.1. Estudio del problema

1.1.1. Planteamiento del problema

A lo largo de los ultimos diez anos, con el crecimiento de la economıa na-cional, se han incrementado diferentes sectores de la misma, ocasionando quela capital se convierta en una central generadora de empleo en el paıs; lo que asu vez produce que el ındice de Colombianos que se movilizan hacia la ciudadcrezca drasticamente. Este y algunos otros motivos, como la alta cantidad decompetencia, sobre poblacion, y sobre todo la necesidad de organizar el trans-porte, han sido causantes de la creacion de un sistema masivo de transporte.

La creacion del ST, proporciono una solucion paulatina al problema, sin em-bargo con el paso del tiempo la idea de unificar el transporte publico, con elSITP, ha hecho que el sector movilidad a nivel distrital, se convierta en uno delos problemas principales de la administracion capitalina, pues el sistema queactualmente opera presenta diferentes incognitas, dentro de las que resaltan laoptimizacion del servicio, la seguridad dentro del sistema, comodidad, costos,etc. Generalmente durante las horas pico se presenta congestion en estacionesy paraderos del SITP, ası como en los del ST. Para el caso de las estaciones, eltiempo de espera tan solo para el ingreso puede superar los diez minutos. Encuanto a los paraderos del SITP las filas que conducen al lugar donde el busabrira las puertas pueden extenderse a mas de quince metros.

Se evidencia que algunos puntos de abordaje (estaciones o paraderos) presentanmayor congestion que otros. El tiempo que una persona pierde intentando en-trar o acercarse al punto de abordaje, puede ser invertido en el desplazamientoa otro punto o en la busqueda de otro medio de transporte. Los usuarios no

17

18 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION

cuentan con una herramienta o medio que les permita identificar los puntos queson realmente crıticos para poder abordar un auto bus del ST o aquellos puntosque comparados con otros presentan una cantidad menor de usuarios.

Por otro lado los usuarios desconocen totalmente el nivel de congestion pun-tual del sistema, tiempo estimado de llegada o cantidad de usuarios aproximadadel siguiente bus que arribara al punto de abordaje en el que se encuentra. Enalgunas situaciones cuando el usuario se encuentra a la espera de un autobusen el punto de abordar, el que este mas cerca puede llevar en el momento masusuarios que otro aunque se encuentre mas lejos. Para ese caso vale la penaesperar unos minutos mas para poder transportarse en un bus mas desocupadoy ası poder viajar mas comodo.

Si los usuarios no cuentan con una fuente de informacion actualizada y coheren-te con el nivel de congestion en tiempo real del ST, se mantendra la dificultadplanteada y las personas que se transportan a diario en el mismo, aumentaransu inconformismo a medida que pasa el tiempo.

Las siguientes son preguntas que seran objeto de estudio a lo largo de esteproyecto, pues se busca agilizar desde un punto de vista tecnologico, el sistemade transporte a nivel distrital.

1.1.2. Formulacion del problema

¿Como podrıan los usuarios del ST de la ciudad de Bogota, enterarse de laubicacion y nivel de congestion de buses y estaciones del mismo para apoyar latoma de decisiones en el uso de las rutas?

1.1.3. Sistematizacion del problema

¿Es importante para el usuario del ST enterarse del nivel de congestion delas estaciones y buses del mismo, en tiempo real al tomar decisiones sobreel uso de las rutas?

¿Es util para la administracion del ST enterarse del nivel de congestionde estaciones y buses del mismo, en tiempo real al tomar decisiones sobreel diseno de las rutas?

¿Es viable invertir en un metodo para optimizar el sistema de transportepublico, a traves del analisis de informacion obtenida en tiempo real sobreel nivel de congestion de estaciones y buses del ST?

1.2. OBJETIVOS 19

1.2. Objetivos

1.2.1. Objetivo general

Implementar una aplicacion movil Android que se integre con un sistema deinformacion basado en la cantidad aproximada de usuarios del ST capturandodatos en tiempo real, permitiendo a los mismos enviar y consultar la informacionque veran los demas usuarios, para lograr identificar el nivel de congestion yubicacion de los buses y estaciones del mismo.

1.2.2. Objetivos especıficos

Implementar el modulo de administracion por medio de aplicaciones WEBpara permitir gestionar la informacion de estaciones y buses (rutas) quecomponen el ST.

Implementar en la aplicacion Android el modulo de recoleccion de datosen tiempo real, suministrados por los usuarios con los cuales se podradeterminar la ubicacion y nivel de congestion de buses y estaciones.

Implementar en la aplicacion Android el modulo de consulta que permitaal usuario enterarse de la ubicacion y nivel de congestion de los buses yestaciones del ST procesando los datos recopilados en tiempo real, sumi-nistrados por los usuarios, para dar a los mismos la informacion solicitada.

1.3. Justificacion

1.3.1. Justificacion practica

Teniendo en cuenta la problematica presentada previamente, el proyecto tie-ne su razon de ser principalmente en el hecho de realizar un estudio preliminardel comportamiento del sistema de transporte masivo, teniendo en cuenta lasdiferentes variables que lo afectan. El estudio permitira obtener una apreciaciondirecta de la gestion del sistema y la interaccion con el usuario que este presenta.

En segundo plano se plantea establecer un mecanismo de organizacion de lainformacion recolectada durante el proceso de estudio investigativo del ambien-te, con el fin de presentar una alternativa que permita informar al usuario sobrela ubicacion y nivel de congestion de estaciones y buses del ST, por medio deun canal directo y efectivo, que permita tambien la centralizacion de un flujode informacion constante que funcione como punto de referencia para toma dedecisiones.

Concretamente el proyecto busca dar una alternativa de fuente de informacionpublica para los usuarios del ST, por medio de un sistema que funcione comocentralizador de informacion, y que facilite el proceso de toma de decisiones.Lo anterior es un medio para enterarse de la ubicacion y nivel de congestion de


buses y estaciones del ST en tiempo real, para establecer un punto de partidaal posterior proceso de toma de decisiones desde diferentes perspectivas.

En la seccion ’Estudio de sistemas previos’ se habla un poco de MOOVITque es una aplicacion que se acerca un poco a la solucion 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 informacion brindada.

Por todo lo anteriormente mencionado, se plantea la creacion e implementacionde una aplicacion movil Android que se integre con un sistema de informacion,de facil acceso a los usuarios del ST y que puedan consultar/enviar informacionen lınea y en el momento en que lo requieran de una forma muy practica, agil yrapida 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 pacienciapara el uso de una aplicacion de este tipo.

1.4. Hipotesis

La implementacion de una aplicacion Android constituira, para el usuario,un medio de consulta inmediata sobre la ubicacion y nivel de congestion de busesy estaciones del ST permitiendoles enterarse de ciertas variables en tiempo realpara tomar decisiones basados en esa informacion.

1.5. Marco de referencia

1.5.1. Marco teorico

En el ano 2000, se inauguro la primera ruta del primer sistema de transportemasivo de Bogota-Colombia, operando entre la autopista norte, avenida caracasy la calle 80. La idea nace como el planteamiento de una solucion al problemaque se presentaba ante la fuerte y agresiva competencia generada por las dife-rentes empresas de transportes privados a nivel distrital y como una respuestaa la creciente demanda de ciudadanos en la capital Colombiana.[4]

Sin embargo un exito prematuro del sistema presento durante sus primeras fasesde funcionamiento, genero un crecimiento no controlado, que a su vez desarrollouna sobre demanda de los usuarios, hasta el punto de un 12.8 % en los ultimos13 anos. (Revista semana, 2014) [1]

Actualmente en la ciudad de Bogota, mas exactamente a partir del ano 2012operan 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 – Americas

G – NQS Sur

H – Caracas sur

J – Eje ambiental

K – Avenida el dorado

L – Carrera 10

M – Carrera septima central

Ası mismo se proyecta la creacion de 62 nuevas estaciones que plantean unaextension de las lıneas “G” (NQS sur), “K” (Avenida el Dorado) y “M” (Carreraseptima central) ası como la implementacion de nuevas troncales:

N – Boyaca sur

P – Boyaca central

R – Boyaca norte

S – Carrera septima norte [6]

Sobrecostos en el mantenimiento del sistema, sobrecupo en los buses queatienden las rutas planteadas, retardos considerables en la llegada y salida delos buses, descompensacion 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 losprincipales problemas a los que ha tenido que enfrentarse el sistema, durante suproceso de evolucion.

Desde el punto de vista del usuario final, el principal problema que presentael 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 deusuarios 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 modemque permiten al usuario acceder a un internet con capacidad de 10Mb, en 15estaciones de las principales troncales del ST en la ciudad con un alcance dealrededor de 400 metros, ası se instalaron dispositivos que permitiran acceder ainternet en los principales portales de la ciudad: Usme, Tunal, Americas, Calle


80 y Suba. [5]

El presente proyecto busca por medio de una solucion tecnologica, brindar unafuente de informacion a los usuarios, que permita a los mismos tener conocimien-to en tiempo real sobre el comportamiento del sistema, especıficamente sobre elnivel de congestion de buses y estaciones.

Desde un punto de vista administrativo o de gestion, con el fin de obteneruna vision holıstica del proyecto, se implementaran algunas fases del ADM (Ar-chitecture Development Method) del marco de trabajo arquitectural planteadopor TOGAF.

TOGAF (The Open Group Architecture Framework), es un marco de traba-jo arquitectural que busca presentar un enfoque de diseno, implementacion ygestion del gobierno de arquitectura de las organizaciones. Creado por el OpenGroup, TOGAF, tiene como principales objetivos describir una metodologıapara la construccion de sistemas de informacion orientada a componentes, con-tener un conjunto de herramientas que faciliten el proceso de integracion y/omigracion de tecnologıas a nivel interno de la organizacion, proveer un lenguajeunificado e incluir una lista de estandares que coordinen las diferentes areas dela 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 organizacion que aplica el marcode trabajo, se hace referencia a 5 dimensiones fundamentales: Arquitectura mo-tivacional, Arquitectura de negocios, Arquitectura de aplicaciones, Arquitecturade Datos y Arquitectura de tecnologıa. Para uso puntual del proyecto, se haraenfasis directamente en las tres ultimas dimensiones. [2]

Dado que para el proyecto no es objeto de estudio analizar el proceso de disenoarquitectural de una organizacion, solamente se tomara como foco de estudio lavista arquitectural de la aplicacion.

Para dar mas claridad respecto a la vista arquitectural de la aplicacion den-tro del marco de referencia de diseno arquitectural, en este se busca presentarun diseno de como funcionara la aplicacion en relacion a los objetivos que seplantearon para ella. Dentro de la vista de aplicacion, se detallan las funcionesde la misma, actores que intervienen directa e indirectamente en la misma, in-terfaces de comunicacion, y mecanismo de despliegue.

A nivel tecnico, se busca el desarrollo de un proyecto tecnologico, que mas alla dedar solucion a la problematica previamente mencionada, presente una implemen-tacion de las metodologıas que mas se adecuen al desarrollo del mismo. Siendoası y teniendo en cuenta el cronograma (que sera presentado posteriormente),se realizara el uso de metodologıas agiles, mas especıficamente metodologıa XP,para el desarrollo del proyecto en general.


La metodologıa XP o programacion extrema es un tipo de metodologıa agil,utilizada principalmente para el desarrollo de software. Propuesta en 1999 porKent Beck, consiste en un marco de trabajo disenado principalmente para eldesarrollo de software, el cual a diferencia de otras metodologıas, hace princi-palmente enfasis en la adaptabilidad que en la previsibilidad. La metodologıaXP, propone un proceso de desarrollo evolutivo orientado a la simplicidad yagilidad, el cual a diferencia de las metodologıas clasicas evita presentar tantaburocracia en las diferentes etapas, reduciendo el numero de las mismas, con elfin de concentrar esfuerzos en aquellos procesos que realmente son vitales dentrodel ciclo de vida del software.

En su libro, Beck, centra el desarrollo de la metodologıa basado en cinco valoresprincipales (comunicacion, simplicidad, retroalimentacion, coraje y respeto), asıcomo una serie de principios (inversiones, economıa, diversificacion, entre otros).A diferencia de las metodologıas convencionales, XP se desarrolla bajo cuatrofases principales, planeacion del proyecto, diseno, codificacion y pruebas, lascuales se encuentran dentro de ciclos repetitivos conocidos como “sprints”. Susistema de recoleccion de requerimientos ejecutado de manera evolutiva, paracada una de las fases liberables, conocido como historias de usuario permiteejecucion conjunta de la mano del cliente, del desarrollo general del proyecto.

En terminos generales, dados los pormenores del proyecto, la implementacion deuna metodologıa agil, para el desarrollo del proyecto, toma vital importancia,dado que permitira realizar la construccion de los requerimientos (historias deusuario) de forma evolutiva para cada una de las fases de desarrollo del proyec-to. [3] [4] [5]

En una capa de mas bajo nivel, del desarrollo de la aplicacion, es necesariomencionar acerca del patron arquitectural MVC (Modelo Vista Controlador),cuyo principal objetivo dentro del desarrollo de un sistema tecnologico, es di-vidir responsabilidades a traves de la declaracion de capas: modelo: en la quese encuentran los elementos relacionados directamente con las reglas y/o logicade negocio; el controlador: encargado de recibir desde las vistas y enrutar laspeticiones hasta el modulo de negocio; finalmente, esta la capa de la vista: encar-gada como su nombre lo indica, su principal responsabilidad es la presentacion,captura y modificacion de los datos. [6]

Finalmente, dando cierre a la contextualizacion del marco teorico, es impor-tante tratar directamente las tecnologıas que seran utilizadas para el desarrollode la solucion (para este caso una aplicacion movil), a la problematica que seplantea. Puntualmente se trataran temas relacionados con la tecnologıa An-droid, y la implementacion de la arquitectura REST.

El proceso de implementacion de la solucion, sera llevado a cabo a partir deltrabajo en conjunto de dos tecnologıas; en primer lugar como foco fundamental


del desarrollo de la aplicacion, se implementara una aplicacion movil basada enel sistema operativo Android, el cual esta disenado originalmente para telefo-nos moviles (evolucionado posteriormente para diferentes dispositivos moviles).Basado en el de Linux, el sistema operativo Android, fue desarrollado en lacompanıa de nombre homonimo (liderada por Rich Miner, Chris White y NickSears), en el ano de 2003. En el ano 2005 la multinacional norteamericana (quepreviamente realizaba apoyos economicos a la companıa), realiza la compra to-tal de Android Inc. Actualmente el sistema operativo ofrece cobertura para lasgrandes marcas de dispositivos moviles, estando ası en su version 7.0, cuyo nom-bre es Nugat. [7] [8]

El sistema operativo Android, presenta una estructura descrita de la siguientemanera: en primer lugar se encuentra el modulo de aplicaciones: correspondienteal conjunto de aplicaciones implementadas por la comunidad de desarrollado-res, que buscan atender funcionalidades puntuales, dando soluciones directasa problemas cotidianos para los usuarios de los dispositivos moviles, ejemplosde este tipo son videojuegos, contactos, exploradores o navegadores, escritorios,herramientas de personalizacion, etc. Las aplicaciones que son instaladas en elsistema operativo, se dividen en tres diferentes tipos:, nativas, hıbridas y We-bApps.

En el segundo escalon de la arquitectura propuesta por el sistema operativoAndroid, se encuentra el Armazon de aplicaciones, el cual busca realizar unaadministracion de las diferentes propiedades con las que cuenta el sistema ope-rativo en relacion con el dispositivo en el que se encuentra alojado, se componede administradores de ventanas, administrador de actividades, administrador decontenidos, vistas del sistema entre otros. Mas adelante se encuentra el modulode librerıas, que permitira establecer acceso a propiedades locales del sistemaoperativo, tales como bases de datos librerıas de seguridad, y administrador desuperficies. Finalmente se encuentra el nucleo del sistema operativo el cual co-mo se menciono previamente esta desarrollado con base al Kernel de Linux; estesera el encargado de administrar recursos de memoria, mantener disponibles losdispositivos de hardware del telefono, entre otros. [9] [10]

Dado que uno de los objetivos especıficos del proyecto es realizar la creacionde una aplicacion movil, el core del proyecto centrara sus esfuerzos en la prime-ra capa del esquema de aplicaciones del sistema operativo Android, realizandoel despliegue de una aplicacion desarrollada en lenguaje Java, cuyo soporte deinformacion fundamental esta radicado en un servicio web que implementara latecnologıa REST.

Un servicio web, es una aplicacion 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 interaccionentre diferentes nodos de una red; un servicio web, puede tambien definirse co-mo una API, que permite ejecutar diferentes operaciones en la maquina en la


Figura 1.1: Arquitectura del sistema operativo Android[9] [10]

que se aloja. [11]

Durante los ultimos anos, el desarrollo de sistemas de informacion se ha orien-tado al desarrollo de arquitecturas orientadas a servicios, permitiendo una altamodularidad de servicios y facilitando la separacion en componentes, de los ele-mentos que intervienen dentro del sistema. La arquitectura REST (REpresen-tation State Transfer), consiste en un diseno arquitectonico, basado en sistemasen red, principalmente aplicaciones web, que implementa el protocolo HTTP,sin embargo para el caso puntual de REST, se realiza una limitacion de lasoperaciones del protocolo (GET, PUT, etc.). El principal objetivo de una arqui-tectura REST, es realizar el intercambio de peticiones utilizando la arquitecturacliente-servidor previamente mencionada, aunque si bien el objetivo es realizarel 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 aplicacion, se realizara la implementacion deun 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 decomplemento, se plantea la construccion de un servicio web que realice el consu-mo de una base de datos relacional, disenada con el fin de cubrir los diferentes


aspectos que se desean tener en cuenta dentro de la solucion planteada. Gra-cias a la implementacion de la vista de aplicacion del marco TOGAF, se puedeverificar el despliegue arquitectonico de la aplicacion.

1.5.2. Marco conceptual

Con el fin de establecer un contexto de los conceptos que seran frecuentadosa lo largo del documento, tanto para la parte tecnica, como para la parte decontextualizacion del problema, en esta seccion, se realizara una aproximacionde los elementos que seran tratados a lo largo del desarrollo del proyecto.

CONTEXTUALIZACION DEL PROBLEMA:

En primer lugar se mencionaran los conceptos mas 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 ano2000. Opera a lo largo de Bogota distribuido por las principales troncales de laciudad. [13]

Sistema masivo de transporte: Tambien llamado autobus de transito rapi-do, es una modalidad de transporte de ciudadanos a gran volumen, pensadoprincipalmente como un medio alternativo, con el fin de agilizar la movilidadgeneral del entorno, bajo el cual es desarrollado. Regularmente es implementadoen grandes ciudades y de diferentes modalidades (metros, trenes, etc.). [14]

ASPECTOS TECNICOS:

Dado que el foco de la solucion planteada para el desarrollo del proyectoconsiste en el desarrollo de una aplicacion movil desarrollada bajo el sistemaoperativo Android, a continuacion se presentan los conceptos mas importantesen cuanto a los aspectos tecnicos que se tendran en cuenta:

Aplicaciones moviles: Son un tipo de software desarrollado principalmen-te para dispositivos moviles, como telefonos inteligentes, tablets, computadorasde bolsillo, entre otros. Presentan un conjunto de ventajas como portabilidady disponibilidad que son superiores a las aplicaciones de computadora conven-cionales. Las aplicaciones moviles permiten sacar un mayor provecho de lascaracterısticas de hardware del dispositivo, ası como informacion proporcionadadirectamente por el usuario, con fines de alimentacion de sistemas de informa-cion. [15]Android: Es un sistema operativo, desarrollado para operar principalmente endispositivos moviles con pantalla tactil. Esta desarrollado bajo tecnologıa Linux.Debido a la alta demanda de telefonos inteligentes de distintos fabricantes esuno de los sistemas operativos mas usado en este tipo de dispositivos. [16]


Algoritmo: Un algoritmo, es una secuencia de instrucciones, que representanun metodo de solucion para un problema determinado. [17]Busqueda de ruta mas corta/optima: En informatica, dentro de la teorıade grafos, se define el algoritmo de la ruta mas corta, como el mecanismo queresuelve el proceso de busqueda de la distancia de menor longitud entre dospuntos, ubicados dentro de un grafo. El proceso de busqueda, debe realizar elprocesamiento de todos los nodos y aristas del grafo, para de esta manera en-contrar el camino mas optimo. Para resolver este problema se han planteadoprincipalmente tres tipos de algoritmos: Dijkstra, Warsahall y Floyd. [18] [19]Busqueda por proximidad: Teniendo en cuenta el objetivo del proyecto, pa-ra este caso se propone una definicion de proximidad, orientada a un tipo dealgoritmo que es implementado, para realizar la busqueda del nodo mas cercanoa un punto preestablecido. El proceso de busqueda se debe realizar a todos losnodos y aristas del grafo. [20]Kernel Linux: El kernel de Linux, es considerado el corazon de todo sistemaoperativo basado en tecnologıa Unix o Linux; es el encargado de que el hard-ware y software de cualquier dispositivo (computadoras, telefonos inteligentes,tablets, etc.), puedan trabajar juntos. Se encuentra licenciado bajo la licenciaGPLV2, lo que indica que su uso es libre, y el fuente del mismo se encuentraconstruido por una comunidad de desarrolladores que constantemente realizancontribuciones al mismo. [21]Aplicaciones nativas: Corresponden a un tipo de aplicaciones desarrolladasprincipalmente para el nucleo de Android, tıpicamente son programas escritosen codigo java, utilizando el esquema XML, para el proceso de la capa de pre-sentacion, aplicaciones hıbridas. [22]Arquitectura cliente-servidor: La arquitectura cliente servidor, es una ma-nera de diseccionar y especializar programas y equipos de computo, de maneraque la tarea que cada cual ejecuta sea realizada de manera eficaz y eficiente, se-parando responsabilidades, y facilitando un mayor y mas sencillo mantenimientodel sistema en general. [23]

Figura 1.2: ArquitecturaClienteServidor [24]


La figura 1.2 representa graficamente el despliegue de una arquitectura clien-te–servidor, en la cual intervienen equipos enviando peticiones directamente aun 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 implementacion de una arquitectura cliente servidor, en la que los rolesde nodos, seran representados por equipos moviles de cada uno de los usuarios.

XML: El Extensible Markup Language, es un tipo tipo de formato de textosimple y muy flexible, derivado del SGML, utilizado fundamentalmente parael almacenamiento y transporte de informacion. XML, esta disenado bajo unesquema de etiquetas, en las que se define la estructura del documento, y seespecifican las configuraciones que este debe tener. [25]

1.6. Aspectos metodologicos

1.6.1. Tipo de estudio

Mediante la implementacion de un sistema de informacion que permita re-copilar datos suministrados por los usuarios del ST y posteriormente presentarinformacion actualizada de la cantidad de usuarios aproximada en estaciones ybuses en tiempo real, la presente investigacion seguira un tipo de estudio expli-cativo, al ofrecer una fuente publica y un mecanismo de recopilacion de datoshasta el momento no implementados, para poder identificar elementos, causas,variables, caracterısticas etc., relacionados directa e indirectamente con la altacongestion del ST, los cuales pueden servir para: la realizacion de nuevas inves-tigaciones , toma de decisiones operativas en el ST y principalmente mantenera la ciudadanıa informada.

1.6.2. Metodo de investigacion

La informacion para calcular la cantidad aproximada de usuarios en estacio-nes y buses determinados del ST, es generada a partir de los datos suministradospor los usuarios, de esta manera la investigacion seguira el metodo inductivo.

Dado que no es objeto primordial de esta investigacion el estudio de los di-ferentes algoritmos de busqueda de ruta mas optima o busqueda de proximidad;con fines netamente academicos, para el proyecto se realizara el calculo de califi-cacion del estado de una ruta o una estacion, a traves de una media aritmetica delas calificaciones proporcionadas por cada usuario. Es importante resaltar que eluso de la media aritmetica, como principal medio de verificacion de construccionde un diagnostico acerca del estado puntual del sistema, es una alternativa uti-lizada estrictamente para el ejercicio academico, dado que, en futuras versionesdel producto final, [tal y como se concluye en la investigacion (revisar apartadode conclusiones)], se realizara la implementacion de diferentes algoritmos quepermitan alcanzar mayor precision en los calculos que se realizaran dentro delsistema en general.

1.7. ORGANIZACION DEL TRABAJO DE GRADO 29

1.6.3. Fuentes y tecnicas para la recoleccion de la infor-macion

Fuentes Primarias: Para calcular la cantidad aproximada de usuarios enestaciones y buses, se recopilara la informacion de los usuarios por medio deuna aplicacion que se ejecuta en dispositivos moviles. Fuentes Secundarias:Documentos y planos publicos del ST, con el fin de obtener la informacion deestaciones y rutas.

1.6.4. Tratamiento de la informacion

Para determinar el nivel de congestion de una estacion o bus, se requiere unacantidad mınima de datos suministrados por usuarios, con los cuales se podracalcular una cantidad aproximada de personas y compararla con la cantidadmaxima que la estacion o bus tenga capacidad. La informacion sera presentadaal usuario graficamente he indicando la ubicacion y nivel de congestion generalde un bus o estacion, por medio de una aplicacion instalada en su dispositivomovil Android.

1.7. Organizacion del trabajo de grado

El proyecto inicio con base a algunas ideas de los integrantes del equipo, loscuales propusieron distintas ideas para luego combinarlas en una sola y llegar adefinir un alcance y objetivos sobre los modulos a desarrollar.

Haciendo uso de la experiencia en desarrollo, administracion de plataformasy 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 elcorrecto desarrollo del mismo.

A medida que se avanza con la ejecucion del proyecto no se presentan grandesproblemas que impacten directa y drasticamente el correcto avance del mismo.La principal dificultad encontrada es la falta de tiempo disponible debido a obli-gaciones laborales y academicas de los integrantes.

1.8. Estudio de sistemas previos

Dentro de la investigacion realizada no se encontraron aplicaciones que tu-vieran las mismas funcionalidades que las propuestas en este proyecto paraatacar el problema mencionado. Sin embargo, en su generalidad se encuentransimilitudes con la filosofıa que manejan dos aplicaciones muy conocidas por lacomunidad respecto a informacion sobre el transporte y trafico. Estas aplicacio-nes son WAZE y MOOVIT las cuales se describiran breve y resumidamente acontinuacion.


1.8.1. Waze

De acuerdo a lo descrito en la pagina de ayuda de WAZE (ahora propiedadde Google), es una aplicacion de navegacion GPS, aunque para muchas personases considerada una red social que permite a sus usuarios compartir informacionsobre el estado del trafico, controles policiales, accidentes, entre otros eventosque puedan afectar la velocidad y calidad de desplazamiento de vehıculos en lascalles.

WAZE es usada por conductores de vehıculos publicos y privados, brindandoinformacion del estado de las vıas. Esto es posible con la participacion de unacomunidad de conductores o tambien llamada red social o red “Geosocial” [26],quienes comparten y evaluan en tiempo real, mediante una aplicacion movil, elestado de las vıas transitadas durante un trayecto. Adicionalmente con base enla informacion recolectada, presenta una ruta optima. La diferencia principalque tendra el sistema de informacion desarrollado en esta investigacion respectoa WAZE, es que se brindara una fuente de informacion actualizada de estacionesy buses del ST. Por otro lado, ambos tienen en comun la participacion de losusuarios, como fuente primordial de los datos.

Un ıtem muy importante y que es la principal similitud que se encontro conla aplicacion de software propuesta, es que depende directamente del buen usoque se le de a la aplicacion por parte de los usuarios para que a los mismos se lesbrinde una informacion de alta calidad y coherente con la realidad del momentoen que se consulte. Para mayor detalle de como funciona WAZE se puede visitarla pagina de soporte oficial referenciada en la bibliografıa. [27]

1.8.2. Moovit

MOOVIT Es una aplicacion movil que permite a los usuarios consultar infor-macion sobre el transporte publico como rutas, paradas, tiempo de espera parala llegada de una ruta, etc. Lo anterior para facilitar la movilidad en el sistemade transporte de cada ciudad; SITP/Transmilenio en el caso de Bogota que es laciudad en la cual se desarrollara nuestro proyecto. MOOVIT tiene varias funcio-nalidades muy importantes y utiles, las cuales se pueden consultar en su paginaoficial moovitapp.com/es/. Sin embargo, la navegacion y facilidad de uso nofavorecen mucho a la misma, teniendo en cuenta que realmente un usuario delST, SITP o cualquier sistema de transporte masivo espera de una herramientapara llevar a cabo su recorrido, la simplicidad de uso y calidad de la informacion.

En cuanto a la implementacion de MOOVIT en el ST de Bogota, a pesar deque presenta a los usuarios informacion de tiempo estimado de trayectos y no-tificaciones del estado del mismo, no permite enterase del nivel de congestionde estaciones y buses, ni tampoco una ubicacion aproximada de estos ultimos.Esta caracterıstica diferencia a MOOVIT del sistema de informacion propuestoa desarrollar en el presente documento.

Parte II

Desarrollo de laInvestigacion

31

Capıtulo 2

Gestion del Proyecto

2.1. Gestion Tecnica

2.1.1. Metodologıa de Desarrollo

La metodologıa de desarrollo a utilizar dentro del proyecto es XP (eXtremingPrograming) o Programacion Extrema teniendo en cuenta la descomposicionmodular que tendra la aplicacion (ver capitulo Arquitectura Tecnica) y buscan-do aprovechar las ventajas que tienen las metodologıas agiles de desarrollo.

Despues de definidas las historias de usuario y especificada la cantidad de his-torias de usuario dentro de cada Sprint proximo a desarrollar, se realizara eldesarrollo del mismo.

Una vez finalizado el desarrollo se liberara el Sprint para que se realice la fasede pruebas, mientras se avanza en el desarrollo de los demas Sprint, y en casode existir errores seran corregidos y entregados con el desarrollo del siguienteSprint.

El detalle de las historias de usuario se encuentra en la seccion Historias deUsuario al igual que las evidencias de las pruebas ejecutadas.

2.1.2. Gestion de Ambientes

Como se vera en mayor detalle en el capitulo de arquitectura tecnica, lafuncionalidad de la aplicacion depende de tres componentes que son la base dedatos, el servicio web y la aplicacion Android como tal.Para mantener separados e independientes los ambientes de desarrollo, prue-bas y produccion, se instalaran tres instancias del motor de base de datos, tresinstancias del servidor de aplicaciones para el web service y se generara el ins-talador de la aplicacion Android apuntando a la instancia del web service segun

33

34 CAPITULO 2. GESTION DEL PROYECTO

corresponda.

El repositorio de los desarrollos de la aplicacion Android, del Servicio Web y losScripts de creacion de objetos de Base de Datos sera un servidor SVN al cualpodran acceder todos los integrantes del equipo del proyecto desde la Internet.

2.1.3. Historias de Usuario

Como tecnica de levantamiento de requerimientos dentro de la metodologıaXP se utilizaron las historias de usuario. Mediante estas, se definieron los com-portamientos funcionales que debe tener la aplicacion, dando de esta manera ladefinicion del alcance funcional que se espera lograr con la misma.

Cada escenario de las historias de usuario se tomo como un caso de pruebaen la ejecucion de las pruebas de caja negra y con base a ello se registran lasevidencias de cada caso de prueba a continuacion de cada descripcion del esce-nario correspondiente.

1. Especificacion Interfaz Grafica de Usuario

Identificador (ID) de la Historia: 0-001

Rol: Usuario final

Caracterıstica/Funcionalidad: Especificacion Interfaz Grafica deUsuario

Razon/Resultado: Especificacion visual de la ventana de inicio desesion/registro.

Escenarios:

• 1. Cumplimiento de especificacion grafica.

Contexto: Pantalla inicial al abrir la aplicacion

Evento: Inicio de la aplicacion. El usuario ingresa a la apli-cacion, y esta presenta la pantalla de inicio de sesion/registro.

Resultado/Comportamiento esperado: Se espera que la pan-talla cumpla con las siguientes caracterısticas:

- Presentacion del logotipo de la aplicacion en la parte central ysuperior de la pantalla.- Campo de email.- Campo de contrasena.- Boton para iniciar sesion.- Boton para registrarse.- Enlace que permitira realizar el envıo de contrasena a un correo

2.1. GESTION TECNICA 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

Razon/Resultado:Registrar usuario final para que pueda usar laaplicacion

Escenarios:

• 1. Usuario no registrado diligencia correctamente el cam-po de email y contrasena

Contexto: Pantalla inicial al abrir aplicacion

Evento: Usuario abre aplicacion y muestra formulario con doscampos: - Email - Contrasena Los diligencia y presiona el botonRegistrar

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 operacion serealizo exitosamente.Aplicacion muestra mensaje [Mensaje codigo INF-1] y Continuaen historia de usuario 1-001

Evidencias:

(a) 0-002-1a (b) 0-002-1b


• 2. Usuario registrado diligencia correctamente el campode email y contrasena



Resultado/Comportamiento esperado: Aplicacion envıa da-tos a servidor y el servidor responde codigo 00101 indicando queel Email ya esta registrado.Aplicacion muestra mensaje [Mensaje codigo ERR-1] y muestranuevamente formulario inicial.

Evidencias:

• 3. Usuario no registrado diligencia incorrectamente el



campo de email



Resultado/Comportamiento esperado: Aplicacion no envıadatos a servidor.Aplicacion muestra mensaje [Mensaje codigo ERR-2] y muestranuevamente formulario inicial.

Validaciones campo Email:- Debe tener caracter ’@’ despues 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 elcampo de contrasena




Validaciones campo Contrasena (polıticas):- Debe tener minimo 6 caracteres


Evidencias:

(a) 0-002-4a (b) 0-002-4a


3. Inicio de sesion


Rol: Usuario final

Caracterıstica/Funcionalidad:Inicio de sesion

Razon/Resultado:Iniciar sesion en la aplicacion para poder accedera las funcionalidades disponibles

Escenarios:

• 1. Usuario registrado diligencia correctamente el campode email y contrasena que corresponde a ese Email enel sistema


Evento: Usuario abre aplicacion y muestra formulario con dos


campos: - Email - Contrasena Los diligencia y presiona el botonIngresar

Resultado/Comportamiento esperado: Aplicacion envıa da-tos a servidor y se realiza la validacion del usuario y clave en elsistema.Servidor responde codigo 00000 que indica que la operacion serealizo exitosamente.

Continua en historia de usuario 1-001Evidencias:


• 2. Usuario registrado diligencia correctamente el campode email y contrasena pero la contrasena no correspondea la registrada en el sistema para ese Email



Evento: Usuario abre aplicacion y muestra formulario con doscampos: - Email - Contrasena Los diligencia y presiona el botonIngresar

Resultado/Comportamiento esperado: Aplicacion envıa da-tos a servidor y el servidor responde codigo [00102] indicando quela contrasena del usuario es incorrecta.Aplicacion muestra mensaje [Mensaje codigo ERR-4] y muestranuevamente formulario inicial.Evidencias:


• 3. Usuario no registrado diligencia correctamente el cam-po de email y contrasena




Resultado/Comportamiento esperado: Aplicacion envıa da-tos a servidor y el servidor responde codigo [00102] indicando queel Email no esta registrado.Aplicacion muestra mensaje [Mensaje codigo ERR-4] y muestranuevamente formulario inicial.

Evidencias:

(a) 0-003-3a (b) 0-003-3a


• 4. Usuario registrado diligencia incorrectamente el cam-po de email


Evento: Usuario abre aplicacion y muestra formulario con dos


campos: - Email - Contrasena Los diligencia y presiona el botonIngresar


Validaciones campo Email:- Debe tener caracter ’@’ despues 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 contrasena




Validaciones campo Contrasena (polıticas):- Debe tener minimo 6 caracteres


Evidencias:


4. Olvido de contrasena

Identificador (ID) de la Historia: 0-004

Rol: Usuario final

Caracterıstica/Funcionalidad: Olvido de contrasena

Razon/Resultado: Reiniciar contrasena y enviarla al e-mail delusuario

Escenarios:

• 1. Usuario registrado selecciona link de olvido de con-trasena

Contexto: Pantalla inicial al abrir la aplicacion

Evento: Inicio de la aplicacion. El usuario ingresa a la apli-cacion, y esta presenta la pantalla de inicio de sesion/registro.

Resultado/Comportamiento esperado: Aplicacion envıa so-licitud a servidor para que envıe contrasena al e-mail del usuario


registrado. Se envıa contrasena y muestra mensaje [INF-7] indi-cando que se envıo contrasena a su e-mail.

Evidencias:


5. Vista principal despues de iniciar sesion


Rol: Usuario final

Caracterıstica/Funcionalidad:Vista principal despues de iniciarsesion

Razon/Resultado:Definir los elementos que se mostraran despuesde iniciar sesion

Escenarios:

• 1. Cumplimiento de especificacion grafica.

Contexto: Pantalla despues de iniciar sesion

Evento: Usuario inicia sesion exitosamente


Resultado/Comportamiento esperado: Una vez el usuarioinicia sesion en la aplicacion, se debe presentar una ventana conel siguiente contenido:

En area de trabajo central, ubicada en la parte central de lapantalla:- Campo de texto para realizar filtro de estaciones.- Listado de estaciones.

En area de trabajo Opciones. Menu ubicado en la parte superiorderecha de la ventana, representado por el ıcono de tres puntosverticales, consta de:- Ordenar por troncal.- Ordenar alfabeticamente.

En area 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 contrasena.- Cerrar sesion.

Evidencias:

(a) 1-001-1a (b) 1-001-1b




6. Area de trabajo central


Rol: Usuario final

Caracterıstica/Funcionalidad:Area de trabajo central

Razon/Resultado:Definir los elementos del area central y su fun-cionalidad

Escenarios:

• 1. Listado de estaciones existentes en la base de datos.

Contexto: Presentacion del area central de trabajo, en la ven-tana principal.

Evento: Listado de estaciones

Resultado/Comportamiento esperado: Se debe presentarun listado de las estaciones que acutalmente se encuentran re-gistradas en el sistema (base de datos central), presentando elnombre 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 elque el consumo del servicio web, que retorna el listado de lasestaciones, no sea exitoso, se debe presentar en la pantalla cen-tral, un mensaje de notificacion de la incidencia, indicando quela informacion no esta disponible.La aplicacion presenta el mensaje [Mensaje codigo INF-2], indi-cando la novedad, y se presenta un boton que permtie recargar lainformacion, enviando nuevamente la peticion al servidor central.


Evidencias:


• 3. Funcionalidad del campo de filtro ubicado dentro delarea 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 estacion por su nombre, al introducircualquier texto, el listado de las estaciones debera modficarse, te-niendo en cuenta las estaciones en las cuales exista coincidenciasen el nombre con el texto ingresado.En el caso de que el texto ingresado no coincida con el nombre dealguna estacion, se presentara el mensaje [Mensaje codigo INF-3].


Evidencias:

(a) 1-002-3a (b) 1-002-3b


7. Area de trabajo Opciones


Rol: Usuario final

Caracterıstica/Funcionalidad:Area de trabajo Opciones

Razon/Resultado:Definir los elementos del area de trabajo de op-ciones y su funcionalidad

Escenarios:

• 1. Ordenamiento y agrupacion de las estaciones por tron-cal.

Contexto: Presentacion del area de trabajo de opciones

Evento: Ordenar por troncal

Resultado/Comportamiento esperado: El usuario desplie-ga el menu de opciones, y al seleccionar la opcion Ordenar portroncal, la aplicacion realiza un ordenamiento del listado de lasestaciones presentadas, agrupandolas por la troncal respectiva acada una de ellas.


Evidencias:


• 2. Ordenamiento alfabeticamente de las estaciones

Contexto:

Evento: Ordenar alfabeticamente

Resultado/Comportamiento esperado: El usuario desplie-ga el menu de opciones, y al seleccionar la opcion Ordenar al-fabeticamente, la aplicacion realiza un ordenamiento alfabetico,tomando como item de ordenamiento el nombre de la estacion.

Evidencias:



8. Area de trabajo Menu principal


Rol: Usuario final

Caracterıstica/Funcionalidad:Area de trabajo Menu principal

Razon/Resultado:Definir los elemenos del area de trabajo Menuprincipal y su funcionalidad.

Escenarios:

• 1. Realizar el cambio de contrasena

Contexto: Presentacion del area de trabajo Menu principal

Evento: Seleccion del menu cambio de contrasena.

Resultado/Comportamiento esperado: La aplicacion pre-senta una pantalla, en la que se muestra el email del usuario, queesta logueado actualmente, ası como tres campos de texto, queconstan de: contrasena actual, nueva contrasena, confirmacionde nueva contrasena. A continuacion de los campos, se muestraun boton que realizara el envıo de la verificacion de la informa-cion suministrada. Las diferentes respuestas que puede tomar laejecucion de este boton son:

- El usuario no ingresa ningun valor. Para este caso la aplica-cion presenta el mensaje [Mensaje codigo ERR-5].- Los valoressuministrados por el usuario en los campos, no coinciden conlas validaciones indicadas para el campo de contrasena, es decir,longitud mınima de 6 caracteres). Para este caso la aplicacionpresenta el mensaje [Mensaje codigo ERR-3].- Los valores de los campos nueva contrana y confirmacion denueva contrasena proporcionados por el usuario, no coinciden.La aplicacion presenta el mensaje [Mensaje codigo ERR-6].- El valor de la contrasena actual ingresada por el usuario, noconicide con la que actualmente se encuentra registrada en la ba-se de datos. La aplicacion presenta el mensaje [Mensaje codigoERR-7].Si el proceso de validacion es exitoso, para los criteriosmencionados anteriormente, la aplicacion realizara el cambio decontrasena en la base de datos del sistema central, presentarael mensaje [Mensaje codigo INF-4], y presentara nuevamente laventana principal de la aplicacion. (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 Sesion

Contexto:

Evento: EL usuario selecciona la opcion Cerrar Sesion del menuprincipal.

Resultado/Comportamiento esperado: La aplicacion deberadestruir la informacion que actualmente conserva en memoria(email y constrasena del usuario logueado), y presentar la pan-talla principal.

9. Presentacion ventana principal modulo buses/rutas


Rol: Usuario final

Caracterıstica/Funcionalidad:Presentacion ventana principal modu-lo buses/rutas

Razon/Resultado:Definir el comportamiento de la aplicacion, cuan-do se presenta la pantalla principal de los buses/rutas.

Escenarios:

• 1. Usuario logueado selecciona estacion y se despliega ellistado de los buses

Contexto: Pantalla despues de seleccionar estacion.


Evento: Usuario selecciona estacion.

Resultado/Comportamiento esperado: Al seleccionar la es-tacion, la aplicacion debera presentar una nueva pantalla con lassiguientes caracterısticas:Menu de opciones en la parte superior derecha, con las siguientesopciones:- Ordenar por nombre- Ordenar por troncalMenu lateral ubicado en la parte superior izquierda, que desplie-ga las mismas opciones presentadas en la pantalla anterior (versprint 2).Campo de texto que permitira realizar el filtro de las rutas queactualmente se presentan.Barra de color en la parte superior de la pantalla que lista lasrutas de una estacion, representando el nivel de congestion de laestacion. Siendo rojo el maximo nivel de congestion y verde elmınimo. (Amarillo y naranja, se presentan como colores de nive-les intermedios).Listado de rutas o buses que paran en la estacion 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 aplicacion debera presentar unapantalla emergente que permita realizar la calificacion del nivelde congestion de la parada de la ruta en la estacion, y presentarla pantalla descrita en las historias de usuario 3-xxx. La pantallade calificacion de la estacion debe contar con las siguientes ca-racterısticas:Nombre de la ruta o bus, estacion y troncal de la misma.Barra slide, que permita establecer la calificacion de la paradade la ruta en la estacion.Boton que permita enviar la informacion con la calificacion de laparada de la ruta en la estacion.


Evidencias:

(a) 2-001-2a (b) 2-001-2b




Evento: Usuario selecciona estacion, pero se pierde conexioncon el servicio.

Resultado/Comportamiento esperado: Para este caso laaplicacion debera retornar codigo de error ERR-008, y presentarnuvamente la pantalla del modulo de estaciones.

• 4. Ordenamientos por nombre

Contexto: Usuario selecciona los ordenamientos del panel deopciones.

Evento: Usuario selecciona ordenamiento por nombre

Resultado/Comportamiento esperado: La aplicacion deberaalterar la lista de buses, teniendo en cuenta el orden alfabetico


del nombre de cada ruta.

Evidencias:


• 5. Ordenamiento por troncal destino

Contexto: Usuario selecciona los ordenamientos del panel deopciones.

Evento: Usuario selecciona ordenamiento por troncal de des-tino

Resultado/Comportamiento esperado: La aplicacion deberaalterar la lista de buses, teniendo en cuenta el orden alfabeticode la troncal de destino de cada ruta.

Evidencias:



• 6. Busqueda filtrada

Contexto: Usuario ingresa informacion dentro del campo de tex-to de filtro por nombre

Evento: Usuario ingresa informacion al filtro de buses.

Resultado/Comportamiento esperado: La aplicacion deberaalterar la lista de buses, presentando unicamente los que tengancoincidencias por el nombre , con la informacion suministada enel campo de texto.

Evidencias:


10. Validar el funcionamiento del GPS


Rol: Usuario final

Caracterıstica/Funcionalidad:Validar el funcionamiento del GPS

Razon/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 notiene habilitado el GPS, se presenta mensaje del codigo ERR-9 yre-direcciona la aplicacion a la pantalla de la historia de usuario1-001.

Evidencias:


• 2. Se valida que el GPS este activo.

Contexto: Una vez el usuario selecciono y califico una ruta,se valida que el GPS del dispositivo este activo.

Evento: GPS Activo

Resultado/Comportamiento esperado: Ejecucion de la his-


toria de usuario 3-002.

Evidencias: Ver evidencias en historia de usuario 3-002

11. Visualizar la ubicacion aproximada de los buses que transitan enla ruta seleccionada.


Rol: Usuario final

Caracterıstica/Funcionalidad:Visualizar la ubicacion aproxima-da de los buses que transitan en la ruta seleccionada.

Razon/Resultado:Se presenta correctamente los componentes grafi-cos en la pantalla, posterior a la seleccion de una ruta

Escenarios:

• 1. Presentacion correcta de los componentes definidosen la pantalla para la ubicacion de buses

Contexto: Una vez el usuario selecciono y califico una ruta,se presentara en un mapa, la ubicacion y nivel de congestion delos buses que transitan bajo la misma.

Evento: Usuario califico una ruta en una estacion

Resultado/Comportamiento esperado: La pantalla para laubicacion de buses, estara conformada por los siguientes compo-nentes graficos:

1. Menu ubicado en la parte superior derecha, con las siguientesopciones:1.1 Ubicar bus menos congestionado1.2 Ubicar todos los buses1.4 Abordar Bus XX. Indicando la ruta seleccionada. EjemploB101.5 Abordar Bus vacıo.

2. Menu lateral ubicado en la parte superior izquierda, el cualcontiene las mismas opciones presentadas la historia de usuario1-001.

3. El area central esta compuesta por:3.1 Boton ubicado en la parte superior, empleado para consultarde nuevo la informacion de los buses que transitan en la ruta.Permanecera oculto, se describe en el escenario 2 de esta mismahistoria de usuario. (Consultar de Nuevo).3.2 Mapa en el que se mostrara los buses de la ruta seleccionada


y el nivel de congestion. Dibujar bus con color segun nivel decongestion actual. Se debe emplear Google Maps.

Evidencias:

(a) 3-002-1a (b) 3-002-1b


• 2. Mensaje informando la inconsistencia.

Contexto: Despues de calificar la ruta, se presenta un error enla conexion

Evento: Se presenta un error de conexion, despues de calificaruna ruta

Resultado/Comportamiento esperado: Al presentarse unerror de conexion en el consumo del servicio disenado para laconsulta de los buses que transitan en una ruta o en la genera-cion del mapa, se presentara el mensaje del codigo de ERR-8.Posteriormente se habilitara el boton: (Consultar de Nuevo), yse 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 estacion

Resultado/Comportamiento esperado: No se encuentranbuses en la ruta calificada, se presenta el mensaje del codigoINF-5. Se habilita el boton (Consultar de Nuevo), descrito en elescenario 2.

Evidencias:


12. Usuario puede ubicar el bus mas cercano o el menos congestio-nado.


Rol: Usuario final

Caracterıstica/Funcionalidad:Usuario puede ubicar el bus mascercano o el menos congestionado.

Razon/Resultado:Ubicar un bus en el mapa, acorde al criterio se-leccionado.

Escenarios:


• 1. Ubicar el bus menos congestionado.

Contexto: El usuario selecciona la opcion (Ubicar bus menoscongestionado), del menu superior derecho.

Evento: Seleccionar opcion: Ubicar bus menos congestionado.

Resultado/Comportamiento esperado: Se ubicara en el ma-pa el bus menos congestionado de la ruta calificada y su nivel decongestion. Dibujar bus con color segun nivel de congestion ac-tual.

Evidencias:


• 2. Error de conexion al consultar buses de ruta


Evento: Se presenta un error de conexion.

Resultado/Comportamiento esperado: Al presentarse un


error de conexion en el consumo del servicio disenado para laconsulta del bus menos congestionado en una ruta, se presen-tara el mensaje del codigo ERR-8. Posteriormente se habilitarael boton: (Consultar de Nuevo), descrito en el escenario 2 de lahistoria de usuario 3-002.

Evidencias:

• 3. Seleccionar ruta que no tenga buses registrados en elmomento de la consulta


Evento: No se encuentra buses en la ruta seleccionada.

Resultado/Comportamiento esperado: Si no se encuentrainformacion de buses que transitan en la ruta seleccionada, sepresenta el mensaje del codigo INF-5. Posteriormente se habili-tara el boton: (Consultar de Nuevo), descrito en el escenario 2de 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 opcion (Ubicar todos los bu-ses), del menu superior derecho.

Evento: Seleccionar opcion: 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 congestion del mis-mo.


Rol: Usuario final

Caracterıstica/Funcionalidad:Se requiere abordar Bus y calificarnivel de congestion del mismo.

Razon/Resultado:Calificar el nivel de congestion de un bus

Escenarios:



Contexto: Al seleccionar la opcion (Abordar Bus), del menusuperior derecho, se validara las condiciones basicas.

Evento: Validacion de GPS Inactivo.

Resultado/Comportamiento esperado: Si el dispotivo notiene habilitado el GPS, se presenta mensaje del codigo WAR-3 y se redirecciona la aplicacion a la pantalla de la historia deusuario 1-001.

Evidencias:


• 2. Valida la distancia entre la estacion y el usuario


Evento: Distancia entre usuario y estacion no es valida

Resultado/Comportamiento esperado: Si la distancia en-


tre la ubicacion actual del usuario y de la estacion es mayor aun valor determinado, se presenta el mensaje del codigo WAR-2y se ejecuta la historia de usuario 3-002.

Evidencias:


• 3. Valida la distancia entre el usuario y el bus que llevala ruta determinada


Evento: Distancia entre usuario y bus no es valida.

Resultado/Comportamiento esperado: Si la distancia en-tre la ubicacion actual del usuario y de un bus es mayor a unvalor determinado, se presenta el mensaje del codigo WAR-5 yse ejecuta la historia de usuario 3-002.


Evidencias:


• 4. Presentacion correcta de los componentes definidosen la pantalla para el abordaje de bus.

Contexto: Al seleccionar la opcion (Abordar Bus), del menusuperior derecho.

Evento: Al seleccionar la opcion (Abordar Bus)

Resultado/Comportamiento esperado: La pantalla para elabordaje de un bus esta compuesta por los siguientes componen-tes (El comportamiento de cada uno se describe en las siguienteshistorias de usuario):

1. Menu lateral ubicado en la parte superior izquierda, el cualcontiene las mismas opciones presentadas la historia de usuario1-001.

2. Menu ubicado en la parte superior derecha, con las siguientesopciones:2.1 Ubicar buses de ruta.


3. El area central esta compuesta por:3.1 Barra de calificacion en la que se indica el nivel de congestiondel bus que sera abordado. La barra presentara un formato decolor (degradado desde verde (indicando que no hay congestiondentro del bus) hasta rojo (indicando un nivel alto de congestiondentro del bus)). Una vez se realice la calificacion, se ocultara.Inicialmente el indicador de la barra esta en la mitad.3.2 Boton Calificar Bus.3.3 Mensaje de codigo INF-6. Solo sera visible cuando se hayacalificado exitosamente el nivel de congestion del bus.3.4 Boton para finalizar viaje (Finalizar Viaje). Solo sera visiblecuando se haya calificado exitosamente el nivel de congestion delbus.

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 opcion (Ubicar todos los bu-ses), del menu superior derecho en la pantalla para el abordajede bus.

Evento: Seleccionar opcion: 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 confirmacion.

Contexto: El usuario califica el nivel de congestion del bus.

Evento: Al seleccionar el boton calificar bus.

Resultado/Comportamiento esperado: Al seleccionar el boton,se presenta un mensaje de confirmacion con las opciones si o no.El mensaje corresponde al codigo WAR-4. Al seleccionar No, sedireccionara a la pantalla descrita en el escenario 4 de la presen-te historia de usuario (3-004). Al seleccionar Si, continua el flujohacia el siguiente escenario.

Evidencias:




Evento: Se presenta un error de conexion.

Resultado/Comportamiento esperado: Al presentarse un


error de conexion en el consumo del servicio disenado para califi-car el nivel de congestion de un bus, se presentara el mensaje delcodigo ERR-8. Posteriormente se presentara de nuevo los com-ponentes descritos en el escenario 1.

Evidencias:

• 8. Presentacion correcta de los componentes definidosdurante el viaje del usuario en el bus.


Evento: Calificacion de nivel de congestion de bus

Resultado/Comportamiento esperado: Despues de calificarel nivel de congestion de bus, se habilita los siguientes compo-nentes: 3.3 y 3.4 descritos en el escenario 4 de la presente historiade usuario(3-004).

Evidencias:


14. Se requiere abordar Bus vacıo.



Rol: Usuario final

Caracterıstica/Funcionalidad:Se requiere abordar Bus vacıo.

Razon/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, porlo cual tampoco se muestra en la lista de buses consultados enuna ruta especifica

Evento: Seleccionar opcion Abordar Bus vacıo

Resultado/Comportamiento esperado: El comportamientodebe ser el mismo de la historia de usuario 3-004. La unica ex-cepcion es que no debe validar la distancia entre el usuario y elbus, ya que el bus se creara por primera vez con esta accion.

Evidencias:



15. Se requiere enviar la ubicacion actual del usuario durante elviaje.


Rol: Usuario final

Caracterıstica/Funcionalidad:Se requiere enviar la ubicacion ac-tual del usuario durante el viaje.

Razon/Resultado: Enviar a un servicio la ubicacion de un usuario.

Escenarios:

• 1. Actualizacion de la ubicacion actual del usuario.

Contexto: Enviar periodicamente la ubicacion actual del usua-rio durante el viaje en el bus.

Evento: Enviar ubicacion del usuario

Resultado/Comportamiento esperado: Posterior a la califi-cacion del nivel de congestion del bus, la aplicacion enviara en uncierto periodo de tiempo (parametrizado en un archivo de confi-guracion, inicializado en 30 segundos) a un servicio, la ubicacionactual del usuario durante el viaje en el bus. De esta manera, conla informacion enviada desde cada dispositivo de los usuarios queviajan en un determinado bus, se podra establecer una ubicacionaproximada del mismo.

Evidencias:Esta ejecucion se realiza en segundo plano, por lo cual no esposible tomar una evidencia de la aplicacion movil. Al realizar laprueba se verifico que llegara la solicitud al WS y que se guardaracorrectamente la informacion en la base de datos.

16. Finalizar Viaje


Rol: Usuario final

Caracterıstica/Funcionalidad:Finalizar Viaje

Razon/Resultado:Enviar una notificacion al servicio, que se encar-ga de detener el proceso de actualizacion de la ubicacion actual delusuario.

Escenarios:

• 1. Finalizacion de viaje

Contexto: El usuario ha seleccionado la ruta que abordara, ca-lificado el estado de la misma, y se encuentra proximo 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 usuarioha seleccionado y calificado la ruta que desea; se presenta el ma-pa los diferentes buses que estan actualmente en servicio. En elmapa se debera mostrar un boton flotante que permite finalizarel viaje. Para el proceso de finalizacion del viaje, se debera dete-ner el proceso de actualizacion de ubicacion actual del usuario ypresentar la pantalla que lista las estaciones. Historia de usuario1-001.

Evidencias:Despues de presionar el boton de finalizar sesion se mostro nue-vamente el listado de estaciones como se esperaba.


17. Portal de Administracion


Rol: Usuario administrador


Caracterıstica/Funcionalidad: Administrar Informacion del Sis-tema de Informacion

Razon/Resultado: Realizar la gestion (Crear, Leer, Actualizar, Bo-rrar) de la informacion de Troncales, Estaciones, Rutas y relacionRuta-Estacion.

Escenarios:

• 1. Gestion de Troncales

Contexto: El usuario administrador ingresa a la opcion de Ges-tion de Troncales

Evento: Se realizan las distintas operaciones de gestion permi-tidas al usuario administrador sobre las troncales

Resultado/Comportamiento esperado: Se realiza la crea-cion, modificacion, lectura y borrado de Troncales de maneraexitosa.

Evidencias:VISTA PRINCIPAL DE PORTAL DE ADMINISTRACION



CREACION DE TRONCAL

Figura 2.47: Evidencias Historia de Usuario 4-001-1a[fuente: los autores]

EDICION DE TRONCAL

Figura 2.48: Evidencias Historia de Usuario 4-001-1b[fuente: los autores]


CONSULTA DE TRONCAL


ELIMINACION DE TRONCAL

Figura 2.50: Evidencias Historia de Usuario 4-001-1d[fuente: los autores]

• 2. Gestion de Estaciones

Contexto: El usuario administrador ingresa a la opcion de Ges-tion de Estaciones

Evento: Se realizan las distintas operaciones de gestion permi-tidas al usuario administrador sobre las Estaciones

Resultado/Comportamiento esperado: Se realiza la crea-cion, modificacion, lectura y borrado de Estaciones de maneraexitosa.


Evidencias:LISTADO DE ESTACIONES


CREACION DE ESTACION



EDICION DE ESTACION


CONSULTA DE ESTACION



ELIMINACION DE ESTACION

Figura 2.55: Evidencias Historia de Usuario 4-001-2e[fuente: los autores]

• 3. Gestion de Rutas

Contexto: El usuario administrador ingresa a la opcion de Ges-tion de Rutas

Evento: Se realizan las distintas operaciones de gestion permi-tidas al usuario administrador sobre las Rutas

Resultado/Comportamiento esperado: Se realiza la crea-cion, modificacion, lectura y borrado de Rutas de manera exitosa.

Evidencias:LISTADO DE RUTAS



CREACION DE RUTA


EDICION DE RUTA



CONSULTA DE RUTA


• 4. Gestion de Rutas por Estacion

Contexto: El usuario administrador ingresa a la opcion de Ges-tion de Rutas por Estacion

Evento: Se realizan las distintas operaciones de gestion permi-tidas al usuario administrador sobre las Rutas por Estacion

Resultado/Comportamiento esperado: Se realiza la crea-cion, modificacion, lectura y borrado de Rutas por Estacion demanera exitosa.

Evidencias:LISTADO DE RUTAS POR ESTACION (PARADA)



EDICION DE RUTA POR ESTACION (PARADA)


CONSULTA DE RUTA POR ESTACION (PARADA)



ELIMINACION DE RUTA POR ESTACION (PARADA)


2.1.4. Mensajes de Error, Informativos y de advertencia

Dentro de las historias de usuario se mencionan algunos mensaje que debenaparecer en la aplicacion, los cuales se listan a continuacion:

1. TABLA DE MENSAJES INFORMATIVOS

Cuadro 2.1: MENSAJES INFORMATIVOS

MENSAJES INFORMATIVOSNumeral MensajeINF-1 Usuario registrado exitosamente.INF-2 Infomacion no disponible. Intentelo de nuevo.INF-3 No se encontro nombre de estacion con el texto ingresado.INF-4 Cambio de contrasena exitoso.INF-5 No se encontro informacion 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

MENSAJES INFORMATIVOSNumeral MensajeWAR-1 Email invalido.WAR-2 No es posible abordar un bus estando lejos de una estacion.WAR-3 El GPS del dispositivo no esta activo.WAR-4 Esta seguro que desea calificar el nivel de congestion del bus?WAR-5 No es posible abordar un bus si no se ha registrado uno cerca a la estacion.

3. TABLA DE MENSAJES DE ERROR

Cuadro 2.3: MENSAJES DE ERROR

MENSAJES INFORMATIVOSNumeral MensajeERR-1 Email ya registrado.ERR-2 Email invalido.ERR-3 Contrasena invalida.ERR-4 Credenciales invalidas.ERR-5 Debe diligenciar los campos.ERR-6 La nueva contrasena y la confirmacion deben ser iguales.ERR-7 La contrasena actual es incorrecta.ERR-8 No se pudo establecer conexion con el servidor central.

2.1.5. Definicion de estructuras de datos

Con base en las definiciones funcionales generadas con las historias de usua-rio en cada sprint, se inicia la definicion tecnica de los componentes de softwarenecesarios para lograr la funcionalidad esperada.

A continuacion la definicion 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 LlaveidUser int (identity) PKemail varchar(100)password varchar(1000)registserDate DateTimelastModificationDate DateTime

2. Tabla ResponseCodes

Cuadro 2.5: Tabla ResponseCodes

Nombre de Campo Tipo de Dato Llavecode varchar(5) PKtype varchar(3) PKdescription varchar(200)

3. Tabla Troncals

Cuadro 2.6: Tabla Troncals

Nombre de Campo Tipo de Dato Llavecode int (autoincrement) PKidentificator char(1) PKname varhcar(100color varchar(7)


4. Tabla Routes

Cuadro 2.7: Tabla Routes

Nombre de Campo Tipo de Dato LlaverouteCode int(identity) PKname varchar(5)

5. Tabla Stations

Cuadro 2.8: Tabla Stations

Nombre de Campo Tipo de Dato LlavestationCode int (identity) PKname varchar(100)troncal int FKregistserDate DateTimelastModificationDate DateTimelatitude numeric(3,15)long numeric(3,15)

6. Tabla RouteStatation

Cuadro 2.9: Tabla RouteStatation

Nombre de Campo Tipo de Dato LlaverouteStationCode int(identity) PKstationCode int FKrouteCode int FKstationIndicator int


7. Tabla RouteStationQualification

Cuadro 2.10: Tabla RouteStationQualification

Nombre de Campo Tipo de Dato LlaverouteStationQualificationCode int(identity) PKqualification introuteStationCode int FKdateQualification dateTime()userId int FK

8. Tabla BusRouteQualification

Cuadro 2.11: Tabla BusRouteQualification

Nombre de Campo Tipo de Dato LlavebusRouteQualificationCode int(identity) PKqualification introuteCode int FKidBus int FKdateQualification dateTime()userId int FK

9. Tabla Bus

Cuadro 2.12: Tabla Bus

Nombre de Campo Tipo de Dato LlaveidBus int(identity) PKinitialLatitude decimal(9,6)initialLongitude decimal(9,6)qualification introuteCode int FKlastUpdateDate dateTime()


10. Tabla BusPosition

Cuadro 2.13: Tabla BusPosition

Nombre de Campo Tipo de Dato LlaveidBusPosition int(identity) PKactualLatitude decimal(9,6)actualLongitude decimal(9,6)dateTimePosition dateTIme()idBus int FK

2.1.6. Definicion de estructura del servicio web

1. Metodo OpRegisterUser

Cuadro 2.14: Metodo OpRegisterUser

OpRegisterUserRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

email string 5 NA resposeCode string 9 NApassword string 6 NA message string 10 NA

2. Metodo OpLoginSession

Cuadro 2.15: Metodo OpLoginSession

OpLoginSessionRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

email string 5 NA resposeCode string 9 9password string 6 NA message string 10 NA


3. Metodo OpGetStations

Cuadro 2.16: Metodo OpGetStations

OpGetStationsRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NA NA NA NA stationCode int 1 NANA NA NA NA name string 3 50NA NA NA NA idTroncal int 1 NANA NA NA NA troncal string 4 13NA NA NA NA identificatorTroncal char 1 1NA NA NA NA colorTroncal string 7 7

4. Metodo OpChangePassword

Cuadro 2.17: Metodo OpChangePassword

OpChangePasswordRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

email string 5 NA resposeCode string 9 9password string 6 NA message string 10 NAnewPassword string 6 NA

5. Metodo OpSetRouteStationQualification

Cuadro 2.18: Metodo OpSetRouteStationQualification

OpSetRouteStationQualificationRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

routeStationCode int 1 NA resposeCode string 9 9qualification int 1 NA message string 10 NAuser String 1 NA


6. Metodo OpGetStationQualification

Cuadro 2.19: Metodo OpGetStationQualification

OpGetStationQualificationRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

stationCode int 1 NA responseCode string 1 NAstationCode int 1 NA qualification int 1 NA

7. Metodo OpGetRoutesStations

Cuadro 2.20: Metodo OpGetRoutesStations

OpGetRoutesStationsRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

stationCode int 1 NA routeCode int 1 NAstationCode int 1 NA name string 1 5stationCode int 1 NA stationName string 1 100stationCode int 1 NA nameStartStation string 1 100stationCode int 1 NA troncalName string 1 100stationCode int 1 NA nameFinishStation string 1 100stationCode int 1 NA troncalColor string 1 7stationCode int 1 NA routeStationCode int 1 NA

8. Metodo OpGetRouteStationQualification

Cuadro 2.21: Metodo OpGetRouteStationQualification

OpGetRouteStationQualificationRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

stationCode int 1 NA responseCode string 1 NAstationCode int 1 NA qualification int 1 NA


9. Metodo OpSetQualificationBusRoute

Cuadro 2.22: Metodo OpSetQualificationBusRoute

OpSetQualificationBusRouteRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

routeCode int 1 NA responseCode string 1 NAidBus int 1 NA qualification int 1 NAqualification int 1 NA

10. Metodo OpGetRouteQualification

Cuadro 2.23: Metodo OpGetRouteQualification

OpGetRouteQualificationRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

routeCode int 1 NA responseCode string 1 NAstationCode int 1 NA qualification int 1 NA

11. Metodo OpGetBus

Cuadro 2.24: Metodo OpGetBus

OpGetBusRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

routeCode int 1 NA idBus int(identity) 1 NArouteCode int 1 NA latitudInitial numeric 1 NArouteCode int 1 NA longitudeInitial numeric 1 NArouteCode int 1 NA qualification int 1 NArouteCode int 1 NA routeCode int 1 NArouteCode int 1 NA lastUpdateDate dateTime() NA NA

2.2. GESTION DE COMUNICACIONES 97

12. Metodo OpSetBusPosition

Cuadro 2.25: Metodo OpSetBusPosition

OpGetBusRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

idBus int 1 NA responseCode int 1 NAlatitudeActual int 1 NA messageResponse string 1 NAlongitudeActual int 1 NA

13. Metodo OpCreateBus

Cuadro 2.26: Metodo OpCreateBus

OpCreateBusRequest Response

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

NombreCampo

TipoDato

LongitudMınima

LongitudMaxima

routeCode int 1 NA responseCode int 1 NAqualification int 1 NA messageResponse string 1 NAinitialLatitude int 1 NA idBus int 1 NAinitialLongitude int 1 NA idBus int 1 NA

2.2. Gestion de Comunicaciones

A nivel general dentro del proyecto se maneja una comunicacion personalen el horario de clase que se dispone para la especializacion cursada. Las de-finiciones funcionales, tecnicas, de documentacion, etc., son realizadas usandovideo-llamadas de Hangouts.Las historias de usuario, definiciones de estructura de base de datos y estructurade 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, tantopara consulta como para modificacion.

Capıtulo 3

Arquitectura Funcional

Para representar los distintos puntos de vista de la arquitectura funcionalse utilizara el lenguaje Archimate 2.0 en cada una de las secciones que sepresentan a continuacion.

3.1. Vista Motivacional

La vista motivacional representa las razones por las cuales se llega a pensar enun cambio de arquitectura empresarial, o en nuestro caso, las motivaciones quellevan al equipo del proyecto a realizar una propuesta para atacar el problemaespecifico planteado en capıtulos anteriores. [28]

3.1.1. Metamodelo

Figura 3.1: Metamodelo Vista Motivacional [28]

99

100 CAPITULO 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, quienessomos 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 abordaruna u otra ruta. Con base en ello se identifica una debilidad que tiene el ST quees la falta de informacion sobre el estado del ST en tiempo real y que pueda serconsultada por el usuario; ası mismo nos enfocamos en tres ıtem especıficos deesa falta de informacion.

Con base en el assessment identificado y sus agregaciones, se plantea el ob-jetivo de brindar esa informacion a los usuarios del ST, basado en esos objetivosse 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 lacomposicion 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 principalque es el usuario del ST que cumple el rol de usuario del dispositivo movil.Los servicios que permiten resolver los requerimientos identificados en la vistaanterior, son accedidos por el usuario a traves de la interfaz (aplicacion Android).

Dichos servicios son realizados por una serie de procesos internos que permi-ten cumplir el objetivo de brindar esa informacion especifica a los usuarios delST.

102 CAPITULO 3. ARQUITECTURA FUNCIONAL

Capıtulo 4

Arquitectura Tecnica

En esta seccion se empleara el lenguaje Archimate version 2.0, para presentargraficamente la descripcion y relacion de los diferentes componentes tecnicos di-senados para el desarrollo del sistema de informacion propuesto. Para lo anteriorse realizaran las diferentes vistas de la capa de aplicacion:

4.1. Vista Comportamiento de Aplicacion

Esta vista describe el comportamiento de una aplicacion, definiendo sus ser-vicios, funciones y sus interrelaciones. [28]

4.1.1. Metamodelo

Figura 4.1: Metamodelo Vista Comportamiento de Aplicacion [28]

103

104 CAPITULO 4. ARQUITECTURA TECNICA

4.1.2. Vista Comportamiento de Aplicacion iTransAgilApp

Figura 4.2: Vista Comportamiento de Aplicacion iTransAgilApp [fuente: losautores]

Mediante la vista de comportamiento de aplicacion, se describen los 3 prin-cipales componentes del sistema de informacion: Aplicacion Android iTransAgi-lApp, Aplicacion Web y Servicio Rest

A continuacion, se describen los componentes y funciones del servicio autenti-cacion, calificacion de estaciones, calificaciones de buses, creacion de estacionesy creacion de rutas:

ITransAgilApp es una aplicacion movil para dispositivos con sistema operativo

4.2. VISTA COOPERACION DE APLICACION 105

Android, mediante la cual el usuario podra autenticarse para poder consultary/o calificar estaciones y buses.

Aplicacion Web permite la creacion y actualizacion de estaciones y rutas.

Finalmente, todas las funciones son accesibles mediante operaciones publicadasen servicios rest, con los cuales toda la informacion es almacenada, consultaday actualizada en la base de datos.

4.2. Vista Cooperacion de Aplicacion

Describe las relaciones y flujos de informacion existentes entre los diferentescomponentes de aplicacion. Adicionalmente permite modelar la cooperacion in-terna entre los servicios que soportan la ejecucion de los procesos de negocio.[28]

4.2.1. Metamodelo

Figura 4.3: Metamodelo Vista Cooperacion de Aplicacion [28]

4.2.2. Vista Cooperacion de Aplicacion iTransAgilApp

En el diagrama, se describe graficamente que los componentes iTransAgi-lApp y Aplicacion Web usan el componente Servicio Rest, el cual tiene accesodirecto a la base de datos, haciendo uso de otro componente denominado Motorde base de datos SQLSever.


Figura 4.4: Vista Cooperacion de Aplicacion iTransAgilApp [fuente: los autores]

4.3. Vista Estructura de Aplicacion

Este punto de vista muestra la estructura de una o varias aplicaciones o com-ponentes. Presenta una herramienta util para entender la estructura de compo-nentes o aplicaciones. [28]

4.3.1. Metamodelo

Figura 4.5: Metamodelo Vista Estructura de Aplicacion [28]

4.3.2. Vista Estructura de Aplicacion 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 APLICACION 107

Figura 4.6: Vista Estructura de Aplicacion iTransAgilApp [fuente: los autores]

componente iTransAgilApp y Aplicaciones Web. Ver figura 4.6 Vista Estructurade Aplicacion

4.4. Vista Uso de Aplicacion

Este punto de vista permite describir como los componentes de aplicacionsoportan o son usados por los procesos de negocio. Permite el diseno de unaaplicacion al identificar los servicios necesarios por los procesos de negocio yotras aplicaciones. [28]

4.4.1. Metamodelo

Figura 4.7: Metamodelo Vista Uso de Aplicacion [28]


4.4.2. Vista Uso de Aplicacion iTransAgilApp

Figura 4.8: Vista Uso de Aplicacion iTransAgilApp [fuente: los autores]

En el diagrama propuesto para presentar el punto de vista uso de aplicacion,se relaciona los servicios definidos en la vista de comportamiento, con los pro-cesos planteados en la arquitectura funcional. De esta manera se describe comola capa de aplicacion ofrece y expone servicios para suplir las necesidades de lacapa de negocio. Ver figura 4.8: Vista Uso de Aplicacion 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 deaplicacion. [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 capalogica de aplicacion, 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 Investigacion

111

Capıtulo 5

Resultados y discusion

El objetivo general ası como cada uno de los objetivos especıficos se lograronen su totalidad ya que se genero un producto de alta calidad, tanto en el sistemade informacion compuesto por la base de datos y el servicio REST que la con-sulta/alimenta, como en la aplicacion movil Android que utiliza dicho sistemade informacion.

Se desarrollo exitosamente el modulo de administracion WEB que permitirarealizar la gestion de estaciones, rutas, y relacion de ruta/estacion (paradas decada ruta en determinadas estaciones).De la misma manera los modulos de recoleccion de informacion y consulta dela misma dentro de la aplicacion Android que permitira mostrar la informacionen los Smartphone de los usuarios del sistema transmilenio.

Se tuvo como premisa la simplicidad en la aplicacion y la facilidad de uso paraque los viajeros en el sistema transmilenio no inviertan mucho tiempo ni esfuerzoen obtener la informacion y en calificar estaciones/buses.

113

114 CAPITULO 5. RESULTADOS Y DISCUSION

Capıtulo 6

Conclusiones

6.1. Verificacion, contraste y evaluacion de losobjetivos

Debido a que el ST esta sometido a cambios constantes para satisfacer lasnecesidades de los usuarios, se requiere la implementacion de un modulode administracion que permita almacenar y actualizar la informacion deestaciones y rutas, de esta manera se podra contar con informacion realy actualizada en la base de datos. Este modulo de administracion serapublicado en un ambiente web, siendo accesible para una cantidad limitadade usuarios, asociados a un rol especıfico.

El exito de la implementacion del sistema de informacion propuesto en estainvestigacion, depende 100 por ciento de la recoleccion de informacion de lafuente primaria, en este caso la suministrada por los usuarios. Se requiereuna participacion de una gran cantidad de usuarios, para poder determinarun nivel de congestion, al igual que la ubicacion geografica de estacionesy buses, que sean lo mas aproximado posible a la realidad, con el objetivode presentar a los mismos una herramienta util de apoyo para la toma dedecisiones.

A pesar de que existen limitaciones como seguridad, acceso a internet pormedio de redes moviles, uso de dispositivos e incluso la aceptacion de losusuarios, sabemos que esta idea, puede influir en la mejora de la calidad delservicio de transporte, siempre y cuando una comunidad entera sea quiensuministre los datos necesarios, para poder generar informacion precisa ycoherente.

115

116 CAPITULO 6. CONCLUSIONES

6.2. Sıntesis del modelo propuesto

Teniendo en cuenta que el objetivo principal de la investigacion, constituıa laconstruccion de una aplicacion movil, basada en tecnologıa Android, para llegara la solucion del problema que en principio se desea atacar, se inicio un procesode investigacion de diferentes alternativas, dentro de las cuales resaltan portalesweb, modificaciones a nivel interno del sistema Transmilenio, entre otras.

No obstante, por diferentes motivos presentados previamente (a lo largo deldocumento), la alternativa tomada para solucionar el problema planteado, fueel desarrollo de una aplicacion movil, que sirva como herramienta principal parala toma de decisiones al momento del uso del sistema transmilenio.

Para llevar a cabo el proceso de construccion del prototipo, inicialmente sedebieron establecer unos alcances preliminares del mismo, teniendo en cuenta eltiempo del que se disponıa para el desarrollo de la investigacion, los recursos entiempo y dinero y los conocimientos con los que contaba el equipo de trabajo.Una vez definidos los alcances de la aplicacion se procedio a iniciar el procesode diseno de la aplicacion ası como un analisis motivacional y/o de viabilidaddel proyecto.

Durante la etapa de concepcion y planeacion del proyecto, como parte del meto-do que se abordo para el proceso investigativo, se realizo la creacion de un crono-grama general, dentro del cual posteriormente y en conjunto con la concepcionde la EDT (Estructura de Desglose de Trabajo) se detallaron las actividadesque deberıan ser ejecutadas, teniendo en cuenta su espacio en el cronograma.

El planteamiento de la metodologıa de desarrollo (metodologıa de desarrolloXP), mecanismos de levantamiento de requerimientos (historias de usuario), se-leccion de tecnologıas (Android para el desarrollo del prototipo de aplicacionmovil, tecnologıa REST para el desarrollo del servicio que sera consumido porla aplicacion, SQLSERVER como motor de base de datos), fueron los siguien-tes pasos a seguir para el modelo de investigacion del proyecto. Teniendo encuenta que se utilizo una metodologıa de desarrollo incremental, se realizo elplanteamiento, ejecucion y cierre de cada etapa realizando una retroalimenta-cion, 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 cuentael seguimiento del desarrollo, diseno de pruebas y ejecucion de las mismas. Fi-nalmente, se realiza el cierre de la investigacion, ajustando pormenores finalesde la aplicacion, cerrando las fases de planeacion, cronograma y presupuesto.

En resumen, el metodo usado para desarrollar el proyecto, presento bastantesbeneficios en particular a la hora del desarrollo de la aplicacion (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 delplazo especificado. Las principales ventajas que se perciben del metodo usadopara el desarrollo del proyecto, es la adecuada planificacion de las tareas y laoptimizacion del uso de los recursos disponibles, principalmente el tiempo. Te-niendo en cuenta los diferentes aportes que el equipo de trabajo recibio duranteel transcurso del postgrado, representaron una ayuda sustancial no solo en elprogreso del proyecto sino en la organizacion del mismo.

Como lecciones aprendidas y oportunidades de mejora se tiene una planeacionmas puntual de los requerimientos y de los alcances del proyecto, esto evitaratener que hacer cambios inesperados sobre la marcha. El metodo usado paracomunicar decisiones, cambios, ajustes, planeaciones, entre otros, puede mejo-rarse con el crecimiento del proyecto, dado que en determinadas ocasiones setendran alcances diferentes, e ıtems que requeriran de una precision y atencionmas puntual; luego el equipo de trabajo debe estar cohesionado y actuar en prodel cumplimiento de las diferentes obligaciones.

6.3. Aportes originales

Tomando como punto inicial para este segmento los alcances de la aplicaciony teniendo en cuenta que se presentan limitaciones de acuerdo al desarrollo dela aplicacion, principalmente los aportes que se plantean para el uso de la inves-tigacion son esencialmente para el area administrativa del ST; la cual a partirde la informacion capturada por la aplicacion podrıa implementar un modelo deadministracion de recursos (buses y diseno de rutas) que permitiera optimizar eldiseno de las rutas y velocidad de respuesta ante represamientos en el SistemaTransmilenio.

La arquitectura pensada para el proyecto permitira el uso del sistema de in-formacion (principalmente la base de datos), como un punto de partida de unanalisis inteligente acerca del funcionamiento cotidiano del sistema de Transmi-lenio, pero mas importante aun, de como los usuarios intervienen tıpicamenteen el mismo y como perciben el funcionamiento general del mismo.

El principal aporte que arroja el proyecto, es el uso sustancial de la informacionque sera recolectada por la aplicacion; dado que esta es enviada directamentepor los usuarios del ST, y consolidada de manera tal que se facilita un accesosencillo y directo a la misma, que puede ser usada como fuente en propuestasde modelos para la optimizacion del diseno de rutas del Sistema Transmilenio.

6.4. Trabajos o publicaciones derivadas

El desarrollo del proyecto permitio crear una herramienta que con el pasardel tiempo y el uso correcto por parte de los usuarios puede ser fuente para

118 CAPITULO 6. CONCLUSIONES

otros proyectos o artıculos relacionados con el sistema de transporte masivoTransmilenio de Bogota-Colombia. El aporte en temas como las causas de la altacongestion, comportamiento de los usuarios ante ciertos eventos en el sistema,medicion de capacidad de reaccion por parte de la administracion del sistemaTransmilenio, y otros temas que puedan usar la informacion procesada por laaplicacion desarrollada en el proyecto.

Capıtulo 7

Prospectiva del trabajo deGrado

7.1. Lıneas de investigacion futuras

Las lıneas de investigacion futuras identificadas en el desarrollo del proyectoson:

Administracion de Sistemas de transporte masivo basados en la informa-cion suministrada por los usuarios

Analisis de comportamiento de los usuarios en un sistema de transportemasivo en el uso del mismo

Correcto diseno de rutas en un sistema de transporte masivo

Implementacion de algoritmos de busqueda de ruta mas rapida en el sis-temas de transporte masivo

7.2. Trabajos de investigacion futuros

Ası mismo, los trabajos de investigacion futuros se encuentran en los mismosenfoques:

Implementacion de algoritmos de busqueda de ruta mas rapida para losusuarios en el uso del Sistema Transmilenio

Analisis y diseno de rutas del Sistema Transmilenio basadas en la infor-macion suministrada por los usuarios

119

120 CAPITULO 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: Embracechange, oct 2000.

[4] Borja Lopez Yolanda. Metodologıa Agil de desarrollo de software – xp. feb2011.

[5] Joskowicz Jose. Reglas y practicas en extreme programming. feb 2008.

[6] Cordero Jorge y otros. Baez Manuel, Borreo Alvaro. Introduccion a an-droid. jan 2010.

[7] Jesus Tomas Girones. El gran libro de android (segunda edicion), may2005.

[8] Android.com, 2014.

[9] Software de comunicaciones - arquitectura android, 2012.

[10] Android os, 2012.

[11] Arquitectura mulntinivel para la construccion 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 ’Simon’ Cuello. Disenando apps para moviles, 2013.

[16] Android, 2016.

[17] Algoritmos defnicion, 2016.

[18] Algoritmos para la ruta mas corta en un grafo, 2016.

[19] Ruta mas corta en grafos, 2016.

121

122 BIBLIOGRAFIA

[20] Algoritmos de aproximacion, 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 Engineersin Israel, IEEEI 2012, pages 1–4, 2012.

[27] Sobre Waze - ayuda de waze, 2016.

[28] The Open Group. ArchiMate 2.1 Specification, 2013.

facultad de ingenier ia - francisco josé de caldas...

Documents