Vasquez Leon Aplicacion Distribuida para El Reporte de Huecos Viales Basado en Coordenadas de Posicionamiento Global

APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES BASADA EN
COORDENADAS DE POSICIONAMIENTO GLOBAL (GPS).
JOHN HENRY VASQUEZ LEON

ANA MARIA CRUZ CARABUENA
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLÓGICA
INGENIERIA EN TELEMATICA
BOGOTÁ D.C.
2017
APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES BASADA EN
COORDENADAS DE POSICIONAMIENTO GLOBAL (GPS).
JOHN HENRY VASQUEZ LEON

Código: 20152678113
ANA MARIA CRUZ CARABUENA
Código: 20152678115
Monografía presentada como requisito para optar al título de

Ingeniero Telemático
Tutor:
SONIA ALEXANDRA PINZON NUÑEZ

Maestra en Ciencias de la Información y las Telecomunicaciones
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLÓGICA
INGENIERIA EN TELEMATICA
BOGOTÁ D.C.
2017
Nota de aceptación
_______________________________
_______________________________
_______________________________
_____________________________
Firma de Tutor
_____________________________
Firma del Jurado
Bogotá D.C. octubre 20 de 2017
3
AGRADECIMIENTOS
A todas las personas que participaron e hicieron posible este proyecto. Muchas
gracias por su apoyo, conocimientos y enseñanzas, a la maestra Sonia Alexandra
Pinzón Núñez.
Agradecemos a los estudiantes de ingeniería telemática Daniel Cruz y Camilo

Andrés Díaz, quienes con su experiencia, conocimientos y orientación nos ayudaron
a alcanzar los objetivos propuestos.
4
DEDICATORIAS
Dedico este proyecto a Dios, a los que me apoyaron en algún momento y lo siguen haciendo
desde la distancia, a mis padres quienes son testigos de mis triunfos y mis derrotas, por ultimo
una dedicación especial a estas esas personas que creyeron en mí y me dieron la oportunidad
de hacer lo que verán más adelante.
John Henry Vásquez León.
Dedico este proyecto a Dios, a mis amigos que han estado a mi lado, me han ayudado y
alentado a lo largo de esta carrera y por ultimo a mi familia por el apoyo que siempre me han
dado.
Ana María Cruz Carabuena
5
TABLA DE CONTENIDO
Pág.
Lista de tablas ...................................................................................................................... 10

RESUMEN ........................................................................................................................... 12
ABSTRACT .......................................................................................................................... 13
INTRODUCCION ................................................................................................................. 14
1. FASE DE PLANEACION, DEFINICION Y ORGANIZACIÓN ........................................ 15
1.1. TITULO ................................................................................................................... 15
1.2. TEMA ...................................................................................................................... 15
1.3. PLANTEAMIENTO DEL PROBLEMA ..................................................................... 15
1.3.1. Descripción .......................................................................................................... 15
1.3.2. Formulación del problema ................................................................................... 16
1.4. OBJETIVOS ............................................................................................................ 16
1.4.1. Objetivo general ................................................................................................... 16
1.4.2. Objetivos Específicos........................................................................................... 16
1.5. JUSTIFICACION ..................................................................................................... 17
1.6. ALCANCES ............................................................................................................. 17
1.7. DELIMITACIONES .................................................................................................. 18
1.7.1. Delimitación Legal................................................................................................ 18
1.7.2. Delimitaciones Sociales ....................................................................................... 19
1.7.3. Delimitación Técnica ............................................................................................ 19
1.7.4. Delimitación Conceptual ...................................................................................... 19
1.7.5. Delimitación Geográfica ....................................................................................... 20
1.7.6. Delimitación Temporal del Proyecto .................................................................... 20
1.8. MARCO DE REFERENCIA ..................................................................................... 20
1.8.1. Marco Histórico .................................................................................................... 20
1.8.2. Marco Teórico ...................................................................................................... 21
1.8.3. Marco metodológico............................................................................................. 25
1.8.3.1. Fases del RUP ................................................................................................. 26
1.9. FACTIBILIDAD ........................................................................................................ 29
1.9.1. Factibilidad Técnica ............................................................................................. 29
1.9.2. Factibilidad Operativa .......................................................................................... 30
1.9.3. Factibilidad Económica ........................................................................................ 31
6
1.9.3.1. Recursos Físicos .............................................................................................. 31
1.9.3.2. Recursos de Software ...................................................................................... 32
1.9.3.3. Recursos de Humanos ..................................................................................... 34
1.9.3.4. Presupuesto ..................................................................................................... 35
1.9.4. Factibilidad Legal ................................................................................................. 35
2. FASE DE MODELAMIENTO DEL NEGOCIO ............................................................... 37
2.1. IDENTIFICACIÓN Y DEFINICIÓN DE LOS MÓDULOS DEL SISTEMA ................ 37
2.2. DIAGRAMAS DE PROCESOS ............................................................................... 38
2.3.1 Modelo de procesos módulo de registro y acceso ............................................... 39
2.3.2 Modelo de procesos módulo de huecos ............................................................... 41
2.3.3 Modelo de procesos módulo de administración de roles. ..................................... 46
2.3.4 Modelo de procesos módulo de reportes. ............................................................ 47
2.3. MODELO DEL DOMINO ......................................................................................... 49
2.4. GLOSARIO DE TÉRMINOS.................................................................................... 50
3. FASE DE REQUERIMIENTOS ..................................................................................... 52
3.1 IDENTIFICACION DE LA INFORMACIÓN ................................................................. 52
3.1.1 Encuesta .............................................................................................................. 52
3.2 REQUERIMIENTOS FUNCIONALES ......................................................................... 53
3.2.1 Requerimiento de módulo de administración de registro y acceso ...................... 53
3.2.2 Requerimiento de módulo de administración de usuarios .................................... 54
3.2.3 Requerimiento de módulo de administración de huecos ...................................... 54
3.2.4 Requerimiento de módulo de reportes ................................................................. 57
3.1. REQUERIMIENTOS NO FUNCIONALES ............................................................... 57
3.2. DEFINICIÓN DE ACTORES ................................................................................... 59
3.3. LISTA PRELIMINAR DE CASOS DE USO ............................................................. 59
3.3.1. DIAGRAMAS CASOS DE USO ........................................................................... 60
3.3.1.1. Diagrama general de casos de uso .................................................................. 61
3.3.1.2. Diagrama de caso de uso usuario móvil ........................................................... 62
3.3.1.3. Diagrama de caso de uso usuario web............................................................. 62
3.3.1.4. Diagrama de caso de uso usuario administrador web ...................................... 63
3.3.2. DOCUMENTACIÓN CASOS DE USO................................................................. 63
3.3.2.1 Ficha de caso de uso consultar hueco ............................................................. 64
4. FASE DE ANÁLISIS...................................................................................................... 65
4.1. DIAGRAMAS DE SECUENCIA ............................................................................... 65
7
4.2. DIAGRAMAS DE COLABORACIÓN ....................................................................... 66
4.3. DIAGRAMAS DE ACTIVIDAD................................................................................. 67
4.4. DIAGRAMAS DE ANÁLISIS.................................................................................... 68
5. FASE DE DISEÑO ........................................................................................................ 69
5.1. LISTA DE CLASES ................................................................................................. 69
5.1.1. Lista de clases aplicación web ............................................................................. 69
5.1.1.1. Lista de clases aplicación móvil ........................................................................ 70
5.1.2. Responsabilidad de clases .................................................................................. 71
5.1.2.1. Responsabilidad de clases aplicación web....................................................... 71
5.1.3. Modelo de interfaz ............................................................................................... 74
5.1.3.1 Modelo de Interfaz Modulo de registro y acceso ............................................... 74
1.1.3.2 Modelo de Interfaz módulo de huecos .......................................................... 75
5.1.3.3 Modelo de Interfaz módulo de usuarios ............................................................ 78
5.1.3.4 Modelo de Interfaz módulo de reportes ............................................................. 79
5.1.4. Mapa de navegación............................................................................................ 80
5.1.4.1. Mapa de navegación aplicación web ................................................................ 80
5.1.5. Modelo de clases ................................................................................................. 83
5.1.5.1. Modelo de clases aplicación web ..................................................................... 83
5.1.5.2. Modelo de clases aplicación móvil ................................................................... 84
5.1.6. Modelo relacional ................................................................................................. 85
5.1.7. DICCIONARIO DE DATOS .................................................................................. 86
6. FASE DE IMPLEMENTACIÓN...................................................................................... 89
6.1. DIAGRAMA DEL SISTEMA .................................................................................... 90
6.2. DIAGRAMA DE COMPONENTES .......................................................................... 92
6.3. DIAGRAMA DE PAQUETES................................................................................... 93
6.4. DIAGRAMA DE DESPLIEGUE ............................................................................... 94
7. FASE DE PRUEBAS..................................................................................................... 95
7.1 PRUEBAS DE SISTEMA DE INTERACCIÓN ............................................................ 95
RECOMENDACIONES ...................................................................................................... 100
CONCLUSIONES ............................................................................................................... 101
BIBLIOGRAFIA .................................................................................................................. 102
REFERENCIAS .................................................................................................................. 104
INFOGRAFIA ..................................................................................................................... 105
ANEXOS ............................................................................................................................ 106
8
LISTA DE ILUSTRACIONES
Ilustración 1. fases RUP ....................................................................................................... 26

Ilustración 2. Cronograma de actividades ............................................................................ 26
Ilustración 3. Diagrama de proceso iniciar sesión ................................................................ 39
Ilustración 4. Diagrama de proceso registrar usuario ........................................................... 40
Ilustración 5. Diagrama de proceso registrar hueco ............................................................. 41
Ilustración 6. Diagrama de proceso consultar hueco ............................................................ 42
Ilustración 7. Diagrama de proceso editar hueco ................................................................. 43
Ilustración 8. Diagrama de proceso eliminar hueco .............................................................. 44
Ilustración 9. Diagrama de proceso ver mapa ...................................................................... 45
Ilustración 10. Diagrama de proceso modificar rol ............................................................... 46
Ilustración 11. Diagrama de proceso generar reporte de huecos por usuario ...................... 47
Ilustración 12. Diagrama de proceso generar reporte de huecos general ............................ 48
Ilustración 13. Modelo del dominio huecapp ........................................................................ 49
Ilustración 14 diagrama general de casos de uso ................................................................ 61
Ilustración 15 diagrama de caso de uso usuario móvil ......................................................... 62
Ilustración 16 diagrama de caso de uso usuario web ........................................................... 62
Ilustración 17 diagrama de caso de uso usuario administrador web .................................... 63
Ilustración 18. Diagrama de secuencia inicio de sesión ....................................................... 69
Ilustración 19. Diagrama de colaboración inicio de sesión móvil .......................................... 70
Ilustración 20. Diagrama de actividad iniciar sesión ........................................................... 411
Ilustración 21. Diagrama de análisis ..................................................................................... 72
Ilustración 22. interfaz módulo de inicio de sesión móvil ...................................................... 77
Ilustración 23. interfaz módulo de registro de usuario móvil ................................................. 78
Ilustración 24. interfaz módulo de consultar un hueco móvil ................................................ 78
Ilustración 27. interfaz módulo de eliminar un hueco ........................................................... 80
Ilustración 28. interfaz módulo de editar un hueco ............................................................... 80
Ilustración 29 interfaz módulo de notificar un hueco ............................................................ 81
Ilustración 30 interfaz módulo de consultar un usuario ........................................................ 81
Ilustración 31 interfaz módulo de editar un usuario .............................................................. 82
Ilustración 32 interfaz módulo de reportes historial por hueco ............................................. 82
Ilustración 33. Modelo de interfaz General ........................................................................... 83
Ilustración 34. Modelo de interfaz usuario administrador ..................................................... 84
Ilustración 35. Modelo de interfaz usuario ............................................................................ 85
Ilustración 36. diagrama de clases aplicación web ............................................................... 86
Ilustración 37. diagrama de clases aplicación móvil ............................................................. 87
Ilustración 38 modelo entidad relación ................................................................................. 88
Ilustración 39 Diagrama del sistema .................................................................................... 88
Ilustración 40 diagrama de componentes ............................................................................. 91
Ilustración 41 diagrama de paquetes ................................................................................... 92
Ilustración 42 diagrama de despliegue ................................................................................. 93
9
LISTA DE TABLAS
Tabla 1 Actividades metodología para el RUP ..................................................................... 27

Tabla 2 Personal requerido para el proyecto........................................................................ 30
Tabla 3 Recursos físicos en el desarrollo de la aplicación ................................................. 311
Tabla 4 Recursos de software en el desarrollo de la aplicación ......................................... 312
Tabla 5 Recursos de software en la implementación de la aplicación por un año ............. 313
Tabla 6 Recursos humanos en el desarrollo de la aplicación............................................. 324
Tabla 7 Recurso humano por un año de implementación .................................................. 324
Tabla 8 Presupuesto del desarrollo de la aplicación .......................................................... 345
Tabla 9 Presupuesto de la implementación de la aplicación por un año ............................ 355
Tabla 10 Descripción de los módulos de la aplicación ....................................................... 377
Tabla 11 Descripción de los procesos por módulos ........................................................... 388
Tabla 12 Glosario de términos ............................................................................................. 50
Tabla 13 Requerimiento RF1 del módulo de administración de registro y acceso ............. 533
Tabla 14 Requerimiento RF2 del módulo de administración de registro y acceso ............. 533
Tabla 15 Requerimiento RF3 del módulo de administración de usuarios .......................... 544
Tabla 16 Requerimiento RF004 del módulo de administración de usuarios ...................... 544
Tabla 17 Requerimiento RF005 de módulo de administración de huecos ......................... 544
Tabla 18 Requerimiento RF006 de módulo de administración de huecos ........................ 555
Tabla 23 Requerimiento RF012 de módulo de reportes ..................................................... 577
Tabla 24 Requerimiento no funcional RF01 seguridad ...................................................... 577
Tabla 25 Requerimiento no funcional RF02 seguridad de logueo ...................................... 588
Tabla 26 Requerimiento no funcional RF03 limitacion de acceso ..................................... 588
Tabla 27 Requerimiento no funcional RF04 nevegadores ................................................. 588
Tabla 28 Requerimiento no funcional RF05 versiones de android ..................................... 588
Tabla 29 Requerimiento no funcional RF06 error de la informacion .................................. 588
Tabla 30 Lista de actores ................................................................................................... 599
Tabla 31 Ficha de caso de uso consultar hueco ................................................................ 643
Tabla 32 lista de clases de la capa modelo de la aplicación web ....................................... 699
Tabla 33 Lista de clases de la capa controlador de la aplicación web ............................... 699
Tabla 34 Lista de clases de la capa servicios de la aplicación web ..................................... 70
Tabla 35 Lista de clases de la capa modelo de la aplicación móvil ...................................... 70
Tabla 36 Lista de clases de la capa controlador de la aplicación móvil ............................... 70
Tabla 37 Lista de responsabilidad de clases aplicación web capa modelo .......................... 71
Tabla 38 Lista de responsabilidad de clases aplicación web capa controlador .................. 733
Tabla 39 Lista de responsabilidad de clases aplicación web capa servicios ..................... 733
Tabla 40 estado usuario ....................................................................................................... 86
Tabla 38 Tipo hueco ............................................................................................................. 86
Tabla 39 Tipo identificación .................................................................................................. 86
Tabla 40 Hueco .................................................................................................................. 876
Tabla 41 Usuario ................................................................................................................ 876
10
Tabla 42 Historial hueco ..................................................................................................... 886
Tabla 43 Prueba módulo de registro y acceso ..................................................................... 95
Tabla 44 Prueba módulo de huecos ..................................................................................... 96
Tabla 45 Prueba módulo de huecos móvil ........................................................................... 97
Tabla 46 Prueba módulo de reportes ................................................................................. 988
Tabla 47 Prueba módulo de algoritmo acercamiento ......................................................... 988
11
RESUMEN
El desarrollo de una aplicación distribuida para el reporte de huecos viales basado

en coordenadas de posicionamiento global, permitirá a los usuarios poder notificar y
ver en los diferentes huecos (baches) que otros usuarios han reportado con
anterioridad también podrán acceder a esta información en tiempo real, y desde
cualquier lugar, dándoles a los usuarios la oportunidad de interactuar con el sistema
permitiendo de manera preventiva evitar accidentes de tránsito o desperfectos
mecánicos.
HUECAPP maneja tecnologías de punta, desarrollado sobre el Framework MVC de

.NET que utiliza el patrón de arquitectura, que garantiza calidad en el desarrollo del
sistema en su componente web, haciéndolo robusto, flexible y amigable para el
usuario final. El servidor componente móvil maneja las tecnologías de Java Android
nativo, al utilizar tecnologías nativas se tiene la ventaja de ser un desarrollo escalable
y ágil haciendo que la aplicación cuente con una integración más compatible con
otras versiones de Android. El servidor de aplicaciones IIS garantiza niveles de
seguridad y facilidad en la administración de los recursos, optimizando el desarrollo
de aplicaciones web separando la lógica, nuestra base de datos, la presentación de
la aplicación web y flexibilidad con la interacción de nuevas aplicaciones.
Los modelos de sistema se desarrollaron con la herramienta Enterprise Architec 10.

HUECAPP, está desarrollado en un conjunto de lenguajes de programación, y es
compatible con sqlserver, que es el motor base de datos utilizada para nuestro
proyecto. Se utiliza la metodología RUP (Rational Unified Process), por ser la
metodología acorde a nuestras necesidades, permitiendo alcanzar en los tiempos
requeridos y las metas propuestas.
12
ABSTRACT
The development of a distributed application for the reporting of road gaps based on global
positioning coordinates, allows users to notify and see the different gaps (holes) that other
users have previously reported can also access this information in real time, and from
anywhere, giving users the opportunity to interact with the system to prevent traffic accidents
or mechanical damage.
HUECAPP handles state-of-the-art technologies, developed on the .NET MVC Framework

that uses the architecture standard, which guarantees quality in the development of the
system in its web component, making it robust, flexible and user-friendly for the end user. The
Windows Mobile server adapts to Android applications with Android and other applications
compatible with Android. The IIS application server guarantees levels of security and ease in
the administration of resources, optimizing the development of web applications by separating
the logic, our database, the presentation of the web application and the flexibility with new
applications.
The system models were developed with the Enterprise Architec 10 tool.
HUECAPP, is developed in a set of programming languages, and is compatible with sqlserver,
which is the database engine used for our project. The RUP (Rational Unified Process)
methodology is used, why the time, goals and goals required are used.
13
INTRODUCCION
El escaso nivel de infraestructura con el que se cuenta en la ciudad de Bogotá a nivel

de carreteras hace que a diario sus habitantes se vean expuestos a situaciones
peligrosas en accidentes de tránsito o tener que ir a su mecánico de confianza a
reparar partes de sus automotores que cayeron en estos baches.
Según una encuesta de la organización “Bogotá como vamos” un 54% de los

bogotanos considera que la mejor alternativa para mejorar la movilidad en la ciudad
es arreglar las vías, también 65% que afirma demorarse más en sus trayectos y sólo
un 13% de personas satisfechas con las vías de Bogotá. Según datos del IDU para
comienzos del año 2015 se contaba con un 40% de la malla vial está en buen estado,
y el 40% en malo; el 20% restante, en regular. Este panorama no parece mejorar
hasta la fecha teniendo en cuenta que la malla vial tiende a deteriorarse con el paso
del tiempo.
El propósito general de este proyecto es elaborar un prototipo de una aplicación

distribuida con el fin de reportar huecos viales basado en coordenadas gps y
establecer controles del manejo de su información para los usuarios y también
ayudar a las autoridades que están es su competencia el mantenimiento de la malla
vial dentro del barrio San Francisco de la localidad 19 de Ciudad Bolívar.
Para la realización del proyecto se ejecutó un profundo levantamiento de información

que permitió identificar las principales características y necesidades del proceso para
la experiencia de usuario fuera única y amigable con sus clientes finales, además de
desde la parte telemática y de sistematización de datos dar solución a los
inconvenientes previamente mencionados
En el presente documento se describe un problema, tomándolo como punto de

partida para el análisis, desarrollo e implementación del proyecto. Para tal efecto se
aplicó la metodología RUP para documentar y desarrollar las fases del proyecto;
entre esas se encuentra la fase de análisis donde se plantea y se define la solución
más óptima para el reporte de huecos viales, y a partir de estas se empieza una
construcción de varios softwares en la fase de diseño, en la que se construyen los
modelos del lenguaje de modelado visual UML, y se termina con la etapa de
implementación y pruebas.
El presente documento muestra el desarrollo de las aplicaciones distribuidas, que

ayuda al mejoramiento de los procesos previamente descritos, mediante un conjunto
de módulos, un portal web, web api y aplicación móvil logrando así una mejora en la
movilidad y un registro de cuantos huecos tiene el barrio san francisco en ciudad
bolívar.
14
1. FASE DE PLANEACION, DEFINICION Y ORGANIZACIÓN
1.1. TITULO
Aplicación distribuida para reportar huecos viales basada en coordenadas de

posicionamiento global (GPS).
1.2. TEMA
Para el desarrollo del proyecto se debe tener en cuenta el tema de aplicación

distribuida orientado a aplicaciones móviles, para el reporte y detección de huecos
viales. Implementando herramientas de programación como C#, y como gestor de
bases de datos SQLSERVER.
1.3. PLANTEAMIENTO DEL PROBLEMA
1.3.1. Descripción
El primer factor que causa problemas en la movilidad de la ciudad es la falta

construcción de nuevas calles, sumado a esta problemática esta que las calles ya
existentes varias de ellas se realizaron sin estudios de planeación o de suelos y no
están preparadas para soportar la carga de trabajo para el que fueron construidas
dentro de su tiempo de vida útil, como por ejemplo una vía que está diseñada para
10 años y se daña a los 2 años de construida, lo cual nos lleva a la conclusión de que
son unas vías que necesitan una remodelación continua.
Los problemas con el estado de las carreteras que se construyen también involucra
al parque automotor de la ciudad, como ejemplo se puede ver automóviles de tráfico
pesado circulando de manera constante y masiva por vías en las que solo pueden ir
vehículos medianos y pequeños, con el tiempo estos vehículos pesados fracturan la
capa asfáltica provocando que los huecos existentes aumenten su tamaño.
El otro factor se centra en el poco mantenimiento de las vías que trae como
consecuencia la formación de huecos y cráteres que son potencialmente peligrosos
para los automotores (Carros, motocicletas) causantes de accidentes de tránsito que
cobran la vida de cientos de personas al año, un total de 31.050 accidentes de
15
tránsito, dejando 13.921 lesionados y 172 fallecidos, de estas cifras el 20% se deben
a problemas de infraestructura solo en el año 2015.
Los trabajos de mantenimiento que realizan las empresas de servicios públicos tales
como el agua, el gas o la telefonía obligan a romper las calles en buen estado
mientras se realizan las labores de mantenimiento estas empresas se encargan de
la logística y desvíos para no afectar el tráfico, pero después al momento de dejar la
calle en las condiciones óptimas, no utilizan los materiales óptimos y en la mayoría
de los casos no pavimentan los huecos causados por sus trabajos.
Las estadísticas emitidas por el IDU en el año 2015 donde en solo la malla vial
principal hay un total de 9.305 huecos sin diferenciar su categoría, de los cuales 2.829
son huecos de categoría 1 (huecos inferiores a 0.5 m).
Además, el aumento de huecos en la ciudad lleva a que los automotores sufran daños
en su estructura mecánica causando que las personas se queden varadas en las
calles a la espera de ayuda, ya que en ocasiones estos daños impiden que los
automóviles puedan seguir su marcha. Como consecuencia de esto los tiempos de
movilidad en la ciudad aumentan.
1.3.2. Formulación del problema
¿Cómo reportar los huecos de la malla vial por medio de una aplicación distribuida
basada en coordenadas de posicionamiento global?
1.4. OBJETIVOS
1.4.1. Objetivo general
Desarrollar una aplicación distribuida para reportar huecos viales basada en

coordenadas de posicionamiento global (GPS) en un entorno Android y web.
1.4.2. Objetivos Específicos
 Diseñar y desarrollar un módulo de gestión que permita crear, modificar y consultar

los usuarios registrados, además de garantizar su acceso a la aplicación de forma
segura.
 Diseñar y desarrollar un módulo de gestión que por medio de un mapa unido al GPS
en la aplicación móvil me permita reportar, modificar y eliminar huecos.
 Diseñar y desarrollar un módulo de reportes para la aplicación web que se encargue

de mostrar las estadísticas de los huecos reportados por los usuarios.
16
1.5. JUSTIFICACION
Las calles de Bogotá han tenido por mucho tiempo la problemática de los huecos en
su malla vial, lo que provoca que los automotores que transitan por esta se dañen o
tengan algún tipo de accidente, además que por culpa de estos huecos el conductor
y/o pasajeros pierden tiempo en sus trayectos.
Actualmente en el mercado hay aplicaciones similares que abordan la problemática

descrita pero no son óptimas ya que en el caso de WAZE un bache o hueco cierra
la calle y toma un desvió, como consecuencia este desvió puede alargar el tiempo
de viaje, por otro lado esta aplicación cuenta con un marcador de ruta el cual no me
permite ver los baches que no estén en la ruta y en caso tal de tomar un desvió o
entrar a una calle con un bache no me va a avisar de la ubicación precisa del mismo
y también el cerramiento dura pocas horas.
Por otra parte, la aplicación HUECOSMED no permite ver los huecos que otros
usuarios han registrado, tampoco es confiable ya que permite denunciar un hueco
en cualquier parte, sin ninguna restricción, tampoco cuenta con un manejo de perfiles
ni de autenticación perdiendo fiabilidad acercad e quien realizo la denuncia del hueco
y no permitiendo la interacción de datos entre los usuarios.
La aplicación permitirá prevenir que ocurra accidentes en la vía, esto debido a que
al enviar una notificación de alerta cuando se esté cerca de un hueco el usuario
tendrá la opción de esquivar el hueco o escoger otra opción de vía.
Cabe resaltar que la aplicación se alimenta de la información que los usuarios

ingresan respecto a los huecos y por este motivo al aumentar el número de baches
la aplicación visualizará información actualizada y precisa, por los motivos
anteriormente mencionados el sistema prevendrá y reducirá los índices de
accidentalidad por causa de los huecos en la ciudad de Bogotá.
1.6. ALCANCES
Para tener un reporte, una estadística más realista ya que el número de huecos en la
ciudad es una cifra inestable será desarrollada una aplicación distribuida como
prototipo la cual será implementada en el barrio San Francisco de la localidad 19 en
Ciudad Bolívar, la cual brindara servicios desde una base de datos a una aplicación
web diseñada para trabajar en un navegador y una en una aplicación para el sistema
operativo Android (api nivel 23).esta aplicación no se encuentra soportada por
ninguna entidad pública ni privada, es un prototipo lanzado por iniciativa propia de los
integrantes que participan en este trabajo de grado y realizado con fines académicos
bajo la modalidad de monografía.
17
En comparación a sus predecesores este proyecto cuenta con un GPS que permitirá
la ubicación en tiempo real a los usuarios que usen la aplicación y conocer de primera
mano la ubicación de los huecos, otro nuevo factor en el desarrollo del proyecto es la
implementación de Android nativo. Teniendo en cuenta de que la idea debe ser
factible, mantenible, sostenible y eficaz en todos los aspectos, se desarrollara bajo el
lenguaje de programación java en el móvil, por el lado del servidor se utilizara
ASP.NET todo esto bajo la persistencia del motor para base de datos SQLSERVER,
por último, en el móvil la persistencia se manejara con la base de datos local SQLite.
Módulo de administración de usuarios
Este módulo se encarga de gestionar la creación, modificación y consulta de usuarios

asimismo de permitir el ingreso a la aplicación, las acciones de creación y
modificación están presentes en la aplicación móvil y en la aplicación web, por el
contrario, la consulta de usuarios será exclusiva para la aplicación web.
Módulo para la administración de huecos
Este módulo de la aplicación móvil permita registrar, consultar, modificar y eliminar

un hueco, las acciones de registrar, consultar y modificar estarán presentes en la
aplicación tanto web como móvil y la acción de eliminar será exclusiva para la
aplicación web. La acción de registrar me permitirá por medio del GPS capturar los
datos tales como las coordenadas geográficas donde se encuentra un hueco además
de capturar la información de la persona que lo reporto y la fecha en la que fue
reportado, también pueden ingresar observaciones o cualquier otro tipo de dato que
pueda ayudar con el proceso. Por otra parte, este módulo permite notificar cuando un
hueco se encuentre cerca donde este el usuario, también puede confirmar si el hueco
ya está tapado o de lo contrario que aún sigue ahí.
Módulo de Reportes
Este módulo exclusivo de la aplicación web se encarga de generar un informe de las

diferentes actividades realizadas por los actores en el administrador y un informe
personalizado por usuario, referente al estado o avance de los huecos denunciados
a manera de históricos exportables en Excel y/o PDF.
1.7. DELIMITACIONES
1.7.1. Delimitación Legal
 La ley 143-01 prohíbe el uso de teléfonos celulares o móviles a toda persona

que este conduciendo un vehículo de motor por las vías, por ende, la aplicación
en su parte móvil no se podrá utilizar mientras se conduce.
18
 La aplicación en su parte móvil tendrá restricciones de propiedad privada, ya
que no se podrá utilizar un aparato móvil.
1.7.2. Delimitaciones Sociales
Dado que la información mostrada por la aplicación respecto a los huecos se basa
en la información suministrada por los usuarios, esta puede llegar a ser inexacta,
incompleta o no actualizada si se tiene en cuenta que es una red geo social y que
no hay un filtro que se encargue de confirmar la veracidad de los datos.
El usuario de la aplicación debe ser responsable por el uso de la aplicación, si este

está conduciendo debe parar para reportar un hueco.
1.7.3. Delimitación Técnica
Las características esenciales de los dispositivos con los cuales se debe hacer uso
de la aplicación distribuida, deberán poseer la mayoría de las tecnologías utilizadas
dentro del desarrollo del sistema.
a. Características mínimas del computador, para que se pueda dar uso a la

aplicación distribuida:
Procesador de 3.0 GHz de velocidad.

Memoria RAM de 2.00 GB
Espacio en disco de 512 Mb
Sistema Operativo Windows (XP o superior)
b. Características mínimas del teléfono móvil, para que se pueda dar uso a la
aplicación distribuida:
Procesador de dos núcleos 1.2 GHz de velocidad.

Memoria RAM de 1.00 GB
Espacio en disco de 6 Gb
Android Lollipop versión 5.1.
GPS
1.7.4. Delimitación Conceptual
La aplicación está dirigida a usuarios que cuenten con automotores tales como carros
o motos y también transeúntes. Pretende que los usuarios reporten la ubicación de
los huecos que se encuentran en la malla vial, los huecos ya reportados con
anterioridad pueden ser visualizados por otros usuarios. Cabe resaltar que la
19
aplicación permitirá clasificar los huecos según su tamaño y por ultimo permitirá
cambiar el estado de los huecos a arreglado si el hueco fue tapado.
1.7.5. Delimitación Geográfica
La implementación de este proyecto como prototipo en fase de pruebas está dirigida

a los transeúntes y conductores de automotores del barrio San Francisco de la
localidad 19 en Ciudad Bolívar, Bogotá, Colombia.
La aplicación solo se podrá usar para lugares que se encuentren en google maps.
1.7.6. Delimitación Temporal del Proyecto
El tiempo estimado para la realización de este proyecto es 6 meses, dando inicio el

Del 22 de agosto de 2016 al 24 de febrero de 2017, de acuerdo a las tareas
planeadas en el cronograma de actividades detallado.
1.8. MARCO DE REFERENCIA
1.8.1. Marco Histórico
Actualmente en la localidad de ciudad bolívar no se tiene una aplicación que

cuantifique la cantidad de huecos, tampoco los ciudadanos conocen donde están
ubicados las alteraciones viales para poder evitar accidentes de tránsito.
También se puede citar como ejemplos HUECOSMED que es una aplicación de la
alcaldía de Medellín la cual su función principal es reportar huecos, estos reportes
llegan directamente a la secretaría de Infraestructura Física para eventualmente
taparlos, pero como restricción esta aplicación solo está disponible para la gente de
Medellín.
Por otra parte, hay una aplicación llamada URBANISMO EN LINEA en la cual el
usuario puede tomarle fotos a los huecos que encuentre en las vías de su ciudad,
para que otros usuarios los puedan identificar y cuidar sus vehículos. La aplicación
Urbanismo en línea se vale de los mapas de Google para mostrar los reportes de
huecos que los usuarios vayan compartiendo. Además, el aplicativo permite tomar
fotos de los cráteres que hacen parte del paisaje de las vías principales de ciudades
como Bogotá y Medellín.
ElHueco era una aplicación lanzada en el 2012 y actualmente fuera de servicio que
permite reportar huecos por medio de una foto de cualquier ciudad y visualizarlos en
un mapa con su ubicación exacta. Hay un mapa disponible en la aplicación y en el
sitio web www.elhueco.net, donde podrá ver estadísticas de los huecos por ciudad,
barrio, etc. Esta aplicación permite ver los huecos que se reportaron.
20
La aplicación anteriormente citada tiene inconvenientes en el caso de HUECOSMED
permite reportar un hueco sin necesidad de crear un perfil y no muestra los huecos
que están reportados en el mapa. En URBANISMO EN LINEA Y ELHUECO permiten
reportar el hueco y visualizar en el mapa los huecos reportados, pero no generan
notificaciones si el usuario se acerca a un hueco además estas aplicaciones están
fuera de servicio.
Por ultimo esta WAZE la cual tiene para múltiples reportes viales y no es específica
para los huecos por lo que a simple vista en el mapa se puede confundir un reporte
de un hueco con otros reportes de peligro esto debido a que todos los reportes de
peligro tienen el mismo icono en el mapa, otro inconveniente que tiene es que al
reportar un hueco no especifica el tipo de hueco y este reporte se elimina y
desaparece del mapa después de un lapso corto de tiempo.
Las redes geosociales es un tipo de red social que incluye funcionalidades
relacionadas con la georeferenciación, tales como la geocodificación o la
geoetiquetación, Ellas permiten a sus usuarios una dinámica social adicional a la que
existe en otras redes sociales, como la interacción basada en el lugar donde se
encuentran.
La georeferenciación se puede dar en las redes sociales gracias a localización de la
dirección IP, la trilateración de un hotspot (zona de cobertura wifi), la localización del
teléfono móvil o incluso la información enviada por el propio usuario al respecto.
(Semana, 2014)
1.8.2. Marco Teórico
APLICACIÓN DISTRIBUIDA:
Una aplicación con distintos componentes que se ejecutan en entornos separados,

normalmente en diferentes plataformas conectadas a través de una red. Las típicas
aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-
middleware-servidor) y multinivel. (Kurose & Ross, 20014)
MULTIPLATAFORMA:
Multiplataforma es un atributo conferido a programas informáticos o métodos y
conceptos de cómputo que son implementados e interoperan en múltiples
plataformas informáticas. Las plataformas de software pueden ser un sistema
operativo o entorno de programación, aunque más comúnmente se trata de una
combinación de ambos
Para que el software pueda ser considerado multiplataforma, debe ser capaz de
funcionar en más de una arquitectura de ordenador o sistema operativo. Esto puede
ser una tarea que consume tiempo, ya que los diferentes sistemas operativos tienen
diferentes interfaces de programación de aplicaciones o API. (EcuRed, 2016).
21
APLICACIÓN WEB:
Son aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor
web a través de Internet o de una intranet mediante un navegador. En otras palabras,
es una aplicación software que se codifica en un lenguaje soportado por los
navegadores web en la que se confía la ejecución al navegador.
Es importante mencionar que una página Web puede contener elementos que
permiten una comunicación activa entre el usuario y la información. Esto permite que
el usuario acceda a los datos de modo interactivo, gracias a que la página responderá
a cada una de sus acciones, como por ejemplo rellenar y enviar formularios, participar
en juegos diversos y acceder a gestores de base de datos de todo tipo (LUJÁN
MORA, 2001).
APLICACIÓN MÓVIL:
las aplicaciones móviles son los conjuntos de instrucciones lógicas, procedimientos,

reglas, documentación, datos e información asociada a estas que funcionan
específicamente en dispositivos móviles, como por ejemplo teléfonos inteligentes,
televisores inteligentes, tabletas, reloj, entre otros.
Las aplicaciones móviles se desarrollan bajo diferentes lenguajes de programación y

funcionan actualmente específicamente en sistemas operativos móviles, en estos
momentos los lenguajes más usados para desarrollar aplicaciones móviles son: Java,
Objetic C, Xcode C#, C++, WebOS, HTML5, Bad, XML, entre otros (Distancia, 2014).
MVC:
(Modelo Vista Controlador) Es un patrón de arquitectura de software que separa los

datos de una aplicación, la interfaz de usuario, y la lógica del control en tres
componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve
frecuentemente en aplicaciones web, donde la vista es la página HTML y el código
que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de
Base de Datos y la Lógica del negocio, y el controlador es el responsable de recibir
los eventos de entrada desde la vista.
Donde la descripción del patrón es la siguiente:
- Modelo: Esta es la representación específica de la información con la cual el sistema
opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador
facilitando las presentaciones visuales complejas. El sistema también puede operar
con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas
de negocio y de datos afines con el sistema modelado.
- Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente
la interfaz de usuario.
- Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca
peticiones al modelo y probablemente, a la vista.
22
Interacción de los componentes.
Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control
que se sigue generalmente es el siguiente:
1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario
pulsa un botón, enlace, etc.)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la
acción solicitada por el usuario. El controlador gestiona el evento que llega,
frecuentemente a través de un gestor de eventos (handler) o callback.
3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma
adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el
carro de la compra del usuario). Los controladores complejos están a menudo
estructurados usando un patrón de comando que encapsula las acciones y simplifica
su extensión.
4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de
usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para
el usuario donde se reflejan
Los cambios en el modelo (por ejemplo, produce un listado del contenido del carro
de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin
embargo, se podría utilizar el patrón Observador para proveer cierta in-dirección entre
el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier
cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios,
pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del
patrón Observador no es posible en las aplicaciones Web puesto que las clases de
la vista están desconectadas del modelo y del controlador. En general el controlador
no pasa objetos de dominio (el modelo) a la vista, aunque puede dar la orden a la
vista para que se actualice. Nota: En algunas implementaciones la vista no tiene
acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la
vista. Por ejemplo, en el MVC usado por Apple en su framework Cocoa. Suele citarse
como Modelo-Interface-Control, una variación del MVC más puro.
5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo
nuevamente....
SQLSERVER:
SQL Server es un sistema de gestión de bases de datos relacionales (RDBMS) de
Microsoft que está diseñado para el entorno empresarial. SQL Server se ejecuta en
T-SQL (Transact -SQL), un conjunto de extensiones de programación de Sybase y
Microsoft que añaden varias características a SQL estándar, incluyendo control de
transacciones, excepción y manejo de errores, procesamiento fila, así como variables
declaradas. (Rouse, 2016).
ASP.NET:
Es un modelo de desarrollo Web unificado que incluye los servicios necesarios para
crear aplicaciones Web empresariales con el código mínimo. ASP.NET forma parte
de .NET Framework y al codificar las aplicaciones ASP.NET tiene acceso a las clases
en .NET Framework. El código de las aplicaciones puede escribirse en cualquier
lenguaje compatible con el Common Language Runtime (CLR), entre ellos Microsoft
Visual Basic, C#, JScript .NET y J#. Estos lenguajes permiten desarrollar aplicaciones
23
ASP.NET que se benefician del Common Language Runtime, seguridad de tipos,
herencia, etc. (microsoft, Información general sobre ASP.NET, 2007)
SDK:
Es generalmente un conjunto de herramientas de desarrollo de software que le

permite al programador o desarrollador de software crear aplicaciones para un
sistema concreto, por ejemplo, ciertos paquetes de software, frameworks,
plataformas de hardware, computadoras, videoconsolas, sistemas operativos,
etcétera.
Es una interfaz de programación de aplicaciones o API (del inglés application

programing interface) creada para permitir el uso de cierto lenguaje de programación,
o puede, también, incluir hardware sofisticado para comunicarse con un determinado
sistema embebido. Las herramientas de desarrollo de software más comunes
incluyen soporte para la detección de errores de programación como un entorno de
desarrollo integrado o IDE (del inglés Integrated Development Environment) y otras
utilidades. Los SDK frecuentemente también incluyen códigos de ejemplo y notas
técnicas de soporte u otra documentación de soporte para ayudar a clarificar ciertos
puntos del material de referencia primario. (Alegsa, 2016).
C#:
Es un lenguaje de programación que se ha diseñado para compilar diversas

aplicaciones que se ejecutan en .NET Framework. C# es simple, eficaz, con
seguridad de tipos y orientado a objetos. Las numerosas innovaciones de C#
permiten desarrollar aplicaciones rápidamente y mantener la expresividad y elegancia
de los lenguajes de estilo de C.
Visual C# es una implementación del lenguaje C# de Microsoft. Visual Studio ofrece
compatibilidad con Visual C# con un completo editor de código, un compilador,
plantillas de proyecto, diseñadores, asistentes para código, un depurador eficaz y de
fácil uso y otras herramientas. La biblioteca de clases de .NET Framework ofrece
acceso a numerosos servicios de sistema operativo y a otras clases útiles y
adecuadamente diseñadas que aceleran el ciclo de desarrollo de manera
significativa. (microsoft, Guía de C#, 2017).
SERVICIOS WEB:
Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su
complejidad a la hora de dar una adecuada definición que englobe todo lo que son e
implican. Una posible sería hablar de ellos como un conjunto de aplicaciones o de
tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o
tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los
proveedores ofrecen sus servicios como procedimientos remotos y los usuarios
solicitan un servicio llamando a estos procedimientos a través de la Web.
Estos servicios proporcionan mecanismos de comunicación estándares entre
diferentes aplicaciones, que interactúan entre sí para presentar información dinámica
24
al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas
aplicaciones, y que al mismo tiempo sea posible su combinación para realizar
operaciones complejas, es necesaria una arquitectura de referencia estándar.
(España, 2016).
1.8.3. Marco metodológico
La metodología que se va utilizar para desarrollar el proyecto, es la metodología de

desarrollo de software llamada Racional Unified Process (RUP).
El Rational Unified Process (RUP) es un proceso de ingeniería de software, creado

por Ivar Jacobson, Grady Booch y James Rumbaugh, cuyo objetivo es el de mejorar
la productividad y el proceso de desarrollo de software en un equipo de trabajo, así
como también dar como resultado la puesta en marcha de las mejores prácticas en
el desarrollo de software por parte de los integrantes de dicho equipo, gracias a
dichas prácticas, es posible dar cabida dentro del RUP a cualquier tipo de proyectos,
incluidos a pequeños proyectos como los de nivel Web. 20
Características del RUP
 Utiliza el Lenguaje Unificado de Modelado (UML) como notación básica.

 Dirigido por casos de uso.
 Centrado en la arquitectura.
 Ciclo de vida iterativo e incremental.
 Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición.
 Las fases se dividen en un conjunto de iteraciones en las que se desarrollan cinco
flujos de trabajo fundamentales: recopilación de requerimientos, análisis, diseño,
implementación y pruebas.
Proceso dirigido por casos de uso:
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al

usuario un resultado importante. Los casos de uso representan los requisitos
funcionales. El proceso dirigido por casos de uso, quiere decir que el proceso sigue
un hilo, avanza a través de una serie de flujos de trabajo que parten de los casos de
uso. Los casos de uso se especifican, se diseñan y los casos de uso finales son la
fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba.
Proceso centrado en la arquitectura:
La arquitectura es una vista del diseño completo con las características más
importantes resaltadas, dejando de lado los detalles. La arquitectura como los casos
de uso, deben evolucionar en paralelo. A medida que los casos de uso se especifican
25
y maduran, se descubre más de la arquitectura. Esto, a su vez, lleva a la maduración
de más casos de uso.
Proceso iterativo e incremental:
Un proceso iterativo e incremental significa llevar a cabo un desarrollo en pequeños

pasos. (Mini Proyectos). El proyecto se divide en una serie de partes o mini-
proyectos, cada uno de estos va a ser una iteración. Las iteraciones hacen que
referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del
producto.
Vida del proceso unificado:
El proceso unificado consiste en una serie de ciclos que constituyen la vida de un

sistema. Al final de cada ciclo se obtiene una versión del producto. Las fases de cada
ciclo son:
a. Inicio: Describe el producto final.
b. Elaboración: Especifica en detalle la mayoría de los casos de uso y diseña la

arquitectura del sistema.
c. Construcción: Construye el producto cubriendo todos los casos de uso.
d. Transición: El producto existe en versión beta y unos usuarios experimentan

con el producto.
1.8.3.1. Fases del RUP
 Modelamiento Del Negocio: En este flujo se describen los diferentes procesos

del sistema y primer acercamiento a la arquitectura del sistema.
 Requisitos: Es el flujo de trabajo que busca establecer las características que
debe cumplir el sistema y los recursos necesarios para su montaje.
 Análisis y Diseño: Es el flujo de trabajo que nos permite obtener una visión
abstracta del sistema, nos da una visión global del sistema.
 Implementación: Tiene en cuenta el desarrollo de software, pruebas unitarias
e integración.
 Pruebas: Describe casos de prueba, procedimientos de prueba y métricas de
seguimiento de defectos.
 Despliegue: Cubre la configuración del sistema.
26
: .
Ilustración 1 fases RUP Fuente: Tomado del libro: El Proceso de desarrollo Unificado del Software
(Consultado: 22/Marzo/2016)
En la siguiente tabla se explican cada una de las fases de la metodología RUP con
sus respectivas actividades que se requieren y se desarrollar la aplicación.
Actividades que se requieren dentro de cada fase del RUP:
Tabla 1 Actividades metodología para el RUP
Flujo de Trabajo Descripción Actividades

Permite generalizar los Las actividades que se
requisitos, como desarrollan es esta fase
"necesidades", y para son:
conocer éstas tenemos  Definición de actores.
que comprender con  Lista preliminar de casos
REQUISITOS mayor amplitud el de uso.
modelamiento del  Depuración de casos de
negocio y el entorno en uso.
27
que trabajan sus  Modelo de casos de uso.
usuarios.
 Modelo del
dominio: Captura
los tipos más
importantes de
objetos en el
contexto del
sistema. Los
objetos del
dominio
representan las
"cosas" que
existen o los
eventos que
suceden.
 Modelo del
negocio:
Describimos los
procesos en
términos de casos
de uso y actores
de nuestro
sistema.
Durante el análisis Las actividades que se
analizamos los requisitos desarrollan es esta fase
que se describieron en la son:
 Diagramas de
captura de requisitos, secuencia.
ANALISIS refinándolos y  Diagramas de
reestructurándolos. colaboración.
Con esto se consigue  Diagramas de
mayor comprensión de actividad
 Diagramas de
los requisitos y una
estado.
descripción de los  Modelo del análisis.
mismos que sea fácil de  Clase del análisis
manejar y que le ayude al
desarrollador estructurar
el sistema entero.
28
Durante el diseño  Lista inicial de objetos.
modelamos el sistema y  Responsabilidades.
encontramos su forma  Modelo del diseño.
 Modelo objeto
para que soporte todos
DISEÑO relacional.
los requisitos, incluyendo  Diccionario de datos.
los requisitos No  Modelo de despliegue.
funcionales y otras  Descripción de la
restricciones. arquitectura.
Durante la Modelo de
implementación implementación:
IMPLEMENTACIÓN empezamos con el  Componente
resultado del diseño e  Interfaz
implementamos el
sistema en términos de
componentes, es decir,
ficheros de código fuente,
scripts, ejecutables y
similares.
En esta fase verificamos  Modelo de pruebas.
el resultado de la  Evaluación de prueba.
implementación  Pruebas individuales.
PRUEBAS  Pruebas del sistema.
probando cada
construcción, incluyendo
tanto construcciones
internas como
intermedias, así como las
versiones finales del
sistema.
Fuente: Elaboración propia y Formulación propia
1.9. FACTIBILIDAD
1.9.1. Factibilidad Técnica
1.9.1.1. Factibilidad técnica en el desarrollo
Las herramientas utilizadas en el desarrollo del sistema han sido adquiridas por los
desarrolladores, algunas de forma libre, las cuales se mencionan a continuación:
29
 Se emplea el sistema operativo Windows 10 para el desarrollo de la aplicación
web y Ubuntu 16.04 para el desarrollo de la aplicación móvil.
 Se emplea IIS Express, la versión gratuita del servidor web IIS.
 Se emplea la versión libre de SQLSERVER, SQLSERVER Express como sistema
de gestor de bases de datos.
 Se emplea un entorno de desarrollo libre Visual Studio Express el cual tiene
licencia freeware (software gratis).
 Framework .NET 3.5 o superior.
 Se emplea el SDK para desarrollo en la versión Android el API 23 (Marshmallow),
el cual su descarga es gratuita.
1.9.1.2. Factibilidad técnica en la implementación
 Base de datos SQL relacional administrada como servicio, de tipo base de datos
única, de nivel básica con 2 GB que incluye almacenamiento por BD.
 APP Service para aplicaciones web en la nube, de nivel básico con vCPU de 1.5
GB de RAM y 10 GB de Storage.
 El software estará diseñado para operar bajo un sistema operativo Linux o
Windows, que provee un servicio web.
 Para poder utilizar el aplicativo se necesita de un computador con pocas
especificaciones ya que uno de los alcances de este proyecto es que desde
cualquier lugar con una conexiona a internet y un ordenador uno pueda acceder
a la aplicación de forma remota.
1.9.2. Factibilidad Operativa
Tabla 2 Personal requerido para el proyecto
Nombre Funciones
Director de Tesis Responsable de supervisar y asesorar la elaboración del
proyecto.
Analistas y Validación de requisitos, especificación, y captura de datos,
Desarrolladores interactuando con el grupo de trabajo de la universidad,
mediante entrevistas, y documentación que ellos suministren.
Elaboración del modelo de análisis y diseño.
Planear, diseñar y evaluar las pruebas.
30
1.9.3. Factibilidad Económica
1.9.3.1. Recursos Físicos
1.9.3.1.1. Recursos físicos en el desarrollo de la aplicación
A continuación, se muestra una tabla con los recursos físicos que se utilizaron para
la realización del proyecto.
Tabla 3 Recursos físicos en el desarrollo de la aplicación.
Ítem Descripc CantDuración Fuente de Recurso Costo Costo Total

ión meses financiació variable fijo
n Valor /
Uni Estu Prop Comprar Mes
v io o alquiler
del
servicio
1 Computa 2 6 X X 0 1’600.000 $
dor $ 3´200.000
3 Servicios 2 6 X X 30.000$ $ 360.000
de Luz
4 Impresio 1 6 X X 40000$ $ 40.000
nes y
Papelerí
a
5 Visitas a 2 6 X X 40.000$ $ 480.000
la
Universid
ad
6 Otros 2 6 X X 35.000$ $ 420.000
TOTAL $4.500.00
0
1.9.3.1.2. Recursos físicos en la implementación de la aplicación
Debido a que la implementación de la aplicación web y la aplicación móvil se hará en

la nube no se contará con recursos físicos.
31
1.9.3.2. Recursos de Software
1.9.3.2.1. Recursos de Software en el desarrollo de la aplicación
El euro es un factor económico que influye en el costo de la implementación de las

aplicaciones, esto debido a que los costos de los servicios en la nube son pagados
en euros.
A continuación, se muestra una tabla con los recursos de software que se utilizaron
para la realización del proyecto.
Tabla 4 Recursos de software en el desarrollo de la aplicación.
Ítem Recurso Cantidad Licencia Valor Valor

Unitario
1 Licencia servidor 2 gratuita 0 0
web IIS Express
2 Licencia 2 gratuita 0 0
SQLSERVER
Express.
3 Licencia MySQL 2 gratuita 0 0
Workbench 5.2 OS
4 Licencia Visual 2 gratuita 0 0

Pardigm for UML
5 Licencia Visual 2 gratuita 0 0
Studio Express
TOTAL $0.0
1.9.3.2.2. Recursos de Software en la implementación de la aplicación
Se utilizará Microsoft Azure que permite implementar infraestructuras y servicios con

rapidez. Puede ejecutar aplicaciones basadas en Windows y Linux.
En la siguiente tabla se mostrará los recursos de Software que se necesitaran por un

año de implementación de la aplicación.
32
Tabla 5 Recursos de software en la implementación de la aplicación por un año.
Ítem Recurso Descripción Cant Meses Valor Valor Valor

/mes precio en
pesos
1 APP Región: Oeste de 1 12 46,30 555,6 1´947.378 $
Service EE.UU € €
Nivel: Básico.
Instancia: 1vCPU,
1.75GB de RAM,
10GB Storage
2 Base de Región: Oeste de 1 12 4,14 € 49,68 174.128,4 $
datos EE.UU €
SQL Nivel: Básico.
Tipo: Base de
datos única.
Nivel de
rendimiento : 2GB
incluido
almacenamiento
por BD
3 Google Darse de alta como 1 - - 25 74.650 $
Play desarrollador de US$
Store aplicaciones y
poderlas publicar
en la tienda.
4 Soporte Soporte técnico de 1 - - 0 0$

técnico azure por un año
5 IVA El desarrollo de un - - - - -
software está
exento del
Impuesto al Valor
Agregado (IVA).
TOTAL 2´196.156,4$
Precio del euro noviembre 28 del 2017: 3,505 pesos colombianos.

Precio del dólar noviembre 28 del 2017: 2,986 pesos colombianos.
33
1.9.3.3. Recursos de Humanos
En la siguiente tabla se muestra los desarrolladores del proyecto, y el director del

mismo.
1.9.3.3.1. Recursos de Humanos en el desarrollo de la aplicación
Tabla 6 Recursos Humanos en el desarrollo de la aplicación
Personal Funció Fuente de Valor Horas/ Valor/ mes Meses Total

n financiación / hora mes
Univer Estud
sidad iante
Sonia Director X 40.000 38 1´520.000$ 6 9´120.000$
Pinzón de $
Tesis
Ana Cruz Analista X 13.600 160 2´176.000 6 13´056.000$
Desarro $ $
llo
John Analista X 13.600 160 2´176.000 6 13´056.000$
Vasquez Desarro $ $
llo
TOTAL 35´232.000 $
1.9.3.3.2. Recursos de Humanos en la implementación de la aplicación
Tabla 7 Recurso humano por un año de implementación.
Personal Función Valor / Horas/ Valor/ mes Meses Total

hora mes
Ingeniero Desplegar y dar 11.000$ 160 1’760.000$ 12 21’120.000$

experto en soporte a las
aplicacion aplicaciones y
es en la bases de datos
nube en la nube
TOTAL 21’120.000$
34
1.1.1.1. Presupuesto
A continuación, se muestra el presupuesto total requerido para el desarrollo de

nuestra aplicación y para la implementación de esta.
Tabla 8 Presupuesto del desarrollo de la aplicación.
RECURSOS VALOR
Recursos Físicos $ 4.500.000
Recursos Humanos $35. 056.000
Recursos de Software $0.0
TOTAL $39.556.000
Tabla 9 Presupuesto de la implementación de la aplicación por un año.
RECURSOS VALOR
Recursos Físicos $0
Recursos Humanos $21’120.000
Recursos de Software $2’196.156,4
TOTAL $ 23’316.156,4
Total, de desarrollo e implementación por un año de la aplicación: $62’872.156,4 de

pesos
1.1.2. Factibilidad Legal
En este sentido no hay problema debido a que las herramientas que se van a utilizar
tienen licencia de software libre.
Además, al ser Huecapp una aplicación que almacenara los datos de los usuarios que
se registran para hacer uso del prototipo, se debe garantizar el cumplimiento de la ley
estatutaria 1581 del 2012 donde se dictan las suposiciones generales de protección
de datos personales. Esta norma establece obligaciones para todas las empresas, sin
excepción alguna, así como para personas naturales que utilicen datos personales
para fines comerciales, entre otros.
“Artículo 1°. Objeto. La presente ley tiene por objeto desarrollar el derecho
constitucional que tienen todas las personas a conocer, actualizar y rectificar las
informaciones que se hayan recogido sobre ellas en bases de datos o archivos, y los
demás derechos, libertades y garantías constitucionales a que se refiere el artículo 15
de la Constitución Política; así como el derecho a la información consagrado en el
artículo 20 de la misma.” (Certicámara, 2013).
35
1.10 Cronograma de Actividades.
Ilustración 2 cronograma de actividades

Fuente Elaboración propia y Formulación propia
1. FASE DE MODELAMIENTO DEL NEGOCIO
Para el desarrollo de esta etapa primero se identifica y define los módulos

que conformaran el sistema Huecapp, posteriormente se identifican los
procesos más importantes que explican detalladamente cuales y cómo
interactúan los actores en el proceso de manipulación y manejo de la
información en el sistema, estos procesos son expuestos en los diagramas
de proceso que estarán más adelante, los cuales se evidencia el flujo del
proceso. Seguidamente se realizó el modelo del dominio el cual capturar y
expresar en forma de diagrama de clases el entendimiento del negocio.
2.1. IDENTIFICACIÓN Y DEFINICIÓN DE LOS MÓDULOS DEL SISTEMA
El sistema se fracciono en cuatro módulos principales, los cuales interactúan

en un solo sistema. En la siguiente tabla se mencionarán y describirán los
cuatro módulos del sistema.
Tabla 10 Descripción de los módulos de la aplicación
Modulo Descripción
Módulo de registro y acceso Este módulo permite a los usuarios
registrarse para poder interactuar
con el sistema, además de
autentificar para poder acceder
como un usuario del sistema y así
poder ver, crear y modificar huecos.
Módulo de huecos En este módulo un usuario
independientemente del rol podrá
crear, modificar y ver la información
de un hueco, poder ver los huecos
que el usuario ha creado o
modificado, además si se tiene el rol
administrador se podrá eliminar
huecos
Módulo de administración de En este módulo el usuario
roles autenticado con el rol de
administrador podrá ver y cambiar el
rol que tenga otro usuario.
Módulo de reportes En este módulo el usuario
autenticado podrá generar reportes
del historial de huecos que ha
creado o modificado, así mismo un
usuario autenticado con el rol de
administrador podrá generar
reportes generales del historial de
los huecos e historial de huecos por
usuario.
2.2. DIAGRAMAS DE PROCESOS
Para representar el flujo de un proceso se utiliza los diagramas de flujo o

diagramas de proceso, en la siguiente tabla se expondrá los procesos de
cada módulo y una breve descripción de estos, seguido de la tabla se
mostrarán los diagramas de proceso los cuales se encargan de mostrar el
proceso paso a paso con sus respectivas actividades y condiciones que
requieren dichas actividades.
Tabla 11 Descripción de los procesos por módulos
Modulo Proceso Descripción

Módulo de Proceso iniciar Proceso por el cual el usuario accede a la
registro y sesión aplicación web o la aplicación móvil.
acceso proceso Proceso por el cual un usuario se registra
registrar usuario en la aplicación web o en la aplicación
móvil, cabe resalta que si el usuario se
registra en cualquiera de estas no
necesita registrarse en la otra aplicación
Módulo de Proceso Proceso por el cual un usuario registra un
huecos registrar hueco hueco, con sus coordenadas, tamaño y
una breve descripción.
Proceso Proceso por el cual un usuario puede ver
consultar hueco en detalle todos los datos más relevantes
de un hueco.
Proceso editar Proceso por el cual el usuario edita los
hueco datos de un hueco, datos tales como tipo
de hueco o la descripción de este.
Proceso Proceso por el cual el usuario
eliminar hueco administrador puede eliminar un hueco,
eliminando con este el historial del hueco.
Proceso ver Proceso por el cual el usuario puede ver
mapa los huecos en un mapa representados por
markers de colores según el tamaño del
hueco.
Módulo de Proceso Proceso por el cual el usuario
administra modificar rol administrador
ción de
roles
Módulo de Proceso generar Proceso por el cual el usuario
reportes reporte de administrador genera un reporte con el
huecos por historial de los huecos filtrado por cada
usuario usuario.
Proceso generar Proceso por el cual el usuario
reporte de administrador genera un reporte son el
huecos general historial de los huecos.
2.3.1 Modelo de procesos módulo de registro y acceso
act [Activ ity] Iniciar sesion [diagrama iniciar se...
Ini ci o i ni ci ar
sesi ón
Ingresar usuario y
contraseña
Datos
val i dos
NO
SI
Buscar usuario y
contraseña
NO
Exi ste
usuari o
comparar contraseña
la
NO
contraseña
es l a del
usuari o
Iniciar sesión
SI
Fi nal
Ilustración 3. Diagrama de proceso iniciar sesión

act [Activ ity] registrar usuario [diagram...
Inicio registrar
usuario
Opción registrar usuario
Ingresar datos del usuario
Datos
validos
SI
NO
Crear usuario
Final
Ilustración 4. Diagrama de proceso registrar usuario

2.3.2 Modelo de procesos módulo de huecos
act [Activ ity] registrar hueco [diagrama registra...
Inicio registrar
hueco
Iniciar sesión
Datos
NO
correctos
SI
Opción crear hueco
Ingresar datos del hueco
Datos
validos
NO
SI
Crear hueco
Final
Ilustración 5. Diagrama de proceso registrar hueco

act [Activ ity] Consultar hueco [diagrama consul...
Inicio
consultar
hueco
Iniciar sesión
NO
Datos
correctos
SI
Opción acciones hueco
Cargar mapa de huecos
Seleccionar hueco
Opción consultar hueco
buscar y cargar hueco de

la base
Mostrar detalles del hueco
Final
Ilustración 6. Diagrama de proceso consultar hueco

act [Activ ity] Editar hueco [diagrama editar huec...
Inicio
editar
hueco
Iniciar sesión
Datos
correctos
NO
SI
Seleccionar hueco
Opción editar hueco
Ingresar datos del hueco
NO
Datos
validos
SI
Editar hueco
Final
Ilustración 7. Diagrama de proceso editar hueco

act [Activ ity] Eliminar hueco [diagrama elimi...
Inicio
eliminar
hueco
Iniciar sesión
NO
Datos
correctos
SI
Seleccionar hueco
Opción eliminar hueco
Mostrar detalles del hueco
Eliminar hueco
Final
Ilustración 8. Diagrama de proceso eliminar hueco

act [Activ ity] registrar usuari...
Inicio ver mapa
Opción v er mapa
Buscar lista de huecos
mostrar los huecos en el

mapa
Final
Ilustración 9. Diagrama de proceso ver mapa

2.3.3 Modelo de procesos módulo de administración de roles.
act [Activ ity] Modificar rol [diagrama modific...
Inicio modificar rol

usuario
Iniciar sesión
NO
Datos
correctos
SI
Opción usuario y roles
Seleccionar usuario
Opción cambiar rol
Seleccionar rol
SI
El usuario ya
tiene
asignado ese
rol
NO
cambiar de rol
Final
Ilustración 10. Diagrama de proceso modificar rol

2.3.4 Modelo de procesos módulo de reportes.
act [Activ ity] reportes generales [diagrama de...
Inicio generar
reportes de
usuario
NO Generar
reportes
generales
SI
Buscar datos de los

huecos por usuario para
el reporte
NO Descargar
reporte
SI
Cargar reporte
Final
Ilustración 11. Diagrama de proceso generar reporte de huecos por usuario

act [Activ ity] reportes usuario [diagrama desc...
Inicio generar
reportes
generales
NO Generar
reportes
generales
SI
Buscar datos del reporte
NO Descargar
reporte
SI
Cargar reporte
Final
Ilustración 12. Diagrama de proceso generar reporte de huecos general

2.3. MODELO DEL DOMINO
El modelo del dominio es utilizado para comprender como interactuará las

clases que representa un objeto físico. El hueco se relaciona con la clase
tipo hueco esto debido a que un hueco puede tiene un tamaño especifico,
además se requiere saber qué cambios se ha sometido el hueco y que
usuarios han realizados estos cambios, por ese motivo la clase historial
hueco se relaciona con la clase hueco y con la clase usuario.
Por otra parte, el usuario se relaciona con la clase estado del usuario, rol y
tipo identificación, la primera especifica el estado que este usuario tiene
actualmente, la segunda especifica el rol que el usuario tendrá en el sistema
y el último especifica qué tipo de identificación tiene el usuario asociado.
class Obj etos del dominio
Hueco 1.. * Historial_Hueco * .. 1 Usuario Estado_Usuario

1
1 1
1
Rol
Tipo_Identificacion
Tipo_Hueco
Modelo de clases del dominio de

la aplicacion web del proyecto
Huecapp
Ilustración 13. Modelo del dominio huecapp

2.4. GLOSARIO DE TÉRMINOS
Durante la primera fase del levantamiento de información se recopilaron

términos los cuales se utilizan constantemente, en esta parte del proyecto
se dan definiciones o explicaciones a estas palabras desconocidas.
Tabla 12 Glosario de términos
CONCEPTO DESCRIPCION
HUECO VIAL Pequeño desnivel en el suelo o en el pavimento,
producido por la pérdida o hundimiento de la capa
superficial.
DETECCIÓN Captar o notar la presencia de un hueco vial.
MODULO Módulo es una porción de un programa de ordenador.

De las varias tareas que debe realizar un programa
para cumplir con su función u objetivos, un módulo
realizará.
REGISTRO Un registro es un conjunto de campos que contienen
los datos que pertenecen a una misma repetición de
entidad.
AUTENTICACIÓN Es la acción que se lleva a cabo para validar la
identidad de un usuario dentro del sistema distribuido.
GEOLOCALIZACIÓN Capacidad para obtener la ubicación geográfica real

de un teléfono móvil o un ordenador conectado a
Internet.
USUARIO Persona que usa habitualmente los servicios de la
aplicación distribuida en un grado de privilegios
inferiores
ADMINISTRADOR Persona que usa habitualmente los servicios de la
aplicación distribuida en un grado de privilegios
mayores la cual le permite un mayor control del mismo
MOVIL Dispositivo electrónico el cual, bajo determinadas
características físicas puede potencialmente brindar el
servicio de la aplicación distribuida
MULTIPLATAFORMA Aplicación que puede utilizarse en diversos entornos
o sistemas operativos en este caso WEB y ANDROID
COORDENADAS Es un sistema el cual permite que cada ubicación en
la Tierra sea especificada por un conjunto de números
3. FASE DE REQUERIMIENTOS
Para determinar las necesidades o las condiciones a satisfacer para la

aplicación web y aplicación móvil es necesario hacer un proceso de
levantamiento de información, una lista de requerimientos funcionales,
requerimientos no funcionales, definición de actores, una lista preliminar de
casos de uso, diagramas de caso de uso con su respectiva documentación.
3.1 IDENTIFICACION DE LA INFORMACIÓN
Levantamiento de información es un proceso en el cual se recopilan datos e

información de la situación actual de un sistema, en el proceso reportes de
huecos viales, se realizó por medio de unas encuestas a la gente del barrio San
Francisco de la localidad 19 de Ciudad Bolívar en la cuidad de Bogotá Colombia,
en la cual se preguntaba sobre los recursos físicos (estado de la malla vial) con
los que contaba la zona.
Ver anexo A. Formato de encuesta para el levantamiento de información.
3.1.1 Encuesta
Con la entrevista realizada, se puedo llegar a un acuerdo, que muestra los

problemas actuales en el proceso de reporte de huecos viales:
 Existe un problema, no se ha tenido un control sistematizado de los

huecos, pues se tienen registros físicos de estos, lo cual no ha permitido
tener un control eficaz, dificultando el trabajo en algunas ocasiones de las
autoridades para repararlos y en paralelo la gente tiene accidentes de
tránsito por no saber la existencia de los mismos.
 Actualmente se cuentan con unas aplicaciones que de manera

indirecta podrían abordar la temática, pero no es posible que se tenga un
reporte exacto sobre la cantidad de huecos y el estado actual de los mismos
en la zona afectada.
 La aplicación distribuida, dará un control total sobre los reportes que

se manejan en la cantidad y característica de los huecos, en el barrio san
francisco de ciudad bolívar. permitiendo así una mejoría en la gestión del
proceso vial en el barrio anteriormente mencionado.
3.2 REQUERIMIENTOS FUNCIONALES
Los siguientes requerimientos funcionales le definirán al usuario los servicios

específicos que el sistema debe proporcionar. En el caso del sistema Huecapp
estos requerimientos funcionales estarán por módulos.
 Requerimiento de módulo de administración de registro y acceso

 Requerimiento de módulo de administración de usuarios
 Requerimiento de módulo de administración de huecos
 Requerimiento de módulo de reportes
3.2.1 Requerimiento de módulo de administración de registro y acceso
Tabla 13 Requerimiento RF1 del módulo de administración de registro y acceso
Nombre de requerimiento RF 001

Funcionalidad El sistema web y móvil será utilizado
solo por personas que sean usuarios
del mismo y que previamente hayan
sido registradas.
Especificación
Entrada Ingresar al aplicativo web y móvil
Proceso Validar datos de inicio de sesión.
Salida Cargar interfaz de inicio
Tabla 14 Requerimiento RF2 del módulo de administración de registro y acceso

Funcionalidad En sistema web y móvil los usuarios
podrán registrarse por medio de un
formulario de inscripción donde se le
pedirán sus datos personales.
Especificación
Entrada Registrarse en el aplicativo web y móvil
Proceso Registrar datos usuarios.
Salida Registrar un usuario
3.2.2 Requerimiento de módulo de administración de usuarios
Tabla 15 Requerimiento RF3 del módulo de administración de usuarios

podrán modificar su información
ingresada previamente por medio de un
formulario de modificación de datos
personales.
Especificación
Entrada Modificar usuario en el aplicativo web y
móvil
Proceso Modificar los datos de un usuario
previamente registrado.
Salida Modificar un usuario
Tabla 16 Requerimiento RF004 del módulo de administración de usuarios

podrán consultar su información
ingresada previamente por medio de un
formulario de consulta de datos
personales.
Especificación
Entrada Consultar usuario en el aplicativo web y
móvil
Proceso Consultar los datos de un usuario
Salida Consultar un usuario
3.2.3 Requerimiento de módulo de administración de huecos
Tabla 17 Requerimiento RF005 de módulo de administración de huecos

podrán crear un hueco solo ingresando
una observación y una característica
del mismo
Especificación
Entrada Crear un hueco en el aplicativo web y
móvil
Proceso Crear un hueco validando parámetros
de entrada u ubicación de coordenadas
gps.
Salida Crear un hueco

podrán consultar un hueco por medio
de un listado y un Live Map donde
mostrara información más detallada del
mismo
Especificación
Entrada Consultar un hueco en el aplicativo web
y móvil
Proceso Consultar un hueco en una lista la cual
estará ordenada de manera
cronológica.
Salida Consultar un hueco

Funcionalidad En sistema web los usuarios podrán
modificar la información ingresada
previamente de un hueco por medio de
un formulario de modificación de
huecos.
Especificación
Entrada Modificar hueco en el aplicativo web.
Proceso Modificar los datos de un hueco
Salida Modificar un hueco

Funcionalidad En sistema web los usuarios podrán
eliminar la información ingresada
previamente de un hueco por medio de
un formulario de eliminación de huecos.
Especificación
Entrada Eliminar un hueco en el aplicativo web.
Proceso Eliminar los datos de un hueco
Salida Eliminar un hueco
Funcionalidad El sistema móvil notificara a los
usuarios cuando un hueco se
encuentre cerca de su ubicación.
Especificación
Entrada Notificar sobre existencia de hueco al
usuario.
Proceso El sistema buscara en el listado de
huecos existentes cual se encuentra
más cerca y lo notificara siempre y
cuando el usuario este ubicado cerca
del mismo.
Salida Notificar la existencia un hueco cercano

Funcionalidad En sistema móvil los usuarios podrán
confirmar la existencia de un hueco
ingresado previamente por medio de un
popup de confirmación de huecos.
Especificación
Entrada Confirmar existencia hueco en el
aplicativo móvil.
Proceso Modificar el estado actual del hueco
Salida Modificar un hueco
3.2.4 Requerimiento de módulo de reportes
Tabla 23 Requerimiento RF012 de módulo de reportes

Funcionalidad Para este módulo se requiere que la
aplicación web se encargue de generar
un informe de las diferentes actividades
realizadas por los actores en el
administrador y un informe
personalizado por usuario, referente al
estado o avance de los huecos
denunciados a manera de históricos
exportables en PDF.
Especificación
Entrada Visualizar reportes e históricos de la
información que contiene la aplicación.
Proceso Modificar los parámetros de búsqueda
del reporte
Salida Cargar modulo visualización de
reportes
3.1. REQUERIMIENTOS NO FUNCIONALES
Habiendo tomado los requerimientos funcionales del sistema, se analizan los

requerimientos no funcionales cuyo fin es el de preparar al sistema para ejecutarse
e infiere en cuestiones de funcionamiento y desempeño de la aplicación, así como
la dinámica de la operación de la aplicación y los criterios de funcionalidad del
sistema y buscan controlar más la operación de la aplicación con el fin de evitar
eventos nuevos y no puedan manejarse.
Tabla 24 Requerimiento no funcional RF01 seguridad
Identificador: RNF 001 Nombre: Seguridad

Descripción: Acceso a la información
Criterios de Aceptación: Debe de haber filtros de seguridad para la consulta

y subida de documentación, igual de protegerse la información de agentes
externos.
Tabla 25 Requerimiento no funcional RF02 seguridad de logueo
Identificador: RNF 002 Nombre: Seguridad de logueo

Descripción: Acceso a la plataforma.
Criterios de Aceptación: Debe validarse que el usuario acreditado es el

único que puede entrar a la cuenta.
Tabla 26 Requerimiento no funcional RF03 limitación de acceso
Identificador: RNF 003 Nombre: Limitación de acceso.

Descripción: Tipos de acceso.
Criterios de Aceptación: Sólo el administrador del sistema tendrá acceso

total a toda la información, usuario se limitará a consultar información acerca
de huecos y lo concerniente a sus credenciales de acceso.
Tabla 27 Requerimiento no funcional RF04 navegadores
Identificador: RNF 004 Nombre: Navegadores

Descripción: Soporte a navegadores web
Criterios de Aceptación: Debe estar apto para usarse con cualquier

navegador; sin embargo, no tendrá de momento una implementación para
tablets específicamente.
Tabla 28 Requerimiento no funcional RF05 versiones de android
Identificador: RNF 005 Nombre: Versiones de Android

Descripción: Soporte a versiones de Android
Criterios de Aceptación: Debe estar apto para usarse en Android Lollipop

versión 5.1. con un dispositivo GPS y acceso a internet
Tabla 29 Requerimiento no funcional RF06 error de la información
Identificador: RNF 006 Nombre: Error de la información

Descripción: Alertas
Criterios de Aceptación: Se emitirá una alerta en caso que haya errores en la
digitación de información y se podrá modificar por el administrador únicamente
cuando es un caso donde los campos principales presenten errores. Igualmente
podrá modificarse por los usuarios en caso que sea posible modificarse un dato
que esté dentro de sus límites para modificación.
3.2. DEFINICIÓN DE ACTORES
La definición de actores nos permitirá saber a ciencia cierta cuales usuarios

podrán interactuar con la aplicación web y móvil de huecapp, en la siguiente
tabla se especifica los actores y una descripción de estos.
Los actores que interactúan con el sistema son:
Tabla 30 Lista de actores
ACTOR 1 USUARIO MÓVIL

DESCRIPCION Es el actor que interactúa con la
aplicación móvil.
LIMITE Puede crear, ver, modificar huecos y
modificar sus credenciales de usuario.
ACTOR 2 USUARIO WEB
DESCRIPCION Es el actor que interactúa con la
aplicación web.
LIMITE Puede ver, crear, editar huecos, ver
una lista y generar un reporte huecos
que ha creado o modificado.
ACTOR 3 USUARIO ADMINISTRADOR WEB
DESCRIPCION Es el encargado de administrar la
página web
LIMITE Además de los límites del usuario web
este puede eliminar huecos, crear
reportes generales de los huecos y
cambiar de rol a los usuarios.
3.3. LISTA PRELIMINAR DE CASOS DE USO
Se analiza las funciones del sistema y los actores que hacen uso de ellas y
según estas funcionalidades se crea una lista preliminar de casos de uso.
 Generar reportes de usuario

 Generar reportes generales
 Registrar hueco
 Consultar hueco
 Editar hueco
 Eliminar hueco
 Modificar rol usuario
 Registrar usuario
 Iniciar sesión
 Ver mapa huecos
3.3.1. DIAGRAMAS CASOS DE USO
El modelo de casos de uso es el artefacto que nos permite presentar las

acciones y el listado de todos los actores para así determinar de una forma
gráfica un dominio en base a su accionar para cada actor. En los casos de uso
a ver se podrá ver el actor y las acciones que el usuario podrá realizar.
En el presente modelado de casos de uso se citarán los diagramas separados

por módulos de desarrollo con una vista general, también una vista distribuido
por aplicación que en este caso es web y móvil. Para por ultimo mostrar la
documentación de todos los casos de uso.
3.3.1.1. Diagrama general de casos de uso
uc Casos de uso principales
Sistema Huecapp
Caso de Uso de modo general

del Sistema Huecapp
Generar reportes de
usuario
Generar reportes
generales
Registrar hueco
Consultar hueco
Editar hueco
Usuario Administrador
Web Usuario Web
Eliminar hueco
Modificar rol
usuario
Registrar usuario
Usuario Mov il
Iniciar sesión
Ver mapa huecos
Ilustración 14. Diagrama general de casos de uso

3.3.1.2. Diagrama de caso de uso usuario móvil
Registrar hueco
«include»
Consultar hueco
«include» Iniciar sesión
Usuario Mov il «include»
Editar hueco
Registrar usuario
Ilustración 15. Diagrama de caso de uso usuario móvil

3.3.1.3. Diagrama de caso de uso usuario web
Generar reportes de
usuario «include»
«include» Iniciar sesión

Registrar hueco
«include»
«include»
Consultar hueco
Usuario Web
«extend»
Editar hueco
«extend»
Ver mapa huecos
Registrar usuario
Ilustración 16. Diagrama de caso de uso usuario web

3.3.1.4. Diagrama de caso de uso usuario administrador web
Registrar usuario
Modificar rol
usuario
«include»
Generar reportes de
usuario
«include»
Iniciar sesión
«include»
Generar reportes
generales «include»
«include»
Registrar hueco
«include»
Usuario Administrador «include»

Web
Consultar hueco
«extend»
Editar hueco
«extend»
Ver mapa huecos
«extend»
Eliminar hueco
Ilustración 17. Diagrama de caso de uso usuario administrador web

3.3.2. DOCUMENTACIÓN CASOS DE USO
Los casos de uso son un método que, justamente, ayudan al Ingeniero de

software a llevar adelante esta parte del desarrollo de un sistema de
software, A continuación, sólo se citará la ficha de caso de uso “Consultar
Hueco” y en el Anexo B (fichas de caso de uso), se podrá consultar la
información completa.
3.3.2.1 Ficha de caso de uso consultar hueco
Tabla 31 Ficha de caso de uso consultar hueco

NOMBRE CASO DE USO
Consulta hueco
CODIGO
HUECAPP-WEB-MOV-0002
ACTORES
Usuario administrador web, usuario web y usuario móvil
DESCRIPCION
Permite al actor consultar el dato de un hueco
PRECONDICIÓN
El usuario debe encontrarse logueado.
FLUJOS NORMALES DE EVENTOS

1 Flujo normal de eventos para consulta web
Actor Sistemas
1 En acciones huecos se selecciona 2 Busca en la base de datos la información del
un hueco (Marker) y se selecciona el hueco según el idHueco.
link de “detalles”.
3 Muestra los datos del hueco en pantalla y con
la opción de “volver al mapa”.
2 Flujo normal de eventos para consulta móvil
Actor Sistemas
1 En menú de opciones selecciona la 2 Busca en la base de datos la información del
opción consultar huecos. dato extra según los datos de entrada.
3 Muestra los datos del hueco en pantalla y con
la opción de “volver al mapa”.
CAMINOS ALTERNATIVOS
Error en la base de datos.
Actor Sistemas
1 Si en cualquier paso de los flujos se recibe un
error desde la base de datos, muestra mensaje
de error.
REQUERIMIENTOS ESPECIALES
El actor debe estar logueado

4. FASE DE ANÁLISIS
Esta fase es el flujo de trabajo que brinda una vista abstracta del sistema ya que
en la misma se definirá que hará el sistema y cuál es el alcance del mismo.
4.1. DIAGRAMAS DE SECUENCIA
Los diagramas de secuencia que se presentan a continuación tienen como

objetivo describir paso a paso la interacción de los objetos a través del tiempo
en las capas modelo, vista y controlador; es decir, como interactúa la interfaz
del usuario con las clases y a su vez como éstas interactúan con las clases
Modelo encargadas de la persistencia de datos.
A continuación, sólo se citará el diagrama de secuencia “inicio de sesión” y

en el Anexo C (Diagramas de secuencia), se podrá consultar la información
completa.
sd Diagrama de secuencia
Vista: Vista: Controlador: Modelo:

index.cshtml Login.cshtml Account.cs usuario.cs
Usuario Web,Usuario
Administrador Web
Login(usuario)
Find(usuario);
return
usuario()
RedirectToLocal(returnUrl)
Ilustración 18. Diagrama de secuencia inicio de sesión

4.2. DIAGRAMAS DE COLABORACIÓN
En los siguientes diagramas de colaboración se describe cómo interactúan

los objetos entre sí mediante funciones y por medio de una secuencia
enumerada permite ver la interacción de la interfaz de usuario con las clases
y la interacción de éstas con las clases que tienen a cargo de la persistencia
de datos.
A continuación, sólo se citará el diagrama de Colaboración “editar hueco” y

en el Anexo D (Diagramas de Colaboración), se podrá consultar la
información completa.
sd Diagrama de colaboracion editar hueco
1. Seleccionar editar
hueco() 2. Edit(id)
----------------------------> Vista: ---------> Vista: Edit.cshtml
ActionMapaHueco.cshtml
Usuario Administrador
Web
3. BuscarHistorial()
4. selecionarHueco()
<-------------------
<----------------
hueco historial_hueco
7. editarhueco()
<--------------------
5. View(hueco)
6. Edit(hueco)
8. View(hueco)
Ilustración 19. Diagrama de colaboración editar hueco

4.3. DIAGRAMAS DE ACTIVIDAD
Los diagramas de actividad que se presentan a continuación muestran los

procesos que la aplicación realiza se representan por medio de flujos en los
cuales se modela el comportamiento de un procedimiento mostrando como
las actividades y condiciones se conectan en las capas modelo, vista y
controlador
A continuación, sólo se citará el diagrama de Actividad “eliminar hueco” y

en el Anexo E (Diagramas de Actividad), se podrá consultar la información
completa.
Ilustración 20. Diagrama de actividad eliminar hueco

4.4. DIAGRAMAS DE ANÁLISIS
El siguiente diagrama de análisis muestra la interacción de cada uno de los

actores del sistema con las aplicaciones que conforman el sistema y a su
vez como estas aplicaciones interaccionan con sus respectivos servicios y
con la base de datos.
analysis Diagrama de analisis
Gestion de huecos,
creacion , edicion,
Pagina web Huecapp
Usuario Web detalles e historial
Gestion de roles y
usuarios, gestion de
Usuario Administrador Pagina web Huecapp huecos,
Web configuraciones y
reportes historial Base de datos
huecos
Usuario Mov il Aplicacion movil android Gestion de huecos por

Huecapp usuario, creacion,
edicion, detalles e
historial y gestion de
usuario, crear editar
Ilustración 21 Diagrama de análisis

5. FASE DE DISEÑO
La fase de diseño es el proceso de aplicar distintas técnicas y principios con el

propósito de definir un proceso o sistema con los suficientes detalles como para
permitir su realización física. El objetivo de la fase es producir un modelo o
representación de una entidad que verá reflejada en la implementación de la
aplicación.
5.1. LISTA DE CLASES
A continuación, se muestran las clases que representan un listado inicial para

elementos en el sistema que tienen potestad dentro de la lógica, estas clases son
de tipo .cs en caso del lenguaje C# y .java en el caso de Android.
5.1.1. Lista de clases aplicación web
Tabla 32 lista de clases de la capa modelo de la aplicación web
Capa Modelo

AspNetRoles.cs

AspNetUsers.cs

estado_usuario.cs

historial_hueco.cs

hueco.cs

tipo_hueco.cs

tipo_identificacion.cs

usuario.cs

AspNetRoles.cs

AspNetUsers.cs

estado_usuario.cs

historial_hueco.cs
 CreacionHueco.cs
 SuperUsuario.cs
Tabla 33 Lista de clases de la capa controlador de la aplicación web
Capa Controlador
 AccountController.cs
 CreacionHuecosController.cs
 estado_usuarioController.cs
 HomeController.cs
 huecoAPIController.cs
 huecoesController.cs
 HuecosApiController.cs
 huecoServicioApiController.cs
 ManageController.cs
 tipo_huecoController.cs
 tipo_identificacionController.cs
 usuarioapiController.cs
 usuarioRepController.cs
 usuariosApiController.cs
 usuariosController.cs
 UsuariosRolesController.cs
Tabla 34 Lista de clases de la capa servicios de la aplicación web
Capa Servicios
 huecoServicioApi.cs
 huecoApi.cs
 usuarioApi.cs
5.1.1.1. Lista de clases aplicación móvil
Tabla 35 Lista de clases de la capa modelo de la aplicación móvil
Capa Modelo
 Bump
 User
 BumpOperations
 UserOperatios
 HuecAppHandler
 ConstantSQL
 JSONHttpClient
Tabla 36 Lista de clases de la capa controlador de la aplicación móvil
Capa controlador
 AppCompatPreferenceActivity
 LoginActivity
 MainActivity
 RegisterActivity
 SettingActivity
 RecycleViewAdapter
 CustomClusterRenderer
 CustomInfoViewAdapter
 MyItemCluster
 BumpFragment
 ConfirmFragment
 MenuAFragmen
 MenuBFragmen
MenuCFragmen
5.1.2. Responsabilidad de clases
A continuación, se muestran las clases que representan un listado inicial para

elementos en el sistema que tienen responsabilidad y comportamiento, estas
clases son de tipo .cs en caso del lenguaje C# y .java en el caso de Android.
5.1.2.1. Responsabilidad de clases aplicación web
Tabla 37 Lista de responsabilidad de clases aplicación web capa modelo
Capa Modelo
Clase Operación
 AspNetRoles.cs Iniciar sesión
 AspNetUsers.cs Iniciar sesión
 usuario.cs Iniciar sesión
 estado_usuario.cs Iniciar sesión
 tipo_identificacion.cs Iniciar sesión
 SuperUsuario.cs Iniciar sesión
 AspNetRoles.cs registrarse
 AspNetUsers.cs registrarse
 usuario.cs registrarse
 estado_usuario.cs registrarse
 tipo_identificacion.cs registrarse
 SuperUsuario.cs registrarse
 hueco.cs Crear hueco
 historial_hueco.cs Crear hueco
 tipo_hueco.cs Crear hueco
 CreacionHueco.cs Crear hueco
 usuario.cs Crear hueco
 hueco.cs Editar hueco
 historial_hueco.cs Editar hueco
 tipo_hueco.cs Editar hueco
 CreacionHueco.cs Editar hueco
 usuario.cs Editar hueco
 hueco.cs Eliminar hueco
 historial_hueco.cs Eliminar hueco
 tipo_hueco.cs Eliminar hueco
 CreacionHueco.cs Eliminar hueco
 usuario.cs Eliminar hueco
 hueco.cs Ver mapa huecos
 historial_hueco.cs Ver mapa huecos
 tipo_hueco.cs Ver mapa huecos
 CreacionHueco.cs Ver mapa huecos
 usuario.cs Ver mapa huecos
 hueco.cs
Detalles hueco
 historial_hueco.cs Detalle hueco
 tipo_hueco.cs Detalle hueco
 CreacionHueco.cs Detalle hueco
 usuario.cs Detalle hueco
 AspNetRoles.cs Agregar rol
 AspNetUsers.cs Agregar rol
 usuario.cs Agregar rol
 estado_usuario.cs Agregar rol
 tipo_identificacion.cs Agregar rol
 SuperUsuario.cs Agregar rol
 AspNetRoles.cs Detalles de usuarios
 AspNetUsers.cs Detalles de usuarios
 usuario.cs Detalles de usuarios
 estado_usuario.cs Detalles de usuarios
 tipo_identificacion.cs Detalles de usuarios
 SuperUsuario.cs Detalles de usuarios
 estado_usuario.cs Configuración estado usuario
 tipo_identificacion.cs Configuración tipo identificación
 tipo_hueco.cs Configuración tipo hueco
Tabla 38 Lista de responsabilidad de clases aplicación web capa controlador
Capa Controlador
Clase Responsabilidad
 AccountController.cs Iniciar sesión
 HomeController.cs Iniciar sesión
 AccountController.cs Registrarse
 HomeController.cs Registrarse
 CreacionHuecosController.cs Crear hueco
 CreacionHuecosController.cs Editar hueco
 CreacionHuecosController.cs Eliminar hueco
 CreacionHuecosController.cs Detalle hueco
 estado_usuarioController.cs Configuración estado usuario
 huecoAPIController.cs Ver mapa huecos
 ManageController.cs Manejo de controllers
 tipo_identificacionController.cs Configuración tipo id
 tipo_huecoController.cs Configuración tipo hueco
 usuarioRepController.cs Creación de reportes
 usuariosApiController Agregar rol usuarios
 usuariosApiController Detalles de usuarios
 UsuariosRolesController.cs Agregar rol usuarios
 UsuariosRolesController.cs Iniciar sesión
Tabla 39 Lista de responsabilidad de clases aplicación web capa servicios
Capa Servicios
Clase Responsabilidad
 huecoServicioApi.cs Crear hueco
 huecoServicioApi.cs Editar hueco
 huecoServicioApi.cs Lista de huecos
 usuarioApi.cs Registrar usuario
 usuarioApi.cs Actualizar usuario
 usuarioApi.cs Actualizar contraseña
 huecoApi.cs Ver mapa huecos
 huecoApi.cs Buscar usuario
5.1.3. Modelo de interfaz
La interfaz que se desarrolla en la aplicación HuecApp se realiza a través

de formularios para la inserción y actualización de datos que son desde el
móvil a un servicio web que a su vez son enviados al servidor y por ultimo
almacenados a la base de datos. Por su parte las consultas son presentadas
a través de mapas y consultas que hacen una mejor experiencia de usuario.
5.1.3.1 Modelo de Interfaz Modulo de registro y acceso
Ilustración 22. Interfaz módulo de inicio de sesión móvil

Ilustración 23. Interfaz módulo de registro de usuario móvil
1.1.3.2 Modelo de Interfaz módulo de huecos
Ilustración 24. Interfaz módulo de consultar un hueco móvil

Ilustración 25. Interfaz módulo de consultar un hueco móvil
Ilustración 26. Interfaz módulo de crear un hueco móvil

Ilustración 27. Interfaz módulo de eliminar un hueco
Ilustración 28. Interfaz módulo de editar un hueco

Ilustración 29. Interfaz módulo de notificar un hueco
5.1.3.3 Modelo de Interfaz módulo de usuarios
Ilustración 30. Interfaz módulo de consultar un usuario

Ilustración 31. Interfaz módulo de editar un usuario
5.1.3.4 Modelo de Interfaz módulo de reportes
Ilustración 32. Interfaz módulo de reportes historial por hueco

5.1.4. Mapa de navegación
5.1.4.1. Mapa de navegación aplicación web
Como se muestra en la grafica se puede ver el flujo de navegación desde

la página principal a las demás paginas conectadas.
El flujo de navegacion cambia y se divide en 2 dependiendo del rol, para

el Administrador hay una navegacion con 7 paginas mas que para un
usuario comun.
Cabe resaltar que la navegacion y la redireccion son diferentes , la

navegacion es fija siempre y la redireccion depende de una accion que a
veces compromete unas variables
ui Nav egacion General
Acerca de
Mapa
«navigate»
«navigate»
Inicio Huecos Acciones huecos

«navigate» «navigate»
«redirect» «redirect»
Historial hueco Detalles hueco

«redirect» «navigate»
«navigate»
Iniciar sesion
Registrarse
Ilustración 33. Modelo de interfaz General

ui Nav egacion Usuario administrador
TipoHueco
Estado Usuario
Acerca de
Tipo identificacion
Configuracion
«navigate»
Usuarios y roles
«navigate»
Listado de Usuarios
Usuarios «navigate»
Inicio Mapa
Huecos
«navigate» Crear Hueco
«navigate»
«redirect» «navigate»
«navigate» Mis Huecos
Iniciar sesion Acciones huecos

Detalles hueco
«redirect»
«redirect» «redirect»
«redirect»
Historial hueco Eliminar hueco

Editar hueco
Ilustración 34. Modelo de interfaz usuario administrador

ui Nav egacion Usuario Logueado
Acerca de
Mapa
«navigate»
«navigate»
Inicio Huecos Crear Hueco
«navigate»
Mis Huecos
«redirect» «navigate» «navigate»
Iniciar sesion Acciones huecos
«redirect» «redirect» «redirect»
Historial hueco Editar hueco Detalles hueco
Ilustración 35. Modelo de interfaz usuario

5.1.5. Modelo de clases
5.1.5.1. Modelo de clases aplicación web
Ilustración 36. Diagrama de clases aplicación web

5.1.5.2. Modelo de clases aplicación móvil
Ilustración 37. Diagrama de clases aplicación móvil

5.1.6. Modelo relacional
Ilustración 38. Modelo entidad relación

5.1.7. DICCIONARIO DE DATOS
Tabla: estado_usuario
Tabla 40 estado usuario
Campo Tipo de Descripción

Dato
ESTUSU_ID INT Llave primaria de la tabla
estado_usuario.
ESTUSU_DESCRIPCION VARCHAR Descripción del estado del
usuario.
Tabla: tipo_hueco
Tabla 41 Tipo hueco

Dato
TIPHU_ID INT Llave primaria de la tabla
tipo_hueco.
TIPHU_DESCRIPCION VARCHAR Descripción del tipo de hueco.
Tabla: tipo_identificacion
Tabla 42 Tipo identificación
Campo Tipo de Dato Descripción

TIPID_ID INT Llave primaria de la tabla
tipo_identificacion.
TIPID_DESCRIPCION VARCHAR Descripción del tipo de
identificación.
Tabla: hueco
Tabla 43 Hueco
Campo Tipo de Dato Descripción

HUE_ID BIGINT Llave primaria de la tabla
hueco.
HUE_FECHA_CREACION DATETIME Fecha de la creación del
hueco
HUE_LATITUD FLOAT Coordenada de latitud
donde está ubicado el
hueco.
HUE_LONGITUD FLOAT Coordenada de longitud
hueco.
HUE_ALTURA FLOAT Coordenada de altura
hueco.
HUE_PRECISION INT Precisión con que se
tomaron las coordenadas
del hueco
HUE_OBSERVACION VARCHAR Una observación que
coloca el usuario que crea o
modifica el hueco
Tabla: usuario
Tabla 44 Usuario

Dato
USU_ID BIGINT Llave primaria de la tabla
usuario.
USU_NOMBRE VARCHAR Nombre del usuario
USU_APELLIDO VARCHAR Apellido del usuario
USU_IDENTIFICACION VARCHAR Número de identificación
del usuario
USU_TELEFONO VARCHAR Teléfono del usuario
USU_FECHAREGISTRO DATETIME Fecha el día que se
registró e usuario.
USU_CORREO VARCHAR Correo electrónico del
usuario
USU_NICKNAME VARCHAR Nombre del usuario para
ingresar a al sistema
USU_LATITUD FLOAT Coordenada de latitud
usuario.
USU_LONGITUD FLOAT Coordenada de longitud
usuario.
USU_ALTURA FLOAT Coordenada de altura
usuario.
USU_PRECISION INT Precisión con que se
tomaron las coordenadas
del usuario
USU_PASSWORD VARCHAR Contraseña del usuario
para ingresar a al sistema
USU_FECHA_MODIFICACION DATETIME Fecha el día que se
modificó el usuario.
estado_usuario_ESTUSU_ID INT Llave foránea del estado
del usuario
tipo_identificacion_TIPID_ID INT Llave foránea del tipo de
identificación del usuario.
Tabla: historial_hueco
Tabla 45 Historial hueco

Dato
HISTHU_ID INT Llave primaria de la tabla
historial_hueco.
HISTHU_FECHA DATETIME Fecha del día que se creó el
usuario.
HISTHU_DESCRIPCION VARCHAR Descripción del historial del
hueco.
tipo_hueco_TIPHU_ID INT Llave foránea del tipo de
hueco.
hueco_HUE_ID BIGINT Llave foránea del hueco.
usuario_USU_ID BIGINT Llave foránea del usuario.
6. FASE DE IMPLEMENTACIÓN
En esta fase el propósito es asegurar que el producto de software esté listo

para ser distribuido entre los diferentes usuarios del sistema.
6.1. IMPLEMENTACIÓN DE LOS SERVICIOS WEB
Debido a que la aplicación móvil y la aplicación web accede a una lista de

huecos, permite reportar (agregar) huecos, editar huecos y solo en el caso
de la aplicación web eliminar huecos, es decir que estas dos aplicaciones
necesitan comunicarse para consumir y alimentar la misma información la
cual es manejada por el servidor y guardada en una base de datos.
Ya que se debían comunicar la aplicación móvil y la aplicación web, la

primera desarrollada en android studio con lenguaje java y la segunda
desarrollada en asp.net con lenguaje c#, se optó por utilizar servicios web,
específicamente servicios restful los cuales permitirían comunicar dos
aplicaciones creadas con dos diferentes tecnologías y leguajes.
Los servicios restful nos solucionan el problema de interactuar entre

diferentes lenguajes ya que estos permitirían realizar operaciones en el
servidor u obtener información en un formato que cualquier aplicación
pueda entender y procesar, el elemento principal en el que se basan estos
servicios consiste en URL´s a las que podemos acceder mediante el
protocolo HTTP además que el lenguaje para el intercambio de información
y el formato de la información que se intercambie con estas URLs lo decidirá
el desarrollador del servicio. Para el caso en concreto de huecapp se utilizó
como lenguaje c# y como formato de salida JSON.
Además de los servicios restful que se utilizaron para la aplicación móvil, se

creó un servicio restful público con el cual cualquier aplicación puede
acceder a este con la url y consumir este servicio, el tipo de método que se
utiliza es GET ya que este método ofrece seguridad e idempotencia,
seguridad al no poder modificar o causar ningún cambio a la información e
idempotencia al devolver siempre una misma respuesta en este caso un
código de esta http además de la información solicitada o un mensaje de
error.
El servicio restful se hace con el fin de escalar la aplicación, ya que los datos
recolectados por los usuarios en un futuro podrán ser utilizados por otras
aplicaciones que no estén relacionadas con huecapp como puede ser con
futuras aplicaciones del el Instituto de Desarrollo Urbano (IDU).
Ilustración 39 pantalla del servicio restful público de huecos que se encuentra en la

aplicación web.
6.2. DIAGRAMA DEL SISTEMA
En el diagrama del sistema se evidencia como es la interacción de los

componentes con la aplicación y con el usuario. A continuación, se
mencionarán los pasos que utiliza la aplicación tanto móvil como web para
acceder a los servicios.
Aplicación Móvil forma general
1. El usuario que va en un vehículo puede acceder a la Aplicación con un

teléfono inteligente que tenga de sistema operativo android.
2. La aplicación móvil Huecapp consulta con los servicios Api y estos a
subes consulta en el core de la aplicación los servicios web.
3. Los servicios web consultan en la base de datos y envían una respuesta
4. Esta respuesta es enviada al teléfono android con un formato JSON
5. En la aplicación móvil el JSON interactuar con el Api de Google Maps
que provee servicios para mostrar los huecos, ingresar nuevos huecos y
ayudar a detectar los huecos.
Aplicación Web forma general

1. El usuario accede a la aplicación web desde cualquier dispositivo que le
brinde acceso a internet.
2. Al realizar una petición la aplicación web se conecta consulta los
servicios bien se servicios Api o servicios de ASP .net.
3. Los servicios mencionados en el paso anterior se conectan con la base
de datos y envían una repuesta.
4. La aplicación web recibe esta información que interactúa con el Api de
Google Maps para JavaScript que provee servicios para mostrar los
huecos existentes y agregar nuevos huecos.
Ilustración 40. Diagrama del sistema

6.3. DIAGRAMA DE COMPONENTES
Los diagramas de componentes permiten visualizar con mayor facilidad la

estructura general del sistema y el comportamiento del servicio que estos
componentes proporcionan y utilizan a través de las interfaces.
deployment Huecapp
Serv idor de aplicaciones w eb
Modulos
Cliente w eb
Internet Information
Módulo de reportes Serv ices (ISS)
Interfaz w eb Serv idor de base de datos
ASP .NET MVC
Módulo de
administración de SQL Serv er
roles Management
Cliente mov il
WEB API
Módulo de huecos
aplicacion
Android
Entity Framew ork
Módulo de registro
y acceso
Ilustración 41. Diagrama de componentes

6.4. DIAGRAMA DE PAQUETES
El siguiente diagrama de paquetes representa la dependencia que tienen

los paquetes que componen la aplicación, muestra cómo están agrupados
estos en las capas de modelo vista y controlador de la aplicación web y la
aplicación móvil.
Ilustración 42. Diagrama de paquetes

6.5. DIAGRAMA DE DESPLIEGUE
Los diagramas de despliegue modelan la arquitectura en tiempo de

ejecución de un sistema. Para este software se utilizó la arquitectura por
capas MVC que permite separar los datos y la lógica de negocio de la
interfaz de usuario.
deployment Huecapp
Serv idor de aplicaciones w eb
Ordenador
«Solicitud de accion» Internet Information Serv ices

Nav egador
(ISS) Serv idor de base de datos
«solicitud de accion»
«respuesta de accion»
ASP .NET MVC SQL Serv er Management
«respuesta de accion»
«solicitud de accion»
Telefono inteligente «Solicitud de accion» WEB API «respuesta de accion»
aplicacion Android «respuesta de accion»
Ilustración 43. Diagrama de despliegue

7. FASE DE PRUEBAS
7.1 PRUEBAS DE SISTEMA DE INTERACCIÓN
Para la realización de las pruebas del sistema, se hizo la instalación de la

aplicación en el servidor destinado para ello. Las pruebas más realizadas
por los usuarios del sistema fueron:
Tabla 5 Prueba módulo de registro y acceso
Prueba módulo de registro y acceso

Dirigida por: Asistente: Estado
Ana María Cruz John Henry Vásquez Proceso O

K
Terminada X
Concepto Inspeccionar el funcionamiento del registro e inicio de sesión de la
página web y móvil de huecapp
Perfil: Usuario web, Usuario móvil y Usuario administrador web
ACCION ELEMENTO Resultado esperado Estado
A PRUEBA
RF002 Página de Ingresar un usuario web al sistema y a la OK
registro base de datos por medio de un
formulario.
RF001 Página de Permitir el ingreso al sistema si los datos OK
inicio de de Usuario y de Contraseña existen y
sesión coinciden con algún registro en la base
(Login) de datos.
RF004 Vista de Registrar un nuevo usuario al sistema OK

registro con el perfil de visitante por defecto, este
se ingresa a la base de datos del
servidor por medio de un servicio
RF003 Vista de Permitir al usuario modificar los datos de OK

editar usuario su cuenta enlazada, para ello tendrá que
registrarse previamente
Errores 1. Ninguna
Correcciones 1. Ninguna

Tabla 6 Prueba módulo de huecos
Prueba módulo de huecos


K
Terminada S
I
Concepto Inspeccionar el funcionamiento del módulo de huecos de la página
web de huecapp
Perfil: Usuario web y Usuario administrador web
A PRUEBA
RF006 mapa Página mapa Mostrar los huecos existentes en un OK
huecos mapa.
RF005 Página crear Permitir la creación de un hueco, el cual OK

mapa mostrara en la página mapa.
RF006 Página mis Permite ver la lista de huecos que el OK

huecos usuario logueado ha modificado o
creado
RF007 Página editar Permite la edición de un hueco de forma OK

hueco exitosa, notificando con un mensaje que
se modificó de manera exitosa
Errores 2. Ninguna

Tabla 7 Prueba módulo de huecos móvil
Prueba módulo de huecos móvil


K
Terminada S
I
Concepto Inspeccionar el funcionamiento del módulo de huecos de la página
web de huecapp
Perfil: Usuario móvil
A PRUEBA
RF006 mapa Vista mapa Mostrar los huecos existentes en un OK
huecos mapa.
RF005 Dialogo para Permitir la creación de un hueco, el cual OK

crear hueco mostrara en la vista del mapa.
RF006 Vista mis Permite ver la lista de huecos que el OK

huecos usuario logueado ha modificado o
creado
RF007 Página editar Permite la edición de un hueco cada vez OK

hueco quien un usuario se encuentre cerca del
hueco de forma exitosa, notificando con
un mensaje que se modificó de manera
exitosa
RF009 Notificación Permite al usuario por medio de una OK
barra de alerta de vibración y una notificación en
Android, la barra de Android enterar de cuando
alerta de hay un bache cerca
vibración
Errores 3. Ninguna

Tabla 8 Prueba módulo de reportes
Prueba módulo de reportes


K
Terminada X
Concepto Inspeccionar el funcionamiento de reportes en la aplicación WEB
Perfil: Usuario web y Usuario administrador web
A PRUEBA
RF0012 Ingresar un usuario web al sistema y a la OK
Formularios base de datos por medio de un
de reportes formulario.
Errores 4. Ninguna
Tabla 9 Prueba módulo de algoritmo acercamiento
Prueba módulo de algoritmo acercamiento


K
Terminada X
Concepto Inspeccionar el funcionamiento del algoritmo de acercamiento
cuando se tiene un hueco cerca
Perfil: Usuario móvil
A PRUEBA
RF009 Cuando se acerca a una distancia OK
prudencial, el móvil notifica a el usuario
Vista de mapa
que se encuentra un módulo cerca del
área
Errores 5. Ninguna

RECOMENDACIONES
 Para la correcta ejecución del proyecto en su parte web es necesario tener

un navegador web como Google Chrome, Mozilla Firefox, o Internet Explorer
9.
 Para la correcta ejecución del proyecto en su parte móvil es necesario contar
con una terminal Android de api 22 Lollipop ya que se encuentra optimizado
para este api del SDK nativo de Android.
 El aplicativo se encuentra diseñado de forma tal que se ejecute

correctamente en servidores ISS de Microsoft.
CONCLUSIONES
En la etapa final de este proyecto, se puede decir que se ha cumplido con el tiempo
establecido y además se ha conseguido desarrollar una Aplicación distribuida que
reporta huecos viales basado en coordenadas de posicionamiento global.
El levantamiento de datos hecho por medio de una investigación apoyado por el

estado del arte para establecer de manera clara como se estaba abordando la
problemática en diferentes ciudades del país, fue de gran importancia, dado que en
este paso de la investigación se estableció un listado de requerimientos que
permitieron tener un horizonte claro sobre dar solución a la problemática planteada.
Se desarrollaron satisfactoriamente los módulos propuestos para la aplicación

distribuida utilizando herramientas como Google Maps, la cual es muy sencillo de
implementar, se optó por el uso de esta tecnología porque es una de las API de
mapas más usados y extendidos en todo el mundo.
Tecnologías como Entity Framework facilitaron el desarrollo del sistema web ya que
permite el desarrollo de aplicaciones orientadas a objetos, pese a esto surgieron
problemas con la utilización de esta tecnología puesto obligaba a crear dos clases
de vista HuecoAPI y usuarioAPI que implementan los modelos del hueco y el
usuario para los servicios creados del Web API.
Para contar con un entregable en un comienzo se utilizaron tecnologías como

XAMARIN un framework para soluciones móviles de Microsoft, pero esta
herramienta no cumplió con las expectativas ya que era muy limitado para los
requerimientos funcionales establecidos inicialmente, en su lugar se utilizó Java y
el SDK de Android nativo el cual cuenta con un robusto número de librerías como
Location con la cual se pudo obtener la ubicación del GPS.
Se pudo realizar una integración de tecnologías que manejan diferentes lenguajes

tales como C# y Java gracias a la implementación del framework (Web API) que
facilitaron el desarrollo de los servicios web.
BIBLIOGRAFIA
 - Zantout, H., & Farhi, M. (1999) International Journal of Information

Management, Volume 19 Issue 6, Paginas 471–484.
 LUJÁN MORA, Sergio. Programación en Internet: clientes web. Alicante:

Editorial Club Universitario, 2001. ISBN 978-84-8454-118-9, 224 p.
 Welling, Luke (1972) SQLSERVER Web development / Luke Welling, Laura

Thomson. 4th edition. Addison-Wesley, 2008
 [Garrett] Jesse James Garrett. Ajax: A New Approach to Web Applications.

Adaptive Path, Feb. 2005.
http://www.adaptivepath.com/publications/essays/archives/000385.php
 Oros Cabello Juan Carlos, Diseño de páginas web interactivas con javascript
y css, Cuarta edición, Editorial alfa omega, 2004.
 Eguíluz Pérez, Javier, Introducción a Ajax, Editorial librosweb, España, 2008.
 Eguíluz Pérez, Javier, Introducción a JavaScript, Editorial librosweb, España,

2009.
 Ruiz Granados Cinthya Estado del Arte 18 octubre 2013:

http://www.larepublica.co/infraestructura/conozca-las-aplicaciones-para-
denunciar-huecos-en-las-calles_71596
 Microsoft, Documentación sobre XAMARIN: https://developer.xamarin.com/
 ALGESA LEANDRO, definición SDK: http://www.alegsa.com.ar/Dic/sdk.php
 QUIJANO JUAN, Introducción al ASP.NET:

http://www.genbetadev.com/formacion/tutorial-de-iniciacion-en-asp-net-mvc-
con-visual-studio-2013
 Modelo Vista Controlador Definición y Características:

http://www.comusoft.com/modelo-vista-controlador-definicion-y-
caracteristicas.
 C# for Visual Studio Code:

https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp
 Cuadros de dialogo en android nativo:
https://developer.android.com/guide/topics/ui/dialogs.html
 Notificaciones en android nativo:

https://developer.android.com/guide/topics/ui/notifiers/notifications.html
 Usando dialog Frarments en android nativo: https://android-

developers.googleblog.com/2012/05/using-dialogfragments.html
 Intents y filtros de intents en android nativo:

https://developer.android.com/guide/components/intents-filters.html
 Marcadores en Google Maps:

https://developers.google.com/maps/documentation/android-
api/marker?hl=es-419
 Ventanas de informacion para markers en Google Maps:

api/infowindows?hl=es-419
 Modificar opciones de camara y vista en Google Maps:

api/views?hl=es-419
 Google maps: https://www.google.com/maps/about/mymaps/
 JavaScript API de google maps:

https://developers.google.com/maps/documentation/javascript/?hl=es-419
 JavaScript API de google maps para uso de geocalizacion:

https://developers.google.com/maps/documentation/javascript/examples/ma
p-geolocation?hl=es-419
 Mapa sincrono JavaScript API de Google Maps:

https://developers.google.com/maps/documentation/javascript/examples/ma
p-sync?hl=es-419
REFERENCIAS
 Alegsa. (22 de 08 de 2016). Definición de SDK. Obtenido de Alegsa.com.ar:

http://www.alegsa.com.ar/Dic/sdk.php
 Certicámara. (29 de Agosto de 2013). Colombia Digital. Obtenido de ABC
para proteger los datos personales, Ley 1581 de 2012 Decreto 1377 de 2013:
https://colombiadigital.net/actualidad/articulos-informativos/item/5543-abc-
para-proteger-los-datos-personales-ley-1581-de-2012-decreto-1377-de-
2013.html
 Distancia, U. N. (9 de 11 de 2014). ¿Que es una Aplicación Móvil? . Obtenido
de Universidad Nacional Abierta y a Distancia :
http://datateca.unad.edu.co/contenidos/233016/EXE_SAM/leccin_2_que_es
_una_aplicacin_mvil.html
 EcuRed. (16 de 08 de 2016). Multiplataforma. Obtenido de EcuRed:
http://www.ecured.cu/Multiplataforma
 España, W. (26 de 08 de 2016). Guía Breve de Servicios Web. Obtenido de
W3C España: https://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
 Kurose, J. F., & Ross, K. W. (20014). REDES DE COMPUTADORES.Un
enfoque descendente basado en Internet. Cordoba: Pearson Educación ed.
 LUJÁN MORA, S. (2001). Programación en Internet: clientes web. Alicante:
Editorial Club Universitario.
 microsoft. (01 de 01 de 2007). Información general sobre ASP.NET. Obtenido
de microsoft: https://msdn.microsoft.com/es-
es/library/4w3ex9c2(v=vs.100).aspx
 microsoft. (23 de 8 de 2017). Guía de C#. Obtenido de microsoft:
https://docs.microsoft.com/es-es/dotnet/csharp/
 Rouse, M. (13 de 05 de 2016). SQL Server. Obtenido de search data center:
http://searchdatacenter.techtarget.com/es/definicion/SQL-Server
 Semana, R. (30 de 1 de 2014). Reporte los huecos que hay en las vías de su
ciudad mediante su celular. Obtenido de Revista Semana:
http://www.semana.com/tecnologia/novedades/articulo/reporte-huecos-vias-
su-ciudad-mediante-su-celular/375657-3
INFOGRAFIA
 Anules, Afipes. Ìteso. [En línea]

http://iteso.mx/~adrianay/sesion3.ppt#264,9,Administracion `
[consultado: 11/Mayo/2017]
 Arana, Nava, Manuel. Principios de Sistemas de información

http://comunidad.uach.mx/marana/materias/ppios_si/ppios_si.htm
 Servidor de aplicaciones IIS [En línea],

https://msdn.microsoft.com/es-es/library/ms181052(VS.80).aspx
[Consultado: 11/Mayo/2017].
 Álvarez, Miguel Ángel. Qué es Javascript. [En línea]

http://www.desarrolloweb.com/articulos/25.php [Consultado:
11/Mayo/2017].
 Programa “Adopta un JSR” [En línea]

https://www.java.net/community/adoptajsr/es [Consultado:
10/Marzo/2017].
 Juan Carbajal Paxi. Desarrollo de aplicaciones MVC. [en línea]:

http://www.slideshare.net/siis/mvc-306955. [Consultado:
10/Mayo/2017].
 Sistema de Información de la universidad Distrital Francisco José de

caldas [En línea] https://condor.udistrital.edu.co/appserv/
 Sistema de Información de Telmex Mobile. [En línea]

http://telmexmobile.com/admin/login. [Consultado: 11/Mayo/2017].
 Infraestructura vial, una deuda pendiente. [En línea]

http://www.bogotacomovamos.org/blog/infraestructura-vial-una-
deuda-pendiente/ [Consultado: 22/Octubre/2017].
 sqlserver 2016 Reference Manual, [En línea]
https://www.microsoft.com/es-es/sql-server/sql-server-2016
ANEXOS
ANEXO A. Formato de encuesta para levantamiento de información
ANEXO B. Fichas de casos de uso
ANEXO C. Diagramas de secuencia
ANEXO D. Diagramas de Colaboración
ANEXO E. Diagramas de Actividad
ANEXO F. Manual de usuario
ANEXO G. Manual de Instalación
Todos los Anexos se encuentran en el CD adicional.

Vasquez Leon Aplicacion Distribuida para El Reporte de Huecos Viales Basado en Coordenadas de Posicionamiento Global

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

Vasquez Leon Aplicacion Distribuida para El Reporte de Huecos Viales Basado en Coordenadas de Posicionamiento Global

Cargado por

Copyright:

Formatos disponibles

APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES BASADA EN

COORDENADAS DE POSICIONAMIENTO GLOBAL (GPS).

JOHN HENRY VASQUEZ LEON

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

JOHN HENRY VASQUEZ LEON

Monografía presentada como requisito para optar al título de

SONIA ALEXANDRA PINZON NUÑEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

Bogotá D.C. octubre 20 de 2017

Agradecemos a los estudiantes de ingeniería telemática Daniel Cruz y Camilo

John Henry Vásquez León.

Ana María Cruz Carabuena

Lista de tablas ...................................................................................................................... 10

Ilustración 1. fases RUP ....................................................................................................... 26

Tabla 1 Actividades metodología para el RUP ..................................................................... 27

El desarrollo de una aplicación distribuida para el reporte de huecos viales basado

HUECAPP maneja tecnologías de punta, desarrollado sobre el Framework MVC de

Los modelos de sistema se desarrollaron con la herramienta Enterprise Architec 10.

HUECAPP handles state-of-the-art technologies, developed on the .NET MVC Framework

El escaso nivel de infraestructura con el que se cuenta en la ciudad de Bogotá a nivel

Según una encuesta de la organización “Bogotá como vamos” un 54% de los

El propósito general de este proyecto es elaborar un prototipo de una aplicación

Para la realización del proyecto se ejecutó un profundo levantamiento de información

En el presente documento se describe un problema, tomándolo como punto de

El presente documento muestra el desarrollo de las aplicaciones distribuidas, que

Aplicación distribuida para reportar huecos viales basada en coordenadas de

Para el desarrollo del proyecto se debe tener en cuenta el tema de aplicación

1.3. PLANTEAMIENTO DEL PROBLEMA

El primer factor que causa problemas en la movilidad de la ciudad es la falta

1.3.2. Formulación del problema

1.4.1. Objetivo general

Desarrollar una aplicación distribuida para reportar huecos viales basada en

 Diseñar y desarrollar un módulo de gestión que permita crear, modificar y consultar

 Diseñar y desarrollar un módulo de reportes para la aplicación web que se encargue

Actualmente en el mercado hay aplicaciones similares que abordan la problemática

Cabe resaltar que la aplicación se alimenta de la información que los usuarios

Módulo de administración de usuarios

Este módulo se encarga de gestionar la creación, modificación y consulta de usuarios

Módulo para la administración de huecos

Este módulo de la aplicación móvil permita registrar, consultar, modificar y eliminar

Este módulo exclusivo de la aplicación web se encarga de generar un informe de las

1.7.1. Delimitación Legal

 La ley 143-01 prohíbe el uso de teléfonos celulares o móviles a toda persona

1.7.2. Delimitaciones Sociales

El usuario de la aplicación debe ser responsable por el uso de la aplicación, si este

1.7.3. Delimitación Técnica

a. Características mínimas del computador, para que se pueda dar uso a la

Procesador de 3.0 GHz de velocidad.

Procesador de dos núcleos 1.2 GHz de velocidad.

1.7.4. Delimitación Conceptual

1.7.5. Delimitación Geográfica

La implementación de este proyecto como prototipo en fase de pruebas está dirigida

1.7.6. Delimitación Temporal del Proyecto

El tiempo estimado para la realización de este proyecto es 6 meses, dando inicio el

1.8. MARCO DE REFERENCIA

1.8.1. Marco Histórico

Actualmente en la localidad de ciudad bolívar no se tiene una aplicación que

1.8.2. Marco Teórico

Una aplicación con distintos componentes que se ejecutan en entornos separados,

las aplicaciones móviles son los conjuntos de instrucciones lógicas, procedimientos,

Las aplicaciones móviles se desarrollan bajo diferentes lenguajes de programación y

(Modelo Vista Controlador) Es un patrón de arquitectura de software que separa los

Es generalmente un conjunto de herramientas de desarrollo de software que le