“Análisis, Diseño y Desarrollo del Sistema Web SATSOS...

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?


alertas en tiempo real disminuirá el posible número de damnificados?


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


permita disminuir el posible número de víctimas y damnificados.


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


Nombre caso de uso Registrar mensaje alerta


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


Seleccionar la opción de

menú: “Mensaje Alerta”

Se carga la pantalla de

mantenimiento de

Mensaje.

Seleccionar botón:

“AGREGAR”


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


Nombre caso de uso Asignar Mensaje de Alerta



Descripción El sistema permite asignar la alerta a los operadores

Precondición Debe existir una alerta con estado PENDIENTE.

33

Flujo Principal


Seleccionar opción de

menú: “Mensaje Alerta”


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


Importancia Alta


Nombre caso de uso Enviar Alerta Masiva


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



menú: “Envío de Alerta”


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


Importancia Alta

34


Nombre caso de uso Generar Reporte


Actor(es) Supervisor / Operador

Descripción El sistema permite generar reporte de las alertas.

Precondición Debe existir alertas registradas.

Flujo Principal



menú: “Reporte”


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.


Importancia Media


Nombre caso de uso Registrar Usuario



Descripción El sistema permite crear nuevos usuarios

Precondición Tener información del usuario

Flujo Principal


Seleccionar la opción de

menú: Mantenimiento de

usuario.


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


validación en los

campos del formulario.

Flujo Alternativa 2 El actor no ingresa data

en campos requeridos


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


Nombre caso de uso Desbloquear Usuario



Descripción El sistema permite desbloquear un usuario.

Precondición Contar con un usuario bloqueado

Flujo Principal



menú “Desbloquear

usuario”.


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


Nombre caso de uso Insertar datos estadísticos


Actor(es) Jefe

Descripción El sistema permite ingresar datos estadísticos.

Precondición Acontecimiento natural ocurrido.

Flujo Principal



menú “Datos

Estadísticos”.


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.


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

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

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

https://proyectosagiles.org/que-es-scrum/

https://solucionespracticas.org.pe/Sistemas-de-Alerta-Temprana-para-inundaciones-(SAT)-Experiencias-en-America-Latina

https://solucionespracticas.org.pe/Sistemas-de-Alerta-Temprana-para-inundaciones-(SAT)-Experiencias-en-America-Latina

https://busquedas.elperuano.pe/normaslegales/ley-que-crea-el-sistema-nacional-de-gestion-del-riesgo-de-de-ley-n-29664-605077-1/

https://busquedas.elperuano.pe/normaslegales/ley-que-crea-el-sistema-nacional-de-gestion-del-riesgo-de-de-ley-n-29664-605077-1/

http://larepublica.pe/sociedad/871526-robo-de-mallas-de-acero-de-proteccion-antihuaico-en-chosica

http://larepublica.pe/sociedad/871526-robo-de-mallas-de-acero-de-proteccion-antihuaico-en-chosica

https://www.indeci.gob.pe/norma_leg/ley_sinagerd.pdf

https://www.indeci.gob.pe/objetos/alerta/MTM1Nw==/20150508202416.pdf

https://www.indeci.gob.pe/objetos/secciones/OQ==/NDY=/lista/MzMx/MTAwMg==/201802271714541.pdf

https://www.indeci.gob.pe/objetos/secciones/OQ==/NDY=/lista/MzMx/MTAwMg==/201802271714541.pdf

https://elpais.com/tecnologia/2016/05/19/actualidad/1463638108_879663.html

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

http://portal.mtc.gob.pe/comunicaciones/sismate/queessismate.html





http://portal.gestiondelriesgo.gov.co/Paginas/SAT.aspx

http://www.unisdr.org/files/608_spanish.pdf

https://www.webcomponents.org/about

“Análisis, Diseño y Desarrollo del Sistema Web SATSOS...

Documents

Transcript of “Análisis, Diseño y Desarrollo del Sistema Web SATSOS...