Propuesta de Diseño de Un Aplicativo Móvil para Reportar Riesgos y Desastres

Facultad de Ingeniería
Trabajo de Investigación
“Propuesta de diseño de un aplicativo

móvil para reportar riesgos y desastres”
AUTORES:
LIZA SILVA, ESTHEFANY - 1525493
VILLAR GAVIDIA, RICARDO - U17209768
Para obtener el Grado de Bachiller en:

Ingeniería de Sistemas e Informática
Lima, diciembre 2019
1
Resumen
En el Perú, de acuerdo a las cifras de INDECI, se atendieron más de 7 mil emergencias
en el 2017 y más de 5 mil en el 2018, muchas de estas emergencias fueron por causas
naturales y otras por causas humanas, para que los daños y afectados se reduzcan es
crucial que el riesgos o desastre sea reportado a tiempo y con información pertinente
para que las entidades como los bomberos, policía, INDECI, entre otros, puedan actuar
de la manera adecuada frente a la emergencia.
Se realizó un trabajo de investigación cuyo propósito fue realizar una propuesta de diseño
para un aplicativo móvil para reportar riesgos y desastres, se utilizó la metodología RUP
para la creación de actividades de levantamiento de información, análisis y diseño del
software, y se empleó SCRUM para la gestión del proyecto, dando como producto las
historias de usuario, Sprints y Producto Backlog. Se utilizó el cuestionario en entrevistas
orales a un bombero y policía para realizar el levantamiento de información, sobre la
atención de riesgos y desastres, empleando la técnica de juicio experto. Además, se
revisaron fuentes de entidades del estado para conocer la situación actual de la atención
de emergencias ante un riesgo o desastre. Para llevar a cabo la propuesta de diseño, se
usaron diferentes softwares de licencia libre: Drwa.io, Marvel App, Bizagi y eclipse, para
la creación de los diseños. Dando como resultado, una propuesta diseño para el futuro
desarrollo de un aplicativo móvil que refleja una solución a la problemática y necesidades
encontradas durante la investigación.
Palabras clave: Aplicación móvil, reporte de daños, riesgos y desastres.
2
Dedicatoria
Este trabajo se lo dedicamos a nuestras

familias y seres queridos que siempre nos
apoyaron a cumplir nuestros objetivos.
3
Agradecimiento
A nuestros profesores por sus enseñanzas y

a nuestro asesor del curso por dedicación y
tiempo al momento de realizar el presente
trabajo de investigación.
2
Índice
Introducción ..................................................................................................................................7
1 Capítulo I: Antecedentes de la Investigación .................................................................9
1.1 Planteamiento del problema..........................................................................................9
1.2 Definición de los Objetivos ..........................................................................................11
1.2.1 Objetivo general ....................................................................................................11
1.3 Alcance de la investigación .........................................................................................12
2 Capítulo II: Marco Teórico ................................................................................................13
2.1 Problemas similares y análisis de soluciones empleadas ......................................13
2.1.1 Enfoque tecnológico  ............................................................................................13
2.1.2 Enfoque de riesgos y desastres  .........................................................................14
2.2 Tecnologías/técnicas de sustento ..............................................................................15
2.2.1 Aplicación móvil  ....................................................................................................15
2.2.1.1 Ciclo de vida de un aplicativo móvil  ...........................................................16
2.2.1.2 Ventajas de un aplicativo móvil ...................................................................16
2.2.2 RUP (Rational Unified Process)..........................................................................17
2.2.2.1 Fase de RUP .................................................................................................17
2.2.2.2 Productos de RUP ........................................................................................18
2.2.3 SCRUM ..................................................................................................................18
2.2.3.1 Eventos de SCRUM:.....................................................................................19
2.2.3.2 Artefactos de SCRUM ..................................................................................20
2.2.4 Técnica de desarrollo ...........................................................................................20
2.2.5 Gestor de Base de datos .....................................................................................21
2.3 Campo de aplicación ....................................................................................................22
2.3.1 Gestión pública......................................................................................................22
2.3.2 Gestión preventiva ................................................................................................22
2.3.3 Gestión de comunicación de emergencias .......................................................22
2.3.4 Gestión de Información ........................................................................................22
2.3.5 Campo Ambiental .................................................................................................22
2.3.6 Campo Económico ...............................................................................................23
2.3.7 Campo Social ........................................................................................................23
2.3.8 Campo Tecnológico ..............................................................................................24
3 Capítulo III: Planteamiento de la Solución ...................................................................24
3.1 Selección de la Solución ..............................................................................................24
2
3.1.1 Evaluación de la metodología .............................................................................24
3.1.2 Evaluación de la gestión del proyecto................................................................24
3.1.3 Evaluación de la técnica de desarrollo ..............................................................25
3.1.4 Evaluación del gestor de base de datos ............................................................25
3.2 Recursos Necesarios ...................................................................................................25
3.2.1 Metodología ...........................................................................................................25
3.2.1.1 Levantamiento de información ....................................................................25
3.2.1.2 Sprint 1: Planificación del proyecto ............................................................28
3.2.1.3 Sprint 2: Diseño del aplicativo .....................................................................29
3.2.1.4 Sprint 3: Desarrollo del aplicativo ...............................................................30
3.2.1.5 Sprint 4: Funcionalidad del aplicativo .........................................................32
3.2.1.6 Sprint 5: Implementación del aplicativo .....................................................32
3.2.2 Herramientas .........................................................................................................33
3.2.3 Cronograma ...........................................................................................................35
3.3 Estudio de viabilidad ....................................................................................................35
3.3.1 Viabilidad operativa ..............................................................................................35
3.3.2 Viabilidad técnica ..................................................................................................35
4 Capítulo IV: Análisis de los resultados de la investigación .....................................36
4.1 Levantamiento de la información ................................................................................37
4.1.1 Actividad: Elaborar documentos para las entrevistas ......................................37
4.1.1.1 Cuestionario para las entrevistas................................................................37
4.1.1.2 Acta de reuniones .........................................................................................38
4.1.2 Actividad: Coordinar por correo fecha y hora de las entrevistas ....................40
4.1.2.1 Correos de coordinación ..............................................................................40
4.1.3 Actividad: Realizar las entrevistas ......................................................................41
4.1.3.1 Audios de las entrevistas .............................................................................41
4.1.3.2 Actas de reuniones debidamente llenadas digitalizados .........................41
4.1.4 Actividad: Procesar la información producto de las entrevistas .....................44
4.1.4.1 Resumen de las entrevistas ........................................................................44
4.1.5 Actividad: Analizar la información procesada ...................................................47
4.1.5.1 Resultado de las entrevistas .......................................................................47
4.1.6 Actividad: Buscar proyectos o investigaciones con línea de investigación
similar a la de nuestro proyecto ..........................................................................................49
4.1.6.1 Carpeta con tesis revisadas ........................................................................50
4.1.7 Actividad: Elegir los proyectos que guarden relación al nuestro ....................50
3
4.1.7.1 Documento Resumen de tesis revisadas ..................................................50
4.2 Sprint 1: Planificación del proyecto ............................................................................51
4.2.1 Actividad: Realizar el modelo del negocio .........................................................52
4.2.1.1 Mapa de procesos de una emergencia ......................................................52
4.2.1.2 Diagrama de proceso del aplicativo ...........................................................53
4.2.1.3 Reglas del negocio .......................................................................................55
4.2.2 Actividad: Elaborar los requisitos para el aplicativo .........................................56
4.2.2.1 Gráficos de casos de uso ............................................................................57
4.2.2.2 Historias de usuario y Product Backlog .....................................................61
4.2.3 Actividad: Realizar reunión para el avance del proyecto.................................67
4.2.3.1 Acta de reunión .............................................................................................68
4.3 Sprint 2: Diseño del aplicativo .....................................................................................69
4.3.1 Actividad: Analizar los requisitos para el desarrollo del aplicativo .................69
4.3.1.1 Metamodelo NoSQL .....................................................................................69
4.3.1.2 Diagrama de clases ......................................................................................70
4.3.1.3 Arquitectura del aplicativo ............................................................................72
4.3.2 Actividad: Elaborar los mockups del aplicativo .................................................72
4.3.2.1 Prototipo de interfaces .................................................................................73
4.3.3 Actividad: Realizar reunión para el avance del proyecto.................................85
4.3.3.1 Acta de reunión .............................................................................................85
Conclusiones y Recomendaciones .......................................................................................87
Conclusiones:............................................................................................................................87
Recomendaciones:...................................................................................................................87
Bibliografía...................................................................................................................................89
Anexo 1: Glosario .........................................................................................................................94
Anexo 2: Modelo de reportes ......................................................................................................95
4
Índice de Ilustraciones
Ilustración 1: Cuestionario para las entrevistas .................................................................. 38
Ilustración 2: Acta de Reunión con los expertos................................................................. 39
Ilustración 3: Correos para la coordinación de las entrevistas ........................................... 40
Ilustración 4: Audio de las entrevistas realizadas ............................................................... 41
Ilustración 5: Acta de reunión con el bombero ................................................................... 42
Ilustración 6: Acta de reunión con el policía ....................................................................... 43
Ilustración 7: Referencia de una entrevista digitalizada a un bombero ............................. 45
Ilustración 8: referencial de una entrevista digitaliza a un policía ...................................... 46
Ilustración 9: Análisis de entrevistas ................................................................................... 49
Ilustración 10: Carpeta con las tesis revisadas .................................................................. 50
Ilustración 11: Documento del resumen de tesis revisadas ............................................... 51
Ilustración 12: Proceso de llamada de emergencia a la policía o bomberos ..................... 52
Ilustración 13: Diagrama de proceso de registro de usuario .............................................. 53
Ilustración 14: Diagrama de proceso de registro de riesgos o desastres .......................... 54
Ilustración 15: Diagrama de atención de emergencia ........................................................ 55
Ilustración 16: CDU/ Ciudadano- Módulo Login ................................................................. 57
Ilustración 17: CDU / Ciudadano – Módulo Usuario ........................................................... 58
Ilustración 18: CDU/ Ciudadano – Modulo Registrar Emergencia ..................................... 58
Ilustración 19: CDU/ Ciudadano – Modulo Visualizar emergencia .................................... 59
Ilustración 20: CDU/ Personal de Emergencia – Módulo Login ......................................... 59
Ilustración 21: CDU / Personal de Emergencia – Módulo Usuario .................................... 60
Ilustración 22: CDU/ Personal de Emergencia- Módulo emergencia ................................. 60
Ilustración 23: Acta de reunión 1......................................................................................... 68
Ilustración 24: Metamodelo NoSQL .................................................................................... 70
Ilustración 25: Diagrama de clases ..................................................................................... 71
Ilustración 26: Arquitectura del aplicativo ........................................................................... 72
5
Ilustración 27: Prototipo del registro del usuario................................................................. 74
Ilustración 28: Prototipo login de usuario ............................................................................ 75
Ilustración 29: Prototipo Menú de opciones de usuario...................................................... 76
Ilustración 30: Prototipo categoría de emergencia ............................................................. 77
Ilustración 31: Prototipo mapa de emergencias ................................................................. 78
Ilustración 32: Prototipo Detalle de Emergencia ................................................................. 79
Ilustración 33: Prototipo Noticias ......................................................................................... 80
Ilustración 34: Prototipo Editar perfil ................................................................................... 81
Ilustración 35: Prototipo menú desplegable para el personal de atención de emergencias
............................................................................................................................................. 82
Ilustración 36: Prototipo Registrar noticia. .......................................................................... 83
Ilustración 37: Prototipo historial de emergencias .............................................................. 84
Ilustración 38: Prototipo Ver mapa ...................................................................................... 85
Índice de Tablas
Tabla 1: Historias de usuario del aplicativo móvil ............................................................... 63
Tabla 2: Product Backlog .................................................................................................... 67
6
Introducción
La presente investigación tiene como objetivo proponer el diseño de una aplicación móvil
para reportar riesgos y desastres, con el fin de proporcionar un canal de comunicación
más para las entidades y que los ciudadanos puedan involucrarse más. De esta manera,
se reducen los efectos que ponen en riesgo la integridad física de las personas o que
causan daños materiales.
La investigación de esta problemática en beneficio de la sociedad se realizó por el interés
de conocer más acerca de la situación actual del país con respecto a su accionar ante los
desastres. Esto permitió conocer el proceso y medios por los cuales se realizan los
reportes de riesgos y desastres más usados por los bomberos y policías, así mismo
percibir las carencias de estos procesos y sistemas.
El poder desarrollar una herramienta que ayude a la gestión preventiva, fue un interés
académico. De tal manera, se puede difundir una cultura preventiva en la población y al
mismo tiempo trabajar de manera colaborativa con ellos para poder obtener la
información pertinente de los riesgos o desastres que están presenciando para poder
actuar de la mejor manera.
Capítulo 1, se definen los antecedentes de la investigación, planteamiento del problema,
se definen los objetivos y el alcance de la investigación.
Capítulo 2, se desarrolla el marco teórico con la investigación de problemas similares y el
análisis de las soluciones empleadas, se listan las tecnologías o técnicas que se usan en
la investigación. Por último, se menciona el campo de aplicación de la propuesta.
7
Capítulo 3, se realiza el planteamiento de la solución con la selección de solución, la
evaluación de los recursos necesarios, metodología empleada, herramientas usadas,
cronograma y estudio de viabilidad.
Capítulo 4, Se realiza el análisis de los resultados de la investigación, con una
descripción las actividades y entregables, definiendo el motivo, uso e importancia que
tuvieron para poder realizar el proyecto hasta la etapa de diseño.
8
1 Capítulo I: Antecedentes de la Investigación
1.1 Planteamiento del problema
Alrededor del mundo se producen distintos fenómenos naturales, de acuerdo a las
condiciones climáticas o las zonas geográficas se presentan en mayor o menor magnitud.
Por consiguiente, en el momento que representan un peligro para la integridad física para
las personas, se convierten en desastres naturales. En consecuencia, las personas,
empresas y gobiernos se han visto en la necesidad de prepararse de manera más
adecuada ante estos eventos e intentar reducir los impactos, pérdidas y daños que estos
puedan ocasionar. Es por eso que diversas organizaciones vienen desarrollando
proyectos para analizar las vulnerabilidades, riesgos y consecuencias que pueden
producirse en su país u otros. Con el fin de ayudar a los gobiernes a estar mejor
preparados, este es el caso de INFORM, realizado por Inter-Agency
Standing Committee (IASC) y la Comisión Europea, cuya misión es ayudar a empresas y
países para que puedan tomar precauciones ante los fenómenos naturales a los cuales
están más expuestos.
En el caso del Perú, es necesario permanecer alerta ante cualquier evento, ya que la
zona geográfica en la que está ubicado es propensa a que ocurran fenómenos naturales
de distintos tipos. INFORM (2018) reporta que el Perú se encuentra en el puesto 68 de
191 países según su vulnerabilidad a los riesgos presentes en desastres naturales
más propensos a suceder, siendo los más preocupantes los sismos, inundaciones, lluvias
intensas, bajas temperaturas y sequías. Ante este tipo de advertencias y los eventos
desafortunados que se vienen presentando en el territorio peruano, las autoridades
buscan desarrollar políticas, estrategias y acciones ante los fenómenos naturales con el
fin de reducir el impacto que estos puedan ocasionar. Presidencia del Consejo de
Ministros (PCM) el Plan Nacional de Gestión del Riesgo de Desastres (PLANAGERD
2014 - 2021) establece el conjunto de orientaciones dirigidas a la reducción de riesgos de
9
desastres, así como una preparación adecuada y minimizar los efectos negativos sobre la
población, economía y el ambiente. De la misma manera, buscan difundir en la población
la cultura preventiva mediante simulacros, publicidad y campañas de concientización,
todas estas acciones son dirigidas por el Instituto Nacional de Defensa Civil (INDECI). Es
así como el estado busca invertir de manera adecuada sus recursos en prevención, con
el fin de mitigar las pérdidas económicas y humanas ante cualquier desastre que se
presente.
En primer lugar, los sistemas de registro de emergencias solo pueden ser usados por
funcionarios públicos autorizados de cada dependencia, el objetivo de estos sistemas es
registrar la información y características de las emergencias atendidas. Sin embargo,
estos sistemas producen un estado desactualizado de la información que se maneja,
debido a que se llenan los formularios horas o días después de atendida la emergencia,
lo cual produce que los datos no sean los correctos y en muchos casos incompleta al
traspapelarse los reportes escritos. En segundo lugar, no se maneja un estándar entre la
policía, bomberos y municipalidades, lo que genera duplicidad en los reportes al ser
llenados con otros nombres o términos, refiriéndose a la misma emergencia. Por lo cual,
no se pueden obtener reportes confiables para el análisis o toma de decisiones. En tercer
lugar, si bien se tienen políticas preventivas por parte del estado y gobiernos regionales
para actuar debidamente antes que sucedan los desastres, no se cuenta con los
suficientes recursos para que el personal recorra el país en búsqueda de situaciones de
riesgo que puedan convertirse en desastres, al no poder reportarlas y comunicarse con
las entidades correspondientes para que tomen las medidas correctivas a tiempo, lo cual
genera una mayor vulnerabilidad a los riesgos por ser detectados de manera tardía. Por
último, la población no se involucra ni se ve tan interesada en la cultura preventiva, esto
se ve reflejado en la poca participación de los simulacros y otros eventos de
concientización por parte de las distintas entidades a nivel nacional, lo que provoca que
10
no se encuentren debidamente preparados ante el suceso de riesgo o desastre en el cual
se puedan ver involucrados, lo cual origina mayor índice de vulnerabilidad y amenaza a
sufrir daños.
1.2 Definición de los Objetivos
1.2.1 Objetivo general
Diseñar un aplicativo móvil para reportar riesgos y desastres.
La solución tecnológica se enfocará en diseñar un aplicativo móvil que permite, a los
usuarios, reportar los riesgos y desastres a nivel nacional que pueden presenciar como
son: accidentes de tránsito, incendios, inundaciones, derrumbes, entre otros. De esta
manera, la aplicación emite una alerta a las autoridades y/o entidades más cercanas para
que estas actúen de forma inmediata o tomen las medidas correctivas en el momento
adecuado, reduciendo así el tiempo de respuesta ante una emergencia. Además, el
aplicativo informa a los ciudadanos sobre las situaciones de riesgo o desastres e indica las
medidas o acciones que se pueden tomar para no verse afectados.
La aplicación beneficiará a los ciudadanos puesto que recibirán continuos mensajes,
boletines e informe de simulacros que los mantendrá informados ante las situaciones de
riesgo y desastres. También, estarán con una continua formación en cultura preventiva
mediante el manual de usuario con la información de los riesgos y desastres más comunes.
Además, se podrá llegar a mayor población mediante boletines virtuales, incentivando a la
participación de talleres o simulacros que realicen las distintas entidades, ya que gran parte
de la población tiene acceso a un smartphone. Adicionalmente, se produce un beneficio
ambiental al reducir el ahorra de formularios impresos y la movilización de personal para el
levantamiento de información. Por último, se tienen un ahorro monetario en la creación de
panfletos o boletines impresos, así como pago por publicidad en los medios, todo esto se
puede enviar a través del aplicativo.
11
1.3 Alcance de la investigación
El presente trabajo de investigación tiene por alcance el diseño de un aplicativo
móvil para el reporte de riesgos y desastres a, el cual contará con una interfaz intuitiva y
fácil entendimiento, con el cual los usuarios podrán guiarse, entender y realizar el reporte
de los riesgos y desastres con la información adecuada.
La aplicación contará con un manual de usuario en el cual mostrará el correcto uso del
aplicativo y la correcta clasificación de los distintos riesgos y desastres como son:
Accidentes de tránsito, tipos de incendios, derrumbes, inundaciones, fugas de gas, entre
otro. Además, se podrá clasificar el incidente de acuerdo al riesgo que representa.
Los datos del reporte estarán estandarizados mediante un formulario con los siguientes
campos: dirección, tipo de riesgos o desastre, fotos o videos adjuntos y una descripción
del riesgo, toda esta información será almacenada en un base de datos en de la cual
pueden obtener reportes más precisos de acuerdo a la necesidad de las entidades y así
puedan tomar mejores decisiones.
Se contará con un espacio informativo en el cual serán publicados boletines informativos
de concientización para los usuarios, motivándolos a que participen activamente de los
simulacros y ejercicios de prevención. Además, se emitirá una alerta informativa en caso
que suceda un desastre de importancia para que los usuarios puedan tomar sus
precauciones.
Finalmente, el aplicativo estará conectado a los principales sistemas de alerta de las
municipalidades, divisiones de policías y bomberos para que estos puedan actuar de
manera inmediata, con el conocimiento del tipo y detalles de la emergencia a la que
acuden.
12
El presente trabajo de investigación se realizará hasta la fase de Análisis y Diseño. En la
fase de análisis se reunirá y analizará la información proporcionada por las personas y/o
entidades para quienes se diseñará la aplicación móvil. El análisis permitirá obtener los
requerimientos y peticiones correspondientes, clasificarlas y diseñar un servicio
personalizado. En la fase de diseño, consiste en plasmar el previo análisis en diagramas,
gráficos y esquemas sobre cómo será el funcionamiento y el aspecto de la aplicación.
2 Capítulo II: Marco Teórico
2.1 Problemas similares y análisis de soluciones empleadas
 Los riesgos y desastres vienen siendo fuente de muchas investigaciones, en las cuales
se busca crear herramientas, usar la tecnología actual, mejorar o proponer procesos en la
prevención y mitigación de riesgos, así como en las etapas de un desastre (antes,
durante y después). En la presente investigación se toma dos enfoques que se relacionan
con la propuesta: tecnológico y riesgos y desastres. 
2.1.1 Enfoque tecnológico 
En la tesis “Diseño de un sistema de telecomunicación con redes Ad Hoc de drones como
alternativa de medio de comunicación para hacer frente a desastres naturales” de
Ramírez, Wilfredo en la Pontificia Universidad Católica del Perú, plantea el uso de drones
en las zonas afectadas por desastres naturales para poder brindar un medio de
comunicación, para esto opto por buscar un programa de simulación de redes
inalámbricas llamado OPNET, con el cual concluye que es posible desarrollar un
sistemas de comunicaciones inalámbricas entre ciudades que se encuentran a hasta a 3
km. de distancia con autonomía de trabajo de 2 horas mediante el uso de paneles solares
en los drones. Por otro lado, la tesis “Propuesta de la aplicación móvil basado en
ubicaciones de zonas ante desastres naturales en Iquitos” de Ríos, Paulo y Vela, Terry
en la Universidad Nacional de la Amazonía Peruana, plantean el uso de una investigación
13
de tipo descriptivo-aplicativo y un diseño no experimental de tipo transversal tomando dos
variables: independiente (desarrollo de una aplicación móvil) y variable dependiente
(gestión de a información de zonas de ubicación ante desastres naturales en Iquitos), con
lo cual recurren a la encuesta con cuestionarios y llegan a la conclusión que el desarrollo
de una aplicación móvil en Android mejorará la gestión de la información ante desastres
naturales en Iquitos. Por último, en la tesis “Aplicación móvil para reportar los daños
causado por los desastres naturales a los centros educativos para el Ministerio de
Educación” de Quispe, Johnny en la Universidad César Vallejo, realiza un tipo de estudio
aplicado y el tipo de diseño fue pre-experimental con 80 instituciones educativas de un
total de 17000 aplicando una técnica no probabilística por ser una prueba piloto. Se llega
a la conclusión que con el uso del aplicativo móvil el tiempo para reportar daños se redujo
en un 77%, mientras que el costo de ese proceso disminuyó en 90%. 
 Las investigaciones expuestas hacen uso de las tecnologías para proporcionar una
herramienta más ante los desastres naturales, de la misma manera que en la presente
investigación. Sin embargo, estas propuestas se plantean en escenarios luego de
ocurridos los desastres, en comparación de mi investigación que se centra en la situación
previa al desastre. 
2.1.2 Enfoque de riesgos y desastres 
 En el proyecto de tesis “La gestión de desastres en la cultura de prevención de los
docentes de Educación Básica Regular, Región Puno - 2016” de Hidalgo, Martha en la
Universidad César Vallejo, emplea una investigación aplicada y el diseño
cuasiexperimental tomando una muestra de 84 docentes divididos en dos grupos, usando
la técnica de la encuesta con cuestionario basado en cultura preventiva validado con el
juicio de expertos, dando como resultado que el grupo en el cual se aplicó la gestión del
riesgo de desastres alcanzó mejores resultados que el otro grupo. Por otro lado, en la
14
tesis “Gestión de riesgos y capacidad preventiva ante desastres originados por el cambio
climático en el distrito de Nueva Cajamarca - 2018” de Justo, Luis en la Universidad
César Vallejo, plantea la relación entre la gestión de riesgo y la capacidad preventiva con
un estudio no experimental, descriptivo correlacional con una muestra de 320 pobladores
usando cuestionarios para medir las variables de estudio. Obteniendo como resultado
que la gestión de riesgo y el grado de capacidad preventiva se califican como deficientes
o malas, concluyendo en que existe una relación entre ambas y la gestión de riesgo
influye en un 65.45% sobre la capacidad preventiva. 
 En relación a nuestra investigación, las investigaciones expuestas muestran la
importancia de poder reportar los riesgos o desastres con respecto a la mejora en la
capacidad preventiva y velocidad de atención de estos acontecimientos. Además, se
busca que con la aplicación móvil para reportar riesgos y desastres impacte en la cultura
preventiva de los ciudadanos. 
2.2 Tecnologías/técnicas de sustento
2.2.1 Aplicación móvil 
Las aplicaciones móviles se han vuelto muy populares en los últimos años, cada vez se
ven en mayor cantidad y de todo tipo, desde aplicaciones para el trabajo como
aplicaciones para el ocio o diversión. Además, para muchas empresas representa un
medio o canal más para llegar a sus clientes. De acuerdo con Ríos (2019) “son
programas que se ejecutan sobre dispositivos móviles como: tabletas o Smartphone por
ello se debe administrar bien los recursos como la memoria, y el procesamiento para no
saturar el dispositivo. Actualmente muchas empresas buscan desarrollar aplicaciones con
el fin de facilitar el acceso a sus servicios y llegar a más clientes.”. Por otro lado, para
Nakamura (2014) las aplicaciones móviles son un software desarrollado y usado para los
dispositivos móviles, recalcando el significado de la palabra móvil la cual hace referencia
15
a que se puede acceder desde cualquier lugar a la información. Así mismo, las
aplicaciones móviles hacen más ágil y rápida la comunicación a larga distancia.
Entonces, las aplicaciones móviles siguen ganando popularidad y las personas recurren a
ellas con mayor frecuencia. Es por ello que, el uso de un aplicativo móvil para el reporte
de riesgos y desastres sería bien aceptado. 
2.2.1.1 Ciclo de vida de un aplicativo móvil 
Para poder desarrollar un aplicativo hay que seguir ciertas actividades secuenciales para
poder obtener un producto que cumpla con el objetivo planteado y satisfaga la necesidad
por el cual está siendo creado a esto se le llama ciclo de vida, este es parecido al ciclo de
vida de una aplicación web o de escritorio, consta de 5 partes, el inicio donde se plantea
una idea con base sólida, luego se precede con un diseño en el cual se define la
experiencia del usuario de la aplicación para obtener un diseño de interfaz de usuario, el
desarrollo donde se hace uso de los recursos para crear la aplicación, la estabilización en
donde se hacen los controles de calidad, limpieza y pruebas necesario, finalmente se
realiza la implementación de la idea propuesta (Microsoft 2016). Estas partes descritas se
deben incluir dentro del proyecto de desarrollo de la aplicación para garantizar su
correcta implementación. 
2.2.1.2 Ventajas de un aplicativo móvil
El desarrollo de una aplicación móvil tiene las siguientes ventajas:
● Se adapta a todo tipo de dispositivos smart, es decir, puede ser usado en una
amplia gama de dispositivos que los usuarios ya tienen.
● Es de fácil acceso para los usuarios, ya que se puede descargar desde cualquier
Store.
● Siempre está disponible ya que se encuentra en cloud, lo que asegura su
disponibilidad 24/7.
16
● Es de fácil uso, ya que cada vez más de usuarios optan por usar las aplicaciones
móviles en lugar que las páginas web.
2.2.2 RUP (Rational Unified Process)
Es una metodología que permite trabajar ordenada y estructuralmente los proyectos de
desarrollo de software, cuyo objetivo es lograr plasmar los requisitos y cumplir con el
alcance propuesto en un software, para esto cuenta con fases y sus artefactos
respectivos por cada fase (Guzmán 2018).
2.2.2.1 Fase de RUP
La metodología RUP consta de cuatro fases, son las siguientes:
● Inicio: En la fase de inicio se busca definir el alcance del proyecto, la viabilidad y
los cotos. Además, se busca identificar los riesgos que pueden ocurrir durante el
proyecto, para finalmente proponer una arquitectura de software y definir el plan
de las fases en las siguientes iteraciones.
● Elaboración: En la fase de elaboración se busca eliminar los riesgos identificados
en la fase anterior, se desarrollan los casos de uso y se lleva a cabo un prototipo
de la arquitectura.
● Construcción: En la fase de desarrollo se busca completar la funcionalidad del
sistema, se realizan pruebas necesarias para verificar el cumplimiento de los
requisitos, se administran los cambios necesarios de acuerdo a las pruebas
realizadas.
● Transición: En la fase de transición se asegura el funcionamiento del software
según los requerimientos establecidos por los usuarios, se realizan ajustes en los
defectos encontrados durante la prueba beta del software con los usuarios y a
partir de esas pruebas se generan nuevos desarrollos.
17
2.2.2.2 Productos de RUP
● Inicio: La fase de inicio comprende todos los artefactos necesarios para llevar a
cabo un correcto alcance y una definición de los requerimientos de los usuarios,
los artefactos que se producen son: Documento visión, diagramas de caso de uso,
especificación de requisitos, diagrama de requisitos.
● Elaboración: En la fase de elaboración se generan distintos diseños que
dependen del tipo de proyecto que se está realizando para ir generando más o
menos artefactos, los principales son: Documento arquitectura que incluye el
diagrama de clase y el modelo E-R, diagrama de secuencia, estados y
colaboración, modelo de dominio y, por último, mapa de comportamiento a nivel
de hardware. También, se producen el diseño y desarrollo de los casos de usos,
así como las pruebas de lo desarrollado hasta el momento.
● Construcción: En la fase de construcción se producen los siguientes artefactos:
Especificación de requisitos faltantes, desarrollo de casos de uso y pruebas de
casos de uso desarrollados.
● Transición: En la fase de transición, se lleva a cabo las pruebas finales del
proyecto, involucrando a los usuarios con el fin de obtener las últimas mejoras a
realizarse, se dan los siguientes artefactos: Pruebas finales de aceptación, puesta
en producción y estabilización.
2.2.3 SCRUM
Es un marco de trabajo que consiste en ciclos iterativos, llamados sprint, en los cuales se
ve un avance incremental del proyecto, lo que permite llevar un control adecuado sobre
los riesgos que se pueden presentar. “Scrum no es un proceso o una técnica para
construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden
emplear varias técnicas y procesos” (Schwaber y Sutherland, 2013). Siendo así, un
marco de trabajo apropiado para proyectos de distintas dimensiones, permitiendo al
18
equipo dividir el objetivo, gestionar recursos, llevar un control de desarrollo y un flujo
continuo de conocimiento entre los miembros del equipo. Por último, se pueden emplear
distintas herramientas en cada uno de los Sprint del proyecto.
2.2.3.1 Eventos de SCRUM:
● El Sprint
Es una parte del proyecto que se lleva a cabo en un tiempo determinado, en el
cual se desarrolla parte del proyecto de manera funcional, es decir es puesto en
producción.
● Reunión de Planificación de Sprint
La reunión es dirigida por el Scrum Master con el fin que todos los puntos de la
reunión sean entendidos, para que sepan que objetivo se debe conseguir con el
sprint y que es necesario hacer para conseguirlo.
● Objetivo del Sprint
El objetivo del Sprint se define en la reunión de planificación de sprint, se describe
el motivo por el cual se lleva a cabo el incremento de dicha iteración con el fin de
conseguir que el equipo trabaje en conjunto para conseguirlo.
● Scrum Diario
Es una reunión que se lleva a cabo cada día por un periodo corto de tiempo, en la
cual se busca que el equipo planifique sus actividades hasta la próxima reunión,
de esta manera se reducen los riesgos, se potencian el desarrollo y todos apuntan
al mismo objetivo.
● Revisión de Sprint
Se lleva a cabo al finalizar el sprint para inspeccionar el incremento realizado en el
sprint, corregir algunos puntos de ser necesarios y se da junto con los
interesados, para que se tenga una apreciación general de lo que se ha
desarrollado y en caso se den cambios.
19
● Retrospectiva de Sprint
Es una reunión de los miembros del equipo, en la cual se hacen una auto
inspección, con la cual se pueden llevar a cabo mejoras que pueden ser aplicadas
en los siguientes Sprint.
2.2.3.2 Artefactos de SCRUM
● Lista de Producto
Es una lista ordenada con todos los requisitos básicos para llevar a cabo el
desarrollo del proyecto, siendo la base de la cual el equipo toma los puntos de
partida para ir generando los incrementos a medida que se llevan a cabo los
sprints.
● Lista de Pendientes del Sprint
Es creada por el equipo en base a su experiencia, en la cual se hace mención al
próximo incremento que se llevará a cabo, sus funcionalidades, objetivo y los
trabajos que se tienen que realizar para poder cumplir dicho incremento.
● Incremento
Se define como la suma de la lista de productos que ya se han realizados, y este
se va creciendo conforme se llevan a cabo los sprint, de esta manera todos los
sprint con estado “terminado” conforma el incremento y se caracteriza porque
puede ser usado, es decir ya es funcional.
2.2.4 Técnica de desarrollo
La técnica de desarrollo es una de las primeras decisiones que se debe de tomar para
empezar con el desarrolla del proyecto. Se tiene que tomar muchas consideraciones,
“dependerá de los recursos económicos con que se cuente, los conocimientos previos del
equipo, la arquitectura general de la solución, así como elementos exógenos como
intereses, pasiones, acuerdos, etc.” (InnovaAge 2017). En la presente investigación se
20
emplea la técnica de desarrollo para aplicaciones híbridas, en las siguientes líneas se
describe un breve concepto y sus principales características:
Las aplicaciones híbridas usan tecnologías como son: HTML5, CSS o JavaScript, las
cuales se emplean mediante un framework de desarrollo como Córdoba o Phonegap por
mencionar alguno de ellos. Estos framework brindan acceso a las capacidades básicas
de los dispositivos móvil sin importar el sistema operativo. Es decir, al desarrollar la
aplicación este se adapta a todas las plataformas móviles, generando un instalador para
cada una de ellas, lo cual genera una portabilidad máxima del desarrollo.
2.2.5 Gestor de Base de datos
El gestor de base de datos nos sirve para saber de qué manera se manejan los datos, el
orden y jerarquía que tendrá la información que se genera o guarda producto del uso del
aplicativo, por lo cual es importante saber las características del proyecto para saber qué
tipo de gestor de base de dato conviene usar. En la presente investigación se usará un
gestor de base de datos NOSQL, el cual se explica en las siguientes líneas:
Las bases de datos NOSQL, son las predecesoras de las SQL y su principal
característica es que no son estructuras, esto quiere decir que no tienen una tabla fija con
los atributos ni se tienen las relaciones entre las tablas, lo que le permite una gran
flexibilidad y escalabilidad a momento de almacenar información, sobre todo cuando se
tienen pocos recursos, si el proyecto va a requerir de constantes cambios. Actualmente,
existen muchas opciones para gestores de base de datos, la mayoría se almacenan en la
nube y ofrecen otros servicios adicionales para trabajar con los datos que se van
generando.
21
2.3 Campo de aplicación
2.3.1 Gestión pública
El tener datos actualizados de los riesgos y desastres más frecuentes el estado puede
designar mayor presupuesto para tomar las medidas correctivas del caso y mitigar los
riesgos más frecuentes que se presentan, reduciendo así daños y pérdidas.
2.3.2 Gestión preventiva
Permite llevar a mayor población, brindando información actualizada y motivando a los
usuarios a la continua participación de talleres, eventos y simulacros que pueden
realizarse. Además de ser un medio más de comunicación ante cualquier evento.
2.3.3 Gestión de comunicación de emergencias
Las instituciones integradas al aplicativo mejoraran sus procesos de comunicación e
información entre instituciones y hacia el ciudadano. De esta manera, se reduce el tiempo
de atención de los riesgos o desastres reportados.
2.3.4 Gestión de Información
Al manejar un estándar de información, todas las entidades manejan una base de datos
unificada, evitando la redundancia de datos o el llenado incorrecto de estos. Además, se
podrá realizar el análisis de datos para la toma de decisiones futuras.
2.3.5 Campo Ambiental
En el aspecto ambiental, se reducirá el uso de fichas a ser llenadas en la recolección de
datos, así como el ahorro de movilización de personal a los distintos puntos del país
(reducción de CO2). Además, con los datos recolectados se podrá realizar una gestión
preventiva más eficiente, con lo cual se puede reducir la contaminación por explosiones,
derrames u otros efectos colaterales de los desastres.
22
2.3.6 Campo Económico
En el aspecto económico, el uso de una aplicación móvil genera un ahorro en costo y
tiempo del personal encargado de la recolección de datos, ya que los datos recolectados
serán proporcionados por las personas que cuenten con el aplicativo móvil e internet
serán procesados de manera automática. Esto es posible debido a la penetración del
servicio de internet móvil, según el Organismo Supervisor de Inversión Privada en
Telecomunicaciones (OSIPTEL 2018) 48.6 % del total de usuarios de telefonía móvil
cuentan con internet móvil en su plan tarifario. Por otra parte, se debe invertir en
capacitación del personal que recibe estos datos para que puedan transformarlos en
información útil y se comunique a las entidades correspondientes los riesgos que se han
detectado para que tomen las medidas necesarias. Así mismo, el poder tener la data
digitalmente suma la calidad, evita la falsificación y daños físicos que las fichas, informes
u otros documentos pueden sufrir.
2.3.7 Campo Social
En lo social, de acuerdo al boletín estadístico virtual de la gestión reactiva de enero del
presente año en el Perú se registraron un total de 5444 emergencias, entre las cuales las
de mayor ocurrencia fueron las bajas temperaturas, incendio urbano e industrial y lluvias
intensas teniendo como consecuencia más de 28 mil damnificados, casi 1 millón de
afectados y 159 fallecidos (INDECI 2019). Ante tantos escenarios negativos, el proyecto
busca involucrar a los ciudadanos con el levantamiento de datos en los diferentes
escenarios de riesgos que ellos puedan presencia. De esa manera, podrán sentir que
están colaborando un poco más con el desarrollo de su comunidad, tendrán un medio por
el cual comunicar de manera efectiva y rápida. Además, se podrá realizar una cultura
preventiva masiva, puesto que el aplicativo también proporciona información pertinente
para reconocer un riesgo, saber qué medidas tomar antes, durante y después de un
23
desastre. OSIPTEL (2018) 78 de cada 100 habitantes accedieron al servicio de internet
móvil, lo cual crea una gran oportunidad de crear cultura preventiva en las familias ante
un desastre mediante la información brindada.
2.3.8 Campo Tecnológico
En el aspecto tecnológico, para fines del 2018 en el Perú se registraron 23.8 millones de
líneas móviles que accedieron a internet (OSIPTEL). El uso de smartphone va en
aumento, por lo cual el uso de una aplicación móvil para la poder reportar riesgos y
desastres será bastante aceptado entre la población, más si es para un bienestar común.
Por otro lado, la manera intuitiva con la cual se podrán enviar los datos y fotos, será
motivo por lo cual cada vez más personas se sumen a querer colaborar con el reporte de
posibles riesgos con los cuales puedan verse afectados ellos o la comunidad.
3 Capítulo III: Planteamiento de la Solución
3.1 Selección de la Solución
3.1.1 Evaluación de la metodología
Se realizó una comparación entre las metodologías para el desarrollo de software RUP y
Cascada. Concluida la comparación, se seleccionó la metodología RUP como la más
adecuada para el presente proyecto, por las características que presenta en cada una de
sus fases. Así mismo, permite realizar un seguimiento y control adecuado de cada uno de
sus artefactos, por lo cual consideramos que es la metodología adecuada para llevar a
cabo el presente proyecto. (Ver F2 - Capítulo 3 Evaluaciones).
3.1.2 Evaluación de la gestión del proyecto
Se realizó una comparación entre tres metodologías ágiles para la gestión del proyecto,
las cuales fueron: Mobile-D, XP y SCRUM, luego de comparar las metodologías, se
decidió usar SCRUM tomando en consideración el tamaño del proyecto, además que nos
24
permite producir entregables de manera incremental y funcional, así como la flexibilidad
para poder trabajar en equipo, llevar un control y tener una mejora continua. Por lo tanto,
consideramos que es la metodología adecuada para este tipo de proyectos. (Ver F2 -
Capítulo 3 Evaluaciones).
3.1.3 Evaluación de la técnica de desarrollo
En la evaluación se realizó la comparación entre las aplicaciones nativas e híbridas, se
tomó la decisión de utilizar una técnica híbrida, por su gran flexibilidad y adaptación a
todas las plataformas que usan los teléfonos móviles, además de su reducido costo y
gran escalabilidad. Por lo cual, consideramos que es adecuada para el tipo de aplicación
que se está proponiendo, ya que muchas personas con dispositivos en distintas
plataformas harán uso de la aplicación. (Ver F2 - Capítulo 3 Evaluaciones).
3.1.4 Evaluación del gestor de base de datos
En la evaluación del gestor de base de datos, se consideraron las bases de datos SQL y
las NoSQL, de las cuales se escogió la base de datos NoSQL por sus gran escalabilidad
y flexibilidad con los datos, además de permitir una adaptación rápida a cualquier
plataforma y su alta disponibilidad con los usuarios finales. Debido a esto, consideramos
que una base de datos NoSQL es la mejor opción para nuestra propuesta. (Ver F2 -
Capítulo 3 Evaluaciones).
3.2 Recursos Necesarios
3.2.1 Metodología
3.2.1.1 Levantamiento de información
En esta etapa se acordó a que expertos se iban a realizar las entrevistas orales,
decidiendo realizarlas a un bombero y un policía, ambos con conocimiento en la atención
y respuesta de riesgos y desastres, se diseñó el cuestionario y se realizaron las
25
coordinaciones con la intendencia nacional de bomberos y la comisaría del distrito de los
olivos, para realizar las entrevistas. Así mismo, se procesó la información obtenida en las
entrevistas, para reforzar la problemática, el alcance y el objetivo de la propuesta bajo el
enfoque de juicio experto de los entrevistados.
Actividad 1: Elaborar cuestionario para las entrevistas
La actividad consiste en la elaboración de preguntas que conforman el cuestionario y que
más adelante son usadas en la entrevista, siendo estas preguntas objetivas para obtener
la información adecuada sobre la atención de riesgos y desastres, situación actual del
país y de las entidades que se ven involucradas en la atención de emergencias producto
de los riesgos y desastres, lo cual nos ayudar a definir la problemática y el alcance del
proyecto.
Entregable:
● Cuestionario para las entrevistas
● Acta de reuniones
Actividad 2: Coordinar fecha y hora de las entrevistas
La actividad consiste en realizar la coordinación de fecha, hora y lugar con las entidades,
para que se lleven a cabo las entrevistas de manera adecuada al bombero y policía,
obteniendo así las citas para las entrevistas.
Entregable:
 Correos de coordinación
Actividad 3: Realizar las entrevistas
26
La actividad consiste en llevar a cabo las entrevistas en la cita pactada en la actividad
anterior con el fin de obtener la información objetiva de acuerdo a las preguntas
realizadas.
Entregable:
● Audio de las entrevistas
● Actas de reunión debidamente llenadas
Actividad 4: Procesar la información producto de las entrevistas
En esta actividad se procede a revisar los apuntes y audios obtenidos producto de las
entrevistas y se plasman en sus documentos respectivos.
Entregable:
● Resumen de las entrevistas
Actividad 5: Analizar la información procesada
La actividad consiste en el análisis de la información rescatada de las entrevistas, de tal
manera que se identifican los problemas que se relacionan con el proyecto y se crea un
alcance de las necesidades a tomar en cuenta al momento de desarrollar el alcance.
Entregable:
 Resultado de las entrevistas
Actividad 6: Buscar proyectos o investigaciones con línea de investigación similar a la de
nuestro proyecto
La actividad consiste en la búsqueda de fuentes con problemáticas similares a nuestro
proyecto con el fin de analizar sus metodologías, resultados y conclusiones.
27
Entregable:
● Carpeta con tesis revisadas
Actividad 7: Elegir los proyectos que guarden relación al nuestro
En esta actividad se escogen las tesis que mejor guarden relación con nuestro proyecto y
nos sirva como punto de inicio de la investigación.
Entregable:
● Resumen de tesis revisadas
3.2.1.2 Sprint 1: Planificación del proyecto
En esta etapa se procede a analizar la información para poder identificar que
requerimientos debe de cumplir el aplicativo. Producto del análisis se elaboran los
diagramas de casos de uso, donde se ven las acciones que se dan al momento que le
usuario interactúa con el aplicativo. También, se lleva a cabo la producción de las
historias de usuario que serán usadas en el desarrollo del aplicativo.
Actividad 8: Realizar el modelo del negocio
En esta actividad se ve el flujo de trabajo que realizará el aplicativo para comunicar las
emergencias registradas por los usuarios y cómo se adapta al proceso de comunicación
actual que poseen las identidades.
Entregables:
● Proceso de comunicación de los bomberos y policías
● Diagrama de proceso del aplicativo
● Reglas del negocio
28
Actividad 9: Elaborar los requisitos para el aplicativo
En esta actividad se definen las necesidades de los usuarios y se plasman mediante los
casos de uso para llevar a cabo el posterior desarrollo de las mismas y estas estén de
acuerdo al alcance del proyecto.
Entregables:
● Gráficos de casos de uso
● Historias de usuario y Product Backlog
Actividad 10: Realizar reunión para el avance del proyecto
La actividad consiste en realizar reuniones con los miembros del equipo para resolver las
incógnitas que se tienen con respecto a lo visto en las actividades anteriores.
Entregable:
Acta de reunión
3.2.1.3 Sprint 2: Diseño del aplicativo
Actividad 11: Analizar los requisitos para el desarrollo del aplicativo
Esta actividad consiste en tener una visión más clara del producto, una visualización de la
base de datos y la arquitectura del aplicativo con el objetivo de tener un escenario más
claro de la implementación del aplicativo.
Entregables:
● Metamodelo NoSQL
29
● Diagrama de clases
● Arquitectura del aplicativo
Actividad 12: Elaborar los mockups del aplicativo
En esta actividad se busca crear prototipos de las interfaces que tendrá el aplicativo con
la distribución de y posición de cada elemento para un mejor entendimiento y producir
una aplicación intuitiva.
Entregables:
● Prototipo de interfaces
incógnitas que se tienen con respecto a lo visto en las actividades anteriores.
Entregable:
 Acta de reunión
3.2.1.4 Sprint 3: Desarrollo del aplicativo
Actividad 14: Desarrollar login y formulario de registro
En esta actividad se desarrolla el login con sus respectivas validaciones, además se crea
el formulario de registro para los usuarios del aplicativo con todos los datos necesarios
para poder reportar una emergencia.
Entregable:
● Ingreso y registro de usuarios funcional
30
Actividad 15: Desarrollar formulario para el registro de la emergencia
En esta actividad se desarrolla el formulario con todos los elementos necesarios para
poder reportar una emergencia: lugar, fecha, tipo de desastre, foto o video.
Entregable:
● Formulario e interface para el reporte de emergencia funcional
Actividad 16: Desarrollar la funcionalidad del mapa con geolocalización
En esta actividad se desarrolla el mapa para el uso de la geolocalización mediante el
GPS del celular y así poder crear una ruta para llegar a la emergencia.
Entregable:
● Mapa de emergencia funcional
Actividad 17: Desarrollo de la interfaz de recepción de las emergencias
En esta actividad se desarrolla la interfaz del aplicativo que enlista todas las emergencias
reportadas y muestra los detalles de la emergencia.
Entregable:
● Ventana de lista de emergencia funcional
Actividad 18: Desarrollo de interfaz para los detalles de emergencia
En esta actividad se desarrolla la interface para poder observar los detalles y el estado de
cada emergencia, así como la vista de un mapa con el cual se puede ver la ruta hasta la
emergencia.
Entregable:
31
● Ventana de detalles de emergencia funcional
incógnitas que se tienen con respecto a lo visto en las actividades anteriores
3.2.1.5 Sprint 4: Funcionalidad del aplicativo
Actividad 20: Realizar testing
En esta actividad se realiza el testing para comprobar y verificar que los requerimientos
de los usuarios se hayan cumplido.
Actividad 21: Realizar pruebas de integración
En esta actividad se realiza la prueba de integración para verificar que la información siga
el flujo correspondiente según lo visto en los procesos.
Actividad 22: Realizar prueba de estrés
En esta actividad se realiza la prueba de estrés para verificar la capacidad de
procesamiento y el rendimiento adecuado del aplicativo.
3.2.1.6 Sprint 5: Implementación del aplicativo
Actividad 24: Cargar el aplicativo a las tiendas virtuales
En esta actividad se sube el aplicativo a las tiendas virtuales para que estén disponibles
para los usuarios finales y puedan descargarlo.
32
Actividad 25: Realizar manual de usuario
En esta actividad se realiza el manual de usuario con el cual se explica detalladamente el
correcto uso del aplicativo para reportar emergencias, los tipos de emergencias y la
manera correcta de clasificarlas.
Entregable:
● Manual de usuario.
Actividad 26: Realizar capacitación a los usuarios
En esta actividad se lleva a cabo una reunión con los usuarios finales que atenderán las
emergencias para que puedan obtener la información pertinente de cada emergencia
reporta y puedan atenderla.
Entregable:
● Documento de acta de capacitación
3.2.2 Herramientas
a) Draw.io
Nos va permitir elaborar diagramas de caso de uso, nos permite compartir y editar con los
usuarios del proyecto. Además, es sin costo y este será utilizado para el proyecto de
investigación.
33
b) Marvel App
Es una aplicación web que permite agregar interactividad a los prototipos y discutir en
línea mediante notas y comentarios. Estos elementos interactivos no solo nos permiten
tener una idea más clara de cómo funcionará el proyecto, sino que también ayudan al
cliente final a visualizar una experiencia de uso y navegación del resultado final.
c) Bizagi
Nos permite realizar los diagramas de los procesos de manera ordena y de fácil
entendimiento para plasmar adecuadamente los procesos que se llevan a cabo dentro del
flujo de información del aplicativo.
d) Técnica de juicio de experto
Es un método de validación para la fiabilidad de la investigación que consiste en tener la
opinión informada de personas, que son reconocidos como expertos por sus
conocimientos y trayectoria. De esta manera, pueden proporcionar opiniones,
información, brindar juicio y valoraciones.
e) Eclipse
Nos permite realizar distintos diagramas, en la presente investigación se usó para realizar
el esquema del metamodelo de la base de datos NoSQL. Además, es un software que
tiene versiones sin costo.
34
3.2.3 Cronograma
3.3 Estudio de viabilidad
3.3.1 Viabilidad operativa
En el presente trabajo de investigación se realizará solo una propuesta de diseño del
aplicativo, mostrando los esquemas, diagramas y prototipos del aplicativo, así como la
elección de la técnica de desarrollo para una aplicación híbrida y el uso de una base de
datos NoSQL.
3.3.2 Viabilidad técnica
En el presente trabajo de investigación se realizaron evaluó las metodologías, técnicas,
herramientas de gestión y desarrollo, siendo estos de libre uso y de tendencia en el
desarrollo actual de aplicaciones móviles.
35
4 Capítulo IV: Análisis de los resultados de la investigación
El siguiente cuadro muestra los entregables que se consiguieron en cada uno de las
etapas y actividades del proyecto. Así mismo, se muestra el antecesor, predecesor de
cada una de las actividades y el tiempo que tomó desarrollarlas.
Con la ayuda de este cuadro, se puede ver como se relacionan los entregables, cuales
dependen de otros y cuales hacen posible a otros para poder llegar al objetivo del
proyecto.
36
4.1 Levantamiento de la información
Se detallan las actividades y el proceso de recolección de información que se realizó,
esto incluye la elaboración de los cuestionarios, coordinación, realización y análisis de las
entrevistas. Además de la búsqueda de proyectos o investigaciones similares que sean
útiles para nuestra línea de investigación.
4.1.1 Actividad: Elaborar documentos para las entrevistas
Se elaboró un cuestionario con preguntas abiertas, que fue usado en entrevistas orales a
un bombero y un policía, que permitieron a los entrevistados explayarse en sus
respuestas y que permitieron obtener la mayor cantidad de información en temas de la
atención de emergencias de acuerdo a sus conocimientos y experiencias.
4.1.1.1 Cuestionario para las entrevistas
Una de las herramientas que se usó para el levantamiento de información fue el
cuestionario, el cual permite a los entrevistados responder a las preguntas abiertamente y
explayarse en sus respuestas para obtener información necesaria del tema a tratar. En el
presente proyecto se elaboró un cuestionario de once preguntas abiertas, las cuales nos
sirvieron para obtener información sobre el reporte y proceso de atención de emergencias
en el Perú. Además, conocer la situación actual en la que se encuentran los sistemas y
canales de comunicación que son usados para el reporte riesgos o emergencias,
prevención y alerta ante desastres que usan los policías y bomberos.
37
Ilustración 1: Cuestionario para las entrevistas
Con el cuestionario elaborado pudimos empezar a realizar las coordinaciones con las
entidades correspondientes para poder concretar las reuniones con un representante del
cuerpo de bomberos del Perú y policía nacional del Perú encargados de la atención de
riesgos o emergencias, este cuestionario fue usado para realizar las entrevistas y lograr
una mejor propuesta de diseño de aplicativo móvil.
4.1.1.2 Acta de reuniones
Las actas de reuniones son una prueba de la realización y conformidad de las reuniones
llevadas, mostrando los participantes, asistentes y objetivos de la reunión. Se elaboró un
acta de reuniones que se usó en las entrevistas para dar conformidad que se llevaron a
38
cabo y autenticidad de la información obtenida de las entrevistas realizadas a los expertos
en materia de riesgos, desastres y emergencias.
Ilustración 2: Acta de Reunión con los expertos
El acta de reuniones nos permitió demostrar la veracidad de las entrevistas, lo cual
respalda la información obtenida sobre los temas de reporte de riesgos y desastres. De
esta manera, se obtuvo el documento que nos sirvió para concluir la entrevista con los
policías y bomberos.
En esta actividad se obtuvieron los documentos necesarios para poder realizar las
entrevistas y dar fe de la autenticidad de las entrevistas, que sirvieron para una mejor
visión de la problemática de nuestra propuesta de diseño.
39
4.1.2 Actividad: Coordinar por correo fecha y hora de las entrevistas
Para nuestro proyecto, se realizaron las coordinaciones de fechas y horas con las
personas que fueron entrevistadas, para poder llevar a cabo las entrevistas de la manera
más adecuada y que no interfiera con las actividades ni responsabilidades de los
entrevistados en su centro de trabajo.
4.1.2.1 Correos de coordinación
El correo electrónico es un medio de comunicación, por el cual se pueden enviar y recibir
mensajes o cartas digitales. Los correos electrónicos nos permitieron coordinador las
fechas y horas en las que pudimos realizar las entrevistas a los expertos en materia de
atención desastres y emergencias de los bomberos y policía.
Ilustración 3: Correos para la coordinación de las entrevistas
La coordinación por correo nos permitió concretar las fechas en las cuales se llevaron a
cabo las entrevistas con el bombero y policía, las cuales quedaron plasmada en audio
con la opinión de los expertos en temas de atención de emergencias y se llenaron las
actas de reunión. Con las reuniones pactadas, pudimos realizar las entrevistas y obtener
más información para hacer un mejor diseño de nuestra investigación.
40
4.1.3 Actividad: Realizar las entrevistas
En esta actividad se llevaron a cabo las entrevistas coordinadas previamente, se llenaron
las actas para dar veracidad que se llevaron de manera adecuada, estas entrevistas
fueron orales y usando las preguntas de opinión abierta que previamente elaboramos.
Además, las entrevistas fueron grabadas, posteriormente procesadas y analizadas.
4.1.3.1 Audios de las entrevistas
Los audios son una evidencia completa de lo que se grabe, en nuestro caso las entrevistas,
las cuales fueron grabadas y se capturó toda la información que los entrevistados nos
proporcionaron y luego volver a revisarla para resumir y analizar todos los detalles.
Ilustración 4: Audio de las entrevistas realizadas
Las grabaciones nos permitieron revisar el contenido de las entrevistas y extraer todos
los detalles, pudiendo así conseguir datos más precisos, un posteriormente nos
permitieron realizar un resumen y análisis adecuado de las necesidades para el diseño
del aplicativo.
4.1.3.2 Actas de reuniones debidamente llenadas digitalizados
Las actas de reunión fueron producto de las entrevistas y nos sirvieron para dar fe de la
correcta realización de las entrevistas y veracidad de los entrevistados.
41
Ilustración 5: Acta de reunión con el bombero
42
Ilustración 6: Acta de reunión con el policía
Las actas de reunión nos permitieron dar veracidad a toda la información obtenida de las
entrevistas y que podemos usar para el diseño de nuestro aplicativo.
Esta actividad contiene las evidencias del desarrollo de las entrevistas, con las cuales
pudimos obtener datos para ser analizados que posteriormente los usamos para la
planificación y diseño del aplicativo.
43
4.1.4 Actividad: Procesar la información producto de las entrevistas
En esta actividad procesamos los datos obtenidos de las entrevistas con la intención de
crear resúmenes con la información pertinente de cada entrevista.
4.1.4.1 Resumen de las entrevistas
El resumen de las entrevistas es la reducción de mucha información, obteniendo los
datos pertinente sin desviarse de las ideas principales. El resumen de las entrevistas fue
realizado con las anotaciones que se hicieron al momento de realizar las entrevistas y
con ayuda de la revisión de los audios, de tal manera que se logró una respuesta concisa
y con información pertinente para cada pregunta.
44
Ilustración 7: Referencia de una entrevista digitalizada a un bombero
45
Ilustración 8: referencial de una entrevista digitaliza a un policía
El resumen de las entrevistas nos permitió tener un panorama más claro del resultado de
la entrevista, siendo objetivos pudimos tener más clara la problemática y el alcance del
proyecto, reconocer las necesidades que posteriormente fueron analizadas para la
creación de las requerimientos e historias de usuarios.
46
Esta actividad nos proporcionó el resumen objetivo con el cual se planteó una solución
óptima a los problemas observados, así como su correcta funcionalidad e integración a
los sistemas actuales.
4.1.5 Actividad: Analizar la información procesada
El análisis de la información procesada producto de cada entrevista, se realizó a cada
pregunta obteniendo una única respuesta, combinando las respuestas a cada pregunta
desde el punto de vista de cada entrevistado.
4.1.5.1 Resultado de las entrevistas
El resultado de las entrevistas son las ideas concretas y bien definidas que los
entrevistados transmitieron durante las entrevistas en cada una de las preguntas. El
resultado de las entrevistas se plasmó en documentos, los cuales contienen los datos
mas relevantes de cada entrevista, esto se realizó con la ayuda de los resumene de la
actividad anterior y con la intención de conocer las necesidades mutuas de cada entidad.
47
48
Ilustración 9: Análisis de entrevistas
El análisis de la información procesada nos permitió obtener un resumen de las
entrevistas realizadas de acuerdo a cada pregunta hecha, de esta manera se pudo
obtener coincidencias entre ambos entrevistados para concretar necesidades, carencias
y definir de mejor manera los problemas a resolver en nuestro diseño. Siendo útil toda
esta información para diseñar los procesos del aplicativo, las reglas del negocio, los
casos de uso y las historias de usuario que se desarrollaron en el sprint 1.
La actividad nos permitió conocer las necesidades comunes de las entidades, policiales y
bomberos, con las cuales se desarrollaron las historias de usuario para el diseño del
proyecto.
4.1.6 Actividad: Buscar proyectos o investigaciones con línea de investigación similar a
la de nuestro proyecto
La actividad buscó realizar la investigación de fuentes de información similares con la
línea de investigación para tener una base y conocimiento de las investigaciones ya
realizadas relacionadas con nuestro proyecto.
49
4.1.6.1 Carpeta con tesis revisadas
La carpeta con las tesis revisadas se encuentra en el OneDrive, es la carpeta que
contiene las tesis y proyectos que revisamos para realizar el marco teórico y tener
conocimiento de las investigaciones similares y que resultados obtuvieron
Ilustración 10: Carpeta con las tesis revisadas
La carpeta contenida en el F1, contiene todas las tesis consultadas para nuestro marco
teórico, luego de encontrar proyectos similares al nuestro se pudo realizar los resúmenes
correspondientes de aquellos trabajos que guardan mayor relación con el nuestro, y así
pudimos tener un estado del arte con mayor sustento y mas enfocado para conseguir
nuestro objetivo.
4.1.7 Actividad: Elegir los proyectos que guarden relación al nuestro
La actividad consistió en realizar un resumen de las tesis que consideramos más
adecuadas y las que nos sirvieron para tener una buena base teórica de nuestra línea de
investigación.
4.1.7.1 Documento Resumen de tesis revisadas
El documento contiene las tesis que consideramos más adecuadas a nuestra línea de
investigación de nuestro proyecto, reconociendo la metodología, resultados y
conclusiones a las cuales llegaron.
50
Ilustración 11: Documento del resumen de tesis revisadas
La carpeta F1 - Tesis revisadas, contiene el procesamiento de las tesis consultadas para
poder llevar a cabo el desarrollo del marco teórico, de este documento se seleccionaron
las que mejor se relacionan a nuestra problemática. Siendo útil toda esta información
para diseñar los procesos del aplicativo, las reglas del negocio, los casos de uso y las
historias de usuario que se desarrollaron en el sprint 1.
En esta actividad se evidencia los documentos revisados para el desarrollo del marco
teórico en base a trabajos que se relacionan a nuestro proyecto, pudiendo así reconocer
que diseño y necesidades a cumplir debe de tener nuestra propuesta.
En esta etapa se lleva a cabo el trabajo de campo, en el cual se pudo obtener la opinión
de expertos y rescatar la información de trabajos relacionados al nuestro para poder
hacer plantear un objetivo, alcance y solución de acuerdo a la situación actual.
4.2 Sprint 1: Planificación del proyecto
La planificación del proyecto es el proceso inicial para definir las bases del aplicativo
móvil para reportar desastres y riesgos. Esta etapa analiza la información obtenida de las
entrevistas y los proyectos de investigación revisados anteriormente para obtener el
proceso de llamada de emergencia, el proceso del aplicativo, los diagramas de casos de
uso y definir las reuniones que se deben llevar a cabo. Asimismo, esta etapa servió para
el diseño del aplicativo según la necesidades y requerimientos que se encuentren en esta
etapa.
51
4.2.1 Actividad: Realizar el modelo del negocio
El modelado de negocio es una técnica que permite diagramar el funcionamiento del
negocio. Este diagrama nos dio una perspectiva general de las actividades, personal y
recursos necesarios en el proceso de llamado de emergencia.
4.2.1.1 Mapa de procesos de una emergencia
El mapa de procesos es un diagrama que representa la estructura y la interrelación de los
procesos de un negocio. Este entregable sirvió para definir las actividades involucradas
en el proceso de llamada de emergencia que reciben las entidades policías y de
bomberos por parte de los ciudadanos al momento de percibir un riesgo o desastre. Para
obtener el mapa de procesos se necesitó el resultado de las entrevistas y el resumen de
la información revisada de los proyectos similares al nuestro.
Ilustración 12: Proceso de llamada de emergencia a la policía o bomberos
El proceso muestra el flujo que sigue el proceso de una llamada de emergencia que se
da cuando una persona realiza una llamada para reportar una emergencia. Empezando
por el destinatario de la llamada, que pueden ser: la policía, los bomberos o la
municipalidad. Luego, la llamada es recibida por el call center y alguno de los
52
trabajadores se encarga de tomar los detalles de la emergencia y posteriormente se
ponen en contacto con las entidades que son necesarias para la atención de dicha
emergencia. Este entregable es necesario para diagramar el proceso del aplicativo móvil.
4.2.1.2 Diagrama de proceso del aplicativo
El diagrama de flujo es una herramienta que representa la secuencia e interrelación de
las actividades y los procesos. El flujograma sirvió para representar el funcionamiento de
aplicativo móvil para reportar riesgos y desastres. Para realizar este entregable fue
necesario analizar los resultados de las entrevistas y las tesis relacionadas a nuestra
temática. A continuación, se describe y representa cada uno de los flujogramas que
representan nuestro aplicativo del aplicativo móvil.
El primer flujograma representa el registro del usuario en el aplicativo. Su objetivo es
definir los pasos que debe seguir el usuario al registrarse en el aplicativo. Para ello el
usuario tiene que seguir los siguientes pasos: abrir el aplicativo, darle clic al registrarme,
llenar el formulario, enviar el formulario y verificar la cuenta con el correo electrónico y el
login. Este sirve para obtener información del usuario del usuario y definir el ingreso al
aplicativo móvil.
Ilustración 13: Diagrama de proceso de registro de usuario
53
El segundo flujograma representa el registro de un riesgo o desastre en el aplicativo y el
envió de este a la entidad encargada de atender emergencia. Su objetivo es definir qué
pasos el usuario debe realizar para registrar un desastre. Los pasos son los siguientes:
inicia sesión, ingresa al registro de riesgos o desastres, completa el formulario con lugar,
foto y descripción, envía formulario y se emite una alerta a las entidades encargadas de
atender emergencias, las entidades atienden las emergencias y dan un check de
conformidad de emergencia atendida. Por otro lado, las personas encargadas de atender
emergencias pueden visualizar en sus teléfonos las emergencias más cercanas. De este
modo, se diseñó el flujo inicial de nuestra propuesta.
Ilustración 14: Diagrama de proceso de registro de riesgos o desastres
El tercer flujograma representa el proceso de atención de una emergencia recibida por
medio del aplicativo. Este flujo sirvió para definir pasos que debe realizar las personas
encargadas de atender emergencias. Los pasos son los siguientes: abrir el aplicativo,
54
iniciar sesión, ver la lista de desastres notificados, atender la emergencia y cambiar el
estado de la emergencia.
Ilustración 15: Diagrama de atención de emergencia
El conjunto de todos estos diagramas de procesos nos permite tener un escenario más
claro del flujo de la información y las acciones de las personas involucradas en estos
procesos. Asimismo, los diagramas de flujo mostrados sirvieron para definir las reglas del
negocio.
4.2.1.3 Reglas del negocio
Las reglas de negocio son policías, normas o reglamentos que representan a una
organización o negocio y rigen lo que se debe hacer. Estas normas se obtuvieron a partir
del análisis previo de las entrevistas, las investigaciones y los diagramas de procesos
presentados en la actividad anterior. A continuación, se muestran las reglas de negocio
de este aplicativo para reportar desastres y riesgos:
- El usuario debe de registrarse con sus datos personales.
- El usuario debe de ingresar sus credenciales para poder realizar los reportes.
55
- El usuario debe de leer los manuales para aprender a reconocer y saber cómo realizar
los reportes.
- El usuario realiza los reportes de los riesgos o emergencia proporcionando la mayor
cantidad de detalles posibles.
- El usuario receptor que se encuentra del lado las entidades reciben las alertas y son los
encargados de atender las alertas en el menor tiempo posible y utilizando el equipo
adecuado de acuerdo a la información recibida.
- El usuario receptor de las entidades se encarga de actualizar los estados de las
emergencias y comunicar al usuario que reportó la emergencia ha sido bien recibida.
Las reglas del negocio definen las actividades y responsabilidades de cada uno de los
involucrados en el uso del aplicativo, con lo cual se consigue un mejor diseño de nuestro
aplicativo en lo que se refiere a las restricciones y a las obligaciones de cada usuario. Por
otro lado, estas reglas negocio sirvieron para definir los requisitos del aplicativo móvil.
4.2.2 Actividad: Elaborar los requisitos para el aplicativo
Los requisitos del aplicativo son las necesidades de los usuarios que son transformadas
en funcionalidad y contenido del aplicativo. Estos requisitos sirvieron para elaborar el
diseño y desarrollo del aplicativo. Para su elaboración, se necesitó el análisis de la
información de las entrevistas, el resumen de las tesis relacionadas a nuestra temática y
los diagramas del modelo de negocio realizados en la anterior actividad. En esta actividad
se realizaron los casos de uso, historias de usuario y product backlog correspondientes
para poder realizar el diseño de la planificación de las partes a ser desarrolladas y
entregadas en cada uno de los sprints.
56
4.2.2.1 Gráficos de casos de uso
Los diagramas de casos de uso son una guía para el desarrollo y el testeo del aplicativo
móvil. Estos diagramas especifican la funcionalidad y el diseño de la aplicación según los
requerimientos planteados por los ciudadanos y el personal de emergencia. Estos
diagramas se obtuvieron del análisis previo de la información de las entrevistas, las
investigaciones y las reglas de negocio.
a. Diagrama de caso de uso para el ciudadano
El propósito de los casos de uso para el ciudadano son describir las acciones que
puede realizar, como verificar que el usuario tenga una cuenta registrada
previamente con sus datos personales, poder registrar una emergencia y
visualizar una lista de emergencias.
La siguiente ilustración representa la acción de poder iniciar una sesión o cerrarla,
previa verificación una cuenta existente, todo esto mediante la interfaz login del
aplicativo.
Ilustración 16: CDU/ Ciudadano- Módulo Login
La siguiente imagen muestra la acción de registrar un usuario en el aplicativo
móvil validando que un ciudadano no tenga más de una cuenta.
57
Ilustración 17: CDU / Ciudadano – Módulo Usuario
La siguiente imagen muestra la acción registrar una emergencia solicitando los
siguientes datos obligatorios: Localización, archivos multimedia y descripción de la
emergencia.
Ilustración 18: CDU/ Ciudadano – Modulo Registrar Emergencia
La ilustración muestra la acción de visualizar las emergencias registradas por
otros usuarios. La finalidad del módulo es mantener informada a la ciudadanía
sobre las emergencias.
58
Ilustración 19: CDU/ Ciudadano – Modulo Visualizar emergencia
B. Diagrama de casos de uso del Personal de emergencias
El propósito de los casos de uso para el personal de emergencias es describir las
acciones que puede realizar, como recibir las notificaciones de las emergencias
más cercanas a su localización y poder cambiar de estado la emergencia.
Se grafica la acción de la verificación y validación de una cuenta del personal de
emergencia. Dentro del personal de emergencia se encuentran: los bomberos, la
policía nacional del Perú, las municipalidades y los hospitales.
Ilustración 20: CDU/ Personal de Emergencia – Módulo Login
59
El gráfico muestra la acción registrar personal de emergencia en el aplicativo
móvil. El sistema valida los datos registrados.
Ilustración 21: CDU / Personal de Emergencia – Módulo Usuario
La siguiente imagen muestra la acción de notificar y cambiar de estado de una
emergencia.
Ilustración 22: CDU/ Personal de Emergencia- Módulo emergencia
Los casos de uso tienen gran importancia en el desarrollo del proyecto puesto que nos
permitieron describir las acciones que puede realizar cada actor del sistema al momento
de hacer uso del aplicativo móvil.
60
4.2.2.2 Historias de usuario y Product Backlog
Las historias de usuario son la descripción escrita sobre los requerimientos del usuario
relacionados hacia el aplicativo. Estas son usadas en la metodología agiles como Scrum.
Para obtener las historias de usuario se analizó las entrevistas, las tesis y el modelo de
negocio del aplicativo. A continuación, se listan las historias de usuario en la siguiente
tabla:
ENUNCIADO DE LA HISTORIA
IDENTIFI ROL CARACTERÍSTIC RAZÓN O RESULTADO
CADOR AO
DE LA FUNCIONALIDAD
HISTORI
1 como Puedo visualizar Con la finalidad de inspeccionar
administrado los usuarios que el usuario utilice la aplicación
r suscritos a la adecuadamente
aplicación y
bloquear a aquellos
usuarios que
cometan faltas o
penalidades en la
aplicación
2 como Puedo visualizar la Con la finalidad de conocer el lugar
administrado lista de las y el tipo de emergencia más
r emergencias y los frecuente. A partir de ello poder
tomar decisiones.
61
reportes de las
emergencias
3 como Necesito Con la finalidad de regístrame de
ciudadano registrarme en la forma segura, evitando que otros
aplicación móvil ciudadanos se registren 2 veces en
indicando mis el aplicativo
datos personales:
Nombres, DNI,
teléfono, dirección,
contraseña
4 como Necesito registrar Con la finalidad de registrar una
ciudadano una emergencia emergencia rápidamente y
enviando un salvaguardar la vida de las
archivo multimedia, personas
una descripción y
mi localización
5 como Necesito conocer con la finalidad de saber si mis
ciudadano de otras familiares, personas cercanas o yo
emergencias me encuentro en un lugar seguro
registradas en el
aplicativo
6 como Necesito con la finalidad de registrarme
personal de registrarme en la seguramente en el aplicativo y de
atención de aplicación móvil que se compruebe que soy parte
emergencia indicando mis del personal de atención de
datos personales: emergencias
62
Nombres, DNI,
teléfono, dirección,
cargo, contraseña
7 como Necesito recibir con la finalidad de atender la
personal de notificaciones emergencia rápidamente
atención de sobre las
emergencia emergencias
cercanas a mi
localización
8 como necesito notificar con la finalidad de indicar que la
personal de que atendí una emergencia fue atendida y evitar
atención de emergencia que otro miembro redunde la
emergencia emergencia ya atendida
Tabla 1: Historias de usuario del aplicativo móvil
En la siguiente tabla se especifican los roles, funciones y detalles importantes de las
historias de usuario. Esta tabla se desarrolla con el propósito de estimar el tiempo de
desarrollo de cada Historias de Usuario y categorizar su relevancia para el proyecto.
Identifica
dor (ID) Dimensión Iteraci Priori

Enunciado de la historia Alias Estado
de la /Extensión ón dad
historia
1 Como administrador, A1 en 3 días si alta
puedo visualizar los proceso
usuarios suscritos a la
aplicación y bloquear a
63
aquellos usuarios que
cometan faltas o
penalidades en la
aplicación, con la
finalidad de inspeccionar
que el usuario utilice la
aplicación
adecuadamente
2 como administrador, A2 en 6 días si alta
puedo visualizar la lista proceso
de las emergencias y los
reportes de las
emergencias, Con la
finalidad de conocer el
lugar y el tipo de
emergencia más
frecuente. A partir de ello
poder tomar decisiones.
3 Como ciudadano, A3 en 2 días si alta
necesito registrarme en proceso
la aplicación móvil
indicando mis datos
personales: Nombres,
DNI, teléfono, dirección,
contraseña, con la
finalidad de registrarme
de forma segura,
64
evitando que otros
ciudadanos se registren
2 veces en el aplicativo
necesito registrar una proceso
emergencia enviando un
archivo multimedia, una
descripción y mi
localización, con la
finalidad de registrar una
emergencia rápidamente
y salvaguardar la vida de
las personas
necesito conocer de proceso
otras emergencias
registradas en el
aplicativo, con la finalidad
de saber si mis
familiares, personas
cercanas o yo me
encuentro en un lugar
seguro
65
6 Como personal de A6 en 3 días si alta
atención de proceso
emergencias, necesito
registrarme en la
aplicación móvil
indicando mis datos
personales: Nombres,
DNI, teléfono, dirección,
cargo, contraseña, con la
finalidad de registrarme
seguramente en el
aplicativo y de que se
compruebe que soy parte
del personal de atención
de emergencias
recibir notificaciones
sobre las emergencias
cercanas a mi
localización, con la
finalidad de atender la
emergencia rápidamente
66
notificar que atendí una
emergencia, con la
finalidad indicar que la
emergencia fue atendida
y evitar que otro miembro
redundé la emergencia
ya atendida
Tabla 2: Product Backlog
Esta etapa nos permitió saber los requisitos, de acuerdo a los problemas y necesidades
encontradas, para el desarrollo del diseño del aplicativo y las funciones que tendrá cada
uno de los involucrados al momento de usar el aplicativo. Estos entregables son base
para la etapa diseño.
4.2.3 Actividad: Realizar reunión para el avance del proyecto
Las reuniones de proyecto son una herramienta para gestionar la información sobre el
desarrollo de un proyecto. El objetivo de esta reunión fue presentar los siguientes
entregables: mapa de procesos del llamado de emergencia, diagrama del proceso del
aplicativo, reglas del negocio, diagramas de casos de uso, historias de usuario y producto
backlog. Asimismo, en esta reunión se coordinó las nuevas actividades para la fase de
diseño.
67
4.2.3.1 Acta de reunión
Ilustración 23: Acta de reunión 1
El acta de reuniones nos permitió alinear nuestros resultados, revisión de los entregables
y la coordinación de cambios y futuras entregas.
68
4.3 Sprint 2: Diseño del aplicativo
El diseño del aplicativo es la etapa en donde se define el aspecto interno y externo del
aplicativo. Para esta etapa se desarrolló el esquema de base de datos NoSQL, diagrama
de clases y la arquitectura de la aplicación. La finalidad de estos diagramas fue describir
la estructura y los componentes necesarios para el desarrollo del aplicativo móvil de
atención de emergencias. Estos diagramas servirían para la etapa de desarrollo del
aplicativo móvil.
4.3.1 Actividad: Analizar los requisitos para el desarrollo del aplicativo
Para el correcto desarrollo del aplicativo, es importante tener en claro los requisitos, estos
fueron plasmados en esquemas y diagramas para su correcto entendimiento, tomando en
cuenta los casos de uso e historias de usuario.
4.3.1.1 Metamodelo NoSQL
La base de datos NoSQL son gestores de bases de datos no relacionales, en otras
palabras, los datos no se estructuran en tablas y no permiten consultas SQL para buscar
información. Estas tienen su propia nomenclatura para realizar consultas NoSQL. Las
bases de datos NoSQL se caracterizan por ser muy flexibles y escalables. Ideales para
aquellas aplicaciones que requieran gran cantidad de recursos. Estas bases de datos no
tienen esquemas estandarizados como las bases de datos SQL.
Este grafico se obtuvo de las historias de usuario, producto backlog y casos de uso. A
continuación, se muestra el metamodelo NoSQL, con cada una de las entidades que
producen los nodos o documentos con cada registro de parte de los usuarios.
69
Ilustración 24: Metamodelo NoSQL
Las Bases de datos NoSQL fue elegida para ser utilizada en este proyecto, ya que el
aplicativo requiere alta escalabilidad, disponibilidad y flexibilidad. Asimismo, este
entregable sirvió para realizar el diagrama de clases del aplicativo
4.3.1.2 Diagrama de clases
El diagrama de clases es tipo de diagrama de UML que contiene todas clases, atributos y
métodos que se deben de crear al momento de desarrollar el aplicativo, de acuerdo con
las necesidades identificadas de los usuarios vistas en todo el marco de la investigación.
Para desarrollar este diagrama se analizó la información de las historias de usuario y los
casos de uso desarrollados en la etapa de planificación. A continuación, se muestra el
diagrama de clases:
70
Ilustración 25: Diagrama de clases
Este diagrama nos permite definir la estructura interna de nuestro aplicativo como la
relación entre objetos, métodos y atributos. Este entregable serviría para la construcción
del aplicativo móvil y para elaborar la estructura MVC modelo, vista y controlador.
71
4.3.1.3 Arquitectura del aplicativo
La arquitectura del aplicativo define las aplicaciones externas que necesita integrar para
su funcionamiento. Esta arquitectura permitió tener un plan general del aplicativo,
mostrando en un gráfico los actores, conexión e integración de los componentes
involucrados. Para desarrollar este diagrama se necesitó el diagrama de clases y la base
de datos NoSQL para comprender el mecanismo técnico del aplicativo.
Ilustración 26: Arquitectura del aplicativo
Esta actividad nos proporcionó un alcance más definido para el diseño del aplicativo, así
como para su desarrollo, mostrando los atributos necesarios, así como las conexiones
que tendrá para su correcto funcionamiento. Este diagrama serviría para el despliegue de
la aplicación en los servidores.
4.3.2 Actividad: Elaborar los mockups del aplicativo
Un mockup es un prototipo, maqueta, vista o aspecto que representa funcionamiento de
un producto o servicio. Es usado para simular el funcionamiento. Con este se valida si se
72
está desarrollando un aplicativo que satisface las necesidades de los usuarios y si está
resolviendo la problemática abarcada. Para llevar a cabo la elaboración de los mockups
se analizó la información del levantamiento del problema, el modelo de negocio y los
requisitos del aplicativo. A partir de ello, se creó las interfaces que represente de mejor
manera el aplicativo y como se navegaría de interfaz en interfaz, así como las acciones
que se pueden realizar en cada una de ellas.
4.3.2.1 Prototipo de interfaces
Se desarrolló el diseño de las interfaces en el programa Marvel app. Estas interfaces se
elaboraron bajo los requerimientos descritos en las historias de usuario y las entrevistas
realizadas a los expertos en la atención de emergencias, como son bombero y policía. El
prototipado de la aplicación sirve para describir gráficamente como el aplicativo móvil
debe ser construido y cuáles son sus funcionabilidades.
En esta interfaz diseñamos el formulario registro del usuario con los siguientes datos:
Nombre, Apellidos, DNI, Teléfono, Email, Contraseña y foto. Estos datos fueron
seleccionados por que validan que una persona existe, mediante su documento de DNI o
algún documento de identidad para las personas extranjeras. Asimismo, si alguna
persona comete una penalidad, esta será identificada y sancionada mediante estos
datos. Por otro lado, el documento de identidad valida que los usuarios no tengan más de
una cuenta en la aplicación.
73
Ilustración 27: Prototipo del registro del usuario
En la interfaz login de usuario pusimos los parámetros de ingreso: correo y contraseña.
Estos datos de ingresos fueron seleccionados porque son datos únicos que identifican a
cada usuario. Por otra parte, el usuario tiene la opción de recuperar su contraseña
mediante envió de un código a su correo. Asimismo, la interfaz valida que el usuario
tenga una cuenta y que los datos de ingreso sean los correctos.
74
Ilustración 28: Prototipo login de usuario
La siguiente interfaz es un menú de opciones desplegable donde pusimos 6 opciones
para el ciudadano: Registrar emergencia, Noticias, Editar Perfil, Notificaciones, Guía de
usuario y Cerrar Sesión. Cada una de estas opciones direcciona a diferentes interfaces,
excepto la opción cerrar sesión. Esta opción se encarga de cerrar la cuenta de usuario y
enviarlo al login de usuario.
75
Ilustración 29: Prototipo Menú de opciones de usuario
Esta interfaz la diseñamos en base a las emergencias que más se reportan en nuestro
país: Accidentes de tránsito, Incendios Urbanos, Incendios Forestales, Derrumbe,
Inundación y otras Emergencias. Esta clasificación permite que el programa mande la
alerta registrada a la entidad correspondiente y que esta tome las medidas más
adecuadas.
76
Ilustración 30: Prototipo categoría de emergencia
La siguiente interfaz la diseñamos para obtener la localización de las emergencias. Un
usuario puede reportar una emergencia en su misma localización o en la otra dirección.
Por otro lado, varios usuarios pueden reportar una emergencia en la misma localización.
La interfaz mapa de emergencia permite al usuario registrar una emergencia en una
localización muy precisa, lo cual ayuda al personal de atención de emergencia identificar
el lugar.
77
Ilustración 31: Prototipo mapa de emergencias
En la interfaz detalle de emergencia pusimos como parámetros de ingreso título,
descripción y foto o video porque estos datos permiten al personal de atención de
emergencias entender cómo se está dando la situación, que recursos necesarios llevar y
que acciones tomar. Asimismo, todos los datos de ingreso son obligatorios porque
requieren la máxima evidencia posible para que se puedan tomar acción antes la
emergencia registrada. En esta interfaz se solicita una foto para poder visualizar la
situación de la emergencia y el personal encargado de atender estas emergencias como
son los policías, bomberos, hospitales o INDECI pueda tomar acciones.
78
Ilustración 32: Prototipo Detalle de Emergencia
Esta interfaz la diseñamos en base a los requerimientos de las entrevistas realizadas. Los
ciudadanos necesitan un apartado para informarse acerca de los sucesos actuales, bien
sean desastres causados por el hombre o por la naturaleza. Por ello colocamos la interfaz
Noticias. Esta interfaz lista todas las noticias publicadas por las entidades que atiendes
emergencias como: La central de bomberos, la policía nacional del Perú, Hospitales
públicos o privados, INDECI. Los datos de ingreso en esta interfaz son: comentarios y
reacciones. Los datos de ingreso no son obligatorios son alternativos.
79
Ilustración 33: Prototipo Noticias
La interfaz editar perfil la diseñamos para que el usuario puede actualizar sus datos
personales registrados al crear su cuenta. Los datos que pueden ser actualizados son:
Nombre, Apellidos, Teléfono, Email y contraseña. Por otro lado, el DNI no aparece en esta
pantalla porque no puede ser cambiado.
80
Ilustración 34: Prototipo Editar perfil
Diseñamos un menú desplegable para el personal que atiende emergencias porque ellos
realizarían otras funciones en la aplicación como mantener informada a la población sobre
las situaciones de emergencia, fomentar la concientización, prevenir a la población, tener
información sobre las emergencias y atenderlas. Por ello, en esta interfaz se colocan las
siguientes opciones: Registrar Noticias, Ver Emergencias, Notificaciones, Guía de usuario
y cerrar sesión.
81
Ilustración 35: Prototipo menú desplegable para el personal de atención de emergencias
Colocamos la interfaz registrar noticia porque en base a las entrevistas realizadas a los
expertos (policía y bombero) solicitaban estar más conectados con los ciudadanos para
concientizarlos, prevenirlos e informarlos y de esta manera el ciudadano pueda tomar las
medidas necesarias salvaguardar su integridad o bien apoyar a los demás. Por otro lado,
los datos de ingreso para esta interfaz son: título, descripción y foto o video.
82
Ilustración 36: Prototipo Registrar noticia.
Se diseñó la interfaz Historial de emergencias porque en la entrevista realizada se
menciona que el personal de emergencia necesita tener información sobre las
emergencias. Por un lado, el personal de emergencia puede visualizar si una emergencia
fue atendida o no. El dato anterior es muy importante porque evita que el personal de
emergencia atienda una emergencia que ya está siendo atendida y en lugar de ello pueda
atender otras emergencias que puedan estar sucediendo al mismo tiempo. Asimismo, el
personal de emergencia puede ver el lugar donde ocurrió o está ocurriendo la situación,
quien registro la emergencia, descripción de la emergencia y el tipo de emergencia.
83
Ilustración 37: Prototipo historial de emergencias
Se diseñó la interfaz Ver emergencia porque el personal de emergencia tener precisión
de la localización de la emergencia y calcular tiempos de legada. Esta interfaz toma la
localización del personal de emergencia y punta la ruta las corta para llegar al lugar de la
emergencia
84
Ilustración 38: Prototipo Ver mapa
4.3.3 Actividad: Realizar reunión para el avance del proyecto
Se llevó a cabo la reunión en la UTP, en la cual se revisaron los avances de los diseños,
se realizaron las correcciones y ajustes necesarios para la culminación correcta del
proyecto.
4.3.3.1 Acta de reunión
El acta de reunión fue firmada por ambos integrantes y da fe del desarrollo de la reunión,
así como los puntos que fueron vistos en la reunión, en la cual se coordinaron los últimos
ajustes para la culminación de la nuestra propuesta.
85
86
Conclusiones y Recomendaciones
Conclusiones:
 Todas las entidades que atienden las emergencias que son reportadas y que
ponen en riesgo la vida de los ciudadanos, debería tener mayor comunicación
para atender las emergencias de manera más oportuna y con los equipos más
adecuados.
 La rápida comunicación al momento que se ve un riesgo o la ocurrencia de un
desastre es crucial para la reducción de los daños personales y materiales que
pueden causarse por efecto del evento ocurrido.
 Tras realizar las entrevistas, se sabe que tanto los bomberos como los policías
tienen un canal de comunicación adecuado para recibir la información de las
emergencias reportadas, por ende, no pueden acudir con los recursos ni
implementos adecuados.
 Para poder realizar un correcto diseño de un software es necesario conocer los
problemas y necesidades de los usuarios.
 La propuesta del presente trabajo de investigación busca crear un canal más de
comunicación que acerque y concientice a los usuarios frente a los riesgos y
desastres a los que están expuestos.
Recomendaciones:
Concluido el presente trabajo de investigación se considera interesante seguir con las
posteriores etapas: construcción, implementación, pruebas y mantenimiento. También
extender la investigar sobre aspectos relacionados. De esta manera se recomienda lo
siguiente.
 Ampliar los estudios expuestos en el presente trabajo de investigación a través de
un análisis cualitativo y cuantitativo.
87
 Para la etapa de construcción del aplicativo móvil se recomienda utilizar un
lenguaje de programación hibrido basado en HTML y JavaScript como Phonegap,
Cordova o Flutter, porque se requiere que toda la población tenga acceso al
aplicativo móvil sin importar el sistema operativo IOS, Android o Windons Phone
 Por otra parte, se recomienda como gestor de base de datos Firebase porque es
una base de datos NoSQL muy flexible y escalable. Asimismo, Firebase ofrece
múltiples funcionalidades como Realtime Database, Cloud Database, Storage,
Analitycs. La última funcionalidad es muy interesante porque permite obtener
reportes precisos acerca de la aplicación.
 También se recomienda utilizar la API de Google Maps para obtener localización y
rutas de los usuarios.
 Asimismo, en la etapa de implementación se recomienda realizar una encuesta a
las personas que utilizan la aplicación para saber si esta es útil y que porcentaje
está ayudando en la atención de emergencias
88
Bibliografía
OSIPTEL (2018). Suscripciones de internet móvil según modalidad. Recuperado de:
https://www.osiptel.gob.pe/repositorioaps/data/1/1/1/par/62-suscripciones-de-internet-
movil-segun-modalid/IntMovil_C6.2_Terminal.pdf
OSIPTEL (2018). Suscripciones de internet móvil según empresa. Recuperado de:
https://www.osiptel.gob.pe/repositorioaps/data/1/1/1/par/63-suscripciones-de-internet-
movil-segun-empresa/IntMovil_C6.3_Penetracion.pdf
OSIPTEL (2018). Acceso a internet móvil de empresas con plan de datos. Recuperado
de: https://www.osiptel.gob.pe/repositorioaps/data/1/1/1/par/68-acceso-internet-movil-
empresa-datos-plan/IntMovil_C6.5_DisponibilidadDatos.pdf
Quispe, J. (2017). Aplicación móvil para reportar los daños causados por los desastres
naturales a los centros educativos para el Ministerio de Educación (Tesis de pregrado).
Universidad César Vallejo. Recuperado de:
http://repositorio.ucv.edu.pe/bitstream/handle/UCV/17466/Quispe_FJ.pdf?sequence=1&is
Allowed=y
Ríos, P. & Vela, T. (2019). PROPUESTA DE LA APLICACIÓN MÓVIL BASADO EN
UBICACIONES DE ZONAS ANTE DESASTRES NATURALES EN IQUITOS (Tesis de
pregrado). Universidad Nacional de la Amazonía Peruana. Recuperado de:
http://repositorio.unapiquitos.edu.pe/bitstream/handle/UNAP/5968/Paulo_tesis_titulo_201
9.pdf?sequence=1&isAllowed=y
Hidalgo,M. (2016) La gestión del riesgo de desastres en la cultura de prevención de los
docentes de Educación Básica Regular, Región Puno – 2016 (Tesis doctoral).
89
http://repositorio.ucv.edu.pe/bitstream/handle/UCV/22446/Hidalgo_JM.pdf?sequence=1&i
sAllowed=y
Justo, L. (2018). Gestión de riesgo y capacidad preventiva ante desastres originados por
el cambio climático en el distrito de Nueva Cajamarca-2018 (Tesis de maestría).
http://repositorio.ucv.edu.pe/handle/UCV/29587
Ramirez, F. (2017). DISEÑO DE UN SISTEMA DE TELECOMUNICACIONES CON
REDES AD HOC DE DRONES COMO ALTERNATIVA DE MEDIO DE COMUNICACIÓN
PARA HACER FRENTE A DESASTRES NATURALES (Tesis de maestría). Pontificia
Universidad Católico del Perú. Recuperado de:
http://tesis.pucp.edu.pe/repositorio/handle/20.500.12404/8820
Presidencia del Consejo de Ministros (2014). Plan Nacional de Gestión del Riesgo de
desastres 2014-2021. Lima, Perú. Recuperado de: https://www.indeci.gob.pe/wp-
content/uploads/2019/01/fil20140605171327.pdf
Index For Risk Managment (2018). INFORM GLOBAL RISK INDEX. Recuperado de:
http://www.inform-
index.org/Portals/0/InfoRM/2018/INFORM%20Annual%20Report%202018%20Web%20S
preads%20v2.pdf?ver=2017-12-20-141446-540
INDECI (2019). Boletín Estadístico virtual de la gestión reactiva (N° 10). Recuperado de:
https://www.indeci.gob.pe/wp-
content/uploads/2019/01/BOLETIN_VIRTUAL_ENERO_2019_PDF.pdf
90
SINPAD (2006). Manual Básico para la Estimación del Riesgo. Recuperado de:
http://sinpad.indeci.gob.pe/UploadPortalSINPAD/man_bas_est_riesgo.pdf
Microsoft (2016). Introduction to mobil sdlc. Recuperado de:
https://docs.microsoft.com/es-es/xamarin/cross-platform/get-started/introduction-to-
mobile-sdlc
INDECI (2019). Acerca de INDECI. Lima, Perú. Recuperado de:
https://www.indeci.gob.pe/institucion/acerca-del-indeci/
Chuquisengo, A. (2011). Guía de Gestión de Riesgos de Desastres. Aplicación Práctica”.
Ministerio de Vivienda, Construcción y Saneamiento. Lima: Soluciones Prácticas.
Nakamura, M. & Gargenta, M. (2014). Learning Android, 2nd Edition Develop Mobile
Apps Using Java and Eclipse (2ª ed.). Gravenstein, USA: O’Reilly.
Ulloa, F. (2011). Manual de gestión del riesgo de desastre para comunicadores sociales.
Lima: UNESCO.
Ministerio de Vivienda (2014). Plan de Prevención y Reducción de Riesgo de Desastres.
Recuperado de:
http://ww3.vivienda.gob.pe/pnc/docs/GestionRDGU/Ica/CENEPRED%20Elab.%20Plan%2
0de%20Prevencion%20y%20Reduccion%20de%20Riesgo%20de%20Desastres.pdf
91
INEI (2017). Compendio Estadístico de la Provincia de Lima. Recuperado de:
https://www.inei.gob.pe/media/MenuRecursivo/publicaciones_digitales/Est/Lib1477/libro.p
df
Sampieri, R. (2014). Metodología de la Investigación. Recuperado de:
https://www.uca.ac.cr/wp-content/uploads/2017/10/Investigacion.pdf
Santiago, R.; Trabaldo, S.; Kamijo, M. y Fernandez, A. (2019). Mobile learning nuevas
realidades en el aula. Recuperado de: http://www.digital-
text.com/FTP/LibrosMetodologia/mlearning.pdf
Tamayo, M. (2003). El Proceso de la Investigación Científica. Recuperado de:
https://clea.edu.mx/biblioteca/Tamayo%20Mario%20-
%20El%20Proceso%20De%20La%20Investigacion%20Cientifica.pdf
Romero, M. (2017). Desarrollo de Aplicaciones Para Dispositivos Móviles. Recuperado
de:
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/66085/3/mromeropoTFG0617me
moria.pdf
INDECI (2006). Manual básico para la estimación del riesgo. Recuperado de:
http://sinpad.indeci.gob.pe/UploadPortalSINPAD/man_bas_est_riesgo.pdf
INDECI (2018). Plan Operativo Institucional 2018. Recuperado de:
https://www.indeci.gob.pe/minisites/plan-operativo-institucional-poi/
92
Brandmanic (2013). Comunicación boca a boca en el marketing online. Recuperado de:
https://www.brandmanic.com/comunicacion-boca-a-boca-en-el-marketing-online/
93
Anexo 1: Glosario
 Aplicación Móvil: son programas que se ejecutan sobre dispositivos móviles como:
tabletas o Smartphone por ello se debe administrar bien los recursos como la
memoria, y el procesamiento para no saturar el dispositivo.
 Ciclo de vida de un Aplicativo Móvil: son fases de un aplicativo: Inicio donde se
plantea una idea con base sólida. Diseño en el cual se define la experiencia del
usuario en la aplicación. Desarrollo donde se hace uso de los recursos para crear
la aplicación. Estabilización en donde se hacen los controles de calidad, limpieza
y pruebas. Implementación de la idea propuesta.
 Cultura preventiva: Contar con políticas públicas que garanticen la Prevención,
Reducción de Riesgos y la Reconstrucción en forma oportuna y balanceada entre
las entidades competentes.
 Desastre: se define como una situación que produce mucho daño
 Desastre natural: un desastre natural nace de la ocurrencia de un fenómeno
natural, el cual causa una interrupción grave en el funcionamiento de una
comunidad causando grandes pérdidas a nivel humano, material o ambiental.
 Emergencia: se define como una situación crítica que manifiesta peligro y requiere
una actuar rápidamente.
 Fenómeno Natural: se define como todo lo que ocurre en la naturaleza que puede
ser percibido por los sentidos. Además, puede ser objeto de conocimiento,
tomando en cuenta sus características, magnitudes y comportamientos, dando pie
a realizar diversas investigaciones para conocer más de ellos, en especial de
aquellos que pueden ocasionar daños.
 Gestión de Riesgo: el conjunto de medidas administrativas, organizativas y
conocimientos operativos para desarrollar políticas y estrategias con el objetivo de
mitigar el impacto de amenazas naturales, desastres ambientales y tecnológicos.
94
 Prevenir: el conjunto de actividades y medidas diseñadas para proporcionar
protección permanente contra los efectos de un desastre.
 Riesgo: Se define como la probabilidad de que se produzca u ocurra un evento
positivo o negativo, que puede generar una oportunidad o amenaza.
Anexo 2: Modelo de reportes
Los reportes sirven para ver de manera resumida los datos producidos por el uso del
aplicativo, con la información obtenida del uso del aplicativo, se podrá generar reportes
que permitan tomar mejores decisiones a los dirigentes de los distritos y gobiernos, de
esta manera podrán saber que lugares y que medidas correctivas tienen que desarrollar
para prevenir y evitar que los riesgos se hagan mayores y que los desastres causen
mayores daños.
El primer modelo de reporte muestra, en un gráfico pastel, los desastres más ocurridos
durante el mes de diciembre del presente año. Con este reporte entidades como los
bomberos, INDECI y otros pueden reforzar y estar mejor preparados para los desastres
que se muestran con mayor ocurrencia.
95
Ilustración 39: Reporte de desastres más frecuentes
El segundo modelo de reporte muestra las zonas mas afectadas por los desastres
durante el mes de diciembre, con lo cual las autoridades pueden designar mas personal y
cantidad de recursos para poder responder antes estas ocurrencias.
Ilustración 40: Reporte de las zonas más afectadas por los desastres
96
Anexo 3: Ficha de Investigación
Ficha de tarea de investigación – FISE
CARRERA: INGENIERÍA DE SISTEMAS E INFORMÁTICA
Título del Trabajo de Investigación propuesto

PROPUESTA DE DISEÑO DE UN APLICATIVO MÓVIL PARA REPORTAR RIESGOS Y
DESASTRES
2. Indica la o las competencias del modelo del egresado que serán desarrolladas
fundamentalmente con este Trabajo de Investigación:
Desarrollar la capacidad de desarrollo de aplicaciones móviles enfocadas al bienestar de
nuestra sociedad con el respaldo de INDECI.
3. Número de alumnos a participar en este trabajo. (máximo 2) Número de alumnos:

__2___________
Indica si el trabajo tiene perspectivas de continuidad, después de obtenerse el Grado
Académico d Bachiller, para seguirlo desarrollando para la titulación por la modalidad de
Tesis o no.
Si tiene perspectivas de continuidad, por cuanto el desarrollo de aplicaciones móviles está en

continuo auge, y tiene sostenibilidad en el tiempo, por los proyectos de migración y procesos
complementarios a los existentes en las empresas.
4. Enuncia 4 o 5 palabras claves que le permitan realizar la búsqueda de información

para el Trabajo en Revistas Indizadas en WOS, SCOPUS, EBSCO, SciELO, etc., desde el
comienzo del curso y obtener así información de otras fuentes especializadas.
Ejemplo:
Palabras Claves REPOSITORIO 1 REPOSITORIO 2 REPOSITORIO 3
1.- Aplicaciones SciELO SCOPUS WOS
móviles
2.Reconocimient SciELO SCOPUS WOS
o de imágenes
por medio de
aplicaciones
móviles
3.- Aplicaciones SciELO SCOPUS WOS
móviles para la
prevención de
desastres
4.- Librerías para SciELO SCOPUS WOS
el
reconocimiento
de patrones
basada en
imágenes
97
5.-software para SciELO SCOPUS WOS
Android y IOS
5. Como futuro asesor de investigación para titulación colocar:

(Indique sus datos personales)
a. Nombre:_REMBRANDT UBALDE ENRIQUEZ_______________

b. Código Docente: C13198 _______________________
c. Correo: [email protected]____
d. Teléfono ____992195477_____________
7. Específica si el Trabajo de Investigación:

(Marca con un círculo la que corresponde, puede ser más de una)
a. Contribuye a un trabajo de investigación de una Maestría o un
doctorado de algún profesor de la UTP.
b. Está dirigido a resolver algún problema o necesidad propia de la
organización.
c. Forma parte de un contrato de servicio a terceros.
d. Corresponde a otro tipo de necesidad o causa (explicar el detalle):
Las aplicaciones móviles abocadas a automatizar procesos específicos de bien común,
específicos de ayuda a solucionar problemas en la sociedad, como los desastres
naturales, y los mecanismos mediante los cuales se pueden prevenir o mitigar.
8. Explica de forma clara y comprensible los objetivos o propósitos del trabajo de investigación
Identificar los procesos necesarios para asistir a los procesos de prevención de desastres.
Construir una app móvil para el registro y envió en tiempo real de imágenes y
geolocalización de zonas propensas a desastres naturales.
Crear una base de datos que administre INDECI interconectada con gobiernos regionales,
municipalidades, bomberos, ejército, cruz roja, hospitales.
9. Brinde una primera estructuración de las acciones específicas que debe realizar el alumno
para que le permita iniciar organizadamente su trabajo
Mapear procesos en Bizagi para la prevención de desastres.

Construir una app móvil para la captura de imágenes, que funcione en sistemas operativos
Android, iOS, bb, winphone.
Registro de imágenes en una Base de datos en tiempo real con su respectiva clasificación
automática.
Integración e interoperabilidad con entidades públicas y empresas privadas relacionadas a
prevención de desastres.
10. Incorpora todas las observaciones y recomendaciones que consideres de utilidad para el
alumno y a los profesores del curso con el fin de que desarrollen con éxito todas las actividades
98
Se recomienda identificar los procesos necesarios para asistir a los procesos de prevención
de desastres mediante la creación de app que permita a cualquier ciudadano, enviar
imágenes en tiempo real, de zonas pasibles de atención inmediata, que pudieran generar
algún problema social (huaycos, construcciones antiguas, Zonas aledañas a ríos con
potencial desborde de causales, puentes deteriorados, buzones abiertos de desagüe,
construcciones mal construidas).
11. Fecha y docente que propone la tarea de investigación

Fecha de elaboración de ficha (día/mes/año): ____25______/ ___01______/ __2019____
Docente que propone la tarea de investigación: _REMBRANDT UBALDE ENRIQUEZ_____
12. Esta Ficha de Tarea de Investigación ha sido aprobada como Tarea de Investigación
para el Grado de Bachiller en esta carrera por:
(Sólo para ser llenada por la Facultad)
Nombre:
_________________________________________________________________________
__________
Código:
_________________________________________________________________________
____________
Cargo:
_________________________________________________________________________
_____________
Fecha de aprobación de ficha (día/mes/año): ________/ __________/ _________
99

Propuesta de Diseño de Un Aplicativo Móvil para Reportar Riesgos y Desastres

Cargado por

Información del documento

Descripción original:

Título 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

Propuesta de Diseño de Un Aplicativo Móvil para Reportar Riesgos y Desastres

Cargado por

Copyright:

Formatos disponibles

Facultad de Ingeniería

“Propuesta de diseño de un aplicativo

Para obtener el Grado de Bachiller en:

Lima, diciembre 2019

En el Perú, de acuerdo a las cifras de INDECI, se atendieron más de 7 mil emergencias

de la manera adecuada frente a la emergencia.

para la creación de actividades de levantamiento de información, análisis y diseño del

historias de usuario, Sprints y Producto Backlog. Se utilizó el cuestionario en entrevistas

orales a un bombero y policía para realizar el levantamiento de información, sobre la

atención de riesgos y desastres, empleando la técnica de juicio experto. Además, se

de emergencias ante un riesgo o desastre. Para llevar a cabo la propuesta de diseño, se

desarrollo de un aplicativo móvil que refleja una solución a la problemática y necesidades

encontradas durante la investigación.

Palabras clave: Aplicación móvil, reporte de daños, riesgos y desastres.

Este trabajo se lo dedicamos a nuestras

A nuestros profesores por sus enseñanzas y

Ilustración 1: Cuestionario para las entrevistas .................................................................. 38

Ilustración 2: Acta de Reunión con los expertos................................................................. 39

Ilustración 3: Correos para la coordinación de las entrevistas ........................................... 40

Ilustración 4: Audio de las entrevistas realizadas ............................................................... 41

Ilustración 5: Acta de reunión con el bombero ................................................................... 42

Ilustración 6: Acta de reunión con el policía ....................................................................... 43

Ilustración 7: Referencia de una entrevista digitalizada a un bombero ............................. 45

Ilustración 8: referencial de una entrevista digitaliza a un policía ...................................... 46

Ilustración 9: Análisis de entrevistas ................................................................................... 49

Ilustración 10: Carpeta con las tesis revisadas .................................................................. 50

Ilustración 11: Documento del resumen de tesis revisadas ............................................... 51

Ilustración 12: Proceso de llamada de emergencia a la policía o bomberos ..................... 52

Ilustración 13: Diagrama de proceso de registro de usuario .............................................. 53

Ilustración 14: Diagrama de proceso de registro de riesgos o desastres .......................... 54

Ilustración 15: Diagrama de atención de emergencia ........................................................ 55

Ilustración 16: CDU/ Ciudadano- Módulo Login ................................................................. 57

Ilustración 17: CDU / Ciudadano – Módulo Usuario ........................................................... 58

Ilustración 18: CDU/ Ciudadano – Modulo Registrar Emergencia ..................................... 58

Ilustración 19: CDU/ Ciudadano – Modulo Visualizar emergencia .................................... 59

Ilustración 20: CDU/ Personal de Emergencia – Módulo Login ......................................... 59

Ilustración 21: CDU / Personal de Emergencia – Módulo Usuario .................................... 60

Ilustración 22: CDU/ Personal de Emergencia- Módulo emergencia ................................. 60

Ilustración 23: Acta de reunión 1......................................................................................... 68

Ilustración 24: Metamodelo NoSQL .................................................................................... 70

Ilustración 25: Diagrama de clases ..................................................................................... 71

Ilustración 26: Arquitectura del aplicativo ........................................................................... 72

Ilustración 28: Prototipo login de usuario ............................................................................ 75

Ilustración 29: Prototipo Menú de opciones de usuario...................................................... 76

Ilustración 30: Prototipo categoría de emergencia ............................................................. 77

Ilustración 31: Prototipo mapa de emergencias ................................................................. 78

Ilustración 32: Prototipo Detalle de Emergencia ................................................................. 79

Ilustración 33: Prototipo Noticias ......................................................................................... 80

Ilustración 34: Prototipo Editar perfil ................................................................................... 81

Ilustración 35: Prototipo menú desplegable para el personal de atención de emergencias

Ilustración 36: Prototipo Registrar noticia. .......................................................................... 83

Ilustración 37: Prototipo historial de emergencias .............................................................. 84

Ilustración 38: Prototipo Ver mapa ...................................................................................... 85

Tabla 1: Historias de usuario del aplicativo móvil ............................................................... 63

Tabla 2: Product Backlog .................................................................................................... 67

para reportar riesgos y desastres, con el fin de proporcionar un canal de comunicación

causan daños materiales.

La investigación de esta problemática en beneficio de la sociedad se realizó por el interés

percibir las carencias de estos procesos y sistemas.

académico. De tal manera, se puede difundir una cultura preventiva en la población y al

actuar de la mejor manera.

Capítulo 1, se definen los antecedentes de la investigación, planteamiento del problema,

con la propuesta: tecnológico y riesgos y desastres. 