Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Facultad de Ingeniería de Sistemas y Electrónica
Carrera de Ingeniería de Sistemas e Informática
Trabajo de Suficiencia Profesional:
“Desarrollo de un Sistema de Monitoreo y Gestión de Incidencias en Tiempo real para la Compañía de
Bomberos de Arequipa”
Bachilleres:
Marco Antonio Medina DávalosFerly Romel Lazo ZúñigaJosé Rafael Yeren Morón
Para optar el Título Profesional de Ingeniero de Sistemas e Informática
Arequipa – Perú
2017
AGRADECIMIENTOS
A dios, a mis padres Federico y Gaby por estar conmigo, por apoyarme, guiarme y por ser la base de mis valores. Agradecer también a todas las personas que de una u otra manera aportaron un granito de arena para poder cumplir esta gran meta.Marco Antonio Medina Dávalos.
A dios, a mis padres Rafael y Elizabeth que me han brindado todo el apoyo necesario para poder culminar esta etapa de mi vida, por ello les doy gracias ya que con su esfuerzo y el mío ahora puedo ser un gran profesional y seré un gran orgullo para ellos.José Rafael Yeren Morón
A Dios. Por haberme permitido llegar hasta este punto y haberme dado salud para lograr mis objetivos, además de su infinita bondad y amor. A mi Madre Virginia Zúñiga A. por su amor incondicional y en especial a mi Esposa Guísella Liz e Hija Emily Luciana por ser fuentes de inspiración en cada día de mi vida.Ferly Romel Lazo Zúñiga
RESUMEN
El presente proyecto está basado en el desarrollo de una solución Web y Móvil
cuyo objetivo es proveer a la ciudadanía una herramienta que permita reportar
incidencias en el momento que estas ocurran, tales como: Emergencias, Incendios,
Rescates y otros para que puedan ser atendidos por la central de Bomberos de
Arequipa; es así como nace Nuestro proyecto “Sistema de Monitoreo y Gestión de
incidencias en tiempo real para la compañía de Bomberos de Arequipa”.
Nuestro aplicativo móvil permitirá involucrar a la ciudadanía con la central de
Bomberos, permitiendo capturar la posición geográfica de una manera precisa
empleando el módulo GPS disponible en el dispositivo móvil.
Nuestro aplicativo web permitirá recibir y mostrar incidencias reportadas por la
ciudadanía en una cola de incidencias así mismo permitirá graficar y mostrar las
incidencias en un mapa digital, para tener una referencia exacta del lugar de la
incidencia. Alternativamente dispondrá de la opción para mostrar la descripción y
fotografías que pueda tener adjunta dicho reporte recibido. La metodología usada en el
presente proyecto es una metodología en Cascada la cual estará compuesta por cuatro
actividades principales:
En la primer actividad se establece el dialogo entre un representante de la
compañía de bomberos y el grupo de trabajo para identificar los procesos e información
importante que se requiere para el desarrollo del presente proyecto.
En la segunda actividad se define el diseño de nuestra solución y los
procedimientos necesarios que aseguren una solución acorde a los requerimientos de la
central de la compañía de bomberos.
En la tercera actividad se realizara la implementación de la solución de software,
así mismo se plantearan estrategias de implementación como la recodificación,
programación en pareja e integración.
En la cuarta actividad el equipo de desarrollo verificara el correcto funcionamiento
de las Aplicaciones Web y Aplicaciones Móvil. Se realizaran pruebas para asegurar que
la codificación funciona según lo planeado.
PALABRAS CLAVES
Aplicación móvil, aplicación web, Backend, Android, geolocalización, incidentes,
atenciones e informante.
ABSTRACT
The present project is based on the development of a Web and Mobile solution
whose objective is to provide citizens with a tool that allows reporting incidents at the
moment they occur such as: Emergencies, Fire, Rescue and others so that they can be
attended by the Arequipa Fire Department; This is how Our project "Real-time incident
monitoring and management system for the fire company in Arequipa" was born.
Our mobile application will allow citizens to be involved with the Fire Department,
allowing to capture the geographical position in a precise way using the GPS module
available on the mobile device.
Our web application will allow you to receive and display incidents reported by the
citizens in a queue of incidents. It will also allow you to graph and show the incidents in a
digital map, to have an exact reference of the place of incidence. Alternatively you will
have the option to display the description and photographs that may have attached the
received report. The methodology used in this project is a methodology in Cascada which
will be composed of four main activities:
The first activity establishes the dialogue between a representative of the fire
company and the working group to identify the processes and important information that
is required for the development of this project.
The second activity defines the design of our solution and the necessary
procedures to ensure a solution according to the requirements of the fire company's
plant.
In the third activity, the implementation of the software solution will be carried out,
as well as implementation strategies such as recoding, pair programming and integration.
In the fourth activity the development team will verify the correct functioning of the
web and mobile applications. Tests will be conducted to ensure that the coding works as
planned.
KEYWORD
Mobile Application, web application, backend, Android, geolocation, incidents, attentions
and informant.
ÍNDICE DE CONTENIDO
AGRADECIMIENTOS...................................................................................................................3
1. CAPITULO I: Introducción................................................................................................13
1.1. Planteamiento del Problema....................................................................................14
1.2. Justificación.................................................................................................................14
1.2.1. Justificación Funcional.....................................................................................14
1.2.2. Justificación Técnica.........................................................................................15
1.3. Objetivos.......................................................................................................................18
1.3.1. Objetivo General.................................................................................................18
1.3.2. Objetivos Específicos........................................................................................18
1.4. Alcances y limitaciones............................................................................................19
2. CAPITULO II: Marco Teórico............................................................................................22
3. CAPITULO III: Propuesta De Aplicación Profesional.................................................27
3.1. Descripción de la propuesta....................................................................................27
3.2. Recursos.......................................................................................................................28
3.2.1. Personal................................................................................................................28
3.2.2. Hardware y Software..........................................................................................29
3.3. Estimación....................................................................................................................30
3.4. Planificación................................................................................................................38
4. CAPITULO IV: Metodología de desarrollo del proyecto............................................40
5. CAPITULO V: Análisis y Diseño......................................................................................44
5.1. Análisis de Negocio...................................................................................................44
5.1.1. Diagrama de flujo de incidentes......................................................................44
5.2. Análisis del Sistema...................................................................................................45
5.2.1. Diagrama de Casos de Uso..............................................................................45
5.2.2. Especificación de los casos de uso...............................................................46
5.2.3. Diagrama de Clases...........................................................................................55
5.2.4. Diagramas de Secuencia..................................................................................56
5.2.5. Especificación de Requerimientos.................................................................62
5.2.5.1. Requerimientos funcionales....................................................................62
5.2.5.2. Requerimientos no funcionales..............................................................78
5.2.6. Arquitectura del Sistema..................................................................................81
5.2.7. Diseño de interfaces..........................................................................................82
5.2.8. Diagrama Entidad Relación..............................................................................88
5.2.9. Diseño de Base de Datos..................................................................................89
5.2.9.1. Modelo Lógico.............................................................................................89
5.2.9.2. Modelo Físico...............................................................................................90
5.2.10. Diccionario de Datos......................................................................................91
6. CAPITULO VI: Aseguramiento de la calidad................................................................95
6.1. Plan de Pruebas..........................................................................................................95
6.2. Cheklist de pruebas.................................................................................................104
7. CAPITULO VII: Resultados.............................................................................................108
7.1. Encuestas de satisfacción.....................................................................................108
7.2. Cuadros estadísticos...............................................................................................113
8. CAPITULO VIII: Conclusión, Recomendaciones y Referencias Bibliográficas. 124
8.1. Conclusiones.................................................................................................................124
8.2. Recomendaciones........................................................................................................124
8.3. Referencias Bibliográficas.........................................................................................126
8.4. Glosario...........................................................................................................................128
ANEXOS......................................................................................................................................130
|
ÍNDICE DE TABLAS
TABLA 1. TABLA EXPERIENCIA PERSONAL 1...............................................................28TABLA 2. TABLA EXPERIENCIA PERSONAL 2...............................................................28TABLA 3. TABLA EXPERIENCIA PERSONAL 3...............................................................29TABLA 4. TABLA COSTOS DE RECURSOS....................................................................30TABLA 5. TABLA TÉCNICA PUNTOS CASOS DE USO..................................................32TABLA 6. TABLA ACTORES TÉCNICA PUNTOS CASOS DE USO................................33TABLA 7. TABLA PESO DE ACTORES TÉCNICA PUNTOS CASOS DE USO...............34TABLA 8. TABLA PESO DE CASOS DE USO TÉCNICA PUNTOS CASOS DE USO.....34TABLA 9. TABLA FACTORES TÉCNICOS PUNTOS CASOS DE USO...........................35TABLA 10. TABLA FACTORES AMBIENTALES PUNTOS CASOS DE USO..................36TABLA 8. CUADRO COMPARATIVO DE METODOLOGÍAS...........................................41TABLA 12 - CASO DE USO REGISTRAR INFORMANTE................................................47TABLA 13 - CASO DE USO REGISTRAR INCIDENTE....................................................49TABLA 14 - CASO DE USO AGRUPAR INCIDENTES.....................................................50TABLA 15 - CASO DE USO GESTIONAR INCIDENTES.................................................51TABLA 16 - CASO DE USO MONITOREAR INCIDENTES GESTIONADOS...................51TABLA 17 - CASO DE USO GESTIONAR DATOS DEL USUARIO MÓVIL.....................52TABLA 18 - CASO DE USO GESTIONAR DATOS DEL USUARIO WEB........................54TABLA 19 - CASO DE USO GENERAR REPORTES DE INCIDENTES..........................54TABLA 20 - REQUISITO FUNCIONAL: REGISTRO DE INFORMANTE..........................62TABLA 21 - REQUISITO FUNCIONAL: REGISTRO DE EMPLEADOS............................63TABLA 22 - REQUISITO FUNCIONAL: REGISTRO DE USUARIOS...............................64TABLA 23 - REQUISITO FUNCIONAL: ENVIO DE INCIDENTE......................................64TABLA 24 - REQUISITO FUNCIONAL: OBTENER UBICACIÓN......................................65TABLA 25 - REQUISITO FUNCIONAL: CAPTURAR FOTOGRAFÍA................................66TABLA 26 - REQUISITO FUNCIONAL: REDIMENSIONAR FOTOGRAFÍA.....................66TABLA 27 - REQUISITO FUNCIONAL: CONTROL DE ACCESO WEB...........................67TABLA 28 - REQUISITO FUNCIONAL: MOSTRAR NOMBRE DEL USUARIO................68TABLA 29 - REQUISITO FUNCIONAL: MOSTRAR LISTA DE INCIDENTES..................69TABLA 30 - REQUISITO FUNCIONAL: MOSTRAR DETALLES DEL INCIDENTE..........69TABLA 31 - REQUISITO FUNCIONAL: GRAFICAR UBICACIÓN....................................70TABLA 32 - REQUISITO FUNCIONAL: AGRUPAR INCIDENTES..................................71TABLA 33 - REQUISITO FUNCIONAL: CREAR ATENCIÓN............................................71TABLA 34 - REQUISITO FUNCIONAL: MOSTRAR ATENCIONES CREADAS...............72TABLA 35 - REQUISITO FUNCIONAL: GESTIONAR ATENCIONES..............................73TABLA 36 - REQUISITO FUNCIONAL: MONITOREAR ATENCIONES...........................74TABLA 37 - REQUISITO FUNCIONAL: BLOQUEAR INFORMANTE...............................74TABLA 38 - REQUISITO FUNCIONAL: REGISTRAR ESTACIONES...............................75TABLA 39 - REQUISITO FUNCIONAL: REGISTRAR CATEGORÍA DE ATENCIÓN.......76TABLA 40 - REQUISITO FUNCIONAL: REGISTRAR CATEGORÍA DE INCIDENTE......76TABLA 41 - REQUISITO FUNCIONAL: REGISTRAR REGISTRAR ROLES....................77TABLA 42 - REQUISITO FUNCIONAL: REGISTRAR REGISTRAR ROLES....................78TABLA 43 - REQUISITO NO FUNCIONAL: REGISTRO DE INFORMANTE....................78TABLA 44 - REQUISITO NO FUNCIONAL: REGISTRO DE EMPLEADOS.....................79TABLA 45 - REQUISITO NO FUNCIONAL: REGISTRO DE USUARIOS.........................79
TABLA 46 - REQUISITO NO FUNCIONAL: ENVIO DE INCIDENTE................................80TABLA 47 - TABLA TABLA INFORMANTES.....................................................................91TABLA 48 - TABLA CATEGORIAINCIDENTE...................................................................91TABLA 49 - TABLA ROLES...............................................................................................91TABLA 50 - TABLA PERSONAL........................................................................................92TABLA 51 - TABLA CATEGORIAANTENCIONES............................................................92TABLA 52 - TABLA ESTACIONES....................................................................................93TABLA 53 - TABLA USUARIOS........................................................................................93TABLA 54 - TABLA INCIDENTES.....................................................................................94TABLA 55 - TABLA DETALLEATENCIONES....................................................................94TABLA 56 - TABLA ATENCIONES....................................................................................94TABLA 57 - PLAN DE PRUEBAS....................................................................................103
ÍNDICE DE FIGURAS
FIGURA 1. CRONOGRAMA DE ACTIVIDADES............................................................................38
FIGURA 2. DIAGRAMA CRONOGRAMA DE ACTIVIDADES........................................................39
FIGURA 3. DIAGRAMA DE FLUJO DE INCIDENTES...................................................................44
FIGURA 4. DIAGRAMA DE CASO DE USO GENERAL................................................................45
FIGURA 5. DIAGRAMA DE CLASES.............................................................................................55
FIGURA 9. DIAGRAMA REGISTRAR INFORMANTE...................................................................56
FIGURA 10. DIAGRAMA REGISTRAR INCIDENTE......................................................................57
FIGURA 11. DIAGRAMA ACCESO APLICATIVO WEB.................................................................58
FIGURA 12. DIAGRAMA GESTIONAR INFORMANTE.................................................................59
FIGURA 13. DIAGRAMA GESTIONAR USUARIO WEB...............................................................60
FIGURA 14. DIAGRAMA GENERAR REPORTE DE INCIDENTE.................................................61
FIGURA 15. DIAGRAMA DE ARQUITECTURA DEL SISTEMA....................................................81
FIGURA 16. LOGIN DEL SISTEMA DE GESTIÓN Y CONTROL DE ALERTAS...........................82
FIGURA 17. PÁGINA DE INICIO....................................................................................................82
FIGURA 18. PÁGINA DE ORGANIZACIÓN DE INCIDENTES......................................................83
FIGURA 19. AGRUPACIÓN Y CATEGORIZACIÓN DE INCIDENTES REPETIDOS....................83
FIGURA 20. PÁGINA DE CREACIÓN DE ATENCIÓN INCIDENTE..............................................84
FIGURA 21. PÁGINA DE MONITOREO DE ATENCIONES GESTIONADAS...............................84
FIGURA 22.PANTALLA DE REGISTRO DE APLICATIVO MÓVIL................................................85
FIGURA 23. PANTALLA DE MENÚ DE APLICATIVO MÓVIL.......................................................86
FIGURA 24. PANTALLA DE ENVÍO DE INCIDENTE EN APLICATIVO MÓVIL............................87
FIGURA 25. DIAGRAMA DE ENTIDAD RELACIÓN......................................................................88
FIGURA 26. MODELO LÓGICO DE BASE DE DATOS.................................................................89
FIGURA 27. MODELO FÍSICO DE BASE DE DATOS...................................................................90
FIGURA 28. TABULACIÓN DE DATOS.......................................................................................113
FIGURA 29. RESULTADOS.........................................................................................................114
FIGURA 30. PREGUNTA 1..........................................................................................................115
FIGURA 31. PREGUNTA 2..........................................................................................................116
FIGURA 32. PREGUNTA 3..........................................................................................................117
FIGURA 33. PREGUNTA 4..........................................................................................................118
FIGURA 34. PREGUNTA 5..........................................................................................................119
FIGURA 35. PREGUNTA 6..........................................................................................................120
FIGURA 36. PREGUNTA 7..........................................................................................................121
FIGURA 37. PREGUNTA 8..........................................................................................................122
1. CAPITULO I: Introducción
Al día, la central telefónica del Cuerpo General de Bomberos en Arequipa recibe
1800 llamadas, de este número solo 40 son pedidos de auxilio para atender
emergencias reales.
El comandante departamental de la VII Comandancia de Bomberos Arequipa,
Brigadier CPC, Jorge Martínez Ríos, informó que mil 760 ciudadanos se comunican
con la línea 116 para jugar y mantener ocupada la línea en un promedio de dos
minutos, lo que impide que en muchos casos las llamadas urgentes sean atendidas.
(Correo, 2016)
A esta problemática adicionamos el hecho de que algunas emergencias
reportadas por los ciudadanos son falsas, perturbadoras, imposibles de localizar su
ubicación o no ameritan atención.
Con el objeto minimizar dichos inconvenientes mencionamos al inicio se plantea
diseñar y desarrollar una herramienta tecnológica compuesta por un Aplicativo Web y
un Aplicativo Móvil para dispositivos Android los cuales en conjunto permita a la
central de bomberos de Arequipa recibir las alertas en tiempo real, localización exacta
y la evidencia fotográfica del incidente reportado por el ciudadano, toda esta
información se mostrará directamente en el mapa digital de Google Map implementado
en el Aplicativo Web para su gestión, categorización y atención.
Así mismo la Central de Emergencia recibirá el número del cual se está
reportando el incidente a fin de poder comunicarse con el ciudadano y solicitar
mayores detalles si se requieren, también podrá bloquear el numero si se descubre
que el incidente reportado no es real.
Página 13 de 132
1.1. Planteamiento del Problema
En la actualidad la central de emergencias de la compañía de bomberos de
Arequipa no cuenta con recursos tecnológicos (software) para la recepción,
monitoreo, control y atención de incidentes en tiempo real tales como:
emergencias médicas, incendios y rescates. En este escenario surge la siguiente
interrogante que direcciona este proyecto. ¿Cómo facilitar la recepción de alertas,
localización exacta, gestión y atención oportuna de los incidentes reportados por
la ciudadanía a la central de emergencia de los bomberos?
1.2. Justificación
1.2.1. Justificación Funcional
El presente proyecto de desarrollado tiene como finalidad poder
brindar una herramienta tecnológica que conecte a los ciudadanos con la
compañía de bomberos de Arequipa con el objetivo alertar e informar de
situaciones de emergencia como: incendios, accidentes de tránsito y afines
a la labor de los bomberos, de esta forma permita reducir el tiempo de
respuesta ante cualquier tipo de incidente.
La herramienta tecnológica estará conformada por dos aplicativos:
un Aplicativo Web y un Aplicativo Móvil los cuales van a interactuar de
manera conjunta cumpliendo el fin propuesto.
Aplicativo Móvil: Permitirá al ciudadano registrarse y reportar los
incidentes que presencie en tiempo real, el Aplicativo Móvil enviará los
Página 14 de 132
datos del usuario, la evidencia fotográfica, una descripción y la ubicación
exacta desde donde se suscitó el incidente. Esta información se
almacenará en una base de datos para su posterior gestión.
Aplicativo Web: Permitirá mostrar información de los incidentes
reportados por los ciudadanos. Dichos incidentes serán gestionados y
organizados para su atención. Las atenciones serán gestionadas por el
usuario web el cual se encargará de categorizar, registrar y actualizar
dichas atenciones. Las atenciones serán mostradas en un mapa digital
para su seguimiento y monitoreo.
1.2.2. Justificación Técnica
El sistema que se propone en este proyecto es el desarrollo de un
Aplicativo Web y un Aplicativo móvil, ya que se cuenta con la necesidad de
tener la información disponible de los incidentes en cualquier punto donde
dichos incidentes se originen para su gestión y atención.
Equipo de Trabajo:
El equipo responsable de la elaboración de este sistema está
conformado de la siguiente manera:
3 Analistas/desarrolladores:
Los presentantes:
o Marco Antonio, Medina Dávalos
o Ferly Romel, Lazo Zúñiga
o José Rafael, Yeren Morón
Página 15 de 132
Realizarán tanto las veces de analistas como de desarrolladores.
1 Consultor:
El asesor del proyecto Franz Asmat Fuentes.
Los usuarios finales:
Usuarios internos (trabajadores de la Central de Emergencia de los
Bomberos) y usuarios externos (la ciudadanía).
Herramientas:
Diseño:
o Dia v 0.97.2
o Gantt Proyect v 2.8.4
o www.SQLdesigner v 2.7
Base de datos:
o Motor de base de datos Postgre SQL ver. 9.6.1
o IDE pgAdmin 4 v 1.1
o servidor Apache TOMCAT 9.
Backend:
o Lenguaje de Programación Java 8
o IDE Eclipse Neon2
o Framework Spring MVC Ver. 4.3.6
Página 16 de 132
o Framework Hibernate Ver. 5.2.7
Frontend:
o Web:
IDE Visual Code Ver. 1.9
Sencha Ext JS6
o Móvil:
Lenguaje de programación Java 8
IDE Android Studio v 2.3
El consumo de datos Móviles y ancho de banda es sumamente
importante y necesita ser controlado. REST es muy útil en dispositivos con
bajos recursos como teléfonos móviles y tablets.
También será necesario que la Central de emergencias cuente con
al menos un ordenador relativamente moderno (superior a Pentium 4) y
con conexión a internet.
Página 17 de 132
1.3. Objetivos
1.3.1. Objetivo General
Desarrollar un sistema para el envío, gestión y monitoreo de
incidentes en tiempo real reportados por parte de la ciudadanía a la
central de emergencias de los bomberos. El envío del incidente se
realizará empleando un Aplicativo Móvil para dispositivos Android. La
gestión y monitoreo de los incidentes reportados se realizarán mediante el
Aplicativo Web.
1.3.2. Objetivos Específicos
Diseñar e implementar la base de datos que de soporte el
almacenamiento de la información.
Diseñar e implementar Back-End de lado del servidor que permita
gestionar los servicios de sistema.
Diseñar e implementar un aplicativo para dispositivos móviles Android
que permita el registro del usuario y reporte de incidentes empleando la
conectividad móvil, la geolocalización y captura de imagen.
Diseñar e implementar un Aplicativo Web para para la gestión y
monitorización de incidentes.
Página 18 de 132
1.4. Alcances y limitaciones
Dentro del Alcance
Aplicativo Móvil:
Permitirá al ciudadano registrarse para poder realizar los reportes de
incidencias a la central de los bomberos.
Permitirá capturar la posición geográfica de una manera precisa
empleando el módulo GPS disponible en el dispositivo móvil.
Permitir al ciudadano digitar una breve descripción o especificación de la
incidencia que va reportar.
Permitir al ciudadano capturar una fotografía que servirán como evidencia
del incidente suscitado.
Permitir enviar el reporte de la incidencia con los datos recolectados de
forma fácil e intuitiva.
Aplicativo Web:
Permitirá recibir y mostrar las incidencias reportadas por la ciudadanía en
una cola de incidencias.
Permitirá mostrar en un mapa digital la ubicación exacta desde donde el
incidente se reporte, además permitirá mostrar la evidencia fotografía
enviada y capturada por el informante.
Permitirá organizar, agrupar y gestionar el estado de cada incidencia
recibida, con el objetivo de generar su atención y tener un mejor control de
las incidencias reportadas.
Página 19 de 132
Permitirá graficar y mostrar las atenciones en un mapa digital, para tener
una referencia exacta del lugar desde donde se reporten las incidencias.
Permitirá generar reportes de los incidentes atendidos por cada compañía
de bomberos por fecha y estados.
Permitirá gestionar el mantenimiento del sistema como: creación de
usuarios, categorías y compañías de bomberos.
Fuera del Alcance
Aplicativo Móvil:
No se publicará el aplicativo móvil en la tienda de Google Play.
La aplicación luego de enviar un incidente no recibirá ningún mensaje de
confirmación o del estado de su incidente reportado, ya que la central se
comunicará a través de una llamada telefónica de ser necesario la
confirmación o algún dato adicional.
Aplicativo Web:
No va a interactuar con algún otro sistema ya existente de la central de
emergencia de los bomberos.
No se baneará del sistema a los usuarios por el IMEI, el baneo se realizará
únicamente por el número telefónico.
Otros:
No se implementará la encriptación de datos, ya que la información con la
que el sistema trabaja no es una data sensible.
Página 20 de 132
No se implementará la gestión auditoría a nivel de base de datos, ya que el
proyecto tiene fines académicos.
No se implementará un menú de ayuda, debido al modo de presentación
del proyecto.
Página 21 de 132
2. CAPITULO II: Marco Teórico
Diagrama UML
“Lenguaje unificado de modelado (UML), es el sucesor de la oleada de métodos
de análisis orientados a objetos que surgió a finales de la década de 1980, UML
unifica sobre todo los métodos de Booch, Jacobson y Rumbaugh”. (Scott, 1999, pág.
1)
Aplicativo Web
“En ingeniería de software se denomina Aplicativo Web a los sistemas
informáticos que los usuarios pueden usar a través de una conexión de internet o
intranet empleando un navegador web”.
JSON
“Json (JavaScript object Notation) es una sintaxis para representar información no
es un programa ni un lenguaje de programación en particular, es solo una manera de
describir y estructurar datos que de forma eventual que podrá ser intercambiado entre
aplicaciones. Su sintaxis es totalmente independiente al lenguaje de programación y
consiste en pares nombre/valor y lista ordenada de valores (arrays)”. (Minera, 2011,
pág. 103)
Aplicaciones Móviles
“Son aplicaciones que se pueden descargar o instalar directamente en el
dispositivo móvil, realizan alguna o varias tareas específicas y cuentan con
repositorios en internet que permiten descargarlas de forma de gratuita o pagada”.
Página 22 de 132
Dispositivo Móvil
“Considerado como un pequeño dispositivo de cómputo o computadora de mano.
Los dispositivos móviles suelen venir con una pantalla táctil o no táctil y a veces,
incluso un mini teclado”. (Tommi, 2007)
Sistemas operativos actuales y más populares en el mercado
Android
Es un sistema operativo enfocado para dispositivos con pantalla táctil y
está basado en Linux, Android es el sistema operativo que tiene la mayor cuota
del mercado en Perú y a nivel internacional, la versión actual de Android es la
6.0.1 Marshmallow.
IOS
Sistema operativo para los dispositivos de Apple (iPhone, iPad) la
diferencia con Android es que solo es posible instalarse en dispositivos de las
mismas compañías y no de otros fabricantes de dispositivos móviles, IOS está
basado en el sistema operativo UNIX y la versión actual de IOS en el mercado es
la 10.2.
Backend y Frontend
“Backend es la parte del lado del servidor el cual se encarga de controlar la
seguridad, las autorizaciones y el procesamiento de datos. Frontend es la parte que
se ejecuta en el navegador del usuario final se encarga de mostrar la información de
una manera atractiva y comunicarse con el Backend para la creación de datos y
visualizarlos”. (Azaustre, 2014)
Página 23 de 132
Framework
“Framework es estructura real o conceptual destinada a servir de soporte o guía
para el desarrollo y/o implementación de una aplicación”.
Spring
“Spring cuenta con muchas aplicaciones de las diferentes tecnologías de código
abierto, las cuales se unifican bajo el nombre de Spring Framework. Cuando se trabaja
con este framework se pueden usar una gran cantidad de herramientas de código
abierto sin necesidad de escribir líneas y líneas de código y sin acoplamiento a
ninguna herramienta en particular. Se puede aplicar en cualquier desarrollo en java e
integrar con otro framework como Hibernate”. (Harrop, 2012, pág. 1)
Hibernate
“Hibernate permite la relación o mapeo de base de datos relacional a objetos, es
decir, es un ORM (Object Relational Mapping). Este framework es bastante utilizado
en la construcción de aplicaciones porque permite un mejor manejo de datos por
ejemplo en cuanto a las transacciones, a las relaciones entre objetos y adicionalmente
brinda una manera más limpia de establecer esta relación”. (Hibernate, 2017)
Base de Datos
“Una base de datos es un conjunto de datos relacionados entre sí, organizados y
estructurados, con información referente a algo. Podremos utilizar una base de datos
para cosas tan sencillas o tan complejas como llevar toda la gestión de una gran
empresa u organización”. (Garcia, 2017, pág. 2)
Apache Tomcat
Página 24 de 132
“El servidor de aplicaciones Tomcat de Apache y las tecnologías afines
proporcionan a los programadores de Java un completo conjunto de herramientas para
crear y desplegar de forma rápida sofisticadas aplicaciones web con alta seguridad”.
(Vivek Chopra, 2008, pág. 4)
Software Libre
“Según la Licencia Pública General, un software libre es aquel que tiene estas
cuatro libertades”: (Valcarcel, 2013, pág. 246)
La libertad de usar el programa, con cualquier propósito.
La libertad de estudiar cómo funciona el programa y adaptando a tus
necesidades.
La libertad de distribuir copias, con lo que puedes ayudar a tu vecino.
La libertad de mejorar el programa y hacer públicas las mejoras a los
demás, de modo que toda la comunidad se beneficie.
Patrón MVC
“Es una arquitectura de diseño de software en cual se separa los componentes de
una aplicación en tres niveles: interfaz de usuario, lógica de control y lógica de
negocios. El patrón MVC se enfoca en la creación de Aplicativo Web con flexibilidad
en la gestión de la base de datos y ordenamiento de la estructura de procesos”.
(Guevara, 2010)
Java
“Java es un lenguaje de programación orientada a objetos, es un lenguaje creado
para realizar una programación rápida y fácil. Su aprendizaje se facilita si ya se
poseen conocimientos previos de C++ y de programación orientada objetos”.
(Apolinario, 2013, pág. 37)
Página 25 de 132
API de Google Maps
“Las API de Google Maps representan a una colección de servicios las cuales
permiten incluir mapas, geo-codificación, lugares y otros contenidos de Google en sus
páginas web o aplicaciones”. (Google Maps APIs)
REST Web Services
“Es un estilo arquitectónico que especifica restricciones, como la interfaz uniforme,
que si se aplican a un servicio Web inducen propiedades deseables, como el
performance, la escalabilidad y la modificabilidad, que permiten que los servicios
funcionen mejor en la Web. En el resto del estilo arquitectónico, los datos y la
funcionalidad se consideran recursos y se accede a ellos usando identificadores de
recursos uniformes (URI), normalmente enlaces en la Web. Cabe indicar que REST no
es un estándar sino un estilo de arquitectura. Aunque REST no es un estándar, está
basado en estándares”. (Oracle, 2017)
Página 26 de 132
3. CAPITULO III: Propuesta De Aplicación Profesional
3.1. Descripción de la propuesta
Se propone el diseño e implementación de un sistema el cual estará compuesto
por un Aplicativo Web para la gestión y monitoreo en tiempo real de los incidentes
reportados a la central de emergencias de los bomberos, así mismo se desarrollará
un aplicativo móvil para dispositivos Android el cual se encargara del envío de los
reportes de incidentes capturados por la ciudadanía, empleando la conectividad móvil,
captura de imagen y la geolocalización. Se tiene como finalidad poder brindar una
herramienta tecnológica que conecte a los ciudadanos con la compañía de Bomberos
de Arequipa, con el objetivo de alertar e informar situaciones de emergencia como:
emergencias médicas, incendios y rescates. Permitirá reducir el tiempo de respuesta
ante cualquier tipo de incidente.
El sistema que se plantea fortalecerá el proceso de la gestión de incidentes que
en la actualidad se realiza a través de llamadas telefónicas. Este sistema será de gran
ayuda, ya que al incluir una fotografía y una ubicación exacta de los incidentes que se
reportan, la central de bomberos tendrá conocimiento de la realidad y veracidad del
incidente reportado.
Página 27 de 132
3.2. Recursos
3.2.1. Personal
Nombres y
apellidos
Marco Antonio Medina Dávalos
Empresa Computer Shops Corporation SRL
Rubro Venta de productos y servicios de Tecnologías de Información
Dirección Ampliación La Negrita C4-A 2do Piso, Región de Arequipa.
Teléfono correo electrónico [email protected]
Área Área de Tecnologías de Información Fecha inicio 2016
Actividad Supervisor de mantenimiento preventivo y correctivo de equipos
informáticos de la SUNARP.
Tabla 1. Tabla Experiencia Personal 1
Nombres y
apellidos
Ferly Romel Lazo Zúñiga
Empresa INGECOM PERU S.A.C
Rubro Telecomunicaciones
Dirección Urb. Quinta Tristán V1 Lt. F, J.L.B y R.
Teléfono (054)424431 correo electrónico [email protected]
Área Control y Sistemas Fecha inicio
2013
Actividad Administración de Servidores Linux, Mantenimiento de
Aplicación Agente de Comunicación del CCMF SUTRAN –
MTC, Administrador de Sistema de Rastreo – INGECOM GPS
Tabla 2. Tabla Experiencia Personal 2
Nombre y José Rafael Yeren Morón
Página 28 de 132
apellidos
Empresa Superintendencia Nacional De Los Registros Públicos
Rubro Institución Pública
Dirección Calle San Francisco 302 - Cercado
Teléfono (054) 21-5783 correo electrónico
Área Analista Informático Fecha inicio
2016
Actividad Soporte informático a sistemas registrales, solución de incidentes
y requerimientos informáticos relacionados a los aplicativos y
módulos registrales
Tabla 3. Tabla Experiencia Personal 3
3.2.2. Hardware y Software
Software Release Date Precio Soles
Dia v 0.97.2 2016 S/. 0.00
Gantt Proyect v 2.8.4 2017 S/. 0.00
wwwSQLdesigner v 2.7 2016 S/. 0.00
pgAdmin 4 v 1.1 2017 S/. 0.00
PostgreSQL Ver. 9.6.1 2016 S/. 0.00
IDE Eclipse Neon 2 2016 S/. 0.00
Apache TOMCAT 9 2017 S/. 0.00
Spring MVC Ver. 4.3.6 2017 S/. 0.00
Hibernate Ver. 5.2.7 2017 S/. 0.00
Página 29 de 132
Sencha Ext JS6 2015 S/. 0.00
Visual Code Ver. 1.9. 2017 S/. 0.00
Sencha Ext JS6 2017 S/. 0.00
Android Studio v 2.3 2017 S/. 0.00
Java Platform (JDK) 8u121 2017 S/. 0.00
Host DigitalOcean 2011 S/.200.00
TOTAL S/.200.00
Tabla 4. Tabla Costos de Recursos
3.3. Estimación
En la actualidad existen diversas técnicas que nos permiten estimar proyectos de
software. La técnica de estimación para el presente proyecto de Tesis será la
Metodología de Puntos de Casos de Uso (UCP) de Gustav Karner, esta técnica
permite realizar estimaciones a partir de modelos orientados a objetos con una alta
precisión.
La metodología de los puntos de casos de uso es una derivación de la
metodología de puntos de función propuesta por Albrecht. Karner basa su
metodología en la utilización de casos de uso como dato de entrada para calcular el
esfuerzo en horas hombre (hh) que son necesarias para el desarrollo de un proyecto
de software. El método de estimación del esfuerzo utiliza cuatro variables principales.
(Karner, 1993)
Página 30 de 132
Clasificación de los Actores Involucrados: “Los actores involucrados en los casos
de uso se clasifican de acuerdo a su característica intrínseca y la forma en que
interactúan con el sistema. Un actor simple (peso=1) es aquel que representa una
interfaz de programación o API (ej.: capa de abstracción); un actor medio (peso=2) es
aquel que interactúa mediante un protocolo (ej.: TCP/IP, HTTP, FTP) y un actor
complejo (peso=3) es aquel que interactúa por medio de una interfaz gráfica. A cada
actor de acuerdo a esta clasificación le corresponde un valor el cual se denomina
peso (El autor de la metodología no específica el origen de los pesos en ninguno de
los casos)”.
Clasificación de Caso de Uso: “Los casos de uso son clasificados de acuerdo a la
cantidad de transacciones que poseen, incluyendo las transacciones de escenarios
alternativos y excluyendo las extensiones o inclusiones de otros casos de uso. Un
caso de uso simple (peso=5) es aquel que posee 3 o menos transacciones; uno
medio (peso=10) es el que posee de 4 a 7 transacciones; y un caso de uso complejo
(peso=15) es el que posee más de 7 transacciones. Nuevamente, a cada caso de uso
le corresponde un peso”.
Factor de Complejidad Técnica del Proyecto de Software: “Los factores técnicos
(T) están definidos por las influencias técnicas que puedan afectar el proceso de
desarrollo del sistema a construir. Cada factor técnico posee un grado de
complejidad, que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5
determina un valor con alto grado de influencia. Cada factor técnico posee un valor de
peso. El peso total de ese factor de influencia técnica se obtiene con el producto entre
el valor de complejidad asignado y el peso que le corresponde al factor”.
Factores de Entorno del Proyecto: “Los factores de entorno (E) indican la influencia
del grupo humano involucrado en el proyecto sobre el sistema a desarrollar. De
manera similar a los factores técnicos, los factores de entorno poseen un grado de
Página 31 de 132
influencia que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5
determina un valor con alto grado de influencia. Cada factor de entorno posee un
valor de peso. El peso total de ese factor de influencia técnica se obtiene con el
producto entre el valor de influencia asignado y el peso que le corresponde al factor
de entorno”. (Remón & Thomas, 2010)
TÉCNICA PUNTOS DE CASO DE USO
1
Calcular los puntos de caso de uso no ajustados (UUCP)
Pesar Actores (AUW) y pesar casos de uso (UUCW)
UUCP =AUW+UUCW
2
Calcular los puntos de casos de uso (UCP)
Pesar factores técnicos (TCF)
Pesar factores Ambientales (EF)
UCP = UUCP*TCF*EF
3Estimar horas hombre
Horas-hombres = UCP * 20
Tabla 5. Tabla Técnica Puntos Casos de Uso
Página 32 de 132
Estimación del Proyecto con la Técnica de Casos de Uso
ACTORES PROPOSITO
Usuario MóvilRealiza el registro de incidente a través
de su dispositivo móvil.
Usuario Web Gestiona y crea la atención del incidente.
Usuario AdministradorGestiona el mantenimiento en el
sistema.
Tabla 6. Tabla Actores Técnica Puntos Casos de Uso
Curso típico de eventos
Este caso de uso empieza cuando el usuario móvil registra el incidente y hace el
envío de dicho incidente.
El usuario web recibe la alerta del incidente en el sistema.
El usuario web gestiona la alerta y crea la atención.
El usuario web recibe confirmación de finalización de incidente y cierra la
atención.
El usuario administrador se encarga de gestionar el mantenimiento del sistema.
Después de tener el flujo básico de eventos en la especificación de casos de uso,
procedemos a calcular los puntos de casos de uso no ajustados (UUCP):
PESO DE ACTORES
Página 33 de 132
Actores Tipo Valor
Usuario Móvil Simple 3
Usuario Web Complejo 3
Usuario Administrador Medio 3
UAW = 9
Tabla 7. Tabla Peso de Actores Técnica Puntos Casos de Uso
PESO DE CASOS DE USO
Caso de Uso Tipo Valor
Registrar usuario móvil Simple 5
Registrar incidente Simple 5
Agrupar incidentes Complejo 15
Gestionar incidentes Complejo 15
Mostrar incidentes gestionados Medio 10
Gestionar datos del usuario móvil Simple 5
Gestionar datos del usuario web Simple 5
Generar reportes de incidentes Simple 5
UUCW = 65
Tabla 8. Tabla Peso de casos de uso Técnica Puntos Casos de Uso
Página 34 de 132
UUCP = UAW +UUCW = 9 + 65 = 74
FACTORES TECNICOS
Factor Descripción Peso Nivel Peso*Nivel
T1 Sistema distribuido 2 0 2
T2Performance o tiempos de
respuesta1 5 5
T3 Eficiencia del usuario final 1 4 4
T4 Procesamiento interno complejo 1 3 3
T5 Código reutilizable 0.5 1 0.5
T6 Facilidad de instalación 0.5 5 2.5
T7 Facilidad de uso 2 5 10
T8 Portabilidad 1 5 5
T9 Facilidad de cambio 1 3 3
T10 Concurrencia 1 5 5
T11 Seguridad 1 4 4
T12 Acceso directo a terceras partes 1 0 0
T13 Facilidades especiales 1 2 2
TFactor=
∑(Nivel*Peso)46
Tabla 9. Tabla Factores Técnicos Puntos Casos de Uso
Página 35 de 132
El peso de los factores técnicos será:
TCF = 0.6 + (0.01 * TFactor) = 0.6 + (0.01 * 46) = 1.06
FACTORES AMBIENTALES
Factor Descripción Peso Nivel Pes*Niv
E1 Familiaridad con el modelo 1.5 3 4.5
E2 Experiencia en la aplicación 0.5 2 1
E3 Experiencia en la orientación a
objetos
1 3 3
E4 Capacidad del analista líder 0.5 3 1.5
E5 Motivación 1 2 2
E6 Estabilidad en los requerimientos 2 3 6
E7 Personal de medio tiempo -1 1 -1
E8 Dificultad en el lenguaje de
programación
-1 2 -2
EFactor=
∑(Nivel*Peso)
15
Tabla 10. Tabla Factores Ambientales Puntos Casos de Uso
EF = 1.4 + (-003 * EFactor) = 1.4 + (-0.03 * 15) = 0.95
Los puntos de casos de uso (UCP) para el proyecto son:
UCP = UUCP * TCF * EF = 74 * 1.06 * 0.95 = 74.518
Página 36 de 132
“El autor sugiere usar 20 horas hombre por UCP, para un sistema de 74.518
UCP * 20 hrs/hombre nos da un total de 1,490.36 hrs/hombre. Lo que equivale a
74 semanas (20 hrs por semana para una persona), de esta forma, nuestro
equipo de 3 personas desarrollarán el sistema y aplicativo móvil en 24 semanas.
Equivalente a 5 meses”. (Remón & Thomas, 2010)
Página 37 de 132
3.4. Planificación
Página 38 de 132
Figura 1. Cronograma de actividades
Figura 2. Diagrama cronograma de actividades
Página 39 de 132
Ya que se está empleando la metodología cascada. Los tres integrantes desarrollaran cada una de las etapas de este proyecto de
manera simultánea.
Página 40 de 132
4. CAPITULO IV: Metodología de desarrollo del proyecto.
En este capítulo vamos a definir la metodología que se empleara para la gestión
del presente proyecto, en la siguiente tabla se mostrará un cuadro comparativo de 4
metodologías aplicables a este proyecto.
MODELO CARACTERISTICA VENTAJA DESVENTAJA
Cascada
“Es el más utilizado.
Nos brinda una visión
del proceso de
desarrollo de software
como una sucesión
de etapas que
produce un producto
de calidad”.
“Se tiene todo bien
organizado y no se
mezclan las fases.
La planificación es
sencilla.
La calidad del
producto resultante
es alta”.
“Tarda mucho
tiempo en pasar por
todo el ciclo.
Es difícil de
incorporar nuevas
cosas si se quiere
actualizar”.
Espiral
“Cada giro se
construye un nuevo
modelo del sistema
completo.
Es el mejor modelo
para el desarrollo de
grandes sistemas”.
“El modelo espiral
permite a quien
desarrolla aplicar el
enfoque de
construcción de
prototipos en
cualquier etapa”.
“Elevada
complejidad.
Es un modelo
costoso.
Genera mucho
tiempo en el
desarrollo del
sistema”.
Incremental “Se evita proyectos
largos y se entrega
“Reduce tiempo de
desarrollo inicial.
“Requiere mucha
planeación, tanto
Página 41 de 132
algo de valor a los
usuarios con cierta
frecuencia.
Difícil de evaluar el
costo”.
Provee un impacto
ventajoso frente al
cliente
suministrando
partes pequeñas”.
administrativa como
técnica.
Requiere de metas
claras para conocer
el estado del
proyecto”.
Basado en
Componentes
“Se basa en la
reutilización de SW
existente.
Este modelo permite
reutilizar partes de
código pre
codificado”.
“Se ahorra tiempo
en desarrollo del
SW y ahorra
dinero.
Simplifica las
pruebas, permite
que cada prueba
sea ejecutada por
separado”.
“Las actualizaciones
de los componentes
adquiridos no están
en manos de los
desarrolladores del
sistema”.
Tabla 11. Cuadro comparativo de metodologías
Fuente: Elaboración Propia
Página 42 de 132
Para el presente proyecto utilizaremos el modelo en Cascada, la cual estará conformada
por cuatro actividades principales:
Figura 1.- Actividades principales del proyecto
Fuente: Elaboración Propia
Planificación:
“En la etapa de planificación se establece el diálogo entre las partes interesadas y
se identifican los procesos e información importante que se requiera para el desarrollo del
software. Además en este punto se establecen todas fechas para la presentación de las
versiones del producto que contemplen los requerimientos especificados, en el que se
muestre el software funcional”. (INTECO, 2009)
Diseño:
“Al emplearse la metodología cascada planteamos un diseño simple, siempre y
cuando pueda funcionar y amoldarse a todas las pruebas que se ejecuten y mientras esta
plasme la intención de los desarrolladores”. (INTECO, 2009)
Desarrollo:
“El desarrollo es una parte fundamental ya que como bien se ha especificado, la
implementación será el Core principal de la metodología cascada que se esté empleando
en este proyecto. Se plantean muchas estrategias de implementación entre ellas; la
recodificación, programación en pareja, integración continua, entre otros. Siempre y
cuando cumpla con los estándares de codificación”. (INTECO, 2009)
Página 43 de 132
Planificación Diseño Desarrollo Pruebas
Pruebas:
“Este es un punto clave en la metodología cascada, ya que los programadores
verifican y validan el correcto funcionamiento de los entregables o versiones. Se plantea
un método de desarrollo basado en las pruebas, de esta manera se asegura que la
codificación funciona según lo especificado en los requerimientos tanto funcionales como
no funcionales”. (INTECO, 2009)
Modelo en Cascada Metodología Elegida
El modelo de cascada está diseñado para proyectos de tamaño reducido y
complejidad controlada.
Es simple de entender y sencillo de usar.
Es casi improbable que presente errores
Incrementa simplicidad de gestión.
Ayuda a entender los requisitos del proyecto.
Los procesos de revisión a aplicar facilitan el cumplimiento de entregables
espáticos.
Aumenta la simplicidad de la gestión, ya que en ningún caso las fases se
superponen.
Ayuda a la comprensión de los requisitos de proyecto.
Existe una sola fecha de entrega.
Página 44 de 132
5. CAPITULO V: Análisis y Diseño
5.1. Análisis de Negocio
5.1.1. Diagrama de flujo de incidentes
Figura 3. Diagrama de flujo de incidentes
Página 45 de 132
Emergencia atendida o cancelada
Registrar y monitorear el estado de la emergencia
Asignar estación(es) de bomberos para atender la
emergencia
NODisponibilidad
SI
Consultar estación de bomberos disponible para la atención de la emergencia
Generar un parte de emergencia
Registrar el tipo de emergencia, ubicación,
referencia, datos del informante
Solicitar datos de la emergencia
NO
SI
Fin de la llamada de emergencia
Disponibilidad
Llamada de emergencia
5.2. Análisis del Sistema
5.2.1. Diagrama de Casos de Uso
Figura 4. Diagrama de caso de Uso General
Página 46 de 132
5.2.2. Especificación de los casos de uso
CU-01 Registrar informante
Resumen La aplicación móvil le permitirá al usuario
registrarse para poder reportar incidentes.
Actor Informante.
Precondición La aplicación debe estar instalada en el
dispositivo móvil.
Flujo normal 01 El informante deberá llenar los campos
del formulario de registro del usuario con
los siguientes datos:
Nombres y apellidos
Numero de celular
Correo electrónico
02 La aplicación móvil deberá verificar que
los datos obligatorios solicitados al
usuario tengan contenido alguno.
03 La aplicación móvil deberá validar que
los datos cumplan con las
especificaciones indicadas por la
aplicación.
04 La aplicación móvil deberá enviar los
datos de forma organizada para su
respectivo almacenamiento en la base
de datos.
Página 47 de 132
Flujos alternos 01 En caso de que el flujo normal 02 no se
realice de forma satisfactoria, el sistema
indicará a través de un mensaje que se
deben llenar los campos obligatorios.
02 En caso de que el flujo normal 03 no se
realice de forma satisfactoria, el sistema
indicará a través de un mensaje que la
información ingresada es incorrecta.
Post condición CU-02 Registrar incidente
CU-08 Gestionar datos del informante
Tabla 12 - Caso de uso Registrar informante
CU-02 Registrar incidente
Resumen El informante deberá registrar un incidente
con los datos necesarios para que este
posteriormente se envíe y pueda ser atendido
por la compañía de bomberos.
Actor Informante.
Precondición El informante debe estar registrado.
Flujo normal 01 El informante deberá elegir un tipo de
incidencia, el cual servirá para clasificar
el incidente de acuerdo al criterio de la
compañía de bomberos para enviar la
unidad adecuada.
Página 48 de 132
02 El informante deberá tomar una
fotografía que servirá de evidencia para
validar la veracidad del incidente, la
fotografía obtenida deberá tener el
formato PNG o JPG.
03 El informante podrá escribir una
descripción del incidente.
04 La aplicación móvil deberá obtener la
ubicación geográfica exacta del lugar
donde se encuentra el usuario móvil, el
cual registrará el incidente.
05 La aplicación móvil deberá validar que
los datos cumplan con las
especificaciones indicadas por la
aplicación.
06 La aplicación móvil deberá enviar los
datos de forma organizada para su
respectivo almacenamiento en la base
de datos.
Flujos alternos 01 En caso de que el flujo normal 03 no se
efectúe, la generación del incidente no
se verá afectada ya que la descripción
del incidente no es obligatoria.
02 En caso de que el flujo normal 04 no se
efectúe de forma satisfactoria, la
Página 49 de 132
aplicación mostrará a través de un
mensaje de alerta que debe volver a
realizar su obtención geográfica.
Post condición CU-04 Gestionar datos del incidente
Tabla 13 - Caso de uso Registrar incidente
CU-03 Agrupar incidentes
Resumen La aplicación Web permitirá al usuario web
agrupar todos los incidentes que se han
registrado desde la aplicación móvil en una
Atención.
Actor Usuario Web.
Precondición CU-02 Registrar incidente.
Flujo normal 01 El usuario deberá ingresar a la ventana
de gestión de incidentes.
02 La aplicación web deberá mostrar todos
los incidentes registrados en una lista.
03 La aplicación web deberá graficar la
ubicación del incidente en un mapa
digital, cada vez que seleccionemos un
incidente
04 La aplicación web deberá mostrar la
fotografía del incidente seleccionado.
Página 50 de 132
05 La aplicación web deberá seleccionar
uno a más incidentes y agruparlos en
una nueva atención, categorizándolos
por tipo de incidente.
Post condición La aplicación web podrá gestionar atenciones
creadas.
Tabla 14 - Caso de uso Agrupar incidentes
CU-04 Gestionar incidentes
Resumen La aplicación web permitirá gestionar las
atenciones creadas, cada atención tendrá un
estado que se irá actualizando de acuerdo a
la situación.
Actor Usuario web.
Precondición CU-03 Agrupar incidente
Flujo normal 01 La aplicación web deberá mostrar la lista
de atenciones creadas por categoría y
fecha.
02 El usuario web deberá seleccionar una
atención e ir a la opción de gestionar.
03 El usuario web deberá actualizar los
datos de la atención y el estado en el
cual se encuentra dicha atención.
Post condición Las atenciones se mostrarán en una ventana
Página 51 de 132
de monitoreo.
Tabla 15 - Caso de uso Gestionar incidentes
CU-05 Monitorear incidentes gestionados
Resumen La aplicación web mostrará la lista de
atenciones en una ventana de monitoreo.
Actor Usuario visor.
Precondición CU-04 Gestionar incidentes.
Flujo normal 01 La aplicación web deberá actualizar la
lista de atenciones.
02 La aplicación web deberá mostrar la lista
de las atenciones gestionadas según su
estado de atención.
Post condición
Tabla 16 - Caso de uso Monitorear incidentes gestionados
CU-06 Gestionar datos del usuario móvil
Resumen La aplicación web permitirá bloquear usuarios
que reporten incidencias falsas, previa
verificación.
Actor Usuario web.
Precondición CU-02 Registrar incidente.
Página 52 de 132
Flujo normal 01 El usuario web deberá detectar que la
incidencia reportada sea falsa.
02 El usuario web deberá bloquear usuario
móvil que realizó el registro de incidencia
falsa.
Post condición Prevenir el spam o registro de incidencias
falsas.
Tabla 17 - Caso de uso Gestionar datos del usuario móvil
CU-07 Gestionar datos del usuario web
Resumen La aplicación web permitirá gestionar los
datos de los usuarios del sistema.
Actor Administrador.
Precondición
Flujo normal 01 El usuario deberá ingresarlos datos del
nuevo usuario web, los datos que se
registrarán son:
Nombres y apellidos
DNI
Dirección.
02 La aplicación web deberá verificar que
los datos obligatorios solicitados al
usuario tengan contenido alguno.
03 La aplicación web deberá validar que los
datos cumplan con las especificaciones
Página 53 de 132
indicadas por la aplicación.
04 La aplicación web deberá enviar los
datos de forma organizada para su
respectivo almacenamiento en la base
de datos.
05 El usuario web deberá actualizar los
datos especificados en el punto anterior,
verificando y validando los datos que se
actualizarán tal como se indica en el
punto 02 y 03.
Flujos alternos 01 En caso de que el flujo normal 02 no se
realice de forma satisfactoria, el sistema
indicará a través de un mensaje que
verifiquen los datos que están
ingresando estén completos.
02 En caso de que el flujo normal 03 no se
realice de forma satisfactoria, el sistema
indicará a través de un mensaje que
verifiqué los datos que está ingresando
sean los correctos.
Post condición Los usuarios con los permisos necesarios
podrán acceder a la aplicación web.
Tabla 18 - Caso de uso Gestionar datos del usuario web
CU-08 Generar reportes de incidentes
Resumen En la aplicación web se podrá generar los
Página 54 de 132
reportes a partir de las incidencias
registradas.
Actor Usuario web.
Precondición CU-02 Registrar incidente.
Flujo normal 01 El usuario web deberá realizar la
consulta de los datos adecuados para
generar el reporte.
02 El usuario web deberá organizar la
información que se mostrará en el
reporte.
03 La aplicación web deberá generar
reporte de incidentes.
Flujos alternos 01 En caso de que el flujo normal 01 no se
realice de forma satisfactoria, se
mostrará a través de un mensaje el
problema que se presente.
Post condición
Tabla 19 - Caso de uso Generar reportes de incidentes
Página 55 de 132
5.2.3. Diagrama de Clases
Página 56 de 132
Figura 5. Diagrama de Clases
Página 57 de 132
5.2.4. Diagramas de Secuencia
Diagrama Registrar Informante
Figura 6. Diagrama Registrar Informante
Página 58 de 132
Diagrama Registrar Incidente
Figura 7. Diagrama Registrar Incidente
Página 59 de 132
Diagrama Acceso Aplicativo Web
Figura 8. Diagrama Acceso Aplicativo Web
Página 60 de 132
Diagrama Gestionar Informante
Figura 9. Diagrama Gestionar Informante
Página 61 de 132
Diagrama Gestionar Usuario Web
Figura 10. Diagrama Gestionar Usuario Web
Página 62 de 132
Diagrama Generar Reporte de Incidente
Figura 11. Diagrama Generar Reporte de Incidente
Página 63 de 132
5.2.5.Especificación de Requerimientos
5.2.5.1. Requerimientos funcionales
FRQ-0001 Registro de informante
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-01
Descripción El sistema permitirá el registro del informante, los
datos solicitados para dicho registro serán:
nombres, apellidos, correo electrónico y número de
celular.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 20 - Requisito Funcional: Registro de informante
FRQ-0002 Registro de empleados
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Página 64 de 132
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-06
Descripción El sistema permitirá el registro del personal que
labora en la institución, los datos solicitados para
dicho registro serán: nombres, apellidos, dirección,
correo electrónico, DNI.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 21 - Requisito Funcional: Registro de empleados
FRQ-0003 Registro de usuarios
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-06
Descripción El sistema permitirá el registro de un usuario con
privilegios para poder gestionar o monitorear
incidentes, los datos solicitados para dicho registro
serán: nombre de usuario y contraseña.
Importancia Importante
Página 65 de 132
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 22 - Requisito Funcional: Registro de usuarios
FRQ-0004 Envío de incidente
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-02
Descripción El sistema permitirá el envío de un incidente, dicho
incidente debe tener los siguientes datos: tipo de
incidente, latitud, longitud, fecha, número de
celular, descripción y fotografía del incidente.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 23 - Requisito Funcional: Envio de incidente
Página 66 de 132
FRQ-0005 Obtener ubicación
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-02
Descripción El sistema permitirá obtener la ubicación actual del
dispositivo móvil mediante la captura de la latitud y
longitud.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 24 - Requisito Funcional: Obtener ubicación
FRQ-0006 Capturar fotografía
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-02
Descripción El sistema permitirá tomar una fotografía y
Página 67 de 132
mostrarla dentro de la aplicación móvil para su
posterior envío.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 25 - Requisito Funcional: Capturar fotografía
FRQ-0007 Redimensionar fotografía
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-02
Descripción El sistema permitirá redimensionar el tamaño de la
fotografía tomada para controlar el espacio en
disco cuando se almacene en el servidor.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 26 - Requisito Funcional: Redimensionar fotografía
Página 68 de 132
FRQ-0008 Control de acceso web
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-03
CU-04
CU-05
CU-07
Descripción El sistema permitirá controlar el acceso web
solicitando un usuario y contraseña válida para
acceder al módulo autorizado.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 27 - Requisito Funcional: Control de acceso web
FRQ-0009 Mostrar nombre del usuario que ingresa al
sistema
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Página 69 de 132
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-07
Descripción El sistema permitirá mostrar el nombre del usuario
que ingresa al sistema en un mensaje de
bienvenida.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 28 - Requisito Funcional: Mostrar nombre del usuario
FRQ-0010 Mostrar lista de incidentes
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-03
CU-04
Descripción El sistema permitirá mostrar la lista de incidentes
reportados desde el aplicativo móvil, indicando el
tipo de incidente, fecha y descripción del incidente
para su posterior gestión.
Importancia Importante
Página 70 de 132
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 29 - Requisito Funcional: Mostrar lista de incidentes
FRQ-0011 Mostrar detalles del incidente
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-03
CU-04
Descripción El sistema permitirá seleccionar un incidente y
mostrar su ubicación geografía, foto del incidente,
en caso de no cargar la foto se mostrará una
imagen referencial de la ubicación.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 30 - Requisito Funcional: Mostrar detalles del incidente
Página 71 de 132
FRQ-0012 Graficar ubicación
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-03
CU-04
Descripción El sistema permitirá mostrar la ubicación exacta
del incidente reportado en un mapa digital, para
ello se empleará el Google Map API.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 31 - Requisito Funcional: Graficar ubicación
FRQ-0013 Agrupar incidentes
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-03
Página 72 de 132
CU-04
Descripción El sistema permitirá seleccionar uno o más
incidentes para poder agruparlos en una nueva
atención o una atención ya existente.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 32 - Requisito Funcional: Agrupar incidentes
FRQ-0014 Crear atención
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-04
Descripción El sistema permitirá crear una atención, el cual
deberá contener un nombre y una categoría, para
ello se deberá seleccionar uno o más incidentes.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 33 - Requisito Funcional: Crear atención
Página 73 de 132
FRQ-0015 Mostrar atenciones creadas
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-04
Descripción El sistema permitirá mostrar las atenciones
creadas indicando la fecha de creación, categoría,
nombre de la atención y número de incidentes
agrupados para dicha atención.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 34 - Requisito Funcional: Mostrar atenciones creadas
FRQ-0016 Gestionar atenciones
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-04
Página 74 de 132
CU-05
Descripción El sistema permitirá gestionar las atenciones
creadas, para la gestión se deberá tener en cuenta
la estación de bomberos que se le va asignar y el
estado en el cual se encuentra (en proceso,
cancelada o atendida). Esta información se irá
actualizando conforme sea el caso.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 35 - Requisito Funcional: Gestionar atenciones
FRQ-0017 Monitorear atenciones
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-05
Descripción El sistema permitirá mostrar en una ventana de
monitoreo las atenciones creadas y el estado en el
que se encuentran, la información a mostrar será:
la descripción de la atención, la estación de
bomberos que fue asignada y el tipo de
Página 75 de 132
emergencia al cual pertenece.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 36 - Requisito Funcional: Monitorear atenciones
FRQ-0018 Bloquear informante
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-07
Descripción El sistema permitirá bloquear al informante en
caso que se detecte que envía información falsa,
el estado del informante en el sistema pasará de
activo a inactivo.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 37 - Requisito Funcional: Bloquear informante
Página 76 de 132
FRQ-0019 Registrar estaciones
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-07
Descripción El sistema permitirá poder registrar y actualizar las
estaciones de bomberos con los siguientes datos:
nombre de la estación, dirección, ubicación,
teléfono, jefe, año de fundación, estado.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 38 - Requisito Funcional: Registrar estaciones
FRQ-0020 Registrar categoría de atención
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-07
Descripción El sistema permitirá poder registrar y actualizar las
Página 77 de 132
categorías de atención con los siguientes datos:
categoría, descripción y estado (activo o inactivo).
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 39 - Requisito Funcional: Registrar categoría de atención
FRQ-0021 Registrar categoría de incidente
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-07
Descripción El sistema permitirá poder registrar y actualizar las
categorías de incidentes con los siguientes datos:
categoría, descripción y estado (activo o inactivo).
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 40 - Requisito Funcional: Registrar categoría de incidente
Página 78 de 132
FRQ-0022 Registrar roles
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-07
Descripción El sistema permitirá poder registrar y actualizar los
roles de usuarios para el Aplicativo Web con los
siguientes datos: rol (administrador o visor),
descripción y estado (activo o inactivo).
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 41 - Requisito Funcional: Registrar Registrar roles
FRQ-0023 Mostrar referencia de ubicación
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Referencias Casos de uso:
CU-04
Descripción El sistema permitirá poder mostrar la dirección del
Página 79 de 132
lugar desde donde se reporta el incidente al
informante para una mejor referencia del lugar de
donde se encuentra.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 42 - Requisito Funcional: Registrar Registrar roles
5.2.5.2. Requerimientos no funcionales
NFR-0001 Accesibilidad
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Descripción El sistema presentara una interfaz de usuario
sencilla para que sea de fácil manejo a los
usuarios del sistema.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 43 - Requisito No Funcional: Accesibilidad
Página 80 de 132
NFR-0002 Mantenibilidad
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Descripción El sistema deberá de tener una programación clara
y estandarizada de manera que pueda ser
fácilmente mantenible.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 44 - Requisito No Funcional: Mantenibilidad
NFR-0003 Disponibilidad
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Descripción El sistema deberá estar disponible en todo
momento, ya que es un sistema que va permitir
reportar incidentes en cualquier momento y lugar.
Importancia Importante
Página 81 de 132
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 45 - Requisito No Funcional: Disponibilidad
NFR-0004 Integridad
Autores Medina Dávalos, Marco Antonio
Lazo Zuñiga, Ferly Romel
Yeren Morón, José Rafael
Fuentes Andrei Gómez Roselló
Descripción El sistema garantizara a los usuarios seguridad en
cuanto a la información que se procesa, se busca
asegurar que la información se envié y recepcione
sin pérdida de datos.
Importancia Importante
Urgencia Alta
Estado Terminado
Estabilidad Alta
Comentarios Ninguno
Tabla 46 - Requisito No Funcional: Integridad
Página 82 de 132
5.2.6.Arquitectura del Sistema
Figura 12. Diagrama de Arquitectura del Sistema
Página 83 de 132
5.2.7.Diseño de interfaces
Aplicativo Web
Figura 13. Login del sistema de gestión y control de alertas.
Figura 14. Página de inicio.
Página 84 de 132
Figura 15. Página de organización de incidentes.
Figura 16. Agrupación y categorización de incidentes repetidos.
Página 85 de 132
Figura 17. Página de creación de atención incidente.
Figura 18. Página de monitoreo de atenciones gestionadas.
Página 86 de 132
Aplicativo Móvil
Figura 19.Pantalla de registro de aplicativo móvil.
Página 87 de 132
Figura 20. Pantalla de menú de aplicativo móvil.
.
Página 88 de 132
Figura 21. Pantalla de envío de incidente en aplicativo móvil.
Página 89 de 132
5.2.8.Diagrama Entidad Relación
Página 90 de 132
Figura 22. Diagrama de Entidad Relación
5.2.9. Diseño de Base de Datos
5.2.9.1. Modelo Lógico
Página 91 de 132
Figura 23. Modelo lógico de base de datos
5.2.9.2. Modelo Físico
Página 92 de 132
Figura 24. Modelo físico de base de datos
5.2.10.Diccionario de Datos
Informantes
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
nombres varchar 45 Nombres del informante
apellidos varchar 45 Apellidos del informante
correo varchar 60 Correo del informante
celular int - Celular del informante
estado int - Estado del informante
Tabla 47 - Tabla Tabla Informantes
CategoriaIncidente
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
categoría varchar 20 Categoría del incidente
descripción varchar 100 Descripción de la categoría del incidente
estado int - Estado de la categoría del incidente
Tabla 48 - Tabla CategoriaIncidente
Roles
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
rol varchar 15 Nombre del rol
descripcion varchar 100 Descripción del rol
estado int - Estado del rol
Tabla 49 - Tabla Roles
Página 93 de 132
Personal
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
dni varchar 8 DNI del personal
nombres varchar 45 Nombres del personal
apellidos varchar 45 Apellidos del personal
celular varchar 15 Celular del personal
correo varchar 60 Correo del personal
direccion varchar 100 Dirección del personal
estado int - Estado del personal
Tabla 50 - Tabla Personal
Categoriaantenciones
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
categoria varchar 20 Nombre de la categoría
descripcion varchar 100 Descripción de la categoría
estado int - Estado de la categoría
Tabla 51 - Tabla Categoriaantenciones
Estaciones
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
nombre varchar 80 Nombre de la estación
direccion varchar 10 Dirección de la estación
Página 94 de 132
ubicacion varchar 30 Ubicación de la estación
telefono varchar 15 Teléfono de la estación
jefe varchar 80 Jefe de la estación
fechafundacio
n
date - Fecha de la fundación de la estación
estado int - Estado de la estación
Tabla 52 - Tabla Estaciones
Usuarios
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
usuario varchar 20 Nombre del usuario
password varchar 20 Contraseña del usuario
idRol int - Rol del usuario FK
idPersonal int - Personal FK
estado int - Estado del usuario
Tabla 53 - Tabla Usuarios
Incidentes
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
fechaHora date - Fecha y hora del incidente
latitud varchar 30 Latitud de la ubicación del incidente
longitud varchar 30 Longitud de la ubicación del incidente
fotografia varchar 266 Fotografía del incidente
descripcion varchar 300 Descripción del incidente
Página 95 de 132
idInformante int - Informantes que reporta el incidente FK
idCategoria int - Categoría del incidente FK
idUsuario int - Usuario que atiendes el incidente FK
estado int - Estado del incidente
Tabla 54 - Tabla Incidentes
DetalleAtenciones
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
idAtenciones int - Id de las atenciones FK
idIncidentes int - Id de los incidentes FK
estado int - Estado de la tabla
Tabla 55 - Tabla DetalleAtenciones
Atenciones
Campo Tipo Tamaño Descripción
id int - Id de la tabla PK
titulo varchar 50 Título de la atención
idCategoria int - Categoría de la atención FK
fechaHora date - Fecha de la atención
descripcion varchar 300 Descripción de la atención
idEstacion int - Estación que realizará la atención FK
idUsuario int - Usuario que realiza la atención FK
estado int - Estado de la atención
Tabla 56 - Tabla Atenciones
Página 96 de 132
Página 97 de 132
6. CAPITULO VI: Aseguramiento de la calidad.
6.1. Plan de Pruebas
Código
de
Requisito
s
Caso
Crític
o
Proceso/
Requisito
Funcional
Pre
Condicio
nes
Caso de
Prueba
Activida
des
Resultado
Esperado
FRQ-0001 SI Registro de
informante.
Llenar el
formulario
con los
datos
correspon
dientes..
Deberá
validar y
enviar los
datos del
informant
e para su
almacena
miento.
Los datos
del
informant
e se
guardaro
n
correcta
mente.
Los datos
del
informante
queden
almacenado
s en la base
de datos.
FRQ-0002 SI Registro de
empleados.
Llenar el
formulario
con los
datos
correspon
dientes.
Deberá
validar y
enviar los
datos del
empleado
para su
almacena
miento.
Los datos
del
emplead
o se
guardaro
n
correcta
mente.
Los datos
del
empleado
queden
almacenado
s en la base
de datos.
FRQ-0003 SI Registro de Llenar el
formulario
Deberá
validar y
Los datos
del
Los datos
del usuario
Página 98 de 132
usuarios. con los
datos
correspon
dientes.
enviar los
datos del
usuario
para su
almacena
miento.
usuario
se
guardaro
n
correcta
mente.
queden
almacenado
s en la base
de datos.
FRQ-0004 SI Envío de
incidente.
Elegir la
categoría,
tomar una
fotografía
y estar
conectado
a internet.
Deberá
validar los
datos y
enviar
para su
almacena
miento.
Los datos
del
incidente
se
guardaro
n
correcta
mente.
Los datos
del
incidente
queden
almacenado
s en la base
de datos.
FRQ-0005 SI Obtener
ubicación.
Conexión
a internet.
Deberá
obtener la
ubicación
exacta
desde
donde se
está
ejecutand
o la
aplicación
móvil.
Se tiene
lista las
coordena
das de la
ubicación
para ser
enviadas.
Las
coordenada
s estén
listas para
su envío.
Página 99 de 132
FRQ-0006 SI Capturar
fotografía.
Elegir una
categoría
de
incidente.
Deberá
obtener la
fotografía
la cual
seguidam
ente será
procesad
a y
enviada.
Se tiene
lista la
fotografía
para ser
redimensi
onada.
La
fotografía
esté lista
para su
redimension
amiento.
FRQ-0007 SI Redimensiona
r fotografía.
Tomar una
fotografía.
Deberá
redimensi
onar la
fotografía
tomada
por el
informant
e, de
modo que
tenga un
tamaño
adecuado
para ser
enviada.
Se tiene
lista la
fotografía
para ser
enviada.
La
fotografía
esté lista
para su
envío.
FRQ-0008 SI Control de
acceso web.
Conexión
a internet
y acceder
Deberá
validar los
datos
Ingreso
del
usuario al
El usuario
acceda al
módulo que
Página 100 de 132
al módulo
de control
de
accesos.
ingresado
s sean
correctos
además
de
verificar
que el
usuario
esté
registrado
en la base
de datos.
módulo
correspo
ndiente.
le
correspond
e.
FRQ-0009 SI Mostrar
nombre del
usuario que
ingresa al
sistema.
Tener los
accesos
necesarios
.
Deberá
mostrar
una
bienvenid
a con el
nombre
del
usuario
que está
accediend
o a la
aplicación
.
Bienvenid
o
<nombre
del
usuario>.
Se muestre
el saludo de
bienvenida.
FRQ-0010 SI Mostrar lista Registrar Deberá Visualiza Se muestre
Página 101 de 132
de incidentes. incidentes. mostrar
una lista
de
incidentes
.
ción de
lista de
incidente
s.
la lista de
incidentes.
FRQ-0011 SI Mostrar
detalles del
incidente.
Registrar
incidentes.
Deberá
mostrar el
detalle de
los
incidentes
tales
como
ubicación
fotografía,
descripció
n y
categoría
al
seleccion
ar en
cada uno
de ellos.
Visualiza
ción de la
ubicación
fotografía
y demás
datos del
incidente.
Se muestre
los detalles
de los
incidentes.
FRQ-0012 SI Graficar
ubicación.
Registrar
incidentes.
Deberá
graficar
sobre un
mapa
Visualiza
ción del
mapa
digital
Visualice la
ubicación
de
Página 102 de 132
digital la
ubicación
exacta del
incidente
registrado
.
con la
ubicación
del
incidente.
incidente.
FRQ-0013 SI Agrupar
incidentes.
Registrar
incidentes.
Deberá
agrupar
incidentes
los cuales
deberán
pertenece
r a una
atención.
Agrupaci
ón
correcta.
Los
incidentes
queden
agrupados.
FRQ-0014 SI Crear
atención.
Registrar
incidentes.
Deberá
crear
atencione
s.
Creación
de
atención
correcta.
La atención
se cree
correctame
nte.
FRQ-0015 SI Mostrar
atenciones
creadas.
Crear
atenciones
.
Deberá
mostrar
las
atencione
s creadas.
Visualiza
ción de
atencione
s
creadas.
Que las
atenciones
se
muestren
en una lista.
FRQ-0016 SI Gestionar Crear
atenciones
Deberá
gestionar
Atención
actualiza
Que se
puedan
Página 103 de 132
atenciones. . la
informació
n de las
atencione
s.
da. actualizar
los datos de
las
atenciones
creadas.
FRQ-0017 SI Monitorear
atenciones.
Crear
atenciones
.
Deberá
mostrar
sobre un
mapa
digital
todas las
atencione
s que
están en
proceso.
Visualiza
ción de
mapa
digital
con la
ubicación
de las
atencione
s.
Visualizar
las
atenciones
en un mapa
digital.
FRQ-0018 SI Bloquear
informante.
Registrar
informante
.
Deberá
bloquear
informant
es.
Informant
e
bloquead
o.
El
informante
quede
bloqueado.
FRQ-0019 SI Registrar
estaciones.
Llenar el
formulario
con los
datos
correspon
dientes.
Deberá
registrar
estacione
s.
Estación
registrad
a.
Los datos
de la
estación
queden
almacenado
s en la base
Página 104 de 132
de datos.
FRQ-0020 SI Registrar
categoría de
atención.
Llenar el
formulario
con los
datos
correspon
dientes.
Deberá
registrar
categoría
de
atencione
s.
Categorí
a de
atención
registrad
a.
Los datos
de la
categoría
de
atenciones
queden
almacenado
s en la base
de datos.
FRQ-0021 SI Registrar
categoría de
incidente.
Llenar el
formulario
con los
datos
correspon
dientes.
Deberá
registrar
incidente.
Categorí
a de
incidente
s
registrad
a.
Los datos
de la
categoría
de
incidentes
queden
almacenado
s en la base
de datos.
Página 105 de 132
FRQ-0022 SI Registrar
roles.
Llenar el
formulario
con los
datos
correspon
dientes.
Deberá
registrar
roles.
Rol
registrad
o.
Los datos
del rol
queden
almacenado
s en la base
de datos.
FRQ-0023 SI Mostrar
referencia de
ubicación.
Obtener la
ubicación.
Deberá
mostrar
una
referencia
de la
ubicación.
Visualiza
ción de
referenci
a del
incidente.
Muestre la
referencia
de la
ubicación.
Tabla 57 - Plan de Pruebas
Página 106 de 132
6.2. Cheklist de pruebas
CONTROL DE LA APLICACIÓN MOVIL
Ítem/s inspeccionado/s: Fecha:
Puntos chequeados: 1 2 3 4 5 Inspector:
1. Validación de campos vacíos
¿Valida que los campos no se encuentran vacíos? SI NO N/A
¿Realiza la validación de campos? SI NO N/A
2. Registro de usuario móvil
¿Se registra el usuario móvil sin ningún problema? SI NO N/A
¿Error al registrar al usuario móvil? SI NO N/A
3. Captura de datos (latitud y longitud)
¿Captura la longitud y latitud desde dispositivo móvil? SI NO N/A
¿Muestra referencia del lugar en base a la latitud y longitud? SI NO N/A
Página 107 de 132
4. Tomar foto
¿Captura la fotografía y la muestra en un control de imagen? SI NO N/A
¿Existe algún error al capturar fotografía? SI NO N/A
5. Registrar incidente
¿Envía datos del incidente a la base de datos? SI NO N/A
¿Falla en él envío del incidente? SI NO N/A
Observaciones
NOTA: N/A = No aplicable.
Página 108 de 132
CONTROL DE LA APLICACIÓN WEB
Ítem/s inspeccionado/s: Fecha:
Puntos chequeados: 1 2 3 4 5 Inspector:
1. GESTION DE USUARIOS WEB
¿Permite crear nuevos usuarios web? SI NO N/A
¿Permite asignar un rol al nuevo usuario web? SI NO N/A
2. GESTION DE ACCESOS
¿Muestra los módulos web según el tipo de usuario? SI NO N/A
¿Valida que solo ingresen usuarios registrados? SI NO N/A
3. MONITOREO DE ATENCIONES
¿Muestra la lista de atenciones según su estado de atención? SI NO N/A
4. GESTION DE USUARIO MOVIL
Página 109 de 132
¿Permite bloquear y desbloquear a un usuario móvil? SI NO N/A
5. GESTION DE INCIDENTES
¿Permite agrupar más de un incidente del mismo tipo en una sola atención? SI NO N/A
¿Permite actualizar datos de un incidente? SI NO N/A
Observaciones
NOTA: N/A = No aplicable.
Página 110 de 132
7. CAPITULO VII: Resultados
7.1. Encuestas de satisfacción
ENCUESTA DE SATISFACCIÓN DEL APLICATIVO MÓVIL
NOMBRE: FECHA:
Su opinión es importante para tratar de mejorar nuestro aplicativo móvil Alerta
Bombero. La información aquí recopilada nos resultará muy útil. Por favor, califique su
grado de satisfacción en los siguientes puntos, teniendo en cuenta que 1 es pésimo, 2
es malo, 3 es regular, 4 es bueno y 5 es excelente (marque con una X).
1. ¿Cuán fácil fue registrarse en el aplicativo móvil Alerta Bombero?
1 2 3 4 5
2. ¿Cuán amigable es la interfaz del aplicativo móvil Alerta Bombero?
1 2 3 4 5
3. ¿Cuán fácil es reconocer las opciones en aplicativo móvil Alerta
Bombero?
1 2 3 4 5
4. ¿Fue fácil seleccionar el tipo de incidente a reportar?
1 2 3 4 5
Página 111 de 132
5. ¿Facilidad al capturar y mostrar la dirección obtenida desde módulo GPS
del dispositivo móvil?
1 2 3 4 5
6. ¿Facilidad al Capturar evidencia fotográfica desde el aplicativo móvil Alerta
Bombero?
1 2 3 4 5
7. ¿Fue rápido enviar el incidente desde aplicativo Alerta Bombero a la
central de emergencias?
1 2 3 4 5
8. ¿Luego de la experiencia obtenida con que probabilidad usted
recomendaría nuestra aplicativo Alerta Bombero a un amigo?
1 2 3 4 5
Página 112 de 132
ENCUESTA DE SATISFACCIÓN DEL APLICATIVO WEB DE GESTIÓN Y
MONITOREO DE INCIDENTES
NOMBRE: FECHA:
Su opinión es importante para tratar de mejorar nuestro Aplicativo Web Alerta
Bombero. La información aquí recopilada nos resultará muy útil. Por favor marque solo
una opción (marque con una X).
1. ¿El acceso al Sistema de Monitoreo y Gestión de Incidentes es sencillo?
( ) SI
( ) NO
2. ¿La interfaz web del sistema de Monitoreo y Gestión de Incidentes es
Amigable?
( ) SI
( ) NO
3. ¿El sistema de Monitoreo y Gestión de Incidentes responde de manera
rápida a sus solicitudes?
( ) SI
( ) NO
Página 113 de 132
4. ¿Es fácil el desplazamiento entre Módulos del Sistema de Monitoreo y
Gestión de Incidentes?
( ) SI
( ) NO
5. ¿Es fácil el reconocimiento de las Alertas recibidas en tiempo real?
( ) SI
( ) NO
6. ¿Es sencillo agrupar los incidentes reportados y suscitados en un mismo
lugar?
( ) SI
( ) NO
7. ¿Es sencilla la creación de Atenciones a partir de la agrupación de
incidentes?
( ) SI
( ) NO
8. ¿Es sencilla la gestión de las atenciones creadas?
( ) SI
( ) NO
Página 114 de 132
9. ¿Es fácil la asignación de las atenciones creadas a las estaciones de
bomberos?
( ) SI
( ) NO
10. ¿Es fácil identificar y bloquear al informante móvil?
( ) SI
( ) NO
11. ¿Es fácil el reconocimiento de las Atenciones en el Mapa de Google Map?
( ) SI
( ) NO
12. ¿El sistema le brinda la información que usted requiere para cumplir con
todas sus labores?
( ) SI
( ) NO
Página 115 de 132
7.2. Cuadros estadísticos
Resultados de Encuesta de Satisfacción del Aplicativo Móvil
Tabulación de datos
Pregunta 1 Pregunta 2 Pregunta 3 Pregunta 4 Pregunta 5 Pregunta 6 Pregunta 7 Pregunta 8Encuestado 1 5 5 4 5 5 5 5 5Encuestado 2 5 5 5 5 5 5 5 5Encuestado 3 5 5 5 5 4 5 5 5Encuestado 4 5 5 5 5 4 5 5 5Encuestado 5 5 5 5 5 4 4 5 5Encuestado 6 5 4 5 5 4 5 5 5Encuestado 7 5 4 5 5 5 5 5 5Encuestado 8 5 5 5 5 5 5 5 5Encuestado 9 5 5 5 5 5 5 5 5
Encuestado 10 5 5 5 5 5 5 5 5Encuestado 11 5 5 5 5 5 5 5 5Encuestado 12 5 5 5 5 5 5 5 5
Figura 25. Tabulación de datos
Fuente: Elaboración Propia
Página 116 de 132
Resultados
Grado de Satisfacción
1.- ¿Facilidad para registrarse en el aplicativo móvil Alerta Bombero
fue sencillo?
2.- ¿Cuán amigable es la
interfaz del aplicativo móvil
Alerta Bombero?
3.- ¿Facilidad en reconocer las opciones en
aplicativo móvil Alerta Bombero?
4.- ¿Facilidad para seleccionar el tipo
de incidente a reportar?
5.- ¿Facilidad al capturar y mostrar la
dirección obtenida desde modulo GPS
del dispositivo móvil?
6.- ¿Facilidad al Capturar evidencia
fotográfica desde el aplicativo móvil Alerta Bombero?
7. -¿Rapidez al enviar el incidente
desde aplicativo Alerta Bombero a
la central de emergencias?
8.- ¿Luego de la experiencia
obtenida con que probabilidad usted
recomendaría nuestra aplicación Alerta Bombero a
un amigo?
Excelente 12 10 11 12 8 11 12 12Bueno 0 2 1 0 4 1 0 0
Regular 0 0 0 0 0 0 0 0Malo 0 0 0 0 0 0 0 0
Pésimo 0 0 0 0 0 0 0 0
Figura 26. Resultados
Fuente: Elaboración Propia
Página 117 de 132
Interpretación de los Resultados de Encuesta de Satisfacción del Aplicativo
Móvil
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
14
1.- ¿La facilidad para registrarse en el aplicativo móvil Alerta Bombero fue sencillo?
Figura 27. Pregunta 1
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 12 encuestados creen que el registro de un
nuevo usuario en el aplicativo móvil es excelente.
Página 118 de 132
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
2.- ¿Cuán amigable es la interfaz del aplicativo móvil Alerta Bombero?
Figura 28. Pregunta 2
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 10 encuestados creen que la interfaz del
aplicativo móvil es excelente y 2 encuestados creen que la interfaz del aplicativo
móvil es buena.
Página 119 de 132
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
3.- ¿Facilidad en reconocer las opciones en aplicativo móvil Alerta Bombero?
Figura 29. Pregunta 3
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 11 encuestados creen que la usabilidad del
aplicativo móvil es excelente y 1 encuestado cree que la usabilidad del aplicativo
móvil es buena.
Página 120 de 132
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
14
4.- ¿Facilidad para seleccionar el tipo de in-cidente a reportar?
Figura 30. Pregunta 4
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 12 encuestados creen que la facilidad para
la selección del tipo de incidentes es excelente.
Página 121 de 132
Excelente Bueno Regular Malo Pésimo0123456789
5.- ¿Facilidad al capturar y mostrar la dirección obtenida desde modulo GPS del dispositivo
móvil?
Figura 31. Pregunta 5
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 8 encuestados creen que la facilidad para
la captura y muestra de la dirección empleando la tecnología GPS es excelente.
Página 122 de 132
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
6.- ¿Facilidad al Capturar evidencia fotográfica desde el aplicativo móvil Alerta Bombero?
Figura 32. Pregunta 6
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 11 encuestados creen que la facilidad en la
captura de la foto es excelente y 1 encuestado cree que la facilidad en la captura
de la foto es buena.
Página 123 de 132
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
14
7. -¿Rapidez al enviar el incidente desde aplica-tivo Alerta Bombero a la central de emergencias?
Figura 33. Pregunta 7
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 12 encuestados creen que la facilidad de
envío del incidente es excelente.
Página 124 de 132
Excelente Bueno Regular Malo Pésimo0
2
4
6
8
10
12
14
8.- ¿Luego de la experiencia obtenida con que probabilidad usted recomendaría nuestra apli-
cación Alerta Bombero a un amigo?
Figura 34. Pregunta 8
Fuente: Elaboración Propia
Interpretación:
De un total de 12 encuestados, 12 encuestados creen que según la
experiencia obtenida recomendarían con una calificación excelente la aplicación
móvil Alerta Bombero.
Página 125 de 132
Conclusión de las Encuestas de Satisfacción del Aplicativo Móvil
De un total de 12 personas encuestadas, 12 encuestados recomiendan el uso de
la aplicación para reportar incidentes en casos de emergencia por su sencillez, rapidez y
facilidad de uso.
De un total de 12 personas encuestadas, 01 encuestado recomienda
desarrollar la aplicación móvil para dispositivos iPhone.
Conclusión de la Encuesta de Satisfacción del Aplicativo Web de Gestión y
Monitoreo de Incidentes
Conclusión:
Después de realizar la encuesta aplicada al operador encargado de la
recepción de incidentes en la central de la compañía de Bomberos, Sé concluye
que el sistema de monitoreo y gestión de incidentes propuesto cumple con todas
las funcionalidades necesarias para un mejor control, gestión de incidentes así
como la determinación de la localización exacta del hecho para su oportuna
atención.
Página 126 de 132
8. CAPITULO VIII: Conclusión, Recomendaciones y Referencias Bibliográficas
8.1. Conclusiones
Se implementó la base de datos la cual podrá soportar todos los procesos
implementados en el sistema.
Se implementó el Back-End del lado del servidor el cual permitirá gestionar la
seguridad y procesamiento de datos del sistema.
Se implementó la aplicación para dispositivos móviles que permitirá a la
ciudadanía poder registrase y reportar incidentes en tiempo real. Para él envió de
la información se emplea la conectividad móvil, geolocalización y captura de
imagen.
Se implementó la aplicación web que permitirá gestionar y monitorear incidentes
reportados desde la aplicación móvil.
Se implementó un sistema de envío, gestión y monitoreo de incidentes el cual
podrá ser usado en escenarios donde las llamadas telefónicas no estén
disponibles pero si se cuente con una conexión de internet.
8.2. Recomendaciones
Se recomienda desarrollar el cliente para los móviles iPhone y Windows Mobile
que en la actualidad también poseen gran cantidad de usuarios que podrían
interesarse por esta aplicación.
Se recomienda desarrollar una versión de la aplicación móvil en otros idiomas ya
que en la actualidad nuestro país es visitado por muchos turistas de diferentes
países y no son ajenos a sufrir o reportar algún tipo de incidente.
Página 127 de 132
Finalmente, se propone expandir la aplicación orientada a otras entidades que
sean de interés para la comunidad, como por ejemplo comisarías, colegios, etc.
Se recomienda Implementar el módulo de auditoría en la base de datos, para un
mejor control de la información procesada por el sistema.
Página 128 de 132
8.3. Referencias Bibliográficas
[1] Apolinario, A. N. (2013). Programacion en Java 2. Lima: Megabyte.
[2] Azaustre, C. (16 de Agosto de 2014). Desarrollo web Ágil con Angular.js .
Latinoamérica.
[3] Clemmons, R. K. (2006). Project estimation with Use Case Points. Estados Unidos:
Crosstalk.
[4] Cobo, Á. (2005). PHP y MySQL: Tecnología para el desarrollo de aplicaciones web.
[5] Durán, L. (2006). El Gran libro del PC interno. México: ALFA OMEGA GRUPO.
[6] Garcia, S. R. (2017). Operaciones con bases de datos ofimáticas y corporativas.
Madrid: Paraninfo S.A.
[7] Google. (s.f.). Google Maps APIs. Recuperado el 20 de Junio de 2017, de
https://developers.google.com/maps/terms?hl=es-419
[8] Guevara, F. &. (2010). Analisis del Modelo Vista Controlador Implementado en
lenguajes de software libre para el desarrollo de aplicaciones web. Liceo de Talentos
Stephen Hawking. Riobamba.
[9] Harrop, C. H. (2012). Spring Configuration in Detail. New York: Apress.
[10] Hibernate. (19 de 06 de 2017). HIbernate 2017. Obtenido de
http://hibernate.org/orm/
[11] INTECO. (2009). Ingeniería del software: Metodologías y ciclos de vida. Madrid:
Laboratorio Nacional de Calidad del Software de INTECO.
[12] Karner, G. (1993). Metrics for Objectory, Degree thesis, Universidad de Linkoping,
Suecia.
[13] Microsoft Corporation. (11 de 02 de 2017). Obtenido de Definición y
características de un web service:
https://msdn.microsoft.com/es-es/library/bb972248.aspx
[14] Mikkonen, T. (2007). Programming Mobile Devices: An Introduction for
Practitioners. Canada: John Wiley and Sons Lte.
[15] Minera, F. (2011). PHP Avanzado. Buenos Aires: Fox Andina & Gradi S.A.
Página 129 de 132
[16] Pressman, R. S. (1998). Ingeniería del software, un enfoque práctico. España:
McGraw-Hill.
[17] Scott, M. F. (1999). UML gota a gota. Juárez: Addison Wesley de México S.A.
[18] Tommi, M. (2007). Programming mobile devices, an introduction for Practitioners .
Chichester: Wiley.
[19] Valcarcel, I. G. (2013). E-business colaborativo: Como implantar software libre.
Madrid: Fundación Confemetal.
[20] Valle, E. C. (s.f.). EJECUTIVOS de INFORMÁTICA - TEMARIO MATERIAS
ESPECÍFICAS.
[21] Vivek Chopra, S. L. (2008). Apache tomcat. Madrid: Anaya Multimedia.
[22] Cristian A. Remón, P. T. (2010). Repositorio institucional de la UNLP. Obtenido
de http://sedici.unlp.edu.ar/bitstream/handle/10915/19290/Documento_completo.pdf?
sequence=1.
Página 130 de 132
8.4. Glosario
API: Son las siglas de Interfaz de Programación de Aplicaciones. El API es un
conjunto de funciones, métodos y/o procedimientos que se pueden emplear para
la construcción de nuevo software.
Servicio Web: Es la tecnología o medio que emplea un conjunto de protocolos y
estándares, los cuales sirven para la transferencia datos o comunicación entre
aplicaciones.
Servidor: Equipo informático que forma parte de una red, a través del cual se
pueden proveer diferentes servicios.
Smartphone: Teléfono móvil con capacidad para almacenar datos y
características de una minicomputadora.
Android: Sistema operativo base para dispositivos móviles. En la actualidad el
más usado por el mercado.
GPS: (Global Position System - Sistema de Posicionamiento Global). Se trata de
un sistema global de navegación por satélite (GNSS) que permite localizar con
precisión un dispositivo GPS en cualquier lugar del mundo.
Software Libre: se refiere a la libertad de los usuarios para ejecutar, copiar,
distribuir, estudiar, cambiar y mejorar el software.
Framework: Framework es estructura real o conceptual destinada a servir de
soporte o guía para el desarrollo y/o implementación de una aplicación.
Incidente: Es el reporte de una emergencia el cual requiere una atención.
Atención: Es la asignación de recursos para atender un incidente reportado por el
informante.
Página 131 de 132
Informante: Persona que registra incidente mediante la aplicación móvil.
Geolocalización Móvil: Es la capacidad para obtener la ubicación geográfica real
desde un dispositivo móvil mediante el uso del módulo GPS.
Evidencia fotográfica: Fotografía capturada desde la aplicación alerta bombero
con el fin de comprobar el incidente.
UPC: Metodología de puntos de caso de uso.
UAW: Sumatoria de todos los pesos de los actores identificados.
UUCW: Sumatoria de los pesos de los casos de uso.
UUCP: Punto de caso de uso no ajustado.
TCF: Factor de Complejidad Técnica.
EF: Factor medioambiental.
AUCP: Punto de Caso de Uso Ajustado.
Página 132 de 132
ANEXOS
Página 133 de 132