APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES …repository.udistrital.edu.co/bitstream/11349/7506/9/VASQUEZ LEON... · APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES BASADA

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

3

Nota de aceptación

_______________________________

_______________________________

_______________________________

_____________________________

Firma de Tutor

_____________________________

Firma del Jurado

Bogotá D.C. octubre 20 de 2017

4

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.

5

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

6

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

7

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

8

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

9

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 25. interfaz módulo de consultar un hueco móvil ................................................ 79

Ilustración 26. interfaz módulo de consultar un hueco móvil ................................................ 79 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

10

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 19 Requerimiento RF007 de módulo de administración de huecos ........................ 555

Tabla 20 Requerimiento RF008 de módulo de administración de huecos ........................ 555 Tabla 21 Requerimiento RF009 de módulo de administración de huecos ......................... 566

Tabla 22 Requerimiento RF010 de módulo de administración de huecos ......................... 566

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

11

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

12

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.

13

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.

14

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.

15

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

16

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.

17

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.

18

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.

19

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

20

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.

21

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).

22

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.

23

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

24

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

25

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

26

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.

27

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

REQUISITOS

Permite generalizar los requisitos, como "necesidades", y para conocer éstas tenemos que comprender con mayor amplitud el modelamiento del negocio y el entorno en

Las actividades que se desarrollan es esta fase son: Definición de actores. Lista preliminar de casos

de uso.

Depuración de casos de

uso.

: .

28

que trabajan sus 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.

Modelo de casos de uso.

ANALISIS

Durante el análisis

analizamos los requisitos

que se describieron en la

captura de requisitos,

refinándolos y

reestructurándolos.

Con esto se consigue

mayor comprensión de

los requisitos y una

descripción de los

mismos que sea fácil de

manejar y que le ayude al

desarrollador estructurar

el sistema entero.

Las actividades que se desarrollan es esta fase son: Diagramas de

secuencia. Diagramas de

colaboración. Diagramas de

actividad Diagramas de

estado. Modelo del análisis. Clase del análisis

29

DISEÑO

Durante el diseño

modelamos el sistema y

encontramos su forma

para que soporte todos

los requisitos, incluyendo

los requisitos No

funcionales y otras

restricciones.

Lista inicial de objetos. Responsabilidades. Modelo del diseño. Modelo objeto

relacional. Diccionario de datos. Modelo de despliegue. Descripción de la

arquitectura.

IMPLEMENTACIÓN

Durante la

implementación

empezamos con el

resultado del diseño e

implementamos el

sistema en términos de

componentes, es decir,

ficheros de código fuente,

scripts, ejecutables y

similares.

Modelo de

implementación:

Componente

Interfaz

PRUEBAS

En esta fase verificamos

el resultado de la

implementación

probando cada

construcción, incluyendo

tanto construcciones

internas como

intermedias, así como las

versiones finales del

sistema.

Modelo de pruebas. Evaluación de prueba. Pruebas individuales. Pruebas 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:

30

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

Desarrolladores

Validación de requisitos, especificación, y captura de datos, 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.


31

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.


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.

Ítem Descripc

ión

Cant Duración

meses

Fuente de

financiació

n

Recurso Costo

variable

Valor /

Mes

Costo

fijo

Total

Uni

v

Estu Prop

io

Comprar

o alquiler

del

servicio

1 Computa

dor

2 6 X X 0 1’600.000

$

$

3´200.000

3 Servicios

de Luz

2 6 X X 30.000$ $ 360.000

4 Impresio

nes y

Papelerí

a

1 6 X X 40000$ $ 40.000

5 Visitas a la Universid

ad

2 6 X X 40.000$ $ 480.000

6 Otros 2 6 X X 35.000$ $ 420.000

TOTAL $4.500.00

0

32

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

Unitario

Valor

1 Licencia servidor

web IIS Express

2 gratuita 0 0

2 Licencia

SQLSERVER

Express.

2 gratuita 0 0

3 Licencia MySQL

Workbench 5.2 OS

2 gratuita 0 0

4 Licencia Visual

Pardigm for UML

2 gratuita 0 0

5 Licencia Visual

Studio Express

2 gratuita 0 0

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.

33

Tabla 5 Recursos de software en la implementación de la aplicación por un año.

Ítem Recurso Descripción Cant Meses Valor

/mes

Valor Valor

precio en

pesos

1 APP

Service

Región: Oeste de

EE.UU

Nivel: Básico.

Instancia: 1vCPU,

1.75GB de RAM,

10GB Storage

1 12 46,30

€

555,6

€

1´947.378 $

2 Base de

datos

SQL

Región: Oeste de

EE.UU

Nivel: Básico.

Tipo: Base de

datos única.

Nivel de

rendimiento : 2GB

incluido

almacenamiento

por BD

1 12 4,14 € 49,68

€

174.128,4 $

3 Google

Play

Store

Darse de alta como

desarrollador de

aplicaciones y

poderlas publicar

en la tienda.

1 - - 25

US$

74.650 $

4 Soporte

técnico

Soporte técnico de

azure por un año

1 - - 0 0$

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.

34

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ó

n

Fuente de

financiación

Valor

/ hora

Horas/

mes

Valor/ mes Meses Total

Univer

sidad

Estud

iante

Sonia

Pinzón

Director

de

Tesis

X 40.000

$

38 1´520.000$ 6 9´120.000$

Ana Cruz Analista Desarro

llo

X 13.600

$

160 2´176.000

$

6 13´056.000$

John

Vasquez

Analista Desarro

llo

X 13.600

$

160 2´176.000

$

6 13´056.000$

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 /

hora

Horas/

mes

Valor/ mes Meses Total

Ingeniero

experto en

aplicacion

es en la

nube

Desplegar y dar

soporte a las

aplicaciones y

bases de datos

en la nube

11.000$ 160 1’760.000$ 12 21’120.000$

TOTAL 21’120.000$


35

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).

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 roles

En este módulo el usuario 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 registro y acceso

Proceso iniciar sesión

Proceso por el cual el usuario accede a la aplicación web o la aplicación móvil.

proceso registrar usuario

Proceso por el cual un usuario se registra 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 huecos

Proceso registrar hueco

Proceso por el cual un usuario registra un hueco, con sus coordenadas, tamaño y una breve descripción.

Proceso consultar hueco

Proceso por el cual un usuario puede ver en detalle todos los datos más relevantes de un hueco.

Proceso editar hueco

Proceso por el cual el usuario edita los datos de un hueco, datos tales como tipo de hueco o la descripción de este.

Proceso eliminar hueco

Proceso por el cual el usuario administrador puede eliminar un hueco, eliminando con este el historial del hueco.

Proceso ver mapa

Proceso por el cual el usuario puede ver los huecos en un mapa representados por markers de colores según el tamaño del hueco.

Módulo de administra

Proceso modificar rol

Proceso por el cual el usuario administrador

ción de roles

Módulo de reportes

Proceso generar reporte de huecos por usuario

Proceso por el cual el usuario administrador genera un reporte con el historial de los huecos filtrado por cada usuario.

Proceso generar reporte de huecos general

Proceso por el cual el usuario administrador genera un reporte son el historial de los huecos.


2.3.1 Modelo de procesos módulo de registro y acceso

Ilustración 3. Diagrama de proceso iniciar sesión

Fuente Elaboración propia y Formulación propia

act [Activ ity] Iniciar sesion [diagrama iniciar se...

Datos

validos

Iniciar sesión

Final

Ingresar usuario y

contraseña

NO

SI

Buscar usuario y

contraseña

Inicio iniciar

sesión

comparar contraseña

la

contraseña

es la del

usuario

NO

SI

Existe

usuario

NO

Ilustración 4. Diagrama de proceso registrar usuario


act [Activ ity] registrar usuario [diagram...

Inicio registrar

usuario

Opción registrar usuario

Datos

validos

Crear usuario

Final

SI

NO

Ingresar datos del usuario

2.3.2 Modelo de procesos módulo de huecos

Ilustración 5. Diagrama de proceso registrar hueco


act [Activ ity] registrar hueco [diagrama registra...

Inicio registrar

hueco

Datos

correctos

Opción crear hueco

Datos

validos

Crear hueco

Final

SI

Iniciar sesión

NO

NO

SI

Ingresar datos del hueco

Ilustración 6. Diagrama de proceso consultar hueco Fuente Elaboración propia y Formulación propia

act [Activ ity] Consultar hueco [diagrama consul...

Inicio

consultar

hueco

Datos

correctos

Opción consultar hueco

Mostrar detalles del hueco

Final

Iniciar sesión

NO

SI

Seleccionar hueco

Cargar mapa de huecos

Opción acciones hueco

buscar y cargar hueco de

la base

Ilustración 7. Diagrama de proceso editar hueco Fuente Elaboración propia y Formulación propia

act [Activ ity] Editar hueco [diagrama editar huec...

Datos

correctos

Opción editar hueco

Editar hueco

Final

Iniciar sesión

NO

SI

Seleccionar hueco



Inicio

editar

hueco

Ingresar datos del hueco

Datos

validos

NO

SI

Ilustración 8. Diagrama de proceso eliminar hueco Fuente Elaboración propia y Formulación propia

act [Activ ity] Eliminar hueco [diagrama elimi...

Datos

correctos

Opción eliminar hueco

Mostrar detalles del hueco

Final

Iniciar sesión

NO

SI

Seleccionar hueco



Inicio

eliminar

hueco

Eliminar hueco

Ilustración 9. Diagrama de proceso ver mapa Fuente Elaboración propia y Formulación propia

act [Activ ity] registrar usuari...

Inicio ver mapa

Opción v er mapa

Buscar lista de huecos

Final

mostrar los huecos en el

mapa

2.3.3 Modelo de procesos módulo de administración de roles.

Ilustración 10. Diagrama de proceso modificar rol Fuente Elaboración propia y Formulación propia

act [Activ ity] Modificar rol [diagrama modific...

Datos

correctos

Opción cambiar rol

Seleccionar rol

Final

Iniciar sesión

NO

SI

Seleccionar usuario

Opción usuario y roles

Inicio modificar rol

usuario

cambiar de rol

El usuario ya

tiene

asignado ese

rol

SI

NO

2.3.4 Modelo de procesos módulo de reportes.

Ilustración 11. Diagrama de proceso generar reporte de huecos por usuario


act [Activ ity] reportes generales [diagrama de...

Inicio generar

reportes de

usuario

Generar

reportes

generales

Buscar datos de los

huecos por usuario para

el reporte

Descargar

reporte

Cargar reporte

Final

NO

NO

SI

SI

Ilustración 12. Diagrama de proceso generar reporte de huecos general


act [Activ ity] reportes usuario [diagrama desc...

Inicio generar

reportes

generales

Generar

reportes

generales

Buscar datos del reporte

Descargar

reporte

Cargar reporte

Final

NO

NO

SI

SI

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.

Ilustración 13. Modelo del dominio huecapp


class Objetos del dominio

Modelo de clases del dominio de

la aplicacion web del proyecto

Huecapp

Hueco

Rol

UsuarioHistorial_Hueco

Tipo_HuecoTipo_Identificacion

Estado_Usuario1.. * * .. 11

111

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


Funcionalidad En sistema web y móvil los 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


Funcionalidad En sistema web y móvil los 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 previamente registrado.

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


Funcionalidad En sistema web y móvil los usuarios 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


Tabla 18 Requerimiento RF006 de módulo de administración de huecos


Funcionalidad En sistema web y móvil los usuarios 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 previamente registrado.

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 previamente registrado.

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 previamente registrado.

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

Ilustración 14. Diagrama general de casos de uso


uc Casos de uso principales

Sistema Huecapp

Generar reportes

generales

Caso de Uso de modo general

del Sistema Huecapp

Modificar rol

usuario

Usuario Web

Usuario Mov il

Usuario Administrador

Web

Consultar hueco

Registrar hueco

Editar hueco

Eliminar hueco

Ver mapa huecos

Generar reportes de

usuario

Registrar usuario

Iniciar sesión

3.3.1.2. Diagrama de caso de uso usuario móvil

Ilustración 15. Diagrama de caso de uso usuario móvil


3.3.1.3. Diagrama de caso de uso usuario web

Ilustración 16. Diagrama de caso de uso usuario web



Usuario Mov il

Consultar hueco

Registrar hueco

Editar hueco

Registrar usuario

Iniciar sesión«include»

«include»

«include»


Usuario Web

Consultar hueco

Registrar hueco

Editar hueco

Ver mapa huecos

Generar reportes de

usuario

Registrar usuario

Iniciar sesión

«include»

«include»

«include»

«extend»

«extend»

«include»

3.3.1.4. Diagrama de caso de uso usuario administrador web

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.


Generar reportes

generales

Modificar rol

usuario


Web

Consultar hueco

Registrar hueco

Editar hueco

Eliminar hueco

Ver mapa huecos

Generar reportes de

usuario

Registrar usuario

Iniciar sesión

«extend»

«extend»

«extend»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

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 un hueco (Marker) y se selecciona el link de “detalles”.

2 Busca en la base de datos la información del hueco según el idHueco.

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 opción consultar huecos.

2 Busca en la base de datos la información del 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.

Ilustración 18. Diagrama de secuencia inicio de sesión


sd Diagrama de secuencia

Modelo:

usuario.cs

Usuario Web,Usuario

Administrador Web

Vista:

Login.cshtml

Controlador:

Account.cs

Vista:

index.cshtml

Login(usuario)

Find(usuario);

return

usuario()

RedirectToLocal(returnUrl)

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.

Ilustración 19. Diagrama de colaboración editar hueco


sd Diagrama de colaboracion editar hueco


Web

Vista:

ActionMapaHueco.cshtml

Vista: Edit.cshtml

hueco historial_hueco

1. Seleccionar editar

hueco()

---------------------------->2. Edit(id)

--------->

3. BuscarHistorial()

<-------------------4. selecionarHueco()

<----------------

6. Edit(hueco)

5. View(hueco)

7. editarhueco()

<--------------------

8. View(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 Fuente Elaboración propia y Formulación propia

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.

Ilustración 21 Diagrama de análisis Fuente Elaboración propia y Formulación propia

analysis Diagrama de analisis

Usuario Web


Web

Usuario Mov il

Pagina web Huecapp

Pagina web Huecapp

Aplicacion movil android

Huecapp

Base de datos

Gestion de huecos,

creacion , edicion,

detalles e historial

Gestion de roles y

usuarios, gestion de

huecos,

configuraciones y

reportes historial

huecos

Gestion de huecos por

usuario, creacion,

edicion, detalles e

historial y gestion de

usuario, crear editar

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 Fuente Elaboración propia y Formulación propia

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

Ilustración 33. Modelo de interfaz General


ui Nav egacion General

Inicio

Acerca de

Huecos

Registrarse

Iniciar sesion

Mapa

Acciones huecos

Historial hueco Detalles hueco

«redirect» «redirect»

«redirect»

«navigate»

«navigate»

«navigate»

«navigate»«navigate»

«navigate»

Ilustración 34. Modelo de interfaz usuario administrador


ui Nav egacion Usuario administrador

Inicio

Acerca de

Huecos

Iniciar sesion

Mapa

Acciones huecos

Historial hueco

Detalles hueco

Editar hueco

Crear Hueco

Mis Huecos

Eliminar hueco

Configuracion

TipoHuecoEstado Usuario

Tipo identificacion

Usuarios

Usuarios y roles

Listado de Usuarios

«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

«redirect»

«redirect» «redirect»

«redirect»

«redirect»

«redirect»

«redirect»«redirect»«redirect»

«navigate»

«navigate» «navigate»

«navigate»

«navigate»

«navigate»

Ilustración 35. Modelo de interfaz usuario


ui Nav egacion Usuario Logueado

Inicio

Acerca de

Huecos

Iniciar sesion

Mapa

Acciones huecos

Historial hueco Detalles huecoEditar hueco

Crear Hueco

Mis Huecos

«redirect»

«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

«redirect»

«redirect»«redirect» «redirect»«redirect» «redirect»

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 Fuente Elaboración propia y Formulación propia

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 Dato

Descripción

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

Campo Tipo de Dato

Descripción

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 donde está ubicado el hueco.

HUE_ALTURA FLOAT Coordenada de altura donde está ubicado el 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

Campo Tipo de Dato

Descripción

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 donde está ubicado el usuario.

USU_LONGITUD FLOAT Coordenada de longitud donde está ubicado el usuario.

USU_ALTURA FLOAT Coordenada de altura donde está ubicado el 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

Campo Tipo de Dato

Descripción

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.

Ilustración 41. Diagrama de componentes


deployment Huecapp

Cliente web

Serv idor de aplicaciones web

Serv idor de base de datos

aplicacion

Android

Interfaz web

Internet Information

Serv ices (ISS)

SQL Serv er

Management

ASP .NET MVC

WEB APICliente mov il

Modulos

Módulo de reportes

Módulo de

administración de

roles

Módulo de huecos

Módulo de registro

y acceso

Entity Framework

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.

Ilustración 43. Diagrama de despliegue


deployment Huecapp

Ordenador

Telefono inteligente

Serv idor de aplicaciones web

Serv idor de base de datos

aplicacion Android

Nav egador Internet Information Serv ices

(ISS)

SQL Serv er ManagementASP .NET MVC

WEB API

«respuesta de accion»

«solicitud de accion»


«solicitud de accion»



«Solicitud de accion»

«Solicitud de accion»

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 OK

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 A PRUEBA

Resultado esperado Estado

RF002 Página de registro

Ingresar un usuario web al sistema y a la base de datos por medio de un formulario.

OK

RF001 Página de inicio de sesión (Login)

Permitir el ingreso al sistema si los datos de Usuario y de Contraseña existen y coinciden con algún registro en la base de datos.

OK

RF004 Vista de registro

Registrar un nuevo usuario al sistema con el perfil de visitante por defecto, este se ingresa a la base de datos del servidor por medio de un servicio

OK

RF003 Vista de editar usuario

Permitir al usuario modificar los datos de su cuenta enlazada, para ello tendrá que registrarse previamente

OK

Errores 1. Ninguna

Correcciones 1. Ninguna


Tabla 6 Prueba módulo de huecos

Prueba módulo de huecos


Ana María Cruz


Terminada SI

Concepto Inspeccionar el funcionamiento del módulo de huecos de la página web de huecapp

Perfil: Usuario web y Usuario administrador web



RF006 mapa huecos

Página mapa Mostrar los huecos existentes en un mapa.

OK

RF005 Página crear mapa

Permitir la creación de un hueco, el cual mostrara en la página mapa.

OK

RF006 Página mis huecos

Permite ver la lista de huecos que el usuario logueado ha modificado o creado

OK

RF007 Página editar hueco

Permite la edición de un hueco de forma exitosa, notificando con un mensaje que se modificó de manera exitosa

OK

Errores 2. Ninguna



Tabla 7 Prueba módulo de huecos móvil

Prueba módulo de huecos móvil


Ana María Cruz


Terminada SI

Concepto Inspeccionar el funcionamiento del módulo de huecos de la página web de huecapp

Perfil: Usuario móvil



RF006 mapa huecos

Vista mapa Mostrar los huecos existentes en un mapa.

OK

RF005 Dialogo para crear hueco

Permitir la creación de un hueco, el cual mostrara en la vista del mapa.

OK

RF006 Vista mis huecos

Permite ver la lista de huecos que el usuario logueado ha modificado o creado

OK

RF007 Página editar hueco

Permite la edición de un hueco cada vez quien un usuario se encuentre cerca del hueco de forma exitosa, notificando con un mensaje que se modificó de manera exitosa

OK

RF009 Notificación barra de Android, alerta de vibración

Permite al usuario por medio de una alerta de vibración y una notificación en la barra de Android enterar de cuando hay un bache cerca

OK

Errores 3. Ninguna



Tabla 8 Prueba módulo de reportes

Prueba módulo de reportes


Ana María Cruz


Terminada X

Concepto Inspeccionar el funcionamiento de reportes en la aplicación WEB

Perfil: Usuario web y Usuario administrador web



RF0012 Formularios de reportes

Ingresar un usuario web al sistema y a la base de datos por medio de un formulario.

OK

Errores 4. Ninguna



Tabla 9 Prueba módulo de algoritmo acercamiento

Prueba módulo de algoritmo acercamiento


Ana María Cruz


Terminada X

Concepto Inspeccionar el funcionamiento del algoritmo de acercamiento cuando se tiene un hueco cerca

Perfil: Usuario móvil



RF009

Vista de mapa

Cuando se acerca a una distancia prudencial, el móvil notifica a el usuario que se encuentra un módulo cerca del área

OK

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: https://developers.google.com/maps/documentation/android-api/infowindows?hl=es-419

Modificar opciones de camara y vista en Google Maps: https://developers.google.com/maps/documentation/android-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/map-geolocation?hl=es-419

Mapa sincrono JavaScript API de Google Maps: https://developers.google.com/maps/documentation/javascript/examples/map-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/ [Consultado: 11/Mayo/2017].

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 [Consultado: 10/Mayo/2017].

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.

Documents

APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES …repository.udistrital.edu.co/bitstream/11349/7506/9/VASQUEZ LEON... · APLICACIÓN DISTRIBUIDA PARA REPORTAR HUECOS VIALES BASADA