Cardenas SJ

Sistema de geolocalización de riesgo de incendios
Item Type info:eu-repo/semantics/bachelorThesis
Authors Cardenas Suca, Julio Cesar; Tapia Medina, Diego Jesús
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights info:eu-repo/semantics/openAccess; Attribution-

NonCommercial-ShareAlike 4.0 International
Download date 02/10/2022 22:59:36
Item License http://creativecommons.org/licenses/by-nc-sa/4.0/
Link to Item http://hdl.handle.net/10757/660880

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERÍA
PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS DE
INFORMACIÓN
Sistema de Geolocalización de Riesgo de Incendios
TESIS
Para optar el título profesional de Ingeniero de Sistemas de Información
AUTOR(ES)
Cardenas Suca, Julio Cesar (0000-0003-4275-6386)
Tapia Medina, Diego Jesús (0000-0001-7446-3612)
ASESOR
Lomparte Alvarado, Romulo (0000-0003-3734-3966)
Lima, 11 de junio de 2022
1
DEDICATORIA
A mis padres por haberme apoyado durante todo este proyecto y por educarme con una
mentalidad de superación y esfuerzo. De igual manera, a mis compañeros por
acompañarme durante toda nuestra vida universitaria.
2
AGRADECIMIENTOS
A mi familia, por haberme dado la oportunidad de formarme en esta prestigiosa universidad

y haber sido mi apoyo durante todo este tiempo. De manera especial a mis profesores y
asesores, por haberme guiado, no solo en la elaboración de este proyecto de Tesis, sino a lo
largo de mi carrera universitaria y por haberme brindado su apoyo en mi desarrollo
profesional para seguir cultivando mis valores.
3
RESUMEN
Este proyecto tiene como finalidad implementar un Sistema de Geolocalización de Riesgo

de Incendios que apoye a las organizaciones respectivas a tomar las precauciones ante los
incendios generados en Lima Metropolitana. Para lograr este objetivo se desarrollará una
investigación que ayude a identificar las principales causas ante esta problemática, las
distintas soluciones previamente propuestas, las tecnologías que favorezcan al desarrollo del
sistema, los involucrados que participan ante este tipo de sucesos, y cuáles son las medidas
correspondientes a tomar en cuenta frente a este tipo de desastre.
La implementación del sistema de geolocalización garantizará la identificación de riesgo de
incendios de una forma anticipada, de tal manera que se reduzcan las posibilidades de sufrir
tanto daños económicos como personales. Asimismo, buscamos aliviar la labor brindada por
el equipo de bomberos del Perú, ya que ellos también podrán contar con la herramienta a
desarrollar y que este les permita actuar de forma rápida y anticipada.
Por lo previamente mencionado, se ha definido que el entregable final sea un sistema de
geolocalización, el cual permitirá optimizar el proceso general de análisis e identificación de
zonas de riesgo, esto mediante el uso de registros históricos o estadísticas previamente
investigadas y analizadas.
El alcance del proyecto se ha contemplado para ser desarrollado a lo largo de las 28 semanas
que comprenden los ciclos académicos de Taller de Proyecto, abarcando los ciclos 2020-01
y 2020-02.
Palabras clave: Geolocalización, Incendios, Predictivos, Desastres, Sistema
4
ABSTRACT
The purpose of this project is to implement a Fire Risk Geolocation System that will support
the respective organizations in taking precautions against fires generated in Metropolitan
Lima. To achieve this objective, research will be carried out to help identify the main causes
of this problem, the different solutions previously proposed, the technologies that favor the
development of the system, those involved in this type of event, and the corresponding
measures to be taken in the face of this type of disaster.
The implementation of the geolocation system will guarantee the identification of fire risk
in advance, in such a way that the possibilities of suffering both economic and personal
damage are reduced. Likewise, we seek to alleviate the work provided by the Peruvian
firefighting team, since they will also be able to count on the tool to be developed and that
this will allow them to act quickly and in advance.
Therefore, it has been defined that the final deliverable is a geolocation system, which will
optimize the overall process of analysis and identification of risk areas, this using historical
records or statistics previously investigated and analyzed.
The scope of the project has been contemplated to be developed throughout the 28 weeks
that comprise the academic cycles of Project Workshop, covering the cycles 2020-01 and
2020-02
Keywords: Geolocation, Fire, Predictive, Disaster, System
5
TABLA DE CONTENIDOS
1 CAPITULO 1: DEFINICIÓN DEL PROYECTO .................................................................................. 16
1.1 ANTECEDENTES ....................................................................................................................... 16

1.2 DOMINIO DEL PROBLEMA ..................................................................................................... 17
1.2.1 FORMULACIÓN DEL PROBLEMA ......................................................................................... 17
1.2.2 ANÁLISIS DEL PROBLEMA 17
1.2.3 IMPORTANCIA DEL PROBLEMA ........................................................................................... 17
1.3 MOTIVACIÓN ............................................................................................................................ 18
1.4 OBJETIVOS ................................................................................................................................. 19
1.4.1 OBJETIVO GENERAL ............................................................................................................... 19
1.4.2 OBJETIVOS ESPECÍFICOS ....................................................................................................... 19
1.5 INDICARES DE ÉXITO ............................................................................................................. 19
1.6 PROPUESTA ............................................................................................................................... 20
2 CAPITULO 2: LOGROS DE LOS STUDENT OUTCOME ................................................................. 21
2.1 STUDENT OUTCOME 1 ............................................................................................................ 21

2.2 STUDENT OUTCOME 2 ............................................................................................................ 22
2.3 STUDENT OUTCOME 3 ............................................................................................................ 23
2.4 STUDENT OUTCOME 4 ............................................................................................................ 23
2.5 STUDENT OUTCOME 5 ............................................................................................................ 23
2.6 STUDENT OUTCOME 6 ............................................................................................................ 24
2.7 STUDENT OUTCOME 7 ............................................................................................................ 26
3 CAPITULO 3: MARCO TEORICO ....................................................................................................... 28
3.1 GEOLOCALIZACIÓN ................................................................................................................ 29

3.1.1 SISTEMA DE GEOLOCALIZACIÓN ........................................................................................ 29
3.1.2 HERRAMIENTAS DE GEOLOCALIZACIÓN .......................................................................... 30
3.2 BIG DATA ................................................................................................................................... 31
3.3 ANÁLISIS PREDICTIVO ........................................................................................................... 31
3.4 CLOUD COMPUTING ............................................................................................................... 33
3.4.1 BENEFICIOS ............................................................................................................................... 34
3.4.2 MODELOS DE SERVICIO ......................................................................................................... 34
3.4.3 PLATAFORMAS CLOUD .......................................................................................................... 35
3.4.4 MODELOS DE IMPLEMENTACIÓN ........................................................................................ 36
3.5 ESTÁNDARES DE CALIDAD ................................................................................................... 37
4 CAPITULO 4: DESARROLLO DEL PROYECTO .............................................................................. 38
4.1 ANÁLISIS .................................................................................................................................... 38

4.1.1 ANÁLISIS DEL PROBLEMA .................................................................................................... 38
6
4.1.2 ANÁLISIS DEL MERCADO ...................................................................................................... 39
4.1.3 ANÁLISIS DE LAS HERRAMIENTAS ..................................................................................... 41
4.1.3.1 API DE GOOGLE MAPS ............................................................................................................ 41
4.1.3.2 SISTEMA DE POSICIONAMIENTO GLOBAL (GPS) ............................................................. 41
4.1.3.3 BENCHMARKING DE ALGORITMOS PREDICTIVOS ......................................................... 42
4.1.3.4 BENCHMARKING DE PLATAFORMAS CLOUD .................................................................. 47
4.1.4 SERVICIOS DE AZURE ............................................................................................................. 49
4.1.4.1 APP SERVICE ............................................................................................................................. 50
4.1.4.2 AZURE MACHINE LEARNING STUDIO ................................................................................ 50
4.1.4.3 AZURE DATABASE FOR MYSQL ........................................................................................... 51
4.1.4.4 AZURE COSMOS DB ................................................................................................................. 52
4.2 ARQUITECTURA TECNOLÓGICA .......................................................................................... 52
4.2.1 DISEÑO DE LA ARQUITECTURA TECNOLÓGICA.............................................................. 52
4.2.1.1 CAPAS DE LA ARQUITECTURA TECNOLÓGICA ............................................................... 54
4.2.1.2 DESCRIPCIÓN DE LOS COMPONENTES DE LA ARQUITECTURA .................................. 54
4.2.2 VISTA FÍSICA ............................................................................................................................. 57
4.3 CONSTRUCCIÓN DE LA SOLUCIÓN ..................................................................................... 58
4.3.1 REQUERIMIENTOS FUNCIONALES ...................................................................................... 58
4.3.2 REQUERIMIENTOS NO FUNCIONALES ................................................................................ 62
4.3.3 DESARROLLO DE LOS PROTOTIPOS .................................................................................... 63
4.4 DESARROLLO DE LA SOLUCIÓN .......................................................................................... 93
4.4.1 DESARROLLO DEL BACKEND ............................................................................................... 93
4.4.2 DESARROLLO DE LA APLICACIÓN WEB ............................................................................ 95
4.4.3 DESARROLLO DE LA APLICACIÓN MÓVIL ........................................................................ 96
4.4.4 SERVICIOS EXTERNOS ........................................................................................................... 97
4.4.5 DESARROLLO DEL ANÁLISIS PREDICTIVO ....................................................................... 97
4.5 PRUEBAS DE LA SOLUCIÓN .................................................................................................. 98
4.5.1 PRUEBAS REALIZADAS POR QUALITY SERVICE ............................................................. 98
4.6 IMPLEMENTACIÓN ................................................................................................................ 104
4.6.1 RECURSOS UTILIZADOS ....................................................................................................... 104
4.6.2 PROCEDIMIENTO DE DESPLIEGUE .................................................................................... 106
4.6.2.1 DESPLIEGUE DEL BACKEND EN AZURE .......................................................................... 106
4.6.2.2 DESPLIEGUE DE CONTENEDORES EN AZURE................................................................. 109
4.6.2.3 DESPLIEGUE DE BASE DE DATOS EN AZURE ................................................................. 112
4.6.2.4 CREACIÓN DEL APK .............................................................................................................. 117
4.6.3 RESULTADO DEL DESPLIEGUE........................................................................................... 118
4.7 PROPUESTA DE VALIDACIÓN ............................................................................................. 120
4.7.1 DISEÑO DE LA VALIDACIÓN DE LA APLICACIÓN MÓVIL ........................................... 120
4.7.2 DISEÑO DE LA VALIDACIÓN DE LA APLICATIVO WEB................................................ 121
7
5 CAPITULO 5: RESULTADOS DEL PROYECTO ............................................................................. 122
5.1 VALIDACIÓN DE LA SOLUCIÓN ......................................................................................... 122

5.1.1 RECOPILACIÓN DE DATOS .................................................................................................. 122
5.1.2 CAPTURA DE DATOS ............................................................................................................. 124
5.1.3 ANÁLISIS DE INDICADORES ............................................................................................... 126
5.1.4 RESULTADO DE PRUEBA ..................................................................................................... 128
5.2 TRABAJOS A FUTURO ........................................................................................................... 132
5.3 PLAN DE COSTOS ................................................................................................................... 132
6 CAPITULO 6: GESTIÓN DEL PROYECTO ...................................................................................... 133
6.1 PLAN DE GESTIÓN DEL PROYECTO .................................................................................. 133

6.2 HOJA DE RUTA DEL PROYECTO ......................................................................................... 140
6.3 PLAN DE GESTIÓN DEL ALCANCE ..................................................................................... 145
6.4 PLAN DE GESTIÓN DE REQUERIMIENTOS ....................................................................... 154
6.5 ENUNCIADO DE ALCANCE DEL PROYECTO ................................................................... 162
6.6 LISTA DE HITOS...................................................................................................................... 163
6.7 PLAN DE GESTIÓN DEL CRONOGRAMA ........................................................................... 165
6.8 PLAN DE GESTIÓN DE COSTOS ........................................................................................... 172
6.9 PLAN DE GESTIÓN DE CALIDAD ........................................................................................ 175
6.10 MATRIZ DE ASIGNACIÓN DE RESPONSABILIDADES .................................................... 179
6.11 PLAN DE GESTIÓN DE RECURSOS ..................................................................................... 181
6.12 PLAN DE GESTIÓN DE COMUNICACIONES ...................................................................... 188
6.13 PLAN DE GESTIÓN DE RIESGOS ......................................................................................... 190
7 CONCLUSIONES ................................................................................................................................ 206
8 RECOMENDACIONES ....................................................................................................................... 207
9 GLOSARIO .......................................................................................................................................... 208
10 BIBLIOGRAFIA .................................................................................................................................. 210
11 ANEXO A -WASC............................................................................................................................... 218
12 ANEXO C- COSTO Y PRESUPUESTO ............................................................................................. 233
13 ANEXO - PLAN DE CONTINUIDAD ............................................................................................... 237
8
ÍNDICE DE TABLAS
PROBLEMA Y CAUSAS .................................................................................................. 17
INDICADORES DE ÉXITO .............................................................................................. 19
CONOCIMIENTOS APLICADOS .................................................................................... 21
RESULTADOS DEL PROYECTO .................................................................................... 25
ELEMENTOS DEL PROYECTO ...................................................................................... 26
TÉCNICAS, HERRAMIENTAS O METODOLOGÍAS UTILIZADAS EN EL

PROYECTO 27
DESCRIPCIÓN DEL PUNTAJE DE CALIFICACIÓN PARA LOS ALGORITMOS

PREDICTIVOS 43
RESULTADOS DEL BENCHMARKING DE ALGORITMOS PREDICTIVOS ............ 47
DESCRIPCIÓN DEL PUNTAJE DE CALIFICACIÓN PARA LAS PLATAFORMAS

CLOUD 48
CARACTERÍSTICAS DE LAS PLATAFORMAS CLOUD............................................. 48
RESULTADOS DEL BENCHMARKING DE LAS PLATAFORMAS CLOUD ............. 49
NODOS DE LA ARQUITECTURA TECNOLÓGICA ..................................................... 54
INTERFACES DE LA ARQUITECTURA TECNOLÓGICA........................................... 55
SOFTWARE DE SISTEMAS DE LA ARQUITECTURA TECNOLÓGICA ................... 56
RED DE COMUNICACIONES DE LA ARQUITECTURA TECNOLÓGICA ............... 57
REQUERIMIENTOS FUNCIONALES DEL SISTEMA .................................................. 58
REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA ........................................... 63
VARIABLES USADAS PARA EL ANÁLISIS PREDICTIVO ........................................ 98
HISTORIAS DE USUARIO CERTIFICADAS EN EL SPRINT 5 ................................... 98
CASOS DE PRUEBA CERTIFICADOS EN EL SPRINT 5 ............................................. 99
HISTORIAS DE USUARIO CERTIFICADAS EN EL SPRINT 6 ................................. 100
CASOS DE PRUEBA CERTIFICADOS EN EL SPRINT 6 ........................................... 101
HISTORIAS DE USUARIO CERTIFICADAS EN EL SPRINT 7 ................................. 102
CASOS DE PRUEBA CERTIFICADOS EN EL SPRINT 7 ........................................... 103
RECURSOS UTILIZADOS PARA EL DESPLIEGUE DEL SISTEMA ........................ 105
PREGUNTAS DE LA ENTREVISTA CON MIEMBROS DE INDECI ......................... 122
9
INDICADORES ANTES DE LA IMPLEMENTACIÓN DE LA PROPUESTA ............ 123
DATOS DE MUESTRA (APLICACIÓN WEB) ............................................................. 128
DATOS DE MUESTRA (APLICACIÓN MÓVIL) ......................................................... 129
COSTOS DEL PROYECTO ($) ....................................................................................... 133
CICLO DE VIDA DEL PROYECTO .............................................................................. 134
ENFOQUES DEL DESARROLLO.................................................................................. 135
PLANES DE GESTIÓN SUBSIDIARIA ......................................................................... 136
UMBRAL DE VARIACIÓN DEL ALCANCE ............................................................... 137
UMBRAL DE VARIACIÓN DEL CALENDARIO ........................................................ 138
LÍNEA BASE DEL CALENDARIO ................................................................................ 138
UMBRAL DE VARIACIÓN DE COSTOS ..................................................................... 139
LÍNEA BASE DE LOS COSTOS .................................................................................... 140
PRINCIPALES ENTREGABLES DEL PROYECTO ..................................................... 141
HITOS SIGNIFICATIVOS DEL PROYECTO................................................................ 142
REVISIONES DEL PROYECTO .................................................................................... 143
FASES DEL CICLO DE VIDA DEL PROYECTO ......................................................... 144
DICCIONARIO DE EDT DEL PROYECTO .................................................................. 146
LÍNEA BASE DE MANTENIMIENTO DEL PROYECTO ........................................... 150
ACEPTACIÓN DE ENTREGABLES DEL PROYECTO ............................................... 152
MÉTRICAS DE LOS REQUERIMIENTOS DEL PROYECTO ..................................... 157
TRAZABILIDAD DE LOS REQUERIMIENTOS DEL PROYECTO ........................... 158
CRITERIOS DE ACEPTACIÓN DEL PROYECTO ....................................................... 162
LISTA DE HITOS DEL PROYECTO ............................................................................. 163
PROCEDIMIENTOS ORGANIZACIONALES DEL PROYECTO ................................ 166
UNIDADES DE MEDIDA DEL PROYECTO ................................................................ 172
NIVEL DE PRECISIÓN DEL PROYECTO .................................................................... 173
NIVEL DE EXACTITUD DEL PROYECTO .................................................................. 173
UMBRALES DE CONTROL DEL PROYECTO ............................................................ 174
ESTÁNDARES DE CALIDAD DEL PROYECTO ......................................................... 175
OBJETIVOS DE CALIDAD DEL PROYECTO ............................................................. 176
10
RESPONSABLES DE CALIDAD DEL PROYECTO .................................................... 176
ENTREGABLES DE CALIDAD DEL PROYECTO ...................................................... 178
PROCEDIMIENTO DE CALIDAD DEL PROYECTO .................................................. 179
MATRIZ DE RESPONSABILIDADES DEL PROYECTO ............................................ 179
IDENTIFICACIÓN DE MIEMBROS DEL EQUIPO DE PROYECTO ......................... 181
GESTIÓN DE MIEMBROS DEL EQUIPO DE PROYECTO ........................................ 181
ROLES Y RESPONSABILIDADES DE LOS MIEMBROS DEL EQUIPO DE

PROYECTO 183
DESARROLLO DEL EQUIPO DE PROYECTO ........................................................... 186
IDENTIFICACIÓN DE RECURSOS FÍSICOS DEL PROYECTO ................................ 188
GESTIÓN DE RECURSOS FÍSICOS DE PROYECTO ................................................. 188
GESTIÓN DE COMUNICACIÓN DEL PROYECTO .................................................... 188
RESTRICCIONES Y SUPUESTOS DE LA COMUNICACIÓN DEL PROYECTO ..... 189
ROLES Y RESPONSABILIDADES DE LOS MIEMBROS DEL PROYECTO ............ 192
GESTIÓN DE RIESGOS DEL PROYECTO ................................................................... 194
PROTOCOLOS DE CONTINGENCIA DEL PROYECTO ............................................ 199
FRECUENCIA Y TIEMPO DE LA GESTIÓN DE RIESGOS ....................................... 202
PROBABILIDADES DE LOS RIESGOS DEL PROYECTO ......................................... 204
IMPACTO POR OBJETIVO DEL PROYECTO ............................................................. 204
MATRIZ DE IMPACTO DEL PROYECTO ................................................................... 205
MATRIZ DE OPORTUNIDADES DEL PROYECTO .................................................... 205
ANEXO A- VARIABLES USADAS PARA EL ANÁLISIS PREDICTIVO .................. 228
ANEXO A- DESCRIPCIÓN DEL PUNTAJE DE CALIFICACIÓN PARA LOS

ALGORITMOS DE PREDICCIÓN  ............................................................................................................. 229
ANEXO A- RESULTADOS DE LA COMPARACIÓN DE ALGORITMOS  ............... 230
ANEXO C- COSTOS INTERNOS DEL PROYECTO ($) .............................................. 234
ANEXO C- COSTOS EXTERNOS DEL PROYECTO ($) ............................................. 235
ANEXO C- COSTO DE OPERACIONES DE MANTENIMIENTO ANUAL DEL

PROYECTO ($) 235
ANEXO C- RESUMEN DE OPERACIÓN DEL PROYECTO ($) ................................. 236
11
ANEXO C- COSTOS CONSIDERADOS ANTE UN INCENDIO ($) ........................... 236
ROLES DE SOPORTE DEL PLAN DE CONTINUIDAD .............................................. 237
MATRIZ DE URGENCIA VS IMPACTO ...................................................................... 240
12
ÍNDICE DE FIGURAS
Figura 1: Aplicación Móvil Smoke Detective ..................................................................... 39

Figura 2: Aplicación Móvil Fire City .................................................................................. 40
Figura 3: Aplicación Móvil Wildfire Analyst Pocket Edition............................................. 41
Figura 4: API de Google Maps ............................................................................................ 41
Figura 5: ¿Qué es GPS? ....................................................................................................... 42
Figura 6: Infraestructura del App Service ........................................................................... 50
Figura 7: Modelo Predictivo en Azure ................................................................................ 51
Figura 8: Azure Database for MySQL ................................................................................ 51
Figura 9: Azure Cosmos DB ............................................................................................... 52
Figura 10: Arquitectura Tecnológica del Sistema ............................................................... 53
Figura 11: Vista Física de la Arquitectura Tecnológica del Sistema .................................. 58
Figura 12: Interfaces del RF01 ............................................................................................ 64
Figura 14: Interfaz del RF03 ............................................................................................... 66
13
Figura 47: Arquitectura de Despliegue del Sistema .......................................................... 106
Figura 48: Inicio de Azure CLI ......................................................................................... 106
Figura 49: Clonación del Proyecto Git .............................................................................. 107
Figura 50: Configuración del plugin de Azure .................................................................. 107
Figura 51: Configuración del archivo POM ...................................................................... 108
Figura 52: Detalles del App Service para el BackEnd ...................................................... 108
Figura 53: Despliegue de Container en DockerHub .......................................................... 109
Figura 54: Creación de AppService para los Contenedores .............................................. 109
Figura 55: Configuración del AppService para los contenedores ..................................... 110
Figura 56: Verificar la configuración de AppService ....................................................... 111
Figura 57: Selección de imagen de Docker ....................................................................... 112
Figura 58: Creación del Servicio de Base de Datos .......................................................... 112
Figura 59: Planes del Servicio ........................................................................................... 113
Figura 60: Ingreso de datos del servicio ............................................................................ 113
Figura 61: Configurar conexión del servicio MySQL ....................................................... 114
Figura 62: Verificar despliegue exitoso............................................................................. 114
Figura 63: Interfaz de Servicios Azure .............................................................................. 115
Figura 64: Creación de Servicio Azure Cosmos ............................................................... 115
Figura 65: Configuración del Servicio Azure Cosmos ...................................................... 116
14
Figura 66: Verificación de despliegue del Servicio Azure Cosmos .................................. 116
Figura 67: Selección del proyecto en Android Studio....................................................... 117
Figura 68: Generación de APK ......................................................................................... 117
Figura 69: APK generado .................................................................................................. 118
Figura 70: Interfaz del Login de la Aplicación Web Desplegada ..................................... 118
Figura 71: Interfaz del Mapa de la Aplicación Web Desplegada ..................................... 119
Figura 72: Interfaces de la Aplicación Móvil Desplegada ............................................... 119
Figura 73: Casos de Prueba para los Ciudadanos ............................................................. 120
Figura 74: Flujo de Búsqueda de Zonas de Riesgo de Incendios ..................................... 120
Figura 75: Casos de Prueba para INDECI ......................................................................... 121
Figura 76: Flujo de Análisis e Identificación de Zonas de Riesgo de Incendios .............. 121
Figura 77: Sub Proceso de Análisis de Zonas de Riesgo de Incendios ............................. 122
Figura 78: Formato de preguntas antes de implementar la propuesta realizadas en Microsoft
Forms ................................................................................................................................. 123
Figura 79: Pruebas con usuario ......................................................................................... 124
Figure 80: Formato de preguntas para la aplicación móvil realizadas en Microsoft Forms
........................................................................................................................................... 124
Figura 81: Pruebas con usuario de INDECI ...................................................................... 125
Figura 82: Formato de preguntas para la aplicación web realizadas en Microsoft Forms 126
Figura 83: Análisis de Indicadores (Aplicación Móvil) .................................................... 126
Figura 84: Análisis de Indicadores (Aplicación Web) ...................................................... 127
Figura 85: Flujo Actual de Análisis e Identificación de Zonas de Riesgo de Incendios ... 127
Figura 86: Sub Proceso de Generación de Escenarios Riesgo .......................................... 128
Figura 87: Satisfacción de los Miembros de INDECI ...................................................... 129
Figura 88: Satisfacción según la Usabilidad .................................................................... 131
Figura 89: Satisfacción según la interfaz de usuario ......................................................... 131
Figura 90: Satisfacción según la eficiencia ....................................................................... 131
Figura 91: EDT del Proyecto ............................................................................................. 145
Figura 92: Organigrama del Proyecto ............................................................................... 183
Figura 93: Arquitectura de Contingencia .......................................................................... 248
15
1 CAPITULO 1: DEFINICIÓN DEL PROYECTO
En esta sección se describe los antecedentes, dominio del problema y la motivación del
proyecto. Asimismo, se presenta el objetivo principal y los específicos del proyecto, así
como con sus indicadores de éxito con la finalidad de respaldar su cumplimiento.
1.1 Antecedentes
Durante los últimos años se realizaron varios estudios donde se indicaba el uso de
sistemas de prevención de incendios. Uno de los tantos proyectos investigados,
consistió en el desarrollo de un sistema de detección de incendios para cocinas (W. L.
Hsu et al., 2019). Este sistema funcionaba mediante sensores meteorológicos que
detectaban llamas altas o fugas de gas y automáticamente apagan el suministro de gas
a la estufa para prevenir incendios, además de alertar a las personas en el hogar
mediante una alarma y mediante mensajes a través de una aplicación de mensajería.
Otra investigación consistió en el desarrollo de un sistema detector de incendios
inteligente (Faisal Saeed et al., 2018). Como parte de su desarrollo se propuso el uso
de sensores, una unidad de procesamiento como el principal receptor del hogar, un
sistema de comunicación GSM y un sistema de alarma. Este sistema permitía detectar
incendios de manera temprana y, al mismo tiempo, el sistema GSM usado comunicaba
sobre el incendio a través de la nube. Asimismo, (Josué Toledo-Castro et al., 2018)
nos presenta el desarrollo de un sistema de identificación de incendios. Este sistema
propuesto usaba un Wireless Sensor Network, un servicio web y una aplicación móvil.
El WSN tenía como finalidad realizar un monitoreo ambiental en tiempo real. El
servicio web buscaba integrar el controlador de incendios basado en lógica difusa y el
estimador de propagación de incendios basado en AHP (Proceso Analítico Jerárquico)
con el objetivo de analizar la existencia de incendios forestales, detectando incendios
recientes y estimando la propagación de incendios. A pesar de ello, estas soluciones
se centran en la identificación de los incendios en tiempo real mediante el uso de un
sistema de prevención y una herramienta tecnológica complementaria. Sin embargo,
nosotros nos centramos en la identificación de manera temprana de incendios mediante
el uso de registros históricos y un algoritmo de predicción.
16
1.2 Dominio del Problema
1.2.1 Formulación del Problema
¿En qué medida un sistema de geolocalización de riesgo de incendios permitiría
optimizar el proceso de análisis e identificación de zonas de riesgo en Lima
Metropolitana?
1.2.2 Análisis del Problema

En base a la pregunta formulada, se detalla en la Tabla 1 el análisis del problema con
sus respectivas causas.
Problema y Causas
Problema Causas
• Tiempo de respuesta por parte de las
entidades técnico-científicas para
atender solicitudes sobre información
El ineficiente proceso de análisis e requerida para el correcto análisis de
riesgo de desastres. (INBP,2019)
identificación de riesgo de incendio
• Manejo de información no consolidada
en Lima Metropolitana, debido a la para la generación de escenarios de
falta de información sobre las zonas y riesgos por parte de INDECI o
Municipalidades. (CENEPRED,2020)
la disponibilidad de recursos. • Veracidad de información sobre el
estado de recursos disponibles para la
atención de desastres. (Agencia
Peruana de Noticias, 2016)
• Conocimiento escaso por parte de la
ciudadanía sobre zonas vulnerables a
incendios. (INEI,2016)
1.2.3 Importancia del problema

En los últimos años, uno de los desastres más comunes ha sido originados por los
incendios. Según un estudio realizado en el primer semestre del año 2019 por el
Instituto Nacional de Defensa Civil (INDECI), en Lima Metropolitana ocurrieron un
total de 148 incendios y 454 alrededor de todo el territorio peruano. Además, se logró
identificar que estos eventos generaron damnificar a más de 800 personas y causaron
la muerte de 9 ciudadanos. Por otra parte, según con el Cuerpo General de bomberos
voluntario del Perú, en el año 2019, la tercera emergencia más atendida fueron los
incendios llegando a ocurrir un total de 7007 a nivel Lima, Callao e Ica. En función
17
a lo anteriormente mencionado, se identifica que Lima es una de las ciudades más
afectadas por este tipo de desastres. De igual manera, según la defensoría del pueblo
en el año 2016, se realizó una fiscalización donde se identificó que el 34% de
hidrantes de los distritos de Lima y Callao tienen problemas de accesibilidad.
Además, se verifico que el 95.33% de los hidrantes no cuentan con ningún tipo de
señalización.
Debido a lo anteriormente mencionado, se identificaron diversas soluciones

tecnológicas que permiten gestionar y notificar la presencia de algún tipo de incendio
tanto en zonas urbanas como rurales. Un ejemplo de ello es la herramienta FireCity,
la cual es una aplicación que conecta en tiempo real los sistemas de alarmas contra
incendios dándole aviso al usuario y poniendo en alerta a la central de bomberos y
serenazgo. Esto es gracias a la creación de un panel de incendios que se conecta a
internet a través del aplicativo, y que envía esta información gestionada, analizada y
validada a través de un monitor web. De igual manera, en el mercado existe la
aplicación denominada AFIS (Sistema Avanzado de Información de Incendios), la
cual proporciona información acerca de los posibles puntos de riesgo, identificación
en tiempo real y data histórica de incendios. Una característica importante de esta
herramienta son los pronósticos de peligros de incendio, ya que utiliza pronósticos
climáticos como la velocidad del aire, temperatura y las estadísticas de incendio
según su ubicación. Sin embargo, este tipo de herramientas están enfocadas a
notificarte cuando el hecho ya ocurrió o esté en proceso. En consecuencia, no existe
actualmente alguna herramienta que te permita identificar las zonas donde es más
probable que ocurra este tipo de incidentes.
1.3 Motivación
El presente proyecto busca brindarle un servicio a la comunidad, mediante un sistema
de geolocalización desarrollado en una plataforma web y móvil, las cuales permitan
optimizar el proceso de análisis e identificación de zonas con un alto impacto en caso
ocurra un incendio, el cual podría ser usado por entidades públicas encargadas de
garantizar la seguridad ciudadana. Asimismo, esta solución permitirá tomar medidas
preventivas, reducir gastos económicos y disminuir la cantidad de ciudadanos
afectados.
18
1.4 Objetivos
1.4.1 Objetivo General
OG: Implementar un Sistema de Geolocalización de Riesgo de Incendios para
mitigar y reducir los posibles lugares de incendio en Lima Metropolitana
optimizando el uso de recursos y tiempo de análisis.
1.4.2 Objetivos Específicos

• OE1: Analizar las herramientas tecnológicas y algoritmos predictivos para el
sistema de geolocalización que permitan identificar las zonas de riesgo de
incendio.
• OE2: Diseñar la arquitectura tecnológica y el prototipo de la solución propuesta
con los métodos específicos que permitan la identificación de las zonas con
mayor riesgo de incendios.
• OE3: Validar que el funcionamiento del sistema desarrollado cumpla con los
requisitos establecidos y evaluar su efectividad al ser probado por un grupo de
usuarios.
• OE4: Elaborar un plan de continuidad que garantice que el sistema propuesto sea
viable tanto tecnológicamente como financieramente en el tiempo.
1.5 Indicares de Éxito

El cumplimiento de los objetivos del proyecto se mide a través de los siguientes
indicadores de logro:
Indicadores de Éxito
Indicador de éxito Objetivo
• Obtener el acta de aprobación por parte del
Product Owner del análisis de las diferentes OE1
IE1 herramientas tecnológicas y algoritmos
para identificar las zonas de riesgo de
incendio
IE2 • Obtener el acta de aprobación por parte del

Product Owner del diseño del sistema de
geolocalización propuesto. OE2
19
• Obtener documento de certificación del
diseño del Sistema de Geolocalización
aprobado por QS.
IE3 • Obtener acta de aprobación por parte del
Product Owner con respecto a la validación OE3
del sistema de geolocalización propuesto.
• Obtener el certificado de QS de las pruebas
de caja negra realizadas en los Sprint 5,6,7.
IE4 • Obtener acta por parte del Product Owner OE4
del plan de continuidad propuesto en el
proyecto.
1.6 Propuesta
La solución propuesta se basa en la identificación de zonas con una alta probabilidad de
riesgo de incendios, utilizando registros históricos de incendios ocurridos en los últimos
5 años y así localizar dichas zonas.
En primer lugar, esta solución consistirá en la recopilación de información de recursos

disponibles y registros de incendios reportados en las zonas definidas en el alcance de
este proyecto. Posteriormente, contar con una base de datos con dicha información y
mediante un algoritmo de predicción, el cual será ejecutado desde una aplicación web,
identificar la probabilidad de impacto que pueda tener un incendio en una determinada
zona. Dicha aplicación web, permitirá tanto la gestión del sistema de geolocalización
como la de los accesos a entidades públicas que utilizaran la herramienta, con el fin de
tomar medidas preventivas. Complementando la solución, se desarrollará una aplicación
móvil que será utilizado por el ciudadano y le permitirá visualizar zonas de riesgo y los
recursos cercanos a él.
20
2 CAPITULO 2: LOGROS DE LOS STUDENT OUTCOME
En este capítulo se describirán las actividades realizadas que forman parte de la evidencia
del cumplimiento de los siete Student Outcomes, los cuales pertenecen a la acreditación
ABET para la carrera de Ingeniería de Sistemas de Información de la Universidad Peruana
de Ciencias Aplicadas.
2.1 STUDENT OUTCOME 1

La capacidad de identificar, formular y resolver problemas complejos de
ingeniería aplicando los principios de ingeniería, ciencia y matemática.
En primera instancia, se desarrolló una ardua investigación con respecto al proyecto

asignado desde una perspectiva de ingeniería, es decir, la identificación de la
necesidad de mejorar el proceso de análisis e identificación de zonas de riesgo de
incendios. Dicho problema fue identificado mediante una investigación del contexto
actual a través de fuentes confiables como los repositorios Scopus, Web of Science,
IEEE Xplore, páginas web confiables y entrevistas con especialistas.
Posteriormente, en base a la investigación realizada se definió una necesidad la cual

fue discutido con el Product Owner, Portfolio Manager y expertos. Con todo lo
mencionado, se consideró necesario optimizar el proceso de análisis e identificación
de zonas de riesgo de incendio. Además, como parte del conocimiento adquirido para
realizar el proyecto, en la Tabla 3 se señala cada conocimiento como fue aplicado.
Conocimientos Aplicados
Conocimiento Aplicación
Matemáticas • Uso de fórmulas matemáticas para
el análisis de los indicadores de la
validación de la solución.
• Uso de fórmulas matemáticas para
el desarrollo del presupuesto del
proyecto.
• Uso de métricas para la gestión del
desarrollo del proyecto.
21
Ciencias • La investigación realizada para
para el desarrollo del Estado del
Arte.
Ingeniería • Desarrollar un sistema de
geolocalización buscando mejorar
el proceso de análisis e
identificación de zonas de riesgo
de incendio
• Analizar los resultados obtenidos
durante la validación para
identificar posibles mejoras.

La capacidad de aplicar el diseño de ingeniería para producir soluciones que
satisfagan necesidades específicas con consideración de salud pública, seguridad
y bienestar, así como factores globales, culturales, sociales, ambientales y
económicos.
Como parte de nuestro Objetivo Especifico 2 “Diseñar la arquitectura tecnológica y

el prototipo de la solución propuesta con los métodos específicos que permitan la
identificación de las zonas con mayor riesgo de incendios”, tuvimos la tarea de
elaborar del sistema de geolocalización propuesto. Para ello, en una fase inicial
realizamos una ardua investigación sobre las tecnologías, herramientas y
componentes que aportarán al desarrollo del sistema. Asimismo, se realizó el diseño
de una arquitectura tecnológica en lenguaje Archimate con sus respectivos atributos
de calidad, con la finalidad de garantizar el correcto funcionamiento de nuestra
solución.
Por otro lado, se modelaron los procesos involucrados haciendo uso de la notación
BPM para conocer como interactúan los principales actores con las aplicaciones web
y móvil que conforman el sistema propuesto. Además, se definieron las principales
funcionalidades de las aplicaciones con sus respectivos prototipos. Para validar la
22
conformidad de lo realizado, se llevó a cabo la certificación de estos a manos de la
empresa IT Services.
Finalmente, se necesitó la aprobación por parte de nuestro Product Owner con

respecto al documento que abarca todo lo explicado anteriormente. De esta manera
logramos reflejar la conformidad del diseño de la propuesta tecnológica tanto a nivel
interno como externo.

La capacidad de comunicarse efectivamente con un rango de audiencias.
Una de las claves para el cumplimiento eficiente de nuestro proyecto fue la

comunicación efectiva. En este proceso de comunicación intervinieron tanto el jefe
de Proyecto como el Scrum Máster, quienes entablaron comunicación constante con
el Portfolio Manager y Product Owner durante las reuniones virtuales, en las cuales
se elaboraron actas de reunión por cada sesión que se tuvo. De igual manera, se
realizó comunicación escrita mediante el correo electrónico UPC. Por otro lado, se
llegó a tener una comunicación con miembros de INDECI, con quienes se tuvo
reuniones virtuales y se compartió información mediante correo electrónico.

La capacidad de reconocer responsabilidades éticas y profesionales en
situaciones de ingeniería y hacer juicios informados, que deben considerar el
impacto de las soluciones de ingeniería en contextos globales, económicos,
ambientales y sociales.
Para la solución planteada de este proyecto, fue necesario el uso de fuentes y artículos
de investigación, en los cuales se ha respetado los derechos de autor y evitando la
usurpación de ideas. Asimismo, se usó la herramienta Turnitin con la finalidad de
realizar revisiones de los artefactos de la memoria del proyecto y evitar un posible
plagio. Por otro lado, la propuesta se realizó cumpliendo las necesidades de los
interesados y respetando las normas legales que correspondan.

La capacidad de funcionar efectivamente en un equipo cuyos miembros juntos
proporcionan liderazgo, crean un entorno de colaboración e inclusivo,
establecen objetivos, planifican tareas y cumplen objetivos.
23
El equipo de proyecto se conforma tanto de un Project Manager y un Scrum Master,
quienes establecieron objetivos de trabajo con sus respectivos indicadores de éxito
con la finalidad de satisfacer las necesidades del cliente resolviendo el problema
planeado a través de la implementación de un sistema de geolocalización de riesgo
de incendios. Además, se realizó un plan de trabajo con las actividades a realizar
durante cada semana del proyecto.
Asimismo, se trabajó constantemente con un Porfolio Manager y un Product Owner

quienes nos asesoraban durante cada fase del proyecto, con una revisión continua de
las tareas y objetivos establecidos en un inicio por el equipo de proyecto. Por otro
lado, la empresa IT Services, la cual ofrece servicios de prestación de recursos QS y
QA durante un periodo de tiempo que dependerá del tipo de tarea que se le asigne al
recurso, facilitaron las labores de búsqueda y análisis de artículos de investigación
como parte del estado del arte y marco teórico.
Finalmente, se solicitó a la empresa Software Factory, la asignación de dos recursos

de Software durante un determinado periodo, los cuales nos facilitaron las
actividades de desarrollo y despliegue de las aplicaciones web y móvil.

La capacidad de desarrollar y llevar a cabo la experimentación adecuada,
analizar e interpretar datos, y usar el juicio de ingeniería para sacar
conclusiones.
Como resultado principal del Objetivo Específico 3: “Validar que el funcionamiento

del sistema desarrollado cumpla con los requisitos establecidos y evaluar su
efectividad al ser probado por un grupo de usuarios".
En primer lugar, se realizaron pruebas de todos los requerimientos implementados

por los recursos QA de la empresa IT Services. Para eso se elaboró los planes de
prueba de la solución, alcanzado un resultado final de un 100% de éxito en los 82
casos de prueba realizados.
Durante la validación de la aplicación móvil participaron ciudadanos de 18 a 40 años,

los cuales simularon el caso de prueba de búsqueda de las zonas de riesgo de
incendios y recursos disponibles cercanos a una ubicación con la finalidad de tomar
la mejor decisión. Asimismo, la aplicación web fue validada por miembros de
24
INDECI encargados de la gestión de riesgos, los cuales simularon el caso de prueba
de análisis de una zona de riesgo de incendios con la finalidad de tomar medidas
preventivas.
Dentro del proceso de captura de datos, los evaluadores registraron el tiempo en el

que los usuarios se demoraron al momento de realizar el caso de prueba al que se les
asignaba. Para poder realizar la captura de datos se empleó Microsoft Forms; donde
se consideró el tiempo que se demoró el usuario y una encuesta de satisfacción en
base al uso de la aplicación.
Para el análisis de indicadores, se evaluaron las encuestas realizadas en Forms por

los usuarios. Cabe resaltar que cada uno de los indicadores evaluados se compararon
con los resultados de una encuesta propia antes de la implementación de la solución
y lo indicado en la reunión con los miembros de INDECI.
Para luego, presentar los resultados obtenidos relacionados al tiempo promedio de

análisis, tiempo promedio de búsqueda y satisfacción del usuario con la aplicación
como se muestra en la Tabla 4.
Resultados del Proyecto

Indicadores Resultados
Tiempo Promedio de Búsqueda (min) 5 min
Tiempo Promedio de Análisis (horas) 14 horas
Porcentaje de Satisfacción del Usuario • Usabilidad: 70% Muy Satisfecho
(Aplicación Móvil) • Eficacia: 55% Muy Satisfecho
• Interfaz: 55% Satisfecho
Porcentaje de Satisfacción del Usuario • Usabilidad: 67% Muy Satisfecho
(Aplicación Web) • Eficacia: 100% Satisfecho
• Interfaz: 67% Satisfecho
En conclusión, se pudo optimizar el tiempo de análisis de las posibles zonas de riesgo

de incendios usando la aplicación web en un 75%. De igual manera, se optimizo el
tiempo de búsqueda usando la aplicación móvil en un 90.6%. Asimismo, los
encuestados quedaron satisfechos con la usabilidad, eficacia e interfaz de las
aplicaciones.
25
Por otro lado, con la finalidad de mejorar nuestra solución nos brindaron
recomendaciones para tanto para la aplicación como para móvil. Con respecto a la
aplicación web, se recomendó el uso de información como la infraestructura de las
viviendas, cantidad de personas por lotes y los recursos disponibles. De igual forma
con la aplicación móvil, donde se recomendó la implementación de un marcado
rápido a la Central de Bomberos.

La capacidad de adquirir y aplicar nuevos conocimientos según sea necesario,
utilizando estrategias de aprendizaje apropiadas.
Para nuestro proyecto, utilizamos herramientas de búsqueda que le permitieron

obtener fuentes confiables sobre soluciones tecnológicas para identificar o prevenir
incendios y el uso de herramientas tecnológicas que nos permitan responder ante la
problemática planteada. En la Tabla 5 se detalla los elementos del proyecto que
permitieron conseguir y aplicar conocimientos.
Elementos del Proyecto

Elemento Conocimientos
Estado del Arte Se tomaron en cuenta artículos de
investigación que no excedan los cuatro
años de antigüedad.
Benchmarking de Herramientas Se investigo sobre las siguientes
Tecnológicas herramientas necesarias para desarrollar
nuestro sistema:
• Algoritmos Predictivos
• Plataformas Cloud
• API de Google Maps
• Sistema de Posicionamiento
Global (GPS)
Solución Tecnológica Propuesta Para nuestra solución consideramos los
siguientes aspectos:
• Registros de incendios urbanos e
hidrantes brindadas por los
26
miembros de INDECI, con la
finalidad de tener una solución
más precisa y confiable.
• Buenas prácticas de desarrollo y
seguridad utilizadas en la
actualidad.
• Infraestructura moderna y
sostenible.
Plan de Continuidad • Se considero la aplicación de un
Services Desk para garantizar la
gestión de los servicios de ITIL.
Además, en la Tabla 6 se detallan las técnicas, herramientas tecnológicas y

metodologías vigentes aplicadas a lo largo del proyecto.
Técnicas, Herramientas o Metodologías utilizadas en el proyecto

Técnicas, Herramientas Descripción
Tecnológicas o Metodologías
SCRUM Es un marco de trabajo ágil que permite
al equipo colaborar mediante iteraciones
o Sprints.
Benchmarking Comparación de herramientas para
definir aquellas que cumplen con los
criterios definidos.
Microsoft Azure Es un conjunto de servicios de pago en
nube que le permite a sus usuarios
desarrollar y administrar sus
aplicaciones.
Machine Learning Studio Es una herramienta colaborativa que se
puede usar para crear, probar e
implementar soluciones de análisis
predictivo
27
Api Google Maps Es un servicio de mapas de Google se
puede integrar con una aplicación web o
móvil con el objetivo de mostrar lugares
relevantes dentro de un mapa.
Android Studio Es una herramienta para desarrollar
aplicaciones para un sistema operativo
Android.
Azure App Services Es una de las herramientas que ofrece
Azure para crear, implementar y escalar
rápidamente mediante API y
aplicaciones web. 
MySQL Azure Es un servicio de base de datos relacional
que permite gestionar y realizar el
mantenimiento tanto de la
infraestructura como del servidor de
bases de datos en la nube.
Azure Cosmos DB Es un servicio de base de datos
NoSQL administrado para el desarrollo
de aplicaciones.
Heroku Es un servicio en la nube que soporta
aplicaciones desarrolladas utilizando
distintos lenguajes de programación.
Git Hub Es una plataforma colaborativa en nube
que permite el alojamiento de proyectos
con una fácil gestión de versiones.
3 CAPITULO 3: MARCO TEORICO

En este capítulo se describen los conceptos necesarios para la comprensión del
proyecto. En un inicio, se detallan los principales términos relacionados a la
tecnología y al entorno del proyecto.
28
3.1 Geolocalización
De acuerdo con (Zhao et al., 2019), la tecnología de geolocalización IP tiene como
objetivo obtener la ubicación geográfica de una dirección IP, como país, ciudad,
longitud y latitud. Actualmente, utilizado en marketing empresarial y seguridad de
red. Por ejemplo, después de obtener la ubicación del usuario, los proveedores de
servicios de Internet pueden diseñar anuncios dirigidos, ajustar de manera inteligente
el idioma y el contenido de las páginas web de acuerdo con las leyes locales, e
impulsar los pronósticos meteorológicos locales y la información de noticias.
Asimismo, el autor indicó la existencia de múltiples métodos para el uso de esta

tecnológica, una de ellas era mediante el uso de un dispositivo conectado a Internet,
con el objetivo de obtener datos en tiempo real y mostrarlos en un mapa con una gran
exactitud. Ciertos datos de geolocalización se pueden reunir de diversas formas:
• Dispositivos GPS
• Navegación web
• Transacciones con tarjetas
• Teléfonos inteligentes
• Identificación de radiofrecuencia (RFID)
3.1.1 Sistema de Geolocalización

Los Sistema de geolocalización son el resultado del uso de la tecnología que está
conformada por un conjunto de herramientas que permiten determinar la ubicación
de un objeto. Normalmente, el objeto suele ser un individuo que desea utilizar un
servicio basado en la ubicación. ("Evaluando Software”,2020)
Hemos podido investigar diferentes artículos donde presentan propuestas de como

usaron los sistemas de geolocalización en diversos ámbitos. Un caso fue el desarrollo
un sistema de geolocalización para determinar el tiempo aproximado de llegada de
un autobús de transporte público a la ubicación del pasajero (Azabache et al., 2018).
Donde gracias a esta solución se comprobó que había gran similitud entre la
ubicación real del vehículo y la ubicación que indicaba el sistema. Además, el tiempo
aproximado inicial correspondía con el real en condiciones donde no surgieron
eventos inesperados como accidentes o tráfico intenso.
29
Otro caso, fue un sistema de detección de fugas de agua basado en Machine Learning
(Wilmer P. Cantos et al., 2020). Esta solución se integra un algoritmo de
reconocimiento de patrones para la detección temprana de fugas y multiparamétricas
con una plataforma SIG (Sistema de Información Geográfica) para apoyar la
geolocalización de la fuente de fuga por medio del análisis de datos temporales y
espaciales; el método también permitirá evaluar la probabilidad de ocurrencia de las
fugas.
3.1.2 Herramientas de Geolocalización

En la actualidad, existen diversas herramientas tecnológicas que facilitan el servicio
de geolocalización. Las cuales en su mayoría funcionan en conjunto con aplicaciones
móviles. Hemos podido identificar las herramientas más usada en el mercado:
Sistema de Posicionamiento Global (GPS)
Es un sistema que permite establecer la posición de un objeto en coordenadas de

latitud y longitud en cualquier parte de la Tierra. Esta tecnología ha sido utilizada en
algunas soluciones con la finalidad de poder ubicar a una persona en situaciones de
emergencias.
De acuerdo con (Hannes Ecker et al., 2020), la tecnología GPS se puede utilizar para
ayudar a ubicar a personas tiene una emergencia basándose en los datos o
información más importante del que realiza la llamada. Sin embargo, en la actualidad
esta solución no se utiliza muy frecuentemente. Por dicha razón, el autor planteo un
método de geolocalización automática para llamadas de emergencia, lo cual permite
recibir la ubicación exacta de una persona que se encuentre en alguna emergencia y
poder mandar sin ningún problema a las ambulancias de manera inmediata. Este
nuevo método fue comparado con las llamadas tradicionales, logrando mejores
resultados que el método tradicional.
Api de Google Maps
Es un servicio de mapas brindado por Google Cloud Plataform, que ofrece diferentes
funcionalidades dentro de un mapa. Esta herramienta permite que los desarrolladores
integren los servicios de Maps en sus aplicaciones. Como las aplicaciones Uber,
WhatsApp, Waze.
30
Existen una gran cantidad de propuestas realizadas en donde destacan el uso del api
de Google Maps con la finalidad de poder integrarlos con su sistema y acceder a los
servicios que brinda. Un caso fue el desarrollo de un sistema basado en cloud
computing para monitorear remotamente y en cualquier momento a los pacientes
infectados con el Zika (Sanjay Sareen et al., 2017). Donde gracias a esta herramienta
se puede visualizar para evaluar las zonas de riesgo y redirigir a los usuarios por la
ruta más segura en estas áreas.
Otro caso fue el desarrollo de un sistema para monitorear el sonido en el ambiente en

tiempo real (Rajiv Kumar et al., 2017). Donde gracias a esta herramienta que trabaja
en conjunto con una aplicación, la cual recibe el código de nivel de ruido con su
respectiva coordenada de georreferencia y lo analiza para asignarle un color de
acuerdo con su nivel de ruido, posteriormente detecta la ubicación del usuario
y genera un mapa de nivel de ruido en un radio de 500 m desarrollado por la Api.
3.2 Big Data

De acuerdo con (Daekyo Jung et al., 2020), la tecnología Big data es usada también
para el manejo de desastres naturales, estos son resultado de la gran cantidad de datos
generados por el crecimiento explosivo de la tecnología de la información y las
comunicaciones. Al utilizar grandes conjuntos de datos, es posible analizar datos de
desastres pasados y desarrollar escenarios futuros para las posibilidades de desastres
y el daño causado por ellos.
Existen una gran cantidad de propuestas realizadas en donde destacan el uso de Big
Data como parte del análisis de datos. Un caso fue el desarrollo de un sistema de
pronóstico de inundaciones basado (Puttinaovarat & Horkaew, 2020). En esta
solución se utilizó el Big Data para monitorear y prevenir situaciones imprevistas es
una práctica que va cobrando fuerza, sobre todo en el campo de la prevención de
desastres naturales, concretamente las inundaciones, que son un problema que ataca
a muchas ciudades del mundo.
3.3 Análisis Predictivo

De acuerdo con (Espino, 2017), el término análisis predictivo es utilizado cuando se
habla de un modelo predictivo, el cual genera un análisis cualificado mediante estos
31
modelos. Sin embargo, este término se utiliza cada vez más para referirse a la
disciplina analítica, como los modelos descriptivos o decisivos. Estas disciplinas
suponen un análisis de datos exhaustivo que permita ser utilizado como una fuente
de ayuda en la toma de decisiones de entidades empresariales.
Por ello, podemos definir un modelo predictivo como una herramienta capaz para
predecir la manera en cómo actúa un individuo. Para llevar a cabo esta predicción es
necesario tener una entrada y una salida, en donde la entrada sería las características
distintivas del individuo y la salida vendría a ser la calificación predictiva luego del
análisis. Una manera en cómo se interpretan los resultados de la predicción es
mediante la calificación obtenida del análisis, es decir, a mayor calificación, mayor
es la probabilidad de que el individuo muestre la conducta predicha.
Sin embargo, para poder elaborar un análisis predictivo es necesario establecer el uso
de algoritmos. Para definir qué algoritmos serán utilizados, es necesario seguir un
orden que tenga en cuenta las siguientes acciones:
• Identificar los objetivos del modelo predictivo.
• Definir el conjunto de datos que se utilizará como entrada del modelo.
• Seleccionar los algoritmos que se aplicarán en el análisis predictivo.
A continuación, se presentará un análisis del trabajo realizado en (Zamorano, 2018),

donde se detalla la comparativa entre algoritmos de aprendizaje autónomo para la
predicción. Para ello, nosotros consideramos los algoritmos más relevantes y
relacionados al proyecto que se desarrollará.
Support Vector Machines (SVM)

De acuerdo con el autor, este algoritmo se suele aplicar para resolver problemas de
clasificación y regresión. Además, clasifican los datos creando hiperplanos que
segregan los datos. La identificación de estos hiperplanos es obligatoria para
clasificar los datos con una mayor precisión. Asimismo, existen 2 tipos de SVM, los
cuales son el Lineal y el Polinomial.
32
K-Nearest Neighbors
Según el autor, el algoritmo K-Nearest Neighbors, también llamado KNN, permite
el reconocimiento de patrones y correlaciones. Por otro lado, no asume la manera en
cómo están distribuidos los datos. A pesar de ello, este algoritmo puede ser una buena
primera opción en caso no se tenga un amplio conocimiento en cómo están
distribuidos los datos a utilizar.
Random Forest Classifer

Con respecto a este algoritmo, el autor afirma que funciona utilizando un árbol de
decisión para encontrar un clasificador más preciso. Cada árbol de decisión es
construido a partir de una secuencia aleatoria de subconjuntos de datos del conjunto
de entrenamiento. A diferencia de los árboles de decisión, los nodos que necesitan
dividir datos eligen la mejor división de un subconjunto aleatorio del conjunto
completo de funciones en lugar de obtener el atributo de mayor ganancia.
Neural Networks
De igual forma, se ha señalado que las redes neuronales son una técnica no lineal que
puede modelar funciones complejas. Se puede aplicar a problemas de predicción,
clasificación o control en diversas disciplinas, como finanzas, psicología
cognitiva/neurociencia, medicina, ingeniería y física.
De manera similar, este algoritmo se usa típicamente cuando no se ha identificado la

naturaleza de la relación entre los valores de entrada y salida. Sin embargo, una
función importante de las redes neuronales es la capacidad de aprender la relación
entre los valores de entrada y salida a través de un entrenamiento de datos.
3.4 Cloud Computing

De acuerdo (Microsoft Azure,2020), la computación en la nube proporciona servicios
informáticos como servidores, almacenamiento, bases de datos, redes, software,
análisis e inteligencia a través de Internet, lo que proporciona una innovación más
rápida, recursos flexibles y economías de escala. Con este servicio, se puede pagar los
servicios en la nube que usa, disminuir los costos operativos, administrar dichos
33
servicios de forma eficiente y escalar a medida que cambian las necesidades de su
negocio.
3.4.1 Beneficios
De acuerdo con (Microsoft Azure,2020) estas son las siete razones principales por
las que una organización opta por el uso de los servicios de computación en la nube:
o Costo: Con los servicios de computación en la nube, puede reducir el costo de

comprar hardware y software.
o Velocidad: Los servicios en la nube se adquieren como autoservicio y bajo
demanda, por eso incluso los recursos de TI pueden ser provisionados en cuestión
de minutos.
o Escala Global: Los servicios de computación ayudan a la distribución correcta de
recursos de TI cuando sean necesarios y desde la ubicación geográfica correcta.
o Rendimiento: Los servicios en la nube se ejecutan en una red mundial de centros
de datos, los cuales son actualizados con hardware de última generación con la
finalidad de ofrecer un servicio más rápido y eficiente.
o Productividad: Los servicios en la nube nos ayudan a evitar realizar tareas de
administración de recursos de TI. Con esto las áreas de TI pueden dedicar tiempo
a alcanzar objetivos más importantes.
o Fiabilidad: Este servicio permite que la generación de copias de seguridad de
datos, la respuesta ante un desastre y la continuidad del negocio sean fáciles de
atender y económicas al permitirle duplicar sus datos en múltiples ubicaciones
redundantes en la red de su proveedor de nube.
o Seguridad: Existen proveedores en la nube que ofrecen un amplio conjunto de
políticas, tecnologías y controles con la finalidad de proteger sus recursos de
posibles amenazas.
3.4.2 Modelos de Servicio

Infrastructure as a Service (IaaS)
Proporciona infraestructura de TI como servidores máquinas virtuales, redes,
sistemas operativos, almacenamiento con modo de pago por uso. La principal ventaja
de IaaS es el uso de la última tecnología en todo momento con respecto a la
infraestructura TI, lo cual permite a los usuarios obtener un servicio de manera más
34
rápido. Las organizaciones utilizan IaaS para crear de una manera rápida nuevas
versiones de sus aplicaciones sin tener demoras innecesarias por compra o
configuración.
Platform as a Service (PaaS)

Es una plataforma compatible con la comunidad de desarrolladores, ya que permite
la integración de servicios web, la integración de bases de datos, la seguridad, la
escalabilidad, el almacenamiento y los servicios de instrumentación de aplicaciones,
además del diseño y el desarrollo de aplicaciones.
Software as a Service (SaaS)

El software como servicio permite la entrega de ciertas aplicaciones de software ya
empaquetadas como servicios remotos que se ofrecen a través de Internet. Asimismo,
permite alojar y administrar aplicaciones de software y su infraestructura, brindando
mantenimiento, como actualizaciones de software y parches de seguridad. La
conexión a las aplicaciones se realiza mediante un navegador web por parte de los
usuarios.
3.4.3 Plataformas Cloud\
Microsoft Azure
De acuerdo con (Microsoft Azure, 2020), es un servicio en la nube creado por
Microsoft en el 2008, cuyo nombre inicial fue el de Project Red Dog. Actualmente,
brinda sus servicios en la nube para crear, probar, implementar y administrar
aplicaciones y servicios utilizando sus centros de datos. Asimismo, proporciona
software como servicio (SaaS), plataforma como servicio (PaaS) e infraestructura
como servicio (IaaS), los cuales son compatible con una amplia variedad de
lenguajes, herramientas y marcos de programación, incluidos software y sistemas
específicos de Microsoft y de terceros.
Amazon Web Services

Según (Amazon Web Services Inc, 2020), es una colección de servicios en la nube
publica, ofrecidas a través de internet, la cual se comenzó a ofrecer en el 2006 por la
35
empresa Amazon. Además, Amazon Web Services proporciona una plataforma de
infraestructura rentable, confiable y escalable en la nube que brinda soporte a cientos
de miles de empresas en 190 países de todo el mundo.
Google Cloud Platform

En (Google Cloud, 2020) se señala que se trata de una plataforma que engloba varios
servicios que se ejecutan sobre la misma infraestructura que utiliza Google
internamente. Además, la plataforma administra herramientas como computación en
la nube, redes, almacenamiento de datos, análisis de datos y aprendizaje automático.
3.4.4 Modelos de Implementación
Private Cloud
Las nubes privadas se refieren a los recursos de TI alojados en la nube los cuales son
consumidos exclusivamente por una organización. Una nube privada se puede ubicar
físicamente en el centro de datos de una empresa. Sin embargo, algunas
organizaciones eligen un proveedor externo para alquilar espacio de almacenamiento
en su nube privada.
Public Cloud
Las nubes públicas son aquellas que se operan por parte de un proveedor de servicios
de nube que hace que los recursos informáticos estén disponibles a través de Internet.
Asimismo, en una nube pública, tanto el hardware, software y otras infraestructuras
de soporte serán administrada por el proveedor de la nube.
Hybrid Cloud
Las nubes híbridas son la combinación entre públicas y privadas, las cuales son
unidas por tecnología con la finalidad de compartir datos y aplicaciones entre ellas.
Asimismo, una nube híbrida puede ofrecer diferentes ventajas como una mayor
flexibilidad, más apoyo para la implementación y mejorar la seguridad.
36
3.5 Estándares de Calidad
ISO / IEC / IEEE 29119

El propósito de la serie ISO/IEC/IEEE 29119 de estándares de pruebas de software,
según (ISO, 2013), es definir un conjunto internacionalmente acordado de estándares
para la ejecución de pruebas de software que pueden ser utilizados por cualquier
organización al realizar cualquier forma de prueba de software.
Este estándar se definió en las siguientes 5 secciones:

• ISO/IEC/IEEE 29119-1:2013, Parte 1: Conceptos y definiciones
• ISO/IEC/IEEE 29119-2:2013, Parte 2: Procesos de prueba
• ISO/IEC/IEEE 29119-3:2013, Parte 3: Documentación de prueba
• ISO/IEC/IEEE 29119-4:2015, Parte 4: Técnicas de prueba
• ISO/IEC/IEEE 29119-5:2016, Parte 5: Pruebas basadas en palabras clave
ISO 9001
De acuerdo con (ISOTools, 2020), la ISO 9001 es una norma internacional elaborada
por la Organización Internacional para la Estandarización (ISO) que es aplicada a los
Sistemas de Gestión de Calidad de organizaciones públicas y privadas. Proporciona
un método de trabajo que permite mejorar la calidad y la satisfacción del cliente de
sus productos y servicios. Por lo tanto, estándares como la ISO 9001 brindan a las
empresas una ventaja competitiva.
ISO 25010
Según (ISO, 2011), la ISO 25010 define dos modelos de la siguiente manera:
• Un modelo de calidad en uso compuesto por cinco características
relacionadas con el resultado de una interacción cuando un producto se utiliza
en un contexto de uso particular. Este modelo de sistema se puede aplicar a
todo el sistema humano-computador, incluido el sistema informático en uso
y los productos de software en uso.
37
• Un modelo de calidad del producto compuesto por ocho características que
están relacionadas con las características estáticas del software y las
propiedades dinámicas de un sistema informático. Este modelo es aplicable
tanto a sistemas informáticos como a productos de software.
4 CAPITULO 4: DESARROLLO DEL PROYECTO

4.1 Análisis
4.1.1 Análisis del Problema
En la actualidad, los incendios urbanos corresponden al 79% de los eventos de
desastre que se registran en la ciudad de Lima, llegando a afectar viviendas,
industrias y áreas comerciales. Un claro ejemplo de este tipo de evento fue el
incendio de mesa redonda ocurrido a las 19:15 del sábado 29 de diciembre de 2001,
en donde se logró identificar la muerte de 277 personas, casi 500 personas heridas,
centenares de desaparecidos, y restos humanos no identificados. Por otro
lado, instituciones como INDECI o el CENEPRED tienen como objetivo principal
reducir las vulnerabilidades y prevenir la generación de nuevos riesgos en la
población de Lima Metropolitana a través de la gestión de programas, proyectos y
acciones que incorporen la prevención y reducción de riesgo de desastres. Sin
embargo, según Mario Valenzuela, Ingeniero Geógrafo Especialista en Gestión de
Riesgo de Desastres en INDECI, indicó que el proceso que conlleva
realizar los planes de respuesta depende de la disponibilidad de la información por
parte de otras entidades. Esto se ve reflejado en el tiempo que se necesita para la
identificación de zonas de riesgo, ya que se elaboran simulaciones de riesgo y
evalúan distintos aspectos para determinar si una zona debe ser considerada riesgosa
o no. Aparte de lo anteriormente mencionado, consideramos que es necesario
conocer la opinión de los ciudadanos, ya que son ellos quienes podrían ser víctimas
de este tipo de eventos. Para ello, en 2018 se realizó una encuesta a una muestra de
1920 personas de 18 años a más en Lima Metropolitana, elaborada por el Instituto de
Opinión Pública de la PUCP (IOP-PUCP). Una de las preguntas formuladas estaba
relacionada con la sensación de seguridad con respecto a sus viviendas frente a
diversos desastres, la cual permitió identificar que el 33.6% de los entrevistados se
manifestó inseguro en sus viviendas ante un incendio. Sin embargo, estas cifras
38
aumentaron al observar los resultados por nivel socioeconómico. En el caso de los
incendios, el porcentaje se elevó hasta un 52.2% para el sector D/E.
4.1.2 Análisis del Mercado

• Smoke Detective
Es una plataforma que convierte a cualquier dispositivo con cámara en un detector
de humo. Esto lo hará mediante un algoritmo que permitirá procesar las imágenes y
videos a través de la cámara de tu celular en un ambiente determinado. (Mizrahi,
2019)
Cuando el humo es detectado, activa una alarma y envía un mensaje que ayuda a
alertar a todos que se encuentran en el lugar. Incluso, la detección de humo es más
rápido que un detector convencional. (Mizrahi, 2019)
Figura 1: Aplicación Móvil Smoke Detective
Fuente: (Mizrahi, 2019)

• FireCity
Es una aplicación que conecta en tiempo real los sistemas de alarmas contra incendios
dándole aviso al usuario y poniendo en alerta a la central de bomberos y serenazgo.
Esto es gracias a la creación de un panel de incendios que se conecta a internet a
través del aplicativo, esta información será gestionada y analizada a través de un
monitor web. El aplicativo funciona de la siguiente manera: El detector de humo
percibe alguna anomalía en el ambiente y emite una alarma al dueño de la propiedad,
además recibirá una notificación y la señal de la alarma mediante la app. La
aplicación notificará sin importar donde te encuentres gracias a la monitorización y
39
visualización gráfica, lo que brindará el aviso en el momento oportuno a los
bomberos y serenazgos. (Publimetro, 2020)
Actualmente en Perú, los bomberos ya monitorean los edificios donde hacen uso
de FireCity, se espera que pueda haber más personas hagan uso de esta aplicación.
(Publimetro, 2020)
Figura 2: Aplicación Móvil Fire City
Fuente: (Publimetro, 2020)
• Wildfire Analyst Pocket Edition

Es una aplicación que predice el comportamiento de los incendios forestales con la
finalidad de ayudar a los cuerpos de bomberos a mejorar el ataque inicial y
comprender mejor el comportamiento del fuego logrando así aminorar pérdidas
humanas. Por lo tanto, esta aplicación ha sido creada para ser usada por el personal
de extinción de incendios forestales. Esta mostrará al usuario las características
puntuales del incendio y la progresión basada en los datos introducidos y los
resultados se presentarán en un mapa en 3D permitiendo que el usuario pueda
cambiar los parámetros y pueda analizar el comportamiento del fuego. (Fraga, 2018)
Además, cuenta con capacidades de Sistemas de Información Geográfica (SIG)
integradas, funciona en zonas con cobertura telefónica limitada y datos
meteorológicos de las estaciones meteorológicas cercanas en el punto de incendio.
(Fraga, 2018)
40
Figura 3: Aplicación Móvil Wildfire Analyst Pocket Edition
Fuente: (Fraga, 2018)
4.1.3 Análisis de las Herramientas

4.1.3.1 API de Google Maps
Es un servicio de mapas de Google se puede integrar con una aplicación web o móvil
con el objetivo de mostrar lugares relevantes como cafeterías, aeropuertos, tiendas
cercanas mediante marcadores dentro de un mapa. Además, nos permite calcular el
tiempo de viaje usando datos históricos de horarios.
Figura 4: API de Google Maps
Fuente: (Google Cloud Blog, 2020)
4.1.3.2 Sistema de Posicionamiento Global (GPS)

Es un sistema que permite establecer la posición de un objeto en coordenadas de
latitud y longitud en cualquier lugar de la Tierra. Esta tecnología ha sido utilizada en
varias soluciones con la finalidad de poder ubicar a una persona en situaciones de
emergencias.
41
De acuerdo con (Hannes Ecker et al., 2020), la tecnología GPS se puede utilizar para
ayudar a ubicar a personas tiene una emergencia basándose en los datos o
información más importante del que realiza la llamada. Sin embargo, en la actualidad
esta solución no se utiliza muy frecuentemente. Por dicha razón, el autor planteo una
solución que, en conjunto con una aplicación, nos permite ayudar a que se pueda
explicar a una persona lo que puede realizar en caso de paros cardiacos. Aparte de
permitir recibir la ubicación exacta de las personas y poder mandar sin ningún
problema a las ambulancias de manera inmediata.
Figura 5: ¿Qué es GPS?
Fuente: (Carvalza, 2020)
4.1.3.3 Benchmarking de algoritmos predictivos
Para la identificación del algoritmo que deseamos utilizar, se realizó un

benchmarking con criterios de aceptación definidos por el equipo y sustentados
por los estudios anteriormente mencionado y otros artículos.
Como podemos observar en la Tabla 7, tenemos los criterios de evaluación
que hemos definido con su respectiva descripción del puntaje con la finalidad de
definir el algoritmo.
42
Descripción del puntaje de calificación para los Algoritmos Predictivos
1-2 3-4 5
Criterios
Muy malo Regular Muy Bueno
Exactitud El algoritmo no El algoritmo El algoritmo

asegura una buena asegura asegura
exactitud durante una exactitud una exactitud
las pruebas regular durante las alta durante las
pruebas pruebas
Precisión El algoritmo no El algoritmo El algoritmo

asegura la precisión asegura la precisión asegura una alta
para predecir el para predecir el precisión para
desastre desastre predecir el desastre
Tiempo de El algoritmo tiene El algoritmo tiene El algoritmo tiene

Entrenamiento un tiempo de un tiempo de un tiempo de
entrenamiento alto entrenamiento entrenamiento alto
moderado
Usado en El algoritmo no es El algoritmo es

incendios usado en predicción usado en predicción
de incendios de incendios
generales urbanos
En base a los artículos y estudios revisados durante la investigación sobre el

funcionamiento de los algoritmos de predicción comparados. Se pudo recopilar los
siguientes datos:
• PRECISIÓN
Con respecto a la precisión de los algoritmos evaluados, tenemos que

(Choubin et al., 2019) propone desarrollar un modelo de predicción de riesgo
en la tierra. Para eso se realizó una comparación de diversos algoritmos de
predicción, entre ellos se encontró el Random Forest y el SVM. Los
43
resultados nos indicaron que el RF, tiene una precisión del 95%. Mientras que
el SVM solo alcanzó un 90% de precisión.
Asimismo, tenemos que (Puttinaovarat & Horkaew, 2020), presenta un

sistema de pronóstico de inundaciones integrado con un framework de
machine learning. Para eso se evaluaron diversos algoritmos como el Random
Forest y el SVM. Los resultados nos indicaron que el RF, tiene una precisión
del 96.7%. Mientras que el SVM solo alcanzo un 96.8% de precisión.
De igual manera, tenemos que (Kaur & Sood, 2020), propone desarrollar una
presentan una arquitectura en capas basadas en IoT para hacer una predicción
correcta de las condiciones de sequía. En dicho artículo se evaluaron los
algoritmos ANN, SVM y KNN, los cuales obtuvieron un nivel de precisión
de 88.9%, 96,8% y 87% respectivamente.
Por otro lado, tenemos que (Khan et al., 2019), realizó una comparación de
ciertos algoritmos de predicción como SVM y KNN. En dicha comparación
se destaca el nivel de precisión que obtuvieron dichos algoritmos. El
algoritmo KNN obtuvo un nivel de precisión del 91% y el SVM tuvo un 95%.
Finalmente, tenemos que (Anbarasan et al., 2020), presentaron un método

para la detección del sistema de desastres por inundación basados en IoT, BD
y CDNN con el fin de superar ciertas dificultades. En dicho artículo se realizó
una comparación de algoritmos de predicción y se indicó que el algoritmo
ANN tiene una precisión de 83.8% al usar 500 datos.
• EXACTITUD
Con respecto a la precisión de los algoritmos evaluados, tenemos que

(Choubin et al., 2019) propone desarrollar un modelo de predicción de riesgo
en la tierra. Para eso se realizó una comparación de diversos algoritmos de
predicción, entre ellos se encontró el Random Forest y el SVM. Los
44
resultados nos indicaron que el RF, tiene un nivel de exactitud de 95% y el
SVM alcanza un 92%.
Asimismo, tenemos que (Sayad et al., 2019), proponen un modelo para

predecir los incendios forestales. En dicho artículo se realizó una
comparación de los algoritmos SVM y ANN. Los resultados nos indicaron
que el algoritmo ANN tiene un nivel de exactitud del 98.3% y el SVM alcanzo
un 97.5%.
De igual manera, tenemos que (Khan et al., 2019), presentaron una

comparación de algoritmos de predicción. Entre ellas se encuentran los
algoritmos de SVM y KNN. En dicho artículo, se indicó que el algoritmo
SVM tiene un nivel de exactitud de 97.4%. Mientras que el algoritmo KNN
alcanza un nivel de 91.7%.
Igualmente, tenemos que (Cantos et al., 2020), presentan un método de

evaluación de riesgos basado en machine learning (ML-RAM), que integra
un algoritmo de reconocimiento de patrones para la detección temprana de
fuga. En dicho artículo se compararon los algoritmos ANN y SVM. Los
resultados nos indicaron que el algoritmo SVM tiene un nivel de exactitud de
83.9% y el ANN un 92.6%.
Por otro lado, tenemos que (Kaur & Sood, 2020), presentan una arquitectura
en capas basadas en IoT para hacer una predicción correcta de las condiciones
de sequía. Para eso se compararon algoritmos de predicción como KNN y
ANN.Los resultados nos indicaron que el KNN tiene un nivel de exactitud de
92 % y el ANN un nivel de 93.8%.
Finalmente, tenemos que (Anbarasan et al., 2020), presentaron un método

para la detección del sistema de desastres por inundación basados en IoT, BD
y CDNN con el fin de superar ciertas dificultades. En dicho artículo se realizó
una comparación de algoritmos de predicción y se indicó que el algoritmo
ANN tiene una exactitud de 84.8% al usar 500 datos.
45
• TIEMPO DE ENTRENAMIENTO
Con respecto al tiempo de entrenamiento de los algoritmos evaluados,

tenemos que (Khan et al., 2019), presentaron una comparación de algoritmos
de predicción. Entre ellas se encuentran los algoritmos de SVM y KNN. En
dicho artículo, se indicó que el algoritmo SVM tiene un tiempo de
entrenamiento de 7.5003 segundos, mientras el algoritmo KNN tiene un
tiempo de entrenamiento de 1.3133 segundos.
Finalmente tenemos que (Microsoft,2020), presenta una comparación de

diversos algoritmos de predicción. Entre ellas se encuentran los algoritmos
ANN y Random Forest. En dicho artículo, se indicó que el algoritmo Random
forest y el ANN tienen un tiempo de entrenamiento moderado. Sin embargo,
esto dependerá del número de datos que utilice.
• USO EN INCENDIOS
Con respecto al uso en incendios de los algoritmos evaluados, tenemos que

(Yu et al., 2017), presentan un proceso de predicción y detección de incendios
utilizando los algoritmos SVM y Random Forest.
Asimismo, tenemos que (Sayad et al., 2019), presentaron los algoritmos de

predicción llamados SVM y ANN para el desarrollo de un modelo con la
finalidad de predecir los incendios forestales.
Finalmente, tenemos que (Kumar et al., 2020), un modelado basado en el

aprendizaje automático con finalidad de poder predecir las zonas más
vulnerables a este tipo de desastres, para eso se utilizó el algoritmo de
predicción llamado Random Forest.
46
Resultados del Benchmarking
Resultados del Benchmarking de Algoritmos Predictivos
Random Forest Support Vector Redes K-Nearest

Criterios
Classifer Machines Neuronales Neighbors
Exactitud 4 3 4 2
Tiempo de 3 3 3 4
Entrenamiento
Precisión 5 4 3 4
Usado en 5 5 3 1
incendios
Total 17 15 13 11
Como se observa en la Tabla 8, para la predicción de incendios urbanos el algoritmo

que cumple con los criterios es el “Random Forest Classifer”, además de tener mayor
precisión a los terremotos. Por ello, se ha concluido que el algoritmo “Random Forest
Classifier” es la mejor opción para la predicción de desastres naturales de todo tipo,
porque cumple con mayor precisión y exactitud. Sin embargo, el algoritmo “SVM”
podría ser utilizados para otro tipo de proyectos, ya que es una muy buena segunda
opción.
4.1.3.4 Benchmarking de plataformas Cloud

A continuación, se presentará un análisis del trabajo realizado en (Joshi & Shah,
2019), se detalla la comparativa entre plataformas Cloud. Para ello, nosotros
consideramos las plataformas Cloud más relevantes para el proyecto.
Para la identificación de la plataforma que deseamos utilizar para el desarrollo de
nuestra aplicación, se realizó un benchmarking con criterios de aceptación definidos
por el equipo.
Como podemos observar en la Tabla 9, tenemos los criterios de evaluación con su

respectiva descripción del puntaje. Asimismo, en la tabla 6, hemos recopilado las
características de dichas plataformas en relación con cada criterio.
47
Descripción del puntaje de calificación para las Plataformas Cloud
Criterios 1-2 3-4 5
Plataforma de No cumple para Cumple para Cumple para ambos
Aplicación aplicación web y aplicación web o tipos de
móvil aplicación móvil aplicaciones
Soporte para No cuenta con Cuenta con algunos Cuenta con muchos
Lenguajes muchos lenguajes lenguajes de lenguajes de
de programación soport programación soport
programación sopor adas adas
tadas
Escalabilidad No es adaptable Es poco adaptable Si es altamente
para su uso para su uso adaptable para su
masivo de usuarios masivo de usuarios uso masivo de
usuarios
Seguridad No cuenta con Cuenta con algunos Cuenta con varios
mecanismo para mecanismos para mecanismos para
proteger proteger los recursos proteger los recursos
los recursos inform informáticos informáticos.
áticos
Costo El costo de uso es El costo de uso es El costo de uso es
muy elevado regular bajo
Soporte técnico No cuenta con Cuenta con algún Si cuenta con
gratuito soporte técnico tipo de soporte soporte técnico
gratuito gratuito
En la Tabla 10, podemos observar las características de cada plataforma Cloud a comparar.
Para eso se revisó la información que brinda en sus respectivas páginas web. Asimismo, se
tuvo en cuenta artículos de investigación donde se comparaba las funcionalidades de dichas
plataformas.
Características de las Plataformas Cloud
Criterios GCP AWS Azure

Plataforma de Web y Mobile Web y Mobile Web y Mobile
Aplicación
Soporte para Go, Java, .NET, Android, Browser, .NET, PHP, C++, Ruby,
Lenguajes Node.js, PHP, iOS, Java, .NET, Java, Node JS, Python
Python, Ruby Node.js, PHP, Python,
Ruby, Go, C++, AWS
48
Mobile SDK y AWS
IoT Device SDK
Escalabilidad Construido en Escalabilidad Escalabilidad automática
escalabilidad (Big automática (Amazon (Autoscaling Application
Table y GFS) Cloud Watch) block y Windows Azure
Fabric Controller)
Seguridad Reglas de acceso AWS Identity and Copias de Seguridad
con el cortafuegos Access Management cifradas
de App Engine Key Vault. Protege las
claves criptográficas
Costo Costo por uso Costo por uso Costo por uso
Soporte técnico Si No Si
gratuito
Resultados del Benchmarking

Como se puede observar en la tabla 11, la plataforma más versátil y que gana en la
comparación es Microsoft Azure, debido a que cuenta con un menor precio,
disponible para aplicaciones web y Mobile.
Resultados del Benchmarking de las Plataformas Cloud

Plataforma de Aplicación 5 5 5
Soporte para Lenguajes 3 3 5
Escalabilidad 3 5 5
Seguridad 4 4 4
Costo 3 3 4
Soporte técnico gratuito 4 2 4
Total 22 22 27
4.1.4 Servicios de Azure
La plataforma de nube Microsoft Azure ofrece una amplia variedad de herramientas

y servicios, las cuales son capaces de responder las necesidades de los
usuarios. Dentro de algunos de sus servicios hemos considerado elegir los
siguientes:
49
4.1.4.1 App Service
Es una herramienta que nos ofrece Microsoft Azure para crear, implementar y
escalar rápidamente mediante API y aplicaciones web. Asimismo, nos permite
trabajar con diferentes lenguajes de programación, en contenedores o ejecutándose
en Windows o Linux. Por otro lado, nos permite satisfacer los requisitos de
rendimiento, seguridad y cumplimiento normativo usando una plataforma de
confianza totalmente administrada que puede controlar más de 40 000 millones de
solicitudes al día.
Figura 6: Infraestructura del App Service
Fuente: (Microsoft Azure, 2020)
4.1.4.2 Azure Machine Learning Studio
Es una herramienta colaborativa que nos permite crear, probar e implementar

soluciones de análisis predictivo. Asimismo, nos brinda un espacio de trabajo visual
e interactivo. También permite trabajar con conjuntos de datos y módulos de análisis
en un lienzo interactivo, conectándolos para formar un experimento. De igual
manera, facilita el diseño del modelo, editar el experimento, almacenar una copia en
caso quiera volver a ejecutarlo. Una vez esté
listo, podemos convertir nuestro experimento de entrenamiento en un experimento
predictivo y luego publicarlo como un servicio web para que otros puedan acceder a
su modelo, ya sean aplicaciones personalizadas o herramientas de BI como Excel.
50
Figura 7: Modelo Predictivo en Azure
4.1.4.3 Azure Database for MySQL
Es un servicio de base de datos relacional que nos ayuda a automatizar la

administración y el mantenimiento tanto de la infraestructura como del servidor de
bases de datos. Además, nos permite obtener las actualizaciones rutinarias y las
copias de seguridad.
Figura 8: Azure Database for MySQL
51
4.1.4.4 Azure Cosmos DB
Es un servicio administrado de base de datos NoSQL para el desarrollo de

aplicaciones. Sus principales ventajas son garantizar tiempos de respuesta menores a
diez milisegundos y brindar una disponibilidad del 99.9% en cualquier parte del
mundo. Asimismo, se puede utilizar como base de datos para aplicaciones escritas
para Mongo DB.
Figura 9: Azure Cosmos DB
4.2 Arquitectura Tecnológica

4.2.1 Diseño de la Arquitectura Tecnológica
En esta sección, se describirá el desarrollo del diseño de la arquitectura tecnológico
para la gestión del sistema propuesto.
52
Figura 10: Arquitectura Tecnológica del Sistema
Fuente: Elaboración propia
53
4.2.1.1 Capas de la Arquitectura Tecnológica
La Arquitectura tecnológica del sistema propuesto se encuentra dividida en las siguientes
capas:
• Capa de presentación
Es la capa donde la presentación del sistema con la que se comunica y captura la
información del usuario. Además, es conocida como la interfaz gráfica, la cual debe tener
como característica ser amigable para los usuarios. Esta capa se comunica únicamente
con la capa lógica del sistema.  
• Capa lógica
Es la capa donde residen los programas que se ejecutan, se reciben las peticiones del
usuario y se envían las respuestas tras el proceso. Además, es conocida como capa lógica
del negocio, ya que se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la capa de presentación con la finalidad de recibir las solicitudes y
presentar los resultados. Asimismo, se comunica con la capa de datos, para realizar las
solicitudes a los gestores de base de datos.
• Capa de datos
Es la capa donde residen los gestores de base de datos, los cuales realizan el
almacenamiento de datos, reciben solicitudes de recuperación de la información por
parte de la capa lógica del sistema.
4.2.1.2 Descripción de los componentes de la Arquitectura

A continuación, se describirán los componentes de la arquitectura tecnológica del sistema
propuesto.
Nodos de la Arquitectura Tecnológica

Nodo Responsabilidad Restricción
Smartphone Dispositivo móvil con sistema Ninguna

operativo Android para usar el
aplicativo móvil.
54
Servidor Servidor con sistema operativo Ninguna
Windows para usar el aplicativo web.
Servidor de Nodo donde se desplegará las Ninguna

Azure aplicaciones web y móvil.
Servidor Externo Servidor externo donde se encuentran Ninguna

los servicios de Google
(Google Maps).
Servidor Backup Servidor donde se almacenera las Ninguna

copias de seguridad de los datos.
Servidor Indeci Servidor de Indeci que proveerán la Ninguna

información necesaria para analizar
las posibles zonas de riesgo de
incendio.
Interfaces de la Arquitectura Tecnológica

Interfaces Responsabilidad Restricción
API Google Interfaz que permite obtener los Se utilizará para la aplicación
Maps mapas de Google maps para web y móvil
las aplicaciones.
Interface móvil Interfaz que permite conectar Ninguna

el front end con el backend de la
aplicación móvil.
Interface web Interfaz que permite conectar Ninguna

el front end con el backend de la
aplicación web.
API Machine Interfaz que permite el análisis Se utilizará para la aplicación

Learning predictivo de las zonas de riesgo de web.
Azure incendio
55
Software de Sistemas de la Arquitectura Tecnológica
Software de Sistemas  Responsabilidad  Restricción
Servidor de Servidor donde se desplegarán ambas Se encontrarán la

Aplicaciones  aplicaciones  aplicación móvil y web
desarrolladas.
Web Service  Es una tecnología que utiliza un Servicio utilizado para la
conjunto de protocolos y estándares que aplicación web y móvil.
sirven para intercambiar datos entre
aplicaciones 
Instancia BD  Instancia de base de datos en donde se Utilizará el gestor de BD
almacenará la información de las MySQL para gestionar la
aplicaciones  información entre las
aplicaciones.
Mongo DB Gestor de Base de datos que se Versión 3.6
encargará tendrá el sistema, el cual
se encontrará en una plataforma Azure. 
Instancia BD - Instancia de base de datos en donde se Utilizará el gestor de Base
Predictiva almacenará la información necesaria de datos Mongo DB para
para el análisis predictivo realizar el análisis
predictivo.
Plataforma Azure  Plataforma donde que soporta el Permitirá tener en la nube
servidor Azure  tanto las bases de datos
como las aplicaciones
desplegadas.
Instancia Backup  Instancia de base de datos de Utilizará el gestor de BD
contingencia para el sistema.  MySQL.
Android  Sistema operativo de dispositivo Permitirá tener en la nube
móvil.  tanto las bases de datos
como las aplicaciones
desplegadas.
Windows  Sistema operativo de los servidores.  Windows Server 2019
56
MySQL Gestor de Base de datos que tendrá el Versión 8.0.20
sistema, el cual se encontrará en una
plataforma Azure. 
Firewall  Es la parte de un sistema informático Ninguna

que está diseñada para bloquear el
acceso no autorizado, permitiendo al
mismo tiempo comunicaciones
autorizadas. 
Red de Comunicaciones de la Arquitectura Tecnológica
Red de
Responsabilidad Restricción
Comunicaciones
Microsoft Azure Es la nube que nos permite acceder a Se utilizará para el

despliegue de la aplicación
los servicios de Azure necesarios
móvil y web.
para el despliegue. Almacenará la base de
datos MySQL
Google Cloud Es la nube que nos permite acceder a Se consume solo el servicio
los servicios del mapa de Google. de API Google Maps
Heroku Es una plataforma en la nube que Se utilizará para desplegar

permite desplegar los servicios los servicios de correo y
externos. Redis
4.2.2 Vista Física

En la siguiente figura, se puede visualizar como interactúan los componentes para el
funcionamiento de ambas aplicaciones.
57
Figura 11: Vista Física de la Arquitectura Tecnológica del Sistema
4.3 Construcción de la solución

4.3.1 Requerimientos funcionales
En la siguiente tabla, se describirá los requerimientos funcionales de las aplicaciones
web y móvil del sistema propuesto.
Requerimientos Funcionales del Sistema

Código de Requerimiento Requisito Descripción
RF01 Registrar Usuario La aplicación móvil debe

permitir al usuario
registrarse
RF02 Autenticar usuario La aplicación móvil debe

permitir el inicio de sesión
al usuario ya sea con su
correo y contraseña.
RF03 Visualizar las Zonas de La aplicación móvil debe

Riesgo permitir visualizar las zonas
de riesgo en un mapa
58
RF04 Visualizar Ruta La aplicación móvil debe
permitir visualizar las zonas
de riesgo de difícil acceso en
un mapa
RF05 Buscar Ubicación La aplicación móvil debe

Geográfica permitir buscar una zona
especifica
RF06 Contribuir Zona de Riesgo La aplicación móvil debe

contribuir una posible zona
de riesgo
RF07 Localizar mi Ubicación La aplicación móvil debe

permitir localizar mi
ubicación actual
RF08 Modificar contraseña La aplicación móvil debe

permitir al usuario
modificar su contraseña
RF09 Guardar Ubicación La aplicación móvil debe

permitir guardar una
ubicación para facilitar la
búsqueda
RF10 Recuperar Contraseña La aplicación móvil debe

permitir recuperar la
contraseña del usuario en
caso de olvido
RF11 Cerrar Sesión La aplicación web debe

permitir finalizar la sesión
RF12 Registrar Usuario La aplicación web debe

permitir al usuario
registrarse
59
RF13 Actualizar y Eliminar La aplicación web debe
Usuario permitir actualizar y elimina
un registro de usuario
RF14 Listar Usuarios La aplicación web debe

permitir visualizar una lista
de los usuarios registrados
RF15 Modificar contraseña La aplicación web debe

permitir al usuario
RF16 Predecir Zonas de Riesgo La aplicación web debe

permitir predecir las futuras
zonas de riesgo
RF17 Registrar de Incendios La aplicación web debe

permitir importar registros
de incendios
RF18 Actualizar y Eliminar La aplicación web debe

Incendios permitir actualizar y
eliminar un registro de
incendios.
RF19 Listar Incendios La aplicación web debe

de los registros de
incendios.
RF20 Listar Zonas de Riesgo La aplicación web debe

de las zonas de riesgo
registradas
RF21 Autenticar usuario La aplicación web debe

permitir el inicio de sesión
60
al usuario ya sea con su
correo y contraseña.
RF22 Listar Zonas Contribuidas La aplicación web debe

de las zonas contribuidas
para ser analizadas
RF23 Registrar Zonas de Riesgo La aplicación web debe

permitir registrar una zona
de riesgo de incendio
RF24 Actualizar y Eliminar Zonas La aplicación web debe

de Riesgo permitir actualizar y
eliminar una zona de riesgo.
RF25 Eliminar Zonas La aplicación web debe

Contribuidas permitir eliminar un registro
RF26 Buscar Zonas La aplicación web debe

permitir buscar una zona
específica en un mapa
geográfico para conocer si
existen zonas de riesgo
RF27 Mostrar Zonas de Riesgo La aplicación web debe

de riesgo registradas en un
mapa geográfico.
RF28 Buscar Usuario La aplicación web debe

permitir buscar usuarios que
cumplan ciertas
condiciones.
RF29 Buscar Incendios La aplicación web debe

permitir buscar incendios
61
que cumplan con ciertas
condiciones.
RF30 Buscar Zonas Contribuidas La aplicación web debe

contribuida que cumplan
ciertas condiciones
RF31 Buscar Zona de Riesgo La aplicación web debe

mapa geográfico.
RF32 Recuperar Contraseña La aplicación web debe

caso de olvido
RF33 Cerrar Sesión La aplicación web debe

RF34 Visualizar La aplicación móvil debe

Recomendaciones permitir visualizar las
recomendaciones frente a un
caso de incendio
RF35 Notificar zona de riesgo de La aplicación móvil debe

incendio permitir alertar en caso el
usuario se encuentre cerca
de una zona de riesgo
4.3.2 Requerimientos no funcionales

En la siguiente tabla, se muestran los requerimientos no funcionales correspondientes al
sistema propuesto.
62
Requerimientos No funcionales del Sistema
Atributo de
ID  Requerimiento No funcional 
Calidad 
Performance  RN01  Toda funcionalidad del sistema y transacción de
negocio debe responder al usuario en menos de 1
segundos. 
RN02  Las modificaciones en la base de datos deberán ser
actualizados para todos los usuarios que acceden a la
aplicación en menos de 1 segundo. 
Disponibilidad  RN03  El sistema debe estar disponible en un 99,99% las
veces que el usuario intente acceder. 
Usabilidad  RN04 La tasa de errores cometidos por el usuario deberá ser
menor del 1% de las transacciones totales ejecutadas en
el sistema 
RN05 El sistema debe proporcionar mensajes de error que
  sean informativos y orientados a usuario final. 
Seguridad  RN06 El sistema bloqueará una cuenta, una vez el usuario
haya realizado 3 intentos erróneos en el login. 
RN07 El sistema permitirá la recuperación de la contraseña
del usuario en caso de olvido. 
Mantenibilidad  RN08 El sistema recibirá actualizaciones seguidas que
corresponderán a la identificación de nuevas zonas de
riesgo. 
4.3.3 Desarrollo de los prototipos

A continuación, se muestran los prototipos correspondientes a las funcionalidades de las
aplicaciones web y móvil.
ID Descripción Requisito
RF01 La aplicación móvil debe Registrar usuario
permitir al usuario registrarse
63
Figura 12: Interfaces del RF01
RF02 La aplicación móvil debe Autenticar Usuario
permitir el inicio de sesión al
usuario ya sea con su correo
y contraseña.
64
RF03 La aplicación móvil debe Visualizar las Zonas de
permitir visualizar las zonas Riesgo
de riesgo en un mapa
65
Figura 14: Interfaz del RF03
RF04 La aplicación móvil debe Visualizar Ruta
de riesgo de difícil acceso en
un mapa
66
RF05 La aplicación móvil debe Buscar Ubicación
permitir buscar una zona geográfica
especifica
67
RF06 La aplicación móvil debe Contribuir Zona de Riesgo
contribuir una posible zona
de riesgo.
68
RF07 La aplicación móvil debe Localizar mi Ubicación
permitir localizar mi
ubicación actual
69
RF08 La aplicación móvil debe Modificar contraseña
permitir al usuario
70
Fuente: Elaboración Propia
RF09 La aplicación móvil debe Guardar Ubicación
permitir guardar una
ubicación para facilitar la
búsqueda
71
RF10 La aplicación móvil debe Recuperar Contraseña
caso de olvido
72
RF11 La aplicación web debe Cerrar Sesión
73
RF12 La aplicación web debe Registrar Usuario
permitir al usuario
registrarse
74
RF13 La aplicación web debe Actualizar y Eliminar
permitir actualizar y elimina Usuario
un registro de usuario
75
RF14 La aplicación web debe Listar Usuarios
de los usuarios registrados
76
RF15 La aplicación web debe Modificar contraseña
permitir al usuario
77
RF16 La aplicación web debe Predecir Zonas de Riesgo
permitir predecir las futuras
zonas de riesgo
78
RF17 La aplicación web debe Registrar de Incendios
permitir registrar un
incendio
79
RF18 La aplicación web debe Actualizar y Eliminar
permitir actualizar y Incendios
eliminar un registro de
incendios.
80
RF19 La aplicación web debe Listar Incendios
de los registros de incendios.
81
RF20 La aplicación web debe Listar Zonas de Riesgo
de las zonas de riesgo
registradas
82
RF21 La aplicación web debe Autenticar usuario
permitir el inicio de sesión al
usuario ya sea con su correo
y contraseña.
RF22 La aplicación web debe Listar Zonas Contribuidas
para ser analizadas
83
RF23 La aplicación web debe Registrar Zonas de Riesgo
permitir registrar una zona
de riesgo de incendio
84
RF24 La aplicación web debe Actualizar y Eliminar Zonas
permitir actualizar y de Riesgo
eliminar una zona de riesgo.
RF25 La aplicación web debe Eliminar Zonas
permitir eliminar un registro Contribuidas
85
RF26 La aplicación web debe Buscar Zonas
específica en un mapa
geográfico para conocer si
existen zonas de riesgo
86
RF27 La aplicación web debe Mostrar Zonas de Riesgo
mapa geográfico.
87
RF28 La aplicación web debe Buscar Usuario
permitir buscar usuarios que
cumplan ciertas
condiciones.
RF29 La aplicación web debe Buscar Incendios
permitir buscar incendios
que cumplan con ciertas
condiciones.
88
RF30 La aplicación web debe Buscar Zonas Contribuidas
contribuida que cumplan
ciertas condiciones
RF31 La aplicación web debe Buscar Zona de Riesgo
mapa geográfico.
89
RF32 La aplicación web debe Recuperar Contraseña
caso de olvido
90
RF33 La aplicación web debe Cerrar Sesión
RF34 La aplicación móvil debe Visualizar
permitir visualizar las Recomendaciones
recomendaciones frente a un
caso de incendio
91
RF35 La aplicación móvil debe Notificar zona de riesgo de
permitir alertar en caso el incendio
usuario se encuentre cerca
de una zona de riesgo
92
4.4 Desarrollo de la Solución

4.4.1 Desarrollo del Backend
Este servicio es el principal, ya que contiene todo el mapeo de la base de datos, expone
todos los endpoints que consumen los clientes web y móvil. Asimismo, contiene toda la
lógica de negocio del proyecto, excepto por la predicción de incendios.
Eficiencia en consumo de recursos en general
93
• Para evitar el consumo excesivo de recursos en la base de datos, se optó por
realizar una actividad de tunning en las consultas de las tablas de usuarios y
recursos. Esto porque contienen miles de registros. En sí, dicha actividad
consistió en añadir índices a las tablas en las columnas a ser consultadas.
• Redis, con el fin de evitar consultar a cada momento la tabla de usuarios y
añadir datos extras, se optó por usar una base de datos Redis para almacenar
algunos datos para el bloque de usuario por tiempo. Estos datos fueron,
intentos de inicio de sesión fallidos, email de usuario y tiempo de bloqueo.
De esta manera se evita consultar a cada momento si un usuario está o no
bloqueado y aplicar algún mecanismo complejo para estar actualizando
directamente en la base de datos MySQL el bloque de un usuario.
Protección de datos end to end
• Para asegurar que los datos no sean consumidos por clientes no autorizados.
Se ha implementado un generador de JWT (Json Web Toket). El cual, a su
vez verifica que el token enviado por los clientes esté firmado por el secret
del backend. De esta forma, cualquier cliente externo que solicite un recurso
al backend no podrá acceder a los datos.
Conexión con servicios externos
El backend realizar conexión mediante el uso de las bibliotecas jersey y gson a

servicios secundarios. Estos en concreto son email y Redis service. Con el primer
servicio envía correos a los usuarios luego de recuperar su contraseña. El segundo
servicio es para el bloque de usuarios.
Encriptación de contraseña
• Para asegurar la protección de la contraseña de los usuarios se ha optado por

encriptarlo, no codificarlo. Para dicha actividad se ha usado la biblioteca
Bcrypt, el cual permite encriptar un string como hash y solo puede ser
comparado con un texto. Es decir, no se puede saber su valor real después de
ser ofuscado.
94
• Para el recuperado de contraseña se ha utilizado un generador (la biblioteca
commons-lang3) de strings aleatorio de 15 dígitos que luego es encriptado
para ser guardado en la base de daos.
4.4.2 Desarrollo de la Aplicación Web

La parte web está compuesto por un proyecto en angular con Google Maps e
integrado con el backend.
Eficiencia en consumo de recursos en general
• Se usó de local storage para guardar datos precisos y evitar consultar a cada
momento a la base de datos. Estos son usuarios logueado y otros datos
menores.
• Para evitar consultar cada vez a la base de datos al momento de refrescar la
lista de registros en cualquiera de los módulos. Se utilizó la arquitectura
publicador-subscriptor que notifica a la vista de listado de registros cuando
ha ocurrido un cambio (agregado, editado o eliminado) de un registro.
Arquitectura Publicador-Subscriptor con MQTT
Para implementar la arquitectura Publicador-Subscriptor, se ha utilizado el protocolo

MQTT, el cual es muy ligero y ampliamente utilizado en IoT. Se eligió dicho
protocolo por ser muy ligero, lo cual permite que consuma muy poca cantidad de red
en cada consulta y es muy rápido en velocidad de respuesta, así como en
implementación. Asimismo, se ha utilizado el message broker Mosquitto, ya que es
muy utilizado en la industria por ser muy robusto, actualizado y muy compatible con
MQTT.
Formularios reactivos
Todos los formularios implementados en la web son de tipo reactivos, lo cual asegura
que su comportamiento reaccione a medida que los usuarios interactúan con la
interfaz como, mostrar un error cuando el usuario introduce un dato erróneo.
95
4.4.3 Desarrollo de la Aplicación Móvil
• La aplicación tuvo como SDK de Android mínimo 23 o Android 6.0
Mashmellow.
• Se desarrollo en el lenguaje Kotlin, en el entorno de desarrollo Android
Studio IDE.
• La aplicación requirió de permisos especiales del sistema tales como
Ubicación, GPS, Internet y servicios en segundo plano.
• La aplicación requiere conexión a internet para funcionar correctamente.
Módulo de Login y Registro
En este módulo se manejó el registro de los usuarios de la aplicación móvil,

pidiéndoles que ingresen un correo, contraseña, nombres y apellidos. También se
manejó el inicio de sesión en la aplicación, el inicio de la sesión genera un token que
el usuario pueda hacer uso de todas las funcionalidades de la aplicación. Además, se
agregó la opción de recuperar contraseña, que recibirá el correo con el cual se ha
registrado el usuario.
Módulo de zonas de Riesgo
Es el módulo principal el cual mostrara un mapa obtenido de la Api de Google Maps

y en la cual dibujara las zonas de riesgo almacenadas en la base de datos y también
los recursos tales como hidrantes al acercar el mapa lo suficiente. Las zonas de riesgo
se dibujan como círculos de colores rojo, naranja y amarillo, para las zonas de alto,
medio y bajo riesgo respectivamente. Para dibujar las zonas de riesgo se usó un
elemento de la librería de Google Maps que serían los marcadores, los cuales
permiten personalizar el icono, posición e información que mostraran al tocarlos.
Además, se añadió un cuadro de búsqueda para que el usuario pueda encontrar la
locación que desea más rápido, y una leyendo que informa sobre las zonas de riesgo.
Módulo de Zonas Contribuidas
Modulo en el cual los usuarios pueden enviar sus zonas que consideren puedan ser
de riesgo de incendios. Para ello se agregó un mapa en el cual puede elegir el punto,
96
cuadros de texto para una breve descripción y deberá elegir la razón por la cual
considera puede ser zona de riesgo.
Módulo de Zonas y Puntos Guardados
Para este módulo se usó el almacenamiento en base datos del dispositivo SQLite, se
crearon tablas para las zonas contribuidas y los puntos personalizados que el usuario
desee guardar. Además, podrá redireccionará al mapa del módulo Zonas de Riesgo a
cualquiera de sus zonas guardadas o puntos personalizados
Módulo de Perfil
Modulo donde se verán los datos del usuario registrado, además tendrá opciones
como cambiar contraseña, ver recomendaciones, ver últimas emergencias y cerrar
sesión.
Módulo de Notificaciones
Modulo que genera un servicio, el cual estará corriendo en segundo plano si el

usuario tiene marcado la opción de notificaciones. El servicio generado usa la librería
de Geolocalización de Google Maps para obtener la ubicación del dispositivo en todo
momento, además, en caso de encontrarse cerca de una zona de Riesgo registrada se
mostrar una notificación alertándole del suceso. El usuario puede elegir si activar las
notificaciones o no.
4.4.4 Servicios Externos
• Email service: Este servicio se implementó para el envío de correos. Esto

permite enviar un correo cada vez que se ejecuta la funcionalidad de
recuperar contraseña.
• Redis service: Este servicio ha sido desarrollado para uso exclusivo de la
funcionalidad de bloqueo de usuarios, ya que guarda datos del tiempo de
bloque, email y número de intentos de inicio de sesión.
4.4.5 Desarrollo del Análisis Predictivo

En base a lo investigado, se optó por usar el algoritmo Decision Forest de la herramienta
Azure Machine Learning. En primer lugar, este servicio consiste en la recopilación
97
de 21502 registros de incendios urbanos ocurridos desde el año 2003 hasta el 2020. Los
cuales pasan por un entrenamiento predictivo según los pasos de Microsoft
Azure Services. Para dicho entrenamiento se tuvo que definir un peso para cada
las variables necesarias para realizar el análisis.
Variables usadas para el Análisis Predictivo
Variables Peso (%)

Número de Personas Afectadas 7.5%
Número de Personas Damnificados 10%
Número de Personas Heridas 2.5%
Número de Personas Fallecidas 15%
Número de Viviendas Afectadas 20%
Número de Viviendas Destruidas 20%
Cantidad de Veces Ocurridas 25%
Una vez finalizado el entrenamiento, la herramienta nos ofrece un Web Service que sirve
como principal fuente de información para identificar el impacto de en las posibles
zonas de riesgo de incendio. Por otro lado, para reducir el tiempo de demora al realizar
las consultas desde la aplicación web, se almacenarán los registros de incendios
en una base de datos MongoDB.
4.5 Pruebas de la Solución
4.5.1 Pruebas realizadas por Quality Service
Se realizaron la validación y certificación de funcionalidades del producto en 3

Sprints de 3 semanas con el apoyo de los recursos de IT Services. las cuales
consistieron en 33 Historias de Usuario y 82 Casos de prueba.
Sprint 5
•Historias de Usuario
Historias de Usuario certificadas en el Sprint 5

Historia de Usuario Descripción
HU09 Como Usuario Administrados quiero registrar un usuario

en la aplicación web para gestionar los accesos para otros
usuario o administradores.
98
HU10 Como Usuario Administrador quiero editar y eliminar

información de algún tipo de usuario en la aplicación web
para tener vigente la información de los mismos
HU11 Como Usuario Administrador quiero listar los diferentes
tipos de usuarios en la aplicación web para realizar una
gestión adecuada.
HU15 Como Usuario Final quiero visualizar un listado de los
registros de incendios en la aplicación web. para realizar
una mejor gestión de ellas.
HU16 Como Usuario Final quiero visualizar un listado de las
zonas de riesgo en la aplicación web para realizar una
mejor gestión de ellas.
HU17 Como Usuario Final quiero acceder a la aplicación web
usando mi usuario y contraseña creadas para acceder a las
funcionalidades de dicha aplicación.
HU19 Como Usuario Final quiero visualizar un listado de las
zonas de riesgo que han sido contribuidas para poder
analizarlas y asignarlas con zona de riesgo
HU22 Como Usuario Final quiero eliminar un registro de las
zonas contribuidas de incendio para contar las posibles
zonas de riesgo
HU25 Como Usuario Final quiero mostrar las zonas de riesgos
en un mapa geográfico para poder tomar precauciones en
caso ocurra un incendio.
•Casos de Prueba
Casos de Prueba certificados en el Sprint 5

HU Caso Prueba Descripción
HU09 Caso de Prueba 28 Registrar Usuario Exitosamente
HU10 Caso de Prueba 31 Actualizar Usuario Exitosamente

HU11 Caso de Prueba 36 Listar Usuarios Registrados
HU15 Caso de Prueba 47 Listar Incendios
HU16 Caso de Prueba 49 Listar Zonas de Riesgo
HU17 Caso de Prueba 51 Iniciar Sesión Exitosamente con rol
Administrador
99
HU19 Caso de Prueba 55 Listar Zonas Contribuidas

HU22 Caso de Prueba 64 Eliminar Zonas Contribuidas
HU25 Caso de Prueba 66 Mostrar Zonas de Riesgo
Sprint 6
HU01 Como Usuario Final quiero registrarme en la aplicación

móvil para acceder a las funcionalidades de dicha
aplicación
HU02 Como Usuario Final quiero ingresar a la aplicación móvil
usando mi correo y contraseña creadas para acceder a las
funcionalidades de dicha aplicación
HU03 Como Usuario Final visualizar todas las zonas de riesgo
de incendio en un mapa en la aplicación móvil para
obtener información sobre las zonas de riesgo.
HU04 Como usuario Final quiero visualizar una ruta
recomendada hacia una ubicación marcada en el mapa de
la aplicación móvil para poder tomar precauciones en
caso ocurra un incendio.
HU05 Como Usuario Final quiero buscar una ubicación
geográfica en la aplicación móvil para localizar una zona
específica.
HU06 Como Usuario Final quiero contribuir con una zona de

riesgo de incendio para informar a las instituciones
respectiva.
HU07 Como Usuario Final quiero ubicar mi posición actual en

la aplicación móvil para identificar las zonas de riesgos
de incendio cercanas a mi ubicación
HU08 Como Usuario quiero actualizar mi contraseña y cerrar
mi sesión en la aplicación móvil para tener una
configuración personalizada de mi cuenta
100
HU18 Como Usuario Final quiero solicitar la recuperación de

mi contraseña en la aplicación móvil para acceder a la
aplicación en caso de bloqueo u olvido de contraseña
•Casos de Prueba

HU01 Caso de Prueba 01 Registrar Nuevo Usuario

Exitosamente
Caso de Prueba 02 Registrar Nuevo Usuario con cuenta
registrada
Caso de Prueba 03 Registrar Usuario con campos vacíos
HU02 Caso de Prueba 04 Iniciar Sesión Exitosamente
Caso de Prueba 05 Iniciar Sesión con credenciales
incorrectas
Caso de Prueba 06 Iniciar Sesión con campos vacíos
HU03 Caso de Prueba 07 Sin Zonas de Riesgo
Caso de Prueba 08 Con Zonas de Riesgo
Caso de Prueba 09 Detalle de la Zona de Riesgo
HU04 Caso de Prueba 10 Visualizar Ruta recomendada
HU05 Caso de Prueba 11 Buscar ubicación geográfica
exitosamente
Caso de Prueba 12 Buscar ubicación geográfica con
campo vacío
HU06 Caso de Prueba 13 Contribuir Zona Exitosamente
Caso de Prueba 14 Contribuir Zona con campos vacíos
HU07 Caso de Prueba 15 Localizar mi ubicación Exitosamente
Caso de Prueba 16 Localizar mi ubicación sin activar
GPS
HU08 Caso de Prueba 17 Editar Contraseña Exitosamente
Caso de Prueba 18 Editar Contraseña con error en la
contraseña actual
Caso de Prueba 19 Editar Contraseña con campos vacíos
101
Caso de Prueba 20 Editar Contraseña con error en la

confirmación
HU18 Caso de Prueba 24 Recuperar Contraseña Exitosamente
Caso de Prueba 25 Recuperar Contraseña con campo
vacío
Caso de Prueba 26 Recuperar Contraseña con correo no
registrado
Sprint 7

Historias de Usuario Descripción
HU23 Como Usuario Final quiero guardar una ubicación

seleccionada para facilitar la búsqueda de zonas de
riesgo.
HU32 Como usuario final quiero visualizar información con
respecto a los incendios para saber cómo actuar frente a
este tipo de desastre.
HU33 Como usuario final quiero recibir notificaciones de
advertencia para saber si me encuentro cerca de una
zona de riesgo
HU30 Como Usuario Final quiero actualizar mi contraseña y
cerrar mi sesión en la aplicación web para tener una
configuración personalizada de mi cuenta
HU13 Como Usuario Final quiero realizar el registro de
incendios en la aplicación web para poder mantener
actualizado el registro histórico.
HU14 Como Usuario Final quiero actualizar y eliminar un
registro de Incendios en la aplicación web para poder
mantener registro actualizado. .
HU20 Como Usuario Final quiero registrar una zona de riesgo
de incendio para visualizarla en un mapa
HU21 Como Usuario Final quiero actualizar y eliminar un
registro de zonas de riesgo de incendio para contar con
información más reciente
102
Historias de Usuario Descripción
HU24 Como Usuario Final quiero buscar una ubicación

geográfica en la aplicación web para ubicar las zonas de
riesgo cercanas a dicha ubicación
HU26 Como Usuario Final quiero buscar los usuarios que
cumplan con ciertas condiciones para tener
conocimiento sobre sus datos.
HU27 Como Usuario Final quiero buscar los incendios que
haya ocurrido en una zona específica para tener
conocimiento sobre sus datos.
HU28 Como Usuario Final quiero buscar las zonas
contribuidas que cumplan con ciertas condiciones para
tener conocimiento sobre sus datos.
HU29 Como Usuario Final quiero buscar las zonas de riesgos
de incendios que cumplan con ciertas condiciones para
tener conocimiento sobre sus datos.
HU31 Como usuario final quiero solicitar la recuperación de
mi contraseña en la aplicación web para acceder a la
aplicación en caso de bloqueo u olvido de contraseña.
HU12 Como Usuario Final quiero identificar las futuras zonas
de riesgo en la aplicación web para asignarlas como
zonas de riesgo de incendio.
•Casos de Prueba

HU12 Caso de Prueba 41 Predecir Zonas de Riesgo Exitosamente

HU13 Caso de Prueba 42 Registrar Incendio Exitosamente
Caso de Prueba 43 Registrar Incendio con campos vacíos
HU14 Caso de Prueba 44 Actualizar Incendio Exitosamente
Caso de Prueba 45 Actualizar Incendio con campos vacíos
Caso de Prueba 46 Eliminar Incendio
HU20 Caso de Prueba 57 Registrar Zonas de Riesgo Exitosamente
Caso de Prueba 58 Registrar Zonas de Riesgo con datos registrados
Caso de Prueba 59 Registrar Zonas de Riesgo con campos vacíos
HU21 Caso de Prueba 60 Actualizar Zona de Riesgo Exitosamente
103
Caso de Prueba 61 Actualizar Zona de Riesgo con datos registrados

Caso de Prueba 62 Actualizar Zona de Riesgo con campos vacíos
Caso de Prueba 63 Eliminar Zonas de Riesgo
HU23 Caso de Prueba 21 Guardar Ubicación
Caso de Prueba 22 Listar Ubicaciones Guardadas
Caso de Prueba 23 Eliminar Ubicación Guardada
HU24 Caso de Prueba 65 Búsqueda Completa

HU26 Caso de Prueba 68 Buscar Usuario Exitosamente
Caso de Prueba 69 Buscar Usuario sin resultados
HU27 Caso de Prueba 70 Buscar Incendio Exitosamente
Caso de Prueba 71 Buscar Incendio Sin resultados
HU28 Caso de Prueba 72 Buscar Zona Contribuida Exitosamente
Caso de Prueba 73 Buscar Zona Contribuida Sin resultados
HU29 Caso de Prueba 74 Buscar Zona de Riesgo Exitosamente
Caso de Prueba 75 Buscar Zona de Riesgo Sin resultados
HU31 Caso de Prueba 76 Recuperar Contraseña Exitosamente
Caso de Prueba 77 Recuperar Contraseña con campo vacío
Caso de Prueba 78 Recuperar Contraseña con correo no registrado
HU30 Caso de Prueba 79 Cerrar Sesión Exitosamente
HU32 Caso de Prueba 80 Visualizar recomendaciones ante incendios
HU33 Caso de Prueba 81 Notificaciones activadas
Caso de Prueba 82 Notificaciones desactivadas
4.6 Implementación
4.6.1 Recursos Utilizados
Se implementó un ambiente usando los siguientes recursos:
104
Recursos utilizados para el despliegue del Sistema
Recursos Proveedor Comentarios
Azure App Services Microsoft Azure En el App Services, se encuentran

for web desplegados tanto el backend de la
aplicación como los servicios de
correo y el bloqueo de usuarios (Redis
Service).
Azure App Services Microsoft Azure En el container App Service se

for container encuentran desplegados el front end de
la aplicación y el servicio análisis
predictivo.
MySQL Service Microsoft Azure Servicio de base de datos de MySQL,

el cual tendrá el sistema.
Azure Cosmo DB Microsoft Azure Servicio de base de datos para el

MongoDB, el cual se encargará
exclusivamente de las consultas para
el servicio de análisis predictivo.
En la siguiente figura, se puede visualizar como interactúan los servicios de la arquitectura

de despliegue del sistema propuesto, el cual se encuentra desplegado en una plataforma
Azure.
105
Figura 47: Arquitectura de Despliegue del Sistema
4.6.2 Procedimiento de Despliegue
Se documentaron de forma detallada los pasos para el despliegue del sistema

propuesto.
4.6.2.1 Despliegue del backend en Azure

1. Iniciamos nuestro Azure CLI en Azure Cloud
Figura 48: Inicio de Azure CLI
106
2. En Azure CLI clonar el proyecto git y situarnos dentro de la carpeta del código
fuente
Figura 49: Clonación del Proyecto Git
3. Configurar el plugin de Azure en el POM.xml.
Figura 50: Configuración del plugin de Azure
• Cuando solicito seleccionar Web app, seleccionar create

• Cuando solicite el tipo de OS, escoger Linux
• Seleccione java 1.8
• Finalmente, de Enter para finalizar la instalación
4. Ahora se tiene que realizar unos cambios en el POM.xml para que funcione el
despliegue.
107
vim pom.xml
Ir hasta la sección de plugin y pulsar insert desde el teclado. A continuación, realizar los
cambios de acuerdo con lo resaltado en la imagen. Luego pulsar Esc en el teclado junto a
:qw para salvar la configuración.
Figura 51: Configuración del archivo POM
5. Ahora se procede a desplegar el backend mediante:

mvn package azure-webapp:deploy
Esto desplegará nuestra aplicación como un App Service, en Azure.
6. Podemos ver la url generada y los demás detalles desde el portal
Figura 52: Detalles del App Service para el BackEnd
108
4.6.2.2 Despliegue de contenedores en Azure
1. Generar nuestra imagen de la aplicación web, mediante Docker. Para ello, nos
tenemos que situar en la raíz de nuestro proyecto en angular y asegurarnos de tener
un archivo Dockerfile. Entonces, debemos ejecutar los siguientes comandos en el
orden:
docker build -t sgri- frontend.
docker tag sgri- frontend userregistry/sgri-frontend:latest
docker push userregistry/sgri- frontend:latest
Al finalizer el proceso, nuestra imagen estará desplegada en nuestro container registry. En

nuestro caso se usó dockerhub.
Figura 53: Despliegue de Container en DockerHub
2. Nos dirigimos al portal de Azure en la sección de App Service y creamos uno. En los
datos que debemos seleccionar, hay que asegurarnos de seleccionar “Docker
Container”
Figura 54: Creación de AppService para los Contenedores
109
3. Al dar en “Next: Docker”, se nos pedirá seleccionar el repositorio de la imagen
Docker y el tag (latest). Si nuestra imagen es privada, cambiar de Public a Private y
añadir las credenciales.
Figura 55: Configuración del App Service para los contenedores
4. Luego que el proceso de despliegue termine ejecutar desde la consola de comandos

de Azure CLI:
az webapp config appsettings set --resource-group geoincendiosV2 --name sgri-frontend --
settings WEBSITES_PORT=4200
La variable de WEBSITES_PORT es muy importante, ya que esta debe ser

modificado de acuerdo con el puerto que expone el contener Docker.
5. Generar nuestra imagen de la aplicación encargada de la predicción de incendios,

mediante Docker. Para ello, nos tenemos que situar en la raíz de nuestro proyecto en
python y asegurarnos de tener un archivo Dockerfile. Entonces, debemos ejecutar los
siguientes comandos en el orden:
docker build -t sgri- predicts.
docker tag sgri- predicts userregistry/sgri- predicts:latest
docker push userregistry/sgri- predicts:latest
110
6. Al finalizar el proceso, nuestra imagen estará desplegada en nuestro container
registry. En nuestro caso se usó dockerhub.
7. Nos dirigimos al portal de Azure en la sección de App Service y creamos uno. En los
datos que debemos seleccionar, hay que asegurarnos de seleccionar “Docker
Container”
Figura 56: Verificar la configuración de AppService
8. Al dar en “Next: Docker”, se nos pedirá seleccionar el repositorio de la imagen

Docker y el tag (latest). Si nuestra imagen es privada, cambiar de Public a Private y
añadir las credenciales.
111
Figura 57: Selección de imagen de Docker
9. Luego que el proceso de despliegue termine ejecutar desde la consola de comandos

de Azure CLI
az webapp config appsettings set --resource-group geoincendiosV2 --name sgri-predicts --
settings WEBSITES_PORT=5000
La variable de WEBSITES_PORT es muy importante, ya que esta debe ser modificado de

acuerdo con el puerto que expone el contener Docker
4.6.2.3 Despliegue de base de datos en Azure

1. Desde el portal de Azure dirigirnos a MySQL Service
Figura 58: Creación del Servicio de Base de Datos
112
2. Seleccionar la opción preview, ya que es recomendado para desarrollo.
Figura 59: Planes del Servicio
3. Ingresar los datos necesarios
Figura 60: Ingreso de datos del servicio
113
4. Firewall rules, seleccionar la opción de acuerdo con la imagen. Esto permite la
conexión de clientes como Mysql Workbench. Finalmente, dar en crear.
Figura 61: Configurar conexión del servicio MySQL
5. Luego que termine el despliegue podemos ver todas las opciones. En la sección de
Connections string nos muestra el string para conectarnos a la base de datos desde
distintos clientes en lenguajes de programación
Figura 62: Verificar despliegue exitoso
114
6. Para desplegar MongoDB Service dirigirnos a la siguiente opción desde el portal
Figura 63: Interfaz de Servicios Azure
7. Dar en add
Figura 64: Creación de Servicio Azure Cosmos
8. Ingresar los datos solicitados. En la sección de API, seleccionar Azure Cosmos DB

for MongoDB API. Finalmente, seguir las opciones y dar en crear
115
Figura 65: Configuración del Servicio Azure Cosmos
9. Luego, de desplegar el servicio podemos ingresar y ver sus opciones
Figura 66: Verificación de despliegue del Servicio Azure Cosmos
116
4.6.2.4 Creación del APK
Primero se selecciona el proyecto Geo Incendios para abrirlo con el IDE de Android
Studio.
Figura 67: Selección del proyecto en Android Studio
Luego de que el proyecto termine de cargarse, en la parte superior se encuentra un

botón con un icono de un martilo, el cual cumple la función de Build. El build
generara el en la carpeta Build/outputs/apks/debug y /release.
Figura 68: Generación de APK
117
Finalmente confirmamos en la carpeta Build/outputs//debug o /reléase; en la cual
encontraremos el APK generado.
Figura 69: APK generado
4.6.3 Resultado del Despliegue
Finalmente, se verificó que el despliegue fue realizado de forma exitosa pudiendo

acceder a nuestra solución web y móvil.
Figura 70: Interfaz del Login de la Aplicación Web Desplegada
118
Figura 71: Interfaz del Mapa de la Aplicación Web Desplegada
Figura 72: Interfaces de la Aplicación Móvil Desplegada
119
4.7 Propuesta de Validación
4.7.1 Diseño de la Validación de la Aplicación Móvil
La solución móvil es validada por usuarios que buscan zonas de riesgo cercanas
a su ubicación. En la validación, se tomará una muestra de 20 usuarios, los cuales
tienen los rangos de 18 a 40 años, de ambos géneros. Para las pruebas, se simula
la búsqueda de las zonas de riesgo de incendios y los recursos disponibles
cercanos a una ubicación con la finalidad de tomar la mejor decisión. Durante el
desarrollo de las pruebas los usuarios emplear un dispositivo móvil con sistema
operativo Android, mientras que el evaluador utiliza un cronómetro.
Figura 73: Casos de Prueba para los Ciudadanos
CASO 1: CIUDADANO
Usted es un ciudadano que desea abrir un negocio
prospero. Para ello, ha considerado 3 ubicaciones: X,

Y y Z. Por tal motivo, decide informarse sobre si existen
zonas de riesgo de incendios y los recursos disponibles

cercanos a dichas ubicaciones. Con el fin de elegir qué
ubicación le conviene más, usted busca información

sobre dichas zonas.
Figura 74: Flujo de Búsqueda de Zonas de Riesgo de Incendios
120
4.7.2 Diseño de la Validación de la Aplicativo Web
En una primera instancia, nos pusimos en contacto con miembros de INDECI,

una de ella fue la señorita Maritza Sánchez, subdirectora de Gestión de Material
Educativo, quien amablemente nos respondió y programó una reunión con
expertos en el tema de incendios. Durante dicha reunión, logramos exponerles a
los expertos nuestro sistema desarrollado. Asimismo, se simulo el análisis de una
zona de riesgo de incendios con la finalidad de tomar medidas preventivas.
Durante el desarrollo de las pruebas los usuarios emplearon una la aplicación
web.
Figura 75: Casos de Prueba para INDECI
CASO 2: MIEMBRO DE INDECI
Usted trabaja como un miembro de INDECI y necesita

averiguar el nivel de riesgo de incendio que existe en una
ubicación X. Posteriormente, analizarla y considerarla
como una zona de riesgo de incendio para poder tomar las
medidas correspondientes
Figura 76: Flujo de Análisis e Identificación de Zonas de Riesgo de Incendios
121
Figura 77: Sub-Proceso de Análisis de Zonas de Riesgo de Incendios
5 CAPITULO 5: RESULTADOS DEL PROYECTO

En el presente capítulo se describe la validación de la solución planteada para el proyecto,
los costos en el cual incurre el desarrollo y la continuidad.
5.1 Validación de la Solución
5.1.1 Recopilación de Datos
Para la validación del proceso de análisis e identificación, inicialmente se realizó

una reunión con cuatro miembros de INDECI. Se recogieron datos para
identificar los responsables y el tiempo real que se tarda en realizar el análisis y
la identificación de las zonas de riesgo de incendio. Con dicha finalidad se
realizaron las siguientes preguntas.
Preguntas de la Entrevista con miembros de INDECI

Preguntas de la Entrevista con los miembros de INDECI
1.- ¿Qué herramientas utilizan para llevar a cabo el proceso de análisis e
identificación de zonas de riesgo?
2.- ¿Qué variables toman en cuenta para dicho análisis?
3.- ¿Cuánto tiempo conlleva realizar un análisis profundo de las zonas de
riesgo de incendios?
4.- ¿Cuentan con un listado de las zonas de riesgo de incendio en Lima?
5.- ¿Cómo los tienen identificados las zonas de riesgo de incendios?
Por otro lado, para la validación del proceso de búsqueda de zonas de riesgo
se realizaron encuestas a 20 usuarios con la finalidad de conocer el tiempo
122
de búsqueda, nivel de conocimiento sobre las zonas de riesgo de incendios y
de recomendaciones preventivas.
Figura 78: Formato de preguntas antes de implementar la propuesta realizadas en Microsoft Forms
Finalmente, se obtuvieron los siguientes resultados antes de la implementación

de nuestra propuesta.
Indicadores antes de la Implementación de la Propuesta

Indicadores antes de la Implementación de la Propuesta
N°
Indicador Medida
Tiempo promedio de búsqueda de zonas

1 55 minutos
de riesgo
Tiempo promedio de análisis e

2 7 días (56 horas)
identificación de zonas de riesgo
123
5.1.2 Captura de Datos
Dentro del proceso de captura de datos, los evaluadores registraron el tiempo en
el que los 20 usuarios se demoraron al momento de realizar la búsqueda de las
zonas de riesgo de incendios usando la aplicación móvil.
Figura 79: Pruebas con usuario
Para poder realizar la captura de datos se empleó Microsoft Forms; donde se

consideró el tiempo de búsqueda que se demoró el usuario y una encuesta de
satisfacción en base al uso de la solución móvil.
Figure 80: Formato de preguntas para la aplicación móvil realizadas en Microsoft Forms
124
En el caso de la aplicación web, los evaluadores registraron el tiempo en el que los
encargados de la gestión de Riesgos de INDECI podían demorar al analizar e
identificar las zonas de riesgo de incendio usando la aplicación web.
Figura 81: Pruebas con usuario de INDECI
Para poder realizar la captura de datos se empleó Microsoft Forms; donde se

consideró el tiempo de búsqueda que se demoró el usuario, nivel de conocimiento y
una encuesta de satisfacción en base al uso de la solución móvil.
125
Figura 82: Formato de preguntas para la aplicación web realizadas en Microsoft Forms
5.1.3 Análisis de Indicadores

Para el análisis de indicadores, se evaluaron las encuestas realizadas por los
usuarios. Cabe resaltar que cada uno de los de los indicadores evaluados se
compararon con los resultados de una encuesta propia antes de la
implementación de la solución y lo indicado en la reunión con los miembros de
INDECI. Los cuales son los siguientes:
Figura 83: Análisis de Indicadores (Aplicación Móvil)
126
Figura 84: Análisis de Indicadores (Aplicación Web)
Se tuvo en cuenta las entrevistas con los miembros de gestión de riesgos de

INDECI, para conocer como realizan el proceso de análisis e identificación de
zonas de riesgo de incendios.
Figura 85: Flujo Actual de Análisis e Identificación de Zonas de Riesgo de Incendios
127
Figura 86: Sub-Proceso de Generación de Escenarios Riesgo
5.1.4 Resultado de Prueba

A partir de la validación de las funcionalidades propuestas de la información
recopilada, se registró el tiempo de análisis y búsqueda para cada responsable.
Se observó una mejora significativa en los tiempos a través de las
funcionalidades desarrolladas en la solución. El tiempo
de análisis e identificación de zonas de riesgo usando nuestra
solución fue en promedio 14 horas; se calculó que el tiempo promedio
disminuyo en 42 horas (75.0%). La Tabla 28 muestra los resultados
obtenidos durante la validación de la optimización del tiempo de
ejecución del proceso de análisis e identificación de zonas de riesgo de
incendios.
Datos de Muestra (Aplicación Web)
N° Tiempo de análisis e identificación Optimización de tiempo de

de zonas de riesgo (horas) análisis e identificación
1 1 día y medio (12 horas) 77.7%
2 2 días (16 horas) 70.4%
De igual manera, se tuvo en cuenta el porcentaje de satisfacción de usuario

mediante la evaluación de tres características principales realizadas por el
usuario, las cuales fueron: usabilidad, eficiencia e interfaz de usuario de
la aplicación web.
128
Figura 87: Satisfacción de los Miembros de INDECI
Por otro lado, se registró una mejora en el tiempo de búsqueda que obtuvieron
los 20 usuarios. El tiempo de búsqueda con nuestra solución tuvo como resultado
promedio 5 minutos; se calculó que el tiempo promedio disminuyo 50 min
(90.6%). La Tabla 29 muestra los resultados obtenidos durante la validación del
tiempo optimizado durante la ejecución del proceso de búsqueda de zonas de
riesgo de incendios.
Datos de muestra (Aplicación Móvil)

Datos de muestra
N° Tiempo de búsqueda Optimización de
zonas de riesgo tiempo de
(minutos) búsqueda
1 6.05 min 89.0%
2 6.17 min 88.8%
3 4.55 min 91.7%
4 3.30 min 94.0%
5 3.43 min 93.8%
6 5.15 min 90.6%
129
7 4.30 min 92.2%
8 4.35 min 92.1%
9 4.32 min 92.1%
10 5.29 min 90.4%
11 5.51 min 89.9%
12 6.20 min 88.7%
13 6.41 min 88.3%
14 5.43 min 90.1%
15 5.45 min 90.1%
16 5.34 min 90.3%
17 6.38 min 88.4%
18 5.41 min 90.2%
19 5.20 min 90.5%
20 5.11 min 90.7%
Asimismo, se tuvo en cuenta el porcentaje de satisfacción de usuario mediante la

evaluación de tres características principales realizadas por el usuario, las cuales
fueron: usabilidad, eficiencia e interfaz de usuario de la aplicación móvil.
130
Figura 88: Satisfacción según la Usabilidad
Figura 89: Satisfacción según la interfaz de usuario
Figura 90: Satisfacción según la eficiencia
131
5.2 Trabajos a Futuro
Esta tesis puede tomarse coma la primera etapa de un proyecto más ambicioso que
puede conformarse por una serie de proyectos similares. En futuras investigaciones,
se considerará la mejora del modelo predictivo implementado utilizando
información sobre la estructura de viviendas, cantidad de personas por
lote y recursos disponibles en las zonas. Por otro lado, se integrará con la base de
datos de INDECI, para evitar la duplicidad de información acerca de los registros de
incendios que permiten realizar el análisis correctamente. De esta manera,
el análisis para la identificación de zonas de riesgo llegaría a ser más preciso.
5.3 Plan de Costos

El objetivo del presente plan de gestión de costos es lograr describir la administración
de los costos asociados a este proyecto, el cual es necesario para asegurar el
cumplimiento de las restricciones presupuestales asignadas. Para ello, se han
identificado varios componentes, métricas e informes de costos asociados al
proyecto, los cuales se detallarán en este documento. Por este motivo, todos los
miembros clave del proyecto y sus partes interesadas deben respetar el plan de
gestión de costos y el plan general del proyecto. Los componentes identificados en
este plan son los siguientes:
Internos:
• Adquisición de servicios Cloud.
• Dispositivos móvil y laptops.
• Licencias y herramientas de Software
• Recursos de gestión y desarrollo del proyecto
Externos:
• Costos de soporte de servicios Cloud
132
Costos del Proyecto ($)
6 CAPITULO 6: GESTIÓN DEL PROYECTO

En esta sección, se explican las acciones realizadas para la Gestión de todo el proyecto en el
curso y la documentación correspondiente a cada fase.
6.1 Plan de Gestión del Proyecto

• Ciclo de Vida del Proyecto
133
Ciclo de Vida del Proyecto
Fase Revisiones Criterio de Criterio de salida

entrada
Inicio Revisión del Project Elaboración del Aprobación del
charter Project charter Project charter
Planificación Revisión Artefactos Elaboración de los Aprobación de los
de gestión artefactos de artefactos de
gestión gestión
Revisión del análisis Elaboración del Aprobación del
de herramientas, documento del objetivo 1
soluciones y análisis de
tecnologías. herramientas,
soluciones y
tecnologías.
Desarrollo Revisión del diseño Elaboración del Aprobación del
del sistema diseño del sistema diseño del sistema
Revisión de la Elaboración de la Aprobación de la
arquitectura del arquitectura del arquitectura del
sistema sistema sistema
Revisión del Elaboración del Revisión del
modelado del modelado del modelado del
proceso del sistema proceso del sistema proceso del sistema
Revisión de los Elaboración de los Aprobación de los
mockups mockups mockups
Acta de aprobación Elaboración del Aprobación del acta
del objetivo 2 acta del objetivo 2
Revisión del paper Elaboración del Aprobación del
paper paper
Revisión de los casos Elaboración de los Aprobación de los
de prueba casos de prueba casos de prueba
134
Acta aprobación Elaboración del Aprobación del acta
objetivo 3 acta del objetivo 3
Revisión del plan de Elaboración del Aprobación del
continuidad documento del plan plan de continuidad
de continuidad
Acta de aprobación Elaboración del Aprobación del acta
del objetivo 4 acta del objetivo 4
Revisión del Paper Elaboración del Aprobación del
Paper Paper
Cierre Revisión de los Preparación de los Aprobación de los
entregables finales entregables finales entregables finales
del proyecto del proyecto del proyecto
• Enfoques de Desarrollo
Enfoques del Desarrollo
Entregable Enfoque de desarrollo

Project charter Desarrollo incremental
Cap,1 – Definición del Proyecto Desarrollo incremental
Cap.2 - Plan Outcomes ABET Desarrollo incremental
Cap. 3 – Marco Teórico Desarrollo incremental
Artefactos de gestión de proyectos Desarrollo incremental
Investigación sobre los algoritmos, tecnologías y Desarrollo incremental
soluciones para el sistema propuesto
Acta de Aprobación del Objetivo 1 Desarrollo incremental
Anexo E – Estado del Arte Desarrollo incremental
Diseño del Sistema propuesto Desarrollo incremental
Cap. 4 – Desarrollo del Proyecto Desarrollo incremental
Desarrollo del Paper Desarrollo incremental
Acta de Aprobación del Paper Desarrollo incremental
135
Cartera de Proyectos Desarrollo incremental
Desarrollo Plan de Continuidad Desarrollo incremental
Cap. 5 – Resultados del Proyecto Desarrollo incremental
Anexo A – WASC Desarrollo incremental
Anexo C – Costos y Presupuestos Desarrollo incremental
Conclusiones y Recomendaciones Desarrollo incremental
Preparación y Entrega de Artefactos de la Desarrollo incremental
Memoria
• Planes de Gestión Subsidiaria
Planes de Gestión Subsidiaria
Nombre Comentario
Alcance Plan de gestión del alcance, enunciado del alcance del proyecto
Tiempo Hoja de ruta del proyecto, Plan de gestión del cronograma
Costo Plan gestión de costos
Calidad Plan de gestión de calidad
Recurso Plan de gestión de recursos
Comunicaciones Plan de gestión de comunicaciones
Riesgo Plan de gestión de riesgos
Logro Plan de gestión de requerimientos
Stakeholder Matriz de asignación de responsabilidades
Otros planes Lista de hitos
• Umbral de Variación del Alcance

Los cambios con respecto al alcance del Proyecto serán conversados con el Manager
y el Product Owner y después de ello se realizará el seguimiento respectivo para su
aprobación de este.
136
Umbral de Variación del Alcance
N° Cambio Propuesto por
1 Cambios con respecto al título del Proyecto Product Owner o Manager
2 Cambios con respecto al enfoque del Proyecto Product Owner o Manager
3 Cambios con respecto a los objetivos del Product Owner o Manager

Proyecto
• Gestión del Alcance de Línea Base

Para el desarrollo del alcance del Proyecto, hemos definido los documentos
necesarios para administrar la línea base del alcance del proyecto lo cual nos
ayudaran a proveer un resultado correcto y su viabilidad. Los documentos son los
siguientes:
• Enunciado del Alcance
• Estructura de Desglose del trabajo del proyecto
• El diccionario del EDT
Si bien es cierto los entregables presentado en el EDT garantizan el correcto

desarrollo del proyecto, pueden ocurrir ciertos eventos que harán que el alcance ya
definido pueda verse afectado de cierto modo
• Umbral de Variación del Calendario

El proyecto no debería presentar muchas variaciones con respecto al cronograma
debido que se encuentra basado en las fechas designadas por la PMO, las cuales son
fijas y, por lo tanto, se deben cumplir de manera clara y directa. Sin embargo, si
existirá alguna variación con respecto al calendario del proyecto no debería exceder
el umbral planificado.
137
Umbral de Variación del Calendario
N° Cambio Umbrales de Control
1 Variación de la duración de las Se expresa indicando un

actividades del cronograma porcentaje (%) de
variación de 5%
• Gestión de Línea Base del Calendario

Para el desarrollo de la línea base del calendario, hemos definido el cronograma con
sus respectivos entregables el cual no debería presentar muchas variaciones con
respecto al cronograma debido que se encuentra basado en las fechas designadas por
la PMO, las cuales son fijas y, por lo tanto, se deben cumplir de manera clara y
directa. Sin embargo, si existirá alguna variación con respecto al calendario del
proyecto no debería exceder el umbral planificado.
Línea Base del Calendario

Fase Entregable Ciclo
Project Charter (Semana 1 – 3)
Iniciación Cap.2 – Plan Outcomes ABET (Semana 2)
Marco Teórico (Semana 2 - 6)
Anexo E – Estado del Arte
Analizar las soluciones propuestas, herramientas
tecnológicas y algoritmos predictivos para el sistema
Planificación de geolocalización (Semana 4 -9)
Artefactos de Gestión de Proyecto (Semana 4 – 9) 2020-1
Acta de aprobación de lo realizado para el Objetivo 1
(Semana 9)
Diseñar la arquitectura tecnológica y el prototipo de la
solución propuesta (Semana 7 – 14)
(Semana 14)
Cap.4 Desarrollo del Proyecto (Semana 1 – 9)
138
Paper (Semana 1 – 12)
Validación del funcionamiento del sistema
desarrollado (Semana 1 - 9)
Ejecución (Semana 9)
Desarrollo del Plan de Continuidad (Semana 9 – 11)
(Semana 11)
Anexo C – Costo y Presupuesto (Semana 10 – 11) 2020-2
Cap.5 Resultado del Proyecto (Semana 11 – 12)
Anexo A – WASC (Semana 12 - 13)
Aprobación del Paper (Semana 12)
Conclusiones y Recomendaciones (Semana 14)
Cierre Preparación y Entrega de Artefactos de la Memoria
(Semana 15)
• Umbral de Variación de Costos

Para poder monitorear el desempeño del costo del Proyecto, se definirían umbrales
de variación. Con la finalidad de poder establecer un valor de variación permitido
antes que se necesario tomar alguna medida. De acuerdo con las actividades que se
realizan durante todo el proyecto en el que incurre en el costo de horas hombre y
costo de herramientas tecnológicas, los umbrales de control asociados se verán en el
siguiente cuadro:
Umbral de Variación de Costos
Costos de Actividades Umbrales de Control
Se expresa indicando un porcentaje (%) de

Horas Hombres
variación de 5%

Pago Único
variación de 10%
139
• Gestión de la línea Base de los Costos
Todas las actividades serán realizadas y supervisadas por los miembros del Proyecto.
Sin embargo, para algunas actividades de la fase de desarrollo se necesarita costear
recursos tecnológicos. Además, para asegurar la viabilidad del proyecto, también se
han definido estimaciones realistas de los costos de las actividades que pueden incluir
un monto determinado en caso de contingencia.
Línea Base de los Costos


Horas Hombres
variación de 5%

Pago Único
variación de 10%
6.2 Hoja de Ruta del Proyecto

• Fases del Ciclo de Vida del Proyecto
El Proyecto esta divide en 4 fases las cuales contemplan todo el desarrollo del sistema de
geolocalización;
• Fase de Iniciación
• Fase de Planificación
• Fase de Ejecución
• Fase de Cierre.
En la fase Inicial, se llevará a cabo la investigación de los diferentes algoritmos,

componentes y tecnologías que están orientadas a la predicción de zonas de riesgo mediante
un sistema de geolocalización. En la fase de Planificación, se llevará a cabo determinar todas
las actividades necesarias para cumplir con los objetivos y el resultado del proyecto. En la
fase de Ejecución se procederá a realizar el diseño del sistema de geolocalización usando
todos los compontes y herramientas seleccionadas. Por último, en la fase de Cierre, se
validará y se verificará los resultados obtenidos con respecto al proyecto. Asimismo, se
entregarán los documentos correspondientes que forman parte del alcance del proyecto.
• Principales Entregables o Eventos
140
Principales Entregables del Proyecto
Fase Entregables
● Project Charter
Iniciación
● Plan Outcomes ABET

● Cap. 3 - Marco Teórico
● Cap. 6 -Artefactos de Gestión de
Proyectos
● Investigación sobre los
Planificación componentes, tecnologías y
algoritmos para el sistema (Objetivo
1)
● Acta de aprobación Objetivo 1
● Anexo E - estado del arte
● Diseño de la arquitectura del

Sistema
● Diseño del modelo del proceso del
Sistema
● Diseño del Prototipo del Sistema
● Acta aprobación Objetivo 2
● Cap.4 - Desarrollo del proyecto
● Desarrollo del Paper
● Acta aprobación del Paper
Ejecución
● Desarrollo del Sistema
● Cartera de Proyectos
● Acta aprobación Objetivo 3
● Desarrollo plan de continuidad
● Acta de aprobación Objetivo 4
● Cap. 5 Resultados del proyecto
● Anexo A WASC
● Anexo C: Costos y Presupuestos
● Conclusiones y Recomendaciones
Cierre ● Preparación y Entrega de Artefactos
de la Memoria
• Hitos Significativos
El proyecto estará compuesto también por hitos, las cuales son una forma de
conocer el avance del proyecto y constituyen un trabajo de duración cero porque
141
simbolizan un logro, un punto y un momento en el proyecto. A continuación, se
presenta los hitos que serán trabajados durante todo el proyecto.
Hitos Significativos del Proyecto

Fase Hitos
Iniciación ● Aprobación Project Charter
● Aprobación de los Artefactos de la

Planificación Gestión del Proyecto
● Aprobación objetivo 1 por PO
● Aprobación del objetivo 2 por QS y

PO
o Aprobación de la
Arquitectura del Sistema QS
o Aprobación del modelado del
proceso del Sistema QS
o Aprobación de las Historias
de Usuarios QS
o Aprobación de las Historias
de Usuarios PO
o Aprobación del Mockups de
Ejecución la ampliación PO
o Aprobación del Mockups de
la aplicación QS
● Aprobación del objetivo 3 PO y QS
o Aprobación de la Aplicación
PO
o Aprobación de la Aplicación
QS
● Aprobación del objetivo 4 PO
o Aprobación del plan de
continuidad PO
● Aprobación del Paper por el coautor
142
Fase Hitos
● Entrega de Artefactos de la Memoria

Cierre
● Aprobación de entregables finales
• Tiempos y Tipos de Revisiones

Los Hitos tendrán un tiempo de revisión y aprobación en las semanas
correspondientes durante el ciclo académico 2020-01 y 2020-02. A continuación, se
presentará el detalle de lo previamente mencionado.
Revisiones del Proyecto

Hitos Tiempo Tipo de Revisiones
Revisión y Aprobación por

Aprobación Project Charter Semana 3 (2020-01)
Manager
Aprobación de los Semana 6 (2020-01) Revisión y Aprobación por

Artefactos de Gestión del Manager
Proyecto
Aprobación objetivo 1 Revisión y Aprobación por

Semana 8 (2020-01)
Product Owner

Aprobación del objetivo 2 Semana 14 (2020-01)
Product Owner y QS
Aprobación del objetivo 3 Revisión y Aprobación por

Semana 7 (2020-02)
Product Owner y QS

Aprobación del objetivo 4 Semana 11 (2020-02)
Product Owner

Aprobación del Paper Semana 12(2020-02)
Coautor
143
Hitos Tiempo Tipo de Revisiones
Entrega de Artefactos de la Revisión y Aprobación por

Semana 15 (2020-02)
Memoria Manager
Aprobación de entregables Revisión y Aprobación por

Semana 16 (2020-02)
finales Comité
• Enfoque
A continuación, se presentará la integración de las Fases del Ciclo de Vida con cada uno
de los Entregables a desarrollar durante todo el proyecto. Asimismo, se puede visualizar
la línea de tiempo en el que se visualiza cada entregable a realizar.
Fases del Ciclo de Vida del Proyecto

Fase Entregable Ciclo
Project Charter (Semana 1 – 3)
Iniciación Cap.2 – Plan Outcomes ABET (Semana 2)
Marco Teórico (Semana 2 - 6)
Anexo E – Estado del Arte
Analizar las soluciones propuestas, herramientas
tecnológicas y algoritmos predictivos para el sistema
Planificación de geolocalización (Semana 4 -9)
Artefactos de Gestión de Proyecto (Semana 4 – 9) 2020-1
(Semana 9)
Diseñar la arquitectura tecnológica y el prototipo de la
solución propuesta (Semana 7 – 14)
(Semana 14)
Cap.4 Desarrollo del Proyecto (Semana 1 – 9)
Paper (Semana 1 – 12)
Validación del funcionamiento del sistema
desarrollado (Semana 1 - 9)
144
Ejecución (Semana 9)
Desarrollo del Plan de Continuidad (Semana 9 – 11)
(Semana 11)
Anexo C – Costo y Presupuesto (Semana 10 – 11) 2020-2
Cap.5 Resultado del Proyecto (Semana 11 – 12)
Anexo A – WASC (Semana 12 - 13)
Aprobación del Paper (Semana 12)
Conclusiones y Recomendaciones (Semana 14)
Cierre Preparación y Entrega de Artefactos de la Memoria
(Semana 15)
6.3 Plan de Gestión del Alcance

• EDT
Figura 91: EDT del Proyecto
145
• Diccionario EDT
Diccionario de EDT del Proyecto

Nivel EDT Nombre de tarea Descripción
1 PRY2020126 Proyecto del Sistema de

Geolocalización de Riesgo de
1 Incendios
2 1.1 Inicio Primera etapa del Proyecto
3 1.1.1 Project Charter Elaboración del acta de constitución
2 1.2 Planificación Segunda etapa del Proyecto
1.2.1 Plan de Proyecto Planificación del plan de trabajo del

3 proyecto
1.2.1.1 Cronograma (Planner) Elaboración del Documento con la

4 herramienta Planner
1.2.2 Lineamientos Base Planificación de los artefactos

necesarios para el desarrollo del
3 proyecto
1.2.2.1 Cap 2. Plan (Alineamientos Elaboración de los Outcomes ABET

4 ABET) relacionados con el proyecto
1.2.2.2 Cap 3. Marco Teórico Elaboración del capítulo del artefacto

4 de la memoria
1.2.2.3 Cap 6. Artefactos PM Elaboración de los artefactos del PM

4 con los planes correspondientes
1.2.2.3.1 Plan de Gestión de Proyecto Elaborar el plan de gestión de

5 proyecto
5 1.2.2.3.2 Plan de Gestión de Riesgo Elaborar el plan de gestión de riesgo
1.2.2.3.3 Plan de Gestión de Cronograma Elaborar el plan de gestión de

5 Cronograma
146
1.2.2.3.4 Plan de Gestión de Elaborar el plan de gestión de
5 Comunicaciones comunicaciones
5 1.2.2.3.5 Hoja de Ruta del Proyecto Elaborar la hoja de ruta del proyecto
1.2.2.3.6 Matriz de Asignación de Elaborar la matriz de asignación de

5 Responsabilidades responsabilidades
1.2.2.3.7 Enunciado del Alcance del Elaborar el enunciado del alcance del
5 Proyecto proyecto
5 1.2.2.3.8 Plan de Gestión del Costo Elaborar el plan de gestión del costo
1.2.2.3.9 Plan de Gestión de Elaborar el plan de gestión de

5 Requerimientos requerimientos
5 1.2.2.3.10 Plan de Gestión de Calidad Elaborar el plan de gestión de calidad
5 1.2.2.3.11 Lista de Hitos Elaborar la lista de hitos
5 1.2.2.3.12 Gestión de Recursos Elaborar la gestión de recursos
5 1.2.2.3.13 Gestión del Alcance Elaborar la gestión del alcance
4 1.2.2.4 EDT/WBS Desarrollo del EDT del proyecto
2 1.3 Desarrollo Tercera etapa del Proyecto
1.3.1 Desarrollo Objetivo 1 Objetivo Especifico 1 que consiste en

el análisis de las herramientas
tecnológicas necesarias para el
3 desarrollo del proyecto
1.3.1.1 Análisis de herramientas Desarrollar la investigación de las

tecnológicas tecnologías aplicables para la
4 solución
1.3.1.2 Benchmarking de las tecnologías Elaboración de un benchmarking de

las tecnologías para identificar la
4 mejor alternativa
147
1.3.1.3 Acta de Conformidad Objetivo 1 Documento aprobado por el PO con
respecto a la conformidad del
4 objetivo específico 1 del proyecto
1.3.2 Anexo E. Estado del Arte Desarrollar el documento de Estado

del Arte con los artículos
3 investigados

el diseño del sistema de
3 geolocalización a desarrollar
1.3.3.1 Historias de usuario Elaboración de las historias de

4 usuarios
1.3.3.2 Diseño de la arquitectura Elaboración del documento

tecnológica del sistema archimate correspondiente a la
arquitectura del tecnológica del
4 sistema
1.3.3.3 Modelo del proceso del sistema Elaboración del modelado en Bizagi
4 correspondiente al proceso
1.3.3.4 Diseño del Sistema con las Investigación de las mejores prácticas
mejores practicas para el desarrollo del sistema de
4 geolocalización a desarrollar


el desarrollo del sistema de
geolocalización de riesgo de
3 incendios
1.3.4.1 Cap 4. Desarrollo del Proyecto Desarrollo del producto tanto web
4 como móvil
148
Elaboración de la Cartera de
4 1.3.4.3 Cartera de Proyectos Proyectos
Objetivo Especifico 4 que consiste en

el desarrollo del plan de continuidad
3 1.3.5 Desarrollo Objetivo 4 del proyecto
Elaboración de la documentación
Desarrollo del plan de necesaria para la continuidad del
4 1.3.5.1 continuidad proyecto en el sector
Documento aprobado por el PO con

4 1.3.5.2 Acta de Conformidad Objetivo 4 objetivo específico 4 del proyecto
Elaboración del documento con los

3 1.3.6 Cap 5. Resultados del Proyecto resultados obtenidos de la solución
3 1.3.7 Paper del proyecto Desarrollo del Paper del Proyecto
Realización del anexo

3 1.3.8 Anexos del Proyecto correspondiente a la memoria
Desarrollo del Anexo

correspondiente a las competencias
4 1.3.8.1 Anexo A: WASC WASC
Desarrollo del Anexo

correspondientes al costo y
4 1.3.82 Anexo C: Costos y Presupuestos presupuesto del proyecto
Explicación de los alineamientos

3 1.3.9 Cap 2. Outcomes ABET realizados con los Outcomes ABET
149
Fase de Entrega de todo lo producido
3 1.4.1 Entrega del Proyecto durante la duración del proyecto
Entrega y exposición final del

Entrega del Sistema de Sistema de Geolocalización de
4 1.4.1.1 Geolocalización Riesgo de Incendios desarrollado
Entrega y exposición de los artefactos

desarrollados y el documento de la
4 1.4.1.2 Entrega de Artefactos y memoria memoria
• Alcance de la línea base de Mantenimiento
Línea Base de Mantenimiento del Proyecto

N° Cambio Propuesto por Mantenimiento
1 Solicitud de Cambio Product Owner • Las modificaciones podrán ser
del Título aceptadas hasta la fase de
planificación.
• Consultas con el Portfolio
Manager para validar el cambio.
• Realizar el documento solicitud
de cambio.
2 Definición de nuevas Product Owner • Las modificaciones podrán ser
inclusiones aceptadas hasta la fase de
planificación.
• En caso el cambio sea aceptado,
estos deberán ser aplicados y
actualizados en los entregables
involucrados.
150
exclusiones aceptadas hasta la fase de
planificación.
involucrados.
restricciones aceptadas hasta la fase de
planificación.
involucrados.
5 Definición de nuevos Product Owner • Las modificaciones podrán ser
objetivos aceptadas hasta la fase de
planificación.
involucrados.
6 Definición de nuevos Portfolio Manager • Actualización del plan de
entregables del Trabajo.
proyecto • Modificación de Posibles
Recursos.
151
7 Definición de nuevos Product Owner • Las modificaciones podrán ser
entregables del aceptadas hasta antes de los
producto Sprints de Certificación
• Actualización del plan de
Trabajo.
• Actualización del Sprint
Backlog
• Aceptación de Entregables
Aceptación de Entregables del Proyecto

N° Entregable Criterios de Aceptación
1 Project Charter • Aprobado por el Portfolio Manager y su
firma como muestra de conformidad
• Aprobado por el Product Owner y su firma
como muestra de conformidad
2 Alineamiento de Outcomes • Aprobado por el Portfolio Manager
ABET • Aprobado por el Comité de Proyecto en la
exposición
3 Cap.3 Marco Teórico • Aprobado por el Portfolio Manager
4 Hoja de Ruta del Proyecto • Aprobado por el Portfolio Manager
5 Plan de Gestión del Alcance • Aprobado por el Portfolio Manager
6 Enunciado del Alcance de • Aprobado por el Portfolio Manager
Proyecto
7 Plan de Gestión de • Aprobado por el Portfolio Manager
Requerimientos
8 Plan de Gestión de Cronograma • Aprobado por el Portfolio Manager
9 Lista de Hitos • Aprobado por el Portfolio Manager
152
10 Matriz de Asignación de • Aprobado por el Portfolio Manager
Responsabilidades
11 Plan de Gestión de • Aprobado por el Portfolio Manager
Comunicaciones
12 Plan de Gestión de Riesgos • Aprobado por el Portfolio Manager
13 Investigación y Análisis sobre las • Aprobado por el Product Owner
herramientas tecnológicas
necesarias para el desarrollo del
Sistema de Geolocalización
14 Benchmarking de las tecnologías • Aprobado por el Product Owner
investigadas • Aprobado por QS
15 Anexo E – Estado del Arte • Aprobado por el Portfolio Manager
16 Acta de Aprobación del Objetivo • Aprobado por el Product Owner
1
17 Diseño de la arquitectura • Aprobado por el Product Owner
tecnológica del sistema • Aprobado por QS
18 Modelo del proceso del sistema • Aprobado por el Product Owner
• Aprobado por QS
19 Desarrollo de las historias de • Aprobado por el Product Owner
usuario • Aprobado por QS
20 Listado de Requerimientos del • Aprobado por el Product Owner
sistema
2
22 Cap.4 Desarrollo del Proyecto • Aprobado por el Product Owner
23 Desarrollo del Sistema de • Aprobado por el Product Owner
Geolocalización
24 Casos de Prueba • Aprobado por el Product Owner
• Aprobado por QS
3
153
26 Desarrollo del Plan de • Aprobado por el Product Owner
Continuidad
4
28 Desarrollo del Paper del Proyecto • Aprobado por el Coautor
29 Cap. 5- Resultado del Proyecto • Aprobado por el Product Owner

• Aprobado por el Portfolio Manager
30 Anexo A - WASC • Aprobado por el Portfolio Manager
31 Anexo C- Costos y Presupuestos • Aprobado por el Product Owner
32 Cap.2 - Outcomes ABET • Aprobado por el Portfolio Manager

33 Entrega del proyecto • Aprobado por el Portfolio Manager
• Aprobado por el Product Owner
• Aprobado por el Comité de Proyectos
• Alcance e integración de Requerimientos
Los elementos definidos en el WBS del Proyecto serán integrados junto con los
requerimientos solicitados y criterios del alcance, los cuales se definieron en conjunto con
el Portfolio Manager o el Product Owner. Para ello, durante cada fase del proyecto, se
realizarán reuniones semanales para una revisión continua de que dichos aspectos se están
desarrollando correctamente y formando un entregable de calidad. Asimismo, estas
reuniones permitirán ver al equipo la trazabilidad de los entregables y que estos se cumplan
según lo establecido en el enunciado del alcance y el acta de constitución aprobado por el
Portfolio Manager y el Product Owner. Por otro lado, existirán entregables en donde la
empresa IT Services se encargará de validar el funcionamiento o documentación del
producto final. Esta validación nos otorgará una certificación la cual demuestre que se ha
cumplido con criterios de aceptación durante cada Sprint.
6.4 Plan de Gestión de Requerimientos

• Recolección de Requerimientos
154
Los requerimientos serán obtenidos de acuerdo con las necesidades que se desean abarcar
con el proyecto. Es importante mencionar que la recolección se dará mediante situaciones
tales como conversaciones con el Product Owner y expertos el uso de la lluvia de ideas entre
el equipo del proyecto.
• Conversaciones con el Product Owner: Básicamente se realizarán las sesiones ya

sean virtuales o presenciales con la finalidad de recolectar la información que se
requiere para abarcar las necesidades y proponer una solución a ello.
• Lluvia de Ideas: Es una herramienta que permitirá la obtención de ideas acerca de

los requerimientos que se puedan generar en base al proyecto con la finalidad de que
esta pueda cubrir las necesidades completamente.
• Análisis de Requerimientos
El análisis de requerimientos para un sistema de información involucra distintas
actividades que van desde la investigación, exploración, indagación, validación y
documentación. Esto permitirá tener un sustento bien formulado que proteja todos
los elementos asociados a la información necesaria para el desarrollo de un sistema,
proyecto, software, aplicación especial o componente de un equipo. Esta actividad
comienza cuando se considera el desarrollo. Es decir, desde la primera fase del
proceso. Es importante que este análisis se realice correctamente para que el sistema
de información resultante satisfaga las necesidades reales del usuario. Por ello, los
requerimientos serán analizados de acuerdo con el tipo, prioridad, propósito del
proyecto y el método de revisión.
• Categorías de Requerimientos
Para el desarrollo del proyecto se definieron las categorías de los requerimientos
como funcionales, no funcionales y de proyecto.
• Requerimientos Funcionales: Los requerimientos funcionales son aquellas
cualidades o capacidades que debe ofrecer una solución o sistema, que se basan en
satisfacer las necesidades de los interesados de la solución propuesta.
• Requerimientos No Funcionales: Son aquellos requerimientos no imprescindibles

con los que un sistema puede contar, ya que no afectan de manera directa a las
necesidades que se establecen con el cliente durante la planificación de la solución.
Por tanto, suelen describirse como atributos de calidad de un sistema.
155
• Requerimientos de Negocio (Proyecto): Aquellos requerimientos que se enfocan
en el análisis y elaboración de documentos para la obtención del cumplimiento de un
entregable en el proyecto.
• Documentación de Requerimientos
Los requerimientos se recopilarán para garantizar la viabilidad del proyecto para eso
hemos definido la siguiente estructura que nos ayudar en la documentación:
• ID: Código del requerimiento
• Requerimiento: Descripción del requerimiento
• Categoría: Tipo de Categoría que pertenece
• Propósito del Proyecto: Objetivo al que va relacionado
• Método de Revisión: Método usado para la revisión del requerimiento
• Estado: Estado en el que se encuentra el requerimiento
• Fecha: La fecha en la que cumplirá con el requerimiento
• Priorización de Requerimientos
La priorización de requerimiento permite identificar aquellas necesidades más
importantes para el cliente, definiendo cuáles son de suma importancia para el
desarrollo del sistema.
El elaborar un adecuado proceso de priorización permite garantizar el adecuado

desarrollo de las siguientes actividades:
• Los stakeholders decidirán las funcionalidades esenciales para el sistema.
• Planificar los requerimientos de manera ordenada para una implementación
exitosa.
• Estimar la satisfacción que espera el cliente con la solución propuesta.
• Poder manejar requerimientos contradictorios
La priorización de los requerimientos será definida de la siguiente forma: alto, medio,

bajo de acuerdo con las necesidades del proyecto.
• Métricas
156
Métricas de los Requerimientos del Proyecto
ID Requerimiento Métrica
RQ-01 % de avance del documento del

Analizar las soluciones propuestas para
objetivo 1 con propuestas similares
permitir la identificación de incendios.
RQ-02 % de avance del documento del

Analizar las herramientas de geolocalización objetivo 1 con herramientas de
para la solución. desarrollo investigadas
RQ-03 Aprobación del PO sobre el

Analizar los algoritmos de predicción
benchmarking de los algoritmos de
necesarios para la solución.
predicción
RQ-04 Identificar los componentes para el diseño del % de avance de la investigación de

sistema propuesto componentes tecnológicos
RQ-05 Realizar el diseño de la arquitectura % de avance del diseño de la

tecnológica con el lenguaje de modelado arquitectura tecnológica
Archimate.
RQ-06 Realizar el modelado del proceso de la % de avance del modelado del

solución propuesta usando la notación BPMN proceso de la solución
RQ-07 % de cumplimiento de
Realizar el diseño de mockups de la solución
requerimientos del sistema de
propuesta
geolocalización
RQ-08 Para la validación del sistema se contará con % de avance del desarrollo de las
el desarrollo de una aplicación web y móvil aplicaciones
RQ-09 % de precisión de en la ejecución

El sistema contara con componentes para
del algoritmo con registros
predecir futuras zonas de riesgo de incendio.
históricos
RQ-10 Elaborar un plan de continuidad que garantice % de conformidad por parte del PO
que el sistema propuesto para garantizar la
viabilidad en el tiempo.
157
• Estructura de Trazabilidad
Trazabilidad de los Requerimientos del Proyecto

ID REQUERIMIENTO CATEGORIA PRIORIDAD PROPOSITO DEL PROYECTO METODO ESTADO FECHA
DE
REVISIÓN
RQ- OE1: Analizar las soluciones Reunión Activo 22/05/20
01 Analizar las soluciones propuestas, herramientas tecnológicas y
propuestas para permitir Negocio ALTA algoritmos predictivos que permitan
la identificación de desarrollar un sistema de
incendios. geolocalización para identificar las
zonas de riesgo de incendio
RQ- OE1: Analizar las herramientas Reunión 22/05/20
Analizar las
02 tecnológicas y algoritmos predictivos
herramientas de
para el sistema de geolocalización que
geolocalización para la
Negocio ALTA permitan identificar las zonas de riesgo Activo
solución.
de incendio.
RQ- Analizar los algoritmos OE1: Analizar las herramientas Reunión Activo 22/05/20
03 de predicción necesarios tecnológicas y algoritmos predictivos
para la solución. Negocio ALTA para el sistema de geolocalización que
158
permitan identificar las zonas de riesgo
de incendio.
RQ- OE2: Diseñar la Reunión Planificado 26/06/20
04 Identificar los arquitectura tecnológica y el prototipo
componentes para el Funcional ALTA de la solución propuesta con los
diseño del sistema métodos específicos que permitan la
propuesto identificación de las zonas con
mayor riesgo de incendios
RQ- OE2: Diseñar la Reunión Planificado 26/06/20
05 Realizar el diseño de la arquitectura tecnológica y el prototipo
arquitectura tecnológica Funcional ALTA de la solución propuesta con los
con el lenguaje de métodos específicos que permitan la
modelado Archimate. identificación de las zonas con
RQ- Funcional OE2: Diseñar la Reunión Planificado 26/06/20
06 Realizar el modelado del arquitectura tecnológica y el prototipo
proceso de la solución ALTA de la solución propuesta con los
propuesta usando la métodos específicos que permitan la
notación BPMN identificación de las zonas con
159
RQ- Funcional ALTA OE2: Diseñar la 26/06/20
07 arquitectura tecnológica y el prototipo
Realizar el diseño de
de la solución propuesta con los Reunión Planificado
mockups de la solución
métodos específicos que permitan la
propuesta
identificación de las zonas con
RQ- Funcional ALTA OE3: Validar que el funcionamiento 16/10/20
Para la validación del
08 del sistema desarrollado cumpla con los
sistema se contará con el
requisitos establecidos y evaluar su Reunión
desarrollo de una
efectividad al ser probado por un grupo Planificado
aplicación web y móvil
de usuarios.
RQ- Funcional ALTA OE3: Validar que el funcionamiento 16/10/20
El sistema contara con
09 del sistema desarrollado cumpla con los
componentes para
requisitos establecidos y evaluar su Reunión Planificado
predecir futuras zonas de
efectividad al ser probado por un grupo
riesgo de incendio.
de usuarios.
RQ- Elaborar un plan de Negocio ALTA OE4: Elaborar un plan de continuidad Planificado 30/10/20
10 continuidad que que garantice que el sistema propuesto
garantice que el sistema sea viable tanto tecnológicamente como Reunión
propuesto para financieramente en el tiempo.
160
garantizar la viabilidad
en el tiempo.
161
6.5 Enunciado de Alcance del Proyecto
• Descripción del Alcance del Proyecto
El presente proyecto tiene como finalidad implementar un Sistema de
Geolocalización de Riesgo de Incendios que apoye a las organizaciones respectivas
a tomar las precauciones ante este tipo de eventos generados en los distritos de Lima
Metropolitana en los últimos años. Para lograr este objetivo se definirán los
entregables necesarios para la justificación de la solución. Asimismo, la
investigación que permita identificar las principales causas ante esta problemática,
las distintas soluciones previamente propuestas, las tecnologías que favorezcan al
desarrollo del sistema, los involucrados que participan ante este tipo de sucesos, y
cuáles son las medidas correspondientes a tomar en cuenta frente a este tipo de
desastre.
• Entregables del Proyecto
Como principal entregable del proyecto, buscamos desarrollar un sistema de

geolocalización de riesgo de incendios, el cual permita a las organizaciones
interesadas en la identificación proactiva de zonas con mayor probabilidad de que
ocurran. Asimismo, se desarrollará un plan de continuidad correspondiente al
proyecto, con el fin de poner en producción el producto y no solo establecerlo como
parte de una solución a nivel académico.
• Criterios de Aceptación del Proyecto
Criterios de Aceptación del Proyecto

Criterios de aceptación
Tiempo
1
• El plazo para realizar el desarrollo e implementación de la solución
es de 2 ciclos universitarios, es decir 2020-1 y 2020-2.
2 Recursos
162
• Contar con laptops que permitan el desarrollo del sistema de
geolocalización
• Contar con recursos de software, como lo pueden ser licencias que
permitan su uso durante el desarrollo.
Calidad
• La solución propuesta debe permitir a las instituciones interesadas

3 actuar de manera proactiva frente a un posible evento de incendio.
• Deberá proporcionar información correspondiente a registros de
incendios de fuentes verificadas como lo será INDECI o el
CGBVP.
Alcance
4
• La solución en primera instancia trabajará dentro de los distritos de
Lima Metropolitana.
• Exclusiones del Proyecto
• El sistema de geolocalización no se enfocará en otros lugares fuera de los

distritos de Lima Metropolitana.
• No se podrán incluir nuevos requerimientos en la solución, una vez iniciado el
proceso de desarrollo.
• La información por recopilar para el modelo predictivo no tomará en
consideración aquellos registros de incendios forestales.
6.6 Lista de Hitos
Lista de Hitos del Proyecto
Hito Descripción del Hito Tipo
Hito 1: Validación con el • Validación del • EXTERNAL

comité de proyectos Project Charter frente al • MANDATORY
comité de proyectos.
163
Hito 2: Aprobación de • Validación de los • EXTERNAL
los artefactos de la artefactos de gestión de • MANDATORY
Gestión del Proyecto proyectos con
el Portfolio Manager •
Hito 3: Aprobación del • Validación de los • EXTERNAL
entregables del • MANDATORY
Objetivo 1
Objetivo 1 con PO
Hito 4: Sustentación • Sustento parcial del • INTERNAL

curso Taller de • MANDATORY
Parcial con el Portfolio
Proyecto 1 frente al
Manager Portfolio Manager
Hito 5: Sustentación • Sustento parcial del • EXTERNAL

parcial curso Taller de Proyecto • MANDATORY
1 frente al Comité de
Proyectos
Hito 6 Aprobación del • Validación de los • EXTERNAL

entregables del Objetivo • MANDATORY
Objetivo 2
2 con PO y QS
Hito 7: Sustentación • Sustento final del curso • EXTERNAL

final con Taller de Proyecto 1 • MANDATORY
el Portfolio Manager frente
al Portfolio Manager
Hito 8: Sustentación final • Sustento final del curso • EXTERNAL

Taller de Proyecto 1 • MANDATORY
con el Comité de
frente al Comité de
Proyectos Proyectos

Objetivo 3
3 con PO y QS
Hito 10 Sustentación Par • Sustento final del curso • INTERNAL

cial con Taller de • MANDATORY
el Portfolio Manager Proyecto 2 frente
Hito 11: • Sustento parcial del • EXTERNAL

Sustentación Parcial con curso Taller de Proyecto • MANDATORY
el Comité de Proyectos 2 frente al Comité de
Proyectos
Hito 12: Aprobación • Validación • INTERNA

del Paper del Proyecto del Paper del Proyecto
164
• MANDATORY

Objetivo 4
4 con PO
Hito 14: Sustentación con • Sustento final del curso • INTERNAL

el Portfolio Manager Taller de Proyecto 2 • MANDATORY
frente
Hito 15: Sustentación • Sustento final del curso • EXTERNAL

final Taller de Proyecto 2 • MANDATORY
frente al Comité de
Proyectos
6.7 Plan de Gestión del Cronograma

• Metodología de Horario
Para el Desarrollo del proyecto se realizará la programación de actividades teniendo
en cuenta las Buenas prácticas propuestas por el PMI para la gestión del tiempo por
dicha razón se realizarán las siguientes actividades:
• Diseñar la gestión del cronograma

• Concretar las tareas que se llevaran a cabo
• Determinar el orden de ejecución de las tareas
• Evaluar la disponibilidad de recursos por tarea
• Evaluar los tiempos de duración por tarea
• Ejecutar el cronograma
• Controlar el cronograma
• Herramienta de Programación
La herramienta que se utilizará será el software Microsoft Project, el cual facilita la
elaboración de un correcto plan de proyecto, visualizar la disponibilidad de recursos
para las tareas, dar seguimiento, gestionar los presupuestos y evaluar las cargas de
trabajo.
165
• Nivel de Exactitud
La estimación de cada paquete de trabajo se basó con la ayuda del calendario del
Capstone publicada por la PMO, el cual establece el tiempo de cada entregable y su
revisión de esta.
• Unidades de Medida
La unidad de medida de la duración de las actividades del proyecto es en días.
• Unidades de Variación
El proyecto no presentará mucha holgura, ya que el cronograma está basado en las
fechas designadas por la PMO, las cuales son fijas y, por lo tanto, se cumplirán de
manera clara y directa. Cabe resaltar que, si existiera algún cambio en las fechas, la
PMO deberá informar de dichos cambios a la brevedad para evitar confusión alguna
con lo elaborado en el cronograma del proyecto.
• Programación de Informes y Formatos

El formato que se utilizará para el cronograma será la estructura de organización del
WBS. Tendrá la siguiente estructura:
EDT Nombre de tarea
• Enlaces de Procedimientos Organizacionales
Procedimientos Organizacionales del Proyecto

EDT Nombre de tarea
1 PRY2020126 Sistema de Geolocalización de Riesgo de Incendios
1.1 Inicio
1.1.1 Project Charter
1.1.1.1 Elaborar Project Charter
1.1.1.2 Revisar Project Charter
1.1.1.3 Aprobación del Project Charter
1.2 Planificación
166
1.2.1 Plan de Proyecto
1.2.1.1 Cronograma (Planner)
1.2.1.1.1 Elaboración del Cronograma (Planner)
1.2.2 Lineamientos Base
1.2.2.1 Cap 2. Plan (Alineamientos ABET)
1.2.2.1.1 Elaborar Plan outcomes ABET
1.2.2.2 Cap 3. Marco Teórico
1.2.2.2.1 Elaboración del Marco Teórico
1.2.2.3 Cap 6. Artefactos PM
1.2.2.3.1 Plan de Gestión de Proyecto
1.2.2.3.1.1 Elaborar Plan de Gestión de Proyecto
1.2.2.3.1.2 Revisar Plan de Gestión de Proyecto
1.2.2.3.2 Plan de Gestión de Riesgo
1.2.2.3.2.1 Elaborar Plan de Gestión de Riesgo
1.2.2.3.2.2 Revisar Plan de Gestión de Riesgo
1.2.2.3.3 Plan de Gestión de Cronograma
1.2.2.3.3.1 Elaborar Plan de Gestión de Cronograma
1.2.2.3.3.2 Revisar Plan de Gestión de Cronograma
1.2.2.3.4 Plan de Gestión de Comunicaciones
1.2.2.3.4.1 Elaborar Plan de Gestión de Comunicaciones
1.2.2.3.4.2 Revisar Plan de Gestión de Comunicaciones
1.2.2.3.5 Hoja de Ruta del Proyecto
1.2.2.3.5.1 Elaborar Hoja de Ruta del Proyecto
167
1.2.2.3.5.2 Revisar Hoja de Ruta del Proyecto
1.2.2.3.6 Matriz de Asignación de Responsabilidades
1.2.2.3.6.1 Elaborar Matriz de Asignación de Responsabilidades
1.2.2.3.6.2 Revisar Matriz de Asignación de Responsabilidades
1.2.2.3.7 Enunciado del Alcance del Proyecto
1.2.2.3.7.1 Elaborar Enunciado del Alcance del Proyecto
1.2.2.3.7.2 Revisar Enunciado del Alcance del Proyecto
1.2.2.3.8 Plan de Gestión del Costo
1.2.2.3.8.1 Elaborar Gestión del Costo
1.2.2.3.8.2 Revisar Gestión del Costo
1.2.2.3.9 Plan de Gestión de Requerimientos
1.2.2.3.9.1 Elaborar Plan de Gestión de Requerimientos
1.2.2.3.9.2 Revisar Plan de Gestión de Requerimientos
1.2.2.3.10 Plan de Gestión de Calidad
1.2.2.3.10.1 Elaborar Plan de Gestión de Calidad
1.2.2.3.10.2 Revisar Plan de Gestión de Calidad
1.2.2.3.11 Lista de Hitos
1.2.2.3.11.1 Elaborar Lista de Hitos
1.2.2.3.11.2 Revisar Lista de Hitos
1.2.2.3.12 Gestión de Recursos
1.2.2.3.12.1 Elaborar Gestión de Recursos
1.2.2.3.12.2 Revisar Gestión del Recursos
1.2.2.3.13 Gestión del Alcance
168
1.2.2.3.13.1 Elaborar Gestión del Alcance
1.2.2.3.13.2 Revisar Gestión del Alcance
1.2.2.4 EDT/WBS
1.2.2.4.1 Elaboración de EDT/WBS
1.3 Desarrollo
1.3.1 Desarrollo Objetivo 1
1.3.1.1 Análisis de herramientas tecnológicas
1.3.1.1.1 Investigación de herramientas tecnológicas
1.3.1.1.2 Análisis de las distintas herramientas tecnológicas
1.3.1.2 Benchmarking de las tecnologías
1.3.1.2.1 Elaborar benchmarking de las tecnologías del sistema
1.3.1.3 Acta de Conformidad Objetivo 1
1.3.1.3.1 Elaborar acta de conformidad del Objetivo 1
1.3.1.3.2 Aprobación del PO con respecto al Objetivo 1
1.3.2 Anexo E. Estado del Arte
1.3.2.1 Elaborar Estado del Arte
1.3.3.1 Historias de usuario
1.3.3.1.1 Elaborar Historias de Usuario
1.3.3.2 Diseño de la arquitectura tecnológica del sistema
1.3.3.2.1 Elaborar la arquitectura tecnológica del sistema
1.3.3.3 Modelo del proceso del sistema
1.3.3.3.1 Elaborar el modelado del proceso del sistema
169
1.3.3.4 Diseño del Sistema con las mejores practicas
1.3.3.5.3 Aprobación de QS con respecto al Objetivo 2
1.3.4.1 Cap 4. Desarrollo del Proyecto
1.3.4.1.1 Elaborar Desarrollo de la Aplicación Web
1.3.4.1.2 Elaborar Desarrollo de la Aplicación Móvil
1.3.4.2.3 Aprobación de QS con respecto al Objetivo 3
1.3.4.3 Cartera de Proyectos
1.3.4.3.1 Elaborar Cartera de Proyectos
1.3.4.3.2 Revisar Cartera de Proyectos
1.3.5.1 Desarrollo del plan de continuidad
1.3.5.1.1 Elaborar del Plan de Continuidad
1.3.5.1.2 Revisar Plan de Continuidad
1.3.5.1.3 Corregir Plan de Continuidad
170
1.3.6 Cap 5. Resultados del Proyecto
1.3.6.1 Elaborar Resultados del Proyecto
1.3.7 Desarrollo del Paper
1.3.7.1 Elaborar Paper del Proyecto
1.3.8 Anexos del Proyecto
1.3.8.1 Elaborar Anexo A. WASC
1.3.8.2 Elaborar Anexo C. Costos y Presupuesto
1.3.9 Cap 2. Outcomes ABET
1.3.9.1 Elaborar Cap 2. Outcomes ABET
1.4 Cierre
1.4.1 Entrega del Proyecto
1.4.1.1 Entrega del Sistema de Geolocalización
1.4.1.2 Entrega de Artefactos y memoria
1.4.1.2.1 Preparación de los artefactos de la memoria
1.4.1.2.2 Entrega de los artefactos de la memoria
Para la gestión del cronograma se iniciará a partir de los siguientes documentos:
• Acta de constitución: En donde se describirá el resumen del cronograma de hitos

y los requisitos necesarios para obtener la aprobación del proyecto.
• Línea base del alcance: Incluye enunciado del alcance del proyecto y de la
estructura de desglose del trabajo EDT/WBS utilizada para definir las
actividades, estimar la duración y gestionar el cronograma.
Además, se realizarán reuniones entre el Product Manager y el equipo del proyecto en la
etapa de planificación, para identificar las actividades de los entregables.
171
• Actualización de Horarios
El equipo del proyecto con ayuda del Portfolio Manager actualizará el cronograma
del proyecto de forma semanal, mediante reuniones de trabajo en las cuáles se
analizará el avance alcanzado contrastado con el avance programado.
La presentación de los cambios en el cronograma se realizará mediante un reporte
semanal, en donde se mostrará las actividades avanzadas en ese lapso y el porcentaje
de avance en cada una de las tareas realizadas. De igual forma se manejará un reporte
gerencial sobre cumplimiento de hitos.
De los avances obtenidos el Gerente del Proyecto deberá realizar especial
seguimiento sobre los avances vencidos a fin de no ocasionar retrasos en la
planificación del proyecto.
6.8 Plan de Gestión de Costos

• Unidades de Medidas
Para el desarrollo del Proyecto se definieron las Unidades de Medida para cada uno
de los recursos los cuales serán usadas en la medición de los Costos como, por
ejemplo, Costos indirectos, tasas horarias, horas hombres, y entre otros.
Unidades de Medida del Proyecto

Recurso Unidades de Medida
Comité del Proyecto Horas hombre
Manager Horas hombre
Product Owner Horas hombre
Scrum Master Horas hombre
Project Manager Horas hombre
Recursos IT Services Horas hombre
Recursos Software Factory Horas hombre
Recurso Físico Cantidad
Recurso de Software Horas de Uso
172
• Nivel de Precisión
Nivel de Precisión del Proyecto
Tipo de Recursos Nivel de Precisión
Persona Horas (8 horas por día)
Físico Horas de Uso
Software Horas de Uso
• Nivel de Exactitud
Se detalla el rango admisible que se utilizará para el planteamiento de estimaciones
realistas sobres los costos que involucran a cada actividad que se llevara a cabo. Por
ello, en base a esto se otorgará un rango aceptable de 5% en las horas de uso a los
recursos humanos y físicos.
Nivel de Exactitud del Proyecto

Costo de Actividades Nivel de Exactitud
5% adicional a las horas asignadas en cada

Horas Hombre
entregable
Horas de Uso de Recursos Físico o 5% adicional a las horas uso asignada a los
de SW recursos
• Enlaces de Procesos Organizacionales

Para efectos del proyecto, se usará un software denominado “Project” en el que se
podrá definir de manera correcta los costos asociados a los recursos (físicos y
humano), los cuales serán empleados durante el desarrollo del proyecto. Además, se
podrá elaborar gráficos con la finalidad de permitir una mayor visibilidad de la
gestión de los costos durante todo el proyecto.
Se podrá realizar los gráficos de los siguientes enunciados:
• Flujo de Caja
• Información general de Costos de la Tarea
• Informe de valor acumulado
173
• Sobrecostos
• Visión General de Costos
• Umbrales de Control
De acuerdo con las actividades que se realizan durante todo el proyecto en el que
solo se incurre en costos de horas hombre y recursos físicos los umbrales de control
asociados se verán en el siguiente cuadro:
Umbrales de Control del Proyecto


Horas Hombres
variación de 5%

Horas de Uso de Recursos Físicos
variación de 5%

Horas de Uso de Recursos SW
variación de 5%
• Reglas de Medición del Rendimiento

Para efectos de la medición del rendimiento en la gestión del proyecto, esta se
realizará a través de los siguientes puntos:
• Porcentaje Acumulado
• Estimaciones por Completar (ETC)
• Estimaciones al Finalizar (EAC)
• Información y Formato de Informes de Costos

La información y formato de informe de costos será realizado a través de una cinta
de informes que permitirán mostrar el detalle de cada uno de estos gráficos
generados, los cuales permitirá tener controlado y monitoreado todas las actividades
y el costo de la generación de esta.
• Detalles Adicionales
En este punto, se detalla que todas las actividades serán realizadas y supervisadas por
los miembros del Proyecto. Sin embargo, para efectos del proyecto no se necesitará
174
opciones de financiación estratégica o pedir fondos prestados ya que el equipo de
proyecto con los recursos físicos necesarios para el desarrollo.
6.9 Plan de Gestión de Calidad

• Estándares de Calidad
Para cumplir con objetivo general del proyecto, debemos desarrollar e implementar
un Sistema de Geolocalización de Riesgo de Incendios. En este sentido, se debe
alinear el desarrollo de este sistema acorde a las normas y estándares de calidad
existentes. A continuación, se presenta dichos estándares y una descripción de cada
una de ellas.
Estándares de Calidad del Proyecto

Estándar Descripción
1. ISO / IEC / IEEE 29119 1. Modelo de proceso de pruebas, que se
compone de un conjunto de estándares
internacionales, en donde se proponen
una serie actividades a realizar en
cualquier ciclo de vida de desarrollo de
software.
2. ISO 9001 2. Método de trabajo que permite
garantizar a los clientes una óptima
calidad de los productos y servicios que
se les ofrece.
3. ISO 25010 3. Modelo en el que se determinan las
características de calidad que se deben
considerar durante la evaluación de
propiedades de un producto software
desarrollado.
• Objetivos de Calidad
175
Objetivos de Calidad del Proyecto
Especificación o Métrica Medida
1. Corrección 1. Facilidad para poder modificar un
programa en caso su entorno cambie, o
necesite mejorar si el cliente final desea
agregar una nueva funcionalidad.
2. Facilidad de Mantenimiento 2. Facilidad y eficacia para el
mantenimiento y reparación del
producto. Además, el tiempo medio de
reparación y la capacidad de
diagnóstico.
3. Integridad 3. Capacidad de un sistema para resistir
ataques (tanto accidentales como
intencionados) contra su seguridad.
4. Facilidad de Uso 4. Facilidad con que los usuarios pueden
utilizar un programa y cumplir una
actividad en concreto.
• Roles y Responsabilidades de Calidad
Responsables de Calidad del Proyecto

Roles Responsabilidades
Project Manager • Elaboración y Supervisión de los

Artefactos tanto el proyecto como
del producto
Scrum Master • Elaboración y Supervisión de los

Artefactos tanto el proyecto como
del producto
Portfolio Manager • Realizar la validación de los

entregables del Proyecto
176
Roles Responsabilidades
• Realizar la aprobación del equipo

para realizar la exposición frente al
comité
Product Owner • Realizar la validación de los

entregables del Producto
Comité de Proyectos • Validar la sustentación que realicen

el Project Manager y Scrum Master
Recursos de IT Services • Realizar la certificación de los

artefactos según el Sprint
correspondiente.
• Realizar las asignaciones solicitadas
por el equipo de proyecto haciendo
uso de las mejores prácticas.
Recursos de Software Factory • Apoyar al desarrollo del Sistema de

Geolocalización de Riesgo de
Incendios, haciendo uso de las
mejores prácticas.
• Entregables y Proceso sujetos a la Revisión de Calidad
177
Entregables de Calidad del Proyecto
Entregables Procesos
• Sistema de Geolocalización de
• Proceso de Certificación de Historias de
Riesgo de Incendios
Usuario
• Elaboración de las Historias de
• Proceso de Certificación del Modelado del
Usuario
Proceso de Geolocalización
• Elaboración del Modelado del
• Proceso de Certificación de la
Proceso de Geolocalización
Arquitectura Tecnológica
• Elaboración del Modelado de la
• Desarrollo del Sistema con ayuda de
Arquitectura Tecnológica del
recursos de Software Factory
Sistema
• Enfoque de Gestión de Calidad

De acuerdo con la ISO 29119, esta ofrece ciertos documentos que garantizan la
correcta evaluación de las funcionalidades con las que el software a desarrollar
deberá cumplir. Asimismo, este estándar consta de 5 partes que permitirán poner a
prueba la calidad del producto final. Esto se desarrollará desde el Sprint el 5 hasta el
7, en los que se ejecutará los respectivos casos de prueba para validar las
funcionalidades definida de la solución propuesta.
Con respecto con la ISO 9001, la gestión de la calidad nos permitirá no solo contar
con una adecuada planificación de nuestra propuesta, sino que también podremos
definir algunos mecanismos para el seguimiento, control y la mejora continua
durante cada fase del proyecto. Esto también se podrá identificar durante la
elaboración de los documentos de requerimientos, casos de prueba y casos de uso.
Según la ISO 25010, el grado de satisfacción de un usuario sobre un producto de

software, es el que define la calidad y el valor de dicho producto. De acuerdo con el
modelo de calidad que se propone, es necesario precisar los requisitos que el cliente
considera necesarios (funcionalidad, rendimiento, seguridad, mantenibilidad, etc.).
En nuestro proyecto, estos aspectos se definirán mediante una evaluación que se
realizará con ayuda de los usuarios finales.
178
• Procedimientos de Calidad Aplicables
Procedimiento de Calidad del Proyecto

Código Procedimiento Objetivo
PC01 Revisión del modelo de la Analizar y corregir el modelado
arquitectura tecnológica según las observaciones o
correcciones que el Product Owner
nos pueda ofrecer.
PC02 Revisión de los mockups Analizar y plasmar un prototipo que

correspondientes al producto final represente al sistema de
geolocalización final y que nos
permita obtener un feedback por
parte del Product Owner para la
mejora.
PC03 Revisión del sistema de Revisar y modificar los cambios

geolocalización y sus funcionalidades según el prototipo presentado
inicialmente, y que este cumpla en
satisfacer las necesidades
establecidas por el Cliente.
6.10 Matriz de Asignación de Responsabilidades
Matriz de Responsabilidades del Proyecto

Fase Project Scrum Manager Product Recurso
Manager Master Owner IT Service
Project Charter R,C R,C I A
Outcomes ABET R,C R,C I
Plan de Gestión de
R,C R,C I
alcance
Enunciado del
R,C R,C I
alcance del proyecto
179
Plan de gestión de
R,C R,C I
Requerimientos
Plan de Gestión del
R,C R,C I
Proyecto
Plan de Gestión de
R,C R,C I
comunicaciones
Hoja de Ruta del
R,C R,C I
Proyecto
Plan de Gestión de
R,C R,C I
Cronograma
Lista de Hitos R,C R,C I
Matriz de
Asignación de R,C R,C I
Responsabilidades
Plan de Gestión de
R,C R,C I
Recursos
Plan de Gestión de
R,C R,C I
Calidad
Plan de Gestión de
R,C R,C I
Riesgos
Investigación de las
tecnologias y R,C R,C I C
herramientas
Diseño del Sistema
R,C R,C I
de Geolocalización
Desarrollo del
Sistema de R,C R,C I C
Geolocalización
Plan de
R,C R,C I A
Continuidad
180
6.11 Plan de Gestión de Recursos
• Identificación del Miembro del Equipo y Estimaciones
Identificación de Miembros del Equipo de Proyecto

Rol Numero Nivel de pericia
1. Product Owner Uno Alta
2. Manager Uno Alta
3. Project Manager Uno Alta
4. Scrum Master Uno Alta
5. Recurso de IT Services Uno Alta
• Adquisiciones de Miembros del Equipo

El procedimiento para el requerimiento y adquisición de personal es de acuerdo con
el proceso que siguen las empresas virtuales.
● Product Owner: Asignado por la PMO de acuerdo con el tipo de proyecto en

la cartera de proyectos.
● Manager: Asignado por la PMO de acuerdo con el tipo de proyecto en la

cartera de proyectos.
● Project Manager: Asignados a un proyecto a través de una postulación al

mismo.
● Scrum Master: Asignados a un proyecto a través de una postulación al mismo.
● Recursos: Son asignados de acuerdo con un proceso de la misma empresa.
• Gestión de Miembros del Equipo

A continuación, se describirá como los miembros del equipo serán administrados y
eventualmente liberados del proyecto cuando se hayan concluido sus actividades.
Gestión de Miembros del Equipo de Proyecto

Miembros del Equipo Descripción de Actividades
Responsable de revisar y aprobar los

Manager
entregables de cada fase del proyecto.
181
Asimismo, será liberado el cierre del
proyecto
Responsable de revisar y aprobar los

entregables en base al producto que se
Product Owner realiza en cada fase del proyecto.
Asimismo, será liberado el cierre del
proyecto
Responsable de elaborar, gestionar y

presentar los entregables que se solicitan
Project Manager para cumplir con los objetivos del proyecto.
Asimismo, será liberado al cierre del
proyecto
Responsable de elaborar, gestionar y

presentar los entregables que se solicitan
Scrum Master para cumplir con los objetivos del proyecto.
Asimismo, será liberado al cierre del
proyecto
Responsable de desarrollar adecuadamente

la aplicación a presentar del proyecto.
Recursos IT Services
Asimismo, será liberado al cierre de la fase
de validación.
• Organigrama del Proyecto

A continuación, se presenta la organización del proyecto de forma jerárquica en un
organigrama con la finalidad de que se visualice los participantes en ello.
182
Figura 92: Organigrama del Proyecto
• Roles y Responsabilidades
Roles y Responsabilidades de los Miembros del Equipo de Proyecto

Rol Responsabilidad Autoridad
● Aprobar proyectos ● Rosario Villalta

profesionales. ● Jimmy Armas
Comité de Proyectos ● Aprobar continuidad ● Daniel Subauste
de proyectos. ● Willy Ugarte
● Realizar las ● Alfredo Barrientos

coordinaciones entre
los gerentes
PMO ● Control y
Seguimiento general
de los proyectos
183
● Asesorar y realizar ● Romulo Lomparte
seguimiento a los
avances del proyecto
● Responder sobre
Product Owner
consultas del proyecto
● Aprobar resultados
del proyecto
● Asesorar y dar ● Emilio Herrera

seguimiento a los
proyectos de la
empresa IT Innova
Manager ● Facilitar
comunicación con la
empresa de IT
Services
● Planifica, dirige y ● Julio Cesar

verifica el cumpliendo Cardenas Suca
de los objetivos del
proyecto
● Definición del alcance
● Gestión del proyecto
Project Manager ● Gestión de los
recursos
● Seguimiento del
cronograma
● Reuniones con el
cliente
184
• Responsable de la • Diego Jesus Tapia
dinámica del equipo Medina
Scrum
• Responsable de
elaborar el product
backlog
Scrum Master • Gestión del proceso

Scrum
• Elimina
impedimentos que
puedan afectar a la
entrega del producto
● Apoyar con la ● Recursos asignados

investigación y durante los ciclos
recopilación de académicos 2020-
fuentes bibliográficas 01 y 2020-02
● Apoyar en la
validación de los
entregables del
Recursos
proyecto de acuerdo
con Sprints
● Emitir certificados de
calidad para los
entregables revisados
del proyecto
• Requerimientos del Entrenamiento
185
Los Recursos de IT Services que cumplen rol de Analista QA tendrá disposición de
elementos o archivos para entender el contexto del proyecto, de manera que pueda
validar y certificar el entregable.
• Recompensas y Reconocimientos
Al finalizar las actividades realizadas por el recurso de TDP, se otorgará una
calificación indicando la calidad del entregable y sus limitaciones que debe mejorar
para futuras actividades.
• Desarrollo del Equipo
Desarrollo del Equipo de Proyecto

Rol Responsabilidad
● Aprobar proyectos profesionales.

Comité de Proyectos ● Aprobar continuidad de proyectos.
● Realizar las coordinaciones entre los

gerentes
PMO ● Control y Seguimiento general de los
proyectos
● Asesorar y realizar seguimiento a los

avances del proyecto
● Responder sobre consultas del
Product Owner
proyecto
● Aprobar resultados del proyecto
● Asesorar y dar seguimiento a los

proyectos de la empresa IT Innova
Manager
● Facilitar comunicación con la
empresa de IT Services
186
● Planifica, dirige y verifica el
cumpliendo de los objetivos del
proyecto
● Definición del alcance
Project Manager ● Gestión del proyecto
● Gestión de los recursos
● Seguimiento del cronograma
● Reuniones con el cliente
• Responsable de la dinámica del

equipo Scrum
• Responsable de elaborar el product
Scrum Master backlog
• Gestión del proceso Scrum
• Elimina impedimentos que puedan
afectar a la entrega del producto
● Apoyar con la investigación y

recopilación de fuentes bibliográficas
● Apoyar en la validación de los
entregables del proyecto de acuerdo
Recursos
con Sprints
● Emitir certificados de calidad para los
entregables revisados del proyecto
• Identificación de Recursos Físicos
187
Identificación de Recursos Físicos del Proyecto
Recurso Cantidad Grado
1. Laptop Personal de Una Alta
Project Manager
2. Laptop Personal de Una Alta
Scrum Master
3. Dispositivo Móvil con Una Alta
SO Android
• Adquisiciones de Recursos Física

Es claro mencionar que la adquisición de los recursos físicos mencionados en el
punto anterior, ya son recursos con los que dispone cada uno de los miembros del
equipo de Proyecto.
• Gestión de Recursos Físicos
Gestión de Recursos Físicos de Proyecto

Recurso Tiempo
Laptop Personal de Project Manager Ciclos Académicos (2020-01 - 2020-02)
Laptop Personal de Scrum Master Ciclos Académicos (2020-01 - 2020-02)
Dispositivo Móvil con SO Android Ciclos Académicos (2020-02)
6.12 Plan de Gestión de Comunicaciones
Gestión de Comunicación del Proyecto

Stakeholder Información Método Frecuencia Remitente
Portfolio Manager Project Charter • Correo Una sola vez Julio
• Reunión Cardenas
virtual
Portfolio Manager Plan de gestión del • Correo Una sola vez Diego Tapia
proyecto • Reunión
virtual
Portfolio Manager Informe semanal del • Reunión Semanal Julio
virtual
proyecto Cardenas
188
Product Owner Project Charter • Correo Una sola vez Julio
• Reunión Cardenas
virtual
Product Owner Presentación del • Correo Una sola vez Julio
Product Backlog • Reunión Cardenas
virtual
Product Owner Informe semanal del • Reunión Semanal Diego Tapia
virtual
proyecto
Product Owner Análisis de tecnologías • Reunión Una sola vez Diego Tapia
virtual
y herramientas para el
desarrollo de la solución
Product Owner Diseño de la Solución • Reunión Una sola vez Diego Tapia
virtual
Propuesta
Product Owner Validación de la • Reunión Una sola vez Julio

virtual
funcionalidad de la Cardenas
solución
Product Owner Plan de continuidad de • Reunión Una sola vez Julio
virtual
la solución Cardenas
Product Owner Acta de reunión • Correo Semanal Julio
Cardenas
Recurso QS Acta de reunión Recurso • Correo Semanal Diego Tapia
IT Service
Comité de Sustentación del • Reunión Dos veces Julio
virtual
Proyectos proyecto Cardenas
• Restricciones o Suposiciones de Comunicación
Restricciones y Supuestos de la Comunicación del Proyecto

Supuestos Restricciones
Las reuniones virtuales se desarrollarán Las reuniones no podrán ser de manera
durante el horario de clases. presencial.
No existe una confidencialidad en las
reuniones virtuales.
189
Limitación del uso de internet.
• Glosario de Terminología Común

• Portfolio Manager: Este rol se encarga de ayudar a una persona a invertir en los
mejores planes de inversión disponibles para obtener retornos garantizados en el
futuro
• Product Owner: Es la persona encargada de actuar como usuario del negocio o
producto frente al Equipo Scrum. Asimismo, promueve una comunicación clara
con el equipo acerca de los requisitos de los productos o servicios que el negocio
requiere, estableciendo los objetivos, criterios de aceptación y el cumplimiento
de estos mismos.
• Product Backlog: Es un listado de todas las tareas que se pretenden hacer durante
el desarrollo de un proyecto.
6.13 Plan de Gestión de Riesgos

• Estrategia
Para poder gestionar los riesgos del proyecto se implementarán estrategias por cada tipo de
riesgo de la siguiente manera:
• Riesgos Positivos:
o Explotar: Esta respuesta busca eliminar la incertidumbre asociada con un

riesgo, asegurando que la oportunidad definitivamente se concrete.
o Mejorar: Esta respuesta busca aumentar la probabilidad y/o los impactos
positivos de una oportunidad.
o Compartir: Esta respuesta busca asignar toda o parte de la oportunidad a
un tercero mejor capacitado con la finalidad poder capturar la oportunidad
en beneficio del proyecto.
o Aceptar: Esta respuesta busca aprovechar la oportunidad en caso se
presente, pero sin tomar ninguna medida.
190
• Riesgos Negativos:
o Evitar: Esta respuesta busca reducir a un umbral aceptable la probabilidad

y/o el impacto de un riesgo.
o Transferir: Esta respuesta busca trasladar el impacto a un tercero, junto
con la responsabilidad de la respuesta.
o Mitigar: Esta respuesta busca que el equipo del proyecto intente reducir
la probabilidad de ocurrencia o impacto de un riesgo.
o Aceptar: Esta respuesta busca que el equipo del proyecto decida
reconocer el riesgo y no tomar ninguna medida.
• Metodología
El Proyecto para este punto tomará la metodología empleada en la guía de PMBOK,
la cual define al riesgo como un evento que si ocurre presenta un efecto contra el
desarrollo del trabajo.
Las herramientas, fuente de datos que se utilizará que se usaran para la gestión de
riesgos son:
▪ Revisión a la documentación: Permite tener una idea del avance con respecto al
desarrollo de planes, supuestos o acuerdos y también de disponer de información
que confirme dichos documentos se hayan elaborado de manera adecuada.
▪ Entrevistas: El proceso de entrevistas a personas con mayor experiencia en este

tipo de proyectos y expertos en la materia permiten identificar los riesgos.
▪ Análisis con lista de verificación: Se elaboran utilizando la data histórica y el

conocimiento adquirido a partir de proyectos similares y diversas fuentes de
información.
• Roles y Responsabilidades
A continuación, se presenta los roles de los miembros del proyecto y las
responsabilidades que tienen dentro de ellos ante la gestión de los riesgos.
191
Roles y Responsabilidades de los Miembros del Proyecto
Rol Responsabilidades
1. Project Manager • Establecer los roles en la gestión de
riesgos y asignar a las personas
adecuadas
• Llevar a cabo el proceso de
identificación y gestión de riesgos.
• Considerar la gestión de riesgo durante
el plan de gestión de proyecto.
• Capacidad para resolver
disconformidades y dar continuidad al
proceso.
2. Scrum Master • Proveer los conocimientos necesarios

para definir los planes acciones que se
deberán tener en cuenta frente a los
riesgos que hayan sido identificados
previamente.
• Brindar apoyo y cooperar en la

implementación de las acciones de
respuesta decretadas.
3. Portfolio Manager • Revisar el avance del proyecto, brinda

retroalimentación respecto a los avances
y garantiza el cumplimiento de los
objetivos principales del proyecto
4. Product Owner • Delimitar el alcance y revisa los avances
del proyecto, así como del brindar
retroalimentación de los entregables
192
• Categorías de Riesgo
Para el desarrollo del proyecto se clasificaron en categorías los riesgos de la siguiente
manera:
Externos
• Imprevisibles: Desastres naturales y cuarentenas.
• Predecibles: Normativas, disponibilidad de materia prima.
Internos
• Cliente: Poca definición del producto.
• Organización: Paros laborales, retraso de aprobaciones.
• Técnicas: Cambios de tecnología, errores de diseño.
• Gestión del Proyecto.
• Legales: Licencias, patentes.
193
• Financiación de la Gestión de Riesgo
Gestión de Riesgos del Proyecto
ID RIESGO DESCRIPCIÓN RESPONSABLE DISPARADOR ESTADO PROBABILIDAD IMPACTO ESTRATEGIA
No entregar a
tiempo el Project Revisar Project
Demora en la Diego Tapia
Charter por lo cual Charter
1 entrega del Julio Cardenas Planificado Bajo Alto Mitigar
puede
Project Charter
desencadenar que (1.1.1 Project
no sea validada Charter)
Cambio del
Cambio del
alcance del
Cambio del Diego Tapia Alcance
proyecto según las
2 Alcance del Julio Cardenas (1.2.2.3.13 Plan Planificado Bajo Alto Mitigar
necesidades del
Proyecto de Gestión de
Product Owner o
Alcance)
Portfolio Manager
Mala definición Se definen de Diego Tapia Mala definición

3 de los manera Julio Cardenas de la Planificado Bajo Alto Mitigar
requerimientos inadecuada los trazabilidad de
194
requerimientos de los
la Solución requerimientos
(1.2.2.3.9 Plan
de Gestión de
Requerimientos)
Falta de
Falta de Los recursos de conocimientos
Diego Tapia
conocimiento de TDP no cumplen para el
4 Julio Cardenas Planificado Bajo Media Mitigar
los Recursos de con las actividades desarrollo del
TDP encargadas análisis (1.3.1
Objetivo 1)
Revisar
Demora en la No entregar a
documento de
entrega del tiempo el
Diego Tapia investigación
documento de documento de
5 Julio Cardenas Planificado Bajo Alto Mitigar
Investigación investigación para
(1.3.1
para cumplir con cumplir el objetivo
Desarrollo del
el Objetivo 1 1
Objetivo 1)
195
Revisar Diseño
No entregar en el de la
Demora en la tiempo disponible Arquitectura
entrega del el entregable Diego Tapia Tecnológico
6 diseño de la ocasiona que no Julio Cardenas (1.3.3.2 Diseño Planificado Bajo Alto Mitigar
arquitectura pueda ser recibido de la
tecnológica para ser arquitectura
certificado tecnológica)
Errores en los
entregables del
Los entregables de
Diego Tapia objetivo 2
Objetivo 2 no objetivo 2 no son
7 Julio Cardenas Planificado Bajo Alto Evitar
sea cumplido aprobados por IT
(1.3.3
SERVICES
Desarrollo del
Objetivo 2)
196
Revisar
No entregar en el
Mockups de la
tiempo disponible
Demora de la Aplicación
el entregable Diego Tapia
entrega de los
8 ocasiona que no Julio Cardenas Planificado Bajo Alto Mitigar
Mockups de la (1.3.3.4 Diseño
pueda ser recibido
Aplicación del sistema con
para ser
las mejoras
certificado
practicas)
No entregar en el
tiempo disponible Revisar la
Demora en el el entregable Diego Tapia Aplicación
9 Desarrollo de la ocasiona que no Julio Cardenas (1.3.4.1 Planificado Bajo Alto Mitigar
solución pueda ser recibido Desarrollo del
para ser Proyecto)
certificado
Diego Tapia Errores en los

Objetivo 3 no La validación del
10 Julio Cardenas entregables del Planificado Bajo Alto Evitar
sea aprobado sistema no es
objetivo 3 (1.3.4
197
aprobada por IT Desarrollo del

SERVICES objetivo 3)
No entregar en el
Revisar Plan de
tiempo disponible
Continuidad
Demora en la el entregable Diego Tapia
11 entrega del Plan ocasiona que no Julio Cardenas Planificado Bajo Alto Mitigar
(1.3.5.1
de Continuidad pueda ser recibido
Desarrollar Plan
para ser
de Continuidad)
certificado
No entregar en el Entrega de los

tiempo disponible Artefactos de la
Demora en la
el entregable Diego Tapia Memoria
entrega de los
12 ocasiona que no Julio Cardenas Planificado Bajo Alto Mitigar
Artefactos de la
pueda ser recibido (1.4.1.2 Entrega
memoria
para ser de artefactos y
certificado memoria)
198
• Protocolos de Contingencia
Protocolos de Contingencia del Proyecto

TIPO DE OBJETIVO DE
ID ACTIVIDADES RESPONSABLES
ACCIÓN CONTINGENCIA
• Planificar las
actividades
• Priorizar las
Entregar en el Diego Tapia
actividades
1 Mitigar tiempo habilitado el Julio Cardenas
• Elaborar el
entregable
entregable
• Validar el
entregable
• Analizar el Diego Tapia

impacto del Julio Cardenas
No afectar la cambio
2 Mitigar viabilidad del • Gestionar
proyecto mediante un
control de
cambio.
• Realizar Diego Tapia

reuniones Julio Cardenas
No afectar la
semanales con PO
3 Mitigar calidad del
para validar la
producto
calidad del
producto.
• Se otorgará Diego Tapia

Brindar un un tiempo Julio Cardenas
4 Mitigar entregable de buena adicional (10%
calidad del tiempo total
de la tarea) para
199
TIPO DE OBJETIVO DE
que pueda
desarrollar la
actividad con
éxito.
• Planificar las Diego Tapia

actividades Julio Cardenas
• Priorizar las
Entregar en el
actividades
5 Mitigar tiempo habilitado el
• Elaborar el
entregable
entregable
• Validar el
entregable

• Priorizar las
Entregar en el
actividades
• Elaborar el
entregable
entregable
• Validar el
entregable

• Priorizar las
Entregar en el
actividades
• Elaborar el
entregable
entregable
• Validar el
entregable
200
TIPO DE OBJETIVO DE

• Priorizar las
Entregar todo lo
actividades
8 Mitigar requerido para la
• Elaborar el
certificación
entregable
• Validar el
entregable

• Priorizar las
Entregar en el
actividades
• Elaborar el
entregable
entregable
• Validar el
entregable

• Priorizar las
Entregar todo lo
actividades
10 Mitigar requerido para la
• Elaborar el
certificación
entregable
• Validar el
entregable

Entregar en el
• Priorizar las
entregable
actividades
201
TIPO DE OBJETIVO DE
• Elaborar el
entregable
• Validar el
entregable
• Manejar un Diego Tapia

Entregar en el control y Julio Cardenas
12 Mitigar tiempo habilitado el seguimiento a las
entregable actividades según
Plan de Trabajo
• Frecuencia y Tiempo
Frecuencia y Tiempo de la Gestión de Riesgos

ID FRECUENCIA TIEMPO
1 Diaria, durante el Desarrollo del entregable Semana 1 - 3 (2020-01)
2 Diaria, durante el Desarrollo del cambio Alguna de las semanas de

(2020-01) o (2020-02)
3 Semanalmente, durante el Desarrollo del proyecto Todas las semanas de

(2020-01) y (2020-02)
4 Semanalmente, durante el Desarrollo de la Todas las semanas de

actividad asignada (2020-01) y (2020-02)
5 Diaria, durante el Desarrollo del entregable Semana 3-8 (2020-01)
9 Diaria, durante el Desarrollo del entregable Semana 1-7(2020-02)
202
ID FRECUENCIA TIEMPO
12 Diaria, durante el Desarrollo del entregable Semana 15 (2020-02)
• Tolerancia de Riesgo de los Interesados

Para el desarrollo del proyecto se define el grado de riesgo que podrán aceptar los
stakeholder, los cuales se definieron de la siguiente manera:
• Product Owner
o El PO del proyecto está dispuesto aceptar un riesgo de calidad menor al
10%.
o El PO del proyecto está dispuesto aceptar un riesgo de cronograma
menor al 5%.
o El PO del proyecto está dispuesto aceptar un riesgo de alcance menor al
10%.
• Portfolio Manager
o El Manager del proyecto está dispuesto aceptar un riesgo de alcance
menor al 10%.
o El Manager del proyecto está dispuesto aceptar un riesgo de cronograma
menor al 5%.
• Comité de Proyecto
o El Comité del proyecto no está dispuesto aceptar un riesgo de
cronograma.
• Seguimiento de Riesgos y Auditoria

Durante el transcurso del proyecto se realizar el seguimiento respectivo de los riesgos
de acuerdo con la probabilidad e impacto. Por ello, se identificarán los riesgos que
puedan ocurrir durante el desarrollo del proyecto con la finalidad de reducir la
probabilidad e impacto dentro del proyecto.
203
• Definiciones de Probabilidad
Probabilidades de los Riesgos del Proyecto
Muy Alto Entre 80% – 100% en que ocurra el evento

Alto Entre 60% – 80% en que ocurra el evento
Medio Entre 40% - 60% en que ocurra el evento
Bajo Entre 20% - 40% en que ocurra el evento

Muy Bajo Entre 1% - 20% en que ocurra el evento
• Definiciones de Impacto por Objetivo
Impacto por Objetivo del Proyecto

Alcance Calidad Tiempo Costo
Muy Alto El entregable El entregable Aumento del Aumento del
(90%) terminado del terminado del tiempo será costo será mayor
proyecto es proyecto es mayor al 20% al 40%
prácticamente prácticamente
inservible inservible.
Alto (70%) Reducción del Reducción de la Aumento del Aumento del
alcance calidad costo será entre un costo será entre un
inaceptable para inaceptable para 10% -20% 20% -40%
el PO. el PO.
Medio (50%) Áreas de alcance La reducción de la Aumento del Aumento del
primarias calidad requiere costo será entre un costo será entre un
afectadas aprobación del 5% -10% 10% -20%
PO.
Bajo (30%) Áreas de alcance Solo los Aumento del Aumento del
secundarias entregables muy tiempo será costo será menor
afectadas exigentes se verán mayor al 5% al 10%
afectados.
204
Muy Bajo Disminución del Degradación de la Aumento Aumento de costo
(10%) alcance apenas calidad apenas insignificante del de manera
apreciables perceptible tiempo insignificante
• Matriz de Probabilidad e Impacto
Matriz de Impacto del Proyecto
Probabilidad Amenazas
Muy Alto 0.05 0.09 0.18 0.36 0.72
(0.90)
Alto (0.70) 0.04 0.07 0.14 0.28 0.56
Medio (0.50) 0.03 0.05 0.10 0.20 0.40
Bajo (0.30) 0.02 0.03 0.06 0.12 0.24
Muy Bajo 0.01 0.01 0.02 0.04 0.08
(0.10)
Muy Bajo Bajo (0.10) Medio (0.20) Alto (0.40) Muy Alto
(0.05) (0.80)
Matriz de Oportunidades del Proyecto
Probabilidad Oportunidades
Muy Alto 0.72 0.36 0.18 0.09 0.05
(0.90)
Alto (0.70) 0.56 0.28 0.14 0.07 0.04
Medio (0.50) 0.40 0.20 0.10 0.05 0.03
Bajo (0.30) 0.24 0.12 0.06 0.03 0.02
Muy Bajo 0.08 0.04 0.02 0.01 0.01
(0.10)
Muy Bajo Bajo (0.10) Medio (0.20) Alto (0.40) Muy Alto
(0.05) (0.80)
205
1.1 CONCLUSIONES
• En una primera instancia, iniciamos con la fase de análisis del presente trabajo, en
donde quedó comprobada la necesidad de una solución tecnológica para monitorear
las posibles zonas de riesgo de incendios urbanos optimizando el uso de recursos.
Debido a que la mayoría de las soluciones que existen actualmente se enfocan en
alertar los incendios urbanos o forestales en tiempo real.
• Posteriormente, fue necesario elaborar una comparación de los algoritmos
predictivos, mediante la cual pudimos rescatar diversas soluciones tecnológicas que
usan este tipo de componentes para predecir de manera anticipada desastres naturales
tales como inundación, sequias e incendios forestales. Durante la selección del
algoritmo a utilizar, identificamos que el Random Forest Classifier era el más
adecuado. Sin embargo, durante su entramiento en la herramienta de Azure Machine
Learning se lo encontró bajo el nombre de Decision Forest.
• Para llevar a cabo el proceso de validación de nuestras soluciones desarrolladas fue
necesario dividirlo en dos partes. En primer lugar, la fase de validación de la
aplicación web nos permitió concluir que, para una correcta validación, es necesario
conocer a los actores principales del proceso de análisis de posibles zonas de riesgo
y cómo se realiza, con la finalidad de poder garantizar que nuestra aplicación nos
permita optimizar dicho proceso.
• Por otro lado, de la fase de validación de la aplicación móvil se puede concluir que,
para garantizar que se está optimizando el proceso de búsqueda de las zonas de riesgo
de incendio es necesario cronometrar el tiempo de interacción de cada usuario que
participa del proceso.
• Durante la fase de los resultados, se pudo demostrar mediante encuestas y entrevistas
que tanto la aplicación móvil como web han tenido una gran aceptación por parte de
los miembros de INDECI como de los estudiantes encuestados. Con respecto a la
aplicación web, se obtuvo 67% de los entrevistados sintieron que la solución cumplía
con las necesidades primordiales para la identificación de zonas con un alto riesgo
de incendio de una manera predictiva. Asimismo, el 55% de los ciudadanos
indicaron la facilidad con la que se puede buscar y tener un detalle de las
zonas riesgosas mediante el aplicativo móvil.
206
• De igual manera, la identificación de nuevas zonas de riesgo de incendio mediante
el uso de la aplicación web propuesta, optimizó en un 75% el tiempo de análisis que
conlleva el proceso actual. Además, la búsqueda precisa de dichas zonas de riesgo
mediante el uso de la aplicación móvil optimizó en un 90.6% el tiempo
promedio de búsqueda de esta información utilizando otras fuentes.
• Finalmente, por todo lo expuesto anteriormente se concluye que la aplicación web y
móvil para la detección de zonas de riesgo de incendio urbanos son válidas y se
evidencia el apoyo en la toma de decisiones tanto de los ciudadanos como de las
entidades responsables de los incendios urbanos. Debido que nos permiten tener un
mejor conocimiento de las zonas de riesgo y de los recursos disponibles para atender
el desastre.
7 RECOMENDACIONES
• En primer lugar, consideramos que el modelo predictivo implementado en este
proyecto podría ser mejorado en una segunda fase del proyecto incorporando
información sobre la estructura de viviendas, cantidad de personas por lote y recursos
disponibles en las zonas.
• De igual forma, evaluamos que para una segunda etapa del proyecto se debe
considerar la implementación de tecnología IoT, como sensores térmicos o cámaras
meteorológicas. Esto se debe a que estos dispositivos otorgan información ambiental
relevante, lo cual permitiría la identificación de zonas de riesgo alimentado al modelo
predictivo propuesto. Debido a la pandemia del COVID 19, las restricciones
establecidas por el gobierno y el presupuesto disponible para el proyecto, no se pudo
acceder a este equipo tecnológico.
• Finalmente, consideramos que nuestra solución debe integrarse con una base de datos
INDECI o el CGBVP permitiendo consolidar la información de los registros de
incendios que permiten realizar el análisis correctamente. Algunas de las alternativas
que consideramos es trabajar con una base de datos de respaldo o mediante un web
service.
207
8 GLOSARIO
• Riesgo: Es la probabilidad de que una amenaza se convierta en un desastre.
• Dirección IP: Es un número que identifica de forma única a una interfaz en red de
cualquier dispositivo conectado a ella que utilice el protocolo IP (Internet Protocol).
• API: Es un conjunto de definiciones y protocolos que se utiliza para desarrollar e
integrar el software de las aplicaciones.
• Incendio: Es una ocurrencia de fuego no controlada que puede afectar o abrasar algo
que no está destinado a quemarse.
• Longitud: Es una de las magnitudes físicas fundamentales que no puede ser definida
en términos de otras magnitudes que se pueden medir.
• Latitud: Es la medida del ángulo formado por el plano ecuatorial con la línea que
une a este punto al centro de la tierra. Por regla general está comprendido entre -90
° y 90 °.
• GPS: Sistema de Posicionamiento Global que puede determinar la ubicación de un
objeto, como un vehículo o persona.
• Android: Es un sistema operativo que se usa en dispositivos móviles, además permite
la ejecución de aplicaciones desarrolladas exclusivamente para este sistema.
• Cloud: Se define como un paradigma que permite ofrecer servicios de computación
o tecnología a través de una red, que usualmente es internet.
• Análisis Predictivo: Extracción de un modelo analítico utilizando datos históricos
que predice el comportamiento futuro o estima resultados desconocidos.
• ISO: Es la Organización Internacional de Normalización o Estandarización,
encargada de la creación de normas o estándares para asegurar la calidad, seguridad
y eficiencia de productos y servicios.
• Benchmarking: Es un proceso continuo que toma como referencia los productos,
servicios o procesos de trabajo de las empresas líderes, para compararlos con los de
tu propia empresa y posteriormente realizar mejoras e implementarlas.
• IoT o Internet de las cosas: Es la interconexión de dispositivos y objetos a través de
una red, en dónde todos ellos podrían ser visibles e interaccionar.
208
• Backend: Es la capa de acceso a datos de un software o cualquier dispositivo, que no
es directamente accesible por los usuarios, además contiene la lógica de la aplicación
que maneja dichos datos.
• Front end: Es la parte del programa que conecta e interactúa con los usuarios que la
visitan.
• Web Service: Es una tecnología que utiliza un conjunto de protocolos y estándares
que sirven para intercambiar datos entre aplicaciones.
• Mockup: Es un diseño inicial de una aplicación móvil y web que se utiliza para
mostrar al cliente como quedaría el producto final
• APK: Es un archivo que contiene una aplicación para ser instalada exclusivamente
en un sistema operativo Android.
• Product Backlog: Es un listado de todas las tareas que se pretenden hacer durante el
desarrollo de un proyecto.
• Hidrante: Es un equipo diseñado para proporcionar una gran cantidad de agua en
caso de incendios.
• Geolocalización: Es la capacidad de obtener la ubicación real de un objeto conectado
a internet,
• Encriptación: Es un procedimiento de seguridad que consiste en la alteración de
algún dato mediante algoritmos de cifrado.
• Historia de Usuario: Es la representación de un requerimiento contado desde la
perspectiva del usuario.
• Arquitectura Tecnológica: Es un modelo que provee información sobre las distintas
plataformas de soporte y como interactúan entre ellas.
• Modelo predictivo: Es un sistema que emplea datos y estadísticas para predecir
resultados a partir de modelos de datos.
209
9 BIBLIOGRAFIA
Anbarasan, M., Muthu, B., Sivaparthipan, C. B., Sundarasekar, R., Kadry, S.,
Krishnamoorthy, S., Samuel, R. D. J., & Dasel, A. A. (2020). Detection of flood disaster
system based on IoT, big data and convolutional deep neural network. Computer
Communications, 150, 150–157. https://doi.org/10.1016/j.comcom.2019.11.022
Azabache, J. O., Bautista Mendoza, D., Fernandez, F. A., & Prado Gardini, R. (2018).
Development and implementation of a geolocation system to determine the approximate
time of arrival of a public transport bus to a user in the city of Trujillo-Peru. Proceedings
of the 2018 IEEE 25th International Conference on Electronics, Electrical Engineering
and Computing, INTERCON 2018, 1–4.
https://doi.org/10.1109/INTERCON.2018.8526469
Biswas, N. K., & Hossain, F. (2018). A scalable open-source web-analytic framework to

improve satellite-based operational water management in developing countries. Journal
of Hydroinformatics, 20(1), 88–99. https://doi.org/10.2166/hydro.2017.073
Cantos, W.P., Juran, I., & Tinelli, S. (2020). Machine-Learning-Based Risk Assessment
Method for Leak Detection and Geolocation in a Water Distribution System. Journal of
Infrastructure Systems, 26(1). https://doi.org/10.1061/(ASCE)IS.1943-555X.0000517
Cantos, Wilmer P., Juran, I., & Tinelli, S. (2020). Machine-Learning-Based Risk
Assessment Method for Leak Detection and Geolocation in a Water Distribution
System. Journal of Infrastructure Systems, 26(1), 1–10.
https://doi.org/10.1061/(ASCE)IS.1943-555X.0000517
Choubin, B., Mosavi, A., Alamdarloo, E. H., Hosseini, F. S., Shamshirband, S., Dashtekian,
K., & Ghamisi, P. (2019). Earth fissure hazard prediction using machine learning
models. Environmental Research, 179. https://doi.org/10.1016/j.envres.2019.108770
Chu, L., Wang, L.-J., Jiang, J., Liu, X., Sawada, K., & Zhang, J. (2019). Comparison of
landslide susceptibility maps using random forest and multivariate adaptive regression
spline models in combination with catchment map units. Geosciences Journal, 23(2),
210
341–355. https://doi.org/10.1007/s12303-018-0038-8
de Oliveira, G. G., Ruiz, L. F. C., Guasselli, L. A., & Haetinger, C. (2019). Random forest
and artificial neural networks in landslide susceptibility modeling: a case study of the
Fão River Basin, Southern Brazil. Natural Hazards, 99(2), 1049–1073.
https://doi.org/10.1007/s11069-019-03795-x
Dian, S., Cheng, P., Ye, Q., Wu, J., Luo, R., Wang, C., Hui, D., Zhou, N., Zou, D., Yu, Q.,
Yu, Q., & Gong, X. (2019). Integrating Wildfires Propagation Prediction Into Early
Warning of Electrical Transmission Line Outages. IEEE Access, 7, 27586–27603.
https://doi.org/10.1109/ACCESS.2019.2894141
Ecker, H., Lindacher, F., Dressen, J., Wingen, S., Hamacher, S., Böttiger, B. W., & Wetsch,
W. A. (2020). Accuracy of automatic geolocalization of smartphone location during
emergency calls — A pilot study. Resuscitation, 146, 5–12.
https://doi.org/10.1016/j.resuscitation.2019.10.030
Ecker, Hannes, Lindacher, F., Dressen, J., Wingen, S., Hamacher, S., Böttiger, B. W., &
Wetsch, W. A. (2020). Accuracy of automatic geolocalization of smartphone location
during emergency calls — A pilot study. Resuscitation, 146, 5–12.
https://doi.org/10.1016/j.resuscitation.2019.10.030
Espino, C. (2017). Análisis predictivo: técnicas y modelos utilizados y aplicaciones del

mismo - herramientas Open Source que permiten su uso. 26/27, I(Principio activo
y prestación ortoprotésica), 67.
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/59565/6/caresptimTFG0117m
emòria.pdf
Hsu, W.-L., Jhuang, J.-Y., Huang, C.-S., Liang, C.-K., & Shiau, Y.-C. (2019). Application
of Internet of Things in a kitchen fire prevention system. Applied Sciences
(Switzerland), 9(17). https://doi.org/10.3390/app9173520
Hsu, W. L., Jhuang, J. Y., Huang, C. S., Liang, C. K., & Shiau, Y. C. (2019). Application of
Internet of Things in a kitchen fire prevention system. Applied Sciences (Switzerland),
9(17). https://doi.org/10.3390/app9173520
Joshi, N., & Shah, S. (2019). A Comprehensive Survey of Services Provided by Prevalent
Cloud Computing Environments (Vol. 104). Springer Singapore.
211
https://doi.org/10.1007/978-981-13-1921-1
Jung, D., Tuan, V. T., Tran, D. Q., Park, M., & Park, S. (2020). Conceptual framework of
an intelligent decision support system for smart city disaster management. Applied
Sciences (Switzerland), 10(2). https://doi.org/10.3390/app10020666
Jung, Daekyo, Tuan, V. T., Tran, D. Q., Park, M., & Park, S. (2020). Conceptual framework
of an intelligent decision support system for smart city disaster management. Applied
Sciences (Switzerland), 10(2). https://doi.org/10.3390/app10020666
Kaur, A., & Sood, S. K. (2020). Cloud-Fog based framework for drought prediction and
forecasting using artificial neural network and genetic algorithm. Journal of
Experimental and Theoretical Artificial Intelligence, 32(2), 273–289.
https://doi.org/10.1080/0952813X.2019.1647563
Kaur, M., Sood, R., & Kaur, J. (2019). Comparative study to understand and analyze cloud
computing. International Journal of Advanced Science and Technology, 28(19), 827–
833.
Kumar, R., Mukherjee, A., & Singh, V. P. (2017). Traffic noise mapping of Indian roads
through smartphone user community participation. Environmental Monitoring and
Assessment, 189(1). https://doi.org/10.1007/s10661-016-5741-1
Kumar, V., Jana, A., & Ramamritham, K. (2020). A decision framework to access urban fire
vulnerability in cities of developing nations: empirical evidence from Mumbai.
Geocarto International. https://doi.org/10.1080/10106049.2020.1723718
Lin, H., Liu, X., Wang, X., & Liu, Y. (2018). A fuzzy inference and big data analysis
algorithm for the prediction of forest fire based on rechargeable wireless sensor
networks. Sustainable Computing: Informatics and Systems, 18, 101–111.
https://doi.org/10.1016/j.suscom.2017.05.004
Nalla, K. R., & El-Ocla, H. (2017). Mobile DNUN: Danger Notification and User
Navigation. IT Professional, 19(1), 21–26. https://doi.org/10.1109/MITP.2017.12
Puttinaovarat, S., & Horkaew, P. (2020). Flood Forecasting System Based on Integrated Big
and Crowdsource Data by Using Machine Learning Techniques. IEEE Access, 8, 5885–
212
5905. https://doi.org/10.1109/ACCESS.2019.2963819
Rodríguez, E. (2009). La Geolocalización, Coordenadas hacia el Éxito El potencial de la

aplicación de una herramienta social de geolocalización en la comunicación
institucional y corporativa. May, 1–12.
Saeed, F., Paul, A., Hong, W. H., & Seo, H. (2019). Machine learning based approach for
multimedia surveillance during fire emergencies. Multimedia Tools and Applications.
https://doi.org/10.1007/s11042-019-7548-x
Saeed, F., Paul, A., Rehman, A., Hong, W. H., & Seo, H. (2018). IoT-Based intelligent
modeling of smart home environment for fire prevention and safety. Journal of Sensor
and Actuator Networks, 7(1). https://doi.org/10.3390/jsan7010011
Saeed, Faisal, Paul, A., Rehman, A., Hong, W. H., & Seo, H. (2018). IoT-Based intelligent
modeling of smart home environment for fire prevention and safety. Journal of Sensor
and Actuator Networks, 7(1). https://doi.org/10.3390/jsan7010011
Sareen, S., Sood, S. K., & Gupta, S. K. (2017). Secure internet of things-based cloud
framework to control zika virus outbreak. International Journal of Technology
Assessment in Health Care, 33(1), 11–18. https://doi.org/10.1017/S0266462317000113
Sareen, Sanjay, Sood, S. K., & Gupta, S. K. (2017). Secure internet of things-based cloud
framework to control zika virus outbreak. International Journal of Technology
Assessment in Health Care, 33(1), 11–18. https://doi.org/10.1017/S0266462317000113
Sayad, Y. O., Mousannif, H., & Al Moatassime, H. (2019). Predictive modeling of wildfires:
A new dataset and machine learning approach. Fire Safety Journal, 104, 130–146.
https://doi.org/10.1016/j.firesaf.2019.01.006
Shah, S. A., Seker, D. Z., Rathore, M. M., Hameed, S., Ben Yahia, S., & Draheim, D. (2019).
Towards Disaster Resilient Smart Cities: Can Internet of Things and Big Data Analytics
Be the Game Changers? IEEE Access, 7, 91885–91903.
Sood, S. K., Sandhu, R., Singla, K., & Chang, V. (2018). IoT, big data and HPC based smart
flood management framework. Sustainable Computing: Informatics and Systems, 20,
102–117. https://doi.org/10.1016/j.suscom.2017.12.001
213
Toledo-Castro, J., Caballero-Gil, P., Rodríguez-Pérez, N., Santos-González, I., Hernández-
Goya, C., Aguasca-Colomo, R., & Schumann, A. (2018). Forest Fire Prevention,
Detection, and Fighting Based on Fuzzy Logic and Wireless Sensor Networks.
Complexity, 2018. https://doi.org/10.1155/2018/1639715
Toledo-Castro, Josué, Caballero-Gil, P., Rodríguez-Pérez, N., Santos-González, I.,

Hernández-Goya, C., Aguasca-Colomo, R., & Schumann, A. (2018). Forest Fire
Prevention, Detection, and Fighting Based on Fuzzy Logic and Wireless Sensor
Networks. Complexity, 2018. https://doi.org/10.1155/2018/1639715
Ye, T., Liu, W., Mu, Q., Zong, S., Li, Y., & Shi, P. (2020). Quantifying livestock
vulnerability to snow disasters in the Tibetan Plateau: Comparing different modeling
techniques for prediction. International Journal of Disaster Risk Reduction, 48.
https://doi.org/10.1016/j.ijdrr.2020.101578
Yu, B., Chen, F., Li, B., Wang, L., & Wu, M. (2017). Fire risk prediction using remote
sensed products: A case of Cambodia. Photogrammetric Engineering and Remote
Sensing, 83(1), 19–25. https://doi.org/10.14358/PERS.83.1.19
Zamorano Ruiz, J. (2018). COMPARATIVA Y ANÁLISIS DE ALGORITMOS DE

APRENDIZAJE AUTOMÁTICO PARA LA PREDICCIÓN DEL TIPO
PREDOMINANTE DE CUBIERTA ARBÓREA.
Zhao, F., Xu, R., Li, R., Zhu, M., & Luo, X. (2019). Street-Level Geolocation Based on
Router Multilevel Partitioning. IEEE Access, 7, 59237–59248.
Publimetro (2020). Firecity, startup que permite alertar a tiempo los incendios. Recuperado
de: https://publimetro.pe/actualidad/tecnologia/firecity-startup-que-permite-alertar-a-
tiempo-los-incendios-noticia/?ref=pur
Sanz, J. (2017). ESTA APLICACIÓN ALERTA DE INCENDIOS FORESTALES CERCA

DE TU UBICACIÓN. Recuperado
de: https://cincodias.elpais.com/cincodias/2017/07/03/lifestyle/1499079319_465991.ht
ml
Cuerpo General de Bomberos Voluntarios (2019). Recuperado

de: http://www.bomberosperu.gob.pe/portal/net_estadistica.aspx
214
Instituto Nacional de Defensa Civil (INDECI) (2020). BOLETIN ESTADÍSTICO
VIRTUAL DE LA GESTIÓN REACTIVA. Recuperado
de: https://www.indeci.gob.pe/
Intendencia Nacional de Bomberos del Perú (2019). Reporte de Investigación y Gestión de

la Información - Emergencias atendidas por el CGBVP 2008-2018. Recuperado
de: http://www.inbp.gob.pe/files/rigi/RIGI_09_Incendios_Industriales_CGBVP_Lima
_Metropolitana_2008_2018_final.pdf
El Comercio (2020). Bomberos: Cuales son las causas más comunes que pueden provocar
un incendio. Recuperado de: https://elcomercio.pe/lima/sucesos/bomberos-cuales-son-
las-causas-mas-comunes-de-incendios-velas-noticia/?ref=ecr
Intendencia Nacional de Bomberos del Perú (2019). Bomberos atendieron 8595 emergencias
a nivel nacional en abril del 2019. Recuperado de: https://www.inbp.gob.pe/bomberos-
atendieron-8595-emergencias-a-nivel-nacional-en-abril-del-2019/
Intendencia Nacional de Bomberos del Perú (2019). Reporte de Investigación y Gestión de

la Información – Análisis de tiempo de respuesta de las emergencias atendidas por el
CGBVP en Lima Metropolitana. Recuperado
de: http://www.inbp.gob.pe/files/rigi/RIGI_11_Tiempo%20de%20respuesta_CGBVP_
Lima_Metropolitana_2014_2018_final_V2.pdf
Evaluando Software (2017). Qué es la Geolocalización y cómo funciona. Recuperado

de: https://www.evaluandosoftware.com/la-geolocalizacion-funciona/  
  
Google Maps Platform | Google Cloud Blog. (2020). Retrieved 8 June 2020,
from https://cloud.google.com/blog/products/maps-platform?hl=es
¿Qué es GPS? | Carvalza. (2020). Retrieved 8 June 2020, from https://www.carvalza.es/que-

es-un-gps
215
API de Geolocation | Google Maps Platform | Google Cloud. (2020). Retrieved 8 June 2020,
from https://cloud.google.com/maps-platform/?hl=es-419.
Qué es Azure: Servicios en la nube de Microsoft | Microsoft Azure. (2020). Retrieved 8

June 2020, from https://azure.microsoft.com/es-es/overview/what-is-azure/#most-
popular-questions.
¿Qué es AWS?. Amazon Web Services, Inc. (2020). Retrieved 8 June 2020, from
https://aws.amazon.com/es/what-is-aws/.
AWS | Informática en la nube. Ventajas y Beneficios. Amazon Web Services, Inc. (2020).
Retrieved 8 June 2020, from https://aws.amazon.com/es/what-is-cloud-computing/.
ISO/IEC 25010:2011. ISO. (2020). Retrieved 8 June 2020,

from https://www.iso.org/standard/35733.html.
ISO/IEC/IEEE 29119-1:2013. ISO. (2020). Retrieved 23 June 2020, from

https://www.iso.org/standard/45142.html.
ISO 9001 - Software ISO 9001 de Sistemas de Gestión ISO. Software ISO. (2020). Retrieved
23 June 2020, from https://www.isotools.org/normas/calidad/iso-
9001/#:~:text=La%20ISO%209001%20es%20una,su%20tama%C3%B1o%20o%20ac
tividad%20empresarial.
Servicios de computación en la nube | Google Cloud. (2020). Retrieved 8 June 2020,

from https://cloud.google.com/?hl=es-419.
What Is Cloud Computing? A Beginner’s Guide | Microsoft Azure. Azure.microsoft.com.

(2020). Retrieved 25 June 2020, from https://azure.microsoft.com/en-
us/overview/what-is-cloud-computing/.
Asociación Peruana de Empresas de Seguros (2020). INFORME TRIMESTRAL DEL

SISTEMA ASEGURADOR – PRIMER TRIMESTRE 2020.
216
https://www.apeseg.org.pe/wp-
content/uploads/2020/06/Resultados_Sistema_Asegurador_1T20.pdf

SISTEMA ASEGURADOR – SEGUNDO TRIMESTRE 2020.

SISTEMA ASEGURADOR – TERCER TRIMESTRE 2020.
Microsoft Azure (2020). App Service pricing. https://azure.microsoft.com/en-

us/pricing/details/app-service/windows/
Microsoft Azure (2020). Azure Cosmos DB pricing. https://azure.microsoft.com/es-

es/pricing/details/cosmos-db/
Microsoft Azure (2020). Azure Database for MySQL pricing.

https://azure.microsoft.com/en-us/pricing/details/mysql/server/
AGENCIA PERUANA DE NOTICIAS. (20 de diciembre de 2016). El 34% de hidrantes

contra incendios en Lima tienen problemas de accesibilidad.
https://andina.pe/agencia/noticia-el-34-hidrantes-contra-incendios-lima-tienen-
problemas-accesibilidad-645811.aspx
INEI. (2016). Encuesta Nacional de Programas Estratégicos (2011-2015).

https://www.inei.gob.pe/media/MenuRecursivo/publicaciones_digitales/Est/Lib1366/li
bro.pdf
CENEPRED. (2020). ESCENARIO DE RIESGO POR INCENDIO URBANO DEL

CERCADO DE LIMA. https://cenepred.gob.pe/web/wp-
content/uploads/2020/12/Escenario-de-Riesgo-por-Incendio-Urbano-del-Cercado-de-
Lima-CENEPRED-MML.pdf
217
10 ANEXO A -WASC
Ensayo del alineamiento con la competencia de “Comunicación Escrita”
El presente ensayo, tiene como finalidad evidenciar el cumplimiento de la competencia

Comunicación Escrita en el desarrollo del proyecto “Sistema de Geolocalización de Riesgo
de Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha competencia
consiste en la capacidad de construir mensajes con información clara, relevante, bien
argumentada a los diversos usuarios. 
Audiencia, contexto y tarea asignada   

Durante todo el desarrollo del proyecto, ha sido necesaria la comunicación constante con
los stakeholders. Esto principalmente mediante el uso del correo electrónico académico con
el fin de promover la formalidad que debe llevarse a cabo. Sin embargo, por algunos motivos
personales era más la comunicación mediante otros medios, ya que los correos que se envían
o recibían se solían perder entre los muchos que el receptor recibía. A pesar de ello, la
formalidad con cada miembro nunca se perdió, la comunicación que se tenía siempre se
representaba respetuosamente al receptor del mensaje y de igual manera al recibir una
respuesta de su parte.  
 
Asimismo, los mensajes que se emitían por parte del equipo siempre eran concisos y lo más
breves posibles. De esta manera, evitamos generar incomodidad a quien recibía el mensaje
y que también sea fácil de entender. Esto trajo como resultado, una comunicación
gratificante por ambas partes y permitieron cumplir el objetivo de la consulta. 
 
Organización y estructura 
 
Como parte del proyecto, fue necesario la documentación de varios planes de gestión, así
como la de artefactos basándose en las metodologías SCRUM y PMI. Estos fueron
cumplidos respetando la estructura y plantillas que se nos proporcionó en un inicio del
proyecto. Así como la información que debería aportar cada uno de estos documentos.  
 
218
Por otro, la existencia de puntos similares en los documentos generó que la
información debía tener concordancia entre sí. De no ser así, surgiría discrepancias o
generaría dudas ante la audiencia y no se podría realizar una adecuada sustentación. 
 
Desarrollo del contenido 
 
Para la elaboración de cada documento fue necesario la investigación de artículos
académicos que permitieran ampliar tanto el contenido de los artefactos como el
conocimiento de los miembros del equipo. De ellos, se pudo rescatar propuestas, soluciones
en donde se discuta acerca de la problemática, situación actual, etc. Esto de acuerdo a la
información que se consideró necesaria rescatar para cada documento por elaborar. De esta
manera, se cumplieron con los objetivos propuestos para cada entregable que se debía
elaborar. 
    
Vocabulario y gramática 
 
El aprendizaje y comprendimiento de nuevos términos fueron debido a la constante lectura
de artículos de investigación. Los cuales atendían a nuestra propuesta y permitieron al equipo
utilizarlos para distintas funciones. Algunas de ellas, fueron utilizadas dentro del Marco
Teórico de la Memoria, al igual que en el glosario del Project Charter desarrollado.
Asimismo, permitieron aplicar dichos términos en lo que respecta a las actas que fueron
generadas durante el proyecto. La comunicación constante con los stakeholders también
exigía que obtengamos mayores conocimientos con respecto a gramática, lo que permitiría
la correcta estructuración de párrafos de texto y llevar una idea bien concisa al receptor. 
 
Ortografía y puntuación 
 
Durante los avances documentados, identificamos muy pocos errores ortográficos en
momentos que se mantenía la comunicación con algún stakeholder. Sin embargo, para evitar
que esto sucediera realizábamos una verificación previa de los documentos o mensajes que
serían compartidos. Un ejemplo de esto, sería la consulta que hacíamos a
nuestro Product Owner, quien daba su conformidad de que el mensaje o documento estuviese
219
bien elaborado.  De igual manera, nuestro Portfolio Manager revisó junto a nosotros los
artefactos que se desarrollaron, con el fin de pasar por distintos filtros de aprobación.
Ensayo del alineamiento con la competencia de “Comunicación Oral”

general Comunicación Oral en el desarrollo del proyecto “Sistema de Geolocalización de
Riesgo de Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha
competencia consiste en la capacidad para transmitir de manera eficaz un mensaje oral a
diversas audiencias, usando distintas herramientas que ayuden en su comprensión.
Organización del Mensaje 

 
En las sustentaciones que el equipo fue partícipe, siempre se realizó una breve descripción
del objetivo del proyecto, el cual consiste en la implementación de un sistema que permita
la identificación de zonas con riesgo de incendios, ya que afecta al ámbito de la seguridad
ciudadana. Esto de acuerdo a las estadísticas existentes que nos permitieron sustentar
y demostrar los impactos que este tipo de desastre puede llegar a generar.  
 
Desarrollo de la idea central 
 
Basándonos en lo anterior, siempre buscamos detallar un poco más la idea principal de las
presentaciones orales. Para ello, lo complementamos con información que el
equipo investigó y consideró relevante para que la audiencia comprenda mejor lo que se
quiere expresar. Asimismo, estas ideas complementarias permitirían reforzar la idea y llegar
a conclusiones claras y concisa. 
 
Aspectos no verbales 
 
Como parte de las sustentaciones frente a las audiencias, los miembros necesitaron una
presentación formal, así como una serenidad al momento de exponer. Esto
último garantizaba la adecuada entonación y fluidez en la pronunciación de las expresiones
utilizadas. Asimismo, debido a coyuntura fue necesario el uso de equipo portátiles que
220
permitieron sustentar con una webcam y que la audiencia analice tanto la postura como los
gestos del equipo. De esta manera, atraíamos la atención del público oyente y entendían de
una mejor manera el mensaje que se quería llevar. 
 
Aspectos verbales 
 
Durante todas las fases del proyecto, fue necesaria una comunicación constante con
los stakeholders, es por ello que siempre se buscó llevar la idea principal del tema a tratar de
la manera más comprensible posible. De igual manera, nosotros aprendimos nuevos
términos que permitieron expandir nuestras ideas y poder expresarnos de forma más técnica.
Dichas expresiones permitieron el adecuado desarrollo de nuestras exposiciones tanto frente
al Portfolio Manager, Product Owner y el Comité de Proyectos. Asimismo, logramos poder
transmitir a la audiencia el significado de estos términos aprendidos a lo largo de nuestra
investigación o reuniones con expertos del tema de los incendios. 
 
Recursos materiales de soporte 
 
Debido a la coyuntura que hemos vivido sobre el COVID-19 se nos ha hecho imposible
contar con reuniones presenciales entre los miembros del equipo, el Portfolio Manager o
el Product Owner. Sin embargo, esto no fue un impedimento para llevar a cabo el proyecto.
Gracias a los recursos de la institución que nos apoya, hemos contado con herramientas como
lo es el Blackboard Collaborate que nos ha permitido realizar las reuniones correspondientes
con los ya mencionados anteriormente. Por otro lado, los miembros del equipo utilizaron la
herramienta Microsoft Teams para poder realizar los avances de forma más ordenada fuera
de los horarios de asesoría.  
 
De igual manera, dentro de algunas herramientas complementarias tenemos la
plataforma Sharepoint, en donde almacenamos todos nuestros avances y permitieron la
rápida presentación de los documentos ante nuestra audiencia. 
En conclusión, debemos tener en cuenta que una de claves para el desarrollo del proyecto la
transmisión de ideas y la definición de acuerdos sean expresados de forma correcta y
efectiva, a esto se le denomina comunicación efectiva. La comunicación efectiva es una de
221
las claves para asegurar que la persona dispone, en el momento apropiado, de la información
requerida, utilizando los medios de comunicación adecuados.
Ensayo del alineamiento con la competencia de “Manejo de Información”
El presente ensayo, tiene como finalidad evidenciar el cumplimiento de la competencia

de manejo de la información durante el desarrollo del proyecto “Sistema de Geolocalización
de Riesgo de Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha
competencia consiste en la capacidad de determinar la información necesaria, así como de
buscarla, evaluarla y usarla de manera ética, con la finalidad de proponer una solución. 
Identifica la necesidad de realizar una investigación 
Como parte inicial del proyecto asignado, tuvimos que identificar una problemática que con
una ardua investigación se logró definir como el ineficiente proceso de análisis e
identificación de riesgo de incendio en Lima Metropolitana, debido a la falta de información
sobre las zonas y la disponibilidad de recursos. Es por ello que definimos como objetivo del
proyecto, con la ayuda de la asesoría, la implementación de un sistema de geolocalización
de riesgo de incendios, el cual permita apoyar a las organizaciones respectivas a optimizar
dicho proceso y tomar las precauciones debidas ante este tipo de eventos. Además,
consideramos esta problemática como un punto muy importante dentro de la sociedad, ya
que es un tipo de desastre que de no ser controlado a tiempo o adecuadamente, perjudicaría
a un gran número de personas. En conjunto con todas las estadísticas encontradas, nos
permitió justificar el motivo de nuestro problema y objetivo definido. De igual manera, el
llegar a identificar alternativas que han sido propuestas anteriormente, nos indica el interés
que este tema puede llegar a alcanzar en el entorno de las investigaciones universitarias.  
Selecciona y evalúa las fuentes de información pertinentes para enfrentar una falta de
información 
Como se mencionó anteriormente, la investigación realizada fue fundamental para la

definición de varias fases dentro del proyecto. Las fuentes utilizadas fueron seleccionadas
de tal manera que se cumplan con ciertos criterios de aceptación para ser tomados en
consideración. En primer lugar, el año de publicación, el cuartil al que pertenece y si se
encontraba indexado o no, esto cumple con la finalidad de poder contar con la información
222
más actualizada y verídica, incluyendo las nuevas tecnologías emergentes, así como las
técnicas de cómo deberían ser aplicadas. 
Por otro lado, las herramientas que el equipo consideran necesarios para su propuesta fueron
tomadas en cuenta durante la búsqueda. Asimismo, se analizaron otras alternativas en
donde no necesariamente se utilizaron las que este proyecto propone. 
Usa la información para resolver un problema, alcanzar o defender una tesis 
Una vez finalizada la búsqueda de información, se identificaron un total de 30 artículos de

los cuales se realizó un análisis de cada uno. De esta manera, identificamos si dicho artículo
nos serviría de ayuda o no. Además, estos permitieron la elaboración del estado del arte y
el paper del proyecto, los cuales fueron aprobados por el coautor asignado. Por otro lado,
para el desarrollo de la solución del proyecto se mantuvo comunicación con miembros de
INDECI, quienes nos proporcionaron información acerca de recursos para la atención de
desastres y los registros históricos utilizados para el entrenamiento predictivo que
permitieron el desarrollo de las funcionalidades principales de las aplicaciones
desarrolladas.
Evalúa la información 
De acuerdo con los artículos investigados y analizados, se pudo rescatar el uso de

herramientas como el api de Google maps y algoritmos predictivos, que permitan la
identificación de zonas de riesgo vulnerables ante incendios. Toda esta información fue
recopilada como parte de nuestro Objetivo 1 y documentada de forma detallada, de tal
manera que facilitará la sustentación parcial frente al comité y aprobado por nuestro PO. Por
otro lado, como se mencionó anteriormente, para el desarrollo del paper se tuvo que evaluar
toda la información recopilada hasta la fecha con el fin de realizar una adecuada sustentación
de la propuesta.  
Usa la información de manera ética 
Como todo proyecto de tesis, el uso de trabajos de investigaciones pasadas es importante.

Sin embargo, el respeto de los trabajos realizados siempre debe estar presente y trabajar con
223
dicha información de forma ética. Es por ello que los documentos correspondientes a los
análisis de artículos y el artefacto de la memoria fueron enviados a la
herramienta Turnitin para validar el porcentaje de copia que pudiera existir en dichos
documentos. Como resultado, tuvimos que realizar las correcciones de acuerdo con los
reportes obtenidos por la herramienta. Una vez finalizada las correcciones, se consolidó en
un solo documento en donde se colocaron todas las referencias y citas bibliográficas
utilizadas, que correspondían a los artículos ya analizados. Todo esto fue aplicando el
formato APA 6, solicitada por nuestra institución académica. 
Ensayo del alineamiento con la competencia de “Ciudadanía”
El presente ensayo, tiene como finalidad evidenciar el cumplimiento de la competencia de

ciudadanía durante el desarrollo del proyecto “Sistema de Geolocalización de Riesgo de
Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha competencia consiste
en la capacidad de valorar la convivencia humana en sociedades plurales, reflexionando acerca
de las dimensiones morales de las propias acciones y decisiones, asumiendo la responsabilidad
por las consecuencias en el marco del respeto de los derechos y deberes ciudadanos.
 
Introducción 
En la actualidad, la seguridad es uno de los aspectos más importantes de la ciudadanía. Esta se
puede ver afectada por una mala gestión o poco compromiso por parte de las autoridades para
actuar de forma rápida y eficiente. Los incendios urbanos son considerados como un desastre
que afecta la tranquilad de la población, ya que suelen causar pérdidas no tan solo económicas,
sino también personales como familiares, amistades, etc. Es por ello que durante el desarrollo
de este proyecto se han evaluados dichos aspectos y se buscó la forma de salvaguardar y
mantener la tranquilidad de los ciudadanos.
Razonamiento Moral 
Se entiende como razonamiento moral al proceso mental que permite a una persona juzgar el
valor de las cosas, para así determinar lo correcto y lo incorrecto. Bajo este concepto, el
proyecto tiene una perspectiva moral. Durante el desarrollo de este proyecto se pudo identificar
224
que los incendios lograrían ser evitados si se cuenta con acciones preventivas, un adecuado
mantenimiento de edificaciones o incluso tomar conciencia por parte de los ciudadanos. Por
ello, en los que respecta a nosotros como miembros del proyecto, consideramos que el análisis
predictivo mediante un sistema de geolocalización de este tipo de desastre beneficiaría a la
ciudadanía. Esto principalmente, porque facilitaría a las autoridades encargadas en la
identificación de medidas preventivas y correctivas de zonas de riesgo de incendios.
Respeto y Disposición al Diálogo 

Se define como la capacidad de proponer y evaluar soluciones a problemas de su entorno
personal y social basadas en el respeto, el diálogo y la búsqueda de acuerdos. Bajo este
concepto, se presenta este proyecto como una solución para el incremento de incendios que
ocurrieron en los distritos Lima Metropolitana que no
se lograron prevenir o terminaron afectando a la ciudadanía de forma económica y personal.
Como parte del dialogo se realizaron entrevistas con los miembros de INDECI con el fin de
compartir ideas para el funcionamiento de nuestra solución.   
Pluralismo y Diversidad 
Como se mencionó previamente, el tomar conciencia de las acciones o aspectos de mejora en
la sociedad es un trabajo en conjunto. Tanto las instituciones u organizaciones encargadas como
la misma ciudadanía son quienes promoverán la ejecución de un cambio o solución
propuesta ante una problemática. Sin embargo, los ciudadanos tendrán un papel importante, ya
que serán ellos los que cumplan con las medidas estipuladas por las autoridades. De lo contrario,
la propuesta o solución que responde a la problemática en cuestión no llegaría a cumplir su
objetivo principal y quedará olvidado. 
Reconocimiento de derechos y deberes ciudadanos 

Velar por la integridad y la seguridad de la ciudadanía es un aspecto muy importante que ha
sido considerado por parte del equipo. Como se mencionó anteriormente, los incendios pueden
afectar a varias familias a la vez, esto dependiendo de la magnitud del desastre. Asimismo,
buscamos garantizar el cumplimiento de los derechos del ciudadano como lo puede ser el
derecho a la vida o integridad. En conclusión, el proyecto propuesto tiene un impacto
importante en la ciudadanía ya que está dirigido a aquellas entidades públicas que se encuentran
225
encargadas de tomar medidas preventivas y a aquellos ciudadanos que desean contar con
información las zonas de riesgo de incendio.
Ensayo del alineamiento con la competencia de “Pensamiento Crítico”
El presente ensayo, tiene como finalidad evidenciar el cumplimiento de la competencia

Pensamiento Crítico durante el desarrollo del proyecto “Sistema de Geolocalización de
Riesgo de Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha
competencia consiste en la capacidad para analizar de manera exhaustiva problemas o
eventos para formular conclusiones sólidamente justificadas. 
Para llevar a cabo el proyecto fue necesario realizar una investigación a fin de poder definir
una problemática. Como resultado, se identificó que los incendios son uno de los
desastres que traen consigo muchos impactos. Además, se identificó la inexistencia de
herramientas tecnológicas que permitieran a instituciones como INDECI el poder identificar
las zonas de riesgo o vulnerables ante este tipo de desastre. Es por ello que planteamos como
objetivo principal del proyecto consiste en la implementación de un Sistema de
Geolocalización de Riesgo de Incendios que apoye a las organizaciones
respectivas a tomar las precauciones ante este tipo de eventos generados en Lima
Metropolitana.
Evaluación y cuestionamiento de la información 
En la actualidad existen herramientas que facilitan la identificación de los incendios.

Algunos ejemplos de esto es la herramienta FireCity, la cual es una aplicación que conecta
en tiempo real los sistemas de alarmas contra incendios dándole aviso al usuario y poniendo
en alerta a la central de bomberos y serenazgo. Esto es gracias a la creación de un panel de
incendios que se conecta a internet a través del aplicativo, y que envía esta información
gestionada, analizada y validada a través de un monitor web. De igual manera, en el mercado
existe la aplicación denominada AFIS (Sistema Avanzado de Información de Incendios), la
cual brinda acceso a los pronósticos de peligros, detección casi en tiempo real, informes
históricos de incendios y mucho más. Una característica importante de esta herramienta son
los pronósticos de peligros de incendio, con base en entradas diarias de pronósticos
226
climáticos numéricos (por ejemplo, velocidad del aire, temperatura del aire y humedad
relativa), y las estadísticas de incendio de su ubicación, o donde quiera que usted señale en
el mapa. Sin embargo, este tipo de herramientas están enfocadas a notificarte cuando el
hecho ya ocurrió o esté en proceso. En consecuencia, no existe actualmente alguna
herramienta que te permita identificar las zonas donde es más probable que ocurra este tipo
de incidentes. 
Análisis del contexto y los supuestos 
Una vez explicada las propuestas existentes ya en el mercado y analizada los puntos de vista
que consideramos que pueden ser mejorables, el equipo de proyecto planteó un sistema de
geolocalización que mediante el uso de herramientas como el API de Google Maps y un
modelo predictivo permitiesen la identificación temprano de zonas vulnerables o con mayor
probabilidad de riesgo ante incendios. 
Planteamiento y sustento de una postura 
El equipo considera sólida esta propuesta, ya que se identificó con expertos de INDECI el
interés que existe en este proyecto, así como los beneficios que le otorgarían en la
adecuada gestión de riesgos y la manera de actuar anticipadamente ante este de tipo de
desastre. Asimismo, gracias a la validación realizada con usuarios, pudimos observar que un
gran porcentaje de los ciudadanos desearían tener más información sobre estos eventos, a
fin de que ellos también puedan saber de qué manera actuar.
Formulación de conclusiones 
Dado toda la información anteriormente mencionada, queremos recalcar que el objetivo

principal de nuestro proyecto es el optimizar el proceso de análisis e identificación de zonas
de riesgo mediante un sistema de geolocalización. Asimismo, consideramos que nuestra
propuesta aporta a la seguridad y tranquilidad ciudadana. Ya que la posibilidad de trabajar
con entidades públicas encargadas de tratar con los incendios permitiría mejorar las
herramientas ya existentes y considerarlas como una base de nuestro aporte.  Por otro lado,
permitiría reducir el impacto económico que generan este tipo de eventos, dentro de las
cuales tenemos las primas de seguros y las indemnizaciones a ciudadanos afectados.
227
 
Ensayo del alineamiento con la competencia de “Pensamiento Cuantitativo”

Pensamiento Cuantitativo en el desarrollo del proyecto “Sistema de Geolocalización de Riesgo
de Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha competencia
consiste en la capacidad de interpretación, representación, comunicación usando información
cuantitativa en diversas situaciones reales. Incluye calcular, razonar, emitir juicios y tomar
decisiones con base en esta información cuantitativa. 
Interpretación 
Como parte del desarrollo de nuestro proyecto fue necesario la recopilación de información. En
primer lugar, obtuvimos los registros de incendios que nos otorgaron miembros de INDECI
luego de una reunión con ellos. Esta información compartida en un formato Excel nos permitió
identificar distintas características que se toman en cuenta durante los incendios. Asimismo,
esto sirvió como parte de un entrenamiento predictivo para la identificación de nuevas zonas de
riesgo.
 
Representación 
Las características que mencionamos anteriormente fueron consideradas como variables para
determinar el nivel de impacto que pudiesen tener ciertas zonas con registros históricos de
incendios. A continuación, presentamos dichas variables y los pesos que se les asignaron a cada
uno de ellos.
Anexo A- Variables Usadas para el Análisis Predictivo

Variables Peso (%)
Número de Personas Afectadas 7.5%
Número de Personas Damnificados 10%
Número de Personas Heridas 2.5%
Número de Personas Fallecidas 15%
Número de Viviendas Afectadas 20%
Número de Viviendas Destruidas 20%
Cantidad de Veces Ocurridas 25%
228
Análisis 
 
Para llevar a cabo este modelo predictivo fue necesario definir el algoritmo predictivo para
nuestro sistema. Para eso se realizó un benchmarking con criterios de aceptación definidos por
el equipo y sustentados por artículos de investigación.  
 
Como podemos observar en la tabla 2, tenemos los criterios de evaluación que hemos definido
con su respectiva descripción del puntaje. 
  Anexo A- Descripción del puntaje de calificación para los algoritmos de Predicción 

 
1-2   3-4   5  

Puntaje  
Muy malo   Regular   Muy Bueno  
Exactitud   El algoritmo no El algoritmo El algoritmo

asegura una buena asegura asegura
exactitud durante una exactitud una exactitud
las pruebas   regular durante las alta durante las
pruebas   pruebas  
Precisión    El algoritmo no El algoritmo El algoritmo

asegura la precisión asegura la precisión asegura una alta
para predecir el para predecir el precisión para
desastre   desastre   predecir el
desastre  
Tiempo de El algoritmo tiene El algoritmo tiene El algoritmo tiene

Entrenamiento   un tiempo de un tiempo de un tiempo de
entrenamiento entrenamiento entrenamiento
alto   moderado   alto  
Usado en El algoritmo no es    El algoritmo es

incendios   usado en predicción usado en predicción
de incendios de incendios
generales   urbanos  
229
 Anexo A- Resultados de la Comparación de Algoritmos 
 
Random Forest K-
Support Vector Redes
   Classifer  Nearest Neighbor
Machines  Neuronales 
  s 
Exactitud  4  3  4  2 
Tiempo de 3  3  3  4 
Entrenami
ento 
Precisión  5  4  3  4 
Usado en 5  5  3  1 
incendios 
Total   17  15    13  11 
Comunicación / Argumentación 
 
En base a lo mostrado anteriormente, se pudo rescatar que el entrenamiento predictivo
obtuvo una eficacia satisfactoria haciendo uso del algoritmo seleccionado y la herramienta
Azure Machine Learning. Asimismo, proponemos que en futuro se podría considerar más
información como el detalle de materiales de infraestructura y cantidad de viviendas para la
evaluación e identificación de nuevas zonas de riesgo. De esta manera, se podría
complementar la herramienta propuesta y promover su uso en otras instituciones no solo
nacionales sino también internacionales.
Ensayo del alineamiento con la competencia de “Pensamiento Innovador”
El presente ensayo, tiene como finalidad evidenciar el cumplimiento de la competencia de

Pensamiento Innovador durante el desarrollo del proyecto “Sistema de Geolocalización de
Riesgo de Incendios” de la carrera de Ingeniería de Sistemas de Información. Dicha
230
competencia consiste en la capacidad de identificar necesidades y oportunidades de mejora para
proponer proyectos innovadores, viables y rentables.
Reconocer Problemas y Oportunidades 
 
Durante los últimos años, ha habido un incremento del 25% de la tasa de incendios ocurridos
en Lima Metropolitana, esto debido a diversas causas que provocaron que el lugar donde
ocurrió el hecho sea vulnerable ante este tipo de desastre. Asimismo, esto ha traído tanto
pérdidas económicas, personales y ambientales a lo largo del tiempo. 
 
En la fase inicial del proyecto se identificó y analizó las diversas oportunidades de mejora y
propuestas enfocadas al uso de la tecnología que permitieran responder esta problemática. Esto
fue posible gracias a la ayuda de las asesorías recibidas y la ardua investigación
realizada. Dentro de los resultados obtenidos de la investigación, se identificó que el uso de la
tecnología, específicamente los algoritmos de predicción, facilitaría el reconocimiento de
manera anticipada de zonas urbanas que tengan una alta probabilidad de ocurrencia de
incendios. 
 
Generar Soluciones Creativas 
 
De acuerdo con lo anteriormente mencionado, es evidente que los incendios pueden provocar
distintos efectos uno más dañino que otro. Como parte de nuestro proyecto, proponemos el
desarrollo de un sistema de geolocalización de las zonas con mayor probabilidad de ocurrencia
de un incendio. Para ello, consideramos necesario la utilización de un algoritmo de predicción.
Durante la investigación realizada, se pudo identificar que el algoritmo Random Forest llegó a
ser más preciso y efectivo para la detección temprana de desastres en comparación con otros.
Nosotros utilizaríamos dicho algoritmo que permitiría la identificación de zonas de
riesgo basándose en registros históricos y ciertos criterios que son consideramos relevantes para
las organizaciones involucradas.  
 
En primer lugar, este sistema tendrá un formato Web en el cual los usuarios de instituciones del
gobierno como lo puede ser INDECI utilizarían esta herramienta para la planificación de
231
acciones correctivas que podrán ser ejecutadas en las zonas que hayan sido identificadas como
riesgosas con respecto a los incendios. 
Por otro lado, también se contaría con una aplicación móvil, en donde los usuarios estarían más
enfocado a los ciudadanos, quienes podría tomar sus propias medidas preventivas. Asimismo,
poder contribuir con nuevas zonas de riesgo que quizás no hayan sido evaluadas o analizadas
por la herramienta, ya sea por falta de información de dicha zona o registros históricos. 
 
De esta manera, tanto las instituciones como los mismos ciudadanos contribuirían en la mejora
de la seguridad ciudadana y la planificación preventiva efectiva ante este tipo de desastres. 
 
  Planificación 
 
Para llevar a cabo la propuesta anteriormente mencionada, será necesario delimitar un alcance
dentro del proyecto. En primer lugar, que contamos con 2 ciclos académicos para poder concluir
con el proyecto. Durante este periodo se establecerán objetivos que serán cumplidos de acuerdo
al calendario establecido, de esta manera tendríamos un control adecuado de los tiempos y
entregables que se deberán presentar a los stakeholders. 
 
Por otro lado, se han establecido roles que serán necesarios para el correcto desarrollo del
proyecto. En primer lugar, como miembros del equipo se tendrá un Project Manager y un Scrum
Master, quienes serán los encargados de sacar adelante el objetivo general del proyecto.
Asimismo, se contará con un Portfolio Manager, quien validará el avance realizado por los
miembros del equipo, así como de apoyar con el conocimiento con las metodologías aplicadas.
Además, un Product Owner, quien nos ayudará mediante asesorías a entender más los objetivos
del sistema propuesto, darnos observaciones o recomendaciones que garanticen que el trabajo
realizado demuestre calidad. 
 
De igual manera, se han establecido un total de 4 objetivos específicos que conforman el
desarrollo del sistema de geolocalización propuesto. En primer lugar, en análisis de las
herramientas y distintas propuestas que hayan respondido a la problemática planteada. En
segundo lugar, el diseño de la solución que se compone tanto de los procesos que se llevarán a
cabo, la arquitectura tecnológica del sistema, los requerimiento funcionales y no funcionales y
un prototipo interactivo para el comprendimiento básico de las funcionalidades que se
232
ofrecerán. En tercer lugar, se tiene el desarrollo del sistema, en donde será necesario el uso de
las herramientas investigadas y aplicarlas de acuerdo al diseño que se había planificado. Por
último, presentar un plan de continuidad del proyecto una vez ya haya sido desarrollado, así
como los documentos que demuestren la conformidad de la solución. 
Rentabilidad y Viabilidad 
 
Como parte de nuestra sustentación acerca de la rentabilidad del proyecto, desarrollamos el
Anexo C – Costos y Presupuestos del Proyecto, en donde detallamos todos los costos internos
y externos del proyecto, así como los costos de operación que consideramos en un periodo de
1 año.
11 ANEXO C- COSTO Y PRESUPUESTO

1. Introducción
1.1 Propósito
El objetivo del presente plan de gestión de costos es lograr describir la gestión de

costos asociados a este proyecto, el cual es necesario para asegurar el cumplimiento
del presupuesto asignado. Para ello, se han identificado los componentes, métricas
e informes de costos asociados al proyecto, los cuales se detallarán en este
documento. Por tal motivo, es necesario que todos los usuarios claves del proyecto
cumplan y trabajen en base al plan de gestión de costos y el plan general del
proyecto.
1.2 Alcance
El plan de gestión de costos incluye tanto los costos internos como externos
necesarios para el desarrollo del proyecto. A continuación, se detallan los
componentes identificados:
Internos:
• Adquisición de servicios Cloud.

• Dispositivos móvil y laptops.
• Licencias y herramientas de Software
• Recursos de gestión y desarrollo del proyecto
233
Externos:
• Costos de soporte de servicios Cloud
2.Costos Internos y Externos
En esta sección se describen los costos relacionados al plan de desarrollo de la solución

propuesta detallando los costos internos y externos para un periodo de cuatro meses.
2.1 Internal Support
Anexo C- Costos Internos del Proyecto ($)
2.2 External Support
Teniendo en cuenta que para este proyecto se requerirá de servicios Cloud

ofrecidos por el proveedor Azure, es necesario considerar la estimación de costos
de soporte que ofrece el proveedor.
234
Anexo C- Costos Externos del Proyecto ($)
3.Enfoque de gestión de costes
3.1 Indicadores de Costes
Una vez analizado los costos de operación, se calculó un aproximado del costo de
operación por un año, en donde se consideran tanto los gastos internos como
externos. De esta manera, dispondremos del soporte adecuado para ofrecer los
servicios propuestos.
Anexo C- Costo de Operaciones de Mantenimiento Anual del Proyecto ($)
Basándonos en que la propuesta responde a un problema de impacto ambiental y

social, no tiene una estimación exacta de retorno de inversión. Sin embargo, si
evaluamos los antecedentes registrados de incendios y el impacto económico que
235
generan, podemos compararlo con la inversión necesaria para el desarrollo del
proyecto propuesto y estimar la reducción económica que conlleva la prevención de
este tipo de desastres.
Anexo C- Resumen de Operación del Proyecto ($)
A continuación, presentamos los costos que involucran los seguros contra incendios,
la infraestructura afectada por el desastre y las indemnizaciones que le corresponden
a los afectados.
Anexo C- Costos considerados ante un incendio ($)
De acuerdo con esto, podemos señalar en primera instancia que gracias a la solución
que proponemos se lograría reducir el costo de la prima de seguros, ya que
estaríamos garantizando la prevención adecuada ante este tipo de desastres.
Asimismo, la necesidad de adquirir este tipo de seguros se vería reducida. Por otro
lado, considerando el costo por pérdidas materiales e indemnizaciones humanas,
vemos que el impacto económico que estos eventos generan podría ser mitigado si
es que se aplican las medidas preventivas correspondientes, tras un correcto análisis
e identificación temprana de zonas de riesgo.
236
12 ANEXO - PLAN DE CONTINUIDAD
Objetivo
El plan tiene objetivo definir las actividades para garantizar la continuidad del negocio en
caso de ocurra un incidente en la ejecución de la solución propuesta.
Objetivos Específicos
Se detallarán los objetivos específicos del plan de continuación establecido:
• Definir los roles y responsabilidades de la implementación y del mantenimiento de

la solución propuesta
• Asegurar el óptimo funcionamiento de la solución propuesta aplicando los planes de
contingencia.
Beneficios
Los principales beneficios de contar con un plan de continuidad se encuentren:
• Identificar los eventos que pueden afectar la continuidad de las operaciones.

• Definir los tiempos y plazos críticos de recuperación, para volver a un estado
operativo.
• Prevenir y minimizar las pérdidas económicas.
• Es una ventaja competitiva.
• Clasificar los activos para priorizar su protección en caso ocurra un incidente
Roles de Soporte
Roles de Soporte del Plan de Continuidad

Rol Responsabilidad
Administrador de Servicios Es el responsable de la gestión total del
ambiente de operaciones y del soporte
durante la implementación y operación de
la solución
237
Operador de Servicios Es la persona encargada de realizar las
actividades de supervisión del desempeño
de la plataforma.
Procedimiento de Soporte
Los operadores de servicio tendrán una capacitación por parte de los jefes del proyecto para
resolver cualquier incidente que se presente durante el funcionamiento del sistema. En
primer lugar, se buscará la recuperación de las funcionalidades según la criticidad de los
procesos. Además, se deberá comprobar que existen las garantías de seguridad necesarias.
Finalmente, cuando se tengan los procesos funcionando de manera correcta, se deben
plantear diferentes estrategias y acciones para recuperar la funcionalidad total del sistema.
1. Gestión de Incidentes
Objetivos de la Gestión de Incidentes
• Identificar mejoras al servicio proactivamente.

• Minimizar el impacto de un incidente en el negocio.
• Restaurar el servicio afectado, lo antes posible y de acuerdo con la
prioridad para el negocio.
Beneficios de la Gestión de Incidentes
Los principales beneficios de la gestión de incidentes son los siguientes:
• Mejorar la satisfacción de los usuarios finales.

• Obtener una mayor eficiencia y productividad a través de toda la
empresa.
• Tener un mayor control de los proceso y monitoreo de los servicios
• Cumplir con los requerimientos de disponibilidad de los servicios de TI.
• Optimización de los recursos disponibles
238
Riesgos de una incorrecta Gestión de Incidentes
Una incorrecta gestión de incidentes puede afectar de manera directa la continuidad

de los servicios como la calidad de atención a los usuarios, lo cual impactaría
directamente con los costos de operación. Los principales riesgos de incorrecta
gestión de incidentes son los siguientes:
• Se genera insatisfacción por parte de los usuarios y clientes por la mala

atención de los incidentes.
• Se pierde valiosa información sobre las causas y efectos de los
incidentes para futuras restructuraciones.
• Las resoluciones de las incidencias no progresan de manera adecuada
debido a la falta de herramientas para realizar un seguimiento
automático y generen notificaciones.
• El incremento de las solicitudes de incidentes, los cuales no podrán ser
atendidos debido a una mala gestión de los recursos disponibles.
Registro de Incidentes
El registro generado por los usuarios, los cuales, al encontrar algún tipo de incidencia
que afecte el desempeño de los servicios, informan a los operadores para su
respectiva atención. El objetivo de dicho registro es ayudar a documentar y
monitorear al responsable de resolver el incidente.
Clasificaciones de Incidencias
Como se pueden registrar varios incidentes al mismo tiempo, se debe determinar el

nivel de prioridad, para la asignación de los recursos al personal encargado. Se
clasifica la prioridad de los incidentes de la siguiente manera:
• Impacto: El daño que se genera en el negocio

• Urgencia: La velocidad con la que se necesita corregir el incidente.
La intersección de los parámetros nos permite definir la prioridad de cada incidente.
239
Matriz de Urgencia vs Impacto
Análisis, Resolución y Cierre de Incidentes
En primer lugar, se debe analizar el incidente con el apoyo de la base de datos donde
se almacenan las lecciones aprendidas de anteriores incidentes, para determinar si
existen alguna solución conocida que se pueda aplicar.
En caso sea necesario se transferirá a un segundo nivel para una investigación por los
expertos encargados. Si los expertos logran atender el incidente se seguirán los
procedimientos establecidos para escalar incidentes.
Además, se puede determinar los posibles cambios según el impacto o el número de

incidentes similares. Asimismo, se deben resolver el incidente en el período
acordado con los usuarios. El objetivo es restablecer el servicio en el menor tiempo
posible, ya sea con una solución temporal o definitiva. Después de restablecer el
servicio y que el usuario confirme la solución del incidente, se cierra documentando
la incidencia de manera detallada.
2. Gestión de Problemas
El objetivo principal es minimizar la probabilidad e impacto de los incidentes, a través de la

identificación de posibles causas de incidentes, y gestionando los workarounds y errores
conocidos.
Control de Problemas
El principal objetivo es transformar los problemas en errores conocidos para poder

definir las medidas correspondientes. Para eso se realizan los siguientes pasos:
• Identificación del problema
240
• Clasificación del problema
• Asignar recursos
• Investigación y diagnostico
• Cierre del problema
Clasificación y Análisis de Recursos
Para la clasificación del problema se debe tomar en cuenta sus características

generales, como las áreas que se encuentran afectadas y los diferentes elementos de
configuración (CIs) involucrados.
Por otro lado, se debe determinar la prioridad del problema. Para eso se debe tomar
en cuenta la urgencia y el impacto del problema. Una vez ya clasificado y de acuerdo
con la prioridad del problema, se deben asignar los recursos necesarios para la
solución. Dichos recursos deben ser suficientes para que el problema se solucione de
manera eficaz.
Análisis y Diagnósticos
En esta parte del proceso es necesario realizar los siguientes procedimientos:
• Identificar las causas principales del problema

• Definir soluciones temporales para minimizar el impacto del problema,
hasta poder implementar las medidas necesarias para resolverlo de manera
definitiva.
• Asegurar que la solución propuesta sea implementada siguiendo los
procedimientos establecidos.
• Mantener la documentación asociada al problema, incluyendo los
workarounds.
• Finalmente, con las causas del problema ya determinadas, se convierten en
un error conocido y comienza a ser manejado con los procedimientos
establecidos.
241
Control de Errores
Para realizar el proceso del control de errores se desarrollan las siguientes

actividades:
• Análisis de la solución
• Aplicación de la solución
3. Gestión de Cambios
El propósito de las prácticas de control de cambios es maximizar la cantidad de cambios

exitosos de productos y servicios, asegurando que los riesgos sean apropiadamente
evaluados, autorizando la ejecución de estos y administrando una programación de cambios.
Registro
Se envía la solicitud de cambio (RFC) al equipo de gestión de cambios para la

validación y aprobación. Esta solicitud puede surgir por los siguientes motivos:
• Un incidente que causa un cambio

• Un usuario que solicita un cambio
• Un problema que provoca un cambio
• Implementar nuevos servicios
Clasificación
Las solicitudes de cambio se deben clasificar según la prioridad, urgencia e impacto

del cambio. En el caso de la prioridad del cambio se determina según los siguientes
niveles:
• Baja: Es frecuente que se considere realizar este tipo de cambios juntos con
otros del mismo nivel.
• Normal: Para este tipo de cambios, se debe buscar el mejor momento, con la
finalidad de buscar el menor riesgo posible y no afectar otros cambios de
mayor prioridad.
• Alta: Este tipo de cambios se deben resolver lo más pronto posible. Debido
que se encuentran relacionados a solucionar un problema o error conocido.
242
• Urgente: Los cambios urgentes son aquellos que se deben implementar para
resolver un problema que está ocasionando serias dificultades en los
servicios.
4. Gestión de Niveles de Servicio
Es aquella que busca establecer un compromiso entre las necesidades y expectativas del
cliente y los costos relacionados a los servicios ofrecidos.
Los principales beneficios de una adecuada gestión son los siguientes:
• Una comunicación fluida y clara con los clientes, lo que impide los malentendidos
relacionados a los servicios ofrecidos.
• Definir objetivos claros y cuantificables.
• Asignar las responsabilidades tanto de los clientes como de los proveedores del
servicio.
• Permite a los clientes conocer los niveles de calidad ofrecidos, así como los
protocolos de actuación en caso de fallos en el servicio.
Planificación
Durante la fase de planificación es necesario establecer los acuerdos y recursos que

serán necesarios para satisfacer las necesidades de los clientes. Dentro de los puntos
que se deben considerar durante la etapa de planificación tenemos:
o Documentación de los servicios TI ofrecidos.

o Presentación de los servicios ofrecidos a los clientes de forma clara y
concisa.
o Establecer indicadores claves de rendimiento del servicio TI
o Desarrollar los Acuerdos de Nivel de Servicio (SLA)
Implementación
Es necesario concluir con la elaboración y aceptación de los acuerdos necesarios para

los servicios prestados. Dentro de los acuerdos que se deben establecer están los
siguientes:
243
• Acuerdos de Nivel de Servicio (SLAs) en donde se detalla una descripción del
servicio que incluya las características específicas del servicio.
• Acuerdos del Nivel de Operación (OLAs) en donde se detallan las especificaciones
técnicas internas que son necesarias para dar soporte a los SLA acordados con los
clientes.
Monitorización
El proceso de monitorización es imprescindible si buscamos mejorar

progresivamente la calidad del servicio que se ofrece, así como su rentabilidad y la
satisfacción que genera en los clientes y usuarios. Por ello, es necesario acordar
escalas de calidad del servicio, los cuales servirán en la elaboración de los informes
correspondientes.
Las principales fuentes de información las constituyen:
o La documentación realiza de SLAs, OLAs, UCs, etc.

o La Gestión de Incidencias y Problemas se encargarán de notificar
sobre las incidencias en el servicio y los tiempos de recuperación.
o La Gestión de la Continuidad y Disponibilidad, informaran los detalles sobre
la infraestructura utilizada para satisfacer los niveles de calidad de servicio
acordados con los usuarios.
o El Service desk que mediante su comunicación diaria con los distintos
usuarios se encargará de supervisar la calidad de los servicios.
Revisión
Como parte final de este proceso, es necesario revisar aquellos SLAs que se han
incumplido. Posteriormente, se debe analizar para elaborar un Programa de Mejora
del Servicio (SIP).
5. Gestión de Seguridad
La Gestión de Seguridad permite el diseño de políticas de seguridad, en conjunto con los

clientes y proveedores correctamente alineadas con las necesidades del negocio. De esta
244
manera, aseguramos el cumplimiento de los estándares de seguridad acordados y
minimizamos los riesgos de seguridad que afecten la continuidad del negocio.
Establecimiento de Políticas de Seguridad
A continuación, presentamos las políticas establecidas para este proyecto:
- Garantizar la privacidad de datos de aquellos usuarios o información que se

encuentren registrada en nuestra nube.
- Definir el rol administrador, quien se encargará de la gestión de usuarios en caso
se necesite bloquear a uno de ellos por algún motivo en específico.
- Diseñar a nivel de base de datos con todos los campos de auditoria necesarios en
caso exista alguna modificación y se desee realizar un seguimiento del evento.
- Notificar a los usuarios el uso de sus datos personales caso se identifique que
vienen realizando alguna acción indebida.
- Garantizar la disponibilidad de datos verídicos y útiles para el análisis que se
realiza.
- Solo los gestores de cambio (programadores), que dan mantenimiento y
actualizan las versiones de la solución tendrán acceso a la BD. Por lo tanto, si los
incidentes, cambios y problemas impactan a la BD, el será el encargado de
supervisar las actividades.
- Se deben realizar copias de seguridad mensuales, con el fin de evitar pérdida de
información. La validación de copias de seguridad debe ser continua.
Definición del Plan de Seguridad
La seguridad que debe ofrecer tanto la aplicación móvil como web que han sido
desarrolladas es primordial, debido a que se no solo se manejaran registros de
usuario, sino que también información privada que las instituciones comparten entre
sí y que permiten tomar decisiones.
Para ello también es necesario evaluar las distintas amenazas que pueden atacar los
dispositivos desde los cuales se hará uso del servicio ofrecido. Dentro de estas
amenazas podemos considerar pishing, spyware, entre otros. Por esto, es necesario
245
la elaboración de un Plan de Seguridad mediante el cual se sepa la manera correcta
de actuar frente a este tipo de eventos.
Aplicación del Plan de Seguridad
Para poder llevar a cabo el plan de seguridad, es necesario la definición de políticas

de seguridad. Posteriormente, establecer los roles involucrados y sus
responsabilidades correspondientemente. Por otro lado, consideramos que es
necesarios establecer dichas políticas en base a las buenas prácticas a fin de respetar
los protocolos establecidos, todo esto en caso se haya aprovechado una
vulnerabilidad del servicio.
Representación de la Recuperación
Sabemos que la restauración del servicio prestado recae sobre la Gestión de

Incidencias. Sin embargo, la Gestión de Seguridad debe velar por lo siguiente:
o Aplicar las políticas establecidas con respecto al manejo de la información

que maneja la solución.
o Verificar en caso hubiese un ataque o caída del servicio, que los datos
continúen con la privacidad y los accesos establecidos previos al desastre.
o Analizar lo ocurrido y proponer nuevas medidas de seguridad que permitan
mitigar el impacto en eventos futuros.
6. Gestión de Disponibilidad
El objetivo principal es garantizar que los servicios TI se encuentren disponibles y funcionen

de manera correcta siempre que los usuarios deseen hacer uso de ellos.
La Gestión de Disponibilidad tiene las siguientes responsabilidades:
• Establecer los requisitos de disponibilidad en conjunto con el usuario final.

• Garantizar el porcentaje de disponibilidad establecido para la aplicación
Geoincendio.
246
• Monitorear de manera constante la disponibilidad de la aplicación Geoincendio.
• Proponer mejoras a futuro en la infraestructura y servicios TI con la finalidad de
aumentar los niveles de disponibilidad.
• Revisar el cumplimiento de los niveles de servicio y operativos acordados con los
proveedores
Planificación
Para llevar a cabo la adecuada planificación, es necesario identificar los niveles de

disponibilidad adecuados tanto para las necesidades reales del negocio como a las
posibilidades de la organización TI.
Por ello, se recomienda realizar un documento del Plan de Disponibilidad, en donde

se describan los objetivos de disponibilidad presentes y futuros. De igual manera,
las técnicas necesarias para medir su cumplimiento. Dentro de los puntos necesarios
en este plan se debe considerar:
o El nivel actual de disponibilidad de los servicios.

o Equipo para la monitorización.
o Métodos de análisis.
o Definiciones exactas de las métricas a utilizar.
o Planes de mejora a futuro.
Arquitectura de Contingencia
Como parte de la disponibilidad del sistema que se propone, consideramos que es

necesario contar con un plan de contingencia. Para una restauración rápida del
sistema en caso de un evento no deseado, sugerimos tomar en cuenta la siguiente
arquitectura de contingencia:
247
Figura 93: Arquitectura de Contingencia
248
249

Cardenas SJ

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cardenas SJ

Cargado por

Copyright:

Formatos disponibles

Sistema de geolocalización de riesgo de incendios

Item Type info:eu-repo/semantics/bachelorThesis

Authors Cardenas Suca, Julio Cesar; Tapia Medina, Diego Jesús

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/openAccess; Attribution-

Download date 02/10/2022 22:59:36

Item License http://creativecommons.org/licenses/by-nc-sa/4.0/

Link to Item http://hdl.handle.net/10757/660880

PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS DE

Sistema de Geolocalización de Riesgo de Incendios

Para optar el título profesional de Ingeniero de Sistemas de Información

Cardenas Suca, Julio Cesar (0000-0003-4275-6386)

Tapia Medina, Diego Jesús (0000-0001-7446-3612)

Lomparte Alvarado, Romulo (0000-0003-3734-3966)

Lima, 11 de junio de 2022

A mi familia, por haberme dado la oportunidad de formarme en esta prestigiosa universidad

Este proyecto tiene como finalidad implementar un Sistema de Geolocalización de Riesgo

Keywords: Geolocation, Fire, Predictive, Disaster, System

1 CAPITULO 1: DEFINICIÓN DEL PROYECTO .................................................................................. 16

1.1 ANTECEDENTES ....................................................................................................................... 16

2 CAPITULO 2: LOGROS DE LOS STUDENT OUTCOME ................................................................. 21

2.1 STUDENT OUTCOME 1 ............................................................................................................ 21

3 CAPITULO 3: MARCO TEORICO ....................................................................................................... 28

3.1 GEOLOCALIZACIÓN ................................................................................................................ 29

4 CAPITULO 4: DESARROLLO DEL PROYECTO .............................................................................. 38

4.1 ANÁLISIS .................................................................................................................................... 38

5.1 VALIDACIÓN DE LA SOLUCIÓN ......................................................................................... 122

6 CAPITULO 6: GESTIÓN DEL PROYECTO ...................................................................................... 133

6.1 PLAN DE GESTIÓN DEL PROYECTO .................................................................................. 133

7 CONCLUSIONES ................................................................................................................................ 206

8 RECOMENDACIONES ....................................................................................................................... 207

9 GLOSARIO .......................................................................................................................................... 208

10 BIBLIOGRAFIA .................................................................................................................................. 210

11 ANEXO A -WASC............................................................................................................................... 218

12 ANEXO C- COSTO Y PRESUPUESTO ............................................................................................. 233

13 ANEXO - PLAN DE CONTINUIDAD ............................................................................................... 237

PROBLEMA Y CAUSAS .................................................................................................. 17

INDICADORES DE ÉXITO .............................................................................................. 19

CONOCIMIENTOS APLICADOS .................................................................................... 21

RESULTADOS DEL PROYECTO .................................................................................... 25

ELEMENTOS DEL PROYECTO ...................................................................................... 26

TÉCNICAS, HERRAMIENTAS O METODOLOGÍAS UTILIZADAS EN EL

DESCRIPCIÓN DEL PUNTAJE DE CALIFICACIÓN PARA LOS ALGORITMOS

RESULTADOS DEL BENCHMARKING DE ALGORITMOS PREDICTIVOS ............ 47

DESCRIPCIÓN DEL PUNTAJE DE CALIFICACIÓN PARA LAS PLATAFORMAS

CARACTERÍSTICAS DE LAS PLATAFORMAS CLOUD............................................. 48

RESULTADOS DEL BENCHMARKING DE LAS PLATAFORMAS CLOUD ............. 49

NODOS DE LA ARQUITECTURA TECNOLÓGICA ..................................................... 54

INTERFACES DE LA ARQUITECTURA TECNOLÓGICA........................................... 55

SOFTWARE DE SISTEMAS DE LA ARQUITECTURA TECNOLÓGICA ................... 56

RED DE COMUNICACIONES DE LA ARQUITECTURA TECNOLÓGICA ............... 57

REQUERIMIENTOS FUNCIONALES DEL SISTEMA .................................................. 58

REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA ........................................... 63

VARIABLES USADAS PARA EL ANÁLISIS PREDICTIVO ........................................ 98

HISTORIAS DE USUARIO CERTIFICADAS EN EL SPRINT 5 ................................... 98

CASOS DE PRUEBA CERTIFICADOS EN EL SPRINT 5 ............................................. 99

HISTORIAS DE USUARIO CERTIFICADAS EN EL SPRINT 6 ................................. 100

CASOS DE PRUEBA CERTIFICADOS EN EL SPRINT 6 ........................................... 101

HISTORIAS DE USUARIO CERTIFICADAS EN EL SPRINT 7 ................................. 102

CASOS DE PRUEBA CERTIFICADOS EN EL SPRINT 7 ........................................... 103

RECURSOS UTILIZADOS PARA EL DESPLIEGUE DEL SISTEMA ........................ 105

PREGUNTAS DE LA ENTREVISTA CON MIEMBROS DE INDECI ......................... 122

DATOS DE MUESTRA (APLICACIÓN WEB) ............................................................. 128

ANEXO A- RESULTADOS DE LA COMPARACIÓN DE ALGORITMOS  ............... 230