“análisis, diseño y desarrollo del sistema web satsos...
Post on 25-Aug-2020
13 Views
Preview:
TRANSCRIPT
Facultad de Ingeniería
Carrera de Ingeniería de Sistemas e Informática.
“Análisis, Diseño y Desarrollo del Sistema Web SATSOS, para optimizar la
prevención de riesgos naturales conociendo el posible número de
damnificados por la caída de Huaicos en los años 2015 y 2017 en Lurigancho
Chosica”
Autor: Jim Jesús Casimiro Valencia
Para obtener el Título Profesional de
Ingeniero de Sistemas e Informática
Asesor: Ing. Víctor Quevedo Dioses
Lima, diciembre 2018
2
DEDICATORIA
Dedico esta tesis primeramente a Dios quien me dio las
fuerzas necesarias para seguir adelante ante cada obstáculo
presentado. A mis padres Jesus y Giovanna que me
apoyaron en todo momento regalándome vida, educación y
los mejores consejos. A mi esposa Lizeth y a mi hija Luhana
que conocen las experiencias que he vivido para lograr
culminar esta etapa tan importante de mi vida. A mis
hermanos Johnatan y Johan por estar a mi lado
brindándome su apoyo incondicional.
3
AGRADECIMIENTO
Agradezco a todas aquellas personas, colegas,
amigos y familiares que de manera directa e indirecta
influyeron en mi para poder realizar este trabajo.
De igual manera, agradezco al Ing. Víctor Quevedo
Dioses por sus críticas, sugerencias y recomendaciones, los
cuales contribuyeron enormemente en el desarrollo de la
presente Tesis.
Finalmente agradezco a la Universidad Tecnológica
del Perú, a mis profesores y compañeros por ayudarme a
crecer en cada paso de mi carrera profesional.
4
RESUMEN
El siguiente proyecto es un desarrollo de un sistema informático para controlar la
información de prevención de riesgos naturales conociendo las cifras de víctimas y el
porcentaje de daños materiales que causaron los huaicos de los años 2015 y 2017.
Definiremos la estructura del desarrollo de la tesis:
Capítulo 1: La formulación y planteamiento del problema, hipótesis, objetivos, alcance,
justificación, delimitaciones, limitaciones, viabilidad de la investigación, diseño de la
investigación y matriz de consistencia.
Capítulo 2: Comprenderá los antecedentes de la investigación, el marco teórico para
entender algunos términos que se mencionarán posteriormente, el marco conceptual,
marco metodológico y legal.
Capítulo 3: Se definen los módulos del sistema y se identifican los requerimientos
funcionales y no funcionales.
Capítulo 4: Se definirán los beneficios esperados y se realizará la comparación del costo
de inversión versus las pérdidas económicas.
Finalmente, la solución planteada permitirá la mejora de los canales de comunicación y la
reducción del porcentaje de víctimas y pérdidas materiales ante un riesgo natural.
5
ÍNDICE
DEDICATORIA ......................................................................................................................................... 2
AGRADECIMIENTO ................................................................................................................................ 3
RESUMEN ................................................................................................................................................ 4
INTRODUCCIÓN .................................................................................................................................... 10
CAPÍTULO 1 ........................................................................................................................................... 11
ASPECTOS GENERALES .................................................................................................................... 11
1.1. PLANTEAMIENTO DEL PROBLEMA ........................................................................................11 1.2. FORMULACIÓN DEL PROBLEMA E HIPÓTESIS ....................................................................12
1.2.1. Problema general ............................................................................................................12 1.2.2. Problemas específicos ....................................................................................................12
1.3. OBJETIVOS DE LA INVESTIGACIÓN ......................................................................................12 1.3.1. Objetivo general ..............................................................................................................12 1.3.2. Objetivos específicos ......................................................................................................12
1.4. ALCANCE DE INVESTIGACIÓN ...............................................................................................13 1.5. JUSTIFICACIÓN E IMPORTANCIA DEL PROYECTO .............................................................13 1.6. DELIMITACIÓN DE LA INVESTIGACIÓN .................................................................................15
1.6.1. Delimitación espacial .......................................................................................................15 1.6.2. Delimitación del universo ................................................................................................15 1.6.3. Delimitación del contenido ..............................................................................................16
1.7. LIMITACIONES DE LA INVESTIGACIÓN .................................................................................16 1.8. ANÁLISIS DE LA VIABILIDAD DE LA INVESTIGACIÓN ...........................................................16
1.8.1. Viabilidad técnica ............................................................................................................16 1.8.2. Viabilidad operativa .........................................................................................................17
CAPITULO 2 ........................................................................................................................................... 18
FUNDAMENTO TEÓRICO .................................................................................................................... 18
2.1. ANTECEDENTES DE LA INVESTIGACIÓN .............................................................................18 2.1.1. Firechat ............................................................................................................................18 2.1.2. Sistema de mensajería de alerta temprana ....................................................................19 2.1.3. Sistema de alerta temprana ............................................................................................20
2.2. MARCO TEÓRICO ....................................................................................................................21 2.2.1. Metodología scrum ..........................................................................................................21
2.3. MARCO CONCEPTUAL ............................................................................................................23 2.3.1. Polymer ...........................................................................................................................23 2.3.2. Javascript ........................................................................................................................23 2.3.3. Servicios rest ...................................................................................................................23 2.3.4. MySql ...............................................................................................................................24 2.3.5. Jboss ...............................................................................................................................24 2.3.6. Eclipse .............................................................................................................................24
2.4. MARCO METODOLÓGICO .......................................................................................................24 2.4.1. Tipo de Investigación ......................................................................................................24 2.4.2. Nivel de Investigación .....................................................................................................25
2.5. MARCO LEGAL .........................................................................................................................25
CAPITULO 3 ........................................................................................................................................... 26
DESARROLLO DE LA PROPUESTA DE INVESTIGACIÓN............................................................. 26
3.1. PROCESO DE NEGOCIO .........................................................................................................26 3.1.1. Proceso de negocio antes de la implementación............................................................26
6
3.1.2. Proceso de negocio después de la implementación .......................................................27 3.1.3. Análisis comparativo de los procesos .............................................................................27 3.1.4. Tabla De Actividades ......................................................................................................28
3.2. CRONOGRAMA DE ACTIVIDADES .........................................................................................28 3.3. IDENTIFICACIÓN DE REQUERIMIENTOS ..............................................................................29
3.3.1. Requerimientos funcionales ............................................................................................29 3.3.2. Requerimientos no funcionales .......................................................................................30
3.4. LENGUAJE DE MODELADO (UML) ..........................................................................................31 4.2.1. Diagrama de casos de uso ..............................................................................................31 4.2.2. Diagrama de secuencia ...................................................................................................39 4.2.3. Diagrama de despliegue del sistema ..............................................................................40
3.5. ARQUITECTURA ......................................................................................................................40 3.5.1. Componentes principales ................................................................................................41 3.5.2. Patrón de diseño .............................................................................................................42 3.5.3. Modelo de datos ..............................................................................................................43
3.6. INTERFAZ DEL SISTEMA .........................................................................................................46 3.7. CONSTRUCCION Y PRUEBAS ................................................................................................61
3.7.1. Framework .......................................................................................................................61 3.7.2. Herramientas, plataformas y tecnología .........................................................................62 3.7.3. Implementación ...............................................................................................................62 3.7.4. Pruebas ...........................................................................................................................71
CAPITULO 4 ........................................................................................................................................... 73
ANÁLISIS COSTO Y BENEFICIO ........................................................................................................ 73
4.1. DETERMINACIÓN DE COSTOS ...............................................................................................73 4.1.1. Costos de inversión .........................................................................................................73 4.1.2. Costos de mantenimiento ................................................................................................75
4.2. BENEFICIOS ESPERADOS ......................................................................................................76 4.2.1. Beneficios tangibles ........................................................................................................76 4.2.2. Beneficios intangibles ......................................................................................................76
4.3. COMPARATIVA DE INVERSIÓN VERSUS PÉRDIDAS ECONÓMICAS .................................77
CONCLUSIONES ................................................................................................................................... 81
RECOMENDACIONES .......................................................................................................................... 82
ANEXOS ................................................................................................................................................. 83
GLOSARIO ............................................................................................................................................. 87
BIBLIOGRAFÍA ...................................................................................................................................... 90
7
INDICE DE ILUSTRACIONES
ILUSTRACIÓN 1: JUSTIFICACIÓN E IMPORTANCIA ............................................................................................ 14 ILUSTRACIÓN 2: DELIMITACIÓN ESPACIAL ....................................................................................................... 15 ILUSTRACIÓN 3: ANTECEDENTE FIRECHAT .................................................................................................... 19 ILUSTRACIÓN 4: ANTECEDENTE SISMATE .................................................................................................... 19 ILUSTRACIÓN 5: ANTECEDENTE SAT ............................................................................................................. 20 ILUSTRACIÓN 6: PROCESO SCRUM .............................................................................................................. 21 ILUSTRACIÓN 7: CASO DE USO INGRESO AL SISTEMA .................................................................................... 37 ILUSTRACIÓN 8: CASO DE USO MENSAJE DE ALERTA .................................................................................... 37 ILUSTRACIÓN 9: CASO DE USO GENERACIÓN DE REPORTES ........................................................................ 38 ILUSTRACIÓN 10: CASO DE USO USUARIO ..................................................................................................... 38 ILUSTRACIÓN 11: CASO DE USO REGISTRO DE DATOS ESTADÍSTICOS .......................................................... 38 ILUSTRACIÓN 12: DIAGRAMA DE SECUENCIA DEL SISTEMA ........................................................................... 39 ILUSTRACIÓN 13: DIAGRAMA DE SECUENCIA POST DESASTRE ...................................................................... 39 ILUSTRACIÓN 14: DIAGRAMA DE DESPLIEGUE ................................................................................................ 40 ILUSTRACIÓN 15: DIAGRAMA PATRÓN MVC ................................................................................................... 43 ILUSTRACIÓN 16: MODELO ENTIDAD RELACIÓN ............................................................................................ 45 ILUSTRACIÓN 17: PÁGINA DE INICIO ............................................................................................................... 46 ILUSTRACIÓN 18: MENÚ PRINCIPAL - SUPERVISOR ........................................................................................ 47 ILUSTRACIÓN 19: PÁGINA MENSAJE ALERTA ................................................................................................. 47 ILUSTRACIÓN 20: AGREGAR MENSAJE ALERTA ............................................................................................. 47 ILUSTRACIÓN 21: OPCIÓN VER MAPA ............................................................................................................ 48 ILUSTRACIÓN 22: CONFIRMACIÓN DE ASIGNACIÓN ........................................................................................ 48 ILUSTRACIÓN 23: MENÚ PRINCIPAL - OPERADOR .......................................................................................... 49 ILUSTRACIÓN 24: PÁGINA ENVÍO DE ALERTA ................................................................................................. 49 ILUSTRACIÓN 25: CONFIRMACIÓN MENSAJES ENVIADOS .............................................................................. 50 ILUSTRACIÓN 26: MANTENIMIENTO ESTADÍSTICA PERSONA ......................................................................... 50 ILUSTRACIÓN 27: MANTENIMIENTO ESTADÍSTICA VIVIENDA .......................................................................... 50 ILUSTRACIÓN 28: MÓDULO DE USUARIO ........................................................................................................ 51 ILUSTRACIÓN 29: MÓDULO DE POBLADORES ................................................................................................. 51 ILUSTRACIÓN 30: PÁGINA DE DESBLOQUEO .................................................................................................. 51 ILUSTRACIÓN 31: PÁGINA DE REPORTE ......................................................................................................... 52 ILUSTRACIÓN 32: REPORTE POR ESTADO ...................................................................................................... 52 ILUSTRACIÓN 33: REPORTE POR FECHA ........................................................................................................ 52 ILUSTRACIÓN 34: FILTRO REPORTE PERSONAS ............................................................................................ 53 ILUSTRACIÓN 35: FILTRO REPORTE VIVIENDAS ............................................................................................. 53 ILUSTRACIÓN 36: REPORTE ANUAL................................................................................................................. 54 ILUSTRACIÓN 37: REPORTE POR RANGO DE FECHA ....................................................................................... 55 ILUSTRACIÓN 38: REPORTE POR QUEBRADA.................................................................................................. 56 ILUSTRACIÓN 39: REPORTE FAMILIAS DAMNIFICADAS ................................................................................... 57 ILUSTRACIÓN 40: REPORTE FAMILIAS AFECTADAS ........................................................................................ 58 ILUSTRACIÓN 41: REPORTE PERSONAS HERIDAS ......................................................................................... 59 ILUSTRACIÓN 42: REPORTE PERSONAS FALLECIDAS .................................................................................... 60 ILUSTRACIÓN 43: CONFIGURACIÓN SPRING XML .......................................................................................... 63 ILUSTRACIÓN 44: CONFIGURACIÓN Y CONEXIÓN ........................................................................................... 64 ILUSTRACIÓN 45: CLASE PSIDAOCONFIG ...................................................................................................... 64 ILUSTRACIÓN 46: CLASE PSIDATASOURCE .................................................................................................... 65 ILUSTRACIÓN 47: CONEXIÓN JBOSS............................................................................................................. 65 ILUSTRACIÓN 48: CLASE CONTROLADOR ....................................................................................................... 66 ILUSTRACIÓN 49: CLASE REQUEST Y RESPONSE .......................................................................................... 67 ILUSTRACIÓN 50: IMPLEMENTACIÓN DEL MÉTODO ......................................................................................... 67 ILUSTRACIÓN 51: CONFIGURACIÓN MYBATIS - STORED PROCEDURE .......................................................... 68
8
ILUSTRACIÓN 52: MYSQL - STORED PROCEDURE ........................................................................................ 68 ILUSTRACIÓN 53: PRUEBA SOAP UI .............................................................................................................. 69 ILUSTRACIÓN 54: CAPA PRESENTACIÓN – POLYMER .................................................................................... 70 ILUSTRACIÓN 55: MÉTODOS PARA PRUEBAS DE CONCURRENCIA.................................................................. 71 ILUSTRACIÓN 56: RESULTADO DE LAS PRUEBAS ............................................................................................ 71
9
INDICE DE TABLAS
TABLA 1: DESCRIPCIÓN DE ACTIVIDADES ....................................................................................................... 28 TABLA 2: CRONOGRAMA GANTT ..................................................................................................................... 28 TABLA 3: REQUERIMIENTOS FUNCIONALES .................................................................................................... 29 TABLA 4: REQUERIMIENTO NO FUNCIONALES ................................................................................................ 30 TABLA 5: CASO DE USO 01 ............................................................................................................................. 31 TABLA 6: CASO DE USO 02 ............................................................................................................................. 32 TABLA 7: CASO DE USO 03 ............................................................................................................................. 32 TABLA 8: CASO DE USO 04 ............................................................................................................................. 33 TABLA 9: CASO DE USO 05 ............................................................................................................................. 34 TABLA 10: CASO DE USO 06 ........................................................................................................................... 34 TABLA 11: CASO DE USO 07 ........................................................................................................................... 35 TABLA 12: CASO DE USO 08 ........................................................................................................................... 36 TABLA 13: PRUEBA UNITARIA .......................................................................................................................... 72 TABLA 14: COSTO DE INVERSIÓN PERSONAL................................................................................................. 74 TABLA 15: COSTO DE INVERSIÓN EQUIPOS ................................................................................................... 74 TABLA 16: COSTO PROVEEDOR MENSAJE DE TEXTO .................................................................................... 75 TABLA 17: COSTOS DE INVERSIÓN MANTENIMIENTO ..................................................................................... 76 TABLA 18: COSTO DE INVERSIÓN TOTAL ........................................................................................................ 77 TABLA 19: REPORTE DE HECHOS ................................................................................................................... 78 TABLA 20: REPORTE DE PERSONAS AFECTADAS EN EL 2015 ....................................................................... 78 TABLA 21: REPORTE DE VIVIENDAS AFECTADAS EN EL 2015 ........................................................................ 78 TABLA 22: REPORTE DE PERSONAS AFECTADAS EN EL 2017 ....................................................................... 78 TABLA 23: REPORTE DE VIVIENDAS AFECTADAS EN EL 2017 ........................................................................ 79 TABLA 24: PROYECCIÓN DE AHORRO ............................................................................................................ 79
10
INTRODUCCIÓN
Lurigancho Chosica es un distrito que se ubica en el lado este de la provincia de
Lima, rodeada por numerosos cerros que en épocas de lluvia la caída de líquido es tan
significativa que el terreno no puede absorberla produciendo una acumulación de lodo y
este por inercia termina convirtiéndose en un Huaico.
Estos acontecimientos se han vuelto constantes en época de lluvias y las
estrategias para prevenir los daños en las victimas por causa de estos desastres
naturales son nulas y muchas veces precipitadas, es por lo que, sumándonos al boom
tecnológico, pues la gran mayoría de personas cuenta con un dispositivo celular que
puede recibir mensajes de texto (SMS), se desea implementar un SISTEMA DE ENVÍO
DE ALERTA POR MENSAJES DE TEXTO (SATSOS).
El Sistema SATSOS informará a la población de los posibles acontecimientos
previsibles de riesgos naturales en tiempo real vía SMS. Dependiendo de la magnitud del
riesgo se informará a las personas designadas para llevar a ejecución el plan de
contingencia brindada por Defensa Civil para salvaguardar la integridad de la población.
11
CAPÍTULO 1
ASPECTOS GENERALES
1.1. PLANTEAMIENTO DEL PROBLEMA
En la actualidad ante un deslizamiento de agua y lodo conocido como huaico, el
personal autorizado (bomberos y policía) activa una alarma (sirenas) para avisar a la
población que está sucediendo un desastre natural.
Esta sirena, al ser activada, informa a la comunidad sobre una presencia de huaico en
alguna quebrada del distrito dando poco tiempo de reacción a los pobladores que
viven en zonas de alto riesgo.
Así mismo, esta sirena no indica:
1. El lugar de procedencia de la caída del huaico.
2. El número posible de víctimas y damnificados.
3. La cantidad posible de daños materiales.
De seguir así, la comunicación con el poblador para prevenirlo e informarlo seguirá
siendo confusa y opaca.
12
1.2. FORMULACIÓN DEL PROBLEMA E HIPÓTESIS
1.2.1. PROBLEMA GENERAL
¿En qué medida la Implementación de un Sistema Informático de envío de
alertas en tiempo real optimizará la prevención de riesgos naturales conociendo
el posible número de cifras de damnificados en los años 2015 y 2017?
1.2.2. PROBLEMAS ESPECÍFICOS
• ¿En qué medida la Implementación de un Sistema Informático de envío de
alertas en tiempo real mejorará la comunicación con los pobladores?
• ¿En qué medida la Implementación de un Sistema Informático de envío de
alertas en tiempo real disminuirá el posible número de damnificados?
• ¿En qué medida la Implementación de un Sistema Informático de envío de
alertas en tiempo real disminuirá la posible cifra de pérdidas materiales?
1.3. OBJETIVOS DE LA INVESTIGACIÓN
1.3.1. OBJETIVO GENERAL
Implementar un sistema informático basado en plataforma web, orientado a
controlar la información de la prevención de riesgos naturales conociendo el
posible número de damnificados en tiempo real.
1.3.2. OBJETIVOS ESPECÍFICOS
• Determinar de qué manera la implementación del Sistema SATSOS
permita mejorar los canales de comunicación conociendo el posible
número de cifras de damnificados.
13
• Determinar de qué manera la implementación del Sistema SATSOS
permita disminuir el posible número de víctimas y damnificados.
• Determinar de qué manera la implementación del Sistema SATSOS
permita disminuir la posible cifra de pérdidas o daños materiales.
1.4. ALCANCE DE INVESTIGACIÓN
Se toma como muestra a todo el distrito de Lurigancho Chosica y en caso de esta
Tesis a los pobladores que viven en el margen del cauce natural de los huaicos
conocido como quebradas.
El Sistema SATSOS optimizará la información de prevención de un riesgo natural
reduciendo el posible número de víctimas y los daños materiales.
Para calcular la optimización vamos a generar reportes con los datos que
obtendremos luego de un desastre natural tomando como base las cifras de
damnificados y daños materiales de los años 2015 y 2017 en el distrito de
Chosica.
1.5. JUSTIFICACIÓN E IMPORTANCIA DEL PROYECTO
Según estudios del diario “El Comercio” la municipalidad de Chosica tuvo un
presupuesto aproximado de 600 millones de soles entre el 2007 y 2015, de las
cuales solo el 3.3% fue destinado para la prevención de desastres naturales.
En el año 2015 fuimos testigos de uno de los huaicos más fuertes en Chosica
porque en un solo día 8 personas perdieron la vida y 108 familias perdieron
absolutamente todo. Ante esto se realizó la instalación de mallas geotérmicas
para aguantar la caída de las rocas provenientes de las principales quebradas.
14
Lo riesgoso es que estas mallas deben tener un mantenimiento continuo para
evitar el sobre peso y la caída de las rocas acumuladas, lo cual es una inversión
fuerte y demanda tiempo en su realización.
Además, estas mallas han sufrido robos por parte de los pobladores quienes han
hurtado accesorios importantes para la estabilidad de las mallas poniendo en
doble riesgo a los pobladores ante un desplome de estas estructuras.
Ilustración 1: Justificación e importancia
Es por lo que se desea implementar un sistema que alerte al poblador de los
acontecimientos que puedan afectar su seguridad y el de su familia mediante
envío de mensajes de texto.
El personal capacitado para manejar el sistema será designado por la
Municipalidad de Chosica, el cual formará parte del equipo de monitoreo de
cámaras de seguridad para que pueda gestionar las alertas y se envíen a los
15
diferentes sectores del distrito para que todo poblador que cuenten con un
dispositivo móvil pueda informarse de los acontecimientos en el distrito en
tiempo real.
1.6. DELIMITACIÓN DE LA INVESTIGACIÓN
1.6.1. DELIMITACIÓN ESPACIAL
Esta investigación comprende la iteración del personal de la municipalidad junto
al cuerpo de bomberos, serenazgo, defensa civil y la policía nacional del distrito.
Según estudios se ha determinado que el distrito de Chosica cuenta con más de
catorce (14) quebradas de riesgo de huaicos periódicamente activos.
Ilustración 2: Delimitación espacial
1.6.2. DELIMITACIÓN DEL UNIVERSO
Los pobladores por investigar serán los que vivan cerca de las quebradas del
16
distrito y los que se encuentren viviendo en el cauce natural de los huaicos.
1.6.3. DELIMITACIÓN DEL CONTENIDO
Esta investigación hará hincapié en cuan eficiente será el Sistema SATSOS para
controlar la información de la prevención de riesgos naturales en tiempo real
disminuyendo la falta de comunicación y el posible número de damnificados y
daños materiales.
1.7. LIMITACIONES DE LA INVESTIGACIÓN
Las limitaciones encontraras en el proyecto fueron:
• La poca disponibilidad de los funcionarios de la municipalidad para participar
en las entrevistas activas para la recopilación de información.
• La poca accesibilidad a las quebradas ya que se encuentran más
resguardadas debido a la perdida de materiales.
1.8. ANÁLISIS DE LA VIABILIDAD DE LA INVESTIGACIÓN
La finalidad en este punto es analizar el proyecto propuesto en base a diversos
criterios.
1.8.1. VIABILIDAD TÉCNICA
La propuesta de solución consiste en implementar un sistema informático para el
cual se ha requerido contar con las siguientes herramientas: Laptops y servidores
de prueba con software de código libre (open source) respectivamente.
17
Para el paso a producción o la implementación del sistema se reutilizará los
servicios de alojamiento que actualmente posee la municipalidad en el área de
monitoreo de cámaras de seguridad.
1.8.2. VIABILIDAD OPERATIVA
Se ha estimado aproximadamente 5 meses para el desarrollo del proyecto donde
se ha provisto con el apoyo de 01 Jefe de Proyecto, 02 programadores y 01
Analista de Sistemas (tesista). Teniendo en consideración que cada uno posee
experiencia en el ciclo del desarrollo de software.
CAPITULO 2
FUNDAMENTO TEÓRICO
2.1. ANTECEDENTES DE LA INVESTIGACIÓN
2.1.1. FIRECHAT
(Jiménez Cano, 2016)
FireChat es la aplicación de mensajería desarrollada por la empresa Open
Garden, este aplicativo funciona cuando otras aplicaciones no pueden ya que
utiliza tecnología de red inalámbrica de malla para conectar personas y
dispositivos móviles vía Bluetooth, wifi y bajo la tecnología de Apple “Multipeer
Conectivity” que logra comunicarse con un dispositivo móvil aun cuando no
existe conexión a Internet o servicio de datos móviles disponibles.
La empresa Open Garden ha lanzado una actualización del aplicativo llamándolo
“FireChat Alerts” que permitirá a los gobiernos, ONG y otros medios emitir
mensajes a las zonas afectadas ante un desastre natural o en grandes
manifestaciones. Una vez que el mensaje llegue a los móviles de ese lugar, la
difusión estará asegurada, aunque no funcione la línea telefónica.
En setiembre del año 2014 en Hong Kong se llevó a cabo una fuerte protesta
debido a la restricción del gobierno chino que impedía que la ciudad
semiautónoma pueda celebrar las elecciones del año 2017 bloqueando la señal
19
de internet para que los protestantes no puedan comunicarse.
Ante este acontecimiento los manifestantes, quienes ya tenían instalado la
aplicación FireChat, se pudieron comunicar y coordinar sus acciones a tomar
evadiendo el bloqueo de internet por parte del estado.
Ilustración 3: Antecedente FireChat
2.1.2. SISTEMA DE MENSAJERÍA DE ALERTA TEMPRANA
(MTC, 2016)
En Perú, el ministerio de Transporte y Comunicaciones está desarrollando un
Sistema de Mensajería de Alerta Temprana de Emergencia (SISMATE) el cual
será una herramienta tecnológica para la difusión de mensajes de texto a
disposición de INDECI.
Este aplicativo funcionará antes, durante y después de un desastre natural para
notificar a los usuarios y ellos no se alarmen saturando las líneas telefónicas de
los diferentes operadores actualmente asociados como se dio en el último
terremoto en la ciudad de Ica.
Ilustración 4: Antecedente SISMATE
20
2.1.3. SISTEMA DE ALERTA TEMPRANA
(UNGRD, 2015)
Este sistema es conocido mundialmente por sus iniciales SAT el cual tiene un
mecanismo autónomo que no necesita estar conectado a otro sistema, su
función es avisar a la comunidad de zonas con alto riego sobre diferentes
fenómenos naturales como son las inundaciones, huaicos, terremotos, etc.
En Colombia tienen implementado un SAT para medir los niveles hídricos los
cuales funcionan gracias a unos sensores de monitoreo de crecimiento o
decrecimiento de agua en los ríos y quebradas.
En El Salvador tienen implementado un promedio de veinte (20) sistemas de
alerta temprana por inundaciones alrededor de todo el país. Estos SAT están
conformados por estaciones que cuentan con equipos automáticos de medición
de lluvia, nivel de ríos que registran y transmiten la información en tiempo real
hacia el Centro de Monitoreo en las oficinas centrales del MARN. Los SAT
apoyados con información del pronóstico hidrológico y meteorológico, emiten
avisos dirigidos a las comunidades, tomadores de decisión, funcionarios locales
y del gobierno central, cuando se prevé la existencia de riesgos por la amenaza
de inundaciones en alguna zona
Ilustración 5: Antecedente SAT
21
2.2. MARCO TEÓRICO
2.2.1. METODOLOGÍA SCRUM
(Albaladejo, 2008)
En Scrum se una metodología ágil y flexible que consiste en realizar entregas
parciales del proyecto final priorizando los puntos más importantes según
definición del cliente maximizando el retorno de la inversión.
Usualmente se utiliza SCRUM para el desarrollo de proyectos complejos que
tengan como finalidad ser terminados en el menor tiempo posible aun cuando se
presenten obstáculos o requisitos y prioridades cambiantes.
Ilustración 6: Proceso SCRUM
Actividades en Scrum:
1. Planificación de la iteración
En cara a empezar con el proyecto se van a planificar tareas que vamos a
dividirlo en dos secciones:
22
• Selección de requisitos: El cliente entrega al equipo la lista de
requisitos a desarrollar y posteriormente se analiza cada punto
priorizando los de mayor necesidad.
• Planificación de la iteración: Se va a coordinar con el equipo la
división de tareas en cara a los requisitos y prioridades enviadas
por el cliente.
2. Ejecución de la iteración
Se realiza diariamente una reunión corta para sincronizar los avances
realizados. En esta reunión cada integrante da a conocer el trabajo realizado y
el trabajo que le queda por realizar para que impedir que se formen obstáculos
y poder cumplir con las fechas establecidas.
El facilitador tiene como función apoyar al equipo en posibles dudas y/o fallas
técnicas que se puedan presentar.
3. Inspección y adaptación
Se defines las reuniones para la revisión de los avances.
• Demostración: Se presentan los requisitos completados según los
hitos establecidos y el cliente realiza la validación de manera
objetiva. De encontrar alguna observación se replanifica el
proyecto.
• Retrospectiva: Se realiza una reunión para identificar los
obstáculos encontrados en el proyecto y planificar las posibles
23
soluciones en cara de un nuevo proyecto y este no afecte en la
productividad.
2.3. MARCO CONCEPTUAL
Entrando en la actualidad del desarrollo de las aplicaciones web vamos a utilizar la
herramienta Polymer junto a los componentes web como Front-End y servicios REST
para las consultas de base de datos y validaciones como Back-End.
2.3.1. POLYMER
Polymer es un conjunto de librerías de código libre mejor conocidas como Polyfills.
Tiene como finalidad crear o reutilizar etiquetas HTML en forma de plantillas para
encontrar la compatibilidad en los principales browsers.
2.3.2. JAVASCRIPT
Es un lenguaje de programación exclusivo para las páginas web que puede ser
ejecutado sin necesidad de tener otro programa instalado. Tiene como finalidad
crear programas de validaciones para brindar una mejor interfaz gráfica al usuario.
2.3.3. SERVICIOS REST
REST es un estilo de arquitectura entre sistemas que usen HTTP para generar
datos en posibles formatos como XML y JSON.
Las operaciones más frecuentes que se usan en los servicios REST son cuatro:
POST (crear), GET (leer y consultar), PUT (editar) y DELETE (eliminar).
24
2.3.4. MYSQL
Es una base de datos Open Source que tiene como característica ser relacional,
multiusuario y multihilo los cuales han favorecido positivamente en su desarrollo y
actualizaciones que la posicionan como una base de datos más utilizadas por
desarrolladores a nivel mundial.
2.3.5. JBOSS
Es una plataforma de tiempo de ejecución del servidor de aplicaciones basada en
código abierto. Tiene como finalidad crear, implementar y alojar aplicaciones y
servicios Java altamente transaccionales. Esta plataforma está basado en código
Java y es utilizado en cualquier sistema operativo que admita Java.
2.3.6. ECLIPSE
Eclipse es un IDE o plataforma de integración de desarrollo compuesta por un
conjunto de herramientas open source con multiplataforma diseñada para
desarrolladores.
2.4. MARCO METODOLÓGICO
2.4.1. TIPO DE INVESTIGACIÓN
• Finalidad: Debido a que la implementación del Sistema SATSOS será
imprescindible como propuesta de solución ante riesgos naturales se
puede definir como una Investigación Aplicada.
• Tipo de diseño: Debido a que se implementará en una población sin
antecedentes sin antecedentes tecnológicos y conociendo los casos de
éxito en otros países se puede definir como Investigación No Experimental.
25
• Naturaleza: Debido a que nos basaremos en los casos de éxitos de otros
países se puede definir como Investigación Cualitativa.
2.4.2. NIVEL DE INVESTIGACIÓN
• Según las características y propiedades que nos brinda el del Sistema
SATSOS como una solución tecnológica ante la prevención de riesgos
naturales se puede definir como una Investigación Descriptiva.
2.5. MARCO LEGAL
(INDECI, 2011)
Se promulgó la ley Nro. 29664 el 08 de febrero del 2011 para crear el Sistema
Nacional de Gestión de Riesgos de Desastres (SINAGERD).
El SINAGERD es un sistema interinstitucional, sinérgico, descentralizado, transversal
y participativo, creado con la finalidad de identificar y reducir los riesgos asociados a
peligros o minimizar sus efectos y evitar la generación de nuevos riesgos, así como la
preparación y atención ante situaciones de desastres, mediante el establecimiento de
principios, lineamientos de política, componentes, procesos e instrumentos de la
Gestión del Riesgo de Desastres.
26
CAPITULO 3
DESARROLLO DE LA PROPUESTA DE INVESTIGACIÓN
3.1. PROCESO DE NEGOCIO
3.1.1. PROCESO DE NEGOCIO ANTES DE LA IMPLEMENTACIÓN
El procedimiento para avisar a los pobladores ante situaciones de huaicos es de
manera manual y espontáneo, es decir, NO tenemos un plan de emergencias a
seguir para que nos ayude a reducir el riesgo de pérdidas humanas y daños
materiales.
En el momento de una situación de emergencia se activan las alarmas de la
central de los bomberos notificando a toda la población en general. Los policías
junto a los serenazgos se trasladan a la zona afectada y van informando a los
pobladores que se retiren a otro lugar más seguro ya que dicha zona será
afectada por un huaico.
Así mismo, al no saber la magnitud de los huaicos y las quebradas activas no se
tiene un reporte anticipado para saber qué zonas son las que deben tener mayor
prioridad dejando al libre albedrio de las autoridades y de la comunidad poder
actuar ante estos acontecimientos.
27
3.1.2. PROCESO DE NEGOCIO DESPUÉS DE LA IMPLEMENTACIÓN
Primero se entregará a la población un plan de contingencia con diferentes
estrategias dependiendo del nivel de alerta del desastre natural (INDECI).
El monitoreo se puede dar de dos maneras: seguimiento por cámara de
seguridad o instalando un instrumento de medición del volumen del agua en los
diferentes puntos de las quebradas (pluviómetros).
Actualmente en Chosica se tiene un área de monitoreo de cámaras de
seguridad, por lo tanto, al detectarse diferentes volúmenes de agua en algunas
quebradas el personal a cargo alertará a un supervisor notificando el incremento
de volumen de agua y la posible presencia de lodo. El supervisor generará una
alerta indicando el nivel de riesgo y una descripción de lo que está sucediendo.
Posteriormente se notificará a las autoridades asignadas a los diferentes puntos
del distrito para que puedan prepararse ante estos acontecimientos.
El jefe de personal asignado de una quebrada tendrá un usuario con el cual
podrá reportar la cantidad de personas e infraestructuras que han sufrido algún
tipo de daño luego de pasado el desastre natural.
3.1.3. ANÁLISIS COMPARATIVO DE LOS PROCESOS
El proceso antes y después de la implementación del Sistema SATSOS se verá
reflejado en el accionar de las autoridades correspondientes y de los mismos
pobladores siguiendo el plan de contingencia definido.
28
Las autoridades y pobladores estarán informadas en tiempo real sobre la
magnitud del desastre y podrán tener mayor tiempo de reacción.
3.1.4. TABLA DE ACTIVIDADES
Tabla 1: Descripción de Actividades
Nro. Descripción
1 Mejorará la comunicación midiendo el porcentaje de mensajes
enviados y leídos satisfactoriamente.
2 Calculará el porcentaje de personas resguardadas al seguir el plan
de contingencia contemplado.
3 Calculará el porcentaje de personas heridas.
4 Calculará el porcentaje de daños materiales
5 Mejorará el control de monitoreo de las quebradas
3.2. CRONOGRAMA DE ACTIVIDADES
Tabla 2: Cronograma Gantt
Nombre de Tarea Duración MES 1 MES 2 MES 3 MES 4 MES 5
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Gestión de Análisis 25 días
Iniciación 11 días x x
Plan de Proyecto 7 días x
Informe del proyecto 7 días x
Documentación de Análisis 22 días
Documento de Requisitos 10 días
x x
Documento de Requerimientos 6 días
x
Documento de Procesos 6 días x
Diseño del Sistema 18 días
Especificación de casos de uso 4 días
x
Diagrama de casos de 4 días x
29
uso
Prototipos de Sistemas 4 días x
Diseño de Base de Datos 4 días
x
Diccionario de Datos 2 días x
Desarrollo de software 45 días
Módulo de Administración 7 días
x
Módulo de Pobladores 7 días x
Módulo de Mensajería 7 días x
Módulo de Usuarios 7 días x
Módulo de Estadística 7 días x
Módulo de Reportes 10 días x
Pruebas de Sistema 15 días
Prueba del Módulo de Sistema 7 días
x
Prueba de Integración del Sistema 8 días
x
Entrega 15 días
Manual de usuario 8 días x
Documento de entrega del Proyecto 5 días
x x
Entrega a Producción 2 días x
3.3. IDENTIFICACIÓN DE REQUERIMIENTOS
3.3.1. REQUERIMIENTOS FUNCIONALES
Tabla 3: Requerimientos Funcionales
REQUERIMIENTOS FUNCIONALES
Nro. Descripción Tipo Dif. Pri.
1 El sistema permitirá el mantenimiento de las
alertas, pobladores y usuarios.
Funcional Medio Medio
2 El sistema permitirá la asignación de perfiles. Funcional Medio Bajo
3 El sistema permitirá desbloquear cuentas de
usuarios con diferentes tipos de roles.
Funcional Medio Bajo
30
4 El sistema permitirá cambiar las credenciales
de autenticación.
Funcional Medio
Alto
5 El sistema permitirá el mantenimiento de
usuarios y serán clasificados según la
quebrada asignada.
Funcional Bajo Bajo
6 El sistema permitirá crear un mensaje de alerta. Funcional Medio
Bajo
7 El sistema permitirá asignar la alerta a un
operador.
Funcional Medio
Bajo
8 El sistema permitirá enviar la alerta asignada
vía mensaje de texto.
Funcional Alto Bajo
9 El sistema generará reportes. Funcional Medio Bajo
3.3.2. REQUERIMIENTOS NO FUNCIONALES
Tabla 4: Requerimiento No Funcionales
REQUERIMIENTOS NO FUNCIONALES
Nro. Descripción Tipo Dif. Pri.
1 El usuario podrá interactuar con el sistema
mediante el ratón y el teclado.
No
Funcional
Alto Medio
2 El desarrollo del sistema tendrá componentes
web en su interfaz gráfica.
No
Funcional
Medio Medio
3 La disponibilidad del sistema para el usuario
será de 24 horas diarias.
No
Funcional
Medio Medio
4 El sistema será accesible desde cualquier
dispositivo o navegador web.
No
Funcional
Medio Medio
31
5 El sistema será ejecutado desde un servidor
Linux con Jboss y MySQL Server.
No
Funcional
Medio Medio
6 El sistema guardara en una base de datos el
log de auditoria.
No
Funcional
Medio Medio
3.4. LENGUAJE DE MODELADO (UML)
4.2.1. DIAGRAMA DE CASOS DE USO
Tabla 5: Caso de uso 01
Nombre caso de uso Ingresar al Sistema
Código caso de uso CU01
Actor(es) Supervisor / Operador
Descripción Ingresar al sistema con un usuario y contraseña.
Precondición Contar con credenciales de ingreso
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Ingresar al sistema Se carga la pantalla de
Inicio de sesión.
Ingresar credenciales de
usuario y contraseña.
Valida credenciales y
permite acceso al
sistema.
Flujo Alternativa Ingresar credenciales de
usuario y contraseña
incorrectas
Mensaje del sistema
“Usuario y/o Contraseña
incorrecta”
Post Condición Mensaje de bienvenida al usuario y carga las
opciones de menú según el rol del usuario.
Flujo excepcional Usuario no tiene acceso
Frecuencia Diaria
Importancia Alta
32
Tabla 6: Caso de uso 02
Nombre caso de uso Registrar mensaje alerta
Código caso de uso CU02
Actor(es) Supervisor
Descripción El sistema permite generar un mensaje de alerta
Precondición Información detallada del acontecimiento y la
quebrada afectada.
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar la opción de
menú: “Mensaje Alerta”
Se carga la pantalla de
mantenimiento de
Mensaje.
Seleccionar botón:
“AGREGAR”
Se carga la pantalla de
formulario de ingreso de
datos del mensaje.
El actor ingresa la
descripción de lo
ocurrido y selecciona el
nivel y la quebrada
afectada.
Valida que los datos
sean correctos.
Seleccionar el botón
“ACEPTAR”
El registro se guarda en
base de datos.
Flujo Alternativa 1 El actor no ingresa
información en los
campos del formulario.
Se muestran alertas de
validación en el
formulario.
Post Condición Mensaje de Alerta creada exitosamente
Frecuencia Ocasional
Importancia Alta
Tabla 7: Caso de uso 03
Nombre caso de uso Asignar Mensaje de Alerta
Código caso de uso CU03
Actor(es) Supervisor
Descripción El sistema permite asignar la alerta a los operadores
Precondición Debe existir una alerta con estado PENDIENTE.
33
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar opción de
menú: “Mensaje Alerta”
Se carga la pantalla de
“Mantenimiento de
mensaje”
Ubicar el mensaje y
seleccionar botón
“Asignar”
Se muestra un mensaje
de alerta indicando que
se asignó
correctamente.
Post Condición Se asigna exitosamente el mensaje de alerta.
Frecuencia Ocasional
Importancia Alta
Tabla 8: Caso de uso 04
Nombre caso de uso Enviar Alerta Masiva
Código caso de uso CU04
Actor(es) Operador
Descripción El sistema permite enviar alerta masiva vía SMS
Precondición Debe existir una alerta con estado ASIGNADO.
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar opción de
menú: “Envío de Alerta”
Se carga la pantalla de
“Envío de alerta masiva“
Seleccionar el botón:
“Enviar Alerta”
Se muestra una alerta
confirmando el envío de
SMS masivo.
Flujo Alternativa No se envía los
mensajes.
El sistema muestra el
error de envío.
Post Condición Se envía exitosamente la alerta masiva.
Flujo excepcional Si al enviar no hay saldo
de la cuenta de SMS
Se muestra el mensaje
de error por falta de
saldo sin actualizar el
estado del mensaje.
Frecuencia Ocasional
Importancia Alta
34
Tabla 9: Caso de uso 05
Nombre caso de uso Generar Reporte
Código caso de uso CU05
Actor(es) Supervisor / Operador
Descripción El sistema permite generar reporte de las alertas.
Precondición Debe existir alertas registradas.
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar opción de
menú: “Reporte”
Se carga la pantalla de
generación de reportes
Seleccionar el tipo de
reporte e ingresar los
datos necesarios.
Carga un formulario para
ingreso de información
necesaria.
Seleccionar botón
“ACEPTAR”
El sistema generará un
reporte en formato PDF.
Flujo Alternativa El Actor no selecciona
correctamente los filtros.
El sistema valida el
ingreso de datos.
Post Condición Se exportará exitosamente el reporte en PDF.
Frecuencia Ocasional
Importancia Media
Tabla 10: Caso de uso 06
Nombre caso de uso Registrar Usuario
Código caso de uso CU06
Actor(es) Supervisor
Descripción El sistema permite crear nuevos usuarios
Precondición Tener información del usuario
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar la opción de
menú: Mantenimiento de
usuario.
Se carga la pantalla de
mantenimiento de
usuario.
Seleccionar botón
“AGREGAR”
Se carga una pantalla de
formulario de ingreso de
datos del usuario nuevo.
El actor ingresa la Permite el ingreso de
35
información del usuario data.
Seleccionar el botón
“ACEPTAR”
El registro se guarda en
base de datos.
Flujo Alternativa 1 El actor ingresa
información errónea en
los campos del
formulario
Se muestran alertas de
validación en los
campos del formulario.
Flujo Alternativa 2 El actor no ingresa data
en campos requeridos
Se muestran alertas de
validación de campos
vacíos.
Post Condición Usuario creado exitosamente
Flujo excepcional Usuario ya existente Mensaje: “Imposible
crear usuario con el
mismo código de
identificación”
Frecuencia Diaria
Importancia Alta
Tabla 11: Caso de uso 07
Nombre caso de uso Desbloquear Usuario
Código caso de uso CU07
Actor(es) Supervisor
Descripción El sistema permite desbloquear un usuario.
Precondición Contar con un usuario bloqueado
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar opción de
menú “Desbloquear
usuario”.
Se carga la pantalla de
desbloqueo de usuario.
Ingresa usuario
bloqueado
Valida el usuario
bloqueado y muestra
motivo de bloqueo.
Seleccionar botón
“DESBLOQUEAR”
Sistema actualiza el
estado del usuario
Flujo Alternativa Ingresa usuario no Valida el usuario
36
bloqueado “Usuario no está
bloqueado”
Post Condición Usuario desbloqueado exitosamente
Frecuencia Diaria
Importancia Alta
Tabla 12: Caso de uso 08
Nombre caso de uso Insertar datos estadísticos
Código caso de uso CU08
Actor(es) Jefe
Descripción El sistema permite ingresar datos estadísticos.
Precondición Acontecimiento natural ocurrido.
Flujo Principal
ACCIÓN ACTOR ACCIÓN SISTEMA
Seleccionar opción de
menú “Datos
Estadísticos”.
Se carga la pantalla de
Datos Estadísticos
Selecciona opción:
Infraestructura o
Poblador.
Permite visualizar los
datos estadísticos de
infraestructuras o
pobladores afectados.
Ingresa datos y
selecciona opción
guardar.
El sistema permite
registrar en base de
datos los datos
ingresados.
Post Condición Se genera un reporte de lo insertado.
Frecuencia Ocasional
Importancia Alta
37
Ilustración 7: Caso de uso Ingreso al Sistema
Ilustración 8: Caso de uso Mensaje de Alerta
38
Ilustración 9: Caso de uso Generación de Reportes
Ilustración 10: Caso de uso Usuario
Ilustración 11: Caso de uso Registro de datos estadísticos
39
4.2.2. DIAGRAMA DE SECUENCIA
Ilustración 12: Diagrama de secuencia del Sistema
Ilustración 13: Diagrama de secuencia post desastre
40
4.2.3. DIAGRAMA DE DESPLIEGUE DEL SISTEMA
Ilustración 14: Diagrama de despliegue
3.5. ARQUITECTURA
En este punto vamos a conocer cómo interactúan los componentes principales de
nuestro aplicativo y el patrón de diseño definido como guía base del desarrollo del
proyecto.
La arquitectura contará con tres niveles: la capa de presentación, la capa lógica del
negocio y la capa de datos quienes se encuentran de manera independiente para
reducir el tiempo de desarrollo.
• Capa de presentación: Es la encargada de capturar información proveniente
del usuario final. Esta capa también es conocida como la capa del usuario ya
41
que debe presentar una interfaz gráfica entendible y únicamente interactúa
con la capa lógica del negocio.
• Capa lógica del negocio: Aquí se establecerán todas las validaciones y
reglas que necesitara nuestro software. Así mismo, se comunicará con la capa
de presentación el cual recibirá parámetros de entrada y mostrará los
resultados. Los mismos que son enviados a la capa de datos para ser
almacenados en la base de datos establecida.
• Capa de datos: Es la capa que se encargará de almacenar la información
proveniente de la capa de negocio conformada por un gestor de base de
datos.
3.5.1. COMPONENTES PRINCIPALES
El sistema web está conformado por tres capas diferentes: cliente, servidor y
datos donde el cliente va a representar al navegador web, el servidor alojará
nuestra aplicación y los datos representará nuestra base de datos.
• Cliente: El sistema está conformado por un cliente web que
comunicará directamente nuestra aplicación con el usuario a través
de un navegador web o móvil.
• Servidor: El servidor de aplicaciones almacenará los componentes
de nuestra aplicación además de dar disponibilidad a nuestras
aplicaciones desplegadas. Actualmente estamos utilizando un
servidor de aplicaciones Linux (Red Hat Enterprise) donde se tiene
configurado Jboss EAP 7.0 el cual tiene alojado varios módulos que
dan continuidad a nuestro aplicativo.
42
• Datos: Esta es la capa encargada de almacenar la información en
una base de datos. Actualmente estamos utilizando la base de datos
Open Source MySQL el cual se encuentra instala en nuestro servidor
Linux.
3.5.2. PATRÓN DE DISEÑO
El patrón de diseño que utilizaremos es el Modelo Vista Controlador o más
conocido como MVC, este patrón divide una aplicación en tres (3) componentes
principales que pueden ser trabajados de manera independiente brindando
mayor rapidez de desarrollo.
• Modelo: Representa a la estructura lógica del software el cual brinda
comunicación como un puente entre la vista, el controlador y la base
de datos.
• Vista: Es la presentación de información contenida en el modelo
hacia el usuario. Estos datos por mostrar pueden ser solo de lectura
como también información editable.
• Controlador: El Controlador acepta solicitudes que hace el usuario a
través del navegador, contacta al Modelo para cualquier dato que
pueda necesitar, y luego toma la Vista adecuada para mostrarle esos
datos al usuario.
43
Ilustración 15: Diagrama patrón MVC
3.5.3. MODELO DE DATOS
Aquí vamos a mostrar las principales entidades que maneja el Sistema
SATSOS.
• Usuario: Contiene información detallada de los pobladores a quienes
enviaremos una alerta ante un desastre natural.
• Documento: Contiene información del tipo de documento de
identidad de una persona registrada en el sistema.
• Administración: Contiene información detallada del personal que
gestionará el sistema para el registro de usuarios, creación de
mensaje de alerta y envío de alertas masivas.
• Rol: Se relaciona directamente a la entidad Administración porque
nos brinda los permisos necesarios para gestionar el sistema.
• Canal: Contiene información del medio por el cual será enviado la
alerta (móvil o correo).
44
• Quebrada: Contiene información de la ubicación geográfica de las
Quebradas en el distrito Chosica.
• Nivel de Alerta: Nos indicará la magnitud de alerta presentada en un
desastre natural.
• Mensaje Alerta: Contiene información de lo ocurrido en un desastre
natural como el lugar afectado y por quien fue creado el mensaje.
• Status: Contiene información para medir en tres (3) diferentes
escalas un determinado desastre natural (Alta, Media y Baja).
• Rep_Personas: Contiene información del total de personas
afectadas en un desastre natural.
• Rep_Viviendas: Contiene información de la cantidad de viviendas o
infraestructuras que han sido afectadas por un desastre natural.
• Auditoria: Contiene información detallada de todo el sistema,
guardando información importante desde el inicio del sistema hasta la
generación de reportes.
Ilustración 16: Modelo Entidad Relación
3.6. INTERFAZ DEL SISTEMA
En esta sección del proyecto se presentará la interfaz gráfica para la implementación
del sistema.
Para la elaboración de la parte visual del proyecto se ha utilizado la herramienta
Visual Studio Code (Polymer 2.0) y para la parte de negocio vamos a trabajar con
servicios REST.
Ilustración 17: Página de Inicio
Ingresamos al sistema con un perfil de Supervisor y vamos a visualizar las
siguientes opciones en el menú:
• Mensaje de Alerta Temprana
• Módulo de Pobladores
• Módulo de Usuarios
• Desbloquear Usuario
• Módulo de Reporte
47
Ilustración 18: Menú principal - Supervisor
El supervisor registrará una alerta
Ilustración 19: Página Mensaje Alerta
Agregamos la alerta con el boton
Ilustración 20: Agregar Mensaje Alerta
48
Verificamos la quebrada registrada en el mensaje seleccionando el botón
Ilustración 21: Opción Ver Mapa
Como último paso asignamos le mensaje generado al operador para que pueda
enviarlo masivamente seleccionando el botón
Ilustración 22: Confirmación de Asignación
49
Ingresamos al sistema con un perfil de Operador y tendremos las siguientes opciones
de menú disponibles:
• Envío de alerta
• Reporte
Ilustración 23: Menú principal - Operador
Seleccionamos la opcion de menu “Envío del alerta”
Ilustración 24: Página Envío de Alerta
Enviamos la alerta seleccionando el botón (mostrará la respuesta
del servicio de envío de SMS)
50
Ilustración 25: Confirmación Mensajes Enviados
El jefe tendrá las siguientes funciones:
• Estadística Personas
Ilustración 26: Mantenimiento Estadística Persona
• Estadística Viviendas
Ilustración 27: Mantenimiento Estadística Vivienda
51
El Supervisor tendrá otras funciones administrativas
• Módulo de usuario.
Ilustración 28: Módulo de Usuario
• Módulo de Pobladores
Ilustración 29: Módulo de Pobladores
• Desbloquear usuario:
Ilustración 30: Página de Desbloqueo
52
• Módulo de Reportes
Ilustración 31: Página de Reporte
Por Estado de Alerta:
Ilustración 32: Reporte por Estado
Por Fecha de Alerta:
Ilustración 33: Reporte por Fecha
53
Reporte de Personas:
Ilustración 34: Filtro Reporte Personas
Reporte de Viviendas:
Ilustración 35: Filtro Reporte Viviendas
Reportes generados:
54
Reporte Anual
Ilustración 36: Reporte anual
55
Reporte Fechas
Ilustración 37: Reporte por rango de fecha
56
Reporte Quebradas
Ilustración 38: Reporte por quebrada
57
Reporte por Familias Damnificadas
Ilustración 39: Reporte Familias Damnificadas
58
Reporte por Familias Afectadas
Ilustración 40: Reporte Familias Afectadas
59
Reporte por Personas Heridas
Ilustración 41: Reporte Personas Heridas
60
Reporte por Personas Fallecidas
Ilustración 42: Reporte Personas Fallecidas
61
3.7. CONSTRUCCION Y PRUEBAS
En esta sección vamos a detallar las tecnologías utilizadas para la construcción del
software, así mismo se explicará el detalle de la implementación del sistema web a
través de clases y códigos importantes.
Por último, se explicarán las pruebas realizadas durante la construcción del
software.
3.7.1. FRAMEWORK
Un framework es un conjunto de conceptos, herramientas y buenas prácticas que
nos ayuda a mantener ordenado nuestro código brindándonos mayor
productividad al permitir reutilizarlo y con ello resolver problemas de índole similar.
SPRING es un Framework que nos permite desarrollar aplicaciones de manera
más rápida, eficaz y corta, saltándonos tareas repetitivas y ahorrándonos líneas
de código.
Ventajas:
• Se basa en ficheros XML o anotaciones.
• Es el encargado de inicializar todos los objetos de los distintos
Frameworks integrados de forma correcta.
MYBATIS es un Framework de persistencia de datos que soporta SQL,
procedimientos almacenados y mapeos avanzados. En este caso vamos a
configurar MyBatis con XML para mapear mapas llamando a consultas de
procedimientos almacenados en MySQL.
62
Ventajas:
• Ahorra un 90% de código.
• Mantiene un control total de las tablas y procedimientos creados.
• Es fácil de utilizar si se dispone del conocimiento de lenguaje SQL
3.7.2. HERRAMIENTAS, PLATAFORMAS Y TECNOLOGÍA
A continuación, se listarán todas aquellas herramientas de software, plataformas y
tecnologías que se emplearon para el desarrollo del software.
• Plataforma: Web
• Lenguaje: Java y Polymer 2.0 (Componentes Web)
• Servidor de aplicaciones: Jboss EAP 7.0
• Framework: Spring y Mybatis
• Modelo de programación: Servicios web REST
• Reportes: JasperReport
• Base de datos: MySQL
• Herramienta de gestión: Gradle
• Herramientas de desarrollo: Eclipse Oxygen, Visual Studio Code y
MySQL workbench
3.7.3. IMPLEMENTACIÓN
En esta sección vamos a describir paso a paso como implementar los métodos de
nuestros servicios REST.
63
• Configuraremos el archivo web.xml:
o Declaramos el listener de Spring el cual será el responsable de
levantar nuestros contextos.
o Declaramos los context-param donde estarán las clases para la
configuración y conexión a la base de datos.
o Declaramos un servlet-maping ingresando el símbolo “/” en el
campo url-pattern.
Ilustración 43: Configuración Spring XML
• Configuraremos la base de datos mediante un archivo properties y
mapearemos el DataSource creado en el servidor JBOSS.
64
Ilustración 44: Configuración y Conexión
Clase PsiDaoConfig:
En esta clase vamos a configurar la conexión llamando al DataSource por
medio del SqlSessionFactoryBean.
Ilustración 45: Clase PsiDaoConfig
Clase ResourceConfig:
65
Mapeamos una ruta fija para nuestro archivo de configuración de propiedades
(config.properties), leemos las variables y establecemos la conexión desde el
servidor Jboss.
Ilustración 46: Clase psiDataSource
Ilustración 47: Conexión JBOSS
66
• Procederemos a crear los métodos en la clase Controller, para esto
definimos las anotaciones “@RestController”, “@RequestMapping” y
“@ResponseBody” soportada por SPRING 4.
Ilustración 48: Clase Controlador
• Procedemos a implementarlos los métodos creados (cada uno seguirá una
lógica similar, así que para fines prácticos explicaremos el método de
LOGIN).
o Crearemos las clases LoginRequestType y LoginResponseType
para el envío y retorno de datos.
67
Ilustración 49: Clase Request y Response
o Implementamos las reglas y validaciones en general utilizando el
objeto HashMap quien se comunicará, por medio del paquete
DAO, con el store Procedure para recuperar los datos necesarios
desde la base de datos.
Ilustración 50: Implementación del Método
68
o Crearemos el store Procedure el cual estará definido por un archivo
XML, el cual tendrá las funcionales de las librerias MyBatis.
Ilustración 51: Configuración MyBatis - Stored Procedure
Ilustración 52: MySQL - Stored Procedure
o Imprimimos los datos de respuesta de nuestro Store Procedure en
formato JSON.
69
Ilustración 53: Prueba SOAP UI
• Consumimos el servicio Rest desde el Front-End polymer, para esto
usamos el componente web IRON-AJAX.
70
Ilustración 54: Capa Presentación – Polymer
Nota:
Para el módulo de Poblador vamos a consumir el servicio web de RENIEC para
poder validar los datos ingresados de los pobladores del distrito de Chosica y
dividirlo de acuerdo con su dirección que registra en el DNI.
WS RENIEC: https://serviciosbiometricos.reniec.gob.pe/identifica/main.do
71
3.7.4. PRUEBAS
Para las pruebas de los servicios Rest utilizamos el software SoapUI y se
realizaron en base a cada uno de los métodos declarados.
Ilustración 55: Métodos para pruebas de concurrencia
Ilustración 56: Resultado de las pruebas
72
Tabla 13: Prueba unitaria
PRUEBA UNITARIA DEL SISTEMA WEB
ID PRUEBA RESULTADO
P001 Verificar el acceso al sistema OK
P002 Verificar la carga de usuarios OK
P003 Verificar la inserción, edición y eliminación de usuarios OK
P004 Verificar la carga de alerta en estado pendiente y asignado. OK
P005 Verificar la inserción, edición y eliminación de alertas OK
P006 Verificar el envío de alertas masivas OK
P007 Verificar el estado de un usuario OK
P008 Verificar la creación de reportes. OK
P009 Verificar la inserción de datos estadisticos. OK
Las pruebas fueron realizadas por el Analista de Sistemas del proyecto (tesista).
Según la metodología utilizada (SCRUM) las pruebas se realizaron en forma
iterativa a medida que se iba implementado el software.
73
CAPITULO 4
ANÁLISIS COSTO Y BENEFICIO
4.1. DETERMINACIÓN DE COSTOS
Vamos a definir los costos estimados que vamos a utilizar para estimar el costo de
inversión y el costo de mantenimiento.
4.1.1. COSTOS DE INVERSIÓN
Es la inversión inicial para poner en funcionamiento el proyecto tomando en
cuenta el pago al personal, alquiler de equipos, compra de software y gastos
generales.
De la tabla 14 definimos lo siguiente:
• Jefe de Proyecto: Persona encargada de cumplir los objetivos planteados
teniendo en cuenta los costos estimados y entregables. Tendrá
participación desde el levantamiento de información hasta el entregable
final (5 meses).
• Analista: Es la persona que acompañará al Jefe de Proyecto en las
reuniones con el cliente y el encargado del desarrollo de la
74
documentación respectiva del proyecto. Tendrá una participación de inicio
del proyecto hasta su entregable final (5 meses).
• Programador: Es la persona que se encargara del desarrollo del software
tomando en consideración la arquitectura y actas entregadas por el
analista. Tendrá una participación desde el inicio de desarrollo del
software hasta el entregable de ajustes finales (2 meses).
Tabla 14: Costo de Inversión Personal
Personal Cantidad
de Personas
Cantidad de días
Cantidad de
horas/día
Total (Horas)
Costo/Hora (Soles)
Total (Meses)
Total (soles)
Jefe de Proyecto
1 150 6 900 50 5 45000
Analista 1 150 6 900 34 5 30600
Programador 2 60 8 480 18 2 8640
TOTAL 84240
• Los equipos en el proceso de desarrollo del software son proporcionados
por la empresa consultora. Luego de la entrega del software los equipos a
utilizar serán las que se encuentren en el centro de monitoreo de
cámaras de seguridad.
• El software por utilizar en la etapa de desarrollo será de código abierto, es
decir, Open Source. Luego de entregado el proyecto se va a reutilizar los
servidores y las computadoras que actualmente se utilizan en el centro de
monitoreo de cámaras de seguridad.
Tabla 15: Costo de Inversión Equipos
Gastos Generales Mes 1 (Soles)
Mes 2 (Soles)
Mes 3 (Soles)
Mes 4 (Soles)
Mes 5 (Soles)
Total (Soles)
Equipos 85 85 85 85 85 425
Software 0 0 0 0 0 0
75
Acceso a Internet 200 200 200 200 200 1000
Consumo Eléctrico 120 120 120 120 120 600
Útiles de escritorio 100 100 100 100 100 500
Alquiler de infraestructura 1200 1200 1200 1200 1200 6000
TOTAL 8525
• El precio unitario por SMS tendrá una variación dependiendo de la
cantidad de SMS a enviarse. Para esta simulación vamos a suponer que
se enviarán a 220 000 mil personas (cantidad aproximada de personas en
Chosica).
Tabla 16: Costo Proveedor Mensaje de Texto
PROVEEDOR Precio unitario
Número de SMS
TOTAL (soles)
GAMANET 0,1 220000 22000
SMSPERU 0,065 220000 14300
NETTEL 0,16 220000 35200
DATEC 0,1 220000 22000
VIA SMS 0,075 220000 16500
De la tabla 16 consideraríamos el menor costo del mercado, por lo tanto,
elegiríamos a la empresa SMSPERU.
4.1.2. COSTOS DE MANTENIMIENTO
Son los gastos que se van a estimar por alguna mejora del software luego de la
entrega final del software. Este gasto lo asume directamente la municipalidad bajo
un presupuesto que ellos van a manejar.
Se recomendaría contar con los servicios de la consultora que realizó el
desarrollo, pero de no ser así se puede contar con los servicios profesionales de
un Analista de sistemas y un desarrollador.
76
Tabla 17: Costos de Inversión Mantenimiento
Personal Cantidad Sueldo % Sistema Total
(soles)
Analista 1 0 100% 0
Programador 1 0 100% 0
Total 0
4.2. BENEFICIOS ESPERADOS
Los Beneficios esperados van a ser divididos en dos secciones, beneficios tangibles
son los que se van a poder medir en términos monetarios y Beneficios intangibles que
son los que tienen un impacto importante en el negocio.
4.2.1. BENEFICIOS TANGIBLES
• Mejora la productividad en el personal asignado en las labores de rescate y
prevención en desastres naturales.
• Reducir el costo de daños materiales.
• Disminuir proporcionalmente la cifra de heridos, damnificados y fallecidos.
• Mejorar el tiempo de respuesta de parte de las autoridades y pobladores
del distrito.
• Mejorar el tiempo de comunicación de la Municipalidad con los pobladores.
4.2.2. BENEFICIOS INTANGIBLES
• Nos detallará los daños causados por los huaicos en reportes.
• Mejora la respuesta de los pobladores ante estos desastres.
• Ahorro de tiempo y esfuerzo en la entrega de comunicación a la totalidad
de la población.
77
• Mayor control lo que reduce el riesgo de la mala utilización de recursos y
delegación de personal.
• Facilita la planificación estratégica.
4.3. COMPARATIVA DE INVERSIÓN VERSUS PÉRDIDAS ECONÓMICAS
En la tabla 14 se calculó que el monto total para la realización del sistema es
aproximadamente 84240.00 soles, en la tabla 15 se calculó el monto de inversión de
gastos generales aproximadamente 8525.00 soles y el costo del proveedor para
enviar SMS por el monto de 14300.00 soles tendríamos un gasto total de 107065.00
soles (tabla 18), monto justificable considerando que el sistema alertará en tiempo
real previniendo a los pobladores ante estos desastres.
Tabla 18: Costo de Inversión Total
Costo de Inversión Total (soles)
Personal 84240.00
Equipos 8525.00
Proveedor de SMS 14300.00
TOTAL 107065.00
Según la tabla 19 en el 2015 hubo un total de 9 personas fallecidas, 25 heridas, 341
familias afectadas y 161 familias damnificadas por los constantes huaicos.
Según la tabla 21 en el año 2017 se presentó el niño costero dejando pérdidas
humanas y económicas fuertísimas en varias regiones del Perú. Solo en Chosica se
registraron 6 personas fallecidas, 42 personas heridas, 2 personas desaparecidas,
250 familias damnificadas y 618 familias afectadas.
78
Tabla 19: Reporte de Hechos
Descripción Ubicación AÑO
2013 2015 2017
Familias Damnificados
Chosica X x x
Familias Afectados Chosica X x x
Personas Heridas Chosica X x x
Personas Fallecidas Chosica X x x
Viviendas Destruidas Chosica X x x
Viviendas Afectadas Chosica X x x
Colegios afectados Chosica x x x
Hospitales Afectados Chosica X x x
Tabla 20: Reporte de personas afectadas en el 2015
AÑO 2015
UBICACIÓN Familias
Damnificadas Familias
afectadas Personas fallecidas
Personas heridas
Chosica 161 341 9 25
Tabla 21: Reporte de viviendas afectadas en el 2015
AÑO 2015
UBICACIÓN Viviendas
colapsadas Viviendas
inhabitables Viviendas Afectadas
Instituciones educativas afectadas
Chosica 107 54 341 48
Tabla 22: Reporte de personas afectadas en el 2017
AÑO 2017
UBICACIÓN Familias
Damnificadas Familias
afectadas Personas fallecidas
Personas heridas
Personas desaparecidas
Chosica 216 355 6 42 2
79
Tabla 23: Reporte de viviendas afectadas en el 2017
AÑO 2017
UBICACIÓN Viviendas
colapsadas Viviendas
inhabitables Viviendas afectadas
Instituciones Educativas afectadas
Chosica 140 83 513 55
Luego de los huaicos de los años 2015 y 2017 se generaron perdidas económicas
que superaron los 200 millones de soles respectivamente declarando a Chosica en
Estado de Emergencia por un promedio de 60 días. Estos gastos fueron destinados
en las instalaciones de carpas provisionales, alimento, ropa y en la reparación de
colegios, instituciones públicas y hogares, sin tomar en cuenta el apoyo humanitario
entregado en forma de donaciones.
Conociendo los gastos que se generan aproximadamente después de un desastre
natural deducimos que la implementación de este sistema reducirá en,
aproximadamente, un 20% los gastos generados para el apoyo de personas
afectadas y las reconstrucciones de viviendas e infraestructuras dañadas.
Tabla 24: Proyección de Ahorro
AÑO
2015 2017 2019 2021
Sin Implementación 200.000.000 200.000.000 200.000.000 200.000.000
Con Implementación 200.000.000 200.000.000 160.000.000 128.000.000
Ahorro Soles - - 40.000.000 72.000.000
80
De la tabla 24 proyectamos un ahorro significativo en los siguientes años luego de la
implementación del Sistema SATSOS.
De seguir con el sistema que maneja la Municipalidad se estima que en los próximos
huaicos del 2019 y 2021 (debido que estos se generan cada dos años) se mantendrá
el mismo gasto de 200 millones de soles aproximadamente tal cual se refleja en los
dos últimos acontecimientos.
Con la implementación del Sistema SATSOS se proyecta un ahorro significativo del
20% obteniendo un ahorro de 40 y 72 millones de soles respectivamente haciendo
este sistema viable para su implementación.
81
CONCLUSIONES
De la tesis expuesta se concluye lo siguiente:
• El Sistema web SATSOS se ajusta a los requerimientos necesarios para poder
informar sobre los acontecimientos ocurridos emitiendo una alerta en tiempo real
para que las autoridades y pobladores tomen acciones y se apeguen al plan de
contingencia.
• El personal municipal encargado del monitoreo de cámaras de seguridad estará
capacitado para reaccionar ante un desastre natural y poder generar las alertas al
sector del distrito afectado.
• El Sistema web SATSOS brindará un canal de comunicación directa desde la
municipalidad hacia los pobladores para informarnos de los acontecimientos
naturales o alguna otra emergencia importante.
• El Sistema web SATSOS controlará la información de la cantidad de personas y
viviendas perjudicadas en un desastre natural.
• El Sistema web SATSOS será el pionero en tecnología web del distrito que
interactuará directamente con la población dando pie a mejoras como son los
aplicativos móviles.
82
RECOMENDACIONES
Para que perdure la importancia de este sistema se recomienda lo siguiente:
• Una vez puesto en marcha el proyecto web SATSOS se hace necesario un
monitoreo continuo de las principales quebradas del distrito de Chosica en los
meses de lluvia que van de octubre a marzo.
• Capacitar al personal asignado para que pueda desplegarse correctamente en el
momento de un desastre natural con simulacros programados por defensa civil y
la municipalidad de Chosica.
• Coordinar con OSIPTEL, INEI y RENIEC para la validación correcta de los
números telefónicos y direcciones de los pobladores con apoyo del último censo
realizado.
• Continuar la investigación y amoldar el sistema web como una solución ante
diversos desastres naturales y/o emergencia.
83
ANEXOS
• Anexo 1: Estado de emergencia Chosica año 2017 ingresado en la Resolución administrativa Nro. 050-2017-CE-PJ
84
• Anexo 2: Decreto Supremo año 2015
85
86
87
GLOSARIO
• AFECTADO: Según INDECI, es aquella persona con alguna perturbación luego
de un desastre natural.
• ANOTACIONES: Son etiquetas que permiten al desarrollador definir el
funcionamiento del software.
• BACK-END: Es la parte del software que se encarga de procesar y validar los
valores enviados de la capa de presentación.
• DAMNIFICADO: Según INDECI, es toda aquella persona que ha sido afectada
parcial o íntegramente por un desastre natural que ha repercutido en su salud o
en sus bienes.
• DATASOURCE: Es el nombre de una cadena de conexión establecida en base de
datos para un servidor.
• FRONT-END: Es la parte del software que se encarga de interactuar con el
usuario y tiene como finalidad enviar los datos al Back-End para su
procesamiento.
• GEOLOCALIZACIÓN: Es la capacidad de encontrar una ubicación geográfica
real.
• GRADLE: Sistema de automatización de construcción de código abierto basada
en Groovy reemplazando el XML utilizado en Maven.
• HTTP: Es el protocolo de transferencia de hipertextos más común que se utilizan
para el intercambio de información de páginas web.
• HASHMAP: Es uno de los objetos más usados en java que tiene como función el
almacenamiento de datos.
• IBM: Empresa multinacional estadounidense enfocado en el desarrollo de
tecnologías y consultorías.
88
• INDECI: Es un organismo del estado que tiene como propósito responder ante
situaciones de desastre naturales.
• IDE: Es un entorno de desarrollo integrado que brinda una interfaz gráfica más
amigable al desarrollador para la creación de software.
• IRON-AJAX: Es un componente web que tiene como finalidad realizar peticiones
Ajax como servicios web para obtener respuestas de diferentes maneras.
• JASPERREPORT: Es una biblioteca embebida en aplicaciones de lenguaje Java
que tiene como finalidad la creación de informes o reportes.
• JSON: Es un tipo de formato de datos más ligeros para el procesamiento de
datos.
• LINUX: Es un sistema operativo GNU de código libre que cuenta con el software
necesario para el óptimo funcionamiento de programas.
• LISTENER: Son los métodos que se encargan de controlar los eventos para
realizar diferentes acciones.
• OPEN SOURCE: Es un software basado en la colaboración abierta de
programadores que tiene como finalidad terminar un bien en común.
• ONG: Es una organización que no depende del gobierno que realiza actividades
sociales de interés nacional.
• PLUVIOMETROS: Instrumento de medición de agua en un determinado lugar que
usualmente se utiliza en las estaciones meteorológicas.
• REQUEST: Es un objeto que pertenece a la clase HttpServletRequest que tiene
como finalidad recibir parámetros en una determinada sesión.
• RESPONSE: Es un objeto que pertenece a la clase HttpServletRequest que tiene
como finalidad mostrar parámetros de salida.
• SOAP UI: herramienta desarrollada en java para la realización de pruebas a
aplicaciones con múltiples protocolos como SOAP, REST, HTTP, etc.
89
• SOFTWARE: Es el conjunto de rutinas y componentes lógicos que tiene como
finalidad la realización de una tarea en específico.
• STORE PROCEDURE: Es un conjunto de comandos SQL que pueden ser
almacenados en un servidor o base de datos.
• XML: Es un archivo compuesto de etiquetas personalizadas para la organización
de datos que tiene como finalidad de generar un objeto simple que pueda ser
almacenada, transmitida, procesada y visualizada en algún dispositivo.
90
BIBLIOGRAFÍA
Albaladejo, X. (31 de Julio de 2008). ProyectosAgiles.org. Recuperado el 28 de Julio de
2018, de https://proyectosagiles.org/que-es-scrum/
Apolo, D. D. (2016). Sistema de Alerta Temprana para Inundaciones - Experiencia en
America Latina. Obtenido de Sistema de Alerta Temprana para Inundaciones - Experiencia en America Latina: https://solucionespracticas.org.pe/Sistemas-de-Alerta-Temprana-para-inundaciones-(SAT)-Experiencias-en-America-Latina
ElPeruano. (19 de Febrero de 2011). Creación del Sistema Nacional de Gestion del
Riesgo. Recuperado el 20 de Julio de 2018, de Creación del Sistema Nacional de Gestion del Riesgo: https://busquedas.elperuano.pe/normaslegales/ley-que-crea-el-sistema-nacional-de-gestion-del-riesgo-de-de-ley-n-29664-605077-1/
ElPeruano. (2 de Mayo de 2017). Robo de Mallas de Seguridad. Recuperado el 10 de
Febrero de 2018, de Robo de Mallas de Seguridad: http://larepublica.pe/sociedad/871526-robo-de-mallas-de-acero-de-proteccion-antihuaico-en-chosica
INDECI. (08 de Febrero de 2011). Ley SINAGERD. Recuperado el 12 de Julio de 2018,
de Ley SINAGERD: https://www.indeci.gob.pe/norma_leg/ley_sinagerd.pdf
INDECI. (8 de Mayo de 2015). Informe de Emergencia 581. Recuperado el 10 de Junio
de 2018, de Informe de Emergencia 581: https://www.indeci.gob.pe/objetos/alerta/MTM1Nw==/20150508202416.pdf
INDECI. (11 de Diciembre de 2017). Compendio Estadistico 2017. Recuperado el 10 de
Junio de 2018, de Compendio Estadistico 2017: https://www.indeci.gob.pe/objetos/secciones/OQ==/NDY=/lista/MzMx/MTAwMg==/201802271714541.pdf
Jiménez Cano, R. (20 de Mayo de 2016). El País. Recuperado el 15 de Marzo de 2018,
de El País: https://elpais.com/tecnologia/2016/05/19/actualidad/1463638108_879663.html
MINTRA. (15 de Junio de 2017). Ministerio del Interior. Recuperado el 17 de Diciembre
de 2017, de Ministerio del Interior: http://conasec.mininter.gob.pe/obnasec/pdfs/Nro.02-DistritoLurigancho.pdf
91
MTC. (10 de Junio de 2016). Ministerio de Transportes y Comunicaciones. Recuperado el
15 de Marzo de 2018, de http://portal.mtc.gob.pe/comunicaciones/sismate/queessismate.html
RENIEC. (s.f.). Catálogo de servicios. Obtenido de Catálogo de servicios:
http://sib.reniec.gob.pe/download/ServiciosBiometricos/CatalogoServiciosBiometricos_v1.0.0.pdf
SGP. (2015). Sociedad Geológica del Perú. Obtenido de Sociedad Geológica del Perú:
http://www.sgp.org.pe/wp-content/uploads/HUAICOS-DE-CHOSICA-CR%C3%93NICA-DE-UN-DESASTRE-ANUNCIADO.pdf
UNGRD. (11 de Junio de 2015). Sistema de Alerta Temprana. Recuperado el 15 de
Marzo de 2018, de http://portal.gestiondelriesgo.gov.co/Paginas/SAT.aspx
UNISDR. (2006). Oficina de las Naciones Unidas para la Reducción del Riesgo de
Desastres. Recuperado el 17 de Diciembre de 2017, de Oficina de las Naciones Unidas para la Reducción del Riesgo de Desastres: http://www.unisdr.org/files/608_spanish.pdf
WebComponents. (4 de Febrero de 2018). webcomponents.org. Obtenido de
webcomponents.org: https://www.webcomponents.org/about
top related