Aplicación distribuida para reportar huecos viales basada en coordenadas de posicionamiento global (GPS)

Texto completo

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

(2) 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. 3.

(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.. 4.

(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. 5.

(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. 1.9.. Fases del RUP ................................................................................................. 26. FACTIBILIDAD ........................................................................................................ 29. 1.9.1.. Factibilidad Técnica ............................................................................................. 29. 1.9.2.. Factibilidad Operativa .......................................................................................... 30. 1.9.3.. Factibilidad Económica ........................................................................................ 31 6.

(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. 2.. Factibilidad Legal ................................................................................................. 35. 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. 3.. 2.3.. MODELO DEL DOMINO ......................................................................................... 49. 2.4.. GLOSARIO DE TÉRMINOS.................................................................................... 50. 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 4.. Ficha de caso de uso consultar hueco ............................................................. 64. FASE DE ANÁLISIS...................................................................................................... 65 4.1.. DIAGRAMAS DE SECUENCIA ............................................................................... 65 7.

(8) 5.. 4.2.. DIAGRAMAS DE COLABORACIÓN ....................................................................... 66. 4.3.. DIAGRAMAS DE ACTIVIDAD................................................................................. 67. 4.4.. DIAGRAMAS DE ANÁLISIS.................................................................................... 68. 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. 5.1.2.. Lista de clases aplicación móvil ........................................................................ 70 Responsabilidad de clases .................................................................................. 71. 5.1.2.1. 5.1.3.. Responsabilidad de clases aplicación web....................................................... 71 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. 5.1.5.. 6.. 7.. Mapa de navegación aplicación web ................................................................ 80 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. 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. FASE DE PRUEBAS..................................................................................................... 95 7.1 PRUEBAS DE SISTEMA DE INTERACCIÓN ............................................................ 95. RECOMENDACIONES ...................................................................................................... 100 CONCLUSIONES ............................................................................................................... 101 BIBLIOGRAFIA .................................................................................................................. 102 REFERENCIAS .................................................................................................................. 104 INFOGRAFIA ..................................................................................................................... 105 ANEXOS ............................................................................................................................ 106 8.

(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. 9.

(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 10.

(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. 11.

(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.. 12.

(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.. 13.

(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. 14.

(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. 15.

(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.. 16.

(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.. 17.

(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. 18.

(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. 19.

(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. 20.

(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 (clientemiddleware-servidor) y multinivel. (Kurose & Ross, 20014) MULTIPLATAFORMA: Multiplataforma es un atributo conferido a programas informáticos o métodos y conceptos de cómputo que son implementados e interoperan en múltiples plataformas informáticas. Las plataformas de software pueden ser un sistema operativo o entorno de programación, aunque más comúnmente se trata de una combinación de ambos Para que el software pueda ser considerado multiplataforma, debe ser capaz de funcionar en más de una arquitectura de ordenador o sistema operativo. Esto puede ser una tarea que consume tiempo, ya que los diferentes sistemas operativos tienen diferentes interfaces de programación de aplicaciones o API. (EcuRed, 2016).. 21.

(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. 22.

(23) 1. 2. 3.. 4.. 5.. Interacción de los componentes. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control que se sigue generalmente es el siguiente: El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) 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. 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. 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. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.... SQLSERVER: SQL Server es un sistema de gestión de bases de datos relacionales (RDBMS) de Microsoft que está diseñado para el entorno empresarial. SQL Server se ejecuta en T-SQL (Transact -SQL), un conjunto de extensiones de programación de Sybase y Microsoft que añaden varias características a SQL estándar, incluyendo control de transacciones, excepción y manejo de errores, procesamiento fila, así como variables declaradas. (Rouse, 2016). ASP.NET: Es un modelo de desarrollo Web unificado que incluye los servicios necesarios para crear aplicaciones Web empresariales con el código mínimo. ASP.NET forma parte de .NET Framework y al codificar las aplicaciones ASP.NET tiene acceso a las clases en .NET Framework. El código de las aplicaciones puede escribirse en cualquier lenguaje compatible con el Common Language Runtime (CLR), entre ellos Microsoft Visual Basic, C#, JScript .NET y J#. Estos lenguajes permiten desarrollar aplicaciones 23.

(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 24.

(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. 25.

(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 miniproyectos, cada uno de estos va a ser una iteración. Las iteraciones hacen que referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Vida del proceso unificado: El proceso unificado consiste en una serie de ciclos que constituyen la vida de un sistema. Al final de cada ciclo se obtiene una versión del producto. Las fases de cada ciclo son: a. Inicio: Describe el producto final. b. Elaboración: Especifica en detalle la mayoría de los casos de uso y diseña la arquitectura del sistema. c. Construcción: Construye el producto cubriendo todos los casos de uso. d. Transición: El producto existe en versión beta y unos usuarios experimentan con el producto. 1.8.3.1.. Fases del RUP.  Modelamiento Del Negocio: En este flujo se describen los diferentes procesos del sistema y primer acercamiento a la arquitectura del sistema.  Requisitos: Es el flujo de trabajo que busca establecer las características que debe cumplir el sistema y los recursos necesarios para su montaje.  Análisis y Diseño: Es el flujo de trabajo que nos permite obtener una visión abstracta del sistema, nos da una visión global del sistema.  Implementación: Tiene en cuenta el desarrollo de software, pruebas unitarias e integración.  Pruebas: Describe casos de prueba, procedimientos de prueba y métricas de seguimiento de defectos.  Despliegue: Cubre la configuración del sistema.. 26.

(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. REQUISITOS. Descripción Permite generalizar los requisitos, como "necesidades", y para conocer éstas tenemos que comprender con mayor amplitud el modelamiento del negocio y el entorno en. 27. Actividades 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) ANALISIS. 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. 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.. 28.  Modelo de casos de uso.. 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.. Durante la Modelo de implementación implementación: IMPLEMENTACIÓN empezamos con el  Componente resultado del diseño e  Interfaz implementamos el sistema en términos de componentes, es decir, ficheros de código fuente, scripts, ejecutables y similares. En esta fase verificamos  Modelo de pruebas. el resultado de la  Evaluación de prueba.  Pruebas individuales. implementación PRUEBAS  Pruebas del sistema. probando cada construcción, incluyendo tanto construcciones internas como intermedias, así como las versiones finales del sistema. Fuente: Elaboración propia y Formulación propia. 1.9.. FACTIBILIDAD. 1.9.1. Factibilidad Técnica 1.9.1.1. Factibilidad técnica en el desarrollo Las herramientas utilizadas en el desarrollo del sistema han sido adquiridas por los desarrolladores, algunas de forma libre, las cuales se mencionan a continuación: 29.

(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 Director de Tesis. Funciones Responsable de supervisar y asesorar la elaboración del proyecto. Validación de requisitos, especificación, y captura de datos, Analistas y Desarrolladores interactuando con el grupo de trabajo de la universidad, mediante entrevistas, y documentación que ellos suministren. Elaboración del modelo de análisis y diseño. Planear, diseñar y evaluar las pruebas. Fuente: Elaboración propia y Formulación propia. 30.

(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. Ítem Descripc CantDuración Fuente de Recurso Costo Costo ión meses financiació variable fijo n Valor / Uni Estu Prop Comprar Mes v io o alquiler del servicio 1 Computa 2 6 X X 0 1’600.000 dor $ 3 Servicios 2 6 X X 30.000$ de Luz 4 Impresio 1 6 X X 40000$ nes y Papelerí a 5 Visitas a 2 6 X X 40.000$ la Universid ad 6 Otros 2 6 X X 35.000$ TOTAL. Total. $ 3´200.000 $ 360.000 $ 40.000. $ 480.000. $ 420.000 $4.500.00 0. Fuente: Elaboración propia y Formulación propia. 1.9.3.1.2.. Recursos físicos en la implementación de la aplicación. Debido a que la implementación de la aplicación web y la aplicación móvil se hará en la nube no se contará con recursos físicos.. 31.

(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 0. Valor. 1. Licencia servidor web IIS Express. 2. gratuita. 2. Licencia SQLSERVER Express. Licencia MySQL Workbench 5.2 OS. 2. gratuita. 0. 0. 2. gratuita. 0. 0. Licencia Visual Pardigm for UML Licencia Visual Studio Express. 2. gratuita. 0. 0. 2. gratuita. 0. 0. 3. 4 5. TOTAL. 0. $0.0. Fuente: Elaboración propia y Formulación propia 1.9.3.2.2. Recursos de Software en la implementación de la aplicación Se utilizará Microsoft Azure que permite implementar infraestructuras y servicios con rapidez. Puede ejecutar aplicaciones basadas en Windows y Linux. En la siguiente tabla se mostrará los recursos de Software que se necesitaran por un año de implementación de la aplicación.. 32.

(33) Tabla 5 Recursos de software en la implementación de la aplicación por un año.. Ítem. 1. Recurso Descripción. Cant Meses. Valor. Valor precio en pesos 555,6 1´947.378 $ €. Región: Oeste de EE.UU Nivel: Básico. Instancia: 1vCPU, 1.75GB de RAM, 10GB Storage Base de Región: Oeste de datos EE.UU SQL Nivel: Básico. Tipo: Base de datos única. Nivel de rendimiento : 2GB incluido almacenamiento por BD Google Darse de alta como Play desarrollador de Store aplicaciones y poderlas publicar en la tienda.. 1. 12. 46,30 €. 1. 12. 4,14 € 49,68 174.128,4 $ €. 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).. -. -. -. -. -. 2. 3. APP Service. Valor /mes. TOTAL. 2´196.156,4$ Fuente: Elaboración propia y Formulación propia. Precio del euro noviembre 28 del 2017: 3,505 pesos colombianos. Precio del dólar noviembre 28 del 2017: 2,986 pesos colombianos. 33.

(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. Sonia Pinzón. Director de Tesis Analista Desarro llo Analista Desarro llo. Ana Cruz. John Vasquez. Fuente de Valor Horas/ financiación / hora mes Univer Estud sidad iante X 40.000 38 $. Valor/ mes Meses. Total. 1´520.000$ 6. 9´120.000$. X. 13.600 $. 160. 2´176.000 6 $. 13´056.000$. X. 13.600 $. 160. 2´176.000 6 $. 13´056.000$. TOTAL. 35´232.000 $. Fuente: Elaboración propia y Formulación propia 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. Ingeniero experto en aplicacion es en la nube TOTAL. Función. Valor / hora. Desplegar y dar 11.000$ soporte a las aplicaciones y bases de datos en la nube. Horas/ mes. Valor/ mes. Meses. 160. 1’760.000$. 12. Total. 21’120.000$. 21’120.000$. Fuente: Elaboración propia y Formulación propia 34.

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

(36) 1.10 Cronograma de Actividades.. Ilustración 2 cronograma de actividades Fuente Elaboración propia y Formulación propia.

(37) 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 Módulo de registro y acceso. Descripción Este módulo permite a los usuarios registrarse para poder interactuar con el sistema, además de autentificar para poder acceder como un usuario del sistema y así poder ver, crear y modificar huecos. Módulo de huecos En este módulo un usuario independientemente del rol podrá crear, modificar y ver la información de un hueco, poder ver los huecos que el usuario ha creado o modificado, además si se tiene el rol administrador se podrá eliminar huecos Módulo de administración de En este módulo el usuario roles autenticado con el rol de administrador podrá ver y cambiar el rol que tenga otro usuario. Módulo de reportes En este módulo el usuario autenticado podrá generar reportes del historial de huecos que ha creado o modificado, así mismo un.