repositorio.utp.edu.perepositorio.utp.edu.pe/bitstream/utp/864/6/marco medina... · web viewa dios,...

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


Nombre y José Rafael Yeren Morón

Página 28 de 132

mailto:[email protected]

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


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


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


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



de datos.


efectúe, la generación del incidente no

se verá afectada ya que la descripción

del incidente no es obligatoria.


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.


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



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.



indicará a través de un mensaje que

verifiquen los datos que están

ingresando estén completos.



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.


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.


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




Página 64 de 132



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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 21 - Requisito Funcional: Registro de empleados

FRQ-0003 Registro de usuarios






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.


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






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.


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






CU-02

Descripción El sistema permitirá obtener la ubicación actual del

dispositivo móvil mediante la captura de la latitud y

longitud.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 24 - Requisito Funcional: Obtener ubicación

FRQ-0006 Capturar fotografía






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 25 - Requisito Funcional: Capturar fotografía

FRQ-0007 Redimensionar fotografía






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.


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






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.


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




Página 69 de 132



CU-07

Descripción El sistema permitirá mostrar el nombre del usuario

que ingresa al sistema en un mensaje de

bienvenida.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 28 - Requisito Funcional: Mostrar nombre del usuario

FRQ-0010 Mostrar lista de incidentes






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.


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






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.


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






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 31 - Requisito Funcional: Graficar ubicación

FRQ-0013 Agrupar incidentes






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 32 - Requisito Funcional: Agrupar incidentes

FRQ-0014 Crear atención






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.


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






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 34 - Requisito Funcional: Mostrar atenciones creadas

FRQ-0016 Gestionar atenciones






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 35 - Requisito Funcional: Gestionar atenciones

FRQ-0017 Monitorear atenciones






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 36 - Requisito Funcional: Monitorear atenciones

FRQ-0018 Bloquear informante






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 37 - Requisito Funcional: Bloquear informante

Página 76 de 132

FRQ-0019 Registrar estaciones






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.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 38 - Requisito Funcional: Registrar estaciones

FRQ-0020 Registrar categoría de atención






CU-07


Página 77 de 132

categorías de atención con los siguientes datos:

categoría, descripción y estado (activo o inactivo).


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






CU-07


categorías de incidentes con los siguientes datos:

categoría, descripción y estado (activo o inactivo).


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






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


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 41 - Requisito Funcional: Registrar Registrar roles

FRQ-0023 Mostrar referencia de ubicación






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.


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





Descripción El sistema presentara una interfaz de usuario

sencilla para que sea de fácil manejo a los

usuarios del sistema.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 43 - Requisito No Funcional: Accesibilidad

Página 80 de 132

NFR-0002 Mantenibilidad





Descripción El sistema deberá de tener una programación clara

y estandarizada de manera que pueda ser

fácilmente mantenible.


Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 44 - Requisito No Funcional: Mantenibilidad

NFR-0003 Disponibilidad





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.


Página 81 de 132

Urgencia Alta

Estado Terminado

Estabilidad Alta

Comentarios Ninguno

Tabla 45 - Requisito No Funcional: Disponibilidad

NFR-0004 Integridad





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.


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



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



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



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



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



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



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



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



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



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

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.


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.


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


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


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


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


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


2

4

6

8

10

12

2.- ¿Cuán amigable es la interfaz del aplicativo móvil Alerta Bombero?



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


2

4

6

8

10

12

3.- ¿Facilidad en reconocer las opciones en aplicativo móvil Alerta Bombero?



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


2

4

6

8

10

12

14

4.- ¿Facilidad para seleccionar el tipo de in-cidente a reportar?



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


5.- ¿Facilidad al capturar y mostrar la dirección obtenida desde modulo GPS del dispositivo

móvil?



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


2

4

6

8

10

12

6.- ¿Facilidad al Capturar evidencia fotográfica desde el aplicativo móvil Alerta Bombero?



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


2

4

6

8

10

12

14

7. -¿Rapidez al enviar el incidente desde aplica-tivo Alerta Bombero a la central de emergencias?



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


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?



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

repositorio.utp.edu.perepositorio.utp.edu.pe/bitstream/utp/864/6/marco medina... · web viewa dios,...

Documents