sistema de alarma comunitaria controlada desde...
TRANSCRIPT
1
SISTEMA DE ALARMA COMUNITARIA CONTROLADA DESDE
DISPOSITIVOS MÓVILES
Luis Alberto Aldana
Jonathan García Buitrago
Universidad Distrital Francisco José de Caldas
Facultad de tecnología
Ingeniería en telemática
Bogotá
2
SISTEMA DE ALARMA COMUNITARIA CONTROLADA DESDE DISPOSITIVOS
MÓVILES
Proyecto de grado
Luis Alberto Aldana
Jonathan García Buitrago
TUTOR
Miguel Ángel Leguizamón Páez
Universidad Distrital Francisco José de Caldas
Facultad de tecnología
Ingeniería en telemática
Bogotá
3
RESUMEN
El proyecto de alarma comunitaria controlada por dispositivos móviles asociados se refiere
al uso de tecnologías que apoyen temas de seguridad ciudadana, no sólo con el objetivo
de reprimir o prevenir delitos, sino también para evitar vandalismo en la propiedad pública
o privada, actuando rápidamente frente a situaciones de emergencia o realizar una
temprana detección de eventos de riesgo; la característica principal de este sistema es el
uso de dispositivos móviles para la activación de las alarmas, las cuales se adaptan a otro
dispositivo móvil con sistema operativo Android que funciona como alarma central;
también se hace uso de herramientas como Firebase, que brinda servicios de bases de datos
no relacionales en tiempo real para móviles y aplicaciones, permitiendo la comunicación
entre dispositivos de forma instantánea y el almacenamiento de datos para análisis de
información; También se usan servicios que ofrece Google Cloud Platform, en nuestro
caso Google AppEngine, que nos da la posibilidad de desplegar una aplicación web para
la administración, sobre la infraestructura de Google, permitiéndonos ventajas como lo
son la escalabilidad y balanceadores de carga, además de sus protocolos de seguridad, esto
con el fin de cumplir con los principios de la seguridad de la información
(confidencialidad, disponibilidad e integridad); Todas estas tecnologías en conjunto nos
permiten crear un sistema de seguridad a un bajo costo que permite reutilizar dispositivos
móviles con sistema Android que cuenten con funciones básicas como internet, llamadas
y SMS.
Palabras clave: Android, dispositivos móviles, seguridad, alarma.
4
AGRADECIMIENTOS
A los docentes que han hecho parte de nuestra
formación y orientación para lograr nuestros objetivos.
A nuestras familias por su apoyo incondicional
y por ser el pilar de nuestras vidas.
Luis Alberto Aldana
Primero que todo a Dios por hacer esto posible y a mi familia
por acompañarme en cada paso que doy y finalmente a mi
compañero de equipo por ejecutar el proyecto y hacer
posible esta gran idea.
Jonathan García Buitrago
5
TABLA DE CONTENIDO
1. Definición planeación y organización ......................................................................................................... 13
1.1. Título del trabajo ............................................................................................................................................ 13
1.2. Planteamiento del problema.................................................................................................................... 13
1.3. Análisis del problema ............................................................................................................................... 14
1.4. Soluciones actuales .................................................................................................................................... 15
1.5. Objetivo general ......................................................................................................................................... 15
1.6. Objetivos específicos ................................................................................................................................ 15
1.7. Alcances ........................................................................................................................................................ 16
1.8 Antecedentes ................................................................................................................................................ 16
1.8.1 Alarma Comunitaria ............................................................................................................................... 16
1.8.2 Alarmapp ................................................................................................................................................... 17
1.8.3 Commisur .................................................................................................................................................. 17
1.8.4 CityCop ...................................................................................................................................................... 18
1.8.5 Haus APP ................................................................................................................................................... 18
1.9 Marco teórico .................................................................................................................................................... 19
1.9.1 ¿Qué es una Alarma Comunitaria? .................................................................................................... 19
1.9.2 ¿Que es un frente de seguridad?................................................................................................. 20
1.9.3 ¿Que es el PLAN NACIONAL DE VIGILANCIA COMUNITARIA POR
CUADRANTE? .................................................................................................................................................. 20
1.9.4 Servicio en la Nube ........................................................................................................................ 21
1.9.5 Google Cloud y Aplicaciones auto escalables (App Engine) ................................................ 22
1.9.6 Firebase ...................................................................................................................................................... 23
1.9.7 ANDROID .................................................................................................................................................. 24
1.9.8 TELEFONÍA MÓVIL ............................................................................................................................... 24
1.9.9 GSM ............................................................................................................................................................. 25
1.9.10 UMTS........................................................................................................................................................ 26
1.9.11 LTE ............................................................................................................................................................ 27
1.9.12 IONIC2 ..................................................................................................................................................... 27
1.9.12 Protoboard ............................................................................................................................................ 28
1.9.13 Resistencia............................................................................................................................................. 28
1.9.14 Capacitor ................................................................................................................................................ 28
6
1.10 Estudio de factibilidad ................................................................................................................................. 30
1.10.1 Factibilidad técnica .............................................................................................................................. 30
1.10.1.1 Dispositivo.............................................................................................................................. 30
1.10.1.2 Canal de comunicaciones ....................................................................................................... 30
1.10.1.3 Plataforma .............................................................................................................................. 30
1.10.1.4 Recurso Humano .................................................................................................................... 30
1.10.2 Factibilidad Financiera..................................................................................................................... 31
1.10.3 Factibilidad de gestión ..................................................................................................................... 31
1.10.4 Factibilidad económica .................................................................................................................... 31
1.11 Cronograma ................................................................................................................................................... 34
2. Fase de análisis ........................................................................................................................................................ 35
2.1 Definición de los objetivos del Product Backlog .................................................................................. 36
2.2 Historias de usuario......................................................................................................................................... 37
2.2.1 Historia de usuario 100 .......................................................................................................................... 37
2.2.2 Historia de usuario 101 .......................................................................................................................... 38
2.2.3 Historia de usuario 102 .......................................................................................................................... 38
2.2.4 Historia de usuario 103 .......................................................................................................................... 38
2.2.5 Historia de usuario 104 .......................................................................................................................... 39
2.2.6 Historia de usuario 105 .......................................................................................................................... 39
2.2.7 Historia de usuario 106 .......................................................................................................................... 39
2.2.8 Historia de usuario 107 .......................................................................................................................... 40
2.2.9 Historia de usuario 108 .......................................................................................................................... 40
2.3 Definición general del software ............................................................................................................. 41
2.3.1 Definición de Sprint ....................................................................................................................... 41
2.3.2 Meta general software ................................................................................................................... 41
2.3.3 Alcance general software ............................................................................................................. 41
2.3.4 Vista de escenarios definido por ......................................................................................................... 41
2.3.5 Vista lógica definida por:...................................................................................................................... 41
2.3.6 Vista de desarrollo definida por: ........................................................................................................ 41
3. Sprint Backlog: 1 .................................................................................................................................................... 42
3.1 Ejecución del sprint......................................................................................................................................... 43
3.1.1 Mockups: Vista Inicial........................................................................................................................... 44
3.2 Vista de escenarios .......................................................................................................................................... 44
3.2.1 Diagrama de casos de uso: Usuario registro ................................................................................... 44
3.2.2 Usuario activación – desactivación ................................................................................................... 45
7
3.3 Vista Lógica ...................................................................................................................................................... 45
3.3.1 Diagrama de clases ................................................................................................................................. 45
3.3.2 Diagrama de flujo definido en FireBase .......................................................................................... 46
3.3.3 Diagrama de Contexto ........................................................................................................................... 46
3.4 Vista de Desarrollo .......................................................................................................................................... 47
3.5 Ejecución de tareas en este Sprint .............................................................................................................. 48
3.5.1 Mockups listado de situaciones. ......................................................................................................... 48
3.5.2 Mockups para capturar los datos ........................................................................................................ 48
3.5.3 Mockups activación-desactivación. ................................................................................................... 49
3.6 Retroalimentación de este sprint. ................................................................................................................ 49
3.7 Diagrama de Gantt Sprint ............................................................................................................................. 50
4. Sprint Backlog 2 ...................................................................................................................................................... 51
4.1 Ejecución del sprint......................................................................................................................................... 52
4.1.1 Mockups: Vista Inicial........................................................................................................................... 53
4.2 Vista de escenarios .......................................................................................................................................... 53
4.2.1 Diagrama de casos de uso: Configuración alarma central .......................................................... 53
4.2.2 Usuario escucha evento activación - desactivación ...................................................................... 55
4.3 Vista Lógica ...................................................................................................................................................... 55
4.3.1 Diagrama de clases ................................................................................................................................. 55
4.3.2 Diagrama de flujo definido en FireBase .......................................................................................... 56
4.3.3 Diagrama de Contexto ........................................................................................................................... 56
4.4 Vista de Desarrollo .......................................................................................................................................... 57
4.5 Ejecución de tareas en este Sprint .............................................................................................................. 58
4.5.1 Mockups Ingreso de identificador de Alarma. ............................................................................... 58
4.5.2 Mockups mostrar estado ....................................................................................................................... 59
4.6 Retroalimentación de este sprint. ................................................................................................................ 60
4.7 Diagrama de Gantt Sprint ............................................................................................................................. 60
5. Sprint Backlog 3 ...................................................................................................................................................... 61
5.1 Ejecución del sprint 2 ..................................................................................................................................... 62
5.2 Vista de escenarios .......................................................................................................................................... 63
5.2.1 Diagrama casos de uso .......................................................................................................................... 63
5.3 Vista Lógica ...................................................................................................................................................... 63
5.3.1 Diagrama de contexto ............................................................................................................................ 63
5.4 Vista de desarrollo ........................................................................................................................................... 64
8
5.4.1 Diagrama de componentes ................................................................................................................... 64
5.4.2 Ejecución de las tareas del sprint Backlog ...................................................................................... 64
5.4.2.1 Login ........................................................................................................................................ 65
5.4.2.2 Consultar Usuarios ................................................................................................................... 66
5.4.2.3 Actualizar Usuarios .................................................................................................................. 67
5.4.2.4 Consulta histórico eventos ........................................................................................................ 67
5.5 Retroalimentación del sprint ........................................................................................................................ 68
5.6 Diagrama de Gantt sprint .............................................................................................................................. 68
6. Sprint Backlog: 4 .................................................................................................................................................... 69
6.1 Ejecución del sprint......................................................................................................................................... 70
6.2 Diagrama del circuito ..................................................................................................................................... 71
6.3 Circuito final ..................................................................................................................................................... 71
6.4 Retroalimentación de este sprint. ................................................................................................................ 72
6.5 Diagrama de Gantt Sprint ............................................................................................................................. 72
7. Esfuerzo general ...................................................................................................................................................... 73
7.1 Estimación de tiempo ..................................................................................................................................... 73
8. Descripción del sistema ........................................................................................................................................ 73
8.1 Implementación. ............................................................................................................................................... 73
9. Recomendaciones del proyecto .......................................................................................................................... 75
10. Anexos ..................................................................................................................................................................... 75
11. Conclusiones .......................................................................................................................................................... 76
12. Bibliografía ............................................................................................................................................................. 77
9
TABLA DE TABLAS
Tabla 1 Factibilidad Económica Recursos Humanos, fuente: Los Autores ........................................ 32 Tabla 2 Factibilidad Económica Recursos Técnicos, fuente: Los Autores ......................................... 32 Tabla 3 Gastos adicionales, fuente: Los Autores ............................................................................... 33 Tabla 4 Factibilidad Económica Costo Total, fuente: Los Autores .................................................... 33 Tabla 5 Producto Backlog, fuente: Los Autores ................................................................................ 37 Tabla 6 Historia de usuario 100, fuente: Los Autores ....................................................................... 37 Tabla 7 Historia de usuario 101, fuente: Los Autores ....................................................................... 38 Tabla 8 Historia de usuario 102, fuente: Los Autores ....................................................................... 38 Tabla 9 Historia de usuario 103, fuente: Los Autores ....................................................................... 38 Tabla 10 Historia de usuario 104, fuente: Los Autores ..................................................................... 39 Tabla 11 Historia de usuario 105, fuente: Los Autores ..................................................................... 39 Tabla 12 Historia de usuario 106, fuente: Los Autores ..................................................................... 39 Tabla 13 Historia de usuario 107, fuente: Los Autores ..................................................................... 40 Tabla 14 Historia de usuario 108, fuente: Los Autores ..................................................................... 40 Tabla 15 Backlog 100, fuente: Los Autores ...................................................................................... 42 Tabla 16 Backlog sprint 100, fuente: Los Autores ............................................................................ 43 Tabla 17 Backlog 101, fuente: Los Autores ...................................................................................... 51 Tabla 18 Backlog sprint 100, fuente: Los Autores ............................................................................ 52 Tabla 19 Backlog 102, fuente: Los Autores ...................................................................................... 61 Tabla 20 Backlog sprint 2, fuente: Los Autores ................................................................................. 62 Tabla 21 Backlog 103, fuente: Los Autores ...................................................................................... 69 Tabla 22 Backlog sprint 103, fuente: Los Autores ............................................................................ 69
10
TABLA DE IMÁGENES
Figura 1 Cronograma, fuente: Los Autores ....................................................................................... 34 Figura 2 Aplicación móvil emisora, fuente: Los Autores ................................................................... 44 Figura 3 Caso de uso usuario registro, fuente: Los Autores ............................................................. 44 Figura 4 Caso de uso activación - desactivación, fuente: Los Autores ............................................. 45 Figura 5 Diagrama de clases emisor, fuente: Los Autores ................................................................ 45 Figura 6 Diagrama de flujo emisor, fuente: Los Autores ................................................................... 46 Figura 7 Diagrama de contexto emisor, fuente: Los Autores ........................................................... 46 Figura 8 Vista de desarrollo emisor, fuente: Los Autores ................................................................. 47 Figura 9 Listado de eventos, fuente: Los Autores ............................................................................. 48 Figura 10 Registro de datos emisor, fuente: Los Autores ................................................................. 48 Figura 11 Botones de activación o desactivación, fuente: Los Autores ............................................ 49 Figura 12 Diagrama de Gantt sprint 1, fuente: Los Autores ............................................................. 50 Figura 13 Aplicación móvil receptora, fuente: Los Autores .............................................................. 53 Figura 14 Caso de uso configuración app, fuente: Los Autores ....................................................... 53 Figura 15 Caso de uso usuario activa por llamada, fuente: Los Autores ......................................... 54 Figura 16 Caso de uso usuario activo por SMS, fuente: Los Autores ............................................... 54 Figura 17 Caso de uso escucha evento activación - desactivación, fuente: Los Autores .................. 55 Figura 18 Diagrama de clases receptor, fuente: Los Autores ........................................................... 55 Figura 19 Diagrama de flujo receptor, fuente: Los Autores .............................................................. 56 Figura 20 Diagrama de contexto receptor, fuente: Los Autores ....................................................... 56 Figura 21 Vista de desarrollo receptor, fuente: Los Autores ............................................................ 57 Figura 22 Ingreso identificador, fuente: Los Autores ........................................................................ 58 Figura 23 Estado alarma, fuente: Los Autores .................................................................................. 59 Figura 24 Diagrama de Gantt sprint 2, fuente: Los Autores ............................................................. 60 Figura 25 Capturar de casos de uso bluetooth, fuente: Los Autores ................................................ 63 Figura 26 Login y consulta de datos, fuente: Los Autores ................................................................ 63 Figura 27 Diagrama aplicación web, fuente: Los Autores ................................................................. 64 Figura 28 Localización de archivos, fuente: Los Autores .................................................................. 65 Figura 29 Mockups login, fuente: Los Autores .................................................................................. 66 Figura 30 Home de aplicación, fuente: Los Autores ......................................................................... 66 Figura 31 Consulta Usuarios, fuente: Los Autores ............................................................................ 66 Figura 32 Actualiza Usuarios, fuente: Los Autores ............................................................................ 67 Figura 33 Consultar alarmas, fuente: Los Autores ............................................................................ 67 Figura 34 Modo móvil, fuente: Los Autores ...................................................................................... 68 Figura 35 Diagrama de Gantt sprint 3, fuente: Los Autores ............................................................. 68 Figura 36 Diagrama prototipo del circuit, fuente: Los Autores......................................................... 71 Figura 37 Prototipo físico, fuente: Los Autores................................................................................. 71 Figura 38 Diagrama de Gantt sprint 4, fuente: Los Autores ............................................................. 72 Figura 39 Diagrama del sistema en general, fuente: Los Autores. ................................................... 74 Figura 40 Diagrama del sistema administrador, fuente: Los Autores ............................................... 74
11
INTRODUCCIÓN
Uno de los aspectos con mayor importancia en las políticas de gobierno es el tema de
seguridad ciudadana, las cifras de la Secretaría de Seguridad, Convivencia y Justicia del
Distrito muestran que localidades como Ciudad Bolívar, Kennedy, Bosa, Usme, Rafael
Uribe y San Cristóbal se encuentran como las más peligrosas, registrando en el 2016 los
casos con más homicidios con el 73%, lesiones personales 61%, hurtos a residencias el
61%, hurto a autos 56% y hurto a motos 61%, siendo las que tienen menores sistemas de
vigilancia.1
Debido a esta situación se han implementado diferentes propuestas, estrategias y sistemas
que ayuden a reducir las amenazas que afectan a los ciudadanos, para mejorar la calidad
de vida de estos, promoviendo la incorporación de tecnologías a favor del fortalecimiento
de la Seguridad Ciudadana y entre ellas destacan los sistemas de alarmas comunitarias,
como un componente tecnológico del programa de Frentes de Seguridad Local, liderado
por la Policía Nacional, conocido como PNVCC - Plan Nacional de Vigilancia
Comunitaria por Cuadrantes, siendo el eje fundamental de articulación para el
cumplimiento de las metas institucionales alineadas con la política nacional de seguridad.
Según el Documento Conpes 3437, presenta a consideración del Consejo Nacional de
Política Económica y social la aprobación para la implementación del proyecto “Sistema
Integrado de Emergencias y Seguridad” -SIES -, donde uno de uno de sus componentes
son las alarmas comunitarias, que bajo las políticas de gobierno han sido definidas por el
Ministerio del Interior a través del Consejo Nacional de Política Económica y Social, como
un subsistema que funciona por medio de sensores los cuales son activados por la
comunidad ante la sospecha de un acto delictivo, que una vez activados, transmiten
inmediatamente la señal de alerta a los organismos competentes para atender esta
situación2, es preciso estudiar alternativas de soluciones telemáticas que permitan integrar
las comunicaciones al momento de hacer la implementación de las alarmas comunitarias,
aprovechando las tecnologías actuales, para lograr una solución de bajo costo, que facilite
la implementación de alarmas comunitarias.
Por ello, el principal objetivo de este proyecto es desarrollar una aplicación que permita
apoyar el PNVCC a través de una alarma instalada en un dispositivo móvil, que permite
ser activada desde dispositivos móviles asociados en tiempo real, haciendo uso de
tecnologías como el internet, SMS y llamadas, almacenando un histórico de datos que
pueden ser usados para el análisis y toma de decisiones.
1 CARACOL RADIO, “Advierten que localidades más inseguras de Bogotá tienen menos vigilancia.”, {En línea}.{06/07/2017} disponible en: (http://caracol.com.co/emisora/2017/02/11/bogota/1486831994_950416.html) 2 Implementación del sistema integrado de emergencias y seguridad-SIES de Colombia, {En línea}.{07/07/2017} disponible en: http://www2.congreso.gob.pe/sicr/cendocbib/con2_uibd.nsf /1FC942F59C0E200C05257784006950D3/$FILE/3437.pdf
12
ABSTRACT
One of the most important aspects of government policies is the issue of citizen security, the
figures from the Ministry of Security, Coexistence and Justice of the District show that cities
such as Ciudad Bolívar, Kennedy, Bosa, Usme, Rafael Uribe and San Cristóbal they are the
most dangerous, registering in 2016 the cases with more homicides with 73%, personal injuries
61%, residential robberies 61%, car theft 56% and motorcycle theft 61%, being those with
minors surveillance systems.
Due to this situation, different proposals, strategies and systems have been implemented to help
reduce the threats that affect citizens, to improve their quality of life, promoting the
incorporation of technologies in favor of strengthening Citizen Security and among them
highlight the community alarm systems, as a technological component of the program of Local
Security Fronts, led by the National Police, known as PNVCC - National Plan for Community
Surveillance by Quadrants, being the fundamental axis of articulation for the fulfillment of
institutional goals aligned with the national security policy.
According to the Document Conpes 3437, it presents to the National Council of Economic and
Social Policy the approval for the implementation of the project "Integrated System of
Emergencies and Security" -SIES-, where one of its components are community alarms, which
under government policies have been defined by the Ministry of the Interior through the
National Council of Economic and Social Policy, as a subsystem that works by means of sensors
which are activated by the community when a criminal act is suspected, which once activated,
immediately transmit the warning signal to the competent agencies to address this situation, it
is necessary to study alternative telematics solutions that allow integrating communications at
the time of implementation of community alarms, taking advantage of current technologies, to
achieve a solution of low cost, that facilitates the implementation of community alarms.
Therefore, the main objective of this project is to develop an application that supports the
PNVCC through an alarm installed in a mobile device, which can be activated from mobile
devices associated in real time, making use of technologies such as the Internet, SMS and calls,
storing a historical data that can be used for analysis and decision making.
13
1.Definición planeación y
organización
1.1. Título del trabajo
SISTEMA DE ALARMA COMUNITARIA CONTROLADA DESDE
DISPOSITIVOS MÓVILES.
1.2. Planteamiento del problema
“De acuerdo con cifras de la Secretaría de Seguridad, Convivencia y Justicia del
Distrito, Ciudad Bolívar, Kennedy, Bosa, Usme, Rafael Uribe y San Cristóbal son
las localidades más peligrosas, donde en 2016 se registraron más homicidios con
el 73% de los casos, lesiones personales 61%, hurtos a residencias el 61%, hurto a
autos 56% y hurto a motos 61%, son las que tienen menores sistemas de vigilancia
como por ejemplo cámaras de seguridad.”3
Ante la inseguridad la ciudad ha venido implementando métodos para contrarrestar
casos que atentan contra la convivencia y seguridad ciudadana, uno de estos métodos
son las alarmas comunitarias, la cuales son usadas para alertar de eventos como pueden
ser un robo (perimetral o interno), incendio, terremoto, inundación, fuga de gas, atraco,
etc.); Esto con el fin de apoyar el Plan Nacional de Vigilancia Comunitaria por
Cuadrantes, que es una estrategia operativa del servicio de Policía, orientada a asegurar
las condiciones de convivencia y el mantenimiento de la seguridad ciudadana4, con
asignación de responsabilidades en un área específica dentro del Modelo de Vigilancia
Comunitaria.
3 CARACOL RADIO, “Advierten que localidades más inseguras de Bogotá tienen menos vigilancia.”, {En línea}.{06/07/2017} disponible en: (http://caracol.com.co/emisora/2017/02/11/bogota/1486831994_950416.html) 4 “Modelo nacional de vigilancia comunitaria por cuadrantes“, {En línea}.{06/07/2017} disponible en: (http://policia.edu.co/documentos/TOMO%202.2.%20Seguridad%20Ciudadana.pdf )
14
“Vecinos cuentan que hace dos meses instalaron un sistema que envía mensajes de
texto a la Policía y activa sirenas en caso de que se presenten hechos delictivos.”5
Actualmente se dispone de una alarmas de sistema satelital GSM como es el caso del
barrio Victoria, pero solo funciona con mensajes de texto, también existe la opción del
uso de pulsadores inalámbricos, pero esto hace que su costo aumente, además de que
no se analiza la información que puede ser importante para la comunidad que permitan
identificar los principales problemas que afectan a la comunidad para toma de
decisiones al establecer un plan de acción para casos de emergencia, además de limitar
la posibilidad de activar la alarma de otras formas posibles como desde internet de su
casa sin importar la red y establecer tipo de alarma los eventos anteriormente
mencionados.
Es preciso estudiar alternativas de soluciones telemáticas que permitan integrar las
comunicaciones al momento de hacer la implementación de las alarmas comunitarias,
aprovechando las tecnologías actuales, como lo son el uso de teléfonos inteligentes y
las redes, por lo tanto:
¿Es posible contribuir a la seguridad ciudadana haciendo uso de elementos
telemáticos, para la creación de una alarma comunitaria controlada desde dispositivos
móviles asociados?
1.3. Análisis del problema
Actualmente existen gran variedad de alarmas comunitarias en el mercado, que
funcionan a través de internet, Bluetooth, llamadas y SMS, que suelen ser activadas
con pulsadores conectados vía Bluetooth, o de forma física como cables, todas estas
soluciones, implican costos extras de inversión en dispositivos y elementos para su
funcionamiento, a los cuales no todas las personas pueden tener acceso, además de que
no ofrecen la opción de análisis de datos en tiempo real, a partir de los registros para
la toma de decisiones que puedan contribuir a mejorar la seguridad ciudadana.
También se pretende abarcar el tema ambiental, debido al frecuente cambio de
dispositivos, el bajo costo, y la obsolescencia programada que hace que muchísimos
teléfonos sean desechados anualmente, ya que se puede aprovechar las características
de estos dispositivos, para que sean las terminales de las alarmas, contribuyendo al
reciclaje de equipos que ya no se usen, disminuyendo costos.
5 EL HERALDO “En La Victoria le “ganan la lucha” a delincuentes con alarma satelital”, {En línea}. {06/07/2017} disponible en: (https://www.elheraldo.co/local/en-la-victoria-le-ganan-la-lucha-delincuentes-con-alarma-satelital-187661)
15
1.4. Soluciones actuales
Consideramos que las soluciones actuales que se encuentran en el mercado son viables,
sin embargo, no son accesibles para todas las personas debido a su costos, en cuanto
a dispositivos, instalación y mantenimiento, además de que no tienen en cuenta la
importancia de los datos que se registran pues no permiten analizar la información
que puede ser útil en la toma de decisiones y limitada escalabilidad en el momento
que se quiera ampliar el número de usuarios o terminales.
La solución que se propone, busca reciclar dispositivos móviles con sistema operativo
Android, que a través de una aplicación, se convierten en terminales de alarmas,
mientras que otra aplicación asociada será es la encargada de activar dicha terminal,
guardando registros que pueden ser analizados desde un administrador web.
1.5. Objetivo general
Desarrollar e implementar una aplicación móvil que permita la manipulación de
una alarma comunitaria que pueda ser controlada desde dispositivos móviles
asociados, haciendo uso de componentes telemáticos como tecnologías de
telecomunicaciones (GSM/UMTS/LTE), plataforma en la nube y base de datos en
tiempo real.
1.6. Objetivos específicos
Implementar componentes telemáticos (protocolos, tecnologías, seguridad de
la información) vistos en la carrera para el desarrollo de la aplicación.
Diseñar un módulo dentro de la aplicación que permita al usuario activar y
desactivar la alarma de forma controlada.
Diseñar e implementar la arquitectura para la integración las tecnologías
propuestas (GSM,UMTS,LTE, servicio en la nube, base datos en tiempo real)
para la comunicación de datos, necesaria en la activación y desactivación de la
alarma comunitaria
Crear un módulo para la administración de usuarios.
Crear un módulo que permita el acceso a la información para analizar los datos
obtenidos como las causas de la activación de la alarma (un robo perimetral o
interno, incendio, terremoto, inundación, fuga de gas, atraco), horas, fechas en
las que se presenta esas causas y lugares en los cuales se activa más seguido.
16
1.7. Alcances
Contribuir al medio ambiente mediante el reciclaje de dispositivos móviles con
sistema operativo Android, que pueden ser usados como terminales de alarmas.
Brindar una herramienta a la comunidad, que sea de fácil acceso y manejo.
Usar nuevas tecnologías que permitan la comunicación en tiempo real.
Permitir el análisis de datos registrados para la toma de decisiones.
Contribuir a la seguridad ciudadana haciendo uso de los conocimientos
adquiridos.
1.8 Antecedentes
Actualmente existen muchas soluciones, que buscan contribuir con la seguridad
ciudadana, con el desarrollo y crecimiento de las ciudades, ha ido evolucionando también
el concepto de seguridad que hoy en día permite modelos con la participación y
colaboración de los ciudadanos. Se plantea el uso de la tecnología para obtener el mayor
provecho de los recursos con los que ya cuentan la ciudad para mejorar la seguridad de
la comunidad e integrar a los ciudadanos que usan la tecnología en la lucha contra la
inseguridad. Tecnologías de características especiales como alta complejidad interna y
sencillez de manejo para el usuario final, instantaneidad e integración con otros sistemas
de inteligencia y logística.
A continuación se definen algunos dispositivos y aplicaciones, que dan soluciones a la
seguridad ciudadana:
1.8.1 Alarma Comunitaria
Alarma Comunitaria es una aplicación Android que te permitirá crear una central de
alarmas utilizando únicamente un teléfono con capacidad de envió de mensajes de texto
SMS.
El mismo aplicativo puede funcionar como Cliente o como Servidor. En el teléfono
registrado como Servidor matricule tantos contactos como desee. Estos serán los usuarios
válidos del sistema. Asigne de esta lista aquellos a los que quiere enviar una alarma ante
una situación de pánico.
17
Eso es todo lo que necesita para empezar a utilizar el aplicativo. Si lo desea puede utilizar
el mismo aplicativo en modo Cliente. Con ello obtendrá funciones adicionales como una
alarma sonora en caso de alarma así como la posibilidad de conocer el nombre de la
persona en problemas.
El teléfono configurado como Servidor tiene la lista de contactos válidos del sistema así
como la lista de ellos a los que se desea enviar un mensaje de alarma. Los usuarios
registrados en el Servidor son los únicos habilitados para iniciar una alarma comunitaria.
Un usuario en problemas realiza una llamada al número móvil del Servidor. El Servidor
revisa en su lista de contactos si la persona que está llamando es un contacto válido del
sistema. Si es así, el Servidor envía un mensaje de texto a los usuarios configurados para
la recepción de la alarma con información de la persona que tiene problemas6.
1.8.2 Alarmapp
¿Quién no ha salido a la calle al escuchar la alarma de su barrio, solo para darse cuenta
que era una falsa alarma? Pensando en dar solución a esta problemática un grupo de
emprendedores en Cali diseñaron la propuesta de 'Alarmapp', una aplicación que permite
identificar la causa de la emergencia que enciende las sirenas.
Las personas han empezado a ignorar el sonido de la alarma. No saben si la presionaron
por error, si es una riña o si se trata de un robo. Al desconocer la causa de la activación
pierde mucha de su utilidad, señaló.
El docente explicó que esta app permitirá mediante controladores electrónicos encender la
alarma desde cualquier dispositivo móvil pero a la vez el usuario deberá especificar el
motivo por el cual es activada7.
1.8.3 Commisur
La aplicación se puede descargar desde IOS y Android. Cada persona debe registrarse y
crear una comunidad, integrada por las personas que decida, vecinos, amigos, compañeros
de trabajo, etcétera.
6 “Alarma comunitaria”, {En línea}. {08/07/2017} disponible en: (http://www.brainatoms.com/communityalarm/index.html) 7 “Alarmapp” ,{En línea}.{08/07/2017} disponible en: (http://www.elpais.com.co/cali/alarmapp-la-aplicacion-que-pondra-en-cintura-las-alarmas-comunitarias-en.html)
18
Al instalar la APP, se puede observar que posee las alertas de incendio, robo, accidente y
pánico. Esta última opción es una especie de comodín, que se utiliza en cualquier situación
que no sea los señalados anteriormente.
En caso de que el usuario tenga alguno de estos problemas, presiona la opción que
corresponda. Esta alerta llega a todos los usuarios que están registrados en esa comunidad.
Uno de los plus que tiene este desarrollo es que permite que las personas sean partícipes
del proceso8.
1.8.4 CityCop
Esta app se creó con el mismo fin que las alarmas comunitarias que utilizan los vecinos de
un barrio: generan un red de seguridad entre las potenciales víctimas. Es decir promover
la seguridad de manera interactiva.
El usuario podrá a su vez recibir en tiempo real las alertas de otras personas que estén
informando lo mismo, generando así un ecosistema retroalimentado por sus propios
usuarios9.
1.8.5 Haus APP
Haus fue creada a comienzo del 2015 por un grupo de emprendedores chilenos que por la
experiencia de un robo dentro de una de nuestras casas, se dieron cuenta de la importancia
de contar con una red de ayuda vecinal inmediata frente a una emergencia. Haus
transforma el celular de cada vecino en una alarma comunitaria, dando un paso más allá
de las sirenas instaladas en la plaza, haciendo que ante una emergencia el teléfono de todos
los vecinos conectados a la red suene como sirena, indicando el tipo de emergencia que
puede ser de seguridad, salud o incendio.
Funciona con un botón de Pánico Vecinal que a diferencia de whatsapp envía un mensaje
SOS en 3 segundos a toda la red vecinal, que es ilimitada, indicando el nombre y la
dirección de la persona que necesita ayuda y haciendo sonar el celular de todos los vecinos
conectados como una potente sirena de emergencia10.
8 “App mantiene a la comunidad conectada y en alerta en caso de emergencia” ,{En línea}.{10/07/2017} disponible en: (http://www.plataformacientifica.cl/app-mantiene-la-comunidad-conectada-y-en-alerta-en-caso-de-emergencia/ ) 9 “CityCop, una app gratuita que emula a las alarmas comunitarias” ,{En línea}.{11/07/2017} disponible en: (http://losandes.com.ar/article/lego-a-la-argentina-citycop-la-aplicacion-que-ayuda-a-prevenir-delitos-811022) 10 “Haus, la app que te conecta con tus vecinos”, {En línea}.{11/07/2017} disponible en: (https://www.harmonia.la/entorno/haus_la_app_que_te_conecta_con_tus_vecinos)
19
1.9 Marco teórico
1.9.1 ¿Qué es una Alarma Comunitaria?
Una “ ALARMA ” es un grupo de elementos electrónicos diseñados para realizar acciones
específicas como detectar anomalías, intrusión o allanamiento en áreas restringidas de una
propiedad o bien; por medio de diferentes tipos de sensores que detectan y crean una señal
por medio de la cual se informa sobre la presencia real o inminente de una amenaza ( robo
perimetral o interno, incendio, evacuación, inundación, temperatura, fuga de gas,
emergencia médica, atraco, coacción, pánico, etc.); y realizan acciones que permite
generar alerta sonora o visual para advertir de un peligro, adicionalmente registrar y
transmitir dando aviso a quienes puedan tomar las acciones correspondientes,
(propietarios, autoridades públicas, bomberos, paramédicos, técnicos) Para minimizar
consecuencias de dicha acción o amenaza. Cuando el sistema se diseña para la protección
de edificios de apartamentos, conjunto residencial, centro comercial, empresarial o
industrial, barrios y en general a “FRENTES DE SEGURIDAD” se denomina “ALARMA
COMUNITARIA”.
Actualmente existen dispositivos como ALARMAS COMUNITARIAS SONORAS DE
ACTIVACIÓN POR CONTROL REMOTO 100m y GSM, estos equipos (receptor y/o
repetidor) son activados por las señales de los transmisores inalámbricos, ya sean los
sensores detectores y/o controles remotos tipo llaveros que pertenecen a todos los
participantes del sistema, donde cada participante puede tener más de un control remoto
según sus necesidades y de acuerdo con los requerimientos individuales y/o presupuesto
de cada participante del sistema, pero tienen gran costo y no analizan datos que pueden
ser relevantes para tomar decisiones11.
En la universidad Javeriana encontramos un MODELO DE INTEGRACIÓN
TECNOLÓGICA DEL SUBSISTEMA DE ALARMAS COMUNITARIAS CON LOS
SISTEMAS DE SEGURIDAD Y EMERGENCIAS (SIES) basado en el uso de tecnología
IP PBX haciendo uso del software Elastix y para la creación de las bases de datos se utiliza
el módulo Mysql incluido en este, pero administrado por la interfaz gráfica de Webmin12.
y en la UNIVERSIDAD TÉCNICA DEL NORTE DISEÑO E IMPLEMENTACIÓN DE
UN SISTEMA DE ALARMA COMUNITARIA A BASE DE MÓDULOS
INALÁMBRICOS UTILIZANDO TECNOLOGÍA ZIGBEE , Zigbee opera en la banda
11 “Alarma comunitaria multi partición cctv inalámbrico”, {En línea}.{18/07/2017} disponible en: (http://alarmascomunitarias.weebly.com/) 12 GÓMEZ RODRÍGUEZ, Wilmar Alejandro, URIBE MALDONADO, Juan Sebastián, “Modelo de integración tecnológica del subsistema de alarmas comunitarias con los sistemas de seguridad y emergencias (SIES)”{En línea}.{20/07/2017} disponible en: (https://repository.javeriana.edu.co/handle/10554/15574)
20
de frecuencia ISM de 2.4 GHz, misma que se encuentra saturada por la utilización de otros
dispositivos inalámbricos13.
1.9.2 ¿Que es un frente de seguridad?
Se denomina “FRENTE DE SEGURIDAD” a un procedimiento de los residentes o
comunidad de un sector para la prevención o detección temprana del delito, vandalismo,
protección, y seguridad, con la colaboración de la comunidad activa de manera inmediata
( Plan Comunal de Seguridad Pública del sector ), y/o el accionar de la Fuerza Pública
basado en el PNVCC ( Plan Nacional de Vigilancia Comunitaria por Cuadrantes) con
mayor proyección en la actualidad, adoptando una metodología de generación de alerta
ya sea organizados por cuadra, manzana, conjunto residencial o barrio con el apoyo de
medios tecnológicos una “ ALARMA COMUNITARIA ”14.
1.9.3 ¿Que es el PLAN NACIONAL DE VIGILANCIA
COMUNITARIA POR CUADRANTE?
El Plan Nacional de Vigilancia Comunitaria por Cuadrantes? Es una estrategia operativa
del servicio de Policía, orientada a asegurar las condiciones de convivencia y el
mantenimiento de la seguridad ciudadana en contextos urbanos y rurales, con asignación
de responsabilidades en un área específica dentro del Modelo de Vigilancia Comunitaria.
En qué consiste? El Plan Nacional de Vigilancia Comunitaria por Cuadrantes – PNVCC,
es un sistema que la Policía Nacional implementa para prestar un servicio a los
Colombianos, aprovechando al máximo los recursos disponibles y generando integración
con la comunidad.
¿Qué es un Cuadrante? Es un espacio geográfico en el cual pueden confluir varias cuadras
o Barrios de una localidad, fijo que a partir de sus características sociales, demográficas
y geográficas, recibe distintos tipos de atención de servicio policial entre los que se
encuentran la prevención, la disuasión y el control de delitos y contravenciones, bajo
principios de integralidad, corresponsabilidad y trabajo con calidad. Los cuadrantes se
definen de acuerdo con el análisis de variables como apreciación diagnóstica, actividad
socioeconómica, tasa delincuencial y tasa poblacional.
13 CASTILLO IMBAQUINGO,Diego Xavier ,“Diseño e implementación de un sistema de alarma comunitaria a base de módulos inalámbricos utilizando tecnología zigbee“ {En línea}.{19/07/2017} disponible en: (http://repositorio.utn.edu.ec/bitstream/123456789/1886/1/04%20RED%20011%20ALARMA%20COMUNITARIA%20A%20BASE%20DE%20M%C3%93DULOS%20INAL%C3%81MBRICOS%20UTILIZANDO%20TECNOLOG%C3%8DA%20ZIGBEE.pdf, 06/04/2017). 14 “Única alarma comunitaria multi partición” ,{En línea}.{22/07/2017} disponible en: (https://alarmascomunitarias.weebly.com/)
21
¿Para qué sirven los Cuadrantes? Sirve para dinamizar el servicio de Policía bajo los
principios de eficacia y efectividad, para generar un servicio de Policía Integral mediante
la prevención, disuasión y reacción15.
Gracias al continuo monitoreo y a la evaluación científica que ha tenido el Plan nacional
de Vigilancia Comunitaria por Cuadrantes, se le otorgó el premio más importante en
criminología a nivel mundial.
“Salón de la Fama de la Actuación policial Basada en Evidencia” “premio que otorga
la Universidad George Mason de Estados Unidos, le será entregado por primera vez a la
Policía Nacional de Colombia por el importante proyecto que se ha venido realizando
con el Plan nacional de Vigilancia Comunitaria por Cuadrantes”16.
1.9.4 Servicio en la Nube
Se presenta como un autoservicio a la carta, es decir, un consumidor puede utilizar
unilateralmente capacidades de computación como almacenamiento en red, tiempo de
servidor lo cual depende de las necesidades que presente el sistema y sin necesidad de
requerir de la interacción humana como los proveedores de servicios lo que indica que es
de forma automática. El amplio acceso a la red es otro punto importante a tener en cuenta
ya que las aplicaciones se encuentran disponibles en la red y el acceso a ellas es a través
de mecanismos estándar que fomentan el uso por parte de las diferentes plataformas
existentes. Un conjunto de recursos físicos de cómputo son compartidos por varios
consumidores, asignados de manera dinámica, en función de la demanda. La capacidad de
Cloud Computing radica en suministrar estos recursos de manera elástica, rápida y de
forma automática. Para el consumidor estas capacidades se muestran ilimitadas y se
pueden adquirir en cualquier cantidad y momento. “Los sistemas de nube controlan y
optimizan el uso de los recursos de manera automática utilizando una capacidad de
evaluación en algún nivel de abstracción adecuado para el tipo de servicio”17.
● Software como Servicio (SaaS): Es el modelo en el que una aplicación está
alojada como servicio para que los clientes accedan a ella por internet. Cuando el
software está alojado fuera del sitio, el cliente no tiene que mantenerlo o darle
soporte. Por otra parte, está en manos del usuario decidir en qué sitio va a alojar el
servicio. La idea es usar el software fuera de la caja sin necesidad de hacer una
serie de cambios o de integraciones con otros sistemas. El proveedor aplica parches
y actualizaciones mientras mantiene la plataforma corriendo.
15 “Única alarma comunitaria multi partición” ,{En línea}.{22/07/2017} disponible en: (https://alarmascomunitarias.weebly.com/) 16 “Policía Nacional de Colombia recibe importante premio“,{En línea}.{02/08/2017} disponible en: (http://laud.udistrital.edu.co/noticias/polic%C3%ADa-nacional-de-colombia-recibe-importante-premo) 17 “CSA Cloud security alliance. Guía para la seguridad en áreas críticas de atención en Cloud Computing” {En línea},{01/08/2017} disponible en: P7 (http://www.cloudsecurityalliance.org/guidance/csaguide-es.v2.pdf)
22
● Plataforma como Servicio (PaaS). La plataforma como servicio es otro
modelo de entrega de aplicaciones. PaaS proporciona todos los recursos requeridos
para construir aplicaciones y servicios completamente desde internet, sin tener que
descargar o instalar software.
● Infraestructura como Servicio (IaaS). Es un modelo basado en la premisa,
que la infraestructura completa (Hardware, almacenamiento, comunicaciones,
espacio físico, etc) es desplegada en un modelo por demanda. Esto casi siempre
toma la forma en un ambiente virtualizado y de servicios relacionados, que
habilitan al usuario crear máquinas virtuales como componentes, que son
administrados por medio de una consola. Los recursos físicos (servidores,
almacenamiento y red) son administrados por el proveedor de nube, mientras que
el sistema operativo y aplicaciones implantadas sobre esos componentes es
manejada por el usuario18.
1.9.5 Google Cloud y Aplicaciones auto escalables (App Engine)
¿Qué es Google Cloud Platform? Es, básicamente, una plataforma que ha reunido todas
las aplicaciones de desarrollo web que Google estaba ofreciendo por separado,
aumentando de esta forma su nivel de competitividad.Google Cloud Platform es utilizada
para crear soluciones a través de la tecnología almacenadas en la nube, algunos servicios
ofrecidos son: Big Query, Cloud storage, Cloud SQL, App Engine y Compute Engine.
¿Qué es Google App Engine? Google App Engine es otro de los servicios que conforman
la familia de Google Cloud Platform. Este servicio es del tipo Plataforma como Servicio
o Platform as a Service (PaaS), nos permite publicar aplicaciones web en línea sin
necesidad de preocuparnos por la parte de la infraestructura y con un enfoque 100% en la
construcción de nuestra aplicación y en la posibilidad de correrla directamente sobre la
infraestructura de Google, es decir, la que Google usa para sus propios productos.
Cuando usamos Google App Engine (GAE) no nos tenemos que preocupar por la
escalabilidad de nuestra aplicación ya que cuenta con un balanceador de carga y
escalamiento automático.Así nuestra aplicación solamente será atendida por las máquinas
necesarias para tener un perfecto comportamiento y para que la respuesta de nuestra
aplicación sea la más óptima19.
18 “CSA Cloud security alliance. Guía para la seguridad en áreas críticas de atención en Cloud Computing” {En línea},{01/08/2017} disponible en: P7 (http://www.cloudsecurityalliance.org/guidance/csaguide-es.v2.pdf) 19 “Qué es y cómo funciona Google App Engine”,{En línea},{02/08/2017} disponible en: (https://platzi.com/blog/google-app-engine/)
23
1.9.6 Firebase
Básicamente es una base de datos remota, alojada en la nube y capaz de ser accedida desde
navegadores y apps para dispositivos, que tiene como principal característica que
almacena y sincroniza datos entre usuarios y dispositivos en tiempo real a través de una
base de datos noSQL alojada en la nube. Los datos actualizados se sincronizan entre
distintos dispositivos conectados en milisegundos y permanecen disponibles si la app
pierde la conexión a la red, lo que brinda una experiencia del usuario de alta calidad sin
importar el estado de la conectividad.
Firebase dispone de diferentes funcionalidades, entre las que se encuentran:
● Base de datos en tiempo real: una base de datos gestionada por Google basada
en JSON que nos permite, mediante eventos, tener funcionalidades en tiempo real.
También nos permite llevar una gestión automática de los datos en el caso de que
la aplicación se encuentre sin conexión, sincronizando todos los cambios una vez
haya recuperado dicha conectividad.
● Sistema de autentificación de usuarios tanto por email/contraseña como por
otros sistemas como facebook, twitter, google, github, etc.
● Cloud Messaging para el envío de notificaciones push a los dispositivos de
una forma sencilla.
● Un sistema de almacenamiento y sincronización de ficheros con el
dispositivo.
● Un sistema de hosting estático, ideal para realizar páginas estáticas o utilizarlo
a modo de CDN de la app.
● Sistema de reporting de errores.
● Laboratorio de pruebas, para realizar pruebas en los dispositivos.
● Funciones lambda basadas en NodeJS para realizar mediante eventos ciertas
operaciones.
● Conexión con AdMob para la monetización de la aplicación.
● Configuración remota de la aplicación, pudiendo cambiar dinámicamente
funcionalidades de la misma.
● Accesible desde los dispositivos del cliente. Se puede acceder de forma
directa a Firebase Realtime Database desde un dispositivo móvil o desde el
navegador web, no se necesita un servidor de apps. La seguridad y la validación
de datos están disponibles a través de las Security Rules de Firebase Realtime
Database, reglas basadas en expresiones que se ejecutan cuando se leen o se
escriben los datos20.
20 Firebase, “Firebase te ayuda a crear mejores apps para dispositivos móviles y hacer crecer tu empresa.” {En línea},{04/08/2017} disponible en: (https://firebase.google.com)
24
1.9.7 ANDROID
Android constituye una pila de software pensada especialmente para dispositivos móviles
y que incluye tanto un sistema operativo, como middleware y diversas aplicaciones de
usuario. Todas las aplicaciones para Android se programan en lenguaje Java y son
ejecutadas en una máquina virtual especialmente diseñada para esta plataforma, algunos
de sus componentes:
● Aplicaciones: Forman la capa superior, esta capa la controla plenamente el
usuario.
● Framework de aplicaciones: El marco de aplicaciones da acceso completo a
los programadores a las mismas APIs utilizadas por las aplicaciones básicas.
● Bibliotecas: El sistema incluye un set de librerías en C y C++ que
proporcionan la mayor parte de las funcionalidades y que son utilizadas por varios
componentes del sistema, entre las que encontramos:
○ System C library: Librería estándar de C, optimizada para dispositivos
móviles.
○ SGL: Motor gráfico 2D.
○ 3D Libraries: Esta librería utiliza hardware para la aceleración 3D.
○ SQLite: Sistema gestor de base de datos.
○ FreeType: Librería para fuentes de texto21.
1.9.8 TELEFONÍA MÓVIL
Evolución:
● GSM La Segunda Generación de móviles comenzó con la implantación del GSM
como sistema utilizado para la comunicación de la voz entre dispositivos móviles. AI
principio de los años 80, existían en Europa hasta seis sistemas de comunicación
analógicos, incompatibles entre ellos. Con el crecimiento del Mercado Común Europeo y
la integración económica de Europa, era de vital importancia desarrollar un sistema de
telefonía común, en el que no existieran incompatibilidades, aunque el usuario cambiase
de país.
● GPRS La evolución hacia el siguiente paso de la telefonía móvil se vió forzada por
la presión del término 'Internet Móvil'. El intento de conseguir una transferencia de datos
de manera satisfactoria era imposible con GSM y la única situación de navegar con móvil
21 Android, “Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma android de google.” {En línea},{04/08/2017} disponible en: (https://e-archivo.uc3m.es/bitstream/handle/10016/6506/PFC_Jaime_Aranaz_Tudela_2010116132629.pdf)
25
no se realizaba. GSM resultó, por lo tanto, un sistema muy eficiente para la voz, pero no
para los datos.
● UMTS o Tercera Generación , El UMTS (Universal Mobile TeleCommunication
System) equivale a la Tercera Generación de móviles. Surgió ante la saturación de
frecuencias originadas por el GSM dentro de Europa. Así en enero de 2000, el ETSI
(European Telecommunications Standards) adoptó el UMTS como nuevo modelo para las
futuras comunicaciones móviles. El UMTS es la versión europea del IMT-2000, el
estándar adoptado por la ITU (International Telecommunication Union), que pretende
constituirse como el patrón tecnológico internacional de las telecomunicaciones.
● Conversión de 2.5G a 3G , queda claro que invertir en telefonía móvil supone
hacerlo partiendo desde la 3G. Nuestra solución está basada en una plataforma 2.5G, si
bien es cierto, no es lógico limitarse a modelos anteriores pudiendo empezar desde el
primer momento con los mejores servicios y aplicaciones. Sobre todo, teniendo en cuenta
que esta tecnología es relativamente barata comparada con otras como una red local en
toda la empresa o la creación de una página Web.
● Cuarta Generación, la Cuarta Generación es el futuro inmediato de las
comunicaciones móviles, ya que supone no sólo una mejora en la velocidad de
transmisión, sino también el acercamiento inequívoco entre los ordenadores y los
terminales móviles, de manera que cada vez sea más sencillo acceder a los recursos que
proporciona la Red sin que sea necesario atender a factores temporales y geográficos. Una
de las ventajas es la velocidad, pues alcanza de 20 a 100 Megabits por Segundo en los
tramos UMT y un Gigabyte en las redes locales. Esto posibilitará que en el móvil puedan
utilizarse varias aplicaciones de forma simultánea como videoconferencias o reproducir
películas con la máxima resolución22.
1.9.9 GSM
GSM es la abreviatura de ‘Sistema Global para las comunicaciones Móviles’ (en inglés,
Global System for Mobile communications). A comienzos del siglo XXI, es el estándar
más utilizado de Europa. Conocido como estándar de segunda generación (2G), su
principal diferencia respecto a la primera generación de teléfonos móviles es que sus
comunicaciones son totalmente digitales.
El estándar GSM permite transmisiones digitales de voz y datos, como mensajes de texto
(SMS) o mensajes multimedia (MMS). Respecto a su arquitectura de red, en GSM todo
terminal móvil debe estar constituido por una tarjeta SIM (Módulo de identificación de
abonado) y el propio dispositivo, normalmente un teléfono móvil23.
22 “bibvirtualdata” ,{En línea}.{06/08/2017} disponible en: (http://sisbib.unmsm.edu.pe/bibvirtualdata/monografias/ingenie/molina_nc/cap03.pdf) 23 “Tecnologia GSM”,{En línea},{06/08/2017} disponible en: 8http://eve-ingsistemas-u.blogspot.com.co/2012/04/el-sistema-global-para.html)
26
La tarjeta SIM es la encargada de identificar en la red al usuario y al terminal móvil. Estos
dispositivos se identifican gracias a un número exclusivo de identificación denominado
IMEI (Identificador internacional de equipos móviles), compuesto por 15 dígitos. Por otro
lado, cada tarjeta SIM también posee un número de identificación único Denominado
IMSI (Identificador internacional de abonados móviles).Una de las características
principales en todas las redes GSM es la capacidad que tiene un usuario para realizar o
recibir llamadas telefónicas, enviar y recibir información o acceder a otros servicios
mientras viaja fuera del área geográfica cubierta por el operador local usando las redes de
otros operadores24.
1.9.10 UMTS
El UMTS (Universal Mobile Telecommunications System o Sistema Universal de
Telecomunicaciones Móviles) es una tecnología móvil de la llamada tercera generación
(3G), sucesora de la tecnología GSM (Global System for Mogile) o 2G. Esta tecnología
permite disponer de una mayor resistencia a interferencias que su predecesora, así como
la utilización simultánea de conexiones de voz y datos, con velocidades de descarga que
pueden alcanzar los 2 Mbit/s para usuarios con baja movilidad o los 144 Kbit/s para
aquellos moviéndose en vehículos a gran velocidad. Estas características han hecho que la
tecnología 3G sea una de las más extendidas y utilizadas para el acceso a Internet de banda
ancha móvil.
Las sucesivas mejoras de la tecnología UMTS han conseguido mayores velocidades de
descarga, como es el caso de HSPA (High Speed Packet Access) con la que se pueden
alcanzar velocidades de hasta 14.4 Mbit/s y la evolución de ésta, HSPA+, que ofrece un
máximo teórico de 42 Mbit/s.
Hay que tener en cuenta que la capacidad de ancho de banda de UMTS es compartida por
todos los usuarios que se encuentran simultáneamente conectados a una misma estación
base, y al mismo tiempo la calidad de la de la conexión depende de la distancia del usuario
a la estación y de las interferencias existentes, por lo que las velocidades de descarga
individuales para cada usuario pueden variar y, de hecho, tienden a ser menores que los
máximos teóricos25.
24 “GSM-07” ,{En línea},{09/08/2017} disponible en: (http://ocw.upm.es/teoria-de-la-senal-y-comunicaciones-1/comunicaciones-movilesdigitales/contenidos/Presentaciones/GSM-07.pdf) 25 “Acceso móvil: UMTS (3G)” ,{En línea}.{10/08/2017} disponible en: (http://www.minetad.gob.es/telecomunicaciones/banda-ancha/tecnologias/movil/Paginas/UMTS.aspx)
27
1.9.11 LTE
Las siglas LTE vienen del término inglés Long Term Evolution, o lo que es lo mismo en
español, Evolución a Largo Plazo.
LTE es una tecnología de transmisión de datos de banda ancha inalámbrica que está
principalmente diseñada para poder dar soporte al constante acceso de teléfonos móviles
y de dispositivos portátiles a internet.
Podríamos resumir diciendo que LTE es la tecnología utilizada en los teléfonos móviles o
celulares de cuarta generación, los llamados Teléfonos 4G, para la bajada y subida de datos
desde internet. Realmente los 4G usan LTE Advanced, la misma tecnología pero más
avanzada como luego veremos.
Cada vez utilizamos más internet con una gran cantidad de dispositivos que hay para ello
en el mercado, nos descargamos millones de aplicaciones, jugamos con millones de
usuarios online, vemos gran cantidad de contenido multimedia, etc. Prácticamente
podemos conectarnos a internet en cualquier momento y cada vez somos más los que lo
hacemos, bien, pues la tecnología LTE pretende dar un mejor servicio para nosotros. Nos
puede proporcionar una gran mejora para subir datos a la red y también para
descargarlos26.
1.9.12 IONIC2
Ionic 2 es un framework para el desarrollo de aplicaciones híbridas, inicialmente pensado
para móviles y tablets, aunque ahora también capaz de implementar aplicaciones web e
incluso dentro de poco aplicaciones de escritorio multiplataforma. Su característica
fundamental es que usa por debajo Angular 2 y una cantidad de componentes enorme, que
facilita mucho el desarrollo de las aplicaciones.
Se trata de una estupenda herramienta para la creación de aplicaciones sorprendentes,
pensada para obtener resultados de una manera rápida y con una menor inversión
económica, ya que permite crear aplicaciones para distintas plataformas móviles con una
misma base de código27.
26 “LTE y LTE Advanced” ,{En línea}.{10/08/2017} disponible en: (http://www.areatecnologia.com/tecnologia/lte.html) 27 “Qué es Ionic 2” ,{En línea}.{11/08/2017} disponible en: (https://desarrolloweb.com/articulos/que-es-ionic2.html)
28
1.9.12 Protoboard
Tabla que permite interconectar componentes electrónicos sin necesidad de soldarlos. Es
muy fácil de utilizar, para el armado de los circuitos electrónicos y desarmado es muy
rápido y sencillo. Se usa para construir prototipos o pruebas experimentales.
Se insertan los dispositivos que se utilizaran a presión en los orificios de la placa. Los
agujeritos que tiene la placa están unidos en la parte inferior de la placa. Existen dos filas
en la parte inferior y superior de la placa, para conectar los dos polos de la fuente de tensión
que alimenta el circuito. Los orificios de la tabla están conectados entre sí en un orden
coherente28.
1.9.13 Resistencia
Se le denomina resistencia eléctrica a la igualdad de oposición que tienen los electrones al
desplazarse a través de un conductor. La unidad de resistencia en el Sistema Internacional
es el ohmio, que se representa con la letra griega omega (Ω), en honor al físico alemán
George Ohm, quien descubrió el principio que ahora lleva su nombre. La resistencia está
dada por la siguiente fórmula:
En donde ρ es el coeficiente de proporcionalidad o la resistividad del material
La resistencia de un circuito eléctrico determina según la llamada ley de Ohm cuánta
corriente fluye en el circuito cuando se le aplica un voltaje determinado. La unidad de
resistencia es el ohmio, que es la resistencia de un conductor si es recorrido por una
corriente de un amperio cuando se le aplica una tensión de 1 voltio29.
1.9.14 Capacitor
Capacitor electrolítico (Radial) de aluminio, de 40 uF (micro Faradios) a 10 Volts, con
corriente de fuga y factor de disipación bajos.
nombre por el cual se le conoce frecuentemente en el ámbito de la electrónica y otras ramas
de la física aplicada), es un dispositivo pasivo, utilizado en electricidad y electrónica,
capaz de almacenar energía sustentando un campo eléctrico. Está formado por un par de
superficies conductoras, generalmente en forma de láminas o placas, en situación de
28 “Circuios electricos y electronicos” ,{En línea}.{12/08/2017} disponible en: (http://cireleele.blogspot.com.co/2014/05/dispositivos-que-utilizaremos-en-las.html) 29 “Circuios electricos y electronicos” ,{En línea}.{12/08/2017} disponible en: (http://cireleele.blogspot.com.co/2014/05/dispositivos-que-utilizaremos-en-las.html)
29
influencia total (esto es, que todas las líneas de campo eléctrico que parten de una van a
parar a la otra) separadas por un material dieléctrico o por el vacío. Las placas, sometidas
a una diferencia de potencial, adquieren una determinada carga eléctrica, positiva en una
de ellas y negativa en la otra, siendo nula la variación de carga total30.
30 “Circuios electricos y electronicos” ,{En línea}.{12/08/2017} disponible en: (http://cireleele.blogspot.com.co/2014/05/dispositivos-que-utilizaremos-en-las.html)
30
1.10 Estudio de factibilidad
1.10.1 Factibilidad técnica
Se requiere una aplicación que permita controlar una alarma comunitaria por medio de
dispositivos móviles asociados.
1.10.1.1 Dispositivo
Existen en el mercado sirenas de tipo exterior, se trata de una sirena que funciona con
corriente alterna colocada dentro de un gabinete protector que funciona como disuasión
sonora.
1.10.1.2 Canal de comunicaciones
Se contemplaron las opciones de uso de Wifi, llamadas y SMS, para la activación de la
alarma que se encuentra en un dispositivo móvil.
1.10.1.3 Plataforma
La plataforma Cloud de Firebase dentro de sus servicios ofrece una base de datos en
tiempo real optimizada para aplicaciones móviles, para el manejo de la información y su
análisis en tiempo real.
También la plataforma de APPENGINE, que permite alojar aplicaciones, que pueden ser
escalables, que hacen uso de balanceadores para cumplir con el principio de disposición.
1.10.1.4 Recurso Humano
El equipo se encuentra conformado de dos desarrolladores con experiencia en plataformas
cloud, desarrollo de aplicaciones móviles y metodologías ágiles de desarrollo, lo cual
permite la realización del proyecto.
31
1.10.2 Factibilidad Financiera
Firebase y APPENGINE, estarán condicionadas respecto al uso de los servicios, ya que
se cobra según el uso y no una tarifa fija, dando beneficios como el pago según el uso de
la aplicación.
1.10.3 Factibilidad de gestión
Se plantea un modelo de trabajo de metodología ágil, el cual permite realizar
retroalimentación, monitoreo y desarrollo del proyecto, implementando Scrum como
estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del
producto, definiendo un conjunto de prácticas y roles, donde los clientes pueden cambiar
de idea sobre lo que quieren y necesitan sin afectar drásticamente el desarrollo del
proyecto.
1.10.4 Factibilidad económica
La factibilidad económica del proyecto es alta, ya que lo que necesitamos en términos
financieros son mínimo dos desarrolladores, asesoría de tutor del proyecto, acceso a
Internet, dos dispositivos móviles con Android, una protoboard y papelería para realizar
el modelado del proyecto.
En las tablas que se presentarán a continuación se describe la factibilidad económica,
identificando los costos de papelería, hardware, software y recursos humanos necesarios
para la realización del proyecto de investigación que se propone.
Se dividió en tres aspectos, recursos humanos (Tabla 1), recursos técnicos (Tabla 2), otros
recursos (Tabla 3) y una tabla final del total del proyecto (Tabla 4):
32
Tabla 1 Factibilidad Económica Recursos Humanos, fuente: Los Autores
Tipo Descripción Valor-
Hora
Cantida
d
Total
Tutor 1 Asesorías para la realización
del proyecto, referente a la
metodología.
$ 40.000 40 Horas $ 1.600.000
Desarrollado
res
Dos programadores que
realicen la implementación de
la solución.
$ 20.000 8 Horas $ 3.840.000
Tutoría Ayuda de compañero ingeniero
electrónico
$40.000 8 Horas $320.000
Total Recursos Humanos $ 5.760.000
Tabla 2 Factibilidad Económica Recursos Técnicos, fuente: Los Autores
Recurso Descripción Valor Unitario Cantidad Total
Computadores
(Servidor -
clientes)
Equipos de escritorio para
el desarrollo y las pruebas
del sistema.
$ 1.700.000 2 $ 3.400.000
Dispositivos
móviles
Equipo móvil con android $ 200.000 2 $400.000
Prototipo Implementación en
protoboard, activación de
alarma
$150.000 1 $150.000
Total Recursos Técnicos $ 3.950.000
33
Tabla 3 Gastos adicionales, fuente: Los Autores
Recurso Descripción Valor Unitario Cantidad Total
Papelería Papelería para
documentación.
$ 50.000 1 $50.000
Conexión a
Internet
Conexión a la red para
investigación y desarrollo de
la aplicación.
$ 60.000
mensual
6 meses $ 360.000
Total Recursos Técnicos $ 410.000
Tabla 4 Factibilidad Económica Costo Total, fuente: Los Autores
Recurso Valor
Total Recursos Humanos $ 5.760.000
Total Recursos Técnicos $ 3.950.000
Total Otros recursos $ 410.000
Costos imprevistos (10%) $ 965.000
TOTAL COSTO $11.085.000
34
1.11 Cronograma
De acuerdo a la metodología que se va a implementar (SCRUM), encontramos los Sprints
Goals (Metas) y sus respectivos Sprint Backlogs(Tareas) como se evidencia en la figura 1.
Figura 1 Cronograma, fuente: Los Autores
35
2. Fase de análisis
Personal encargado del desarrollo de la metodología
Product Backlog:
Jonathan García, Luis Aldana
Sprint planning:
Integrantes: Luis Aldana, Jonathan García
Sprint Backlog:
Jonathan García, Luis Aldana.
Scrum master:
Luis Aldana
Product owner:
Jonathan García
Equipo (Team):
Jonathan García, Luis Aldana.
Sprint:
Jonathan García, Luis Aldana
Retroalimentación:
Jonathan García, Luis Aldana.
36
2.1 Definición de los objetivos del Product Backlog
Para la definición del product backlog hacemos uso de historias de usuario, para tener de
una forma más detallada el proyecto a desarrollar, el cual cuenta con un estado y prioridad,
con esto sabemos en qué estado del proyecto global estamos y que necesitan más urgencia
para realizar cada actividad o historia de usuario como se ve en la Tabla 5.
PRODUCT BACKLOG
HISTORIA
ID
HISTORIA DE USUARIO ESTADO PRIORIDAD
Registro de datos (Emisor)
100 El usuario requiere configurar la aplicación móvil
emisora y almacenar los datos. Realizada 5
Activación-Desactivación alarma (Emisor)
101 El usuario necesita activar-desactivar la alarma y a
su vez enviar un evento para ser almacenado los
datos.
Realizada 4
Aplicación central (Receptor)
102 El usuario requiere configurar la aplicación móvil
central receptora. Realizada 5
Eventos en aplicación central (Receptor)
103 La aplicación central requiere escuchar los eventos
que se presenten en la Base de Datos y a si la
activación o desactivación de la alarma.
Realizada 4
Login en aplicación Web (Administrador)
104 El administrador requiere registrarse en la aplicación
web mediante un login. Realizada 3
Administración de usuarios (Administrador)
105 El administrador requiere ver el listado de usuarios. Realizada 3
Actualización de usuarios (Administrador)
37
106 El administrador requiere poder cambiar el estado de
los usuarios. Realizada 3
Historial de eventos (Administrador)
107 El administrador requiere ver el listado de alarmas
existentes y observar el historial de eventos en cada
una.
Realizada 3
Prototipo
108 Incorporación de prototipo que aumenta la señal de
audio e incorpora circuitos que simulan un switch
para encender o apagar la alarma.
Realizada 5
Tabla 5 Producto Backlog, fuente: Los Autores
2.2 Historias de usuario
2.2.1 Historia de usuario 100
100 Registro de datos (Emisor)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Crear un modelo de entidad el cual permita identificar las entidades relacionadas en la
aplicación, definiendo atributos y características de cada una de estas.
2 Definir una herramienta o motor de base de datos que permita almacenar y establecer los
objetos para la creación e identificaron de la información.
3 Creación de métodos que permitan crear, actualizar la información de la aplicación
móvil.
Tabla 6 Historia de usuario 100, fuente: Los Autores
38
2.2.2 Historia de usuario 101
101 Activación-Desactivación alarma (Emisor)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creación de método que permitan activar y desactivar la alarma a través de la aplicación
móvil.
2 Seleccionar el evento, para ser registrados en la base de datos.
Tabla 7 Historia de usuario 101, fuente: Los Autores
2.2.3 Historia de usuario 102
102 Aplicación central (Receptor)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creación de un formulario de ingreso del id de la alarma.
2 Conectar a la base de datos.
3 Consultar información de la alarma.
4 Mostrar en una vista el estado de la alarma.
Tabla 8 Historia de usuario 102, fuente: Los Autores
2.2.4 Historia de usuario 103
103 Eventos en aplicación central (Receptor)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creación de función que estará escuchando bandera en la base de datos.
2 Activación de alarma en caso de que su estado "Encendido" cambie a "True" y así emitir
un sonido.
3 Desactivación de alarma en caso de que su estado "Encendido" cambie a "False" y parar
el sonido que se esté emitiendo.
Tabla 9 Historia de usuario 103, fuente: Los Autores
39
2.2.5 Historia de usuario 104
104 Login en aplicación Web (Administrador)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creacion formulario de login para el ingreso a la aplicación Web.
2 Desarrollo para la autenticación y conexión con la base de datos.
Tabla 10 Historia de usuario 104, fuente: Los Autores
2.2.6 Historia de usuario 105
105 Administración de usuarios (Administrador)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creación de módulo que consulta usuarios.
2 Creación de módulo que muestra usuarios en la vista.
Tabla 11 Historia de usuario 105, fuente: Los Autores
2.2.7 Historia de usuario 106
106 Actualización de usuarios (Administrador)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creación de módulo que permita la actualización del estado del usuario, para que así el
usuario pueda activar o desactivar la alarma.
Tabla 12 Historia de usuario 106, fuente: Los Autores
40
2.2.8 Historia de usuario 107
107 Actualización de usuarios (Administrador)
ID DESCRIPCIÓN DE ACTIVIDAD
1 Creación de módulo que consulta alarmas
2 Creación de módulo que muestra alarmas en la vista y su historial de los eventos
sucedidos.
Tabla 13 Historia de usuario 107, fuente: Los Autores
2.2.9 Historia de usuario 108
108 Prototipo
ID DESCRIPCIÓN DE ACTIVIDAD
1 Incorporación de circuitos en la protoboard
2 Ampliación de la señal de audio emitida por el celular para poder ser procesada.
3 Comprar intensidad de la señal para activar o desactivar la alarma
4 Encender o apagar la alarma.
Tabla 14 Historia de usuario 108, fuente: Los Autores
41
2.3 Definición general del software
2.3.1 Definición de Sprint
Para el manejo de los sprints en el desarrollo de este proyecto se tiene en cuenta que todos
deben cumplir con un alcance y una meta la cual está conformada de la siguiente manera:
2.3.2 Meta general software
Desarrollo de dos aplicaciones móviles, una es la aplicación emisor que permite la
activación y desactivación de la alarma, enviando una traza a la base de datos para que sea
almacenada; y la otra es la aplicación central receptora que estará a la escucha de eventos
hechos en la base de datos para la activación o desactivación de la alarma y una aplicación
web que se encarga de la administración de los usuarios e historial de las alarmas.
2.3.3 Alcance general software
Desarrollo de un sistema que consta de una aplicación móvil emisor, una aplicación móvil
receptor y un administrador web, que permitan la administración y activación de una
alarma controlada desde los dispositivos móviles en tiempo real.
2.3.4 Vista de escenarios definido por
Agrupa escenarios de casos de uso y definición de roles principales (Diagrama de casos
de uso).
2.3.5 Vista lógica definida por:
Modela elementos que soportan la funcionalidad del sistema este provee al usuario final
desde el punto de vista estático o dinámico (Diagrama de contexto, Diagrama de clases).
2.3.6 Vista de desarrollo definida por:
Esta describe la organización estética del software en su ambiente de desarrollo.
42
3. Sprint Backlog: 1
En este sprint lo que se busca desarrollar las actividades de creación de usuarios y la
asociación a una alarma en específico, además del ingreso a la aplicación móvil donde se
especifica con más detalle en el Product Backlog las cuales poseen una prioridad de 5 pero
las cuales son las base para poder desarrollar y crear un modelo de base de datos estándar,
el ID de estas historias de usuario son: 100,101.
Se toman en cuenta la realización de componentes y definición de arquitectura la cual se
plantea desde el punto inicial. Como también la definición de modelos UML que permiten
definir el sprint y las funcionalidades de las actividades.
Lo primero a realizar es la creación de usuarios, los cuales deben ser incluidos en un
modelo de base de datos como entidades principales en la aplicación.
BACKLOG ID: 100
ID Historia de
usuario
Tarea Prioridad
100 Elección y creación de un modelo de base de datos por objetos 5
Creación de Mockups para registro de usuario 3
Creación y codificación del módulo de registro del usuario
asociado a una alarma en específico
4
101 Creación de Mockup de activación de alarma con evento
asociado
3
Creación y codificación de la funcionalidad que activa y
desactiva la alarma
4
Guardar traza de eventos hechos por cada usuario 4
Tabla 15 Backlog 100, fuente: Los Autores
43
Sprint
ID 1
Backlog ID 100
Historias de U 100,101
Responsables Luis Aldana, Jonathan García
Descripción de las
funcionalidades
La primera funcionalidad de este sprint consiste en la creación de usuarios y
asociación a una alarma en específico.
Como segunda funcionalidad se encuentra la activacion y desactivacion de
la alarma asociada a un evento en particular
La tercera funcionalidad es guardar un registro por cada acción hecha por
cada usuarios
Tabla 16 Backlog sprint 100, fuente: Los Autores
3.1 Ejecución del sprint
La primera tarea de desarrollar es lo que comprende almacenar los datos en el sistema.
Para esto se usa FireBase esta herramienta es una la cual está orientada a la creación de
aplicaciones de alta calidad ya que ofrece varios servicios dentro de este bases de datos en
tiempo real realizar un CRUD en tiempo real ya que los datos pueden ser refrescados y
consultados en cualquier momento, los datos se almacenan en formato JSON permitiendo
un intercambio de datos ligero ya que maneja estructura vectorial orientada a objetos y
permite mayor flexibilidad y capacidad lógica a la base de datos además que está orientada
a los flujos de datos.
Con esta estructura inicial poder registrar tanto usuarios como alarmas desde la aplicación
móvil, donde las actividades a realizar son registrar un usuario y eventos realizados por el
usuario de activación y desactivación de alarma.
Se utiliza a su vez el framework Ionic2, que sirve para crear aplicaciones híbridas con
javascript y es basado en angularJs2, dándonos así una mayor comodidad al momento de
desplegar nuestro mismo código en diferentes entornos móviles.
En los siguientes Mockups se describe concretamente la ejecución del sprint.
44
3.1.1 Mockups: Vista Inicial
A continuación se muestra en la Figura 2 pantalla principal de la aplicación emisora.
Figura 2 Aplicación móvil emisora, fuente: Los Autores
3.2 Vista de escenarios
3.2.1 Diagrama de casos de uso: Usuario registro
Caso de uso del usuario y sus acciones al momento de registrarse así como lo evidencia la Figura 3
Figura 3 Caso de uso usuario registro, fuente: Los Autores
45
3.2.2 Usuario activación – desactivación
Caso de uso reflejado en la Figura 4 y sus acciones.
Figura 4 Caso de uso activación - desactivación, fuente: Los Autores
3.3 Vista Lógica
3.3.1 Diagrama de clases
Diagrama y relación de clases como se ve en la Figura 5.
Figura 5 Diagrama de clases emisor, fuente: Los Autores
46
3.3.2 Diagrama de flujo definido en FireBase
Estructura de datos en Firebase se muestra en la Figura 6.
Figura 6 Diagrama de flujo emisor, fuente: Los Autores
3.3.3 Diagrama de Contexto
En la Figura 7 se refleja la interacción de los actores.
Figura 7 Diagrama de contexto emisor, fuente: Los Autores
47
3.4 Vista de Desarrollo
Se evidencian los archivos y relaciones entre cada una de ellos como se ve en la Figura 8.
Figura 8 Vista de desarrollo emisor, fuente: Los Autores
48
3.5 Ejecución de tareas en este Sprint
3.5.1 Mockups listado de situaciones.
La creación de una actividad o pantalla principal donde se puede visualizar un listado de
las situaciones para poder activar la alarma (Figura 9)
Figura 9 Listado de eventos, fuente: Los Autores
3.5.2 Mockups para capturar los datos
La primera tarea es la realización de la actividad donde el usuario se pueda registrar es
importante capturar los siguientes datos. (Figura 10)
Identificador de alarma
Nombres completos
Dirección
Figura 10 Registro de datos emisor, fuente: Los Autores
49
3.5.3 Mockups activación-desactivación.
Creación de una pantalla principal donde se puede visualizar un botón para la activación
o desactivación de la alarma. Cuando el usuario al dar clic en el botón “Activar” este
encenderá la alarma y si al dar clic en el botón desactivar, apagará la alarma; estos dos
sucesos podrán ser accionados siempre y cuando el usuario esté activo, a su vez puede
escoger el evento asociado (Robo,Terremoto,Incendio). (Figura 11)
Figura 11 Botones de activación o desactivación, fuente: Los Autores
3.6 Retroalimentación de este sprint.
En este sprint se realizó completamente, las tareas que se estimaron, dentro de las tareas
las que abarcan mayor tiempo es la configuración de FireBase ya que para la creación y
apertura de este servicio, se requería el registro como desarrollador y la creación de un
registro de aplicación para poder consumir y que la API proporcionará los servicios Real
time Database. En donde se consolidó la instancia para el flujo de datos de la aplicación.
50
Se desarrolló de la aplicación móvil híbrida hecha en ionic 2, generando el APK para poder
ser instalado en dispositivos android y así poder probar la funcionalidad propuesto en el
Sprint.
3.7 Diagrama de Gantt Sprint
En la Figura 12 se muestra el desarrollo del Sprint.
Figura 12 Diagrama de Gantt sprint 1, fuente: Los Autores
51
4. Sprint Backlog 2
En este sprint lo que se busca desarrollar las actividades del app receptor, que se encargará
de escuchar la base de datos en caso de que sea activada o desactivada la alarma, también
aquí se hace la asociación del app con una alarma específica, siendo así una aplicación
central, el ID de estas historias de usuario son: 102 y 103.
Se toman en cuenta la realización de componentes y definición de arquitectura la cual se
plantea desde el punto inicial. Como también la definición de modelos UML que permiten
definir el sprint y las funcionalidades de las actividades.
Lo primero a realizar es la configuración de la app central, para la asociarla a la alarma
que va a estar escuchando a la base de datos, para luego capturar el evento en caso de que
cambie el estado y encender o apagar la alarma.
BACKLOG ID: 101
ID Historia de
usuario
Tareas Prioridad
102 creación de un formulario de ingreso del id de la alarma
central
5
conectar a la base de datos 4
mostrar en una vista el estado de la alarma 3
103 Creación de función que estará escuchando a la base de datos,
llamadas y sms que reciba el dispositivo.
5
activación de alarma en caso de que su estado "Encendido"
cambie a "True"
4
desactivación de alarma en caso de que su estado "Encendido"
cambie a "False"
4
Tabla 17 Backlog 101, fuente: Los Autores
52
Sprint
ID 2
Backlog ID 101
Historias de U 100,101
Responsables Luis Aldana, Jonathan García
Descripción de las
funcionalidades
La primera funcionalidad de este sprint consiste la configuración de la app,
asociandola con una alarma específica
Como segunda funcionalidad se encuentra el mostrar el estado de la alarma
La tercera funcionalidad es escuchar los eventos de la base de datos para su
activacion o desactivacion
Tabla 18 Backlog sprint 100, fuente: Los Autores
4.1 Ejecución del sprint
La primera tarea de desarrollar es configurar el App para asociarlo con una alarma
específica, conectándose a FireBase, esta herramienta es una la cual está orientada a la
creación de aplicaciones de alta calidad ya que ofrece varios servicios dentro de este bases
de datos en tiempo real, para ser consultados en cualquier momento, se usa el ID Android
Studio V3.0.1 y las dependencias para autenticacion “com.google.firebase:firebase-
auth:10.0.1” y consulta de la base de datos “com.google.firebase:firebase-
database:10.0.1”.
En los siguientes Mockups se describe concretamente la ejecución del sprint.
53
4.1.1 Mockups: Vista Inicial
Vista principal de configuración de la alarma como se observa en la Figura 13
Figura 13 Aplicación móvil receptora, fuente: Los Autores
4.2 Vista de escenarios
4.2.1 Diagrama de casos de uso: Configuración alarma central
Caso de uso de ingreso de identificador de alarma evidenciado en la Figura 14.
Figura 14 Caso de uso configuración app, fuente: Los Autores
54
Caso de usos activados por llamadas o SMS evidenciado en la Figura 15 y Figura 16.
Figura 15 Caso de uso usuario activa por llamada, fuente: Los Autores
Figura 16 Caso de uso usuario activo por SMS, fuente: Los Autores
55
4.2.2 Usuario escucha evento activación - desactivación
Caso de uso de eventos (Figura 17).
Figura 17 Caso de uso escucha evento activación - desactivación, fuente: Los Autores
4.3 Vista Lógica
4.3.1 Diagrama de clases
Diagrama principal de alarma receptora (Figura 18).
Figura 18 Diagrama de clases receptor, fuente: Los Autores
56
4.3.2 Diagrama de flujo definido en FireBase
Diagrama de modelo de datos en Firebase (Figura 19)
Figura 19 Diagrama de flujo receptor, fuente: Los Autores
4.3.3 Diagrama de Contexto
Diagrama de contexto de flujo de datos se observa en la Figura 20.
Figura 20 Diagrama de contexto receptor, fuente: Los Autores
57
4.4 Vista de Desarrollo
Archivos necesarios para la creación de aplicación receptora y relación entre ellos, evidenciados en
la Figura 21.
Figura 21 Vista de desarrollo receptor, fuente: Los Autores
58
4.5 Ejecución de tareas en este Sprint
4.5.1 Mockups Ingreso de identificador de Alarma.
La creación de una actividad o pantalla principal donde se pueda ingresar el identificador
de la alarma.(Figura 22)
Figura 22 Ingreso identificador, fuente: Los Autores
59
4.5.2 Mockups mostrar estado
Se muestra al usuario la alarma y su estado, en caso de ser “True” la alarma se activará,
en caso de ser “False” se desactiva la alarma. (Figura 23)
Figura 23 Estado alarma, fuente: Los Autores
60
4.6 Retroalimentación de este sprint.
En este sprint se realizó completamente, las tareas que se estimaron, dentro de las tareas
las que abarcan mayor tiempo es la de activar el evento de inicializar la alarma según el
estado de la alarma, debido a que se tenía que ir por la rama del nodo de la alarma asignada.
Se desarrolló un App para Android el cual se asocia a una alarma en la base de datos de
Firebase, la cual está escuchando los eventos de la alarma asignada, para la posterior
activacion y desactivacion de la alarma.
4.7 Diagrama de Gantt Sprint
Desarrollo del Sprint lo observamos en la Figura 24.
Figura 24 Diagrama de Gantt sprint 2, fuente: Los Autores
61
5. Sprint Backlog 3
En este sprint se desarrollaron las actividades correspondientes a las historias de usuario
105, 106, 107, 108 en la que se hará la integración del servicio de Appengine con Firebase,
mediante el desarrollo de una aplicación web para la administración de usuarios y alarmas
en el sistema.
BACKLOG ID: 102
ID Historia
de usuario
Tarea Prioridad
105 Integración libre con aplicativo, que permitan la conexión con la base
de datos de Firebase y Appengine.
5
Creación de formulario para ingreso de user y password. 4
Creación de módulo de autenticación a la base de datos. 4
106 Creación de módulo de consulta de usuarios. 4
Creación de vista donde se visualizarán los usuarios. 4
107 Creación de formulario que permita el ingreso de datos a actualizar. 5
Creación de módulo que realizará la actualización de datos del
usuario.
4
108 Creación de módulo de consulta de alarmas. 4
Creación de vista donde se visualizarán las alarmas. 4
Tabla 19 Backlog 102, fuente: Los Autores
62
Sprint
ID 2
Backlog ID 102
Historias de U 105,106,107,108
Responsables Luis Aldana, Jonathan García
Descripción de las
funcionalidades
La primera funcionalidad de este sprint consiste en la creación de un login
Como segunda funcionalidad se encuentra el poder actualizar la
información de los usuarios.
La tercera funcionalidad es poder ver el historial de eventos sucedidos por
alarma.
Tabla 20 Backlog sprint 2, fuente: Los Autores
5.1 Ejecución del sprint 2
Para la ejecución de este sprint la primera tarea a realizar es la implementación e
integración de la conexión de Appengine con firebase a través del uso del SDK de google.
El SDK permite interactuar con Firebase, leyendo y escribiendo datos de Realtime
Database, generando y verificando tokens de de autenticación de Firebase. Con una cuenta
Gmail, se accede a Firebase, se crea un proyecto, se configura el user y password para la
la autenticación y poder interactuar con la Base de Datos.
63
5.2 Vista de escenarios
5.2.1 Diagrama casos de uso
Caso de uso interacción del administrador y sus acciones (Figura 25)
Figura 25 Capturar de casos de uso bluetooth, fuente: Los Autores
5.3 Vista Lógica
5.3.1 Diagrama de contexto
Diagrama de flujo de los datos (Figura 26).
Figura 26 Login y consulta de datos, fuente: Los Autores
64
5.4 Vista de desarrollo
5.4.1 Diagrama de componentes
Interacción del administrador (Figura 27)
Figura 27 Diagrama aplicación web, fuente: Los Autores
5.4.2 Ejecución de las tareas del sprint Backlog
Las librerías y algunos servicios se instalan con el SDK de google Appengine. La conexión
a Firebase se hace mediante la librería de firebase.js, para la autenticación y consulta de
datos.
Archivos necesarios para la aplicación web (Figura 28)
65
Figura 28 Localización de archivos, fuente: Los Autores
5.4.2.1 Login
Se realiza la validación de credenciales ingresadas, para acceder a la aplicación (Figura
29)
66
Figura 29 Mockups login, fuente: Los Autores
Se ingresa al home de bienvenida si las credenciales son válidas. (Figura 30)
Figura 30 Home de aplicación, fuente: Los Autores
5.4.2.2 Consultar Usuarios
Listado de usuarios por alarma (Figura 31)
Figura 31 Consulta Usuarios, fuente: Los Autores
67
5.4.2.3 Actualizar Usuarios
Se selecciona el registro que se quiere actualizar, se escoge la opción activar o
desactivar.(Figura 32)
. Figura 32 Actualiza Usuarios, fuente: Los Autores
5.4.2.4 Consulta histórico eventos
Se selecciona la alarma, y luego se muestra los eventos realizados en esta alarma. (Figura
33)
Figura 33 Consultar alarmas, fuente: Los Autores
68
5.5 Retroalimentación del sprint
Se realizaron los módulos correspondientes, pero se requirió un poco más de esfuerzo en
la parte visual, ya que era necesario que también se pudiera ver en móviles. (Figura 34)
Figura 34 Modo móvil, fuente: Los Autores
5.6 Diagrama de Gantt sprint
Desarrollo del Sprint lo observamos en la Figura 35
Figura 35 Diagrama de Gantt sprint 3, fuente: Los Autores
69
6. Sprint Backlog: 4
En este sprint lo que se busca desarrollar las actividades de crear un prototipo que simula
un switch, la decisión a tomar será hecha por una señal entrante, así el circuito decidirá si
es necesario el prender o apagar la alarma, el ID de esta historia de usuario es: 108.
BACKLOG ID: 103
ID Historia de
usuario
Tarea Prioridad
108 Hacer un diagrama del circuito final 5
Incorporar los circuitos de forma correcta, en la protoboard 4
Capturar la señal de audio y esta misma ampliarla 4
Procesar la señal y al final saber si encendemos o apagamos la alarma 4
Tabla 21 Backlog 103, fuente: Los Autores
Sprint
ID 4
Backlog ID 103
Historias de U 108
Responsables Luis Aldana, Jonathan García
Descripción de las
funcionalidades
La primera funcionalidad de este sprint consiste en la creación del diagrama
del circuito a incorporar.
Como segunda funcionalidad se encuentra el desarrollo de incorporar cada
circuito en el orden correcto.
La tercera funcionalidad es por medio de la captura de la señal, el circuito
tomará la decisión de apagado o prendido de la alarma.
Tabla 22 Backlog sprint 103, fuente: Los Autores
70
6.1 Ejecución del sprint
El desarrollo de este sprint se centraliza en la creación de un prototipo que nos funcione
como switch de activación o desactivación de la alarma, tenemos dos entradas (energía y
señal de audio) y una salida (sirena o alarma), para obtener una funcionalidad total del
prototipo consta de 4 fases para su desarrollo:
● Amplificación: En esta fase se toma como señal de entrada un audio que es emitido
por el dispositivo receptor, ya que la señal es baja para procesarla se aumenta en 20
DB a través del circuito LM386 que se encarga de este proceso.
● Filtro pasa bajas: Se usa para obtener la señal envolvente del audio, recordemos que
lo que se desea es destacar el detalle de los sonidos y detectar cuando hay sonido o
ausencia de él.
● Comparador: En esta etapa se desea obtener una señal tipo binaria que indique si
hay presencia de sonido o no. Esto se logra definiendo el umbral a través de un
potenciómetro que actúa como divisor de voltaje y se ajusta manualmente.
● Switch On/Off: Por último dependiendo de la señal entrante, decide si es posible el
activar la alarma o no.
71
6.2 Diagrama del circuito
Diagrama del circuito a desarrollar en la protoboard se observa en la figura 36
Figura 36 Diagrama prototipo del circuit, fuente: Los Autores.
6.3 Circuito final Circuito físico e implementado (Figura 37)
Figura 37 Prototipo físico, fuente: Los Autores.
72
6.4 Retroalimentación de este sprint.
En este sprint se realizó completamente, las tareas que se estimaron, este prototipo nos
ayuda a tener un sistema completo y controlado de la activación de la alarma.
6.5 Diagrama de Gantt Sprint
Desarrollo del Sprint lo observamos en la Figura 38.
Figura 38 Diagrama de Gantt sprint 4, fuente: Los Autores
73
7. Esfuerzo general
7.1 Estimación de tiempo
Cada integrante del equipo contó con 28 Horas semanales de trabajo, lo que implica
un total disponible de 56 horas semanales de todo el equipo. Para realizar el total de
los backlog se requirieron un total de 336 horas (6 meses de trabajo).
8. Descripción del sistema
8.1 Implementación.
El sistema creado tiene varios componentes, el primero de ellos es una aplicación móvil
desarrollada en el framework Ionic2 para aplicaciones híbridas, que utiliza javascript y es
basado en AngularJs2, esto hace que el mismo código pueda ser desplegado en diferentes
plataformas. Este aplicativo a su vez está conectado a firebase, una base de datos en tiempo
real no relacional, que guarda sus datos en formato JSON (JavaScript Object Notation), al
ser una base de datos en tiempo real nos facilita en la sincronización de múltiples
dispositivos a la escucha de eventos y de la actualización de la información de forma
rápida, la aplicación móvil tiene la principal funcionalidad de activar o desactivar la
alarma.
El segundo componente es una aplicación nativa desarrollada en android, la cual está
conectada con la base de datos, escuchando eventos para tomar la decisión de reproducir
un sonido o no.
Un tercer componente es un prototipo de interruptor desarrollada en protoboard y con
circuitos para encender o apagar la corneta (sirena), consta de dos entradas, energía y la
señal de audio, la señal de audio será procesada por el circuito ampliando sus decibelios y
así dependiendo del voltaje la corneta será encendida o apagada, y una salida que es la
corneta.
74
A continuación se ilustra el sistema completo.(Figura 39)
Figura 39 Diagrama del sistema en general, fuente: Los Autores.
Por último está el componente de la administración de los datos desarrollado en la nube
(Cloud), este desarrollo está hecho en Appengine, el cual consta de un login, y consultas para
ver el historial de eventos sucedidos en cada alarma configurada y la administración de
usuarios por alarma. (Figura 40)
Figura 40 Diagrama del sistema administrador, fuente: Los Autores
75
9. Recomendaciones del proyecto
Se recomienda para una segunda versión, hacer uso de otras herramientas como
interfaz entre la alarma y el dispositivo receptor, de tal forma que no sea
necesariamente un móvil con sistema operativo Android como interfaz para la alarma,
para que funcione sobre cualquier plataforma o no dependa de un sistema operativo
especifico, también contemplar el uso de otras tecnologías que se tienen incorporadas
como lo son el bluetooth y GPS, que permitan recolectar más datos para su análisis.
El apoyo por parte de la Universidad al planteamiento de más proyectos que
favorezcan a la comunidad, que contribuyan a mejorar la calidad de vida de la
ciudadanía, haciendo buen uso de nuevas tecnologías.
10. Anexos
Dentro de los anexos se encuentran los siguientes manuales:
Manual aplicación móvil emisor.
Manual aplicación móvil receptor.
Manual aplicación web administrador.
Manual Incorporación del sistema.
76
11. Conclusiones
Se han cumplido satisfactoriamente los objetivos de este proyecto, ya que se ha adquirido
una experiencia muy valiosa en la creación de aplicaciones Android, con herramientas
utilizados en la creación de la misma como Firebase y Appengine.
También se logró adquirir experiencia en el diseño de apps que requieran una
comunicación entre diferentes dispositivos y manejo de datos en tiempo real, con bases
de datos no relacionales, además del uso de un dispositivo físico como lo es la alarma y la
activación de esta, desde cualquier dispositivo asociado.
Con la implementación de tecnologías móviles en los servicios de seguridad se mejora de
manera considerable algunos de los eventos que puedan ocurrir diariamente en el sector
dando así la posibilidad de que cualquier usuario puede acceder a dicho recurso, en este
caso en la activación de una alarma por supuestos sucesos que están sucediendo en el
momento.
De manera que para este proyecto se aplicaron tecnologías libres y que cumplieran con
los requerimientos para reforzar cada objetivo que se quería lograr además que es software
libre lo cual permite brindar un apoyo a la comunidad a un bajo costo.
También se plantea la posibilidad de reciclaje mediante el uso de dispositivos android que
no se usen, para usarlos como receptores, contribuyendo así a la conservación del medio
ambiente, ya que solo se necesita que cuente con las funciones básicas para su
funcionamiento, como lo son llamadas, mensajes y conexión a internet.
Por todo lo anterior es un proyecto innovar, ofreciendo una alternativa a nivel local,
escalable, que puede convertirse en global ya que tecnologías como CLOUD que permiten
mayor disponibilidad y seguridad de la información almacenada.
77
12. Bibliografía
[1] CARACOL RADIO, “Advierten que localidades más inseguras de Bogotá tienen menos
vigilancia.”, {En línea}.{06/07/2017} disponible en:
(http://caracol.com.co/emisora/2017/02/11/bogota/1486831994_950416.html)
[2] “Modelo nacional de vigilancia comunitaria por cuadrantes“, {En línea}.{06/07/2017}
disponible en:
(http://policia.edu.co/documentos/TOMO%202.2.%20Seguridad%20Ciudadana.pdf )
[3] EL HERALDO “En La Victoria le “ganan la lucha” a delincuentes con alarma
satelital”,
{En línea}. {06/07/2017} disponible en:
(https://www.elheraldo.co/local/en-la-victoria-le-ganan-la-lucha-delincuentes-con-alarma-
satelital-187661)
[4] “Alarma comunitaria”, {En línea}. {08/07/2017} disponible en:
(http://www.brainatoms.com/communityalarm/index.html)
[5] “Alarmapp” ,{En línea}.{08/07/2017} disponible en:
(http://www.elpais.com.co/cali/alarmapp-la-aplicacion-que-pondra-en-cintura-las-alarmas-
comunitarias-en.html)
[6] “App mantiene a la comunidad conectada y en alerta en caso de emergencia” ,{En
línea}.{10/07/2017} disponible en: (http://www.plataformacientifica.cl/app-mantiene-la-
comunidad-conectada-y-en-alerta-en-caso-de-emergencia/ )
[7] “CityCop, una app gratuita que emula a las alarmas comunitarias” ,{En
línea}.{11/07/2017} disponible en: (http://losandes.com.ar/article/lego-a-la-argentina-
citycop-la-aplicacion-que-ayuda-a-prevenir-delitos-811022)
[8] “Haus, la app que te conecta con tus vecinos”, {En línea}.{11/07/2017} disponible en:
(https://www.harmonia.la/entorno/haus_la_app_que_te_conecta_con_tus_vecinos)
[9] “Alarma comunitaria multi partición cctv inalámbrico”, {En línea}.{18/07/2017}
disponible en:
(http://alarmascomunitarias.weebly.com/)
[10] GÓMEZ RODRÍGUEZ, Wilmar Alejandro, URIBE MALDONADO, Juan Sebastián,
“Modelo de integración tecnológica del subsistema de alarmas comunitarias con los
sistemas de seguridad y emergencias (SIES)”{En línea}.{20/07/2017} disponible en:
(https://repository.javeriana.edu.co/handle/10554/15574)
78
[11] CASTILLO IMBAQUINGO,Diego Xavier ,“Diseño e implementación de un sistema
de alarma comunitaria a base de módulos inalámbricos utilizando tecnología zigbee“ {En
línea}.{19/07/2017} disponible en:
(http://repositorio.utn.edu.ec/bitstream/123456789/1886/1/04%20RED%20011%20ALAR
MA%20COMUNITARIA%20A%20BASE%20DE%20M%C3%93DULOS%20INAL%C3
%81MBRICOS%20UTILIZANDO%20TECNOLOG%C3%8DA%20ZIGBEE.pdf,
06/04/2017).
[12] “Única alarma comunitaria multi partición” ,{En línea}.{22/07/2017} disponible en:
(https://alarmascomunitarias.weebly.com/)
[13] “Policía Nacional de Colombia recibe importante premio“,{En línea}.{02/08/2017}
disponible en:
(http://laud.udistrital.edu.co/noticias/polic%C3%ADa-nacional-de-colombia-recibe-
importante-premo)
[14] “CSA Cloud security alliance. Guía para la seguridad en áreas críticas de atención en
Cloud Computing” {En línea},{01/08/2017} disponible en: P7
(http://www.cloudsecurityalliance.org/guidance/csaguide-es.v2.pdf)
[15] “Qué es y cómo funciona Google App Engine”,{En línea},{02/08/2017} disponible
en: (https://platzi.com/blog/google-app-engine/)
[16]Firebase, “Firebase te ayuda a crear mejores apps para dispositivos móviles y hacer
crecer tu empresa.” {En línea},{04/08/2017} disponible en: (https://firebase.google.com)
[17]Android, “Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma
android de google.” {En línea},{04/08/2017} disponible en:
(https://e-
archivo.uc3m.es/bitstream/handle/10016/6506/PFC_Jaime_Aranaz_Tudela_201011613262
9.pdf?sequence=1 )
[18] “bibvirtualdata” ,{En línea}.{06/08/2017} disponible en:
(http://sisbib.unmsm.edu.pe/bibvirtualdata/monografias/ingenie/molina_nc/cap03.pdf)
[19] “Tecnologia GSM”,{En línea},{06/08/2017} disponible en: 8http://eve-ingsistemas-
u.blogspot.com.co/2012/04/el-sistema-global-para.html)
[20] “GSM-07” ,{En línea},{09/08/2017} disponible en: (http://ocw.upm.es/teoria-de-la-
senal-y-comunicaciones-1/comunicaciones-
movilesdigitales/contenidos/Presentaciones/GSM-07.pdf)
[21] “Acceso móvil: UMTS (3G)” ,{En línea}.{10/08/2017} disponible en:
(http://www.minetad.gob.es/telecomunicaciones/banda-
ancha/tecnologias/movil/Paginas/UMTS.aspx)
79
[22] “LTE y LTE Advanced” ,{En línea}.{10/08/2017} disponible en:
(http://www.areatecnologia.com/tecnologia/lte.html)
[23] “Qué es Ionic 2” ,{En línea}.{11/08/2017} disponible en:
(https://desarrolloweb.com/articulos/que-es-ionic2.html)
[24] “Circuios electricos y electronicos” ,{En línea}.{12/08/2017} disponible en:
(http://cireleele.blogspot.com.co/2014/05/dispositivos-que-utilizaremos-en-las.html)