Post on 18-Aug-2020
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.
Fuente: Elaboración propia y Formulación propia
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.
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.
Í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
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.
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$
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.
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 $
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 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$
Fuente: Elaboración propia y Formulación propia
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).
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Cargar mapa de huecos
Opción acciones 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
Cargar mapa de huecos
Opción acciones 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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
Tabla 14 Requerimiento RF2 del módulo de administración de registro y acceso
Nombre de requerimiento RF 002
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
Fuente: Elaboración propia y Formulación propia
3.2.2 Requerimiento de módulo de administración de usuarios Tabla 15 Requerimiento RF3 del módulo de administración de usuarios
Nombre de requerimiento RF 003
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
Fuente: Elaboración propia y Formulación propia
Tabla 16 Requerimiento RF004 del módulo de administración de usuarios
Nombre de requerimiento RF 004
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
Fuente: Elaboración propia y Formulación propia
3.2.3 Requerimiento de módulo de administración de huecos Tabla 17 Requerimiento RF005 de módulo de administración de huecos
Nombre de requerimiento RF 005
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
Fuente: Elaboración propia y Formulación propia
Tabla 18 Requerimiento RF006 de módulo de administración de huecos
Nombre de requerimiento RF 006
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
Fuente: Elaboración propia y Formulación propia
Tabla 19 Requerimiento RF007 de módulo de administración de huecos
Nombre de requerimiento RF 007
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
Fuente: Elaboración propia y Formulación propia
Tabla 20 Requerimiento RF008 de módulo de administración de huecos
Nombre de requerimiento RF 008
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
Fuente: Elaboración propia y Formulación propia
Tabla 21 Requerimiento RF009 de módulo de administración de huecos
Nombre de requerimiento RF 09
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
Fuente: Elaboración propia y Formulación propia
Tabla 22 Requerimiento RF010 de módulo de administración de huecos
Nombre de requerimiento RF 010
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
Fuente: Elaboración propia y Formulación propia
3.2.4 Requerimiento de módulo de reportes
Tabla 23 Requerimiento RF012 de módulo de reportes
Nombre de requerimiento RF 012
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
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
3.3.1.3. Diagrama de caso de uso usuario web
Ilustración 16. Diagrama de caso de uso usuario web
Fuente Elaboración propia y Formulación propia
uc Casos de uso principales
Usuario Mov il
Consultar hueco
Registrar hueco
Editar hueco
Registrar usuario
Iniciar sesión«include»
«include»
«include»
uc Casos de uso principales
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
Fuente Elaboración propia y Formulación propia
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.
uc Casos de uso principales
Generar reportes
generales
Modificar rol
usuario
Usuario Administrador
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
Fuente: Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
sd Diagrama de colaboracion editar hueco
Usuario Administrador
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
Usuario Administrador
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
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
Tabla 34 Lista de clases de la capa servicios de la aplicación web
Capa Servicios
huecoServicioApi.cs
huecoApi.cs
usuarioApi.cs
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
Ilustración 23. Interfaz módulo de registro de usuario móvil
Fuente Elaboración propia y Formulación propia
1.1.3.2 Modelo de Interfaz módulo de huecos
Ilustración 24. Interfaz módulo de consultar un hueco móvil
Fuente Elaboración propia y Formulación propia
Ilustración 25. Interfaz módulo de consultar un hueco móvil
Fuente Elaboración propia y Formulación propia
Ilustración 26. Interfaz módulo de crear un hueco móvil
Fuente Elaboración propia y Formulación propia
Ilustración 27. Interfaz módulo de eliminar un hueco
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
5.1.3.3 Modelo de Interfaz módulo de usuarios
Ilustración 30. Interfaz módulo de consultar un usuario
Fuente Elaboración propia y Formulación propia
Ilustración 31. Interfaz módulo de editar un usuario
Fuente Elaboración propia y Formulación propia
5.1.3.4 Modelo de Interfaz módulo de reportes
Ilustración 32. Interfaz módulo de reportes historial por hueco
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
5.1.6. Modelo relacional
Ilustración 38. Modelo entidad relación
Fuente Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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.
Fuente: Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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
Fuente Elaboración propia y Formulación propia
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»
«respuesta de accion»
«solicitud de accion»
«respuesta de accion»
«respuesta 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
Fuente: Elaboración propia y Formulación propia
Tabla 6 Prueba módulo de huecos
Prueba módulo de huecos
Dirigida por: Asistente: Estado
Ana María Cruz
John Henry Vásquez Proceso OK
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
ACCION ELEMENTO A PRUEBA
Resultado esperado Estado
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
Correcciones 2. Ninguna
Fuente: Elaboración propia y Formulación propia
Tabla 7 Prueba módulo de huecos móvil
Prueba módulo de huecos móvil
Dirigida por: Asistente: Estado
Ana María Cruz
John Henry Vásquez Proceso OK
Terminada SI
Concepto Inspeccionar el funcionamiento del módulo de huecos de la página web de huecapp
Perfil: Usuario móvil
ACCION ELEMENTO A PRUEBA
Resultado esperado Estado
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
Correcciones 3. Ninguna
Fuente: Elaboración propia y Formulación propia
Tabla 8 Prueba módulo de reportes
Prueba módulo de reportes
Dirigida por: Asistente: Estado
Ana María Cruz
John Henry Vásquez Proceso OK
Terminada X
Concepto Inspeccionar el funcionamiento de reportes en la aplicación WEB
Perfil: Usuario web y Usuario administrador web
ACCION ELEMENTO A PRUEBA
Resultado esperado Estado
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
Correcciones 4. Ninguna
Fuente: Elaboración propia y Formulación propia
Tabla 9 Prueba módulo de algoritmo acercamiento
Prueba módulo de algoritmo acercamiento
Dirigida por: Asistente: Estado
Ana María Cruz
John Henry Vásquez Proceso OK
Terminada X
Concepto Inspeccionar el funcionamiento del algoritmo de acercamiento cuando se tiene un hueco cerca
Perfil: Usuario móvil
ACCION ELEMENTO A PRUEBA
Resultado esperado Estado
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
Correcciones 5. Ninguna
Fuente: Elaboración propia y Formulación propia
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.