Gestión de parqueos públicos con plataforma tecnológica

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
PLATAFORMA TECNOLÓGICA DE GESTIÓN DE ESPACIOS

PÚBLICOS DESTINADOS AL SERVICIO DE PARQUEOS
CASO: “GOBIERNO AUTÓNOMO MUNICIPAL DE LA PAZ”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA

MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS
POSTULANTE: LUIS MIGUEL MANTILLA CONDORI

TUTOR METODOLÓGICO: M.Sc. FRANZ CUEVAS QUIROZ
ASESORA: Lic. BRÍGIDA ALEXANDRA CARVAJAL BLANCO
LA PAZ – BOLIVIA
2017
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
Dedicatoria
A Dios.
Por haberme permitido llegar hasta
este punto, haberme dado salud y
por iluminar mi mente en cada paso
que doy.
A mis padres Genaro y Julia.

Por ser el pilar fundamental en todo
lo que soy, en toda mi educación
tanto académica, como de la vida y
sobre todo por su incondicional
apoyo perfectamente mantenido a
través del tiempo.
Todo este trabajo ha sido posible
gracias a ellos.
AGRADECIMIENTOS
Agradecer
A la Lic. Brígida Alexandra Carvajal Blanco, por el tiempo invertido; Sus conocimientos,
orientación, esfuerzo, dedicación, paciencia y su excepcional asesoría han sido fundamentales
para la elaboración del presente proyecto de grado.
Al M.Sc. Franz Cuevas Quiroz, por la paciencia y el tiempo brindado; A través de su
colaboración, persistencia, conocimiento y motivación me ha brindado una excelente tutoría en
la elaboración del presente proyecto de grado.
A la Ing. Juana Villca Marca y al Ing. Roberto Zambrana, por abrirme las puertas de la Unidad
de Desarrollo e Innovación Tecnológica del Gobierno Autónomo Municipal de La Paz y darme
la oportunidad de innovar desarrollando el presente proyecto.
Al Sr. Roberto Morales, por todo el conocimiento y apoyo brindados; Su manera de trabajar, su
persistencia y motivación han sido fundamentales para el desarrollo del presente proyecto
además de ser uno de los principales impulsores del mismo, en su calidad de Jefe de Proyectos
de la Unidad de Desarrollo e Innovación Tecnológica.

RESUMEN
El acceso a nuevas tecnologías por parte de la población se ha incrementado gradualmente a
nivel mundial, como también el uso de dispositivos móviles. Así mismo la utilización de las
mismas nos permiten proponer soluciones a problemas cotidianos de una manera innovadora
basados en conceptos como domótica y ciudades inteligentes, que comprenden varios enfoques
pero siempre tienden a mejorar la calidad de vida de la población. Uno de estos problemas es
el incremento del parque automotor en distintas ciudades del mundo y la poca cantidad de
estacionamientos en las mismas, son la fuente principal de grandes congestionamientos
vehiculares, más aun es el caso de la ciudad de La Paz-Bolivia, cuya estructura de angostas
avenidas dificulta el tránsito de vehículos en varias de sus vías.
La propuesta consiste en la desarrollo de una plataforma que permita gestionar espacios públicos
destinados al servicio de parqueos, basándose en el Plan de Movilidad Urbana Sostenible y el
Plan de trabajo para la gestión 2017 de la Secretaria Municipal de Movilidad del Gobierno
Autónomo Municipal de La Paz.
La plataforma consiste de una aplicación web desarrollada utilizando el framework Laravel y
de dos aplicativos móviles desarrollados para el sistema operativo Android, el desarrollo nativo
de ambos aplicativos móviles nos permite acceder a los recursos del sistema operativo como la
cámara, GPS e impresora térmica en dispositivos POS, de una manera muy sencilla.
Los resultados brindados por las pruebas comprueban, que según los ciudadanos encuestados,
la plataforma es bastante útil, necesaria y fácil de utilizar. Con lo cual se concluye que con la
implementación de la plataforma, se brinda un mejor servicio a la ciudadanía.
Palabras Clave: Plataforma Tecnológica, Aplicación móvil, parqueos

ABSTRACT
The Access to new technologies by the population has gradually increased worldwide, as has
the use of mobile devices. Also the use of the same allow us to propose solutions to daily
problems in an innovative way based on concepts such as home automation and smart cities,
which comprise several approaches but always tend to improve the quality of life of the
population. One of these problems is the increase of the car park in different cities of the world
and the small amount of parking in them, are the main source of great vehicular congestion,
more so is the case of the city of La Paz-Bolivia, whose structure of narrow avenues hinders the
transit of vehicles in several of its tracks.
The proposal consists of the development of a platform to manage public spaces for the parking
service, based on the Sustainable Urban Mobility Plan and the 2017 Work Plan for the Municipal
Secretary of Mobility of the Municipal Autonomous Government of La Paz.
The platform consists of a web application developed using the Laravel framework and two
mobile applications developed for the Android operating system, the native development of both
mobile applications allows us to access the operating system resources such as the camera, GPS
and thermal printer in devices POS, in a very simple way.
The results provided by the tests prove, according to the citizens surveyed, the platform is quite
useful, necessary and easy to use. It concludes that with the implementation of the platform, a
better service is provided to the citizens.
Key Words: Technology Platform, Mobile application, parking

ÍNDICE pág.
CAPITULO I ............................................................................................................................. 1
MARCO INTRODUCTORIO.................................................................................................. 1
1.1. ANTECEDENTES ............................................................................................................. 3
1.1.1. ANTECEDENTES INSTITUCIONALES ............................................................ 3
1.1.2. ANTECEDENTES DE PROYECTOS SIMILARES ........................................... 4
1.2. PLANTEAMIENTO DEL PROBLEMA .......................................................................... 6
1.2.1. PROBLEMA CENTRAL .................................................................................... 10
1.3. DEFINICIÓN DE OBJETIVOS ...................................................................................... 11
1.3.1. OBJETIVO GENERAL ...................................................................................... 11
1.3.2. OBJETIVOS ESPECÍFICOS .............................................................................. 11
1.4. JUSTIFICACIÓN ............................................................................................................ 11
1.5. ALCANCES Y LÍMITES ................................................................................................ 14
1.5.1. ALCANCES ........................................................................................................ 14
1.5.2. LÍMITES ............................................................................................................. 15
CAPITULO II .......................................................................................................................... 16
MARCO TEÓRICO ................................................................................................................ 16
2.1. CIUDADES INTELIGENTES Y GESTIÓN DE ESPACIOS PÚBLICOS .................... 17
2.1.1. Centros y Espacios Públicos Como Oportunidades ............................................ 18
2.1.2. Servicio de Parqueos a la Ciudadanía.................................................................. 19
2.1.3. Plataforma Tecnológica y Plataforma como Servicio ......................................... 20
2.2. INGENIERÍA WEB ......................................................................................................... 22
2.2.1. Metodología Scrum ............................................................................................. 22
2.2.2. Framework Laravel 5.4........................................................................................ 29

2.3. INGENIERÍA MÓVIL..................................................................................................... 30
2.3.1. Metodología Ágil Para Desarrollo De Software Móvil ....................................... 30
2.3.2. Mobile – D y Ciclo de Vida Mobile – D ............................................................. 31
2.3.3. JSON Web Tokens y Algoritmo SHA-256 ......................................................... 35
2.3.4. Android ................................................................................................................ 36
2.4. GEOLOCALIZACIÓN .................................................................................................... 39
2.4.1. Google Maps ....................................................................................................... 40
2.4.2. OpenStreetMap .................................................................................................... 41
2.4.3. Comparación entre Google Maps y OpenStreetMap ........................................... 42
CAPITULO III ........................................................................................................................ 45
MARCO APLICATIVO ......................................................................................................... 45
3.1. DESARROLLO DE LA PLATAFORMA ...................................................................... 45
3.2. PREGAME Y FASE DE EXPLORACIÓN E INICIALIZACIÓN ................................. 45
3.2.1. Concepción y Exploración................................................................................... 46
3.2.2. Indagación y Elaboración del Product-Backlog .................................................. 46
3.2.3. Especificación ...................................................................................................... 50
3.2.4. Inicialización ....................................................................................................... 52
3.3. GAME Y FASE DE PRODUCCIÓN ............................................................................. 58
3.3.1. Desarrollo de los Sprints ..................................................................................... 58
3.3.2. Iteraciones de aplicativos móviles ....................................................................... 69
3.4. POSTGAME Y FASE DE ESTABILIZACIÓN, PRUEBAS Y REPARACIONES ...... 87
3.4.1. Pruebas y Reparaciones ....................................................................................... 87
3.4.2. Calidad de Software............................................................................................. 90

3.5. PRUEBAS Y RESULTADOS ......................................................................................... 93
3.5.2. Resultados y Aceptación de la Plataforma ........................................................ 107
CAPITULO IV....................................................................................................................... 109
CONCLUSIONES Y RECOMENDACIONES .................................................................. 109
4.1. RECOMENDACIONES ................................................................................................ 110
REFERENCIA BIBLIOGRÁFICA ..................................................................................... 112
ANEXOS ................................................................................................................................ 118

ÍNDICE DE TABLAS pag.
Tabla 1.1 Costos para recuperar un vehículo infractor. ............................................................ 8
Tabla 1.2 Costos para el desarrollo y publicación de aplicaciones. ....................................... 12
Tabla 2.1 Componentes de la metodología Scrum. ................................................................ 23
Tabla 2.2 Elementos de la metodología Scrum. ..................................................................... 25
Tabla 2.3 Fases de la metodología Scrum. ............................................................................. 28
Tabla 2.5 Características del Framework Laravel .................................................................. 30
Tabla 2.6 Etapas de la fase de producción.............................................................................. 33
Tabla 2.7 Etapas de la fase de estabilización.......................................................................... 34
Tabla 2.8 Etapas de la fase de estabilización.......................................................................... 37
Tabla 2.9 Características de Google Maps ............................................................................. 40
Tabla 2.10 Características de OpenStreetMap ......................................................................... 42
Tabla 2.11 Comparación de características entre Google Maps y OpenStreetMap ................. 43
Tabla 3.1 Tareas realizadas para la obtención de requisitos................................................... 46
Tabla 3.2 Requerimientos básicos del proyecto. .................................................................... 47
Tabla 3.3 Product-Backlog de la plataforma. ......................................................................... 47
Tabla 3.4 Lista de requerimientos para las aplicaciones móviles........................................... 49
Tabla 3.5 Tabla de requerimientos no funcionales. ................................................................ 49
Tabla 3.6 Roles y personal involucrados en el desarrollo de la Aplicación web ................... 52
Tabla 3.7 Usuarios involucrados en el desarrollo de las Aplicaciones móviles ..................... 52
Tabla 3.8 Tabla de actores de la plataforma ........................................................................... 53
Tabla 3.9 Configuración del aplicativo web ........................................................................... 57
Tabla 3.10 Configuración de los aplicativos móviles............................................................... 57
Tabla 3.11 Errores encontrados en la plataforma ..................................................................... 87

Tabla 3.12 Solución de errores encontrados en la plataforma .................................................. 88
Tabla 3.13 Escala de medición ................................................................................................. 91
Tabla 3.14 Encuesta de Utilidad Percibida (UP) ...................................................................... 91
Tabla 3.15 Encuesta de Facilidad de Uso Percibida (FUP) ...................................................... 92
Tabla 3.16 Encuesta de Actitud Hacia el Uso .......................................................................... 92
Tabla 3.17 Repositorios de los aplicativos desarrollados ......................................................... 93
Tabla 3.19 Prueba para el rol del Agente GMT ....................................................................... 95
Tabla 3.20 Prueba para el rol del Ciudadano............................................................................ 99

ÍNDICE DE FIGURAS pag.
Figura 1.1 Organigrama de dependencia de la unidad. ............................................................ 4
Figura 1.2 Vehículo estacionado a pesar de la prohibición ...................................................... 7
Figura 1.3 Vehículo inmovilizado por un Cepo policial. ......................................................... 9
Figura 1.4 Módulos de la plataforma...................................................................................... 14
Figura 2.1 La base de la Smart City ....................................................................................... 21
Figura 2.2 Componentes de la metodología Scrum ................................................................ 24
Figura 2.3 Ejemplo Product Backlog. .................................................................................... 26
Figura 2.4 Ejemplo Sprint Backlog ........................................................................................ 27
Figura 2.5 Fases de la metodología Mobile-D ....................................................................... 31
Figura 2.6 Arquitectura de Android ....................................................................................... 38
Figura 2.7 Comparación de Sitios web que utilizan Google Maps y OpenStreetMap ........... 43
Figura 3.1 Arquitectura de la Plataforma ............................................................................... 51
Figura 3.2 Casos de uso de la plataforma. .............................................................................. 54
Figura 3.3 Modelo Entidad Relación de la Base de Datos ..................................................... 55
Figura 3.4 Diagrama de clases de la Base de Datos ............................................................... 56
Figura 3.5 Backlog del proyecto en Taiga. ............................................................................. 58
Figura 3.6 Planificación de los Sprints ................................................................................... 59
Figura 3.7 Planificación del primer Sprint utilizando la herramienta Taiga .......................... 60
Figura 3.8 Desarrollo del primer Sprint.................................................................................. 60
Figura 3.9 Página principal del aplicativo web ...................................................................... 61
Figura 3.10 Módulo de administración de personas de la aplicación web ............................... 62
Figura 3.11 Planificación del Segundo Sprint utilizando la herramienta Taiga ....................... 63
Figura 3.12 Desarrollo del Segundo Sprint .............................................................................. 64

Figura 3.13 Módulo de monitoreo de parqueos ........................................................................ 65
Figura 3.14 Módulo de multas y sanciones .............................................................................. 66
Figura 3.15 Planificación del Tercer Sprint utilizando la herramienta Taiga .......................... 67
Figura 3.16 Desarrollo del Tercer Sprint .................................................................................. 67
Figura 3.17 Mapa de calor del uso de parqueos ....................................................................... 68
Figura 3.18 Módulo de reportes general ................................................................................... 69
Figura 3.19 Aplicación móvil iParqueos .................................................................................. 70
Figura 3.20 Historia de usuario 1 ............................................................................................. 71
Figura 3.29 Historia de usuario 10 ........................................................................................... 74
Figura 3.30 Cronograma de Iteraciones ................................................................................... 74
Figura 3.31 Liberación de la primera iteración con 2 historias de usuario completadas ......... 75
Figura 3.32 Módulo de Loguin y Registro de la aplicación ciudadano .................................... 76
Figura 3.33 Modulo de registro y configuración de vehículos de aplicación ciudadano ......... 77
Figura 3.34 Liberación de la segunda iteración con 3 historias de usuario completadas ......... 78
Figura 3.35 Implementación de Google Maps en Android ...................................................... 79
Figura 3.36 Módulo de reserva de aparcamiento aplicación ciudadano .................................. 79

Figura 3.37 Módulo de historial de movimientos aplicación ciudadano .................................. 80
Figura 3.38 Liberación de la tercera iteración con 3 historias de usuario cerradas .................. 81
Figura 3.39 Módulo de Multas y sanciones de la aplicación ciudadano .................................. 82
Figura 3.40 Aplicación Móvil Institucional en su etapa final .................................................. 83
Figura 3.41 Loguin y Módulo de registro de alquiler de aparcamiento ................................... 84
Figura 3.42 Módulo de monitoreo de la aplicación institucional ............................................. 84
Figura 3.43 Liberación de la cuarta iteración con dos historias de usuario cerradas ............... 86
Figura 3.44 Módulo de reporte y emisión de sanciones aplicación institucional ..................... 87
Figura 3.45 Configuración tiempo de espera de respuesta en los sockets de los servicios ...... 89
Figura 3.46 Algoritmo de compresión de imágenes módulo de sanciones .............................. 90
Figura 3.47 Zona definida para la prueba piloto ...................................................................... 94
Figura 3.48 Resultado encuesta de Utilidad Percibida (UP) .................................................. 107
Figura 3.49 Resultado encuesta de Facilidad de Uso Percibida (FUP) .................................. 108
Figura 3.50 Resultado encuesta de Actitud hacia el uso ........................................................ 108

1
CAPITULO I
MARCO INTRODUCTORIO
El acceso a nuevas tecnologías por parte de la población se ha incrementado gradualmente a
nivel mundial, como también el uso de dispositivos móviles. Ante esto se ha generado un
movimiento tecnológico que permite proponer soluciones a problemas cotidianos de una manera
innovadora basados en conceptos como domótica y ciudades inteligentes, que comprenden
varios enfoques pero siempre tienden a mejorar la calidad de vida de la población.
Por otra parte se ha notado un incremento del parque automotor en distintas ciudades del mundo
y la poca cantidad de estacionamientos en las mismas, son la fuente principal de grandes
congestionamientos vehiculares y contaminación al medio ambiente, en el caso de la ciudad de
La Paz - Bolivia, cuya estructura de angostas avenidas, no tiene la capacidad para permitir la
circulación del parque automotor, que actualmente se encuentra en constante crecimiento y más
aún cuando vehículos son estacionados en ambos lados de las vías, provocando
permanente congestión vehicular.

2
Las municipalidades o ayuntamientos de diferentes países del mundo, como medida para hacer
valer sus políticas de estacionamiento en espacios públicos; como ser calles, avenidas, plazas,
entre otros; han optado por la utilización de una herramienta denominada parquímetro. Un
parquímetro es un dispositivo físico ubicado en vía pública y permite el ordenamiento como
también la medición del tiempo de estacionamiento de vehículos, su función consiste en
recolectar dinero a cambio del derecho de estacionar un vehículo en vía pública.
El Gobierno Autónomo Municipal de la Paz, en gestiones anteriores realizo la implementación
de parquímetros mecánicos en determinados espacios de parqueos públicos, los mismos fueron
retirados debido a diferentes fallas operativas, administrativas y por actos vandálicos que
sufrieron los dispositivos. En la actualidad la ciudad de La Paz no cuenta con ningún tipo de
parquímetros, sean mecánicos o electrónicos, en ninguna vía pública, ya que su implementación
sería en extremo oneroso para el municipio.
En el presente proyecto de grado, busca utilizar los avances tecnológicos que ofrece la
tecnología móvil, con el fin de implementar una plataforma de gestión de espacios públicos
destinados al servicio de parqueos para brindar un mejor servicio a la ciudadanía.
Algunos de los avances tecnológicos son: el Sistema de Posicionamiento Global denominado
GPS que permite determinar la posición de un objeto en toda la tierra con una precisión de hasta
centímetros, Otro avance es el gran número de smartphones que cuentan con sensor de posición
GPS y la comunicación de tiempo real.
Con el uso de las tecnologías anteriormente mencionadas se implementará una plataforma, que
permita efectuar el control, seguimiento y monitoreo de espacios públicos; además permitirá
realizar la gestión de sanciones y así mismo la gestión respectiva para el secuestro y devolución
3
de vehículos infractores por el mal uso de espacios públicos de acuerdo a normas impuestas por
el Gobierno Autónomo Municipal de la Paz.
La plataforma, contará con dos aplicaciones móviles una destinada al ciudadano y otra destinada
para el uso exclusivo de la institución; La aplicación destinada al ciudadano le permitirá al
usuario consultar, alquilar y pagar por el uso de un espacio público; La aplicación institucional
permitirá realizar el monitoreo y control de espacios públicos destinados al servicio de
parqueos, liberar espacios públicos, reportar y gestionar la sanción de vehículos por el mal uso
de espacios públicos. La plataforma también contará con una aplicación web que gestionará el
acceso a espacios públicos y permitirá la emisión de reportes acerca del uso de servicios.
1.1. ANTECEDENTES
1.1.1. ANTECEDENTES INSTITUCIONALES
El Gobierno Autónomo Municipal de la ciudad de la Paz denominado GAMLP, tiene como
misión mejorar la calidad de vida de los habitantes del Municipio de La Paz, generando y
ejecutando políticas de desarrollo integral en corresponsabilidad con su comunidad,
administrando su territorio y prestando servicios con transparencia, equidad, calidad y calidez;
con servidores públicos municipales motivados, comprometidos y con solvencia técnica.
La Unidad de Desarrollo e Innovación Tecnológica denominada UDIT, depende de la Dirección
de Gobierno Electrónico y Modernización de la Gestión denominada DGEM como se observa
en la Figura 1.1; La UDIT tiene como función principal desarrollar y administrar soluciones
tecnológicas para la gestión de información del Gobierno Autónomo Municipal, además de
promover la constante innovación tecnológica para la implementación del Gobierno Electrónico

4
y la mejora continua de los servicios en línea que presta el Gobierno Autónomo Municipal
(GAMLP, 2017).
La UDIT es encargada de la plataforma de Gobierno Electrónico Integra 24/7, que cuenta con
módulos complementarios como 24/7 Ciudadano, 24/7 Institucional, Motor de procesos Lotus
– IF, Aplicación móvil de participación ciudadana, entre otros. Dentro de los proyectos previstos
a desarrollo se encuentra la Plataforma de Control de Parqueos denominado i-Parqueos,
orientada a la gestión del servicio de espacios públicos.
La plataforma de control de espacios públicos denominada i-Parqueos, es una plataforma de
ordenamiento del estacionamiento en vía pública, que permitirá alquilar y pagar el uso de
parqueos en vía pública.
Unidad de Desarrollo e
Innovación Tecnológica
Figura 1.1 Organigrama de dependencia de la unidad.
Fuente: (GAMLP, 2017)
1.1.2. ANTECEDENTES DE PROYECTOS SIMILARES
En la carrera de Ingeniería en Sistemas Computacionales de la Universidad de Guayaquil,
Ecuador se realizó el proyecto de grado, con el tema: “Diseño e implementación de un sistema

5
que permita la integración de varios establecimientos de parqueo para vehículos livianos
del centro de Guayaquil, verificar la disponibilidad de parqueos en línea y administración
de reservas, para dispositivos móviles con plataforma Android” en el cual se logra
desarrollar un sistema denominado “Parqueo Fácil”, que permite integrar varios
establecimientos de parqueo de la zona bancaria de Guayaquil, utilizando: MySQL como
sistema de administración de base de datos Open Source, GlassFish Server 4.1 como servidor
de aplicaciones de código abierto, geo-posición y tecnología android (Guale, 2015).
En la Facultad de Ingeniería de la Pontificia Universidad Católica del Ecuador, Quito, Ecuador
se realizó el proyecto de grado, con el tema: “Implementación de un prototipo para la gestión
de sistemas de parqueo utilizando una red de sensores inalámbricos” en el cual se logra
desarrollar el prototipo de un sistema utilizando: El diseño lógico y físico de la red de sensores
basada en el protocolo IEEE 802.11, la plataforma Arduino, BitNami (Bitrock Inc n.d.),
tecnología android, php con el uso de frameworks Laravel, Huge, y Slim (Flores, 2015).
En la Facultad de Ingeniería Eléctrica y Electrónica de la Escuela Politécnica nacional, Quito,
Ecuador se realizó el proyecto de grado, con el tema: “Diseño e implementación de un
prototipo de sistema para parqueo utilizando una red de sensores inalámbricos” en el cual
se realiza la implementación del prototipo de un sistema de parqueo utilizando: una red de
sensores inalámbricos con tecnología IPv6, programación C#, tecnología Android (Santamaría,
2016).
En la Carrera de Ingeniería de Sistemas de la Universidad Técnica de Machala, Machala, El Oro
se realizó el proyecto de grado, con el tema: “Desarrollo de una aplicación móvil para la
gestión de espacios en un parqueadero de un centro comercial” en el cual se logró desarrollar

6
un prototipo de una aplicación móvil con una arquitectura cliente/servidor y una aplicación web
utilizando: PHP, MySQL, RWD (Responsive Web Design) y la librería Pusher para ofrecer
información en tiempo real (Pizarro, 2016).
En la carrera de Informática de la Universidad Mayor de San Andrés, La Paz, Bolivia se realizó
el proyecto de grado, con el tema: “Sistema web de seguimiento y control de supervisores y
obras basado en la geolocalización en dispositivos móviles caso: agencia estatal de
vivienda” en el cual se logra implementar un sistema Web utilizando: el sistema de
posicionamiento global denominado GPS, recursos que ofrece los dispositivos móviles como
acceso a cámara, acceso a mapas y acceso a internet (Mamani, 2016).
1.2. PLANTEAMIENTO DEL PROBLEMA
El parque automotor en la ciudad de la paz se ha incrementado exponencialmente en los últimos
años, según datos de la Secretaría Municipal de Gestión Ambiental actualmente en la urbe
paceña existe un total de 230.400 vehículos y se proyecta, que en un par de años más alcance a
313.000 (El Diario 1, 2016). Ante el incremento del parque automotor tanto del sector público
como particular, es evidente que no existen estacionamientos suficientes para abastecer a este,
a mediados del año 2016 tras el anuncio de las sanciones a los conductores que estacionen su
vehículo en espacios no permitidos en la ciudad de La Paz, la demanda de los parqueos públicos
se incrementó en un 20% según los administradores de parqueos privados, sin embargo, el centro
paceño tiene pocos espacios para dejar momentamente las movilidades (Asociación
Teledifusora Boliviana, 2016).
Por otra parte existe una notable falta de conocimiento de las normas de tránsito o simplemente
son ignoradas por parte de la ciudadanía, el Punto 3 del Artículo 127 de prohibiciones se afirma
7
que: Es prohibido estacionar, parar o detener vehículos: En las aceras, pasos de peatones o
lugares destinados exclusivamente al cruce de los mismos (Reglamento del Código del Tránsito,
1978). En el mes de marzo del año 2016 transito identifico que, al menos en 15 puntos de la
ciudad de La Paz no existen señales viales o éstas pasan desapercibidas, lo que dificulta el
ordenamiento del tráfico vehicular y peatonal, ante este hecho la Policía Boliviana, dio a conocer
todas estas deficiencias al gobierno municipal (Villa, 2016).
Las causas anteriormente mencionadas se desenvuelven generando una serie de problemas aún
mayores, la estrecha estructura de las calles y los vehículos que se estacionan a ambos lados de
las vías, provocan permanente congestionamiento vehicular (Silva, 2016). En un recorrido que
realizo La Razón, por 18 puntos de la ciudad, observó que los conductores parquean sus coches
donde quieren, a cualquier hora y por el tiempo que lo necesiten (Villa, 2016).
Figura 1.2 Vehículo estacionado a pesar de la prohibición
Fuente: Alejandro Álvarez.
Muchas veces dichos vehículos son estacionados por un corto lapso de tiempo por la necesidad
de no encontrar un parqueadero cercano o simplemente no tener conocimiento de la existencia
de uno cercano a su ubicación como se observa en la Figura 1.2.

8
El problema del parqueo de vehículos en las calles de La Paz no es nuevo, y episódicamente se
nos recuerda que no solo tiene que ver con la falta de espacio suficiente para todos los
automóviles y el poco respeto que merecen los carteles que prohíben el estacionamiento en
diversos puntos, sino también con las personas que se ofrecen a “cuidar” los coches por una
propina (La Razón 1, 2016).
Las Frente a los problemas mencionados anteriormente, es notable que los vehículos
estacionados en espacios públicos no autorizados suscitan problemas y molestia en la
ciudadanía, ante este hecho, en fecha 21 de junio, la Alcaldía de La Paz informó el inicio de los
operativos para remolcar a todo vehículo que esté estacionado en vías no autorizadas,
principalmente de las zonas de Miraflores, Centro y Sur de la ciudad. (Página Siete 1, 2016).
Los propietarios de vehículos infractores son multados con 300 bolivianos y también deben
pagar una suma igual por el uso de la grúa; Una vez que el vehículo sea trasladado al depósito
municipal se debe que cancelar también 50 bs por día que el vehículo permanezca en dicho
depósito, como se observa en la Tabla 1.1. Las acciones que realiza la Alcaldía de la ciudad de
La Paz están amparadas por la Ley Municipal de Transporte 1518 (GAMLP, 2016).
Tabla 1.1 Costos para recuperar un vehículo infractor.

Monto
Sanción
300 Bs.
Multa por la infracción
300 Bs.
Pago por el uso de la grúa
Uso del depósito edil 50 Bs. / día
Nota: Costos que deben cancelar los propietarios, para recuperar un vehículo
infractor que haya sido remolcado (GAMLP, 2016).

9
Para evitar que los conductores aparquen en lugares no permitidos, actualmente los reguladores
viales realizan controles continuos, expresó el Director de la Unidad Especial de Movilidad. Sin
embargo su trabajo se restringe debido a otros operativos y tareas que deben cumplir (Villa,
2016).
Es notable la falta de existencia de recursos humanos por parte de los reguladores viales para
realizar el control respectivo de espacios públicos, sin dejar de lado que como medida de sanción
para inmovilizar vehículos actualmente se utilizan Cepos1 como se observa en la Figura 1.3,
acción que limita físicamente las funcionalidades que debe cumplir el regulador vial.
Figura 1.3 Vehículo inmovilizado por un Cepo policial.
Fuente: Echave, M. (La Prensa, 2013)
No se cuentan con los recursos materiales suficientes como cepos y grúas para desempeñar la
labor de control de espacios públicos, por tal motivo se redujeron los operativos para el
remolque de vehículos mal estacionados y dicha acción se ha reducido a ser solo propaganda
(El Diario 2, 2016).
1
Es un artefacto ideado para sujetar, retener o inmovilizar algo, o alguien.
10
El año 2016 el GAMLP, indico que los funcionarios ediles emitirán una factura por la sanción
una vez que el vehículo sea cargado, además, se colocará un sticker en la acera o lugar de donde
sea remolcado el motorizado para anunciar que en ese lugar está prohibido estacionar (Página
Siete 1, 2016). La ciudadanía no acepta las sanciones emitidas por los reguladores viales,
muchas veces por los errores humanos que pueden ser cometidos al instante de aplicar una
sanción, los afectados piden alternativas para estacionarse mientras que los vecinos solicitan
que haya "mano dura”. La petición de todos los conductores sancionados por parquear sus
autos en diferentes vías es coincidente, “si van a prohibir que estacionemos, también nos tienen
que dar una alternativa o una solución. No hay parqueos seguros en la ciudad” indicaron los
afectados (Página Siete 2, 2016).
Ante todos los hechos descritos anteriormente se identificaron los siguientes problemas:
 Acumulación excesiva de vehículos sobre avenidas principales.
 Desconocimiento de la existencia de zonas de parqueo por parte de los ciudadanos.
 Limitación de recursos materiales para imponer sanciones a vehículos infractores.
 Carencia de recursos humanos por parte de las autoridades para realizar el control de
vehículos.
 Errores humanos al momento de la emisión de sanciones por parte de las autoridades.
1.2.1. PROBLEMA CENTRAL
¿La gestión de espacios públicos destinados al servicio de parqueos podrá brindar un mejor
servicio a la ciudadanía con nueva tecnología?

11
1.3. DEFINICIÓN DE OBJETIVOS
1.3.1. OBJETIVO GENERAL
Implementar una plataforma tecnológica de gestión de espacios públicos destinados al servicio
de parqueos para brindar un mejor servicio a la ciudadanía.
1.3.2. OBJETIVOS ESPECÍFICOS
 Desarrollar un módulo de control de espacios públicos en la aplicación móvil para coadyuvar
a reducir la congestión vehicular.
 Desarrollar un módulo de consultas que brinde información confiable acerca de la ubicación
y el estado de espacios públicos destinados al servicio de parqueos.
 Construir un módulo de gestión sanciones virtuales, que permita descartar el uso de recursos
materiales.
 Implementar un servicio en línea que brinde información confiable, disponible para optimizar
el uso de recursos humanos.
 Implementar un módulo de emisión y control de sanciones basado en georeferenciación,
captura de imágenes e información para acrecentar la emisión de sanciones.
 Realizar pruebas de calidad de software en la aplicación móvil y en la aplicación web.
1.4. JUSTIFICACIÓN
En lo económico, la tarea de control de espacios públicos no es nada sencilla, empresas ofrecen
soluciones a este problema con tecnología de monitoreo y su implementación sería en extremo
oneroso para el municipio de La Paz. La plataforma tecnológica, será desarrollada basada en
software libre promoviendo el plan de Implementación de software libre y estándares abiertos
de la Agencia de Gobierno Electrónico Tecnologías de la Información y Comunicación

12
(AGETIC, 2016), la aplicación móvil destinada a la ciudadanía también estará disponible en el
sistema operativo IOS.
El GAMLP cuenta con una licencia de desarrollador en Google Play, para realizar la publicación
de la aplicación destinada al ciudadano bajo la plataforma Android, se puede observar el costo
de la publicación en la Tabla 1.2. También cuenta con un servidor para la publicación de
servicios y para la publicación de la aplicación Web.
Tabla 1.2 Costos para el desarrollo y publicación de aplicaciones.

Descripción Costo
Tipo de Licencia
Es necesaria para distribuir 25 $, solo se paga una vez.

Licencia de desarrollador en
productos en la tienda de
Google Play
Google Play.
Total 25 $
Nota: Licencia para publicar aplicaciones en Google Play (Developer Console, 2016).
El proyecto presenta una solución innovadora al problema de monitoreo y control recurriendo
directamente a la Guardia Municipal de Transporte, promoviendo la optimización de funciones
desarrolladas por los mismos utilizando la política empresarial BYOD2. La plataforma
optimizara el uso de espacios públicos y será una fuente que genera recursos económicos para
el municipio de La Paz.
2
Abreviado en Ingles BYOD “trae tu propio dispositivo” es una política empresarial consistente en
que los empleados lleven sus propios dispositivos a su lugar de trabajo.
13
En lo social, la congestión vehicular en arterias principales de la ciudad de La Paz se ha vuelto
una situación bastante agobiante para el municipio especialmente en horas pico, un factor
prioritario que indirectamente coadyuva a dichas congestiones son los vehículos estacionados
en vías públicas sin control alguno provocando atascamientos, generando altos niveles de
contaminación, pérdidas de tiempo, y altos niveles de estrés en la ciudadanía.
La plataforma optimizara el uso de espacios públicos y ayudara indirectamente a reducir el
tráfico vehicular en las arterias principales de la ciudad de la paz, mejorando la calidad medio
ambiental y el bienestar de la ciudadanía.
En lo técnico, el proyecto busca una solución por medio de la implementación de una plataforma
tecnológica cuya finalidad es brindar información para realizar el control de espacios públicos
ayudando directamente a los conductores e indirectamente a todo el municipio de La Paz, será
una base consolidada para el desarrollo de futuros proyectos apuntando hacia el mismo objetivo.
El GAMLP actualmente cuenta con la tecnología necesaria para el desarrollo e implementación
del presente proyecto. Para el desarrollo e implementación de la plataforma tecnológica de
gestión de espacios públicos destinados al servicio de parqueos se utilizaran las siguientes
herramientas:
 Una computadora de escritorio.
 Un servidor de pruebas.
 Dos dispositivos móviles con sistema operativo Android 4.1.2 y 6.0.1 respectivamente.
 Un dispositivo P.O.S con impresora térmica y versión de Android 4.2.2.

14
1.5. ALCANCES Y LÍMITES
1.5.1. ALCANCES
La plataforma tecnológica de gestión de espacios públicos destinados al servicio de parqueos
cuenta con una aplicación web, una aplicación móvil destinada al ciudadano y una aplicación
móvil institucional desarrollada para dispositivos P.O.S. La plataforma cuenta con módulos
destinados a la aplicación web y a las aplicaciones móviles como se observa en la Figura 1.4.
PLATAFORMA
APLICACIÓN APLICACIÓN APLICACIÓN

WEB CIUDADANO INSTITUCIONAL
Módulo de Módulo de Módulo de Módulo de

Módulo de
monitoreo y consultas y emisión y
control de sanciones
alquiler de control de reportes.
espacios espacios virtuales. sanciones.
públicos. públicos.
Figura 1.4 Módulos de la plataforma

de gestión de espacios públicos destinados al servicio de parqueos.
La aplicación web permitirá gestionar los espacios públicos destinados al servicio de parqueos,
generara: reportes de vehículos en depósito, reportes de vehículos con grampa virtual y reportes
de vehículos a ser retirados a depósitos municipales.

15
La aplicación destinada al ciudadano le permitirá consultar la ubicación de parqueos cercanos a
su posición, realizar reservas con geo localización, realizar consultas de sus sanciones y su
historial de movimientos.
La aplicación institucional permitirá realizar el seguimiento y control de espacios públicos,
registro de multas y sanciones, consultar: reportes de vehículos en depósito, reportes de
vehículos con grampa virtual y reportes de vehículos a ser retirados a depósitos municipales.
1.5.2. LÍMITES
Los límites que se pueden observar en la implementación de la plataforma son los siguientes:
 Inicialmente las aplicaciones móviles solo estarán disponibles para el sistema operativo
Android.
 Para acceder a los servicios que ofrece la plataforma, se requiere una conexión estable a
internet.
 El monitoreo y control es responsabilidad del encargado de control y monitoreo.
 Para generar una sanción por el uso indebido de espacios públicos, el encargado de control y
monitoreo debe realizar la validación de datos correspondiente.
 Todas las notificaciones al ciudadano se realizaran vía SMS3, correo electrónico y por medio
de la aplicación móvil.
3 siglas del inglés Short Message Service, servicio de mensajes simples.

16
CAPITULO II
MARCO TEÓRICO
Las ciudades de América Latina y el Caribe denominado ALC son protagonistas de uno de los
procesos de crecimiento demográfico más significativos que ha vivido el planeta, con grandes
consecuencias para la sostenibilidad, la calidad de vida y la competitividad de la región. Hacer
frente a estos retos supone una evolución en el ámbito de la gobernanza y la toma de decisiones,
así como el uso cada vez más eficiente de los recursos de nuestras ciudades, con miras a
emprender una gestión inteligente (Bouskela, Casseb, Bassi, De Luca, & Facchina, 2016).
A partir de su uso cada vez más amplio, las Tecnologías de la Información y Comunicación
denominadas TIC se han convertido en un aliado fundamental de esta gestión inteligente en
ALC. Sin embargo, el uso de estas tecnologías debe ser entendido como un medio y no como
un fin en sí mismo, Iglesias (como se citó en Bouskela et al, 2016). Piensa que “No es
suficiente con tener ciudades inteligentes. También hace falta tener ciudadanos inteligentes”.
17
Las personas tienen un rol muy importante como beneficiarios y participantes de las
transformaciones, a partir del uso activo de dispositivos y aplicaciones móviles que facilitan
cada vez más el seguimiento y la colaboración con las políticas de sus gobernantes (Bouskela
et al, 2016).
2.1. CIUDADES INTELIGENTES Y GESTIÓN DE ESPACIOS PÚBLICOS EN

ZONAS URBANAS
La elevada concentración urbana plantea a las ciudades y a los países una serie de retos para
atender las necesidades de las poblaciones en crecimiento, comenzando con elementos básicos
como infraestructura, saneamiento, transporte, energía, vivienda, seguridad, empleo, salud y
educación, y pasando por otros también fundamentales como comunicación y esparcimiento.
Mantener a la ciudad funcionando de manera sostenible e integrada es ciertamente uno de los
grandes retos del siglo XXI.
Una ciudad inteligente es aquella que coloca a las personas en el centro del desarrollo y de la
planificación, de acuerdo con una visión de largo plazo. Es aquella que coloca en el centro de
la planificación al sistema de transporte público y la democratización del uso de los espacios
públicos, e impide el crecimiento de la ciudad hacia áreas de riesgo y vulnerabilidad frente a
desastres naturales. Es aquella que prioriza en su agenda la seguridad ciudadana, los servicios
públicos, la respuesta a emergencias, la disponibilidad de los recursos hídricos para las
generaciones futuras y la participación de los ciudadanos. Es aquella que usa la tecnología como
una herramienta para elaborar una visión y objetivos de largo plazo (Bouskela et al, 2016).
18
2.1.1. Centros y Espacios Públicos Como Oportunidades
En la medida en que los gestores públicos trabajan para crear ciudades más dinámicas,
sostenibles, creativas, resilientes, atractivas, inclusivas e innovadoras, es inevitable pensar en
una nueva planificación urbana a partir de los conceptos de Smart Cities. Después de todo,
solamente se puede administrar aquello que se puede medir; por ello, uno de los puntos más
importantes de las plataformas de Ciudades Inteligentes es exactamente basar su funcionamiento
e instancias de decisión en la recopilación y análisis de los datos de la ciudad (Bouskela et al,
2016).
Los centros urbanos son los lugares polisémicos de la ciudad, excepto cuando se homogeneizan
y especializan. El desafío urbano es hacer ciudad sobre la ciudad: regenerando, rehabilitando,
completando, creando nuevos centros metropolitanos, garantizando la movilidad, accesibilidad
y diversidad de los mismos. En la ciudad de ciudades la movilidad y la visibilidad son derechos
ciudadanos. La respuesta a los retos urbanos con proyectos urbanos comprometidos con
objetivos diferentes. La participación ciudadana es un debate político y cultural, orientado por
objetivos políticos explícitos y por la emergencia de los valores culturales e intereses sociales
implícitos. El espacio público es un desafío político, urbanístico y cultural referido a toda la
ciudad (Borja & Muxí, 2001).
En la ciudad de La Paz, existen numerosos lugares u espacios urbanizados, donde relativamente
existe mucha afluencia de personas con vehículos, los cuales hacen uso de estos espacios
públicos para estacionar los mismos. Esta acción es aprovechada por personas que ven estos
espacios públicos como espacios de oportunidades, donde hombres, mujeres y hasta ancianos y
niños ejercen control sobre el espacio disponible para el estacionamiento. En todos los casos,
19
los conductores deben acceder a pagar una propina al “cuidador” para evitar el riesgo de ver
luego la pintura rayada o algún accesorio roto (La Razón 1, 2016).
Según la Secretaria Municipal de Movilidad del GAMLP, denominada SMM, el Plan de
Movilidad Urbana Sostenible denominado PMUS en el año 2012, propone la gestión y
regulación de los estacionamientos como un instrumento de desincentivo del vehículo privado.
2.1.2. Servicio de Parqueos a la Ciudadanía
La Paz, como las ciudades troncales de Cochabamba y Santa Cruz, carecen de sitios de
estacionamiento y los que hay no se los respeta por parte de las mismas autoridades porque
cambian el momento menos esperado. No hay orden ni equidad para asignar sitios privados o,
si los hay, son simplemente para los bancos que han adquirido poder omnímodo en el país,
debido al poder financiero que han incrementado grandemente en los últimos diez años (El
Diario 3, 2016).
Según (El Diario 3, 2016), la Alcaldía de La Paz, debería encarar su construcción o incentivar
al capital privado en acuerdo con propietarios de terrenos para que se construya una
infraestructura que, además, implicaría grandes ingresos para quienes los instalen porque la
urgencia de contar con lugares de estacionamiento es cada vez más sentida.
Como se mencionó anteriormente la ciudad de La Paz se tiene unos escases de parqueos,
vivimos en una ciudad que comienza a adentrarse aún más en el mundo de la tecnología y la
innovación, el GAMLP y otras entidades tanto públicas como privadas día a día desarrollan
proyectos de innovación apoyándose fielmente en la tecnología, con la única finalidad de
encaminar a la Ciudad de la Paz hacia una ciudad inteligente, donde se integre a los ciudadanos
en las diversas esferas de la administración pública.

20
2.1.3. Plataforma Tecnológica y Plataforma como Servicio
Según Techopedia, una plataforma es un grupo de tecnologías que se utilizan como una base
sobre la que se desarrollan otras aplicaciones, procesos o tecnologías (Techopedia 1, 2017).
Plataforma como servicio denominado PaaS es un concepto que describe una plataforma de
computación que se alquila o se entrega como una solución integrada, una pila de soluciones o
un servicio a través de una conexión a Internet (Techopedia 2, 2017).
La pila de soluciones puede ser un conjunto de componentes o subsistemas de software
utilizados para desarrollar un producto o servicio totalmente funcional, como una aplicación
web que utiliza un sistema operativo, un servidor Web, una base de datos y un lenguaje de
programación. Más genéricamente, la pila de soluciones puede proporcionar un Sistema
Operativo, un middleware, una base de datos o una aplicación (Techopedia 1, 2017).
Según (Bouskela et al, 2016) Plataforma Tecnológica, es una capa de aplicaciones y sistemas
de comunicación que funcionarán como interfaces entre la gestión y los ciudadanos y las
diferentes estructuras y departamentos de una ciudad. Esos sistemas pueden servir como
plataformas de colaboración, o sea, la creación de aplicaciones móviles que permiten la
recolección de datos y la gestión participativa por parte de los ciudadanos y/o que permiten que
la ciudad se comunique con ellos para enviar alertas de emergencia o sugerencias de transporte
es un buen ejemplo de lo que se llama interfaces de comunicación.
En muchas ciudades, el uso creciente de las plataformas digitales accesibles vía web o por
teléfonos inteligentes integra a los ciudadanos en las diversas esferas de la administración
pública: desde la solicitud de servicios hasta el seguimiento de la rendición de cuentas de la

21
gestión municipal. Crear una ciudad inteligente requiere grandes inversiones (Bouskela et al,
2016).
Figura 2.1 La base de la Smart City

Fuente (Bouskela et al, 2016).
Independientemente de la aplicación, una solución de Smart City involucra procesos,
tecnologías y personas. Desde el punto de vista tecnológico, tiene invariablemente cuatro
elementos básicos como se observan en la Figura 2.1.

22
2.2. INGENIERÍA WEB
2.2.1. Metodología Scrum
Scrum aparece como una práctica destinada a los productos tecnológicos. En 1996 Jeff
Sutherland y Ken Schwaber presentaron las prácticas que se usaban como proceso formal para
el desarrollo de software y que pasarían a incluirse en la lista de Agile Alliance (Gallego, 2012).
Scrum es un marco de trabajo que ha sido usado para gestionar el desarrollo de productos
complejos desde principios de los años 90. Scrum no es un proceso o una técnica para construir
productos; en lugar de eso, es un marco de trabajo dentro del cual se emplean varias técnicas y
procesos. Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las
prácticas de desarrollo, de modo que podamos mejorar (Schwaber & Sutherlan, 2013).
Scrum al ser una metodología de desarrollo ágil tiene como base la idea de creación de ciclos
breves para el desarrollo, que comúnmente se llaman iteraciones y que en Scrum se llamarán
Sprints (Gallego, 2012).
a. Componentes de Scrum
Scrum se puede dividir de forma general en dos componentes que son las reuniones y los roles.
Las reuniones forman parte de los artefactos de esta metodología junto con los roles y los
elementos que los forman. En la Tabla 2.1, se describen los componentes de la metodología
Scrum así también sus componentes y la finalidad u objetivo que tienen cada uno.
23
Tabla 2.1 Componentes de la metodología Scrum.

Sub Componente Finalidad u Objetivo
Componente
Las Reuniones Planificación del Definir en un documento los requisitos del

Backlog sistema por prioridades. En esta reunión se
define la planificación del sprint 0.
Seguimiento del Sprint Realizar reuniones diarias para evaluar el

avance de las tareas con preguntas como:
 ¿Qué trabajo se realizó?
 ¿Qué trabajo se realizara?
 Inconvenientes que han surgido.
Revisión del Sprint Realizar una revisión del Sprint finalizado. Se

presentan los resultados finales y una demo o
versión, esto ayudará a mejorar el feedback con
el cliente.
 Toma las decisiones y conoce el negocio
Los Roles
Product Owner del cliente y su visión del producto.
 Se encarga de escribir las ideas del cliente,
las ordena por prioridad y las coloca en el
Product Backlog
Comprobar que el modelo y la metodología

Scrum Master
funcionan. Se encarga de eliminar todos los
inconvenientes que hagan que el proceso no
fluya e interactuará con el cliente y con los
gestores.
 Grupo formado por unas 3 a 9 personas.
Scrum Team  Organizan y toman decisiones para
conseguir su objetivo.
24
 Cada miembro del equipo está

involucrado en la estimación del esfuerzo
de las tareas del Backlog.
Fuente: (Gallego, 2012).
Las reglas de Scrum vinculan a los eventos, artefactos y roles, rigiendo las relaciones e
interacciones entre ellos como se observa en la Figura 2.2.
Figura 2.2 Componentes de la metodología Scrum

Fuente (Gallego, 2012)
b. Eventos de Scrum
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad
de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo o time-boxes, de
tal modo que todos tienen una duración máxima. Una vez que comienza un sprint su duración
es fija y no debe acortarse o alargarse. Los demás eventos deben terminar siempre que se alcance
el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir
desperdicio en el proceso. (Schwaber & Sutherland, 2013).

25
Durante el Sprint:
 No se realizan cambios que puedan afectar el objetivo del Sprint.
 Los objetivos de calidad no disminuyen.
 El alcance debe ser clarificado y renegociado entre el Dueño del Producto y el Equipo de
Desarrollo a medida que se va aprendiendo más.
c. Elementos de Scrum
En la Tabla 2.2, se detallan los elementos que forman a Scrum.
Tabla 2.2 Elementos de la metodología Scrum.

Descripción
Elemento
Product Backlog Inventario gestionado y creado por el cliente con la ayuda del Scrum
Master en el cual se almacenan todas las funcionalidades o requisitos
en forma de lista priorizada, debe contener las siguientes
características:
 Contener los objetivos del producto, para expresarlos se suele usar

las historias de usuario.
 Indicar el valor que le da el cliente y el coste estimado.
 Indicar las posibles iteraciones y los releases que se han indicado
al cliente.
 Posibles riesgos identificados e incluir las tareas necesarias para
solventarlos.
Sprint Backlog Lista de tareas que elabora el equipo durante la planificación de un

Sprint, se realiza la asignación de tareas a cada persona y el tiempo
que queda para terminarlas. De esta manera el proyecto se descompone
en unidades más pequeñas y se puede gestionar el avance de los
mismos.
26
Incremento Representa los requisitos que se han completado en una iteración y que
son perfectamente operativos. Según los resultados que se obtengan el
cliente puede ir haciendo los cambios necesarios y replantear el
proyecto.
Aunque no hay ningún producto especial a la hora de confeccionar la lista, según (Palacio &
Ruata, s.f) como se observa en la Figura 2.3, es conveniente que esta lista incluya información
relativa a:
 Identificador para la funcionalidad.
 Sistema de priorización u orden.
 Descripción de la funcionalidad.
 Estimación.
Figura 2.3 Ejemplo Product Backlog.

Fuente (Palacio & Ruata, s.f)
Las historias de usuario, son las especificaciones de las funcionalidades que va a tener el
software, las historias de usuario se componen de tres fases denominadas “Las 3 C”:
 Card: Que es una breve descripción escrita que servirá como recordatorio.
27
 Conversation: Es una conversación que servirá para asegurar lo descrito en la primera fase
y concretar el objetivo.
 Confirmation: Son tests funcionales para fijar detalles que sean relevantes e indicar cuál
será el límite.
Según (Gallego, 2012), generalmente las tareas a completar se suelen gestionar mediante el
Scrum Taskboard, a cada objetivo se le asignan las tareas necesarias para llevarlo a cabo, se
usan post-its que se van moviendo de una columna a otra para cambiar el estado.
Figura 2.4 Ejemplo Sprint Backlog

Fuente (Gallego, 2012)
d. Fases de Scrum
Según (Schwaber & Beedle, 2001), Scrum se estructura en tres fases, las cuales se describen en
la Tabla 2.3.
28
Tabla 2.3 Fases de la metodología Scrum.

Fase Descripción Finalidad
Pre-Game Especificación de las tareas que  Recopilación de requerimientos

se van a realizar en las iteraciones para conformar el Product-Backlog
y sus prioridades ya que la  Analizar los Riesgos y controles
arquitectura del sistema en esta apropiados para los riesgos.
fase es importante para el apoyo  Seleccionar las herramientas y la
del contexto y necesidades del infraestructura de desarrollo.
nuevo software.  Calcular o estimar el costo de cada
iteración.
Game En esta fase el producto va  Planeación del Sprint en dos

evolucionando con el desarrollo reuniones consecutivas donde se
de los Sprints. clarifica y prioriza nuevamente el
Product Backlog y crear el Backlog
del Sprint respectivamente.
 Desarrollo del Sprint, el trabajo se
organiza en iteraciones en no más
de 30 días. En esta fase se provee el
Sprint Backlog, los responsables y
la duración de la actividad.
 Revisión de Sprint, al final de cada
iteración se lleva a cabo una reunión
de revisión en donde se presenta la
nueva funcionalidad del producto,
diseño, ventajas, y esfuerzos.
Post-Game Luego de haber culminado todas Realizar la preparación operacional,

las iteraciones, resta la revisión incluyendo las pruebas y documentación
final denominado Cierre final.
29
2.2.2. Framework Laravel 5.4
Las plataformas para el desarrollo de aplicaciones web como herramientas facilitadoras
para el desarrollador, brindan una base sólida para la construcción de la misma. Los llamados
frameworks para PHP4, son un esquema para el desarrollo y/o la implementación de una
aplicación. Son un conjunto de archivos, en este caso PHP, que vienen preparados con toda
la estructura necesaria para desarrollar varios tipos de proyectos (Sierra, Acosta, Ariza, & Salas,
2013).
Laravel es un MVC5 web-development framework escrito en PHP. Este ha sido diseñado para
mejorar la calidad de software reduciendo el costo inicial de desarrollo y mejorando la
experiencia de trabajar aplicaciones abasteciendo una sintaxis de expresiones claras y un núcleo
de funcionalidad que llevaría mucho tiempo de implementación (McCool, 2012).
Fue creado en 2011 y actualmente está en continuo desarrollo. Este framework usa el paradigma
Orientado a objetos, permite el uso del patrón MVC, ORM6. Gran parte de Laravel está formado
por dependencias, especialmente de Symfony, esto implica que el desarrollo de Laravel
dependa del desarrollo de sus dependencias.
Laravel, propone en el desarrollo usar 'Routes with closures', en lugar de un MVC
tradicional con el objetivo de hacer el código más claro. Aun así permite el uso de MVC
tradicional (Sierra, Acosta, Ariza, & Salas, 2013).
Algunas características del Framework laravel se describen en la Tabla 2.5.
4
Acrónimo recursivo de Hypertext Preprocessor, PHP es un lenguaje de programación de uso general y de
código abierto.
5
Abreviado en Ingles MVC, Modelo Vista Controlador, es un patrón de arquitectura de software.
6
Abreviado en Ingles ORM, Mapeo Objeto-Relacional, es un modelo de programación.
30
Tabla 2.5 Características del Framework Laravel
Número Característica
1 Sistema de ruteo, también RESTful
2 Blade, Motor de plantillas
3 Peticiones Fluent
4 Eloquent ORM
5 Basado en Composer
6 Soporte para MVC
7 Usa componentes de Symfony
Fuente: (Sierra, Acosta, Ariza, & Salas, 2013).
2.3. INGENIERÍA MÓVIL
2.3.1. Metodología Ágil Para Desarrollo De Software Móvil
Una metodología de desarrollo es un conjunto de procedimientos, técnicas y ayudas a la
documentación para el desarrollo de productos de software, basada en experiencias obtenidas
durante la implementación de proyectos exitosos; sin embargo, al representar sólo una guía, el
desarrollador está en la libertad de modificarlas y adaptarlas a su realidad, tomando sólo lo más
útil de ellas. (Salo & Hulkko, 2005)
En el ámbito del desarrollo de software, existen dos tipos de metodologías, rígidas y ágiles, las
cuales difieren dependiendo del tipo, tiempo planificado y recursos disponibles.
Las metodologías ágiles son las más convenientes para el desarrollo de aplicaciones móviles,
debido a la velocidad con la que cambia el entorno, las tecnologías y las tendencias del mercado.
31
2.3.2. Mobile – D y Ciclo de Vida Mobile – D
Es una metodología para el desarrollo ágil de software, creado por un grupo de investigadores
del VTT7 en Finlandia. Además del desarrollo de software para móviles, es utilizada y
recomendada en varios contextos, como ser: seguridad, finanzas, logística y aplicaciones de
simulación.
Pruebas del
Exploración Inicialización Producción Estabilización
Sistema
Pruebas del
Establecimiento Configuración Día de planeación Día de planeación
Sistema
definicion del
Día de planeación Día de trabajo Día de trabajo Día de planeación
alcance
Establecimiento Finalización de la
Día de trabajo Día de liberación Día de trabajo
del proyecto documentación
Día de liberación Día de liberación Día de liberación
Figura 2.5 Fases de la metodología Mobile-D

Fuente (Salo & Hulkko, 2005)
Como se observa en la Figura 2.5, esta metodología se compone de 5 fases que son Exploración,
Inicialización, Producción, Estabilización y Pruebas del sistema. Cada una de las fases descritas
anteriormente tiene asociadas etapas, tareas y prácticas.
a. Fase de Exploración
El propósito de la fase de exploración es la planificación y establecimiento del proyecto. La
fase de exploración puede ser realizada con anticipación de tiempo a las otras fases.
7
Centro de Técnico de Investigación de Finlandia, es el centro de investigación multidisciplinario más grande del
norte de Europa. Provee soluciones y servicios con la más alta tecnología.
32
La fase de exploración es una fase importante para establecer las bases para la implementación
controlada de software en relación con el desarrollo de productos, por ejemplo, las cuestiones
relacionadas con la arquitectura del producto, proceso de desarrollo de software y la selección
de medio ambiente. Se necesitan diferentes grupos de interés para ofrecer su experiencia en la
fase de exploración.
Las metas de la fase de exploración son:
 Establecer los grupos de usuarios necesarios en la planificación y el seguimiento del
proyecto de desarrollo de software.
 Definir y acordar los objetivos y el alcance del proyecto de desarrollo de software.
 Planificar el proyecto respecto del medio ambiente, el personal y cuestiones de
procedimiento.
b. Fase de Inicialización
El propósito de la fase de inicialización es permitir que el éxito de las próximas fases del
proyecto mediante la preparación y verificación de todas las cuestiones fundamentales del
desarrollo a fin de que todos están en plena disposición al final de la fase para implementar los
requerimientos seleccionados por el cliente.
Las metas de esta fase son:
 Obtener una buena comprensión global del producto para el equipo del proyecto en base en
los requisitos iniciales y descripciones de línea arquitectura.
 Preparar los recursos físicos, técnicos y humanos, así como la comunicación con el cliente,
planes del proyecto y todo el desarrollo crítico para que todos ellos estén en plena
33
disposición para implementar los requisitos de ejecución seleccionados por el cliente
durante las próximas fases del proyecto.
c. Fase de Producción
El propósito de la fase de producción es implementar la funcionalidad requerida en el producto
mediante la aplicación del ciclo de desarrollo iterativo e incremental.
Las metas de la fase son:
 Implementar las funcionalidades al producto priorizadas por el cliente.
 Centrarse en la funcionalidad básica fundamental y priorizar su implementación en las
primeras iteraciones para permitir mejorar estas funcionalidades a través de los diferentes
ciclos.
Las etapas de esta fase se describen en la Tabla 2.6.
Tabla 2.6 Etapas de la fase de producción
Etapa Descripción
Día de planeación Se deben definir los contenidos para la

iteración, por ejemplo las historias de
usuario.
Día de trabajo Implementar la funcionalidad planeada de

una manera controlada.
Día de liberación El propósito es validar y verificar las

funcionalidades implementadas.
Generalmente termina con una liberación
del producto no oficial.
34
d. Fase de Estabilización
En esta fase nos aseguramos de la calidad de la implementación del proyecto, las metas de esta
fase son:
 Finalizar la implementación del producto.
 Mejorar y garantizar la calidad del producto.
 Finalizar la documentación del producto.
Las etapas de esta fase se describen en la Tabla 2.7.
Tabla 2.7 Etapas de la fase de estabilización
Etapa Descripción
Día de planeación Se definen los contenidos por ejemplo

historias de usuario y tareas, para la
implementación de características
restantes del producto y para mejorar
internamente y externamente la calidad
del producto.
Día de trabajo Finalizar la implementación del producto

como también mejorar y asegurar la
calidad del producto
Finalización de la documentación Finalizar la arquitectura de software,

diseño e interfaces de usuario e incorporar
estas en la documentación final.
Día de liberación Verificar y validar las funcionalidades

implementadas y la calidad de todo el
35
proyecto y su documentación, este día

termina con la liberación de todo el
software.
e. Fase de Pruebas y Reparaciones
El propósito de la fase de pruebas y reparaciones es verificar si el sistema producido implementa
la funcionalidad definida por el cliente correctamente, se provee retroalimentación de parte del
equipo sobre las funcionalidades y se reparan los errores encontrados.
Las metas de esta fase son:
 Probar el sistema basado en la documentación del mismo.
 Proveer información sobre los errores encontrados.
 Permitir al equipo planear un plan para reparar los errores encontrados.
 Reparar los errores encontrados de acuerdo al plan elaborado.
 Producir un sistema tan libre de errores como sea posible.
2.3.3. JSON Web Tokens y Algoritmo SHA-256
Denominado JWT, es un estándar abierto RFC 7519, que define una forma compacta y
autónoma para transmitir de forma segura la información entre las partes como un objeto JSON8.
Esta información puede ser verificada y confiable porque está firmada digitalmente. Los JWT
8
JSON, acrónimo de JavaScript Object Notation, es un formato de texto ligero para el intercambio de datos.
36
se pueden firmar usando un secreto con el algoritmo HMAC9, o un par de claves públicas /
privadas usando RSA10.
JWT tiene las siguientes características:
 Compactos, Debido a su tamaño más pequeño, los JWT pueden enviarse a través de una
URL, un parámetro POST o dentro de una cabecera HTTP. Además, el tamaño más
pequeño significa que la transmisión es rápida.
 Autónomo, La carga contiene toda la información necesaria sobre el usuario, evitando la
necesidad de consultar la base de datos más de una vez.
Dentro de la estructura que maneja JWT, consta de tres partes separadas por puntos (.), Que son:
 Header, que es el encabezado normalmente consta de dos partes: el tipo del token, que es
JWT, y el algoritmo de hashing que se utiliza, como HMAC SHA256 o RSA
 Payload, la segunda parte de la ficha es la carga útil, que contiene las reivindicaciones. Las
reivindicaciones son declaraciones sobre una entidad y metadatos adicionales. Existen tres
tipos de reclamaciones: reclamaciones reservadas, públicas y privadas.
 Signature, Para crear la parte de la firma hay que tomar el encabezado codificado, la carga
útil codificada, un secreto, el algoritmo especificado en el encabezado, y firmarlo.
2.3.4. Android
a. Arquitectura
Android es una pila de software de código abierto basado en Linux creada para una variedad
9
HMAC, en criptografía es un código de autenticación de mensajes en clave-hash.
10
RSA, en criptografía (Rivest, Shamir y Adleman), es un sistema criptográfico de clave pública desarrollado en
1977.
37
amplia de dispositivos y factores de forma. En la Tabla 2.8, se describe los componentes
principales de la Arquitectura de la plataforma Android.
Tabla 2.8 Etapas de la fase de estabilización
Componente Descripción
Kernel de Linux  Es la base de la plataforma Android.

 Permite que Android aproveche funciones de seguridad claves y,
al mismo tiempo, permite a los fabricantes de dispositivos
desarrollar controladores de hardware para un kernel conocido.
Capa de  La capa de abstracción de hardware (HAL) brinda interfaces

abstracción de estándares que exponen las capacidades de hardware del
hardware (HAL) dispositivo al framework de la Java API de nivel más alto.
Tiempo de  Para los dispositivos con Android 5.0 (nivel de API 21) o
ejecución de versiones posteriores, cada app ejecuta sus propios procesos con
Android sus propias instancias del tiempo de ejecución de Android (ART).
Bibliotecas  La plataforma Android proporciona la API del framework de

C/C++ nativas Java para exponer la funcionalidad de algunas de estas
bibliotecas nativas a las apps.
Framework de la  Todo el conjunto de funciones del SO Android está disponible

API Java mediante API escritas en el lenguaje Java.
Apps del sistema  En Android se incluye un conjunto de apps centrales para correo
electrónico, mensajería SMS, calendarios, navegación en Internet
y contactos, entre otros elementos.
Fuente: (Developers Android, 2016).

38
Figura 2.6 Arquitectura de Android

Fuente (Developers Android, 2016)
Así mismo, en la Figura 2.6, se puede observar los componentes y las partes principales que
supone cada una dentro de la arquitectura de la plataforma Android.
b. Entrono de Desarrollo Android Studio

Según (Developers Android, 2016), Android Studio es el entorno de desarrollo integrado
denominado IDE11, oficial para el desarrollo de aplicaciones para Android y se basa en IntelliJ
11
Abreviado en Ingles, IDE entorno de desarrollo integrado, es una aplicación informática que proporciona
servicios integrales para facilitar el desarrollo de software.
39
IDEA12. Además del potente editor de códigos y las herramientas para desarrolladores de
IntelliJ, Android Studio ofrece aún más funciones que aumentan tu productividad durante la
compilación de apps para Android, como las siguientes:
 Sistema de compilación flexible basado en Gradle13.
 Entorno unificado para desarrollo en todo tipo de dispositivos Android.
 Instant Run, para aplicar cambios sin la necesidad de compilar un nuevo APK14.
 Integración de plantillas de código y GitHub.
 Herramientas Lint para detectar problemas de rendimiento, uso, compatibilidad de versión,
etc.
 Compatibilidad con C++ y NDK
 Soporte integrado para Google Cloud Platform.
2.4. GEOLOCALIZACIÓN
La geolocalización es la capacidad para obtener la ubicación geográfica real de un objeto, como
un radar, un teléfono móvil o un ordenador conectado a Internet. La geolocalización puede
referirse a la consulta de la ubicación, o bien para la consulta real de la ubicación. El término
geolocalización está estrechamente relacionado con el uso de sistemas de posicionamiento, pero
puede distinguirse de estos por un mayor énfasis en la determinación de una posición
significativa (por ejemplo, una dirección de una calle) y no sólo por un conjunto de coordenadas
geográficas. Este proceso es generalmente empleado por los sistemas de información
geográfica, un conjunto organizado de hardware y software, más datos geográficos, que se
12
IntelliJ IDEA, es un ambiente de desarrollo de programas informáticos, es desarrollado por JetBrains.
13
Graddle, es una herramienta para manejar y automatizar los procesos de compilación y construcción de
proyectos de software.
14
Abreviado en Ingles APK, Aplicación Empaquetada de Android, es un paquete para el SO Android.
40
encuentra diseñado especialmente para capturar, almacenar, manipular y analizar en todas sus
posibles formas la información geográfica referenciada.
2.4.1. Google Maps
Google Maps es un servidor de aplicaciones de mapas en la web que pertenece a Alphabet Inc.
Ofrece imágenes de mapas desplazables, así como fotografías por satélite del mundo e incluso
la ruta entre diferentes ubicaciones o imágenes a pie de calle con Google Street View.
Existe una variante a nivel entorno de escritorio llamada Google Earth que ofrece Alphabet Inc.
también de forma gratuita. En 2014, los documentos filtrados por Edward Snowden revelaron
que Google Maps es parte y víctima del entramado de vigilancia mundial operado por varias
agencias de inteligencia occidentales y empresas tecnológicas.
En la Tabla 2.9, se pueden observar algunas de las características que ofrece Goolge Maps.
Tabla 2.9 Características de Google Maps
Nro Característica Descripción
1 Básicas  Ofrece la capacidad de realizar acercamientos y

alejamientos para mostrar el mapa.
 Control del nivel del Zoom
 Búsqueda de direcciones desde palabras
 Coordenadas, están en el sistema WGS84 y se
muestra la latitud y la longitud, positiva para Norte y
Este, negativa para Sur y Oeste.
2 Avanzadas Google añadió un indicador de vehículo, en el cual una

persona puede ubicar un taxi o un transporte público en
una gran ciudad en tiempo real.
41
3 Imágenes ofrecidas por Cuenta con vistas provistas desde un satélite, en 2005 el
satélite satélite de Google Maps llamado DigitalGlobe, es el que
proveía la mayor cantidad de imágenes satelitales.
4 Multivistas En el año 2005, se lanzó la una vista dual de Google

Maps, esta vista se combina de los mapas tradicionales
y la vista satelital con mapas ilustrados.
Fuente: (Wikipedia 3, 2017).
2.4.2. OpenStreetMap
También conocido como OSM, es un proyecto colaborativo para crear mapas libres y editables;
Los mapas se crean utilizando información geográfica capturada con dispositivos GPS móviles,
orto fotografías y otras fuentes libres. Esta cartografía, tanto las imágenes creadas como los
datos vectoriales almacenados en su base de datos, se distribuye bajo licencia abierta Licencia
Abierta de Bases de Datos.
En octubre de 2014 en el proyecto estaban registrados en torno a 1.840.000 usuarios, de los
cuales alrededor de 22.600 realizaban alguna edición en el último mes. El número de usuarios
crece un 10% por mes. Por países el mayor número de ediciones provienen de Alemania,
EE.UU., Rusia, Francia e Italia.
Los usuarios registrados pueden subir sus trazas desde el GPS y crear y corregir datos vectoriales
mediante herramientas de edición creadas por la comunidad OpenStreetMap. Cada semana se
añaden 90.000 km de nuevas carreteras con un total de casi 24.000.000 km de viales (febrero de
2011), eso sin contar otros tipos de datos (pistas, caminos, puntos de interés, etc.). El tamaño de
la base de datos llamada planet.osm se situaba en febrero de 2011 por encima de los 205
gigabytes, incrementándose diariamente en unos 10 megabytes de datos comprimidos.

42
En la Tabla 2.10, se puedn observar algunas de las caracterisiticas de OpenStreetMap.
Tabla 2.10 Características de OpenStreetMap
Nro Característica
 La cobertura de datos se extiende al conjunto de todos los países del mundo,
1
siendo esta cada vez mayor en las regiones emergentes del planeta.
 El crecimiento es sorprendentemente constante, lo que significa una gran
2
cantidad de personas trabajando activamente en aportar datos al mapa.
 La gran cantidad de datos que soporta la base de datos de OSM está llegando a
3
un nivel que hace que sea difícil procesarlos sin una infraestructura de
servidores costosos. Esta es una de las razones por la que, según el informe, se
ha incrementado el soporte por parte de empresas comerciales a la cartografía
de OSM.
 A pesar del fuerte aumento de requerimientos técnicos por el gran volumen de
4
datos que se maneja, la infraestructura de servidores del proyecto parece ser
todavía muy estable.
 Observando las tendencias en la expansión de cobertura y el soporte que se
5
está dando a los datos de OSM por terceros, el proyecto está listo para ser
adoptado en servicios de navegación tradicional y aplicaciones LBS.
Fuente: (Wikipedia 4, 2017).
2.4.3. Comparación entre Google Maps y OpenStreetMap
Realizando la comparación entre Google Maps y OpenStreetMaps, se tiene que la principal
diferencia es el uso que tienen ambos a nivel internacional, en el caso de Google Maps se tiene
que una cantidad de 5.633.3400 sitios web lo utilizan a diferencia de OpenStreetMap que tan
solo tiene un total de 11.087 sitios web, que lo utilizan, como se observa en la Figura 2.7.
43
Figura 2.7 Comparación de Sitios web que utilizan Google Maps y OpenStreetMap
Fuente (similartech, 2017).
Así mismo, una de las razones por la que Google Maps es más utilizado, es porque es soporta
en más navegadores que OpenStreetMap, como también tienen influencia el máximo nivel de
Zoom, y la cantidad de tipos de mapas, entre otras como se observa en la Tabla 2.11.
Tabla 2.11 Comparación de características entre Google Maps y OpenStreetMap
Caracteristica Google Maps OpenStreetMap
Los soportes de IE7 +, Firefox 2.0.0.8+, Safari IE7 +, Mozilla Firefox 3.5 +,
navegador Web 3+, Mozilla 1.7+, Opera 8.02+, Google Chrome 4+, Safari 4+
Google Chrome 1+
Nivel máximo zoom 22 19
Tipos de mapas Mapa con los datos de tráfico de Mapa estándar, Transportes
tránsito (por separado y ver su Mapa, Mapa del ciclo,
bicicleta), vía satélite con los humanitaria
datos de tráfico (LIDAR 3D
para ciertos lugares que no
44
están presentes en la mayoría de

los lugares), híbrido
Modo 3D Si No
Servicio de dirección Dirección API Google El uso de servicios de terceros
Servicio de dirección Si El uso de servicios de terceros

inversa
Direcciones de Si El uso de servicios de terceros

bicicletas (zonas restringidas)
Contacto Integración Si No
Información sobre el Si El uso de servicios de terceros

tráfico en Tiempo Real (zonas restringidas)
Turn-by-Turn Si El uso de servicios de terceros

Navigation (zonas restringidas)
Fuente: (Agilestorelocator, 2017).

45
CAPITULO III
MARCO APLICATIVO
3.1. DESARROLLO DE LA PLATAFORMA
El desarrollo del proyecto está enmarcado en las metodologías agiles de desarrollo Scrum y
Mobile–D, ambas metodologías están orientadas al desarrollo de aplicaciones web y
aplicaciones móviles respectivamente, en este capítulo se describe el desarrollo del prototipo de
la plataforma en cada una de sus fases.
3.2. PREGAME Y FASE DE EXPLORACIÓN E INICIALIZACIÓN
En ambas metodologías tanto Scrum como Mobile-D, la fase inicial es la más importante, en el
caso de Scrum el objetivo de la fase inicial denominada Pregame, es construir el Product-
Backlog.
En el caso de la metodología Mobile-D, en la fase de exploración, se identifica a los usuarios
involucrados en el desarrollo del producto, como también los requerimientos que presentan, las
historias de usuario, las tareas que se realizaran y la planeación del desarrollo del producto.
46
En esta fase, en ambos se aplicara la ingeniería de requerimientos, la cual nos proporcionara el
mecanismo apropiado para entender lo que desea el cliente.
3.2.1. Concepción y Exploración
En esta fase, se realizaron 3 tareas de manera paulatina para la obtención de requisitos, los
mismos se observan de manera resumida en la Tabla 3.1.
Tabla 3.1 Tareas realizadas para la obtención de requisitos.

TAREA DESCRIPCIÓN DE LA TAREA
Entrevistas Se realizaron entrevistas con los usuarios de la plataforma, se

realizó encuestas a ciudadanos, y se mantuvieron entrevistas
Personales
frecuentes con el personal de la UDIT dependiente del GAMLP.
Observación Se observaron las dificultades con las que cuenta la guardia de
movilidad y transporte para poner orden en las calles de la ciudad
de la paz, así mismo la falta de un mecanismo en la cual se puedan
apoyar para gestionar espacios públicos que serán destinados al
servicio de parqueos en la ciudad de La Paz.
Documentación Se documentaron todas la observaciones y se generó un flujo de
procesos que permita la gestión de espacios públicos, mismo que
llegaría a ser una herramienta persuasiva para disminuir el tráfico
vehicular en el centro de la ciudad de La Paz.
3.2.2. Indagación y Elaboración del Product-Backlog
En esta fase definiremos el Product-Backlog, en el cual se especifican todas las tareas y
requerimientos del producto final. Esta información se recopilo a través de entrevistas realizadas
con el personal del GAMLP. En la Tabla 3.2, se describen los requerimientos básicos del
proyecto “Plataforma Tecnológica de Gestión de Espacios Públicos Destinados al Servicio de
Parqueos”, a partir de los mismos se realizara un análisis y se construirá la lista de

47
requerimientos funcionales que viene a ser el Product-Backlog del proyecto así como también
la lista de requerimientos no funcionales.
Tabla 3.2 Requerimientos básicos del proyecto.
Requerimientos
Gestión y configuración de usuarios

Registro de espacios públicos destinados al servicio de parqueos.
Consultas de estado de espacios públicos destinados al servicio de
parqueos, vía aplicación web y aplicación móvil.
Registro de alquiler de espacios públicos vía aplicación móvil.
Registro de emisión de sanciones.
Emisión de reportes para la toma de decisiones.
A partir de la lista básica de requerimientos de la plataforma descrita en la Tabla 3.2, se realizó
el análisis correspondiente y en coordinación con el personal del GAMLP se construyó el
Product-Backlog como se observa en la Tabla 3.3.
Tabla 3.3 Product-Backlog de la plataforma.

DESCRIPCION MODULO PRIORIDAD
ID
R1 Gestión y Autentificación de usuarios Administración BAJA

R2 Configuración de perfiles de usuarios Administración, BAJA
Servicio RestFull
R3 Configuración de billetera móvil Servicio RestFull MEDIA
R4 Administrar registro y configuración de Servicio RestFull ALTA
vehículos
R5 Registro y configuración de Espacios Administración ALTA
públicos
48
R6 Administrar estado de espacios públicos Monitoreo y ALTA

por sectores Control
R7 Reporte de grado de utilización de Reportes, ALTA
espacios públicos por sectores. Servicio RestFull
R8 Administrar disponibilidad de espacios Consultas y ALTA
públicos Alquiler, Servicio
RestFull
R9 Reporte de disponibilidad de espacios Reportes, MEDIA
públicos Servicio RestFull
R10 Administrar pagos por alquiler de Consultas y MEDIA
espacios públicos. Alquiler,
Servicio RestFull
R11 Administrar emisión de sanciones Sanciones, MEDIA
Servicio RestFull
R12 Administrar pago de sanciones Sanciones, MEDIA
Servicio RestFull
R13 Reporte historial de movimientos de los Reportes, BAJA
usuarios Servicio RestFull
R14 Reporte de sanciones, Reporte de cobros y Reportes, MEDIA

sanciones, Reporte de pagos. Servicio RestFull
En el Product-Backlog se describen también los requisitos que requieren la construcción de un
Servicio RestFull, los mismos serán consumidos por la parte de aplicaciones móviles de la
plataforma tanto la aplicación móvil destinada al ciudadano, como también la aplicación
institucional, a partir de los mismos se construyó la lista de requerimientos para ambas
aplicaciones que se divide en tres aplicativos, como se observa en la Tabla 3.4.

49
Tabla 3.4 Lista de requerimientos para las aplicaciones móviles

REQUERIMIENTOS
APLICATIVOS
Servicios RestFull 1. Creación de servicios web para el registro de usuarios,

actividades que realiza el usuario como consultas de
parqueos cercanos a su ubicación, alquiler de espacios
públicos y pago por los mismos, gestión y control del
uso de espacios públicos.
Aplicación Ciudadano 2. Registro de datos y configuración del usuario.
3. Registro de vehículos del usuario.
4. Consultas de espacios públicos con geolocalización.
5. Reserva de alquiler de espacios públicos.
6. Consulta historial de uso de espacios públicos.
7. Consulta de multas y sanciones.
8. Gestión de pago multas y sanciones.
9. Configuración de billetera móvil.
Aplicación Institucional 10. Monitoreo y control de espacios públicos.
11. Registrar Alquiler de espacios públicos.
12. Emisión y control de sanciones.
13. Reporte de vehículos a ser retirados de vía pública.
14. Reporte de vehículos con grampa virtual.
15. Reporte de vehículos a ser remolcados.
En la Tabla 3.5, se puede observar la lista de requerimientos no funcionales.
Tabla 3.5 Tabla de requerimientos no funcionales.

REFERENCIA REQUERIMIENTOS
Aplicativo La plataforma debe contar con una aplicación móvil y dos

aplicaciones móviles, una aplicación destinada al ciudadano y otra
destinada a la institución.
50
Acceso La llave de acceso a la aplicación móvil destinada al ciudadano tiene

una validez para realizar solo una reserva.
Portabilidad La aplicación web es portable en cualquier sistema operativo solo
requiere un navegador web, las aplicaciones móviles estarán
disponibles en el sistema operativo Android, la aplicación
institucional será compatible también con dispositivos POS.
Despliegue La aplicación institucional será desplegada en dispositivos POS,
cada usuario encargado del monitoreo y control de espacios
públicos contara con un dispositivo POS.
Para el despliegue de la aplicación destinada al ciudadano, el
usuario podrá descargar la aplicación de Google Play.
3.2.3. Especificación
En esta fase se define la arquitectura de la plataforma, la cual está basada en la arquitectura
Cliente – Servidor, para el BackEnd se utilizara el sistema de gestión de bases de datos
PostgreSQL, así mismo el aplicativo web será desarrollado basado en el framework de Laravel;
Para la conexión entre el aplicativo web y la base de datos se utilizara el controlador
PDO_PGSQL15; Los aplicativos móviles tanto el aplicativo destinado al ciudadano como el
institucional se comunicaran con la plataforma a través de servicios, los mismos serán
desarrollados utilizando el API Rest del framework de Laravel. Las peticiones para el
despliegue de la aplicación web serán desarrolladas utilizando la técnica de desarrollo web
AJAX16, de esa manera la aplicación se ejecutara del lado del cliente, es decir en sus
navegadores, mientras se mantiene una comunicación asíncrona con el servidor en segundo
plano, como se observa en la Figura 3.1.
15
PDO_PGSQL, es un controlador que implementa la interfaz de Objetos de Datos de PHP.
16
AJAX, acrónimo de Asynchronous JavaScript And XML.
51
Servicio
Rest Cliente
Api Rest
Aplicación
Institucional
www.
Petición
www. Ajax SERVIDOR
INTERNET GAMLP
www.
HttpRequest
Aplicación
Web
Aplicación
BD Parqueos
Laravel
Servicio Rest
Administración
Aplicación
Ciudadano
Figura 3.1 Arquitectura de la Plataforma
Una vez definida la arquitectura de la plataforma, se define a los usuarios que intervendrán
con el desarrollo del producto, como también sus roles.
En el desarrollo de la aplicación web, se optara por el uso de los roles empleados en la
metodología Scrum como se observa en la Tabla 3.6. En el desarrollo de las aplicaciones
móviles se empleara la definición de usuarios según la metodología Mobile-D como se
observa en la Tabla 3.7.

52
Tabla 3.6 Roles y personal involucrados en el desarrollo de la Aplicación web

Personal
Roles
Product Owner Ing. Roberto Zambrana
Ing. Juana Villca Marca
Univ. Luis Miguel Mantilla Condori
Scrum Master Tec. Roberto Morales Morales
Scrum Team Univ. Luis Miguel Mantilla Condori
Lic. Primo Wenceslao Mamani
Lic. Rosmery Mamani
Tabla 3.7 Usuarios involucrados en el desarrollo de las Aplicaciones móviles

Personal
Usuario
Steering Group Ing. Roberto Zambrana
Ing. Juana Villca Marca
Tec. Roberto Morales Morales
Project Team Univ. Luis Miguel Mantilla Condori
Customer Group Tec. Orlando Miguel Huanca Córdova
Exploration Group Univ. Luis Miguel Mantilla Condori
3.2.4. Inicialización
Esta fase será adoptada dentro de la fase Pre-Game para el desarrollo de la plataforma. Esta
fase se considera dentro de la metodología Mobile-D, y es en la que se preparan y verifican

53
los asuntos críticos que involucran el desarrollo de la plataforma como también la
configuración para el proyecto tanto para los aplicativos móviles como para el aplicativo web.
Ya definido el Product-Backlog como también la arquitectura de la plataforma, se procede a la
definir los actores que harán uso de la plataforma, así también se describen los objetivos que
cumplen los mismos como se observa en la Tabla 3.8.
Tabla 3.8 Tabla de actores de la plataforma

Objetivos
Actor
Administrador Gestionar usuarios.

Administrar los espacios públicos destinados al servicio de
parqueos como ser capacidad de los espacios, costos por hora.
Tiene acceso a todos los módulos de la aplicación web.
Generar reportes desde la aplicación web.
Monitorea el estado de los espacios públicos.
Guardia GMT Recibe reporte del estado de espacios públicos.
Emite sanciones por el mal uso de espacios públicos.
Recibe reporte de vehículos a ser retirados de vía pública.
Recibe reporte de vehículos con grampa virtual.
Ciudadano Registro de datos y configuración del usuario.
Registra sus vehículos.
Configuración de billetera móvil.
Consulta ubicación de espacios públicos con geolocalización.
Consulta el estado de espacios públicos.
Realiza pago por alquiler de espacios públicos.
Consulta historial de uso de espacios públicos.
Consulta de multas y sanciones.
Gestiona el de pago multas y sanciones.
54
Con los actores definidos en la Tabla 3.8, se procede a describir de forma general, los casos de
uso de la plataforma como se observa en la Figura 3.2.
Figura 3.2 Casos de uso de la plataforma.
Con los requisitos funcionales de la plataforma como se describe en la Tabla 3.3 y con los
casos de uso descritos en la Figura 3.2, se procede al modelado de la base de datos.

55
Figura 3.3 Modelo Entidad Relación de la Base de Datos
En la Figura 3.3, se puede observar el modelo entidad relación de la base de datos, en donde se
almacenara toda la información. En la Figura 3.4 se pueden observar el diagrama de clases de
la base de datos, contemplando la base de datos en su totalidad incluidas las tablas destinadas
a almacenar los históricos de la tabla “Alquila” y la tabla “Sanciona”, también se contempla
las tablas para la navegación y permisos de los usuarios basado en roles y accesos.
56
Figura 3.4 Diagrama de clases de la Base de Datos

57
Antes de iniciar el desarrollo, se configuraron los ambientes de trabajo de los aplicativos a
desarrollar, en la Tabla 3.9, se puede observar la base de configuración del aplicativo web,
como también las versiones que fueron utilizadas para el desarrollo.
Tabla 3.9 Configuración del aplicativo web

Configuración Versión
Nro.
1 PHP 7.0.15
2 Laravel Framework 5.3.45
3 JSON Web Token 0.5
4 Bootstrap 3.5
5 JQuery 3.1.0
En la Tabla 3.10, se puede observar la configuración de utilizada para el desarrollo de los
aplicativos móviles,
Tabla 3.10 Configuración de los aplicativos móviles

Configuración Versión
Nro.
1 Android Studio 2.3.3
2 compileSdkVersion 24
3 buildToolsVersion 25.0.2
4 minSdkVersion 16
5 targetSdkVersion 24
58
3.3. GAME Y FASE DE PRODUCCIÓN
En esta fase se describe el desarrollo de la aplicación web, donde se describe el desarrollo de
cada uno de los Sprints, Así también paralelamente se describirá el desarrollo de las aplicaciones
móviles en cada una de sus iteraciones para lograr los requerimientos funcionales.
3.3.1. Desarrollo de los Sprints
Para la administración del proceso de desarrollo se utiliza la herramienta de gestión de proyectos

Taiga.
En la Figura 3.5 se detalla el Backlog de historias de usuarios utilizando la herramienta Taiga.
Figura 3.5 Backlog del proyecto en Taiga.

59
El proceso de desarrollo se sujetara a la presentación de 3 Sprints, en la Figura 3.6, se detalla
la planificación de los Sprints utilizando la herramienta Taiga, definiendo las fechas de entrega
sujeta a calendario.
Figura 3.6 Planificación de los Sprints
3.3.1.1. Primer Sprint: Desarrollo de la interfaz de Administración
En este punto se detallara el desarrollo del primer Sprint, siguiendo la metodología Scrum se
realizaran las siguientes 3 tareas: Planeación del Sprint, Desarrollo y Revisión del Sprint.
 Planeación, a partir del primer Sprint, con las historias de usuarios previamente
seleccionadas se realizara la planificación de las tareas a realizar por historia de usuario, en
la Figura 3.7 se observan las historias de usuario seleccionadas y las tareas que componen
terminar cada historia de usuario.

60
Figura 3.7 Planificación del primer Sprint utilizando la herramienta Taiga
 Desarrollo, en la Figura 3.8 se detalla el desarrollo del Primer Sprint exitosamente,
utilizando la herramienta Taiga, podemos observar el cierre del Sprint, donde se destacan
10 tareas cerradas exitosamente dando un total de 104 puntos completados.
Figura 3.8 Desarrollo del primer Sprint

61
 Revisión, Se revisaron las tareas asignadas, en la Figura 3.8 se detalla el proceso de
desarrollo final de este Sprint, como resultado se agregaron las nuevas funcionalidades a
la aplicación web, en la Figura 3.9 y la Figura 3.10, se muestran algunas de las interfaces
con las nuevas funcionalidades presentadas.
Figura 3.9 Página principal del aplicativo web

62
Figura 3.10 Módulo de administración de personas de la aplicación web
3.3.1.2. Segundo Sprint: Desarrollo de la interfaz de monitoreo y control
En este punto se detallara el desarrollo del segundo Sprint, siguiendo la metodología Scrum se
 Planeación, a partir del Segundo Sprint, con las historias de usuarios previamente
seleccionadas se realizara la planificación de las tareas a realizar por historia de usuario,
en la Figura 3.11 se observan las historias de usuario seleccionadas y las tareas que
componen terminar cada historia de usuario.

63
Figura 3.11 Planificación del Segundo Sprint utilizando la herramienta Taiga
 Desarrollo, en la Figura 3.12 se detalla el desarrollo del Segundo Sprint, la interfaz de
monitoreo, utilizando la herramienta Taiga, podemos observar el cierre del Sprint, donde
se destacan 11 tareas cerradas exitosamente dando un total de 235 puntos completados.

64
Figura 3.12 Desarrollo del Segundo Sprint
desarrollo final de este Sprint, como resultado se agregaron las nuevas funcionalidades a la
aplicación web, en la Figura 3.13 y la Figura 3.14, se muestran algunas de las interfaces
con las nuevas funcionalidades presentadas.
En la Figura 3.13, se puede apreciar un listado de los parqueos según su zona de
ubicación, este módulo presenta una actualización constante, indicando y alertando el
estado de los espacios públicos destinados al servicio de parqueos. Este módulo también
cuenta con un fragmento de georeferenciación de los parqueos, para ello se hace uso del
API de Google Maps Web.

65
Figura 3.13 Módulo de monitoreo de parqueos

66
Figura 3.14 Módulo de multas y sanciones
3.3.1.3. Tercer Sprint: Desarrollo de la interfaz de Control, Alquiler y Reportes
En este punto se detallara el desarrollo del Tercer Sprint, siguiendo la metodología Scrum se
 Planeación, a partir del Tercer Sprint, con las historias de usuarios previamente
seleccionadas se realizara la planificación de las tareas a realizar por historia de usuario,
en la Figura 3.15 se observan las historias de usuario seleccionadas y las tareas que
componen terminar cada historia de usuario.

67
Figura 3.15 Planificación del Tercer Sprint utilizando la herramienta Taiga
 Desarrollo, en la Figura 3.16 se detalla el desarrollo del Tercer Sprint, la interfaz de
Control, Alquiler y Reportes, utilizando la herramienta Taiga, podemos observar el cierre
del Sprint, donde se destacan 10 tareas cerradas exitosamente dando un total de 194
puntos completados.
Figura 3.16 Desarrollo del Tercer Sprint
desarrollo final de este Sprint, como resultado se agregaron las nuevas funcionalidades a la
aplicación web, de la Figura 3.17 y la Figura 3.18, se muestran algunas de las interfaces
68
con las nuevas funcionalidades presentadas. En la Figura 3.18 se observa, el reporte de la
demanda de parqueos en diferentes puntos de la ciudad, este reporte ayuda a la toma de
decisiones para la creación de zonas de estacionamiento tarifado con más demanda.
Figura 3.17 Mapa de calor del uso de parqueos
En la Figura 3.18, se observa el módulo de reportes de manera general, la misma cuenta con
dos secciones en la parte lateral izquierda se cuenta con despliegue general del estado de la
plataforma, como son el número de parqueos, la cantidad de vehículos registrados hasta el
momento, la cantidad de alquileres utilizados entre otros, estos reportes pueden ser exportados
en formato Excel.
69
Figura 3.18 Módulo de reportes general
3.3.2. Iteraciones de aplicativos móviles
El resultado de esta fase es desarrollar dos aplicaciones móviles una destinada al ciudadano
denominada iParqueos y la otra institucional denominada iParqueosGMT, en la figura 3.19 se
puede observar la aplicación iParqueos en su fase final.

70
Figura 3.19 Aplicación móvil iParqueos

71
Antes de comenzar con el desarrollo se realizara la planeación de cada iteración, una
característica de la metodología Mobile-D previa a realizar las iteraciones en el desarrollo del
producto es definir las historias de usuario y las tareas respectivas, para este cometido se utilizara
la herramienta Taiga, el detalle de las mismas se puede observar de la Figura 3.20 a la Figura
3.29.
Figura 3.20 Historia de usuario 1

72

73

74
Con las historias de usuario descritas anteriormente de la Figura 3.20 a la Figura 3.29, en la
Figura 3.30 se puede observar el cronograma de entrega de las iteraciones utilizando la
herramienta Taiga, donde se describe las fechas de inicialización y finalización, como también
las tareas que involucra cada iteración.
Figura 3.30 Cronograma de Iteraciones

75
3.3.2.1. Primera Iteración
En la primera iteración se completaron y liberaron la historia de usuario 1 y la historia de usuario
2, como se observa en la Figura 3.31, en primera instancia se crearon los servicios web
complementarios a la plataforma utilizando la API Rest del framework Laravel 5.3.
Figura 3.31 Liberación de la primera iteración con 2 historias de usuario completadas
La estructura de los servicios creados consiste en cuatro capas: La primera es la encargada de
verificar el acceso a la capa de datos basado en la autentificación de un token que es entregado
al usuario cuando este se realiza el logueo en la aplicación iParqueos, la segunda capa es la

76
encargada del acceso a los datos, la tercera capa es la contiene la lógica del negocio y la última
capa es la que contiene los métodos necesarios del servicio. La estructura del servicio para
registro de usuarios, solo cuenta con tres capas, a partir del registro se le pedirá al usuario que
realice el logueo correspondiente y se le brindara un token que le servirá al usuario como llave
de acceso para la primera capa de los servicios al realizar cualquier petición, en la aplicación
móvil. Los tokens que se le provean al usuario tienen cierto tiempo de vida o fenecen una vez
que son utilizados en una petición de tipo reserva.
Con los servicios implementados se procedió al desarrollo de las interfaces, en la Figura 3.32 se
muestra la interfaz de registro y log in en la aplicación móvil iParqueos, y en la Figura 3.33 se
muestra el módulo de registro de vehículos del usuario.
Figura 3.32 Módulo de Loguin y Registro de la aplicación ciudadano

77
En la Figura 3.33, se puede observar ell modulo de registro y configurcion de vehiculos del
usuario, en este modulo solo se requieren datos basicos del vehiculo, como el color, marca,
modelo y placa del vehiculo.
Figura 3.33 Modulo de registro y configuración de vehículos de aplicación ciudadano
3.3.2.2. Segunda Iteración
En la Segunda Iteración, se completaron y liberaron las historias de usuario 3, 4 y 5 numeradas
como 55,58 y 60 respectivamente como se observa en la Figura 3.34. Al no contar con la
configuración de la billetera móvil, al momento de realizar la solicitud de estacionamiento solo
podrá realizar la reserva de dicho espacio y no así el pago por el mismo, para realizar la reserva
el usuario debe encontrarse próximo, cercano o en el lugar a estacionar, caso contrario de ser
necesario el encargado de control y monitoreo tiene la opción de dar de baja dicha reserva, y de
esa manera dar prioridad a los vehículos que se encuentren físicamente en el lugar. Un pre-
78
requisito para la solicitud de reserva de un espacio es tener registrado el vehículo que se desea
estacionar.
Figura 3.34 Liberación de la segunda iteración con 3 historias de usuario completadas
Se inició diseñando la interfaz de búsqueda de aparcamiento, para ello se consumió la API de
Google Maps, como se observa en la Figura 3.35, para la visualización del mapa se utiliza un
79
AsyncTask también denominado hilo, la comunicación se realiza de manera asíncrona, en la
Figura 3.35 se observa el consumo de la API para geo referenciar los espacios públicos
destinados al servicio de parqueos más cercanos a una ubicación.
Figura 3.35 Implementación de Google Maps en Android
En la Figura 3.36, se puede observar el módulo de solicitud y consulta de parqueos.
Figura 3.36 Módulo de reserva de aparcamiento aplicación ciudadano

80
Así mismo en esta iteración se realizó la simulación de pago por alquiler de un espacio
público, donde según el tiempo seleccionado nos permite efectuar el pago por el mismo en la
Figura 3.37 se observa la transacción realizada y la consulta de la misma en el historial del
usuario.
Figura 3.37 Módulo de historial de movimientos aplicación ciudadano
3.3.2.3. Tercera Iteración
En esta tercera iteración se finaliza el desarrollo de la aplicación destinada al ciudadano con el
cierre de la historia de usuario 6 numerada según la herramienta Taiga como 64, Así mismo se
inicia el desarrollo de la Aplicación institucional destinada Agente Supervisor y Cobrador,
para el cometido en esta fase se cierran las historias de usuario 7 y 8 numeradas como 68 y 72
respectivamente como se observa en la Figura 3.38.

81
Figura 3.38 Liberación de la tercera iteración con 3 historias de usuario cerradas
En la Figura 3.39 se observa la interfaz liberada y cerrada en esta iteración para la historia de
usuario 6, donde se detallan las consultas que realiza el usuario para seguir sus sanciones y
82
multas impuestas, en este módulo al consumir el Servicio Rest nos devuelve las sanciones y
multas que tenga el usuario con el siguiente detalle: La fecha de la sanción, la placa del vehículo,
lugar de la sanción, la hora en la que se realizó la sanción y el monto impuesto como multa a la
infracción cometida.
Figura 3.39 Módulo de Multas y sanciones de la aplicación ciudadano
Así mismo, como se indica al inicio de esta iteración, se procede a iniciar el desarrollo de la
aplicación institucional, esta aplicación es en la que se apoyara el encargado de monitoreo y
control, la misma permite tener información con actualización constante del estado de un
parqueos designado, además de registrar e imprimir comprobantes de parqueo y registrar
sanciones dentro de la plataforma; En la Figura 3.40, se puede observar el aplicativo
desarrollado en su última etapa.

83
Figura 3.40 Aplicación Móvil Institucional en su etapa final

84
Figura 3.41 Loguin y Módulo de registro de alquiler de aparcamientos aplicación institucional
En la Figura 3.41, se observa el Loguin de la aplicación institucional basado en la zona de
parqueo de asignación del guardia GMT y el módulo de registro de aparcamientos.
Figura 3.42 Módulo de monitoreo de la aplicación institucional

85
En la Figura 3.42, se observa el módulo de monitoreo destinada a la aplicación móvil
institucional, en la cual se destaca el tiempo de permanencia autorizado de todos los vehículos
en la zona de parqueo asignada, en este módulo se destaca la comunicación en tiempo real,
alertando al guardia el estado de utilización de los parqueos brindándole la opción de reimprimir
el comprobante de estacionamiento, misma funcionalidad que tiene un límite de 2 impresiones;
Para la implementación de la impresión en los dispositivos POS, se utilizó como librería el
proyecto nativo identificado con nombre de paquete “uk.co.senab.photoview” incorporado
dentro del proyecto y la librería mobiprint3 en su versión 0.2; Así mismo se tiene la opción de
extender el tiempo de estacionamiento de un vehículo si el propietario así lo desea, dentro de la
plataforma el tiempo de espera, previa a la sanción automática de un vehículo que ocupa un
espacio de parqueo es de 15 minutos; finalizado ese tiempo la sanción recae en el encargado de
monitoreo. El encargado de monitoreo tiene la opción de dar de liberar a los vehículos si es que
los mismos abandonan su espacio, o realizar la sanción respectiva según la casuística una vez
finalizado el tiempo de aparcamiento de un vehículo para evitar ser sancionado el mismo, esta
última funcionalidad se detalla en la cuarta iteración.
3.3.2.4. Cuarta Iteración
En esta iteración se finaliza el desarrollo de la aplicación móvil institucional con el cierre de las
historias de usuarios identificadas con números 75 y 78 respectivamente según la herramienta
Taiga, como se observa en la Figura 3.43.
El dispositivo POS, para el cual está destinada la aplicación institucional, no es compatible con
Google Play Services17, por ende tampoco es compatible con Google Maps, por lo que se en
17
Google Play Services, es una aplicación del sistema operativo Android, que sirve principalmente para la
autenticación de servicios de Google.
86
este módulo de la aplicación se utiliza OpenStreetMap para permitir la georeferenciación en la
emisión de sanciones.
Figura 3.43 Liberación de la cuarta iteración con dos historias de usuario cerradas
En la Figura 3.44, se observa el módulo de reporte y emisión de sanciones, la funcionalidad de
este módulo es mostrar las últimas 10 sanciones emitidas del día, en el caso de la emisión de
sanciones el encargado de monitoreo y control, es responsable de la emisión de una emisión e
imprimir un comprobante del motivo de la sanción, además de seguir el protocolo ya definido
por la SMM en el caso de remolque de vehículos infractores o recurrentes. Dentro de la
plataforma la veracidad de las sanciones es validad con una fotografía y la georeferenciación
del lugar del hecho, para la captura de la fotografía se hace uso de los recursos nativos del
sistema operativo Android, recurso con el que cuenta el dispositivo POS.

87
Figura 3.44 Módulo de reporte y emisión de sanciones aplicación institucional
3.4. POSTGAME Y FASE DE ESTABILIZACIÓN, PRUEBAS Y REPARACIONES
En esta fase se finaliza el desarrollo de la plataforma, para ello se realizaran las pruebas
necesarias y se dará solución a las mismas, además se asegurara la calidad del producto
desarrollado utilizando pruebas de aceptación del producto.
3.4.1. Pruebas y Reparaciones
Al realizar las pruebas de los aplicativos finales tanto en los aplicativos móviles como el
aplicativo web, se encontraron un total de 7 errores y observaciones, los cuales se describen en
la Tabla 3.11.
Tabla 3.11 Errores encontrados en la plataforma

Aplicativo Descripción
Nro.
1 Web Los mapas tardan mucho en cargar

88
2 Web Para actualizar los datos de monitoreo de los parqueos se tiene

que actualizar toda la página necesariamente
3 Móvil En la aplicación institucional la llamada a los servicios en
ocasiones demora más de 30 segundos.
4 Móvil En la aplicación institucional no se cuenta con un buscador de
vehículos por la matrícula para disminuir el tiempo de
búsqueda visual.
5 Móvil Él envió de imágenes al momento de imponer una sanción
demora hasta 5 minutos.
6 Móvil En la aplicación destinada al ciudadano, al momento de
buscar aparcamiento, si el GPS del dispositivo se encuentra
desactivado, causa que la aplicación se detenga.
7 Móvil En la aplicación destinada al ciudadano, cuando se cierra el
aplicativo dejan de llegar las notificaciones cuando el tiempo
de parqueos esta por expirar.
Luego de analizar los errores encontrados se procedió a realizar las reparaciones respectivas a
cada uno de los errores como se observa en la Tabla 3.12.
Tabla 3.12 Solución de errores encontrados en la plataforma

Nro. Tipo Solución Solución
1 Nueva Se quitó la vista de los mapas en el menú principal, al

Funcionalidad momento de realizar la búsqueda, de esta manera los mapas
solo se cargan una vez que el usuario desee verlos.
2 Desarrollo Se agregó un temporizador, que actualiza únicamente el
FrontEnd componente de listado de vehículos en el módulo de
monitoreo, la actualización se realiza de manera automática
cada 5 minutos.
3 Desarrollo Se agregó un TimeOut de 4 segundos al socket de espera y a
BackEnd la conexión de tipo client, además se agregó un validador para
89
evitar él envió de datos duplicados, como se observa en la

Figura 3.45.
4 Nueva Se agregó un filtro de búsqueda, para optimizar el tiempo de
Funcionalidad búsqueda visual en el módulo de monitoreo y control y en el
módulo de multas y sanciones.
5 Desarrollo Se desarrolló una función de compresión de imágenes, previo
envió de la misma, el cual disminuye el tamaño de la imagen
en un 80%, su tamaño original, como se observa en la Figura
3.46.
6 Desarrollo Se agregó una función de consulta si el GPS, se encuentra
FrontEnd encendido en el dispositivo, si el GPS está desactivado, la
aplicación muestra un dialogo indicando el estado del GPS y
si el usuario desea activarlo, caso contrario se muestran todos
los parqueos.
7 Desarrollo Se desarrolló un Background service, que funcione de manera
local con la base de datos SQLite, esta implementación no
requiere el acceso a internet del dispositivo para recibir
notificaciones.
Figura 3.45 Configuración tiempo de espera de respuesta en los sockets de los servicios
90
En la Figura 3.46, se puede observar la utilización del algoritmo de compresión desarrollado,
esta implementación se la hace en el ActivityOnResult, que es el método nativo donde llegan
los datos devueltos por otros activities, en este caso la cámara.
Figura 3.46 Algoritmo de compresión de imágenes módulo de sanciones
3.4.2. Calidad de Software
Como se describe al inicio de esta fase, el cálculo de dicha calidad se realizara en base a pruebas
de aceptación para ello se creó un cuestionario utilizando El modelo de Aceptación de
Tecnológica denominado TAM por sus siglas en inglés (Abu-Dalbouh, 2013), dicho modelo
como los usuarios están dispuestos o aceptar o rechazar una nueva tecnología, que puede ser
una aplicación móvil, aplicación web, sistema de información u otros.
El cuestionario cuenta con tres segmentos: Utilidad, Facilidad de uso y Actitud hacia el uso. De
acuerdo a estudios realizados por el autor del modelo TAM, la usabilidad es más importante que
la facilidad de uso y la actitud hacia el uso. Las encuestas creadas para este cometido se
encuentran en las siguientes tablas: Tabla 3.14, Tabla 3.15, Tabla 3.16.
91
Para medir el grado de Utilidad, Facilidad de uso y Actitud hacia el uso, en los cuestionarios
mencionados anteriormente, se utilizara una escala de medición, basada en una calificación
que va de 1 a 5, como se observa en la Tabla 3.13.
Tabla 3.13 Escala de medición
Escala de medición
Absolutamente no No En cierta Si cumple Cumple considerablemente
manera
1 2 3 4 5
Tabla 3.14 Encuesta de Utilidad Percibida (UP)

Nro. Pregunta
1 ¿Cumple con mis expectativas?

2 ¿Me parece útil usar una aplicación en mi celular para estacionar mi
vehículo en vía pública?
3 ¿Le parece adecuado el tiempo de demora para estacionar su vehículo
utilizando la aplicación en su celular?
4 ¿Le parece eficiente poder extender el tiempo de permanencia de su
vehículo en un espacio público desde donde se encuentre con la aplicación
móvil?
5 ¿Considera usted importante poder consultar información de todos los
movimientos que haya tenido su vehículo así también las infracciones
impuestas que pueda tener?
6 ¿Le parece útil el uso de la plataforma?
7 ¿Volvería a utilizar la aplicación?
8 ¿Recomendaría el uso de la aplicación a otras personas?

92
Tabla 3.15 Encuesta de Facilidad de Uso Percibida (FUP)

Nro. Pregunta
1 ¿Utilizar la plataforma i-Parqueos sería complicado para mí?

2 ¿Los aplicativos móviles tienden a desplegar muchos mensajes de error?
3 ¿Los aplicativos móviles necesitan un manual para poder ser utilizados de
la manera correcta?
4 Facilidad de recordar características principales y como usarlas
5 Encuentro a la plataforma i-Parqueos fácil de utilizar
Tabla 3.16 Encuesta de Actitud Hacia el Uso

Nro. Pregunta
1 Utilizar la plataforma i-Parqueos (Aplicativo móvil o web) me facilita

buscar estacionamiento en espacios públicos y pagar por el uso de los
mismos.
2 Utilizar la plataforma i-Parqueos (Aplicativo móvil o web) sería
beneficioso en mi municipio.
3 Utilizar la plataforma i-Parqueos (Aplicativo móvil o web) en el municipio
de La Paz sería positivo para generar conciencia ciudadana al momento
estacionar un vehículo en espacios públicos.
Además, para asegurar la calidad del producto desarrollado, todos los aplicativos cuentan con
una integración continua de esa manera se asegura que las mismas sean fáciles de mantener,
para ello se utiliza el software de control de versiones Git18, apoyándonos en el sistema de
gestión código GitLab19, los repositorios de los distintos aplicativos desarrollados se pueden
observar en la Tabla 3.17. Estos repositorios cuentan con dos ramas en todos los casos, la
18
Git, es un software de control de versiones, pensado en la eficiencia y la confiabilidad del mantenimiento de
versiones de versiones de aplicaciones.
19
GitLab, es un servicio web de control de versiones y desarrollo de software colaborativo basado en Git.
93
rama denominada master y otra rama denominada develop, en la rama mater se encuentran
solo las liberaciones estables de los distintos aplicativos; En la rama develop se encuentran
todos los commits20 realizados a lo largo del proceso de desarrollo.
Tabla 3.17 Repositorios de los aplicativos desarrollados

Aplicativo Repositorio
Aplicativo web https://gitlab.com/luis.mantilla/iParqueos_Oficial.git
Aplicativo móvil ciudadano https://gitlab.com/luis.mantilla/iParqueos_Oficial.git
Aplicativo móvil intitucional https://gitlab.com/luis.mantilla/iParqueos-Ciudadano.git
3.5. PRUEBAS Y RESULTADOS
Para realizar las pruebas de funcionalidad de la plataforma, se evaluaron los distintos casos de
uso planteados al inicio del desarrollo. Estas pruebas se las realizo la zona Miraflores Bajo,
definida como zona de prueba piloto por la Secretaria Municipal de Movilidad, del GAMLP
como se observa en la Figura 3.47, para ello se invitó a 15 personas que aceptaron probar el
producto desarrollado de manera voluntaria, para ello se facilitó a los voluntarios de 4
dispositivos móviles, que tenían la aplicación destinada al ciudadano instalada.
20
En el contexto de la ciencia de la computación y la gestión de datos, commit se refiere a la idea de consignar
un conjunto de cambios tentativos de forma permanente.
94
Figura 3.47 Zona definida para la prueba piloto

Fuente (Secretaria Municipal de Movilidad, 2017)
3.5.1. Funcionalidad de la Plataforma
Para la realización de las pruebas se utilizaron 3 tipos de dispositivos móviles y una
computadora portátil, las características de los mismos se describen en la Tabla 3.18.
Tabla 3.18 Características de dispositivos móviles de prueba
Dispositivo Versión de Android Resolución Tipo de Red GPS
Samsung Galaxy J7 6.0.1 1080 x 1920 4G LTE SI

pixels
Prime
Sony Xperia S LT26i 4.1.2 720 x 1280 3G SI

pixels
95
MoviWire Multiprint 4.2.2 480 x 540 3G-2G SI
Smartphone con
impresora térmica
En la Tabla 3.19 se detalla la prueba realizada para el agente GMT, encargado de monitoreo y
control, en la prueba se siguió el flujo definido en los casos de uso.
Tabla 3.19 Prueba para el rol del Agente GMT

Condiciones de la Prueba  Número de usuarios: 5
 Tipo de Conexión de datos: 3G
 Número de dispositivos POS: 5
 Fecha: 23-06-2017
 Horario: 15:00 - 18:00
 Lugar: Unidad de Desarrollo e
Innovación Tecnológica, Ex – Banco
del Estado, Calle Mercado, La Paz.
Procedimiento de la Prueba
 El encargado de monitoreo ingresa a la aplicación con sus credenciales de uso
asignadas.
96
 El encargado de monitoreo y control verifica el estado del parqueo en el que se
encuentra y registra un el aparcamiento de un vehículo, para ello introduce los datos
básicos del vehiculó que son la placa, la ciudad a la que pertenece el tipo de vehículo
y el color del vehículo.

97
 El encargado de monitoreo, consulta al ciudadano cuento el tiempo que desea aparcar
su vehículo y le indica el costo total por el tiempo requerido.

98
 Una vez realizado el cobro por el uso del estacionamiento en vía pública, el encargado
de monitoreo y control registra la solicitud de aparcamiento y el pago por la misma.
Una vez realizado el registro el encargado de monitoreo y control imprime un
comprobante de la transacción y se la entrega al ciudadano.
 El encargado de monitoreo y control, recibe la actualización de la lista de
aparcamientos después de haber, realizado el registro.

99
 Los datos se actualizan constantemente en centro de control, y se evidencia el estado
del aparcamiento que cuenta con el nuevo registro.
Conclusión de la prueba
Luego de finalizar la prueba se concluyó lo siguiente.
 La funcionalidad probada de la plataforma, se encuentra funcionando de manera
correcta para el rol del Agente GMT.
 Se identificaron caídas de red dado que los dispositivos POS solo cuentan con una
conexión 3G.
 El tiempo de registro de un vehículo lleva en promedio 37 segundos, lo que es bastante
rápido y ayuda al encargado de monitoreo y control de manera significativa a realizar
sus funciones.
En la Tabla 3.20, se puede observar a detalle las pruebas realizadas para el rol del ciudadano,
en donde el usuario puede registrarse desde el aplicativo, iniciar sesión, configurar sus
vehículos y por ende reservar un espacio de parqueo.
Tabla 3.20 Prueba para el rol del Ciudadano

Condiciones de la Prueba  Número de usuarios: 10
 Tipo de Conexión de datos: 4G
 Número de dispositivos: 2
 Fecha: 28-06-2017
 Horario: 12:00 - 15:00
 Lugar: Zona Miraflores Bajo, Av.
Argentina.
100
Procedimiento de la Prueba
 El ciudadano ingresa a la aplicación, al no contar con un usuario y contraseña procede
a registrarse en la plataforma.
 Una vez de que el usuario finaliza su registro, procede a ingresar sus credenciales de
registro, el servicio de logueo verifica las credenciales de acceso y le genera un JWT
al usuario, con el cual realizara las peticiones al servidor. Si las credenciales son
válidas el usuario ingresara al menú principal del aplicativo móvil.

101
 Luego de que el ciudadano se autentica en la aplicación, la aplicación le indica al
usuario que necesariamente de registrar y configurar su vehículo, esta configuración
es muy sencilla y solo requiere datos principales de los vehículos.

102
 Una vez que el ciudadano ha configurado su vehículo, se encuentra habilitado para
aparcar su vehículo en cualquier estacionamiento disponible. Para ello el ciudadano
debe dirigirse al módulo de solicitud de parqueos, en el cual tiene información geo
referenciada, de los 5 parqueos más cercanos a su ubicación, además del estado y
capacidad de los mismos.
 Después de que el ciudadano elige un lugar de aparcamiento, la aplicación le pedirá
que se seleccione el tiempo que desea estacionar su vehículo.

103
 Después de que el ciudadano elige el tiempo requerido de permanencia y confirma
que está de acuerdo con las restricciones de uso, procede a realizar la reserva
seleccionando el vehículo que desea aparcar.

104
Se puede tener más de un vehículo registrado por ciudadano, además se la aplicación permite
visualizar el detalle de confirmación del tiempo seleccionado como también el monto a pagar.
 Un a ves registrado e tiempo estacionamiento del vehículo, el usuario puede consultar
el estado de movimiento de sus vehículos.
 La solicitud de estacionamiento también se puede visualizar, desde la aplicación
institucional, mostrando el detalle de la reserva en su totalidad.

105
 Este registro también se puede evidenciar en el centro de monitoreo y control.

106
Conclusión de la Prueba
Luego de finalizar la prueba para el rol del ciudadano se concluyó lo siguiente.
 La funcionalidad probada de la plataforma, se encuentra funcionando de manera
correcta para el rol del Ciudadano.
 Se identificaron pocas caídas de red debido a la ubicación de la zona destinada a la
realización de las pruebas.
 El tiempo de solicitud de parqueo, teniendo el vehículo previamente configurado le
lleva al ciudadano en promedio 55 segundos.

107
3.5.2. Resultados y Aceptación de la Plataforma
Basados en los cuestionarios descritos en el punto 3.4.2, se obtuvieron los siguientes
resultados: En la Figura 3.48, se puede observar basados en la escala medición descrita en la
Tabla 3.13, que un 78% de los encuestados piensan que la plataforma es de gran utilidad, por
tanto cumple con la expectativa de la ciudadanía.
Utilidad Percibida (UP)

Absolutamente no No En cierta manera Si cumple Cumple Considerablemente
0% 2%
9%
11%
78%
Figura 3.48 Resultado encuesta de Utilidad Percibida (UP)
En la Figura 3.49, se puede Observar que el grado de Facilidad de Utilidad Percibida, tiene un
total de 81 %, eso indica que la ciudadanía considera que es muy fácil interaccionar con la
plataforma a través de los aplicativos móviles, se concluye que dichos aplicativos cuentan con
interfaces amigables y fáciles entender.

108
Facilidad de Uso Percibida (FUP)

2% 4%
6%
7%
81%
Figura 3.49 Resultado encuesta de Facilidad de Uso Percibida (FUP)
En la Figura 3.50, se observa que el 71%, de la ciudadanía presento una actitud bastante buena
hacia el uso de la plataforma, en las pruebas realizadas se percibió que una minoría de la
ciudadanía se resiste adoptar nuevas tecnologías.
Actitud hacia el Uso

3%
10% 7%
9%
71%
Figura 3.50 Resultado encuesta de Actitud hacia el uso

109
CAPITULO IV
CONCLUSIONES Y RECOMENDACIONES
La adopción de la plataforma le permite al ciudadano, tener información geo referenciada de los
espacios públicos destinados al servicio de parqueos, a través de dispositivos móviles con
sistema operativo Android, lo cual le permite acceder a este servicio de una manera muy rápida
y sencilla, por tanto se concluye que con la implementación de la plataforma, se brinda un mejor
servicio a la ciudadanía.
El uso de la plataforma le facilita al encargado de monitoreo y control desempeñar sus funciones
de manera rápida y eficiente.
La adopción de la plataforma incrementa el tiempo de utilización de los espacios públicos
destinados al servicio de parqueos, ya que en la extensión de tiempo de aparcamiento no existen
tiempos muertos, además de contar con un tiempo de espera de 15 minutos para la liberación
del vehículo una vez finalizado el tiempo de aparcamiento del mismo, previa sanción
automática.
110
Las interfaces desarrolladas en los distintos aplicativos, fueron catalogadas como amigables por
parte de la ciudadanía, lo cual promueve su uso y genera interés en la misma.
Según las pruebas realizadas, las encuestas de la utilidad percibida y la facilidad de uso
percibida, arrojaron resultados bastante favorables, un 78% de la ciudadanía encuestada piensa
que la plataforma es bastante útil y necesaria y un 81%, piensa que utilizar la plataforma a través
de los aplicativos móviles es considerablemente fácil.
4.1. RECOMENDACIONES
 Dadas las características de la plataforma, se recomienda migrar los servicios de tipo
RestFul, utilizando el lenguaje para queries GraphQL, de esta manera se podría optimizar
el módulo de monitoreo en la aplicación institucional.
 Se recomienda incrementar el alcance de la aplicación destinada al ciudadano, adoptando
el desarrollo para otros sistemas operativos, como ser iOS y Windows Phone.
 Se recomienda incorporar el servicio de billetera móvil en la aplicación destinada al
ciudadano, para que la ciudadanía pueda realizar sus pagos tanto de multas y sanciones
como por el uso de un espacio público destinado al servicio de parqueos.
 Se recomienda incorporar el presente proyecto en la plataforma iGob24/721, ya que con su
adopción se amplía el abanico de funcionalidades y servicios que ofrece el Gobierno
Autónomo Municipal de La Paz a través de su plataforma iGob24/7.
 Se recomienda que después de la estabilización y uso de la plataforma a través de la
aplicación móvil destinada al ciudadano, se adopte nuevas tecnologías basadas en IOT,
21
iGob24/7, acrónimo de Gobierno Electrónico Innovador, es una plataforma tecnológica que brinda a la comuna
una variedad de servicios y trámites en línea con la finalidad de mejorar la calidad de vida de la ciudadanía,
consolidar una gestión eficiente y romper las barreras geográficas.
111
sustituyendo gradualmente al personal encargado de monitoreo y control por una red de
sensores y cámaras de vigilancia.
 Al ser una plataforma emergente se recomienda incentivar el uso de la misma en la
ciudadanía a través de campañas de concientización, e incentivo de descuentos por el uso
de la misma.
 Se recomienda analizar la base de datos semestralmente, para generar nuevas soluciones
en la gestión de espacios públicos destinados al servicio de parqueos y apoyarse en los
reportes que ofrece la plataforma para la toma de decisiones dentro de la institución.

112
REFERENCIA BIBLIOGRÁFICA
Abu-Dalbouh, H. M. (2013). A questionnaire approach based on the technology acceptance
model for mobile tracking on patient progress applications. Journal of Computer
Science, 9(6), 763-770.
Agetic (2016). Agencia de Gobierno Electrónico Tecnologías de la Información y
Comunicación: Plan de Software Libre y Estándares Abiertos, recuperado de
http://www.agetic.gob.bo/index.php/plan-de-software-libre
Agilestorelocator (2017). Google Maps vs OpenStreetMap recuperado de:
https://agilestorelocator.com/blog/google-maps-vs-open-street-maps-comparison/
Apple Developer Program (2016). Recuperado el 07 de noviembre de 2016, de
https://developer.apple.com/programs/
Arana, R. (2015). Diseño de un prototipo de aplicación móvil (ANDROID) “PARQUIL” para
la administración y localización de parqueaderos públicos ubicados en las parroquias
Rocafuerte y Pedro Carbo-Concepción de la ciudad de Guayaquil (Proyecto de grado).
Universidad de Guayaquil, Guayaquil, Ecuador.
Báez, M., Borrego, Á., Cordero, J., Cruz, L., González, M., Hernández, F., ... & Torralbo, P.
(2012). Introducción a Android. EME Madrid, España, 121.
Borja, J., & Muxí, Z. (2001). Centros y espacios públicos como oportunidades. Revista Perfiles
Latinoamericanos, 9(19), 115-130.

113
Bouskela, M., Casseb, M., Bassi, S., De Luca, C., & Facchina, M. (2016). La ruta hacia las
smart cities: Migrando de una gestión tradicional a la ciudad inteligente.
Concejal Silva propone Ley Municipal de parqueos (01 de marzo de 2016).Concejo Municipal.
Recuperado de
http://www.concejomunicipal.bo/concejo/index.php/component/content/article.html?id
=308:concejal-silva-propone-ley-municipal-de-parqueos
Developer Console (2016). Recuperado el 07 de noviembre de 2016, de
https://support.google.com/googleplay/android-developer/answer/6112435?hl=es
El Diario 1. Parque automotor es fuente de mayor contaminación en La Paz (26 de Junio de
2016). El Diario. Recuperado de
http://www.eldiario.net/noticias/2016/2016_06/nt160626/nacional.php?n=41&-parque-
automotor-es-fuente-de-mayor-contaminacion-en-la-paz
El Diario 2.Tránsito: presencia esporádica (28 de Agosto de 2016).El Diario. Recuperado de
http://www.eldiario.net/noticias/2016/2016_08/nt160828/editorial.php?n=26&-
transito-presencia-esporadica
El Diario 3. Alcaldía y parqueo para automotores (15 de Agosto de 2016). El Diario. Recuperado
de http://www.eldiario.net/noticias/2016/2016_08/nt160815/editorial.php?n=29
Enriquez, J. G., & Casas, S. I. (2014). Usabilidad en aplicaciones móviles. Informes Científicos-
Técnicos UNPA, 5(2), 25-47.

114
Flores, A. (2015). Implementación de un prototipo para la gestión de sistemas de parqueo
utilizando una red de sensores inalámbricos (Proyecto de grado). Pontificia Universidad
Católica del Ecuador, Quito, Ecuador.
Gallego, M. T. (2012). Metodología Scrum. Gestión de Proyectos Informáticos, Recuperado de:
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612mem
oria.pdf
Gómez, A., & Lopez, M., & Migani, S., & Otazú, A. (2010). COCOMO, Un Modelo de
Estimación de Proyectos de Software, recuperado de
https://blogadmi1.files.wordpress.com/2010/11/cocom0llfull.pdf
Guale, N. (2015). Diseño e implementación de un sistema que permita la integración de varios
establecimientos de parqueo para vehículos livianos del centro de Guayaquil, verificar
la disponibilidad de parqueos en línea y administración de reservas, para dispositivos
móviles con plataforma android (Proyecto de grado). Universidad de Guayaquil,
Guayaquil, Ecuador.
La Prensa. Guardias ediles podrán colocar cepos a los vehículos infractores (04 de abril de
2013). La Prensa. Recuperado de http://www.laprensa.com.bo/diario/actualidad/la-
paz/20130404/guardias-ediles-podran-colocar-cepos-a-los-
vehiculos_45570_73299.html
La Razón 1. Dueños de las calles (30 de junio de 2016). La Razón. Recuperado de
http://www.la-razon.com/opinion/editorial/Duenos-calles_0_2518548128.html
115
Mamani, D. (2016). Sistema web de seguimiento y control de supervisores y obras basado en la
geolocalización en dispositivos móviles caso: agencia estatal de vivienda (Proyecto de
grado).Universidad Mayor de San Andrés, La Paz, Bolivia.
Manual de organización y funciones (Gobierno Autónomo Municipal De La Paz, Gestión 2016).
Recuperado de la plataforma Mercurio del Gobierno Autónomo Municipal De La Paz.
McCool, S. (2012). Laravel Starter. Packt Publishing Ltd.
Página siete 1. Alcaldía de La Paz remolcará con grúas a vehículos estacionados en vías no
autorizadas (21 de julio de 2016). Página siete. Recuperado de
http://www.paginasiete.bo/sociedad/2016/7/21/alcaldia-remolcara-gruas-vehiculos-
estacionados-vias-autorizadas-103580.html
Página Siete 2.Grúas ediles cosechan apoyo y protestas en sus operativos (31 de julio de 2016)
Página Siete. Recuperado de http://www.paginasiete.bo/sociedad/2016/7/31/gruas-
ediles-cosechan-apoyo-protestas-operativos-104589.html
Pesi (2016). Plataforma tecnológica de seguridad industrial Recuperado de http://www.pesi-
seguridadindustrial.org/index.php?option=com_content&view=article&id=62&Itemid
=45&lang=es
Pizarro, D. (2016). Desarrollo de una aplicación móvil para la gestión de espacios en un
parqueadero de un centro comercial (Proyecto de grado). Universidad Técnica de
Machala, Machala, El Oro.
Pressman, R. S., & Troya, J. M. (1988). Ingeniería del software (No. 001.64 P74s.). McGraw
Hill.
116
Reglamento del Código del Tránsito, (Capítulo VIII De los estacionamientos, paradas y
detenciones) (8 de junio de 1978).
Romero, Y. F., & González, Y. D. (2012). Patrón modelo-vista-controlador. Revista Telem@
tica. Vol, 11(1), 47-57.
Rosado, D. G., Blanco, C., Sánchez, L. E., Fernández-Medina, E., & Piattini Velthuis, M. (2010,
July). La Seguridad como una asignatura indispensable para un Ingeniero del Software.
In XVI Jornadas de Enseñanza Universitaria de la Informática (pp. 205-212).
Universidade de Santiago de Compostela. Escola Técnica Superior d'Enxeñaría.
Santamaría, C. (2016). Diseño e implementación de un prototipo (Proyecto de grado). Escuela
Politécnica nacional, Quito, Ecuador.
Sierra, F., Acosta, J., Ariza, J., & Salas, M. Estudio y análisis de los framework en php basados
en el modelo vista controlador para el desarrollo de software orientado a la web.
Obtenido de http://publicaciones. unisimonbolivar. edu. co/rdigital/inovacioning/index.
ph p/identic/article/viewFile/73/91.
Similartech (2017), Google Maps vs OpenStreetMap, recuperado de
https://www.similartech.com/compare/google-maps-vs-openstreetmap
Sommerville, I., & Galipienso, M. I. A. (2005). Ingeniería del software. Pearson Educación.
Techopedia 1(2017) Lugar de publicación: www.techopedia.com. Dirección de donde se extrajo
el documento https://www.techopedia.com/definition/3411/platform
117
Techopedia 2(2017) Lugar de publicación: www.techopedia.com. Dirección de donde se extrajo
el documento https://www.techopedia.com/definition/147/platform-as-a-service-paas
Villa, M. Tránsito identifica 15 puntos que necesitan señalización en La Paz (20 de marzo de
2016) El Diario. Recuperado de http://www.la-razon.com/ciudades/Problema-Transito-
identifica-necesitan-senalizacion-La_Paz_0_2456754393.html
Villa, Micaela. En La Paz las prohibiciones se ignoran y se parquea donde sea (02 de diciembre
de 2013).La Razón. Recuperado de http://www.la-
razon.com/index.php?_url=/ciudades/Paz-prohibiciones-ignoran-
parquea_0_1734426626.html
Wikipedia 1 (2016). Aplicación Web, Recuperado de
https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web
Wikipedia 2 (2016). Aplicación Móvil, Recuperado de
https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_m%C3%B3vil
Wikipedia 3 (2016). Google Maps, Recuperado de
https://es.wikipedia.org/wiki/Google_Maps#Caracter.C3.ADsticas
Wikipedia 4 (2016). OpenStreetMap, Recuperado de
https://es.wikipedia.org/wiki/OpenStreetMap#Caracter.C3.ADsticas_actuales_y_desaf.
C3.ADos_futuros_del_proyecto
Contar con un módulo de Información Construir un Informacion Avalar la emision
ANEXO A
control de espacios confiable en tiempo módulo de confiable, de sanciones con

públicos en la aplicación real de ubicación y el
móvil para coadyuvar a estado de espacios
sanciones disponible y en recursos
reducir la congestión públicos destinados virtuales, que tiempo real que visuales,ubicación
vehicular. al servicio de permita descartar optimize recursos e informacion del
parqueos. recursos humanos. momento exacto
ARBOL DE OBJETIVOS
materiales.
INFORMACION EN TIEMPO REAL ACERCA DE LA

UBICACIÓN, ESTADO Y CAPACIDAD DE ESPACIOS
PÚBLICOS DESTINADOS AL SERVICIO DE PARQUEOS PARA
REALIZAR EL PROCESO DE CONSULTAS, CONTROL Y
ANEXOS
SEGUIMIENTO DE LOS MISMOS, PARA BRINDAR UN MEJOR

SERVICIO A LA CIUDADANIA.
Plataforma tecnólogica
que coadyuve a la Tecnologia basada en Emplear la politica
gestion y viabilidad de georreferenciación y Tecnologia móvil y web. empresarial BYOD.
uso de espacios públicos geolocalizacion.
destinados al servicio de
parqueos.
118
CONGEST EMISION CUIDADORES DE MALA CULTURA MOLESTI
ANEXO B
ION DE VEHICULOS CIUDADANA AL A

VEHICUL DIOXIDO APROPIANDOSE DE MOMENTO DE CIUDAD
AR DE ESPACIOS APARCAR UN ANA.
ÁRBOL DE PROBLEMAS
ACUMULACIÓ DESCONOCIMIE LIMITACIÓN DE CARENCIA DE ERRORES

N EXCESIVA NTO DE LA RR MATERIALES RRHH POR PARTE HUMANOS AL
DE VEHICULOS EXISTENCIA DE PARA IMPONER DE LAS MOMENTO DE LA
SOBRE ZONAS DE SANCIONES A AUTORIDADES EMISION DE
AVENIDAS PARQUEO POR VEHICULOS PARA REALIZAR SANCIONES POR
PRINCIPALES PARTE DE LOS INFRACTORES. EL CONTROL DE PARTE DE LAS
CIUDADANOS. VEHICULOS AUTORIDADES.
INFRACTORES.
GESTIÓN DE ESPACIOS PÚBLICOS

DESTINADOS AL SERVICIO DE
PARQUEOS
INCREMENTO DEL PARQUE POCOS

FALTA DE CONOCIMIENTO
AUTOMOTOR EN LA CIUDAD ESTACIONAMIENTOS DE
DE NORMAS DE TRANSITO
DE LA PAZ PARQUEO
119
120
ANEXO C – MATRIZ DE MARCO LÓGICO
Objetivos Resumen Narrativo Indicadores Medios De Supuestos

Objetivamente Verificación
Verificables
Fin La plataforma Se notara la eficiencia y El medio de Habrá una campaña
contribuirá a que la la velocidad para verificación serán los de concientización y
ciudadanía cuente con acceder al servicio en el reportes de grado de familiarización con la
un servicio de grado de utilización que utilización de los plataforma por parte
parqueos rápido, tenga el mismo. distintos espacios del GAMLP con la
eficiente y confiable. públicos destinados al ciudadanía.
servicio de parqueos y
el importe económico
que brinde el mismo.
Propósito Brindar Información Brindar a la ciudadanía Registrar y notificar Todos los usuarios y
en tiempo real acerca y a los encargados de en tiempo real el encargados de
de la ubicación, monitoreo de los estado de los espacios monitoreo tendrán
estado y capacidad de espacios públicos una públicos destinados al acceso a internet.
espacios públicos herramienta para servicio de parqueos.
destinados al servicio realizar el proceso de
de parqueos para consultas, control y
realizar el proceso de seguimiento de los
consultas, control y espacios públicos
seguimiento de los destinados al servicio
mismos. de parqueos.
Productos Se cuenta con una Se utilizaran 6 zonas de Cada zona de parqueo Los riesgos que se
plataforma que parqueos definidos por tendrá a un encargado podrían presentar son:
permite mediante dos la Secretaria Municipal de monitoreo que se -Que por motivos de
aplicaciones móviles de Movilidad para apoyara en la red un usuario no
una destinada al determinar el grado de aplicación móvil llegue a realizar la
ciudadano y otra utilización que tenga la institucional, para reserva por el uso de
institucional, realizar plataforma y por ende el notificar el correcto y un espacio público.
el proceso de servicio. el mal uso de los -Que por motivos de
consultas, alquiler, espacios públicos. red el encargado de
control y seguimiento monitoreo no reciba la
de los espacios notificación por el uso
públicos destinados al de un espacio público.
servicio de parqueos. -Que por motivos de
red el usuario no
pueda solicitar el uso
de un espacio público.
Activida- -Desarrollar un Los módulos El GAMLP cuenta Los posibles riesgos
des módulo de control de desarrollados se con las licencias que se prevén son:
espacios públicos en encuentran dentro de necesarias para la -Qua la aplicación sea
la aplicación móvil dos aplicaciones, una publicación en ambas retirada de la tienda
para coadyuvar a destinada al ciudadano tiendas de App Store por no
reducir la congestión y otra institucional aplicaciones tanto renovar la licencia
vehicular. destinada a los Google Play como anual de 99$.
-Desarrollar un encargados de App Store, en la
módulo de consultas monitoreo. implementación del
que brinde -El costo de publicación presente proyecto
información confiable de ambas aplicaciones solo se necesita hacer
acerca de la ubicación en Google Play es 25 $. la publicación en
y el estado de espacios Google Play.
121
públicos destinados al
servicio de parqueos.
-Construir un módulo
de gestión sanciones
virtuales, que permita
descartar el uso de
recursos materiales.
-Implementar un
servicio en línea que
brinde información
confiable, disponible
para optimizar el uso
de recursos humanos.
-Implementar un
módulo de emisión y
control de sanciones
basado en
georeferenciación,
captura de imágenes e
información para
acrecentar la emisión
de sanciones.
-Realizar pruebas de
calidad de software en
la aplicación móvil y
en la aplicación web.
122
ANEXO D
PORTABILIDAD DEL PRODUCTO DESARROLLADO
Para el cálculo de dicha portabilidad, se utilizara el estándar internacional de normas ISO/EC
9126 para la calidad de software. La portabilidad es la capacidad que tiene el software para ser
trasladado de un entorno a otro, la usabilidad se divide en 5 criterios, los cuales son
adaptabilidad, facilidad de instalación, coexistencia, reemplazabilidad y conformidad de
portabilidad.
Se realizó la valoración de cada sub-atributo, basado en una escala de valores como se observa
en la siguiente Tabla de escala de valores.
Tabla de Escala de Valores

Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Valorando la portabilidad de la plataforma se tienen las siguientes apreciaciones, como se
observa en la Tabla de valoración de la portabilidad.
Tabla de Valoración de la portabilidad

Factor de Ajuste Valor
Adaptabilidad 4
Facilidad de instalación 5
123
Coexistencia 3
Reemplazabilidad 4
En base a la valoración obtenida, se puede cuantificar la portabilidad de la plataforma.
4 + 5 + 3 + 4 100
Portabilidad = ∗ = 80%
4 5
124
ANEXO E
ANÁLISIS COSTO-BENEFICIO
Una de las tareas de mucha importancia en la planificación de proyectos de software es la
estimación, con ello se pretende determinar con cierto grado de certeza, los recursos, costos,
tiempos y esfuerzos necesarios para el desarrollo de dichos proyectos de software.
Para ello utilizaremos el modelo COCOMO II22, a su vez COCOMO II tiene 3 modelos
denominados, composición de aplicación, diseño temprano y post arquitectura.
Para determinar el costo de desarrollo dentro del modelo COCOMO II, es necesario seguir
ciertas métricas de estimación de software, en este proyecto se utilizara la técnica de Puntos
Objeto.
1. Calculo del costo de desarrollo de software
Según COCOMO II, se tiene lo siguiente:
𝐶𝐷 = 𝐶𝑃 ∗ 𝑃𝑟 ∗ 𝑇𝐷𝐸𝑉
Donde:
CP: Costo estimado por programador, que para este proyecto utilizaremos el valor de 2800 Bs.
Pr: Numero de Programadores para el desarrollo, que para este cálculo utilizaremos 1 persona.
TDEV: Tiempo de desarrollo.
Entonces sí:
Pr = E / TDEV
𝑻𝑫𝑬𝑽 = [3.0 ∗ 𝐸 0.33+0.2∗(B−1.01) ] ∗ (𝑆𝐶𝐸𝐷%⁄100)
Donde:
22
COCOMO, por su acrónimo del inglés COnstructive COst MOdel, El modelo constructivo de costos, es un
modelo matemático de base empírica utilizado para estimación de costos de software.
125
E: Es el esfuerzo expresado en meses personas, calculado sin tener en cuenta el multiplicador
de esfuerzo SCED
SCED %: porcentaje de expansión del cronograma (alargamiento de calendario).
B: Factor de escala
B = 0.91+ 0.01 * Wi
Wi: Sumatoria de los pesos de los factores de escala de COCOMO II, estos valores se pueden
apreciar en la siguiente Figura.
Figura Valores de Factores de Escala

Fuente (Boehm, 1995)
Donde:
PREC: Precedencia.
FLEX: Flexibilidad de Desarrollo.
RESL: Resolución de Arquitectura/Riesgos.
TEAM: Cohesión de equipo.
PMAT: Madurez de proceso.
Para el presente proyecto se tomara los valores de cada factor y alargamiento de calendario
nominal de escala nominal.
Para el cálculo de programadores y el tiempo de desarrollo es necesario determinar el esfuerzo.

126
Para calcular el esfuerzo (E) y la duración (TDEV) usaremos las ecuaciones básicas del modelo
de COCOMO, como se observa la siguiente formula.
𝐸 = 𝑁𝑂𝑃⁄𝑃𝑅𝑂𝐷
Dónde:
NOP: Nuevos Puntos Objeto.
PROD: Ratio de Productividad.
(100 − %𝑅𝑒𝑢𝑠𝑒)
𝑵𝑶𝑷 = 𝑃𝑂 ∗
100
PO: Estimar el número de pantallas, informes y componentes de las que consta esta aplicación.
Para realizar el conteo de los puntos Objeto, seguiremos la siguiente secuencia de pasos:
a) Hacer el recuento de Objetos: Estimar el número de pantallas, informes y componentes
de las que consta esta aplicación.
b) Clasificar cada instancia de objeto dentro de 3 niveles de complejidad (simple, media,
difícil) según valor de las dimensiones de la característica, para ello se utilizara el siguiente
esquema de clasificación de objetos:
Figura Referencia de Composición de aplicaciones

c) Pesar el número de cada celda, reflejando el esfuerzo relativo requerido para implementar
una instancia de ese nivel de complejidad como se observa en la siguiente Figura.

127
Figura Nivel de Complejidad (Pesos)

d) Determinar Puntos Objeto: Suma todas las instancias de objeto pesadas para conseguir un
número. El recuento de Puntos Objeto.
e) Estimar el porcentaje de reutilización que se espera lograr en este proyecto. Calcular los
nuevos Puntos Objeto a desarrollar.
f) Determinar un ratio de productividad, como se observa en la siguiente Figura.
Figura Ratio de Productividad

Aplicando los pasos anteriormente descritos se tiene lo siguiente:
i. Basado el Product-Backlog de la plataforma, descrita en la Tabla 3.3 y en la Lista de
Requerimientos de los aplicativos móviles descritos en la Tabla 3, se logró hacer el recuento
de objetos como se observa en la siguiente Tabla.

128
Tabla de Recuento de Objetos de la Plataforma
Aplicativo Pantallas Informes Componentes

3GL
Aplicativo Web 15 4 2
Aplicativo Móvil Ciudadano 11 1 1
Aplicativo Móvil Institucional 6 2 1
Total 32 7 4
ii. En la siguiente Tabla se detalla la calificación de los objetos contados en el paso anterior
según su complejidad.
Tabla de Recuento de Objetos de la Plataforma
Tipo de Objeto Pesos asociados a los niveles de complejidad
Simple Medio Difícil
Pantallas 18 6 8
Informes 2 2 3
Componentes 3GL 2 1 1
iii. Con los objetos clasificados, se procede a realizar la suma de los pesos.
 𝑃𝑎𝑛𝑡𝑎𝑙𝑙𝑎𝑠 = (18 ∗ 1) + (6 ∗ 2) + (8 ∗ 3) = 54
 𝐼𝑛𝑓𝑜𝑟𝑚𝑒𝑠 = (2 ∗ 2) + (2 ∗ 5) + (3 ∗ 8)= 38
 𝐶𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡𝑒𝑠 3𝐺𝐿 = (2 ∗ 0) + (1 ∗ 0) + (1 ∗ 10) = 10
iv. Con los pesos obtenidos, se procede a determinar los Puntos Objeto, que sería igual a la
sumatoria de todos los pesos obtenidos en el punto anterior.
𝑃𝑂 = 102
129
v. En este punto se realizara la estimación del porcentaje de reutilización y los Nuevos Puntos
Objeto denominados NOP.
Si: %𝑅𝑒𝑢𝑠𝑒 = 80%
(100−%𝑅𝑒𝑢𝑠𝑒)
Entonces: 𝑵𝑶𝑷 = 𝑃𝑂 ∗ =24
100
vi. En este punto determinaremos el radio de productividad, según la valores de Ratio de
Productividad, se elige el siguiente valor.
𝑃𝑅𝑂𝐷 = 25 (𝐴𝐿𝑇𝐴)
vii. Con el Ratio de Productividad seleccionado, se procede a calcular el valor Mes-Persona.
Si:
𝐸 = 𝑁𝑂𝑃⁄𝑃𝑅𝑂𝐷
Reemplazando los valores obtenidos en el punto anterior, se tiene que:
𝐸 = 24⁄25 = 0.96
Por tanto Realizando el redondeo correspondiente se tiene que:
𝐸 = 1 𝑚𝑒𝑠 − 𝑝𝑒𝑟𝑠𝑜𝑛𝑎
viii. Calculo del tiempo de desarrollo:
𝑻𝑫𝑬𝑽 = [3.0 ∗ 𝐸 0.33+0.2∗(B−1.01) ] ∗ (𝑆𝐶𝐸𝐷%⁄100)
Donde:
B=0.91+ 0.01*Wi
Para todos los valores de escala el valor nominal, entonces se tiene lo siguiente:
PREC=1.24 FLEX=3.72 RESL=5.65 TEAM=2.19 PMAT=1.56
Wi = 14.36
B = 0.91 + 0.01 * 14,36

130
B = 1.05
Continuando, según los siguientes niveles de medida detallados en la siguiente Figura, se
elegirá el valor Nominal.
Figura Niveles de Medida TIME

Entonces:
SCED=100%
Por tanto:
𝑻𝑫𝑬𝑽 = [3.0 ∗ 𝐸 0.33+0.2∗(B−1.01) ] ∗ (𝑆𝐶𝐸𝐷%⁄100)
𝑻𝑫𝑬𝑽 = [3.0 ∗ 10.33+0.2∗(1.05−1.01) ] ∗ (100⁄100)
𝑻𝑫𝑬𝑽 = 3 ∗ (1)
𝑻𝑫𝑬𝑽 = 3 𝑚𝑒𝑠𝑒𝑠 (91 𝑑𝑖𝑎𝑠)
Por lo tanto se tiene que, el tiempo de desarrollo de software será aproximadamente de 91 días.
ix. Con el tiempo de desarrollo encontrado en el anterior punto, se procede a declarar el número
de programadores requeridos para el desarrollo de este proyecto:
𝑃𝑟 = 1
x. Con todos los datos se hallaron se procede a determinar el costo de desarrollo de la
plataforma, según el modelo COCOMO II.
Se tiene que:
𝐶𝐷 = 𝐶𝑃 ∗ 𝑃𝑟 ∗ 𝑇𝐷𝐸𝑉
Reemplazando los valores adecuadamente se tiene que:

131
𝐶𝐷 = 2800 [𝐵𝑠⁄𝑃𝑒𝑟𝑠𝑜𝑛𝑎] ∗ 1[𝑃𝑒𝑟𝑠𝑜𝑛𝑎⁄𝑀𝑒𝑠(𝑒𝑠)] ∗ 3[𝑀𝑒𝑠(𝑒𝑠)]
𝐶𝐷 = 8400 [𝐵𝑠]
Por tanto se concluye que el costo aproximado de desarrollo de la plataforma según el modelo
COCOMO II es de 8400 Bs.

Gestión de parqueos públicos con plataforma tecnológica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestión de parqueos públicos con plataforma tecnológica

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

PLATAFORMA TECNOLÓGICA DE GESTIÓN DE ESPACIOS

PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA

POSTULANTE: LUIS MIGUEL MANTILLA CONDORI

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

este punto, haberme dado salud y

por iluminar mi mente en cada paso

A mis padres Genaro y Julia.

lo que soy, en toda mi educación

tanto académica, como de la vida y

sobre todo por su incondicional

apoyo perfectamente mantenido a

través del tiempo.

Todo este trabajo ha sido posible

orientación, esfuerzo, dedicación, paciencia y su excepcional asesoría han sido fundamentales

para la elaboración del presente proyecto de grado.

Al M.Sc. Franz Cuevas Quiroz, por la paciencia y el tiempo brindado; A través de su

colaboración, persistencia, conocimiento y motivación me ha brindado una excelente tutoría en

la elaboración del presente proyecto de grado.

de Desarrollo e Innovación Tecnológica del Gobierno Autónomo Municipal de La Paz y darme

la oportunidad de innovar desarrollando el presente proyecto.

de la Unidad de Desarrollo e Innovación Tecnológica.

estacionamientos en las mismas, son la fuente principal de grandes congestionamientos

vehiculares, más aun es el caso de la ciudad de La Paz-Bolivia, cuya estructura de angostas

avenidas dificulta el tránsito de vehículos en varias de sus vías.

destinados al servicio de parqueos, basándose en el Plan de Movilidad Urbana Sostenible y el

Autónomo Municipal de La Paz.

La plataforma consiste de una aplicación web desarrollada utilizando el framework Laravel y

implementación de la plataforma, se brinda un mejor servicio a la ciudadanía.

Palabras Clave: Plataforma Tecnológica, Aplicación móvil, parqueos

transit of vehicles in several of its tracks.

Secretary of Mobility of the Municipal Autonomous Government of La Paz.

and thermal printer in devices POS, in a very simple way.

better service is provided to the citizens.

Key Words: Technology Platform, Mobile application, parking

1.1. ANTECEDENTES ............................................................................................................. 3

1.1.1. ANTECEDENTES INSTITUCIONALES ............................................................ 3

1.1.2. ANTECEDENTES DE PROYECTOS SIMILARES ........................................... 4

1.2. PLANTEAMIENTO DEL PROBLEMA .......................................................................... 6

1.2.1. PROBLEMA CENTRAL .................................................................................... 10

1.3. DEFINICIÓN DE OBJETIVOS ...................................................................................... 11

1.3.1. OBJETIVO GENERAL ...................................................................................... 11

1.3.2. OBJETIVOS ESPECÍFICOS .............................................................................. 11

1.4. JUSTIFICACIÓN ............................................................................................................ 11

1.5. ALCANCES Y LÍMITES ................................................................................................ 14

1.5.1. ALCANCES ........................................................................................................ 14

1.5.2. LÍMITES ............................................................................................................. 15

MARCO TEÓRICO ................................................................................................................ 16

2.1. CIUDADES INTELIGENTES Y GESTIÓN DE ESPACIOS PÚBLICOS .................... 17

2.1.1. Centros y Espacios Públicos Como Oportunidades ............................................ 18

2.1.2. Servicio de Parqueos a la Ciudadanía.................................................................. 19

2.1.3. Plataforma Tecnológica y Plataforma como Servicio ......................................... 20

2.2. INGENIERÍA WEB ......................................................................................................... 22

2.2.1. Metodología Scrum ............................................................................................. 22

2.2.2. Framework Laravel 5.4........................................................................................ 29

2.3.1. Metodología Ágil Para Desarrollo De Software Móvil ....................................... 30

2.3.2. Mobile – D y Ciclo de Vida Mobile – D ............................................................. 31

2.3.3. JSON Web Tokens y Algoritmo SHA-256 ......................................................... 35